On 03/02/2015 10:22 AM, Olle E. Johansson wrote:
On 02 Mar 2015, at 16:54, Matt Jordan <reviewbo...@asterisk.org
<mailto:reviewbo...@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?
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
