[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/#review5075
-----------------------------------------------------------



team/schmidts/unleash-the-beast/main/rtp_engine.c
<https://reviewboard.asterisk.org/r/1640/#comment9341>

    While this may fix this particular problem, I'm not sure it was ever expected that an AST_CONTROL_UPDATE_RTP_PEER frame would be handled in an RTP local bridge.
    
    There are two instances where the AST_CONTROL_UPDATE_RTP_PEER frame will be queued up:
    1. When processing a 200 OK response to a re-invite request where T38 is disabled
    2. When processing a re-INVITE request with T38 disabled, after sending a 100 Trying and 200 OK
    
    The question is: should we be queueing this frame in the presence of any re-invite that meets these criteria, or only if direct media is enabled?


- 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/20111223/b325b130/attachment.htm>