[SIPForum-discussion] RTP packet loss tolerance/ timers

[Dale R. Worley]

Amanpreet Singh <amanpreeet.singh at gmail.com> writes:
> I'm looking for the best practices to have minimum packet loss/ delays in
> case of primary network link failure. As the network secondary link takes
> about 3 seconds to come up.
>
> What best we can do on the application side to have the minimum RTP packet
> loss? Do we have timeout, retransmission timers for RTP, or any mechanism
> to adjust to minimize the loss. if not adjustable, default values based on
> which we can try changing network layer failover.

If you're sending real-time data, such as a two-way conversation, if the
link loses 3 seconds of data, you're going to lose 3 seconds of data.
Video and audio codecs use various tricks to cover up single packet
losses by synthesizing data to fill the gap in a way that avoids humans
perceiving the gap.  But there's no way to do that with a 3 second gap,
the recipient will notice.

If you're sending one-way data in near-real-time, and the major losses
are three-second gaps, you could send the audio data twice, with a
three-second offset between them.  A suitable decoder can patch the two
together to cover 3-second losses.  RFC 2198 gives a framework for
sending RTP packets that contain both a primary stream and a delayed,
redundant secondary stream.  But unfortunately, RFC 2198 specifies a
14-bit field to give the time offset between the streams, and with a
typical 8k/sec sample rate, the maximum value that can be specified is
2.048 seconds, which isn't long enough for your situation.

However, you could specify two separate RTP streams in the SDP, one of
which is the same packets as the other but transmitted 3 or more seconds
later.

Dale