Subject: [AVT] Bad RTCP in IETF multicast sessions

From: Ross Finlayson <[email-masked]>
Date: Wed, 19 Mar 2003 17:11:07 -0800

FYI, I have noticed a couple of problems (one minor; one major) with RTCP 
packets being sent on at least two of the current IETF multicast sessions: 
"channel 1 MPEG-1" and "channel 2 MPEG-1".  (I haven't checked the H.261 
sessions.   Note also that the separate, high-bitrate, NCast sessions do 
not seem to have the problem.)

First, the minor problem: Two of the participants (receivers):
         128.223.214.24 (==tesla.uoregon.edu)
         158.38.62.70 (==tikneppen.uninett.no)
on the "channel 1 MPEG-1" session have been sending RTCP packets like the 
following:
         81ca0002 e8e9e765 010e3132
These appear to be RTCP "CNAME" "SDES" packets, but there are a couple of 
problems with them:
1/ Because these RTCP packets don't begin with a "RR" (or "SR"), they're 
illegal, according to section 6.1 of the current RTP spec: 
"draft-ietf-avt-rtp-new-12.txt".
2/ The "length" field in the "CNAME" SDES item (see section 6.5.1 of the 
RTP spec) is 14 (==0x0e), but there are only two following bytes (0x31 and 
0x32)!

These participants both appear to be using the same (broken) 
implementation.  Is this MIM?  In any case, it should be fixed.

Now, the major problem: The sending nodes for both "channel 1 MPEG-1" and 
"channel 2 MPEG-1"
         130.129.32.30 and 130.129.32.10, respectively
are sending RTCP "Sender Report" (SR) packets that contain a bad  RTP 
timestamp field.  Because of this, the RTP timestamp -> NTP time mapping is 
getting messed up, which in turn is messing up client audio/video 
synchronization.

Example:
1/ A RTP (video) packet with timestamp 0x2bfc3a46 is received at (Unix 
epoch) time 1048118445.555259
2/ Next, a RTCP SR packet is received (for the video session):
         80c80006 16a2d20b c2238330 69780000 3f0b1b5d 00160cf2 56d52c81 
81ca0005         16a2d20b 010d3133 302e3132 392e3332 2e333000 81cc0008 
16a2d20b 4d534f4b         1964eb29 00010010 ec1f67fd da1efce1 194ac2ed 
7d7ca166
(This RTCP packet actually contains a SDES and an APP packet, following the 
SR, but for the purpose of this message I care only about the SR.)
The NTP timestamp in this SR packet is
         0xc2238330,0x69780000
which maps to the (Unix epoch) time 1048118448.411987.  So far, so 
good.  However, the RTP timestamp in this SR is
         0x3f0b1b5d
which is *completely different* from the timestamps that have been 
appearing in RTP packets around this time.  In fact, it's more than 3000 
seconds later!  Note that the very next packet received is:
3/ A RTP (video) packet with timestamp 0x2bfc6932

It wouldn't be so bad if both the video and audio sessions had SRs with 
NTP->RTP timestamp mappings that were 3000+ seconds too 
high.  Unfortunately, though, this happens only with the video 
session.  The RTP timestamps in the audio session's SR's are OK.  Because 
of this, a receiver's A/V time synchronization can get badly messed up.

Please try to fix this (if not for the rest of this IETF, then in time for 
the next one).

         Ross.

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

---

From: "Lucy E. Lynch" <[email-masked]>
Date: Wed, 19 Mar 2003 17:21:57 -0800 (PST)

Ross -

yes, I'm running mim on tesla from the command line (using
an sdp file).

Lucy E. Lynch 				Academic User Services
Computing Center			University of Oregon
[email-masked]		(541) 346-1774/Cell: 912-7998