Subject: [MMUSIC] BUNDLE Q14: Mandate usage of RTP/RTCP mux within a BUNDLE group? [was: On the sparsity of RTP Payload types]

From: Christer Holmberg <[email-masked]>
Date: Sun, 16 Mar 2014 14:16:34 +0000

Hi,

Do other people have opinions on this?

Just to clarify: the support of RTP/RTCP mux is already mandated in BUNDLE, and question is not whether the included the a=rtcpmux attribute or not when RTP/RTCP mux is used - it shall be included. The question is whether we should mandate usage of RTP/RTCP mux within a BUNDLE group.

Regards,

Christer

________________________________________
From: mmusic [[email-masked]] on behalf of Justin Uberti [[email-masked]]
Sent: Friday, 14 March 2014 7:33 PM
To: Magnus Westerlund
Cc: mmusic (E-mail)
Subject: Re: [MMUSIC] On the sparsity of RTP Payload types

Agree this is a real limitation. In addition to the codecs listed above, note that CN and telephone-event are often needed, and potentially in multiple clockrates.

(which is why I think we shouldn't burn PTs on demultiplexing)

On Fri, Mar 14, 2014 at 2:56 AM, Magnus Westerlund <[email-masked]<mailto:[email-masked]>> wrote:
MMUSIC,

There's have been a number of people not believing in that RTP payload
types may become a limiting factor when trying to express configurations
in SDP or other signaling. Thus, I would like to share my concerns over
how the combination of various mechanism effects the number of actual
payload type configurations needed to negotiated.

First a set of mechanism that do affect Payload Type usage.

1. RTCP MUX (RFC 5761)
If one uses RTCP RTP multiplexing, then a number of the RTP payload
types are reserved for identifying the RTCP packets, rather than RTP
payload formats. The default reservation is to reserve PT numbers 64-95.
This limits the 128 PTs to 96 available ones.

2. BUNDLE (draft-ietf-mmusic-sdp-bundle-negotiation)
When using BUNDLE, all listed m= sections within a bundle group are in
the same RTP session, thus all the PTs share a single common PT
numbering space. Bundle has done what it can to allow re-use across the
m= sections for the same configurations.

3. Multi-Media RTP sessions (draft-ietf-avtcore-multi-media-rtp-session)
This mechanism allows multiple media types, like audio, video and text
to share the same RTP session. This in itself does not reduce the
availability, but increases the number of codec configurations that
might be required (or desired) to signal support for.

4. RTP Retransmission (RFC 4588)
RTP retransmission payload format, requires one PT per PT that one want
to be able to retransmit. If the answer is all of the payload formats,
this doubles the payload format consumption.

5. XOR based FEC (RFC 5109)
This RTP payload format would normally just consume one PT as it is
capable of recovering the original PT field of a lost packet. However,
it is commonly used with the redundancy payload format (RED) (RFC 2198).
And RED requires one to have one RTP payload type per Redundancy
combination. Thus, this results in at least as many PT as PTs one like
to be able to apply FEC on.

Lets try using the above in combination and see what the implications are.

So we have 96 available values using RTCP mux, we like to use RTP
Retransmission as well as XOR FEC, to be able to cope with whatever RTT
the path provides and still be robust to packet losses within that
single RTP session. Thus, we end up with a maximum of 32 PTs for
encoding configurations.

As this is an RTP session that contains both Audio and Video we need to
create a number of configurations for both of media types. This endpoint
do support a descent amount of codecs to be compatible with various systems.

Audio: PCMA, PCMU, OPUS, AMR, AMR-WB, EVRC, EVRCWB, G.719, G.722, G.729
Video: H.264, H.265, VP8, VP9, SVC

On the audio side (10 codecs), this is actually a relative small subset
of the audio codecs that may be carried in RTP. Considering the
different configurations or annex extensions, there is no problem to
actually triple this list when it comes to audio. For video these 5 is a
selection of what might be in use in the near future. Also here there
are some potential, although less to offer additional PTs based on the
codec configurations. H.264 could run amok and offer a huge number if
one have a codec implementation that supports many profiles, as each
profile requires its own PT to be offered. As H.264 has 10+ profiles it
is possible. But, a more realistic count is likely 3 PTs.

The main point is that just the codecs listed above are themselves 15.
With some need to have different configurations for some of them, the
number can relatively easily be doubled and result in that one is up
against the limit (32).

There are clearly choices that one can make to reduce the usage and save
some number of PT values. My main concern is that one more mechanism
that results in equal number of PTs of its own in regards to what it is
associated with, is likely to cause significant concern. And we do have
some that has the potential. Multi stream scalability or simulcast if we
would require to indicate each codec configuration with its own payload
type will increase the requirement with a significant factor.

Thus, this is a potential issue, and an issue that can't be dismissed,
just because your set of limitations makes it unlikely that you will run
into it. We do need to ensure that mechanisms doesn't waste PT values to
achieve some other gain. This is becoming a real limitation.

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

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

---

From: Justin Uberti <[email-masked]>
Date: Wed, 19 Mar 2014 17:13:40 -0700

Note that the current text indicates that rtcp-mux is mandatory-to-use when
bundling. The question here is whether we should reopen that discussion.

*6.2.3.  rtcp-mux Attribute

   For each "m=" line in a BUNDLE group, an Offerer and Answerer MUST
   assign an SDP rtcp-mux attribute [RFC5761].*

My feeling is no, since it creates odd edge cases, such as when you
have an existing audio m= line with rtcp-mux on, and then want to
bundle an audio m= line without rtcp-mux onto the existing transport;
since you don't have enough ICE components in the existing transport,
it's not clear how to perform the bundling.

On Sun, Mar 16, 2014 at 7:16 AM, Christer Holmberg <
[email-masked]> wrote:

> Just to clarify: the support of RTP/RTCP mux is already mandated in
> BUNDLE, and question is not whether the included the a=rtcpmux attribute or
> not when RTP/RTCP mux is used - it shall be included. The question is
> whether we should mandate usage of RTP/RTCP mux within a BUNDLE group.
>
> Regards,
>
> Christer
>
>
>
> Agree this is a real limitation. In addition to the codecs listed above,
> note that CN and telephone-event are often needed, and potentially in
> multiple clockrates.
>
> On Fri, Mar 14, 2014 at 2:56 AM, Magnus Westerlund <
> [email-masked]<mailto:[email-masked]>>
> wrote:
> MMUSIC,
>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 19 Mar 2014 19:28:19 -0700

I have to agree with Justin here. Fewer moving parts that way. BUNGLE is
already complex enough.
On Mar 19, 2014 5:14 PM, "Justin Uberti" <[email-masked]> wrote:

> Note that the current text indicates that rtcp-mux is mandatory-to-use
> when bundling. The question here is whether we should reopen that
> discussion.
>
>
> My feeling is no, since it creates odd edge cases, such as when you have an existing audio m= line with rtcp-mux on, and then want to bundle an audio m= line without rtcp-mux onto the existing transport; since you don't have enough ICE components in the existing transport, it's not clear how to perform the bundling.
>
>
>
>
>
>
> [email-masked]

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 20 Mar 2014 07:49:25 +0000

Hi,

>6.2.3.  rtcp-mux Attribute
>
>   assign an SDP rtcp-mux attribute [RFC5761].
>
>
>
> My feeling is no, since it creates odd edge cases, such as when you have an existing audio m= line with rtcp-mux on, and then want to bundle an 
> audio m= line without rtcp-mux onto the existing transport; since you don't have enough ICE components in the existing transport, it's not clear how to perform the bundling.

Within a BUNDLE group, one cannot use RTP/RTCP mux for some m- lines, and not use RTP/RTCP mux for some other m- lines. Either you use RTP/RTCP mux for the whole BUNDLE group, or you don't use it. If that is unclear in the spec, we can add some text about that.

Then, if the concern is when adding new m- lines to an existing BUNDLE group, we could always say that, if you have an existing BUNDLE group with RTP/RTCP mux, new m- lines added to that BUNDLE group MUST also use RTP/RTCP mux.

I guess the big question here is whether there will be a risk of running out of payload type values if mandating RTP/RTCP mux. Magnus and Justin have given some good insight into "payload type consumption".

Regards,

Christer

Note: When talking about m- lines, I refer to m- lines for RTP transport. 

On Sun, Mar 16, 2014 at 7:16 AM, Christer Holmberg <[email-masked]> wrote:

Hi,

Regards,

Christer

1. RTCP MUX (RFC 5761)

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 20 Mar 2014 10:50:01 +0100

> Do other people have opinions on this?

I have considered this proposal in a wider context and have the
following reflections and also an additional motivation why I personally
consider it important that a bundle-group shall be possible to be
established with RTCP on either the same transport flow (5-tuple) as
RTP, i.e. using a=rtcp-mux, or using separate transport flows (one for
RTP, one for RTCP), i.e. no a=rtcp-mux.

First of all BUNDLE is a general signaling mechanism it is possible to
apply to any user of SDP offer/answer. WebRTC is the first and the one
which pushed it into existence, but I am pretty certain it will not be
the only user of  the mechanism.

What Justin is pushing for, prevents one to have multiple media streams
of different or the same type, i.e. what ever you put in the same bundle
group, to have RTCP separated on transport level from RTP.

In most cases this doesn't matter, but where it can matter is when using
QoS, for example in cellular environments. Being forced to put RTCP on
the same QoS treatment as the media will either reduce the achievable
quality or increase the cost. Being able to spend these commonly 5% of
bandwidth on improving media or avoiding higher cost is significant in
such an environment.

Thus, I think everyone needs to thing twice about this. Shall really
relatively minor implementation concerns and focus on general Internet
only deployments win out over BUNDLEs applicability and the possibility
to get the most out of any QoS when available.

To be clear, I am fine with having usage of a=rtcp-mux as default
behavior, but from my perspective we need to be able to actually
negotiate if one turns on RTP/RTCP multiplexing using the a=rtcp-mux
attribute when doing an round of offer/answer based signaling.

cheers

Magnus Westerlund

SE-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 20 Mar 2014 10:56:10 -0400

One comment inline

> attribute when doing an round of offer/answer based signaling.

IMO, if rtcp-mux is to be an option in bundles, then I am *not* fine 
with having it as default behavior. Doing so would mean the default is 
one way with bundle, and a different way without bundle. Such an 
inconsistency is crazy - it will lead to a lot of confusion.

Especially consider what happens if offer is constructed with bundle and 
says nothing about rtcp-mux, but the answerer doesn't support bundle. 
Are you doing rtcp-mux or not?

	Thanks,
	Paul

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 20 Mar 2014 16:51:17 +0100

> inconsistency is crazy - it will lead to a lot of confusion.

What I meant with default, being the recommended starting behavior if
you haven't a reason to do otherwise. What the offering parties really
like to do is explicitly signalled, always! If one wants to use
a=rtcp-mux one MUST include it, if not don't include it.

> Are you doing rtcp-mux or not?

Well, you do that initial offer with a=rtcp-mux. If the answer removes
both BUNDLE and the a=rtcp-mux, then you don't use either. Then you have
to use the separate transports that you are required to include for this
reason when offering BUNDLE initially. For subsequent offers, the offer
knowing the receiver was known to support BUNDLE one can use that
assumption. Thus, one can avoid the inclusion of RTCP transports if one
offers a=rtcp-mux. That is the reason I find it good to mandate support
of a=rtcp-mux. However, as I wrote in the previous message, there are
reasons why an Offerer should be able to allocate transports and then
remove the a=rtcp-mux from its new Offer.

I am worried that people appear think that just because you offer
BUNDLE, you can have a lot of values set by not explicitly indicating
them in the SDP. That, is from my perspective NUTS. We have to be
explicit about the usage and configuration of other mechanisms. In some
cases BUNDLE leads to restrictions, for example across the m= lines in
the BUNDLE group. Attributes that you would include on a single m=
section when not using BUNDLE do have to be included in all the  m=
sections when using it. When doing BUNDLE the common start assumptions
should be that normal non-BUNDLE behavior applies. There might be
exceptions and that is what the SDP mux drafts tries to make clear.

Cheers

Magnus Westerlund

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 20 Mar 2014 12:50:33 -0400

OK. We are in agreement. I misunderstood what you meant by "default". I 
think you meant "recommended initial setting".

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 20 Mar 2014 18:01:57 +0000

Hi,

Please note that NOBODY has suggested that we would have RTP/RTCP mux WITHOUT explicit indication using a=rtcp-mux. 

The question is whether we shall mandate the usage of RTP/RTCP mux (and, hence a=rtcp-mux) in BUNDLE, or whether we shall allow BUNDLE groups with separate RTP- and RTCP ports.

Regards,

Christer

________________________________________
From: mmusic [[email-masked]] on behalf of Magnus Westerlund [[email-masked]]
Sent: Thursday, 20 March 2014 5:51 PM
To: Paul Kyzivat; [email-masked]
Subject: Re: [MMUSIC] BUNDLE Q14: Mandate usage of RTP/RTCP mux within a BUNDLE group? [was: On the sparsity of RTP Payload types]

Cheers

Magnus Westerlund