RtcRtpReceiver matching rules for payload, SSRC and receiverId

Currently the RtcRtpReceiver object is setup to match incoming RTP 
streams based on 3 configurable options:
- payload type
- SSRC
- receiverId (aka appId)

Each one of these is "nullable" meaning, you can specify some 
combination of rules to match an incoming stream.

While this is simple, it can create some ambiguities which I will 
attempt to illustrate and suggest possible resolutions.

----

Use case (1): Specify an RtcRtpReceiver matching as:
- receiverId = "foo"
- payload type = 96

Then any stream which has a receiverId as "foo" and a payload of "96" 
will match that RtcRtpReceiver object. Any stream that does not match 
will be treated as "unhandled" and an "unhandled" event will fire.

----

Use case (2): Specify an RtcRtpReceiver matching as receiverId = "foo" 
but RTP stream drops "foo" receiverId extension header after first 
remote RTCP "ack" of that RTP stream

If a receiverId (DOMString) of "foo" comes in with an SSRC of "1000", as 
soon as the RTP stream gets acknowledged via an RTCP report then the 
receiverId can be dropped from the RTP packet extension header. But an 
implicit receiverId of "foo" must remain attached to every SSRC "1000" 
even though the receiverId is no longer present to continue allowing the 
RtcRtpReceiver matching rules to apply.

In my mind, the best way to handle this scenario.

If later suddenly another RTP SSRC stream of 1000 added a receiverId of 
"bar" instead of "foo", then that SSRC 1000 RTP stream no longer would 
match the "foo" rule and any further SSRC of 1000 without any receiverId 
would be considered as having a "bar" receiverId and not "foo".

----

Use case (3): Two RtcRtpReceiver objects matching as:
a) SSRC = 5000
b) SSRC = 5000, payload = 101

In this case, an RTP stream with 5000 and a payload ID that did not 
match 101 would match to RtcRtpReceiver object (a) and an RTP stream 
with SSRC 5000 but a payload ID of 101 would match to RtcRtpReceiver 
object (b). In other words, the most specific match wins over the 
general match.

----

Use case (4): Two RtcRtpReceiver objects matching as:
a) SSRC = 5000, payload = 96
b) SSRC = 5000, receiverId = "foo"

In this case, an RTP stream with SSRC 5000 and a payload ID of 96 would 
match (a). An RTP stream with SSRC 5000 and payload ID of 101 with no 
receiverId would not match (a) or (b) and would be "unhandled".

An RTP stream with SSRC 5000, payload ID of 96 and receiverId of "foo" 
would be ambiguous as both (a) or (b) could match. I think there needs 
to be precedence rules for matching in such cases. I'm open to debate as 
to what those rules should be. Would payload trump receiverId? Would it 
depend on RtcRtpReceiver construction order? Would it go to "unhandled" 
for the web app developer to resolve the conflict?

----

Use case (5): One RtcRtpReceiver object matching as:
- receiverId = "foo"

RTP stream (A) arrives with receiverId = "foo". RTP stream (B) arrives 
with receiverId = "foo".

Since there's only one "MediaStreamTrack" associated to the 
RtcRtpReceiver object, what happens to these two RTP streams? Yes, it's 
possible (perhaps likely) that one stream is replacing the other thus 
"last one wins" is an acceptable rule.

However, it's also possible this is not the case you have two streams 
and you need to decide what to do. Options:
i) last one wins, one RTP stream is thrown to the floor and the other is 
rendered
ii) both streams win. For audio, the system could auto-mix and treat 
each as contributing sources, but that's not an option for video so it 
would mean an event firing to give additional "MediaStreamTracks" as 
part of the RtcRtpReceiver which was not the original design intent for 
RtcRtpReceiver. The idea was that once "start(...)" was called on an 
RtcRtpReceiver, the MediaStreamTrack object would be valid to pre-wire 
to the rendered output to avoid any missing starting packets which might 
cause glitches.
iii) hybrid model - MediaStreamTrack is setup with "start(...)" to 
pre-wire, but an event fires to indicate a new MediaStreamTrack 
available but the existing MediaStreamTrack remains alive. This would 
imply some small buffering should be done to prevent glitches during the 
setup phase (which in my mind is already need for "unhandled" RTP 
streams so that's not a big deal for me).



Thoughts?


Filed as: https://github.com/openpeer/ortc/issues/48

Received on Sunday, 13 April 2014 19:28:21 UTC