- From: Emil Ivov <emcho@jitsi.org>
- Date: Mon, 14 Apr 2014 18:36:36 +0200
- To: Martin Thomson <martin.thomson@gmail.com>, Bernard Aboba <bernard.aboba@gmail.com>
- CC: openpeer/ortc <ortc@noreply.github.com>, public-ortc@w3.org
Hey folks, On 14.04.14, 18:07, Martin Thomson wrote: > On 13 April 2014 16:45, Bernard Aboba <bernard.aboba@gmail.com > <mailto:bernard.aboba@gmail.com>> wrote: > > 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 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 Do you mean RTPReceiver? > (for a given ICE/DTLS transport) and that b) if you find an RTPListener > that matches on SSRC, stop looking. Same question. Also, kind of a side/clarifying question: If I understand correctly that filtering logic is necessary for two cases: 1. The app wants to create RTPReceivers before it starts getting media (for whatever reason) so these rules help make sure that when media actually starts arriving it would flow to the right receivers. Pre-defining such rules is not mandatory however and apps can very well create receivers on the fly as they get unhandled events. 2. RTPReceiver-s have already been created (either "pro" or "re" actively) and these rules try to guarantee that media would continue flowing to the right receiver with as little intervention from the application as possible. Are the above statements correct? Emil -- https://jitsi.org
Received on Monday, 14 April 2014 16:37:08 UTC