Subject: [rtcweb] JSEP Appendix B: Routing of RTCP XR packets

From: Bernard Aboba <[email-masked]>
Date: Fri, 20 Jan 2017 16:21:05 -0800

It has been pointed out to me that the text in JSEP Appendix B does not
include text relating to the routing of RTCP XR packets, described in RFC
3611.

Since RTCP XR packets include report blocks with different formats coming
up with appropriate text is challenging.

For example, the following text covers Loss RLE Report Blocks (Section
4.1), Duplicate RLE Report Blocks (Section 4.2), Packet Receipt Times
Report Blocks (Section 4.3), Statistics Summary Report Blocks (Section 4.6)
and VoIP Metric Report Blocks (Section 4.7):

   If the packet is of type XR with a BT of 1 (Loss RLE Report Block), 2
(Duplicate RLE Report
   Block),  3 (Packet Receipt Times Report Block), 6 (Statistics Summary
Report Block),
  7 (VoIP Metric Report Block), for each report block in the packet whose
"SSRC of source"
   is found in the outgoing SSRC table, deliver a copy of the RTCP packet
to the
   "m=" line associated with that SSRC.

However, RFC 3611 also includes the Receiver Reference Report Block
(Section 4.4) whose format looks like this:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     BT=4      |   reserved    |       block length = 2        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              NTP timestamp, most significant word             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             NTP timestamp, least significant word             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Should this be forwarded to the RtpSender whose outgoing SSRC table that
matches the
"SSRC" field in the RTCP XR packet?

There is also is the DLRR Report Block (Section 4.5) whose format looks
like this:

  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     BT=5      |   reserved    |         block length          |
 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
 |                 SSRC_1 (SSRC of first receiver)               | sub-
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
 |                         last RR (LRR)                         |   1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                   delay since last RR (DLRR)                  |
 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
 |                 SSRC_2 (SSRC of second receiver)              | sub-
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
 :                               ...                             :   2
 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

For this one, I'm assuming that the SSRC of Nth receiver field is matched
against the
ssrc_table to determine the appropriate RtpReceivers to receive a copy of
the RTCP packet.

There are of course other RTCP XR RFCs.  I have not reviewed those yet.
But before doing that, I'd like to get some feedback on whether the general
approach outlined above is sane (or whether parsing individual RTCP XR
report blocks is a bad idea to begin with).

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 23 Jan 2017 13:57:14 +0100

Hi Bernard,

I think one important aspect here is that it doesn't make sense to put 
all possible RTCP formats into BUNDLES text on demultiplexing RTCP. I 
think what is needed in BUNDLE is the general principle and some examples.

To my understanding we have a couple of different principles in RTCP 
when it comes to SSRCs.

1. Statements. The sourcing endpoint simply states that this applies for 
the following SSSRC. This is true for SDES, RTCP SR (sender report 
part). And this applies to RTP streams being received by the endpoint.

2. Reporting: Report Blocks in SR or RR which states. I am X and here is 
my report on Y. Where each block has an SSRC. This is also true for the 
Feedback format. Which is either single target, i.e. FB formats SSRCS 
are both valid, from who and who the target for the feedback is. Multi 
FCI where the Target SSRC is at the FCI level is a variant more similar 
to the report block. So what is of interest is first of all any feedback 
or reporting on the RTP streams the endpoint sends. Thus, the outgoing 
SSRCs for a media description is what is of primary interest. Then there 
could exist secondary interest for feedback other provides, i.e. that 
the target SSRC is for other endpoints RTP Streams. This should normally 
only occur in RTP sessions for some specific topologies, like multicast 
based or interconnects to such where the RTP middlebox doesn't filter 
away such messages.

3. Unspecified receiver. The APP packet is one of those that only have a 
source, and thus who is the consumer on the endpoint is not clear 
without looking into the information on a deeper level.

I would also note that implementation variations and how the API between 
the higher layers and the RTP/RTCP protocol implementation will highly 
affect how one interacts. I have done implementation which has both poll 
and rule based subscription to information updates or feedback events.

There is also the question of how one on the RTCP side best expresses 
the mapping between the RTPTranscivers and the BUNDLE media description.

