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

One way get around this is:

1. Check for a rule that matches the AppId in the packet, if present. If no AppId or no match, continue. If there is a match on appId (and PT if that is in the rule), create a rule with only the SSRC, overwriting a previously created SSRC rule if present.
2. Check for a rule that matches the SSRC in the packet. If a match is found, check the PT portion of that rule (if present). If no match, continue.
3. Check for a rule matching only the PT (no SSRC or AppId in the rule).
4. If no match, throw an unhandledrtp event.

With this process, a packet with the same AppId and new SSRC won't result in an unhandledrtp event, just a relatching. However a different AppId and same SSRC would create two rules, both of which would match w/o AppId.


On Apr 13, 2014, at 5:31 PM, Robin Raymond <notifications@github.com<mailto:notifications@github.com>> wrote:


The would presume that once an RtpReceiver is locked onto a stream, it's locked onto that stream forever and any new stream that comes in has to be fired as an unhandled event which needs a new RtpReceiver as oppose to allowing a receiver to be repurposed. In a conference scenario where streams are constantly changed, that means every change would need a new RtpReceiver per changed RTP stream (assuming it was coming from an SFU that didn't re-write the SSRC).

I'm okay with that, but we do still need to have exact rules.

—
Reply to this email directly or view it on GitHub<https://github.com/openpeer/ortc/issues/48#issuecomment-40325145>.