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.