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

On 30.04.14, 18:18, Peter Thatcher wrote:
> 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.

and 3. you need to be able to get it.

> 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.

I think the oldest SFU I am aware of is the one you are using so if this 
one survives it, then we are fine and there's no risk of explosions :)

Again, that's not a problem for the SFU. It's a problem for the endpoints.

And I am also fine with 1, 2 and 3 above.

Emil

> 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
> <mailto: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>
>         <mailto: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>>
>                  <mailto: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
>
>

-- 
https://jitsi.org

Received on Wednesday, 30 April 2014 16:26:08 UTC