Re: [ortc] Undefined RTCRtpListener behavior (#48)

On 13 April 2014 16:45, Bernard Aboba <bernard.aboba@gmail.com> wrote:

> Questions below.
>
> On Apr 13, 2014, at 3:33 PM, Martin Thomson <notifications@github.com>
> wrote:
>
> Don't make it so complex. Here's some simple rules.
>
>    1. SSRC wins.
>
> [BA] Can you clarify what this means? Is it "check first for a match on
> SSRC only" or "if there is a more specific match with an SSRC choose that
> rule?"
>

It means that you can a) only have one RTPListener with a given SSRC (for a
given ICE/DTLS transport) and that b) if you find an RTPListener that
matches on SSRC, stop looking.

>
>    1. Receiver ID is used in the absence of SSRC.
>    2. Payload type last, because that's trickier.
>
> [BA] what if there is no PT rule? Can matches occur based on SSRC/AppId
> alone?
>

That's pretty much the point of AppID, isn't it?  To match streams ahead of
having to fall back on inference (which is what PT is, because there's no
guarantee that a PT match is unique).

>
>
> Once a match is made, the SSRC is copied in and then rule 1 is used from
> then on.
>
> [BA] Is it only SSRC that is copied in, or also PT?
>

Only the SSRC.  Presumably the listener has a description of the codec that
the PT maps to, or you are unable to use the packet.

> Mismatches are only a problem (and worth reporting perhaps ... but in
> something like stats) when:
>
> a. Payload type for a known SSRC isn't known.
>
> [BA] Is a PT match always required?
>

No definition for PT == no decode.  But decoding comes after correlation,
so I wouldn't want to create a requirement that forced the correlating
component to know about PT.

> b. Receiver ID comes with with something else.
>
>
> [BA] Due to SSRC conflict a new SSRC can appear with a previously matched
> AppId without misconfiguration.  That should just copy in a new SSRC.
>

Yep.  That's rule 2.

What I was concerned with here was cases where you get a different receiver
ID on the same SSRC.  That creates a situation where you have an SSRC
collision that the colliding peers might be unaware of.  You don't want to
switch on receiver ID, because there is no guarantee that the receiver ID
will continue to be sent.  Therefore, the best response is to flag it and
discard the packet.  If the new sender continues to send, but subsequently
drops the header extension, THEN you are in real trouble.


> It is odder if a different AppId appears with an already configured SSRC.
> Then you'd either need an error event or decide which rule to evaluate
> first.
>
> Both indicate either misconfiguration or SSRC collision between remote
> peers in the RTP session. Neither is of particular concern.
>
>
> [BA] Agree that SSRC collision shouldn't be a concern.
>