Subject: Re: SDP questions

From: Mark Handley <[email-masked]>
Date: Wed, 09 Aug 95 16:35:31 +0100

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

Yes, SDP does appear to be the natural place to define these dynamic
types.

>> 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).

Agreed.

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

I don't believe we can remove the encoding list entirely because there
are a signifcant (i.e. more than one) number of none RTP encoding
types.  However, now we have the transport type field in SDP, we can
hang the SDP RTP-based encoding types off the RTP AVT profile.  I
agree this should be done.

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

This is profile dependant.  The RTP spec states "typically an
application will operate under only one profile...".  This may be the
case for apps, but not for SDP.  If we're going to use the payload
type number you'd better specify which profile applies too, or someone
sooner or later is going to end up writing an app that doesn't use the
default profile for the SDP media type, and then SDP would not know
which tool to start.  Something like "AVP-17" would solve the problem.

However, this is a little too implicit for my liking.

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

If it's a dynamic format, don't you need to tell the app what the
payload type number to encoding/sample-rate/no_of_chans mapping is?  I
thought this was the point of Steve's message?

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

Yes, this was what I was thinking too.

>Obviously, redundancy also adds the 
>possibility for lack of consistency.

This is a whole new headache we're currently going through with our
audio tool :-)

Based on your suggestions, I favour something like:

m=audio 12346 RTP PCMU,8000

or

m=audio 12345 RTP L16,11025/2
a=ptype:97

Thus the sample rate is a compulsory part of audio media types.  The
number of channels could conceivably be used by some other payload
types (not just RTP audio) so we make it generic to all media types
and optional defaulting to one. If someone tries to use the number of
channels field for media where it's meaningless (such as RTP video)
then this is an error.  We already have this "/" notation for
addresses and ports, so allowing it for encodings is fairly natural.

How this works with heirarchical encodings probably requires some more
thought, and certainly some explanation :-)

We then allow the ptype attribute to specify a payload type number
should anyone need SDP to specify this mapping.

Is there a requirement to use SDP to define a whole set of dynamic
mappings?

If so I guess we'd need a set of mapping attribute something like:

a=ptmap:L8,8000 96
a=ptmap:L8,11025 97
a=ptmap:L16,8000 98
a=ptmap:L16,11025 99
etc...

Comments?

Mark

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 09 Aug 1995 17:56:36 +0200

> thought this was the point of Steve's message?

Yes, clearly.

> addresses and ports, so allowing it for encodings is fairly natural.

I don't see the benefit of using a slash separator rather than a comma 
list with one, two or three parameters (encoding only for video, two or 
three parameters for audio). Also, for video, 'sampling rate' is 
probably an inappropriate term (or did you want to put the frame 
count/second there?).

> Is there a requirement to use SDP to define a whole set of dynamic

We have little experience with dynamic typing, but I have the feeling 
that once you want one, you may need a whole batch, so I'm 
uncomfortable with a single one. However, this raises another issue: 
Given dynamic adjustment of media types (to account for network load 
variations, say) by either human or some algorithm, how meaningful are 
the format descriptions, except as the initial starting value. Just 
because the sd entry says PCMU,8000, I can't assume that it's still 
PCMU,8000 when I start my receiver. This may be more something that the 
spec should clarify; specifying a list of possible encodings is 
probably overkill in the absence of a negotiation mechanism.

> If so I guess we'd need a set of mapping attribute something like:

Reasonable, except that the channel count is missing.

> Mark

Henning