Re: I think we need a way to configure the RTCP SSRC.

So, we're all happy with:

1.  You can set the RTCP SSRC.
2.  The default, if you don't set it, is to choose a random one.  Don't go
choosing 1 as the default because that would make some poor old SFU setup
explode when the JS developer doesn't know he needs to set it.  If you want
ssrc=1, it's easy to set :).

I think I'm OK with that.  We can always change our mind later if we run
into a problem :).



On Wed, Apr 30, 2014 at 9:14 AM, Emil Ivov <emcho@jitsi.org> wrote:

>
>
> On 30.04.14, 18:04, Peter Thatcher wrote:
>
>>
>>
>>
>> On Wed, Apr 30, 2014 at 8:46 AM, Emil Ivov <emcho@jitsi.org
>> <mailto:emcho@jitsi.org>> wrote:
>>
>>
>>
>>     On 30.04.14, 17:22, Peter Thatcher wrote:
>>
>>
>>
>>
>>         On Tue, Apr 29, 2014 at 10:42 PM, Emil Ivov <emcho@jitsi.org
>>         <mailto:emcho@jitsi.org>
>>         <mailto:emcho@jitsi.org <mailto:emcho@jitsi.org>>> wrote:
>>
>>              Hey folks,
>>
>>              I personally don't see the need to set the SSRC (just as
>>         there is no
>>              need to do it for bidirectional RTP) but I do agree there
>>         has to be
>>              a way to obtain it from the API. We actually also need that
>>         in the
>>              case when we have disparate numbers of multiple senders and
>>              receivers and it can no longer be assymed what SSRC is used
>>         where.
>>
>>
>>         I'm pretty sure we need it at least for the 1.0 shim.
>>
>>
>>     Could you please explain why?
>>
>>
>>         And I'm sure
>>         there are legacy interop scenarios the JS will need to specify
>>         the RTCP
>>         SSRC, and letting the browser choose won't be enough.  In
>>         particular,
>>         I'm thinking of how it will want to correlate the RTCP SSRC of an
>>         RtpReceiver with the RTP SSRC of an RtpSender.  I think letting
>>         the JS
>>         specify the RTCP SSRC in the RtpReceiver is the easiest way.
>>
>>
>>     Easiest for who? From a web dev's perspective it would probably be
>>     much more intuitive to say "this sender and receiver belong to the
>>     same context" than "you need to extract the value of the 'four funky
>>     letters' in the receiver and set it on the 'four funky letter' in
>>     the sender".
>>
>>
>> ​I really don't want to start requiring the JS to correlate RtpSenders
>> and RtpReceivers into "contexts" just to work around the oddities of
>> RTCP.
>>
>
> Generating invalid RT(C)P unless the developer intervenes doesn't really
> sound like an oddity workaround.
>
>
>  "contexts" are just going to turn into complex rat holes.  For
>> the normal/simple cases of using the API, I think just not setting it
>> and using the default (either ssrc=1 or random) will work fine.
>>
>
> If both are fine, then let's just forget about the "1" value and resolve
> the whole thing. As long as you do that, then the majority of the cases
> would neither need to set nor get the SSRC.
>
> Emil
>
> --
> https://jitsi.org
>