Subject: [straw] My comments on WGLC for draft-ietf-straw-b2bua-rtcp-03

From: Magnus Westerlund <[email-masked]>
Date: Mon, 23 Feb 2015 17:17:31 +0100

WG,

Section 3.2:

APP:  [RFC3550]
      If the B2BUA has changed any SSRC in any direction, it MUST update
      the SSRC in the BYE message.

Copy and paste error "BYE" message.

Section 3.2:

   Feedback messages:  [RFC4585]
      All Feedback messages have a common packet format, which includes
      the SSRC of the packet sender and the one of the media source the
      feedack is related to.  Just as described for the previous
      messages, these SSRC identifiers MUST be updated if the B2BUA has
      changed any SSRC in any direction.  It MUST NOT, though, change a
      media source SSRC that was originally set to zero.  Besides,
      considering that many feedback messages also include additional
      data as part of their specific Feedback Control Information (FCI),
      a media-aware B2BUA MUST take care of them accordingly, if it can
      parse and regenerate them, according to the following guidelines.

I think to avoid erroneous behaviour one must demand that any B2BUA that
rewrites SSRCs MUST be capable of parsing the FCI for any feedback
message it allows being used in the RTP session. Otherwise you will end
up with FCI with wrong SSRC information. Thus I would suggest that you
remove the caveat from that last sentence to force the implementation to
follow them.

 "It MUST NOT, though, change a
      media source SSRC that was originally set to zero."

This is likely the right decision, however it has the error case when an
endpoint uses SSRC 0. Otherwise one must be Feedback message type aware
and know if this is an unused 0 or an actually used 0 that then needs
rewriting.

Section 3.2:
At the same time, the
   ability for a media-aware B2BUA to inspect/modify RTCP packets may
   also mean such a B2BUA may choose to drop RTCP packets it can't
   parse: in that case, a media-aware B2BUA SHOULD also advertize its
   RTCP level of support in the SDP in a coherent way, in order to
   prevent, for instance, a UAC to make use of NACK messages that would
   never reach the intended recipients.

I wished this was stronger. I think dropping packets only as really last
possibility, and then only for issues that are of temporary nature. I
would also like to make clear that when one are talking about dropping
RTCP packets, then one only drops the offending RTCP packet, not the
whole compound RTCP packet.

Section 3.2:

What about the ECN Feedback messages and RTCP XR report specified in RFC
6679? There are sequence numbers and SSRCs that needs to rewritten
consistently here.

Section 3.3:

I think there should be a reference here to Section 3.2.2 of
draft-ietf-avtcore-rtp-topologies-update.

Somewhere:

I am missing a discussion of the impact of both reduced size RTCP (RFC
5506) as well as RTP/RTCP multiplexing (RFC 5761).

The reduced size is mostly a question if the endpoint as well as the
B2BUA can support it, thus enable it coherently across the both sides.

When it comes to RTP/RTCP multiplexing, it can be used by the
Media-aware relay as well as the media terminator on each leg
independently given that it ensure that there are no conflicting RTP
payload type numbers on both sides alternatively is capable of rewriting
RTP payload type numbers to ensure no conflict in the domain where the
RTP/RTCP multiplexing is applied.

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: [email-masked]
----------------------------------------------------------------------

---

From: Lorenzo Miniero <[email-masked]>
Date: Tue, 24 Feb 2015 09:09:20 +0100

Hello Magnus,

thanks a lot for your detailed review!

I've added a couple of inline comments.

On Mon, 23 Feb 2015 17:17:31 +0100
Magnus Westerlund <[email-masked]> wrote:

> WG,
> 
> 
> Section 3.2:
> 
> APP:  [RFC3550]
>       If the B2BUA has changed any SSRC in any direction, it MUST
> update the SSRC in the BYE message.
> 

Ack.

