Subject: [MMUSIC] Comments on draft-ietf-mmusic-sdp-bundle-negotiation-16 - a=rtcp-mux and a=rtcp issue

From: Magnus Westerlund <[email-masked]>
Date: Thu, 26 Feb 2015 15:02:30 +0100

Hi,

I have finally managed to review BUNDLE's state with a fresh mind after
my parental leave.  I think the document is in pretty good shape but I
have one significant issue and a number of smaller comments where
clarifications might be needed. This email does only contain the
significant issue, I will send a separate email about the other issues.

This concerns the text around RTP/RTCP Multiplexing, something I noticed
also Paul commented during the WG last call.

To be more specific my issue is around the changes for a=rtcp
defined in

10.3.2.2:

    In addition, the offerer MUST associate an SDP
   'rtcp' attribute [RFC3605] with each bundled RTP-based "m=" line
   (including any bundle-only "m=" line), with an attribute value that
   is identical to the port value assigned to the "m=" line itself, in
   the offer.

10.3.2.3:

   If the answerer rejects usage of RTP/RTCP multiplexing within the
   BUNDLE group, it MUST NOT associate an SDP 'rtcp-mux' or SDP 'rtcp'
   attribute with any bundled "m=" line in the answer.  The answerer
   MUST, based on the port number of the selected offerer BUNDLE
   address, use the next higher (odd) destination port number [RFC3550]
   for sending RTCP packets associated with each bundled RTP-based "m="
   line towards the offerer.

   NOTE: When the answerer rejects usage of RTP/RTCP multiplexing, the
   reason for mandating usage of the next higher (odd) destination port
   number for RTCP is to allign the procedures for the corresponding
   offer.

So, I find this application of a=rtcp highly inconsistent, contradicting
other specifications and likely to lead to several issues.

First, can one really combine ICE with the usage of having the same
a=rtcp value as in the m= port? This leads to two candidates with the
same address and foundation for different components. The only thing
indicating the different components are the different priority values.

Like in this Offerer:

m=audio 10000 RTP/AVP 0
a=rtcp-mux
a=rtcp:10000
a=candidate:1 1 UDP 2130706431 10.0.1.1 10000 typ host
a=candidate:1 2 UDP 2130706430 10.0.1.1 10000 typ host

If the peer accepts a=rtcp-mux, there are no additional issues as then
a=rtcp value is ignored and nothing is returned. But, lets actually see
what happens when the answerer rejects a=rtcp-mux in different cases.
This is based on the above offer. Note that the below discussion assumes
that the answerer supports the a=rtcp attribute. If it didn't support
a=rtcp, the answerer would assume RTCP to be sent to m= line's port+1.

Case A - Answer Supports BUNDLE:

For someone that understands BUNDLE and follows the above
specification text, the RTCP flow shall now be used according to an
offer equivalent to this:

m=audio 10000 RTP/AVP 0
a=rtcp:10001
a=candidate:1 1 UDP 2130706431 10.0.1.1 10000 typ host
a=candidate:1 2 UDP 2130706430 10.0.1.1 10000 typ host

I note about the above the following:

- that this rules requires that the offer do ensure to allocate port
10001 and listen on it. Thus, still requiring an additional port be
allocated on the offer side.

- That we actual have a discrepancy between a signalled value (a=rtcp)
and what is actually used. This will cause issues in gateways and
firewalls.

- That I don't have an ICE candidate existing for my second component
with a port matching what is in the a=rtcp attribute. So I don't
understand how my ICE processing is going to complete.

Case B - Answerer doesn't support BUNDLE:

If the answerer does not understand BUNDLE and rejects
a=rtcp-mux it can't know about the special rules and thus it will send
its RTCP according to the following SDP offer:

m=audio 10000 RTP/AVP 0
a=rtcp:10000
a=candidate:1 1 UDP 2130706431 10.0.1.1 10000 typ host
a=candidate:1 2 UDP 2130706430 10.0.1.1 10000 typ host

Thus the answerer will send RTCP to port 10000. This may work as long as
the answerer uses different source address+port for RTP and RTCP so that
the Offerer sees different 5-tuples. With the caveat that I am uncertain
if ICE can handle this situation correctly as it will have difficulties
to separate which component a connectivity check is related to.

