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

[Dan Austin]

I’d say it is a bug.  When packetization support was added it did
prevent native bridging if the call legs had different requirements,
and the code looked much like what you have in the review.

Dan

From: asterisk-dev-bounces at lists.digium.com [mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of Mark Michelson
Sent: Wednesday, February 06, 2013 11:53 AM
To: Mark Michelson; Asterisk Developers; Mark Michelson
Subject: [asterisk-dev] [Code Review] Disallow native RTP bridging when packetization differs between streams

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


Review request for Asterisk Developers.
By Mark Michelson.
Description

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.


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.

Bugs: ASTERISK-20650<https://issues.asterisk.org/jira/browse/ASTERISK-20650>
Diffs

 *   /branches/1.8/main/rtp_engine.c (380922)

View Diff<https://reviewboard.asterisk.org/r/2319/diff/>


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