Cheers

Magnus

Den 2017-01-21 kl. 01:21, skrev Bernard Aboba:
> include text relating to the routing of RTCP XR packets, described in
> RFC 3611.
>
> Since RTCP XR packets include report blocks with different formats
> coming up with appropriate text is challenging.
>
> Report Blocks (Section 4.3), Statistics Summary Report Blocks (Section
> 4.6) and VoIP Metric Report Blocks (Section 4.7):
>
>   7 (VoIP Metric Report Block), for each report block in the packet
> whose "SSRC of source"
>    is found in the outgoing SSRC table, deliver a copy of the RTCP
> packet to the
> For this one, I'm assuming that the SSRC of Nth receiver field is
> matched against the
> ssrc_table to determine the appropriate RtpReceivers to receive a copy
> of the RTCP packet.
>
> But before doing that, I'd like to get some feedback on whether the
> general approach outlined above is sane (or whether parsing individual
> RTCP XR report blocks is a bad idea to begin with).
>
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

-- 

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 24 Jan 2017 16:49:22 -0800

Magnus said:

"we have a couple of different principles in RTCP when it comes to SSRCs..."

Thanks. I tried to encapsulate this in the following PR:

https://github.com/rtcweb-wg/jsep/pull/530

On Mon, Jan 23, 2017 at 4:57 AM, Magnus Westerlund <
[email-masked]> wrote:

> Hi Bernard,
>
> I think one important aspect here is that it doesn't make sense to put all
> possible RTCP formats into BUNDLES text on demultiplexing RTCP. I think
> what is needed in BUNDLE is the general principle and some examples.
>
> To my understanding we have a couple of different principles in RTCP when
> it comes to SSRCs.
>
> the following SSSRC. This is true for SDES, RTCP SR (sender report part).
> And this applies to RTP streams being received by the endpoint.
>
> Feedback format. Which is either single target, i.e. FB formats SSRCS are
> both valid, from who and who the target for the feedback is. Multi FCI
> where the Target SSRC is at the FCI level is a variant more similar to the
> report block. So what is of interest is first of all any feedback or
> reporting on the RTP streams the endpoint sends. Thus, the outgoing SSRCs
> for a media description is what is of primary interest. Then there could
> exist secondary interest for feedback other provides, i.e. that the target
> SSRC is for other endpoints RTP Streams. This should normally only occur in
> RTP sessions for some specific topologies, like multicast based or
> interconnects to such where the RTP middlebox doesn't filter away such
> messages.
>
> source, and thus who is the consumer on the endpoint is not clear without
> looking into the information on a deeper level.
>
>
> There is also the question of how one on the RTCP side best expresses the
> mapping between the RTPTranscivers and the BUNDLE media description.
>
> Cheers
>
> Magnus
>
>
>

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 25 Jan 2017 11:06:36 +0100

> https://github.com/rtcweb-wg/jsep/pull/530

I looked at the PR.

So on the very basic level this would clearly be sufficient. However, it 
might have significant duplication of the processing for the higher 
layer due to the this sentence "sender SSRC for the packet is found in 
the incoming SSRC table, deliver a copy of the packet to the "m=" line 
associated with that SSRC."

The above will result in that each RTCP XR will be first forward in its 
entirety to the "m=" line that receives the SSRC that the peer endpoint 
uses for reporting. Then for all RTCP XR report blocks that contains 
SSRC of source or corresponding and has a SSRC value corresponding to a 
by this endpoint sent RTP stream, the individual report block will be 
delivered to that RTP streams "m=" line. There exist a possibility that 
one receives report block reporting on RTP streams sent by other 
endpoints, i.e. RTP streams that are part of the incoming RTP stream to 
m= line mapping table. These third party report may be useful to confirm 
that also others see issues with delivery etc of an incoming stream. 
However, but any differences in report may be due to the difference in 
path between the RTP stream source and the endpoint sending this report, 
and the path the local endpoint sees. Also for SFM and RTP mixers, these 
third party reports normally makes no sense as the RTP streams received 
by the different participants from the same media source are not the 
same due to per endpoint specific forwarding of RTP stream decisions. 
Thus they need to be suppressed by the RTP middlebox.