>       All Feedback messages have a common packet format, which
> includes the SSRC of the packet sender and the one of the media
> source the feedack is related to.  Just as described for the previous
>       messages, these SSRC identifiers MUST be updated if the B2BUA
> has changed any SSRC in any direction.  It MUST NOT, though, change a
>       data as part of their specific Feedback Control Information
> (FCI), a media-aware B2BUA MUST take care of them accordingly, if it
> can parse and regenerate them, according to the following guidelines.
> 
> I think to avoid erroneous behaviour one must demand that any B2BUA
> that rewrites SSRCs MUST be capable of parsing the FCI for any
> feedback message it allows being used in the RTP session. Otherwise
> you will end up with FCI with wrong SSRC information. Thus I would
> suggest that you remove the caveat from that last sentence to force
> the implementation to follow them.
> 

That's a good point, I'll remove that part.

> This is likely the right decision, however it has the error case when
> an endpoint uses SSRC 0. Otherwise one must be Feedback message type
> aware and know if this is an unused 0 or an actually used 0 that then
> needs rewriting.
> 

I hadn't thought about that: I'll add a clarification in the points
where we talk about an SSRC=0, specifying that it must not be changed
unless the B2BUA is aware of an actually used SSRC=0 in the managed
sessions.

>    prevent, for instance, a UAC to make use of NACK messages that
> would never reach the intended recipients.
> 
> I wished this was stronger. I think dropping packets only as really
> last possibility, and then only for issues that are of temporary
> nature. I would also like to make clear that when one are talking
> about dropping RTCP packets, then one only drops the offending RTCP
> packet, not the whole compound RTCP packet.
> 

By stronger you mean turn the SHOULD to a MUST? Will clarify about just
stripping the unknown RTCP from the compound packet.

> Section 3.2:
> 
> What about the ECN Feedback messages and RTCP XR report specified in
> RFC 6679? There are sequence numbers and SSRCs that needs to rewritten
> consistently here.
> 

Thanks for this, I wasn't sure indeed whether we were covering all the
RTCP messages. XR are already there in general, ECN and related XR are
not, so I'll add them.

> draft-ietf-avtcore-rtp-topologies-update.

Thanks, I'll add this.

> B2BUA can support it, thus enable it coherently across the both sides.

Good point, will do. I wonder if it makes sense to also suggest
"gatewaying" reduced to/from non-reduced size RTP, in case one side
supports it and the other doesn't. If one is trying to use it it's
probably for a good reason, and if the B2BUA can take care of that if
might help.

> payload type numbers on both sides alternatively is capable of
> rewriting RTP payload type numbers to ensure no conflict in the
> domain where the RTP/RTCP multiplexing is applied.
> 

Same as above, I'm wondering if, for the Media-aware and Media
terminator cases, we can also state that a B2BUA can keep an rtcp-mux
session on one side and a non-muxed on the other side, in case that
peer doesn't support it, if it makes sure that it will
multiplex/demultiplex properly on both sides and that it will take care
of the negotiation accordingly. This might make sense to limit the
amount of network resources used at least on one side of the
communication, for just a little additional complexity to just relaying.

Thanks again for this!
Lorenzo 

> _______________________________________________
> straw mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/straw

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 24 Feb 2015 10:08:04 +0100

Hi,

I have responded where necessary and removed where there appear to be no
need for further comments.

> stripping the unknown RTCP from the compound packet.

Yes, I would prefer a MUST here.

A media-aware B2BUA that performs RTP level translation must understand
the RTCP related to the media streams it modifies. Unknown RTCP in that
case becomes a issue. That message can be directly related to the media
stream it produces and thus needs translation. Thus if it is going drop
to prevent inconsistencies, it really should signal its capabilities.

Unfortunately the B2BUA is going to be a third party that needs support
for any extension one like to use. But, that is unavoidable when it
performs modifications.

A Media-aware relay that only performs inspection but not modification
actually works much closer to a media relay and could thus potentially
accept unknown RTCP packets. However, that is likely against its role of
policy enforcer.

> probably for a good reason, and if the B2BUA can take care of that if

So for a Media Terminator, this is a no brainer, use it on each leg
independently. Doing the translation in media-aware is possible but far
from trivial. The reason is that a reduced size RTCP implementation can
issue a higher rate of RTCP feedback messages due to the gains from the
reduced size. If these messages needs timely response from the other
peer the translator will have issues to get them there, unless the RTCP
bandwidth is different on each side. In which case you end up with other
issues, which makes me not recommend that. So I think RTP/RTCP mux is
fine to gateway. Reduced Size should have a warning attached.

