[asterisk-bugs] [Asterisk 0007904]: Transfer capability is inherited by a channel after being transfered via atxfer

noreply at bugs.digium.com noreply at bugs.digium.com
Tue Jan 15 01:27:27 CST 2008


A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=7904 
====================================================================== 
Reported By:                k-egg
Assigned To:                otherwiseguy
====================================================================== 
Project:                    Asterisk
Issue ID:                   7904
Category:                   Applications/app_dial
Reproducibility:            always
Severity:                   major
Priority:                   high
Status:                     assigned
Asterisk Version:           1.2.11 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        No 
Request Review:              
====================================================================== 
Date Submitted:             09-08-2006 06:37 CDT
Last Modified:              01-15-2008 01:27 CST
====================================================================== 
Summary:                    Transfer capability is inherited by a channel after
being transfered via atxfer
Description: 
PhoneA calls PhoneB (221)
by Dial("mISDN/12-1", "mISDN/1/221|15|tr")
PhoneA is not allowed to initiate transfers at that time.
PhoneB is allowed to.

PhoneB transfers PhoneA to PhoneC(208) (attended trans) 
by Dial("Local/208 at isdn-nt-1-bcec,2", "mISDN/8/208|15|")

now PhoneA now is allowed to initiate transfers: 

for example:
exten => 1,1,Playback(tt-monkeys)
cli output: 
- Started music on hold, class 'default', on Local/208 at isdn-nt-1-bcec,1
    -- Playing 'pbx-transfer' (language 'de')
    -- Executing Playback("Local/1 at macro-dial_intern-e687,2",
"tt-monkeys") in new stack
    -- Playing 'tt-monkeys' (language 'en')



Is this a bug? a feature? or designed to behave like this?
wondering...

kegg
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
has duplicate       0010198 Important vulnerability after native tr...
related to          0010897 Parked call inherits transfer capability
====================================================================== 

---------------------------------------------------------------------- 
 sergee - 01-15-08 01:27  
---------------------------------------------------------------------- 
otherwiseguy,

there were 2 things:

1. Initialy Reported problem with 't' option
2. Problem with 'T' option - reported by you.


There was definitely a bug (wrong C code) with 1st issue - my patch fixes
it.

2nd issue is not a bug, code is ok there is nothing wrong with it. This is
how transfer was _designed_ to work. As for me i don't like it too, but i
don't see a way of fixing it in current implementation of transfer
(described in my precious posts here). 

May be you can offer a way of fixing it? i would glad to hear a fresh
ideas..

Probably we need to export some sort of API to Asterisk's dialplan, for
controlling xfer capabilities by users. But anyway - this is different
issue IMHO, more likely feature request. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
01-15-08 01:27  sergee         Note Added: 0076954                          
======================================================================




More information about the asterisk-bugs mailing list