Subject: SDP questions

From: Stephen Casner <[email-masked]>
Date: Wed, 26 Jul 1995 21:13:03 -0700 (PDT)

Mark,

The RTP profile allocates some of the payload format type space for
dynamically defined formats, with the expectation that session control
protocols will provide a means to bind some payload format definition
to a payload type code.  Shouldn't SDP provide such a mechanism?  I
realize there are several pieces that need to be defined to complete
it, such as the structure of a payload format definition.

The SDP spec lists the format names for audio and video, but there is
not a 1-1 mapping between those and payload format codes.  In
particular, there is no code for L8, and there are two codes for L16
(at 8000 and 16000 Hz).

Second item: session control applications may need to store locally
some attributes of a session that need not or should not be
transmitted to other participants in the session.  It would be
convenient to store those attributes in the session description, but
with some indicator that they are local.  The instance we noted was
for attributes that might be included with "a=", so the first guess
might be to specify another letter that meant local attribute.  But it
seems that there might also be a need to store locally some
information that would normally be coded in other field types.

							-- Steve

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 08 Aug 1995 19:21:27 +0200

> particular, there is no code for L8, and there are two codes for L16

As Steve pointed out, the encoding names are not meant to completely 
specify a payload format. For video, this distinction can be generally 
ignored, for audio it is critical. There are currently no names for the 
full format (for audio, encoding + channel count + sampling rate + 
maybe packetization).

Since it is generally not good to have two 'almost equal' lists, 
particularly when IANA has to decide whether there are one or two, I 
would suggest removing the encoding list from the SDP spec entirely. 
There are two cases for RTP:

1) standard format with a fixed (profile/IANA-assigned) payload type;
   we might as well use the number for that in the SDP description 
(avoids
   a separate name space) and map to user-readable names at user agents.

2) dynamic format with some randomly selected payload type. Here, use a
   description like L16,2,11025 for stereo at 11025 Hz linear.

Side issue:
There are some issues with payload formats that get frozen, i.e., 
acquire their own fixed payload type later. (If you just say 'payload 
type 17', and 17 was defined after the media agent was coded, the media 
agent would be clueless, even though it might support the particular 
combination of encoding, channel count, and sampling rate.) This 
problem can be avoided if the whole specification (e.g., L16,2,11025) 
is always included, even for 'fixed' codes. This allows media 
applications that don't know about a new assignment to work if they 
support the format itself. Obviously, redundancy also adds the 
possibility for lack of consistency.

Henning