- From: Bernard Aboba <Bernard.Aboba@microsoft.com>
- Date: Thu, 12 Feb 2015 02:05:47 +0000
- To: Jiannan Zheng <jzheng@exchange.microsoft.com>
- CC: "public-ortc@w3.org" <public-ortc@w3.org>
Comments below.
________________________________________
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.
[BA] Is the issue that the SR is potentially received both before media and before signaling could arrive with the "SSRC of sender"?
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.
[BA] The RTCP common header includes the "SSRC of sender" field. If there is no SSRC_1 field in an RR, then yes, there is no way to route this to the RtpSender that needs to receive the RR.
In the case of the Sender Report (SR), BYE or SDES the "SSRC of Sender" represents the SSRC of the RtpSender, which is set by a call to sender.send(). When an RtpReceiver has no SSRC matching rules configured (e.g. the "SSRC of sender" is not included in the RtpEncodingParameters), and no RTP packets have yet been received from that sender, causing an entry to be added to the ssrc_table[sender.SSRC], when those RTCP packets arrive they cannot be routed.
For the Sender Report, BYE, SDES, etc. there is an additional alternative, other than queueing the RTCP packets and waiting for an ssrc_table entry to be created on the appropriate RtpReceiver.
This is for the application to explicitly choose the SSRC that the RtpSender should use to send by filing the SSRC attribute in within RtpEncodingParameters. The chosen SSRC can then be communicated in signaling so that the RtpReceiver on the other end can configure that SSRC so as to cause an ssrc_table entry to exist prior to receipt of any RTP packets.
Of course, this will only work if the signaling arrives prior to receipt of the RTCP packets.
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.
[BA] Both RTP and RTCP packets are processed by the appropriate transport object (e.g. RTCDtlsTransport), prior to being delivered to Sender/Receiver objects. We do not talk about this in the specification, but my assumption has been that SR/RR/SDES/BYE/Feedback messages need to be decrypted prior to routing since the needed fields are only available in cleartext as you point out.
-----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 Thursday, 12 February 2015 02:06:15 UTC