[asterisk-dev] [Code Review] Disallow native RTP bridging when packetization differs between streams

[jcolp]

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

Ship it!


Yes to all 3 imo.

- jcolp


On Feb. 6, 2013, 1:53 p.m., Mark Michelson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2319/
> -----------------------------------------------------------
> 
> (Updated Feb. 6, 2013, 1:53 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> In the linked issue, it is brought up that faxing was broken in Asterisk 1.8 due to the fact that Asterisk was not honoring the packetization specified in an SDP. As it turns out, the reason why things went awry was that a local RTP bridge was being used, thus bypassing any smoothers created on the RTP streams.
> 
> In order to fix this, I propose this fix. With this, there can be no native RTP bridging (local or remote) if the packetization of the streams is not compatible. If packetization is not the same on both sides of the call, then the bridging must go through the core.
> 
> I'm looking for three pieces of feedback here
> 
> 1) Is this approach correct? Should we prevent native RTP bridging if packetization of the streams differs?
> 2) Is the code implemented correctly?
> 3) Should this change be thrown into 1.8 as is? I think this is a bug myself, so I was planning to put this into 1.8. However, I would be interested in knowing if this sort of behavior change could cause unintended consequences.
> 
> 
> This addresses bug ASTERISK-20650.
>     https://issues.asterisk.org/jira/browse/ASTERISK-20650
> 
> 
> Diffs
> -----
> 
>   /branches/1.8/main/rtp_engine.c 380922 
> 
> Diff: https://reviewboard.asterisk.org/r/2319/diff
> 
> 
> Testing
> -------
> 
> I tested this by placing a call from SIPp through Asterisk to a Polycom phone on my desk. The SIPp scenario specifies a ptime of 30. The leg between Asterisk and the phone specifies a ptime of 20. Using wireshark, I can see that before this patch is applied, the different packetizations allow for a local RTP bridge to be used. A packet capture shows that audio from Asterisk to SIPp comes in 20 ms segments. With the patch applied, local RTP bridging is prevented. A packet capture shows that audio from Asterisk to SIPp comes in 30 ms segments.
> 
> 
> Thanks,
> 
> Mark
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130206/b1105b9b/attachment-0001.htm>