Review Board 1.7.16

Disallow native RTP bridging when packetization differs between streams

Review Request #2319 - Created Feb. 6, 2013 and submitted

Mark Michelson
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.
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.
Ship it!
Posted (Feb. 6, 2013, 9:08 a.m.)
Yes to all 3 imo. runs on a server provided by Digium, Inc. and uses bandwidth donated to the open source Asterisk community by API Digital Communications in Huntsville, AL USA.
Please report problems with this site to