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

On 30.04.14, 18:12, 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".
>
>
> Easiest to fit into the API surface and keeping the complexity down.  ​

To me that's an API that doesn't require explicit action. Requiring a 
setSSRC() or any other explicit action in the common case.

> ​Most web developers won't touch this property.  I think it will work
> fine in most use cases without reading it or writing it.

Yes. Unless you go on and set it to 1.

>         ​I'm not sure why SSRC=1 would be a problem in an SFU situation.  If
>         multiple receivers are all sending with SSRC=1, why would the
>         SFU get
>         confused?  They are all coming in from different connections anyway.
>
>
>     It's not about the SFU being confused. Some SFUs (because there's
>     more than one in the market ;) ) would just forward all RTP and RTCP
>     to everyone else so it will be up to the endpoints to distinguish them.
>
>
> ​An SFU that forwards all RTP and RTCP to all participants?

Yes. An RTP translator.

> So I could
> send with an SSRC you're sending with and pretend to be you?

What? Of course not :). That would cause an SSRC conflict that will be 
handled as per 3550. Although I don't see why anyone would do that (well 
... unless it's because they all use "1").

> That doesn't sound like a very good SFU.

Why? Because it doesn't behave come from your favourite vendor? :)

Emil


-- 
https://jitsi.org

Received on Wednesday, 30 April 2014 16:20:02 UTC