- From: Peter Thatcher <pthatcher@google.com>
- Date: Wed, 30 Apr 2014 09:12:57 -0700
- To: Emil Ivov <emcho@jitsi.org>
- Cc: Robin Raymond <robin@hookflash.com>, "public-ortc@w3.org" <public-ortc@w3.org>
- Message-ID: <CAJrXDUGd=Ea0AuaLv3CvpN1ADQS4tZbs=N335tq2XsadHOHj0w@mail.gmail.com>
On Wed, Apr 30, 2014 at 8:46 AM, Emil Ivov <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>> 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.
Most web developers won't touch this property. I think it will work fine
in most use cases without reading it or writing it.
>
> more inline:
>>
>>
>> On 30.04.14, 04:23, Robin Raymond wrote:
>>
>>
>> You are correct. This is an oversight.
>>
>> The receiver must emit a "sender SSRC". Typically in a
>> bi-directional
>> scenario the client would pick the SSRC of the sending stream to
>> indicate receiver reports. But when you have 1-way streams or
>> uncouple
>> the sender from the receiver, it's not clear what value should
>> be picked.
>>
>> My answers would be:
>> 1) If not specified, system can pick one. It can chose an SSRC
>> "source"
>> to put into the receiver report from a sender within the same "RTC
>> context" if one exists, or just chose a new SSRC at random.
>> Either would
>> work satisfactory IMHO.
>>
>>
>> Agreed. SSRC=1 will become messy when multiple receivers are sending
>> RTCP (e.g. in an SFU conference) so a random generated SSRC would be
>> much better.
>>
>>
>> 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? So I could
send with an SSRC you're sending with and pretend to be you? That doesn't
sound like a very good SFU.
>
>
> 2) Not that I'm aware. I don't see what the browser engine would
>> do with
>> that information. Worse, if the send stream was broadcasted to
>> multiple
>> receivers, there would be multiple parties reporting about the
>> same SSRC
>> each with having their own source SSRC. Perhaps an app level
>> would want
>> to know the stats reported by each receiver source but I don't
>> see the
>> value in telling the sender engine what SSRC value(s) to expect
>> from the
>> receiver's source in advance.
>>
>>
>> In the current WebRTC implementation Chrome seems to be ignoring
>> RTCP FIRs from SSRCs that it doesn't know. I don't exactly know what
>> the reason is (pacing i-frames?) but it is one reason why you'd need
>> it signalled.
>>
>>
>> Yeah, that's kind of why I asked if we need to signal this at all. In
>> principle, I don't see a reason it needs to be.
>>
>
> Neither do I (and this goes for both RTP and RTCP).
>
>
> Put in practice, in
>> Chrome right now, if you don't signal the SSRC you're going to send RTCP
>> with, Chrome will drop the RTCP on the receive side (sometimes; it's
>> complicated). But it's possible that wasn't intentional; It may have
>> just been an oversight.
>>
>
> Maybe, although given Chrome's overall fetish with SSRCs and how it
> insists on knowing everything in advance it kind of fits into a pattern.
>
> By the way, it also special cases SSRC=1, such
>> that it never drops the RTCP when SSRC=1.
>>
>
> Good to know.
>
> Emil
>
>
>> Cheers,
>> Emil
>>
>>
>>
>> -Robin
>>
>> Peter Thatcher <mailto:pthatcher@google.com
>> <mailto:pthatcher@google.com>>
>>
>> April 29, 2014 at 3:20 PM
>> One thing that I think we have overlooked is how the JS can
>> configure
>> the SSRC to go in RTCP packets.
>>
>> For example, if I do this:
>>
>> var rtpReceiver = new RTCRtpReceiver(...);
>> rtpReceiver.receive(...);
>>
>> At this point, the rtpRecever knows how to receiver RTP.
>> But to send
>> back RTCP, the RtcpReceiver needs to know which SSRC to send
>> the RTCP
>> with. In the typical 1:1 WebRTC 1.0, SDP-based scenario,
>> this is done
>> with the SSRC used to send RTP. In ORTC lingo, that means
>> it assumes
>> the existence of an RtpSender with a configured sendSSRC.
>> Obviously
>> we can't make this assumption, and it seems to me that RTCP
>> is kind of
>> broken for the one-way-media case.
>>
>> So what can we do? One simple solution is to let the JS
>> sepecify the
>> SSRC that the RtpReceiver should use to send RTCP. That
>> way, 1.0
>> shims can use this to configure RTCP correctly, and pure
>> ORTC clients
>> can make sure that an SSRC is properly configured.
>>
>>
>> So I propose we add this:
>>
>> dictionary RTCRtpParameters {
>> // all the other stuff (codecs, layers, extensions)
>> unsigned int rtcpSsrc;
>> };
>>
>> When used in RtcpReceiver.receive(), it will control what
>> SSRC to use
>> when sending RTCP.
>>
>> The questions I have that I'm not quite clear on are:
>>
>> 1. What should the browser do if it's not set? Not send
>> RTCP? Just
>> pick an SSRC? I'm inclined to just say use ssrc=1, but
>> that sounds
>> too easy, so there must be some old RFC that says we're not
>> allowed to
>> do that.
>>
>> 2. Does this value need to be set in the RtpSender to let it
>> know the
>> SSRC to expect? In other words, does this value need to be
>> signalled?
>> I don't see why it really needs to be, but demux is
>> complex, and so
>> there might be some reason it would be needed for demux.
>>
>>
>> --
>> https://jitsi.org
>>
>>
>>
> --
> https://jitsi.org
>
Received on Wednesday, 30 April 2014 16:14:06 UTC