Subject: Timestamp/sequence# following SSRC collision

From: Flemming Andreasen <[email-masked]>
Date: Sun, 13 Aug 2000 22:32:23 -0400

Greetings

The initial value of the RTP timestamp and sequence number SHOULD be
random, and if a source discovers an SSRC collision with itself, it MUST
send an RTCP BYE packet. When the source re-joins the session with a new
SSRC, should the initial RTP timestamp and sequence number be random
again, or can we continue using the old "sequence" ? Does it matter ?

Thanks

        Flemming

--
Flemming Andreasen
Cisco Systems

---

From: [email-masked] (Ron Frederick)
Date: Mon, 14 Aug 2000 08:52:33 -0700

> again, or can we continue using the old "sequence" ? Does it matter ?
From the point of view of some other receiver in the session, the new SSRC
is going to make this participant seem like a brand new sender, at least
until some time later when the first RTCP arrives with their CNAME. So, I
don't really see any value in preserving the sequence numbers and timestamps.
I would treat this case the same as when you first start up and suggest
picking a new random offset for each. I'm not sure it strongly matters,
though.
--
Ron Frederick
[email-masked]

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 20 Aug 2000 17:44:34 -0400

From the viewpoint of the sender (and the one changing the SSRC), it's
easier to keep the sequence number and timestamp progression going,
particularly if the two pieces of code are separate. Thus, I would
certainly not want to prescribe a change. (A receiver is ill-advised to
fail if for some reason there's a ts/seq. no discontinuity, so it should
be ok either way.)

---

From: [email-masked] (Ron Frederick)
Date: Fri, 25 Aug 2000 13:15:58 -0700

> fail if for some reason there's a ts/seq. no discontinuity, so it should
My assumption was that this would be one piece of code, since at the time
you generate each packet you are filling in all of the sequence number,
timestamp, and SSRC. However, I agree that it should be ok either way and
it is probably best for the RTP spec to not require either behavior.
--
Ron Frederick
[email-masked]