- From: Bernard Aboba <Bernard.Aboba@microsoft.com>
- Date: Wed, 18 Feb 2015 19:48:51 +0000
- To: Robin Raymond <robin@hookflash.com>, Jiannan Zheng <jzheng@exchange.microsoft.com>
- CC: "public-ortc@w3.org" <public-ortc@w3.org>
- Message-ID: <BLUPR03MB149DCCDBF5EA60665F7133AEC2C0@BLUPR03MB149.namprd03.prod.outlook.com>
One other point relating to RTCP packet routing.
Unlike RTP, where an RTP packet is only delivered to a single receiver, RTCP compound packets can be delivered to multiple objects. Delivering RTCP information to the right objects is important to ensuring that the Stats API (which in ORTC is object-based) functions correctly.
As an example, an RTCP compound packet MUST include an SR/RR and SDES (CNAME) but also may include other packet types (e.g. BYE, FB, etc.).
Even with an RTCP payload type, there may be information for multiple objects. For example, the RTCP SDES and BYE packets can have a Source Count (SC) greater than one so as to include information relating to multiple senders, identified by their SSRCs/CSRCs. Since CSRCs may be included in these packets, there may be no RtpSender object to which the information relates.
6.5<http://tools.ietf.org/html/rfc3550#section-6.5> SDES: Source Description RTCP Packet
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P| SC | PT=SDES=202 | length |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
chunk | SSRC/CSRC_1 |
1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SDES items |
| ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
chunk | SSRC/CSRC_2 |
2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SDES items |
| ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
6.6<http://tools.ietf.org/html/rfc3550#section-6.6> BYE: Goodbye RTCP Packet
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| SC | PT=BYE=203 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC/CSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
(opt) | length | reason for leaving ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
As another example, the Receiver Report can provide information relating to multiple sources, so that information from a single RTCP payload may need to be delivered to multiple RtpSender objects.
6.4.2<http://tools.ietf.org/html/rfc3550#section-6.4.2> RR: Receiver Report RTCP Packet
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P| RC | PT=RR=201 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report | SSRC_1 (SSRC of first source) |
block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | fraction lost | cumulative number of packets lost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extended highest sequence number received |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| interarrival jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| last SR (LSR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delay since last SR (DLSR) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report | SSRC_2 (SSRC of second source) |
block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 : ... :
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| profile-specific extensions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Similarly, the Sender Report (SR) can also contain reports relating to multiple sources:
6.4.1<http://tools.ietf.org/html/rfc3550#section-6.4.1> SR: Sender Report RTCP Packet
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P| RC | PT=SR=200 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of sender |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
sender | NTP timestamp, most significant word |
info +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP timestamp, least significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sender's packet count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sender's octet count |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report | SSRC_1 (SSRC of first source) |
block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | fraction lost | cumulative number of packets lost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extended highest sequence number received |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| interarrival jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| last SR (LSR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delay since last SR (DLSR) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report | SSRC_2 (SSRC of second source) |
block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 : ... :
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| profile-specific extensions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
From: Robin Raymond [mailto:robin@hookflash.com]
Sent: Wednesday, February 18, 2015 5:47 AM
To: Jiannan Zheng; Bernard Aboba
Cc: public-ortc@w3.org
Subject: Re: Issue 180: RTCP packet routing
I think there is something getting confused (or misunderstanding). So let me try to clarify my understanding to see if it matches yours...
In ORTC, all communication is effectively unidirectional, i.e. a sender always flows RTP traffic to the receiver. The bi-directional nature is only achieved by way of both sides sending from a sender to the other side’s receiver.
A [sender SSRC=5] ==> B [receiver]
A [receiver] <== B [sender SSRC=6]
They are unrelated for the most part. However, receiver reports from B (and A)’s receiver require a SSRC field be filled into the receiver reports (i.e. RtpReceiver.rtcp.ssrc). B’s receiver can choose any SSRC is wants for the receiver reports, e.g.:
A [sender SSRC=5] ==> B [receiver RTCP RR SSRC=99 *any random SSRC can be used*]
A [receiver] <== B [sender SSRC=6]
B receiver is not required to use the SSRC of B’s sender BUT convention of SDP O/A indicates that they match:
A [sender SSRC=5] ==> B [receiver RTCP RR SSRC=6 *not really required to be the sender's 6*]
A [receiver] <== B [sender SSRC=6]
So B using SSRC 6 in the RtpReceiver.rtcp.ssrc which happens to match B’s sender is convention of SDP O/A and not a true requirement.
So when you say SDES / BYE are not sender specific, it’s my understanding they are sender specific. SDES being the description of a source, requires a source. Only the sender has a source. BYE is the same (indicating the closure of a source). The only thing that generates a source is a sender (even in mixers). Yes, there can be BYEs about contributing sources, but they are contributing sources of a sender to a mixer and then a mixer BYEing the contributing sources out of the mixed RTP stream from its sender in kind.
There is no reason for a receiver to say to the sender “BYE” because it doesn’t emit a source, same with SDES. A receiver might provide feedback reports from its own perspective (i.e. RtpReceiver.rtcp.ssrc) but as far as I can tell it doesn’t help route back to any specific sender on the remote side since in all of those reports related to feedback contain the SSRC of the sender anyway).
In the case above, it’s always A’s sender or B’s sender which emit SDES and BYE, and never either of the receivers. I re-read the RFC related to RTCP (been a while) and I can see it’s not exactly clear cut and dry that BYE/SDES are only emitted exclusively from a sender so perhaps I’m misinterpreting the RFC but my initial read leads me to believe that’s the case.
FYI - I’m not against RtpSender.rtcp.ssrc as pointing to the same value as the Receiver’s RtpReceiver.rtcp.ssrc but to write it into the ORTC specification, I would need to include recommendations on how it would affect the routing of packets which I still am not seeing… at least not yet...
-Robin
On February 17, 2015 at 4:38:57 PM, Jiannan Zheng (jzheng@exchange.microsoft.com<mailto:jzheng@exchange.microsoft.com>) wrote:
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<mailto:robin@hookflash.com>>
Sent: Tuesday, February 17, 2015 10:53 AM
To: Jiannan Zheng; Bernard Aboba
Cc: public-ortc@w3.org<mailto: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.
Received on Wednesday, 18 February 2015 19:49:26 UTC