Re: Issue 180: RTCP packet routing

SDES / BYE should not be sender specific, if the remote peer is a mixer, SDES/BYE could carry any participant's information in the mixer. I am not sure if we could mandate if ORTC has an "a=sendonly" to a mixer, we drop SDES and BYEs, at least the ssrc collision detection based on SDES will not work. We also need to send an BYE for any SSRC RtpReceiver uses for its rtcp packets.



________________________________
From: Robin Raymond <robin@hookflash.com>
Sent: Tuesday, February 17, 2015 10:53 AM
To: Jiannan Zheng; Bernard Aboba
Cc: public-ortc@w3.org
Subject: RE: Issue 180: RTCP packet routing


I cannot see a single packet that a receiver would generate which does not include the SSRC of the sender’s encoding parameter.

If there is a single packet generated by the receiver that would not also contain the SSRC of sender’s encoding parameter then we must have the sender.rtcp.ssrc requiring meaning. But I cannot see a single example of this happening. BYE and SDES are sent by senders and not by a receiver (to my understanding) and receiver feedback mechanisms always would require the sender’s SSRC from the sender's encoding parameters. Do you have an example of a packet a receiver would generate an RTCP which does not include the SSRC from the sender’s encoding parameters ?

-Robin


On February 15, 2015 at 4:02:11 PM, Jiannan Zheng (jzheng@exchange.microsoft.com<mailto:jzheng@exchange.microsoft.com>) wrote:

It is not sufficient to route all rtcp packets. Not all rtcp packets carries the destination  rtp session's ssrc. Reciever report record and feedback messages are the ones with this ssrc, while others like sdes and bye and application specific extension packets don't.

Also receiver report record and feedback message are in the encrypted portion of rtcp payload, it mandates we have to decrypt at the demuxer.

Sent from my Windows Phone
________________________________
From: Robin Raymond<mailto:robin@hookflash.com>
Sent: ‎2/‎15/‎2015 12:36 PM
To: Bernard Aboba<mailto:Bernard.Aboba@microsoft.com>
Cc: public-ortc@w3.org<mailto:public-ortc@w3.org>
Subject: 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<mailto: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<mailto: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<mailto: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<mailto:robin@hookflash.com>>
Sent: Saturday, February 14, 2015 6:32 AM
To: public-ortc@w3.org<mailto: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<mailto: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<mailto: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.