Subject: [MMUSIC] On the sparsity of RTP Payload types

From: Magnus Westerlund <[email-masked]>
Date: Fri, 14 Mar 2014 10:56:01 +0100

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]
----------------------------------------------------------------------

---

From: "Roni Even" <[email-masked]>
Date: Fri, 14 Mar 2014 12:24:18 +0200

Hi Magnus,
I think that also the static payload types limit the number of available PT
Roni

> -----Original Message-----
> From: mmusic [mailto:[email-masked]] On Behalf Of Magnus
> Westerlund
> Sent: 14 March, 2014 11:56 AM
> To: mmusic (E-mail)
> Subject: [MMUSIC] On the sparsity of RTP Payload types
> 
> MMUSIC,
> 
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.
> 
> 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.
> 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.
> 
> 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.
> 
> 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.
> 
capable of
> recovering the original PT field of a lost packet. However, it is commonly
used
> with the redundancy payload format (RED) (RFC 2198).
> combination. Thus, this results in at least as many PT as PTs one like to
be able
> to apply FEC on.
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.
> 
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.
> 
> 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.
> 
number
> can relatively easily be doubled and result in that one is up against the
limit
> (32).
> 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.
> 
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
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 14 Mar 2014 11:41:57 +0100

> I think that also the static payload types limit the number of available PT

Not really, a modern user of SDP you should be able to override any of
the static PT value with whatever you want to use it for. But, I agree
it is the PT values you like to consume last as they might have issues
with redefining or getting accurate monitoring on them due to
misinterpretation of them as the static codec assignment.

But, if you need to avoid using them you loose 24 values for actually
assigned ones, and another 3 are reserved.

/Magnus

-- 

Magnus Westerlund

---

From: Justin Uberti <[email-masked]>
Date: Fri, 14 Mar 2014 10:33:42 -0700

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)

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 17 Mar 2014 14:01:13 +0100

> note that CN and telephone-event are often needed, and potentially in

Correct, I forgot to include these in the audio examples.

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

And here I assume you mean associating one incoming RTP packet stream
with a specific usage and m= section in the signalling?

I think we are making progress on that functionality, and I have hope
after hallway discussion in London that we will see a basic targeted
version of "appid" for this purpose (1-to-1 association) pretty soon.

Cheers

Magnus

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

-- 

Magnus Westerlund