- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Tue, 18 Feb 2014 13:30:28 -0800
- To: Peter Thatcher <pthatcher@google.com>
- Cc: Bernard Aboba <Bernard.Aboba@microsoft.com>, "public-orca@w3.org" <public-orca@w3.org>
On 18 February 2014 13:18, Peter Thatcher <pthatcher@google.com> wrote: > I think I'm more in favor of #2. After sleeping on it, I am too. I think that the first would more likely be a sign of poorly configured application. > As for the receiverId, we should certainly include it in the event, but the > question I have is: if you configure an RtpReceiver to expect a receiverId, > and packets are received with that receiverId, so the packets are routed to > the correct RtpReceiver, but then later packets are received with the same > SSRC, but not the receiverId header extension, is the packet routed to the > RtpReceiver (ie is the ssrc auto-configured for that RtpReceiver) or is > onunhadledrtp fired, or both? I think that the expectation is that the receiver ID is only sent in the first burst of packets (so that P(at least one packet with receiver ID got through) =~ 1). So the answer to this would be no. SSRC reuse is the only case where this could cause problems. With receiver ID, this is easy because a new stream will have a new receiver ID. The only case that might be a problem is where the new stream doesn't have receiver ID. In either case, I think that there would have to be an RTCP BYE for the old SSRC, otherwise it would be perfectly normal to treat a new stream on the same SSRC as a collision.
Received on Tuesday, 18 February 2014 21:30:57 UTC