Questions below. On Apr 13, 2014, at 3:33 PM, Martin Thomson <notifications@github.com<mailto: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 for a match on SSRC and PT if that is also in the rule?" 1. Receiver ID is used in the absence of SSRC. [BA] Just receiver ID or also PT if in the rule? 1. Payload type last, because that's trickier. [BA] is this a check for a matching PT-only rule? Once a match is made, the SSRC is copied in and then rule 1 is used from then on. [BA] Is the SSRC copied in only for a receive ID match or any match without SSRC? (E.g. PT-only). 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? 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. 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. — Reply to this email directly or view it on GitHub<https://github.com/openpeer/ortc/issues/48#issuecomment-40322228>.
Received on Monday, 14 April 2014 00:57:00 UTC