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

[RR] See inline

> Emil Ivov <mailto:emcho@jitsi.org>
> April 30, 2014 at 11:46 AM
>
>
> 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:
>>
>> [...]
>>
>> I'm pretty sure we need it at least for the 1.0 shim.
>
> Could you please explain why?
[RR] Hmmm... if it's part of the SDP somewhere (implicitly or 
explicitly) then any ORTC 1.1 -> WebRTC 1.0 shim or WebRTC 1.0 -> ORTC 
1.1 shim would require the value for compatibility. I would like to know 
if it's actually expressed somewhere in SDP though or presumed because 
of some magic m-line matching rules. I'm not certain for this point. 
Does someone else know?
>
>> 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".

[RR] Presumably it would be defaulted by the engine so easiest would 
refer to a quick knob someone who needs that detail can tweak the value 
(I presume)?
>
>>     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.

[RR] Yes, that was my point in the other email. If the RRs were all 
forwarded by the same intermediate box to someone they would lose source 
IP context.
>
>>         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).

[RR] Nor myself.
>
>> [...]