Subject: RTCP in Rendez-Vous 1.0.2

From: Hugh LaMaster <[email-masked]>
Date: Wed, 27 May 1998 17:31:40 -0700 (PDT)

I'm seeing some odd RTCP apparently from Rendez-Vous 1.0.2 and I was
wondering if this was a known effect.  In "Places ..."  (224.2.172.238)
the traffic is being sourced on port 51482 and the RTCP reports on 51483. 
Someone is viewing it using Rendez-Vous 1.0.2, and I am seeing what look
like receival reports for all the other RTCP senders.  So, more than
likely I am totally confused, but, there is some chance there is a bug in
Rendez-Vous 1.0.2 RTCP processing which interprets RTCP receival reports
from other receivers as "sources".  Do others see this/like to interpret
it?  Look at the traffic for 224.2.172.238.

--
 Hugh LaMaster, M/S 233-21,    ASCII Email: [email-masked]
 NASA Ames Research Center     Or:          [email-masked]
 Moffett Field, CA 94035-1000  No Junkmail: USC 18 section 2701
 Phone: 650/604-1056           Disclaimer:  Unofficial, personal *opinion*.

---

From: Bill Fenner <[email-masked]>
Date: Thu, 28 May 1998 08:25:41 PDT

Yup, I've seen this; Apple's QuickTime viewer and an as-yet-unnamed
tool also seem to do it sometimes.  From what I've seen, the RR's
all have a ehsr of 0, which is pretty easy to detect and skip.
(The only explanation for an ehsr of 0 is having received 0 packets
from this source).  My patch for rtpmon to skip these RR's is
something like this:

Index: monitor.cc
===================================================================
RCS file: /tilde/fenner/cvs/rtpmon/monitor.cc,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -u -r1.17 -r1.18
--- monitor.cc	1998/02/02 21:42:51	1.17
+++ monitor.cc	1998/02/02 22:36:01	1.18
@@ -537,6 +543,16 @@
 			     u_char* ep, Member *m, u_int32_t addr)
 {
     while ((u_char*)rr < ep) {
+	if (rr->rr_ehsr == 0) {
+	    /*
+	     * Several tools insert bogus RR records.  Luckily, all
+	     * (so far) set the extended highest sequence received
+	     * to 0 on the bogus records.  If they haven't received
+	     * any packets, then it's probably a bogus RR so skip it.
+	     */
+	    rr++;
+	    continue;
+	}
 	u_int32_t srcid = rr->rr_srcid;
 	Member* s = lookup(srcid, 0);
 	int loss = ntohl(rr->rr_loss) & 0x00ffffff;

  Bill