> communication, for just a little additional complexity to just relaying.

Yes, I think a Media-Aware B2BUA that has the PT translation
capabilities doing RTP/RTCP mux gatewaying is a quite simple operation.
The only important issue here is to ensure that there is room to do the
PT translation, but that should not be an issue so far. But, it does put
requirement on a signalling part to verify that.

Cheers

Magnus Westerlund

---

From: Lorenzo Miniero <[email-masked]>
Date: Tue, 24 Feb 2015 11:31:37 +0100

Hi Magnus,

thanks again for this very quick new round of feedback! I'll make sure
I'll address all your points in the new version of the document.

Lorenzo

On Tue, 24 Feb 2015 10:08:04 +0100
Magnus Westerlund <[email-masked]> wrote:

> Hi,
> 
> I have responded where necessary and removed where there appear to be
> no need for further comments.
> 
> >>    ability for a media-aware B2BUA to inspect/modify RTCP packets
> >> may also mean such a B2BUA may choose to drop RTCP packets it can't
> >>    parse: in that case, a media-aware B2BUA SHOULD also advertize
> >> its RTCP level of support in the SDP in a coherent way, in order to
> > By stronger you mean turn the SHOULD to a MUST? Will clarify about
> > just stripping the unknown RTCP from the compound packet.
> > 
> 
> A media-aware B2BUA that performs RTP level translation must
> understand the RTCP related to the media streams it modifies. Unknown
> RTCP in that case becomes a issue. That message can be directly
> related to the media stream it produces and thus needs translation.
> Thus if it is going drop to prevent inconsistencies, it really should
> signal its capabilities.
> 
> Unfortunately the B2BUA is going to be a third party that needs
> support for any extension one like to use. But, that is unavoidable
> when it performs modifications.
> 
> accept unknown RTCP packets. However, that is likely against its role
> of policy enforcer.
> 
> > 
> >> Section 3.2:
> >>
> >> What about the ECN Feedback messages and RTCP XR report specified
> >> in RFC 6679? There are sequence numbers and SSRCs that needs to
> >> rewritten consistently here.
> >>
> > 
> > 
> > Thanks for this, I wasn't sure indeed whether we were covering all
> > the RTCP messages. XR are already there in general, ECN and related
> > XR are not, so I'll add them.
> > 
> > 
> >>
> >> Section 3.3:
> >>
> >> I am missing a discussion of the impact of both reduced size RTCP
> >> (RFC 5506) as well as RTP/RTCP multiplexing (RFC 5761).
> >>
> >> The reduced size is mostly a question if the endpoint as well as
> >> the B2BUA can support it, thus enable it coherently across the
> >> both sides.
> >>
> > 
> > 
> > probably for a good reason, and if the B2BUA can take care of that
> > if might help.
> 
> independently. Doing the translation in media-aware is possible but
> far from trivial. The reason is that a reduced size RTCP
> implementation can issue a higher rate of RTCP feedback messages due
> to the gains from the reduced size. If these messages needs timely
> response from the other peer the translator will have issues to get
> them there, unless the RTCP bandwidth is different on each side. In
> which case you end up with other issues, which makes me not recommend
> that. So I think RTP/RTCP mux is fine to gateway. Reduced Size should
> have a warning attached.
> 
> > 
> > 
> >> independently given that it ensure that there are no conflicting
> >> RTP payload type numbers on both sides alternatively is capable of
> > terminator cases, we can also state that a B2BUA can keep an
> > rtcp-mux session on one side and a non-muxed on the other side, in
> > case that peer doesn't support it, if it makes sure that it will
> > multiplex/demultiplex properly on both sides and that it will take
> > care of the negotiation accordingly. This might make sense to limit
> > the amount of network resources used at least on one side of the
> capabilities doing RTP/RTCP mux gatewaying is a quite simple
> operation. The only important issue here is to ensure that there is
> room to do the PT translation, but that should not be an issue so
> far. But, it does put requirement on a signalling part to verify that.
> 
> Cheers
> 
> Magnus Westerlund
>