[asterisk-dev] [Code Review] 4453: Asterisk 14: RTP improvements

[Mark Michelson]

On 03/02/2015 10:22 AM, Olle E. Johansson wrote:
>
> On 02 Mar 2015, at 16:54, Matt Jordan <reviewboard at asterisk.org 
> <mailto:reviewboard at asterisk.org>> wrote:
>
>> {quote}
>> Buffering/reordering
>>
>> RTP may be received in bursts, out of order, or in other less-than-ideal ways. Asterisk will implement reception buffers to place incoming RTP traffic into, potentially reordering packets as necessary if they arrive out of order.
>> {quote}
>>
> By default, asterisk should forward RTP packets without any buffer, 
> without reordering or doing anything. Today Asterisk renumbers packets 
> - thus hiding packet loss and reordering. This is bad.
>
> Forwarding with packet loss and reordering is quite ok as default. The 
> endpoint in the call will sort it up with a jitter buffer.
>
> In some cases Asterisk is the endpoint of the RTP stream (IVR, 
> protocol conversion). In that case we can apply a buffer like any 
> endpoint. But not by default.
>
> I guess cases with transcoding involved also requires a jitter buffer.
>
> /O

After reading this response and thinking about it for a while, I think 
you're 100% correct here. In fact, I think the best course of action is 
not to perform buffering or reordering at the RTP layer under any 
circumstances. Instead, the application can be responsible for deciding 
what is appropriate. When I say "application" here, I don't mean the 
dialplan application Asterisk is running, but a high-level description 
of what is happening, media-wise.

So for instance, if a native local RTP bridge is being used, then RTP 
comes in one side and is directly sent out the other side. We can make 
the assumption that the RTP-capable endpoints will perform their own 
buffering, re-ordering, and synchronizing. We just need to make sure 
that we provide proper timestamps so that a receiver can accurately 
reconstruct the stream.

If other types of bridges are being used, then it is dependent on the 
channel technology and the number of parties in the bridge whether we 
want to buffer/synchronize. And if we do want to perform buffering or 
synchronization of streams, that should be taken care of at the channel 
or bridge level, not at the RTP level.

For IVRs or call recording, then like you mentioned, 
buffering/synchronizing is always a good idea. But again, this doesn't 
need to happen at the RTP layer.

My plan here is to remove the language about buffering and 
synchronization from the RTP layer. Does anyone object to this?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20150302/9f5d56eb/attachment-0001.html>