[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.

[Kevin Fleming]

> On Dec. 23, 2011, noon, Matt Jordan wrote:
> > team/schmidts/unleash-the-beast/main/rtp_engine.c, lines 914-915
> > <https://reviewboard.asterisk.org/r/1640/diff/1/?file=22384#file22384line914>
> >
> >     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?

While it may be true that those are the only two cases where that control frame is currently generated, that is not an appropriate definition of its semantics. The purpose of this control frame is to indicate that the other RTP endpoint has changed in some material way (address/port, format, etc), so that any bridge/application/channel that is connected to it can react appropriately.


- Kevin


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


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/eacdb44b/attachment-0001.htm>