Subject: [AVT] Possible issues in RTP/RTCP (RFC 3550)

From: "Bhattacharya, Abhijit \(Abhijit\)" <[email-masked]>
Date: Wed, 7 Feb 2007 23:34:29 +0530

Hi all,

I feel the following issues exist in RFC 3550 (RFC for RTP and RTCP).

Problem 1:
If an RTP packet arrives after the jitter tolerance period of that
network node on which the packet is received, the packet becomes useless
because the frame which was supposed to contain this packet has already
been played out to avoid delay. So this packet, which arrived after the
stipulated jitter tolearnce period, is as good as lost for the receiving
node, although it has arrived at its destination. At present this packet
is not considered as a lost packet.

Example:

If an RTP packet of sequence number n arrives at time t1 at a network
node N with ptime of p and jitter tolerance of J, then the expected time
e of arrival of RTP packet of sequence number n-1 at the same node is
(t1 - p). Hence the RTP packet with sequence number n-1 is a delayed
packet if it arrived at t2 and (t2 - e) > J. This is because, if the RTP
packet of sequence number n-1 comes after that, its likely that the next
RTP packet would have been played out thus making the RTP packet with
sequence number n-1 useless.

Effect:
It gives a wrong impression of loss of packets as the quality of the
media (audio/video) played out is definitely reduced due to the absence
of the packet which arrived late. If this happens more frequently, the
quality of the media will be significantly degraded although it will not
be reflected in the report showing loss of packets.

Problem 2: 

Now if a duplicate RTP packet is received, it is not handled separately.
It is considered for all the feedback report generation. Since loss of
packets is equal to expected packets - the received number of packets,
let us consider the following example.

Example: 

Let us consider the expected packet count to be c and received packets
to be r which includes d number of duplicate packets.  Now lost packet
count p is equal to c-r, but actually the count MUST be c-r-d.  Thus the
lost packet count gives a wrong impression.

I need some advice how to go about with this issue. 

Thanks and regards,

Abhijit Bhattacharya

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Randell Jesup <[email-masked]>
Date: Wed, 07 Feb 2007 17:12:18 -0500

>be reflected in the report showing loss of packets.

Correct, though RTCP stats are not a measure of media quality, so the
use you're assuming isn't the use that RTCP SR/RR were designed for.  For
media quality RTCP, see some of the other specs/drafts (RTCP-XR, video, etc).

>packets is equal to expected packets - the received number of packets,

Correct.

Again, SR/RR RTCP are not media-quality reports (or even very good
link-quality reports).  Don't try to use them for that.  SR/RR are
(apparently) designed to be simple to calculate and not require any
significant amount of state to generate (like a list of recent missing
packets). 

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)

---

From: "Alan Clark" <[email-masked]>
Date: Wed, 7 Feb 2007 17:41:45 -0500

As Randell stated in his reply - you should consider using RTCP XR (RFC3611)
for multimedia applications.
 
The RFC3611 VoIP metrics block has
- packet loss rate (which is defined as NOT including duplicate packets)
- packet discard rate (packets that arrived too late were discarded)
 
- burst/gap metrics - which report separately on periods of high and low
loss/discard.  Using the default value for Gmin of 16
 .....a burst would be a period of 5% or higher packet loss/discard
 .....during gaps, any lost or discarded packets would be preceded and
followed by at least 16 good packets
 
- etc
 
Regards
 
Alan Clark
Telchemy

  _____  

From: Bhattacharya, Abhijit (Abhijit)
[mailto:[email-masked]] 
Sent: Wednesday, February 07, 2007 1:04 PM
To: [email-masked]
Subject: [AVT] Possible issues in RTP/RTCP (RFC 3550)

Hi all,

Problem 1:
If an RTP packet arrives after the jitter tolerance period of that network
node on which the packet is received, the packet becomes useless because the
frame which was supposed to contain this packet has already been played out
to avoid delay. So this packet, which arrived after the stipulated jitter
tolearnce period, is as good as lost for the receiving node, although it has
arrived at its destination. At present this packet is not considered as a
lost packet.

Example:

If an RTP packet of sequence number n arrives at time t1 at a network node N
with ptime of p and jitter tolerance of J, then the expected time e of
arrival of RTP packet of sequence number n-1 at the same node is (t1 - p).
Hence the RTP packet with sequence number n-1 is a delayed packet if it
arrived at t2 and (t2 - e) > J. This is because, if the RTP packet of
sequence number n-1 comes after that, its likely that the next RTP packet
would have been played out thus making the RTP packet with sequence number
n-1 useless.

Effect:
It gives a wrong impression of loss of packets as the quality of the media
(audio/video) played out is definitely reduced due to the absence of the
packet which arrived late. If this happens more frequently, the quality of
the media will be significantly degraded although it will not be reflected
in the report showing loss of packets.

Problem 2: 

Now if a duplicate RTP packet is received, it is not handled separately.  It
is considered for all the feedback report generation. Since loss of packets
is equal to expected packets - the received number of packets, let us
consider the following example.

Example: 

Let us consider the expected packet count to be c and received packets to be
r which includes d number of duplicate packets.  Now lost packet count p is
equal to c-r, but actually the count MUST be c-r-d.  Thus the lost packet
count gives a wrong impression.

Thanks and regards,

Abhijit Bhattacharya