<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 03/02/2015 10:22 AM, Olle E.
Johansson wrote:<br>
</div>
<blockquote
cite="mid:CE07B4D7-18BA-4F03-99AC-D8E078FDCA27@edvina.net"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<br>
<div>
<div>On 02 Mar 2015, at 16:54, Matt Jordan <<a
moz-do-not-send="true"
href="mailto:reviewboard@asterisk.org">reviewboard@asterisk.org</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<pre style="font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: pre-wrap; word-wrap: break-word;">{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}
</pre>
<br class="Apple-interchange-newline">
</blockquote>
</div>
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.
<div><br>
</div>
<div>Forwarding with packet loss and reordering is quite ok as
default. The endpoint in the call will sort it up with a jitter
buffer.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>I guess cases with transcoding involved also requires a
jitter buffer.</div>
<div><br>
</div>
<div>/O</div>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
My plan here is to remove the language about buffering and
synchronization from the RTP layer. Does anyone object to this?<br>
</body>
</html>