Hi,

I have done this review as part of the TSVART's task to review documents 
with potential transport impact.

Below you will find a number of comments on issues that I found. I think 
there are several significant issues below: 2, 3, 4, and 6. The rest 
would be good to address. I am sorry that this review is late in the 
process.


1. Section 3.1: I am surprised that there are no discussion for a Media 
Relay regarding a=rtcp-mux and its impact on where RTP/RTCP packets will 
flow and if a=rtcp attribute is at all relevant. I think there would be 
clearer if one in the context of a=rtcp also discusses a=rtcp-mux and 
how that impacts the actual transport layer flows that will result.

2. Section 3.1:
    While [RFC7022] can prevent this from
    happening, there may be implementations that don't make use of it.
    As such, a B2BUA MAY rewrite CNAME items if any potential collision
    is detected, even in the Media Relay case.  If a B2BUA does indeed
    decide to rewrite CNAME items, though, then it MUST generate new
    CNAMEs following [RFC7022].

While the Media Relay is generally safe in regards to the use of RTP 
header extensions, this text above actually requires translation of the 
RTP header extension identified as 
"urn:ietf:params:rtp-hdrext:sdes:cname" [RFC7941]. Then also that needs 
to be translated.

3. Section 3.2:

Also this section will need a discussion of RTP header extensions. So 
one set of header extensions that may be translated are any SDES items. 
So CNAME, MID, RID should be considered. Especially MID and RID as they 
are directly related to SDP they are likely to need translation.

However, also the set of transport related information, like the ones 
that has been proposed for use with RMCAT but have not yet been 
approved. As they can have packet specific information, if one starts 
removing packets, then one may need to consider these also.

4. Section 3.2: SR Entry:

I like to note that if an Media Relay act in the role of a SFU, then it 
needs to track in the outgoing SR, the relevant number of packets sent, 
total amount of bytes sent to that particular receiver, rather than what 
was received. Note, that as this is SR specific, it does not apply to RR.

I note that SFU also requires sequence number rewriting, which affects 
other RTCP packet type that reference sequence numbers, like NACK.

5. Section 3.2:

       REMB:  [I-D.alvestrand-rmcat-remb]
          A media-aware B2BUA MUST properly rewrite the additional SSRC
          identifier(s) in REMB packets, if it changed the related RTP
          SSRC of the media sender.

I assume that you have had some thought about the need to include this 
individual proposal. I do note that it is not clear if this ever will be 
published, especially considering the RMCAT WG's work on a different 
feedback format.

6. Section 3.2:

In fact, while a Media Relay B2BUA may choose to
    use it on the side that supports it and not on the side that doesn't,
    there are other aspects to take into account before doing so.

The above sentence indicates that it is okay to use reduced sized RTCP 
on one leg but not the other. I would strongly discourage that due to 
the issues that are raised. If one is going to "forward" a reduced size 
RTCP packet, that needs to be upgraded to a compliant RTCP compound 
packet. Which makes it bigger, and then RTCP bandwidth becomes an issue. 
I think the above sentence should be clearer that there are real issues 
here. And I think the conclusion should be to use it only if both legs 
support it.

Cheers

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: magnus.westerlund@ericsson.com
----------------------------------------------------------------------