W3C home > Mailing lists > Public > public-orca@w3.org > February 2014

Re: [ortc] Proposal: RtpListener for unsignalled ssrcs (#32)

From: Martin Thomson <martin.thomson@gmail.com>
Date: Tue, 18 Feb 2014 13:30:28 -0800
Message-ID: <CABkgnnVy7JqRNJ3nXb7NVaW0uK6YYEVHiUGW-Own6_CCf9k=dw@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:39:24 UTC