Re: Issue 180: RTCP packet routing

Yes, which is why I don't see why we need the value for the sender for demuxing reports from the receiver.

- Robin



> On Feb 15, 2015, at 3:26 PM, Bernard Aboba <Bernard.Aboba@microsoft.com> wrote:
> 
> Assuming that receiver.receive(parameters) included SSRC settings in parameters.encodings[i].ssrc, would that not ensure that an RR or Feedback Message could always have an "SSRC of media" (FB Message) or SSRC_N field (RR), even before any packets were received?
> 
> 
> On Feb 15, 2015, at 7:19 AM, Robin Raymond <robin@hookflash.com> wrote:
> 
>> 
>> Yes, receiver reports can go to multiple senders (due to their compound nature).
>> 
>> I’m not sure where we would ever have unknown receiver reports / receiver feedbacks that would not also include a sender’s RTP SSRC because that SSRC was not yet known. I can’t see a scenario where that would happen. However, I am okay with the sender’s rtcp.ssrc having the meaning of the receiver’s rtcp.ssrc for the sake of definition but I don’t know where it would used anywhere in practice.
>> 
>> -Robin
>> 
>> 
>>> On February 14, 2015 at 10:24:51 PM, Jiannan Zheng (jzheng@exchange.microsoft.com) wrote:
>>> 
>>>  
>>> 
>>> Robin, Yes, the callee's RtpReceiver should have encoding[0].ssrc=100 and rtcp.ssrc=200, matching the caller side RtpSender's setting. In my previous example I was listing the caller side RtpReceiver's settings. Our examples are the same.
>>> 
>>>  
>>> 
>>> The ambiguity is in the interpretation of this sentence in spec if we apply rtcp parameter on RtpSender:
>>> 
>>> "ssrc of type unsigned long
>>> The SSRC to be used in the Receiver Report "SSRC of packet sender" field as defined in [RFC3550] Section 6.4.2. If unset, ssrc is chosen by the browser, and the chosen value is not reflected in RTCRtcpParameters.ssrc. If the browser chooses the ssrc it may change it in event of a collision, as described in [RFC3550]."
>>> 
>>> It can be read either as the "SSRC of packet sender" of the RTCP flowing from RtpSender to RtpReceiver, or on the reverse direction. Since the ssrc in the encoding parameter on sender side already defines the "SSRC of packet sender", it is better to have the rtcp.ssrc as the "SSRC of packet sender" of this RtpSender is about to receive, matching the examples we gave.
>>> 
>>>  
>>> 
>>> It should be expected that on RTCP packet needs to be routed to multiple sender/receiver objects because RTCP packets are usually combo packets. The SR should be processed by RtpReciever and RR goes to RtpSender.  We don't have trouble handling known RTCP messages. The potential routing problem is we may not be able to route application defined RTCP extensions, but we may not worry about it now.
>>> 
>>>  
>>> 
>>>  
>>> 
>>>  
>>> From: Robin Raymond <robin@hookflash.com>
>>> Sent: Saturday, February 14, 2015 6:32 AM
>>> To: public-ortc@w3.org; Jiannan Zheng; Bernard Aboba
>>> Subject: RE: Issue 180: RTCP packet routing
>>>  
>>> 
>>> Something looks wrong in your example:
>>> 
>>>> RtpReceiver; 
>>>> bRTCRtpParameters.encodings[0].ssrc = 200; 
>>>> bRTCRtpParameters.rtcp.ssrc = 100; 
>>>> 
>>>> RtpSender: 
>>>> aRTCRtpParameters.encodings[0].ssrc = 100; 
>>>> aRTCRtpParameters.rtcp.ssrc = 200; 
>>> 
>>> You have the sending using an RTP SSRC of 100 but the receiver is expecting RTP with an SSRC of 200.
>>> 
>>> Is this what you meant to write:
>>> 
>>> RtpReceiver; 
>>> bRTCRtpParameters.encodings[0].ssrc = 100; 
>>> bRTCRtpParameters.rtcp.ssrc = 200; 
>>> 
>>> RtpSender: 
>>> aRTCRtpParameters.encodings[0].ssrc = 100; 
>>> aRTCRtpParameters.rtcp.ssrc = 200; 
>>> 
>>> 
>>> Are you suggesting that the RTCRtpParameters.rtcp.ssrc effectively being the “receiver’s unique SSRC”? If so, keep in mind in the case of simulcasting multiple senders could have the same RTCRtpParameters.rtcp.ssrc all pointing to the same receiver object (albeit only one sender will be active at a time).
>>> 
>>> I’m not sure there is ambiguity though since you signalled your SSRCs in the encoding parameters so any sender SSRCs in any receiver reports or feedbacks will be well understood which sender it belongs.
>>> 
>>> -Robin
>>> 
>>>> On February 13, 2015 at 8:04:35 PM, Jiannan Zheng (jzheng@exchange.microsoft.com) wrote:
>>>> 
>>>> Can we also clarify the meaning of the SSRC in
>>>> "
>>>> WebIDLdictionary RTCRtcpParameters {
>>>> unsigned long ssrc;
>>>> DOMString cname;
>>>> boolean reducedSize = false;
>>>> boolean mux = true;
>>>> };
>>>> " ?
>>>> 
>>>> Spec says:
>>>> "ssrc of type unsigned long
>>>> The SSRC to be used in the Receiver Report "SSRC of packet sender" field as defined in [RFC3550] Section 6.4.2. If unset, ssrc is chosen by the browser, and the chosen value is not reflected in RTCRtcpParameters.ssrc. If the browser chooses the ssrc it may change it in event of a collision, as described in [RFC3550]."
>>>> 
>>>> There is no ambiguity for RtpReceiver that this SSRC is the value to put into the "SSRC of packet sender" field in receiver report.
>>>> On RtpSender side, we should expect this is the SSRC in the incoming receiver report's "SSRC of packet sender" field since RtpSender doesn't send receiver reports.
>>>> 
>>>> For example,
>>>> Assume we are the caller, we send an offer with "a=ssrc : 100", and get an answer with "a=ssrc : 200". Caller creates one RtpSender and one RtpReceiver.
>>>> 
>>>> RtpReceiver;
>>>> bRTCRtpParameters.encodings[0].ssrc = 200;
>>>> bRTCRtpParameters.rtcp.ssrc = 100;
>>>> 
>>>> RtpSender:
>>>> aRTCRtpParameters.encodings[0].ssrc = 100;
>>>> aRTCRtpParameters.rtcp.ssrc = 200;
>>>> 
>>>> This should be sufficient to determine all RTCP routing if a "a=ssrc" line is negotiated.
>>>> 
>>>> Thanks,
>>>> 
>>>> -Jiannan
>>>> 
>>>> -----Original Message-----
>>>> From: Bernard Aboba [mailto:Bernard.Aboba@microsoft.com]
>>>> Sent: Friday, February 13, 2015 4:24 PM
>>>> To: public-ortc@w3.org
>>>> Subject: RE: Issue 180: RTCP packet routing
>>>> 
>>>> An update to the proposed Section 8.3.2 text:
>>>> 
>>>> 8.3.2 RTCP matching rules
>>>> 
>>>> The RTP matching rules also influence how RTCP Sender Reports (SRs), SDES and BYE packets are delivered to RTCRtpReceiver objects. When these packets are received, sender.ssrc is set to the "SSRC of sender" field defined in [RFC3550] Section 6.4.1 (Sender Report), the "SSRC/CSRC" field defined in [RFC3550] Section 6.5 (SDES) or the "SSRC/CSRC" field defined in [RFC3550] Section 6.6 (BYE). If rtcp_receiver == ssrc_table[sender.ssrc] is set, the RTCP SR, SDES or BYE packet is delivered to rtcp_receiver. If it is unset, the RTCP packet is queued for 30 seconds, and ssrc_table[sender.ssrc] is checked again, in case reception of an RTP packet resulted in an addition to ssrc_table[]. If when the timeout expires ssrc_table[sender.ssrc] is still unset, the RTCP SR, SDES or BYE packet is discarded.
>>>> 
>>>> When RTCP RR or Feedback Messages are received, the "SSRC of source" field defined in [RFC3550] Section 6.4.2 (Receiver Report) or the "SSRC of media source" field defined in [RFC4585] Section 6.1 (Feedback Messages), is checked against the values of parameters.codecs[j].parameters.ssrc (for j = 0 to the number of codecs) provided in calls to sender.send(parameters). If a match is found, the RTCP packet is delivered to sender.