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

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.

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.

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

Cheers,
Emil


>
> -Robin
>
>> Peter Thatcher <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

Received on Wednesday, 30 April 2014 05:42:50 UTC