- From: Jiannan Zheng <jzheng@exchange.microsoft.com>
- Date: Mon, 23 Feb 2015 23:23:30 +0000
- To: Robin Raymond <robin@hookflash.com>, Bernard Aboba <Bernard.Aboba@microsoft.com>
- CC: "public-ortc@w3.org" <public-ortc@w3.org>
- Message-ID: <2c547fb91db74f95be43e8ae3f2b4f59@DFM-CO1MBX15-08.exchange.corp.microsoft.com>
I think It comes from the fact that we hide the RTP session concept from upper layer. We need a hint which RTP session the RTCP packets belongs to and this information needs to come from sender/receiver’s RTCP parameter. It is a problem for bundling multiple RTP sessions to the same transport.
So come back to the original problem, is the below example right understanding of the protocol:
Alice calls Bob
If we implement webrtc SDP on top, the offer/answer will have:
Alice’s offer:
…
m=audio …
a=ssrc : 1 …
…
m=video …
a=ssrc : 2
Bob’s answer:
…
m=audio …
a=ssrc: 101
…
m=video …
a=ssrc: 102 …
…
We configure ORTC this way:
Alice:
Audio: Sender encoding parameter SSRC = 1
rtcp parameter SSRC = 101
Receiver encoding parameter SSRC = 101
rtcp parameter SSRC = 1
Video: Sender encoding parameter SSRC = 2
rtcp parameter SSRC = 102
Receiver encoding parameter SSRC =102
rtcp parameter SSRC = 2
Bob:
Audio: Sender encoding parameter SSRC = 101
rtcp parameter SSRC = 1
Receiver encoding parameter SSRC = 1
rtcp parameter SSRC = 101
Video: Sender encoding parameter SSRC = 102
rtcp parameter SSRC = 2
Receiver encoding parameter SSRC = 2
rtcp parameter SSRC = 102
Internally, we route rtcp combo packets to both sender and receiver with the matching encoding parameter (for receiver) and rtcp parameter (for sender) and let the sender/receiver to consume the fields they are interested in.
Another clarification is contributor SDES is needed by the sender. The sender needs to compare its encoding parameter SSRC to the incoming contributing source SSRC in SDES to detect SSRC collision.
Thanks,
-Jiannan
From: Robin Raymond [mailto:robin@hookflash.com]
Sent: Wednesday, February 18, 2015 7:36 PM
To: Jiannan Zheng; Bernard Aboba
Cc: public-ortc@w3.org
Subject: RE: Issue 180: RTCP packet routing
Right. A compound RTCP packet could contain forwarded BYEs from contributing sources where there isn’t any receiver with a listening routing SSRC entry in place to handle that packet.
E.g:
Alice [sender SSRC = 5] ===> MIXER [sender SSRC 10, CSRC 5 + 6] ===> Charles [receiver latch = SSRC 10]
Bob [sender SSRC = 6] ===>
In this scenario Charles is receiving the mixer's SSRC 10 with contributions from 5 + 6. Thus SDES packets about 5 + 6 as well as BYEs could happen regarding the contributing sources without necessarily being related back to SSRC 10. There’s no entry in the latching table for SSRC 5 or 6 because they are contributing sources so the report would be dropped. Although SDES and BYE packets are always compounded within other SR or RR so likely the relationship to the senders SSRC might be present (but it isn’t guaranteed to be the correct sender relationship, is it?).
Technically, at the moment those packets don’t have meaning because we don’t expose a “getContributingSources()” method. So dropping them isn’t the end of the world for these particular cases but that isn’t a good solution longer term and may cause issue with regards to the stats API.
-Robin
On February 18, 2015 at 2:48:54 PM, Bernard Aboba (bernard.aboba@microsoft.com<mailto:bernard.aboba@microsoft.com>) wrote:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Received on Monday, 23 February 2015 23:24:11 UTC