Subject: Static versus dynamic payload types.

From: Arlie Davis <[email-masked]>
Date: Thu, 1 Aug 1996 15:26:01 -0400

The issue of static versus dynamic payload types has come up so
frequently on this and other mailing lists, that it leads me to believe
that the current system is inadequate.  Developers of new applications
who use static payload types fear the wrath of the gurus if they deploy
their tools without the gurus' blessing.  Developers who use dynamic
payload types must either depend on the quality (and existence!) of the
session tools, or must coordinate informing the receivers of the payload
type through other means (email, sneaker-net, web page, whatever).

This is frustrating, and hindering new application development.  Here's
my little mini-proposal.

Why not throw out the existing system, and replace it with something
much more flexible, extensible, and decentralized?  Whenever a developer
wants to create a new payload type, generate a new GUID (from DCE RPC /
MS COM).

(If you've never heard of GUIDs, they are unique, 128-bit numbers that
can be generated on any machine that has an IEEE network card (Ethernet,
Token Ring, etc.).  GUIDs are generated using the MAC address of one of
the machine's network cards and a few other things.)

Most people would gripe about transmitting 16 bytes for just the payload
type; I'm one of them.  So, modify RTP to have two kinds of packets:
stream data and stream description.  Stream data is just what it sounds
like; the SSRC (and network-layer address/port) would identify the
stream.  A stream description packet would be transmitted at the
beginning of a transmission and then periodically during the
transmission.  The stream description would also have the SSRC and all
the necessary information to uniquely identify the stream that is being
described.  The stream description would contain the (rather long) GUID
that serves as the payload type, along with any other parameters that
are deemed relevant.

Even a relatively huge stream description packet (~256 bytes) could be
transmitted once every few seconds.  At worst, when a client joins an
on-going transmission, it would have to wait a few seconds before being
able to identify the contents of the packet.

You could even do this within the context of the current RTP protocol. 
Define two static payload types: Stream data and stream description. 
The RTP header contains all the information needed to identify the
stream; the payload type (from the current RTP header) would serve to
distinguish stream data from stream descriptions.  The two static
payload types would allow people to assign their own new, dynamic
payload types _without_ the need for externally coordinating the payload
type.

Please direct comments directly to me.  I'll summarize to the list, if
necessary.

-- arlie