[asterisk-dev] [Code Review] Fix SIP blind transfer playing parking slot to caller.

rmudgett reviewboard at asterisk.org
Thu Feb 9 19:10:11 CST 2012


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1730/
-----------------------------------------------------------

(Updated Feb. 9, 2012, 7:10 p.m.)


Review request for Asterisk Developers and Mark Michelson.


Changes
-------

Fix SIP parking extension test to check for the correct extension and context requested by the transfer.


Summary
-------

Using SIP blind transfer to a custom parking lot access extension plays the parking slot to the parked call.

The BLINDTRANSFER channel variable was not being used correctly to determine the parking channel name.

BLINDTRANSFER is set by features DTMF, SIP, and IAX when the blind transfer methods are invoked.

This patch also fixes the ability of timedout parked calls to use the correct channel to callback the parker.


This addresses bugs AST-766 and ASTERISK-19322.
    https://issues.asterisk.org/jira/browse/AST-766
    https://issues.asterisk.org/jira/browse/ASTERISK-19322


Diffs (updated)
-----

  /branches/1.8/channels/chan_sip.c 354798 
  /branches/1.8/main/features.c 354798 

Diff: https://reviewboard.asterisk.org/r/1730/diff


Testing
-------

Parked a call with a custom parking lot access extension dialplan where the Park application is not the first priority of the extension.

exten => 600,1,Park()

exten => 700,1,NoOp()
exten => 700,n,Park()

exten => 800,1,NoOp()
exten => 800,n,ParkAndAnnounce(something appropriate was put here)

The initial call was made to and from the transferer.
SIP blind transfered to the 600 and 700 extension call.
SIP attended transfered to the 600 and 700 extension.
SIP blind transfered to the 800 extension.
SIP attended transfered to the 800 extension does not work and likely is not a valid scenario anyway.  It is outside the scope of this patch anyway.

Now works as expected for the tested scenarios.


Thanks,

rmudgett

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20120210/579727ad/attachment.htm>


More information about the asterisk-dev mailing list