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

[noreply at bugs.digium.com]

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 07:20 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 07:20  
---------------------------------------------------------------------- 
k-egg,

i want to clearify the process of 'inheriting' transfer capabilities:

3 parties participate in transfer: transferer, transferee and 3rd party :)
(let's say 111,222,333)
call legs for transferer and transferee are created during normal call

exten => XXX,1,DIAL(SIP/${EXTEN}||t)

let's say 111 calls 222, call established and bridged, 222 is capable of
transfer and 111 is not. When 222 is trying to transfer this call to 333,
transfer creates new call leg by calling DIAL(LOCAL/333 at ..) - so it would
be looped into dialplan, and 333 will "inherit" transfer capabilities
(because of 't' option).

But what happens when our dialplan use 'T' option?

exten => XXX,1,DIAL(SIP/${EXTEN}||T)

Once again 111 calls 222, call bridged. Now 111 is capable of transfer and
22 is not. 111 transfers call to 333. Transfer calls DIAL(Local/333 at ..)
again, and this is the place where everything happens, each DIAL creates
atleast 2 call-legs. Dial through "Local" channel creates virtual call-leg,
you can see it in "core show channels" - something like
"Local/333 at default-2111;1". And this virtual leg is considered to be a
caller, so the option 'T' is applyed to it, and later to 222, when 111
hangup and 222 become connected to 333.

what we could do in this case? explicitly ignore/revoke all transfer
capabilities? That would brake nice behaviour of 't' option... 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
01-15-08 07:20  sergee         Note Added: 0076965                          
======================================================================