[asterisk-dev] [Code Review] fix regression after rev 336294 that music on hold didnt worked when a call was put on hold in a local_bridge.

[Matt Jordan]

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

Ship it!


I put together a test that exercised the scenario that you had and was able to produce some bad side effects from the local bridge not handling that particular frame.  As it stands now, if two SIP endpoint's RTP sessions are bridged using the local bridge loop, and the frame is queued up to the local bridge for any reason, the bridge will exit prematurely.

Since the channels currently do not handle the frame (chan_sip absorbs it in sip_indicate; other drivers have no handler for it and will, for the most part, return -1 from their respective indicate methods), having the bridge swallow the frame is at least in line with how the remote_bridge handles it in the case of everything but an UNHOLD.  Since, in the local bridge, there isn't any reason to send any additional re-invites in the case of an UNHOLD, there's no reason to send anything up to the channel driver level.

I'll check in the tests for the testsuite after this has been committed, but I'm inclined to think there isn't any additional work that needs to be done to handle this control frame at this time.

- Matt


On Dec. 22, 2011, 3:58 a.m., schmidts wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1640/
> -----------------------------------------------------------
> 
> (Updated Dec. 22, 2011, 3:58 a.m.)
> 
> 
> Review request for Asterisk Developers and jrose.
> 
> 
> Summary
> -------
> 
> with adding the AST_CONTROL_UPDATE_RTP_PEER control frame music on hold stoped working when a call was put on hold. The problem was that the control frame was only handled when received in a remote_bridge but not in a local_bridge.
> By adding the handling of the UPDATE_RTP_PEER frame also to local_bridge moh works again.
> 
> 
> This addresses bug ASTERISK-19095.
>     https://issues.asterisk.org/jira/browse/ASTERISK-19095
> 
> 
> Diffs
> -----
> 
>   team/schmidts/unleash-the-beast/main/rtp_engine.c 348832 
> 
> Diff: https://reviewboard.asterisk.org/r/1640/diff
> 
> 
> Testing
> -------
> 
> tested several calls. Moh is working again when a call is put on hold.
> 
> 
> Thanks,
> 
> schmidts
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20111228/966240e1/attachment.htm>