- From: Bernard Aboba <Bernard.Aboba@microsoft.com>
- Date: Fri, 13 Feb 2015 20:17:16 +0000
- To: Jiannan Zheng <jzheng@exchange.microsoft.com>
- CC: "public-ortc@w3.org" <public-ortc@w3.org>
Below is a proposed resolution. Does this work for you?
Add a sub-heading "Section 8.3.1 RTP matching rules" prior to the current text in Section 8.3 on Matching rules.
Add Section 8.3.2:
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 an RTCP SR, SDES or BYE packet is received, packet.ssrc is set the "SSRC of sender" field defined in [RFC3550] Section 6.4.1 (Sender Report), or "SSRC/CSRC" field defined in [RFC3550] Section 6.5 (SDES) or [RFC3550] Section 6.6 (BYE). If receiver == ssrc_table[packet.ssrc] is set, the RTCP SR, SDES or BYE packet is delivered to receiver. If it is unset, the RTCP packet is queued for 30 seconds, and ssrc_table[packet.ssrc] is checked again, in case reception of an RTP packet resulted in an addition to ssrc_table[]. If it 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 provided in calls to sender.send(parameters) for j=0 to the number of codecs. If a match is found, the RTCP packet is delivered to sender.
Also, the following updated text is proposed in Section 9.5.1 Dictionary RTCRtcpParameters Members:
ssrc of type unsigned long
The SSRC to be used in the "SSRC of packet sender" field defined in [RFC3550] Section 6.4.2 (Receiver Report), as well as in [RFC4585] Section 6.1 (Feedback Messages). 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].
________________________________________
From: Jiannan Zheng
Sent: Wednesday, February 11, 2015 3:01 PM
To: Bernard Aboba; public-ortc@w3.org
Subject: RE: Issue 180: RTCP packet routing
Allow me to rephrase the problem in a slightly different way.
We've put quite some words to specify the matching rules for RTP packets on the receiver side, however we didn't put much details for RTCP packets on the reverse direction. RTCP packets only carries receiver's send SSRC in common header. If we bundle A/V or multiple video RTP sessions together, an incoming RTCP packet with unseen SSRC cannot be routed.
We either need to let RtpSender know this SSRC or we need to parse further into the RTCP payload to route.
The suggest method means we solely rely on RR or feedback message to latch RTCP and the protocol doesn't support any other way. Even if signaling knows how to de-mux the RTCP (for example, by the a=ssrc from the remote offer/answer), there isn't a way to let ORTC layer know.
This may not work, two issues:
1, If RtpReceiver doesn't receive anything due to RtpSender not sending or loss, the RTCP packet will have an empty RR, which has no RR blocks and with RC=0. We will not have the SSRC_1 field in RR record to route.
The danger is all the other control information, including CNAME, SR for RTT calculation, any application defined extensions, even BYE will get lost before the first RTP packet reaches the RtpReceiver.
2, This will require the de-multiplexer decrypting the RTCP packet in order to route RR is encrypted and this mandates the de-multiplexer must know the key and be able to use the correct key.
It is not a problem for DTLS for now because we have one key per IceTransport and disallow rekey. If ever we allow multiple keys (as in SDES it is allowed that A/V using different a=crypto lines), we have a chicken & egg problem that we need to locate the correct RTP session(sender) to know the key. It may be solved by trying to use all keys but indeed sounds like a hack.
The solution is to let the RtpSender know the a=ssrc value of the matching sender on the other end. If this value is not set, we rely on the best-effort matching method below. To configure this SSRC on RtpSender, we will need an optional parameter in encoding parameter, something like peerSSRC.
-----Original Message-----
From: Bernard Aboba [mailto:Bernard.Aboba@microsoft.com]
Sent: Wednesday, February 11, 2015 1:09 PM
To: public-ortc@w3.org
Subject: RE: Issue 180: RTCP packet routing
Here are some thoughts on how routing of RTCP packets works.
Let us assume that the DtlsTransport receives an RTCP Sender Report (SR) that (like other RTCP packets) contains the SSRC of Sender field. On the receiver, if there is an entry for ssrc_table[sender.ssrc], then the report can be delivered to that receiver. If there is no table entry, then the RTCP SR can be queued for some time period (e.g. 10 seconds) by which time an ssrc_table entry may have been created and the SR can therefore be delivered. Otherwise, the SR can be dropped. A similar issue can occur with an RTCP BYE, which contains the SSRC/CSRC of the source that is becoming inactive.
It does not appear that this issue can occur with Receiver Reports which include the SSRC of the source they are reporting on, and so these can always be delivered to the appropriate RtpSender object based on the SSRC configured by the application or chosen by the browser. Similarly, RFC 4585 Section 6.1 defines the RTCP packet format for feedback messages, which contains the SSRC of the packet sender as well as the SSRC of the media source, allowing it to be delivered to the appropriate RtpSender object.
Here is the format of an SRTP packet (RFC 3711 Section 3.4):
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| RC | PT=SR or RR | length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| SSRC of sender | |
+>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
| ~ sender info ~ |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| ~ report block 1 ~ |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| ~ report block 2 ~ |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| ~ ... ~ |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |V=2|P| SC | PT=SDES=202 | length | |
| +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
| | SSRC/CSRC_1 | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| ~ SDES items ~ |
| +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
| ~ ... ~ |
+>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
| |E| SRTCP index | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
| ~ SRTCP MKI (OPTIONAL) ~ |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| : authentication tag : |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
+-- Encrypted Portion Authenticated Portion -----+
Figure 2. An example of the format of a Secure RTCP packet,
consisting of an underlying RTCP compound packet with a Sender Report
and SDES packet.
The SR or RR is always first since RFC 3550 Section 6.1 says:
SR or RR: The first RTCP packet in the compound packet MUST
always be a report packet to facilitate header validation as
described in Appendix A.2. This is true even if no data has been
sent or received, in which case an empty RR MUST be sent, and even
if the only other RTCP packet in the compound packet is a BYE.
More detail on the format of the SR from RFC 3550 Section 6.4.1:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
and here are the details of the RR:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
And here is the RFC 4585 Section 6.1 feedback format:
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| FMT | PT | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Feedback Control Information (FCI) :
: :
Figure 3: Common Packet Format for Feedback Messages
________________________________________
From: Bernard Aboba
Sent: Wednesday, February 11, 2015 1:00 PM
To: public-ortc@w3.org
Subject: Issue 180: RTCP packet routing
>From Jiannan Zheng:
Section 8.3 describes matching rules for routing of RTP packets to RtpReceiver objects. There is no equivalent text for RTCP packets. Since RTCP packets do not include the Packet Type of the RTP packets they relate to, nor do they include a muxId, the only way they can be routed is via the SSRC. If there is no ssrc_table entry corresponding to the SSRC, the RTCP message may not be routable.
Received on Friday, 13 February 2015 20:18:04 UTC