Subject: RTP profiles and payload types in SDP

From: Mark Handley <[email-masked]>
Date: Fri, 22 Dec 1995 11:53:38 +0000

(I know it's dangerous sending this so close to Christmas, but if you
plan to use SDP, please read this! Sorry it's so long!)

I had a long discussion with Steve Casner last night regarding RTP
profiles and payload types.  If you remember, the problem Steve raised
is that the names currently specified in the SDP draft and RTP AV
Profile do not specify a unique mapping onto payload type for two
main reasons:

 - such names are profile specific, and there may be more than one profile
   possible for a media type.
 - some (perhaps soo to be many?) payload types are allocated dynamically,
   and therefore the encoding name is not sufficient.

We discussed a large range of options for dealing with these,
including making the assumption that for audio and video media, there
will only be one AV profile.  However, this seems to be a bad course
to take, given that there may soon be more than one RTP profile for
whiteboard type applications, and any mechanim we choose to solve this
problem should also be used for audio and video.  We also don't want
to adopt a solution that becomes ugly should a different AV profile be
defined for some reason (one possible though undesirable example is
that such a profile could emerge from the current H.323 work).

Given that we need to specify the profile for the payload type to be
meaningful, there are several options:

  1 specify it in the protocol field
  2 specify it in the format field
  3 merge protocol and format fields and use one unique namespace
  4 add a new profile field

4 is undesirable as concept of a profile is RTP specific, and although
we expect SDP to be used primarily for RTP media streams, we wish to
avoid constraining it to be used so.

3 is how SDP was originally specified.  The split was made to avoid
overloading of the format field, as there are a number of well defined
(eg ITU standard) formats that will quite likely be carried over
different protocols in different environments (SDP is not restricted
to use in sd like tools).

I originally favoured 2, as that seemed to make it simpler for generic
RTP monitoring/recording tools to be started for RTP based media.
However, Steve has convinced me that for all purposes expect generic
loss monitoring, the protocol specification is incomplete without the
profile being specified, and that this makes it easier to solve the
problem of dynamic payload type mappings.  In addition, although a
media tool may operate with more than one payload type from a single
profile, no media tool will switch between profiles for a single media
stream.  

Currently only the AV profile is defined.  The protocol field for RTP
based applications operating under this profile will thus be "RTP/AVP"
(the slash notation is consistent with other grouping conventions in
use in SDP, though it should probably be explained somewhere in the
next draft).  Should new RTP profiles be defined, their protocol field
will follow the same format (RTP/???).  

The second part of the problem Steve identified was how to deal with
dynamic payload types.  We seem to be undergoing the start of an
explosion in new and experimental payload types as new encodings are
developed which are more appropriate that traditional ITU standards
for packet networks.  It is not clear to either of us whether anything
other than ITU standards will have static payload types - it is not
impossible that dynamic payload types will be used by the majority of
the new encodings currently being developed, and thus it seems
appropriate SDP should be one of the primary mechanisms used to bind
dynamic payload types to particular encodings.  It is clear that
whatever we do with SDP, some configuation of SDP clients (however
this configuration is done) is required to map particular encoding
names onto particular media tools.  Given that the RTP payload type is
only 7 bits, that many new experimental encodings and being developed
and that new adaptive tools may switch encodings between a
significantly large range of alternatives, it seems likely that
per-session binding of dynamic payload types to particular encodings
(or instantiations of encodings) will be desirable in SDP.

Taking this into account, what we're proposing for RTP based media
streams is to put a *list* of payload type *numbers* in the format
field.  If, under the relevant profile, the payload type is a static
allocation, then no further fields are necessary.  If however, the
payload type is a dynamic one, then an additional field is needed to
define the mapping of payload type to media format.  

For 8KHz PCMU mono audio, we would simply use:

m=audio 12345 RTP/AVP 0

(0 is the static payload type defined for 8KHz PCMU mono audio in RTP/AVP)

A more complex example is:

m=audio 12345 RTP/AVP 96 97 98
a=rtpmap:96 L8/8000
a=rtpmap:97 L16/8000
a=rtpmap:98 L16/11025/2

In this case, L8 and L16 are defined in the RTP AVP as names for 8 bit
linear sampling and linear 16 bit linear sampling.  However, not
payload type is given, as the clock rate and number of channels may
vary.

The general format for an rtpmap attribute is:

RTPMAP::= "a=rtpmap:" <payload type> space <encoding name> "/"  <clock rate>
	  [ "/" <number of channels>]

<number of channels> is ommited if it is one or is not applicable.

Now there is still question is what to do about new encoding types.
Even though there may be no static assignment of payload types, I
expect that encoding types will need to be registered with IANA.  To
allow experimental encoding types to be used, these should be prefaced
with "X-" in the traditional way.  For example, a redundant-audio
stream might be defined as:

m=audio 12345 RTP/AVP 99
a=rtpmap:99 X-GSMLPC/8000

This obviously requires sites that wish to receive this stream to have
appropriate configuration state for GSMLPC to enable them to know
which tool to start and what the command line options should be.

Now I should emphasize that I don't expect all this complexity to be
visible to the user - it should be hidden behind a sensible interface.
The current sdr interface for creating session is already too
complicated for "normal" (ie RTP unaware) users, and should be
simplified anyway.  There has been some talk of discouraging people
from creating vat protocol (as opposed to RTP audio) sessions by
making it ugly to do so in SDP - I think this is the wrong place for
such social engineering, although I have no problem with doing so in
the sdr user interface :-)

Comments and/or suggestions are of course welcome!

Have a happy new year!

Mark