To me it appears reasonable that third party reports are processed in 
the same context that considers the local statistics for the 
corresponding incoming RTP stream when they occur, which should be rarely.

Thus, the need for the above quoted rule is dependent on if there exist 
RTCP XR report blocks that is not tightly couple to an RTP stream and 
thus can't be processed in the m= line context that originates or 
receives the RTP stream? In RFC 3611 the ones that has this aspect is 
the Receiver Reference Time Report Block (Section 4.4). However, at the 
same time I see very little meaning of forwarding this to the higher 
layers. This report block combined with DLRR (Section 4.5) is a 
mechanism that is either turned on in the RTP session or not. It is the 
RTP stack that must do the processing of any incoming RRT to enable the 
sending of the DLRR for that SSRC. And if the local endpoint originates 
RTT, then the interesting outcome is the resulting RTT measurement 
between this local endpoint and the peer.

I have not looked at all the report blocks in the registry:

http://www.iana.org/assignments/rtcp-xr-block-types/rtcp-xr-block-types.xhtml#rtcp-xr-block-types-1

BT's XQN (RFC5093) lacks SSRC field, but that is likely a bug as it 
talks about sequence numbers, and thus need to reference an RTP Stream.

There might be some additional, some random sampling indicated that most 
are after all reporting on a RTP stream in some sense. The example that 
doesn't it is not obvious that it is appropriate to route it to the 
higher layer of the m= line.

Thus I wonder if this description will result in the duplication on the 
common case, and still not be the appropriate response for the few odd 
RTCP XR report blocks.

I don't have an text change proposal at this point.

Cheers

Magnus

>
> On Mon, Jan 23, 2017 at 4:57 AM, Magnus Westerlund
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>     Hi Bernard,
>
>     I think one important aspect here is that it doesn't make sense to
>     put all possible RTCP formats into BUNDLES text on demultiplexing
>     RTCP. I think what is needed in BUNDLE is the general principle and
>     some examples.
>
>     1. Statements. The sourcing endpoint simply states that this applies
>     for the following SSSRC. This is true for SDES, RTCP SR (sender
>     report part). And this applies to RTP streams being received by the
>     endpoint.
>
>     2. Reporting: Report Blocks in SR or RR which states. I am X and
>     here is my report on Y. Where each block has an SSRC. This is also
>     true for the Feedback format. Which is either single target, i.e. FB
>     formats SSRCS are both valid, from who and who the target for the
>     feedback is. Multi FCI where the Target SSRC is at the FCI level is
>     a variant more similar to the report block. So what is of interest
>     is first of all any feedback or reporting on the RTP streams the
>     endpoint sends. Thus, the outgoing SSRCs for a media description is
>     what is of primary interest. Then there could exist secondary
>     interest for feedback other provides, i.e. that the target SSRC is
>     for other endpoints RTP Streams. This should normally only occur in
>     interconnects to such where the RTP middlebox doesn't filter away
>     such messages.
>
>     3. Unspecified receiver. The APP packet is one of those that only
>     have a source, and thus who is the consumer on the endpoint is not
>     clear without looking into the information on a deeper level.
>
>
>     I would also note that implementation variations and how the API
>     between the higher layers and the RTP/RTCP protocol implementation
>     will highly affect how one interacts. I have done implementation
>     which has both poll and rule based subscription to information
>     updates or feedback events.
>
>     There is also the question of how one on the RTCP side best
>     expresses the mapping between the RTPTranscivers and the BUNDLE
>     media description.
>
>     Cheers
>
>     Magnus
>
>
>
>         block
>          |                         last RR (LRR)
>          |   1
>         block
>          :                               ...
>          :   2
>         [email-masked] <mailto:[email-masked]>
>         <https://www.ietf.org/mailman/listinfo/rtcweb>
>
>
>
>     --
>
>     Magnus Westerlund
>
>     <tel:%2B46%2010%207148287>
>     <tel:%2B46%2073%200949079>
>     <mailto:[email-masked]>

-- 

Magnus Westerlund