[asterisk-dev] [Code Review] 4192: Update channel Stasis topics during a masquerade

Mark Michelson reviewboard at asterisk.org
Tue Nov 18 16:04:42 CST 2014


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

(Updated Nov. 18, 2014, 10:04 p.m.)


Status
------

This change has been discarded.


Review request for Asterisk Developers and opticron.


Repository: Asterisk


Description
-------

Testing revealed a regression that occurred when performing an attended transfer to a Stasis application. StasisEnd events were not being seen for the channels involved in the masquerade that occurs in this situation.

In the test, a channel not in a is attended transferred into a Stasis application. When performing an attended transfer into an application, a masquerade is required. The transferee channel takes the place of the channel that previously was in the Stasis application. The masquerade operation calls into Stasis, stating that a channel in Stasis is being replaced by a channel that was previously not in Stasis. The expected outcome is that the channel that previously was not in Stasis will have all its events sent to the Stasis application. The problem is that the masquerade operation, while updating the internals of the involved channels, never actually updates the Stasis channel topics on the involved channels. The result is that forwards from an incorrect channel topic are going to the interested Stasis application, which don't match up with what the Stasis app thinks it is interested in. By updating the topic on the channel prior to calling masquerade fixup/breakdown callbacks, the forwards work as expected and StasisEnd messages reach the application as expected.


Diffs
-----

  /branches/12/main/channel_internal_api.c 428116 
  /branches/12/main/channel.c 428116 

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


Testing
-------

Re-ran the attended transfer test that had been failing and found that it worked consistently.


Thanks,

Mark Michelson

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20141118/7cbbbf7d/attachment.html>


More information about the asterisk-dev mailing list