<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 02 Mar 2015, at 16:54, Matt Jordan <<a 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></body></html>