However, I do note that the design consideration of BUNDLE thought this
construct to be brittle for RTP due to the quite unspecified source port
usage in offer/answer contexts when ICE isn't used.

I think this situation MUST be addressed.

The first step is to stop overriding the specified a=rtcp behaviour. If
a=rtcp is used, then its value needs to be used if a=rtcp-mux is
rejected and point to where one is willing to receive RTCP. Let is be
the next higher odd port, or some other port. To my understanding the
support for a=rtcp is wide spread. I also like to remind you that RFC
5761 requires a=rtcp to be included if ICE is used (Section 5.1.3).

The next step is to figure out if one at all can have a=rtcp point to
the same port as the one used for RTP. The design considerations so far
indicates that the answer to this is NO! To my understanding mostly due
to the unspecified usage of source ports. Also ICE appears to have
issues with this configuration.

The implications of the above is that in all initial offers have to have
unique address+port combinations for RTP and RTCP respectively with
matching sets of ICE candidates if ICE is used. Thus, we end up with a
high resource consumption prior to BUNDLE being established.

We previously had have quite some discussions about mandating a=rtcp-mux
when using BUNDLE to reduce the initial port consumption and need to
gather for it. Unfortunately I don't see how we get around the resource
consumption if one at all is going to be able to have working downgrade
from BUNDLE to non-BUNDLE. If one uses ICE and a=rtcp-mux RFC 5761
mandates inclusion of a=rtcp. If one doesn't use ICE one could have or
not have, but independently if one is to handle rejection of a=rtcp-mux,
then the offerer must have assigned port. The a=rtcp presence is just a
question which port must be allocated, any vs next higher number.

My conclusion, if we desire any support for the answer to reject
a=rtcp-mux then the initial offer must include a port for RTCP, either
explicit (a=rtcp) or implicit (+1 rule). If one ties this lack of
backwards compatibility for a=rtcp-mux to BUNDLE, then backwards
compatibility for BUNDLE will be affected as that fails in cases when
the answerer does not support a=rtcp-mux. Only if we are willing to
throw that backwards compatibility out of the door can we do something
else. I assume that we are not. Thus, I think we will have to live with
the port consumption, at least a=bundle-only mitigates it.

My proposal for changes to the text causing these issue are the following:

In 10.3.2.2:

1. Offerer: MAY include a=rtcp attribute as required or desired by other
specification to indicate the port where RTCP will be received if
a=rtcp-mux is rejected. In case a=rtcp is excluded the normal +1 rule
applies.

2. Offerer: the a=rtcp attribute shall have a port value different than
the m-line

In 10.3.2.3:

3. Answerer: if the answerer rejects rtcp-mux, it is allowed in include
an a=rtcp attribute to indicate where it will receive RTCP, or fall back
on the +1 rule.

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: Roman Shpount <[email-masked]>
Date: Thu, 26 Feb 2015 10:42:12 -0500

> an a=rtcp attribute to indicate where it will receive RTCP, or fall back
+1. I think this would make rtpc attribute usage much more logical.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 26 Feb 2015 20:10:27 +0000

Hi,

I’ve had a chat with Magnus regarding this, and I support his suggestion.

It will require some editorial changes, but before I start working on that I want to verify that people are ok with the suggestion.

Regards,

Christer

From: mmusic [mailto:[email-masked]] On Behalf Of Roman Shpount
Sent: 26 February 2015 17:42
To: Magnus Westerlund
Cc: mmusic (E-mail)
Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-sdp-bundle-negotiation-16 - a=rtcp-mux and a=rtcp issue

On Thu, Feb 26, 2015 at 9:02 AM, Magnus Westerlund <[email-masked]<mailto:[email-masked]>> wrote:
My proposal for changes to the text causing these issue are the following:

In 10.3.2.2<http://10.3.2.2>:

In 10.3.2.3<http://10.3.2.3>:

---

From: "Stach, Thomas" <[email-masked]>
Date: Fri, 27 Feb 2015 07:26:20 +0000

Magnus’ suggestions is fine.

Regards
Thomas

From: mmusic [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Donnerstag, 26. Februar 2015 21:10
To: Roman Shpount; Magnus Westerlund
Cc: mmusic (E-mail)
Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-sdp-bundle-negotiation-16 - a=rtcp-mux and a=rtcp issue

Hi,

Regards,

Christer