Subject: Re: Question regarding SDP and MIME codec registration...

From: Colin Perkins <[email-masked]>
Date: Mon, 24 Apr 2000 16:41:06 +0100

[...rem-conf added back to the cc list...]

--> Henning Schulzrinne writes:
>Mark Handley wrote:
>> This wasn't obvious to me from the previous messages in this thread.
>> I agree that b= isn't useful for negotiation.  Yet another case where
>> SDP falls short because it doesn't have a grouping mechanism for
>> parameters of formats.
>
>Yes, we are definitely reaching the limits of the protocol.
>
>> 
>> There seem to be several alternatives
>> 
>>   a=rtpmap:100 vnd.nuera.ecelp7470/8000
>> 
>>   a=rtpmap:100 vnd.nuera.ecelp;bps=7470/8000
>> 
>>   a=rtpmap:100 vnd.nuera.ecelp/8000
>>   a=fmtp:100 bps=7470
>> 
>> The first overloads the MIME subtype.  The second overloads the format
>> name, by encoding a MIME parameter in it when used with SDP (SDP won't
>> care - it's just a token) but the MIME registration is clean.  The
>> last doesn't overload anything, but may not satisfy them that it's a
>> required parameter.
>
>None of them are great, I agree. Among the bunch, the second one is
>probably the least bad, in my view. (2327 doesn't say anything about
>what's legal in an 'encoding name', so that anything except a / would
>work. It's not really a token, in the strict sense, since tokens can't
>contain semicolons.)

The MIME registration for the standard codecs in the a/v profile
(draft-ietf-avt-rtp-mime-02.txt) uses the third option, with a 
statement that some parameters are required. 

Colin

>I don't think the third one would work as it now requires that the
>negotiation code goes fishing elsewhere. You'd end up with something
>like
>
>a=rtpmap:100 vnd.nuera.ecelp/8000
>a=rtpmap:101 vnd.nuera.ecelp/8000
>a=rtpmap:102 vnd.nuera.ecelp/8000
>
>a=fmtp:100 bps=7470
>a=fmtp:101 bps=8000
>a=fmtp:102 bps=9600
>
>which is likely to be very confusing.
>
>
>
>
>
>> 
>> None of these really seem all that satisfactory, but I can't think of
>> any other good alternatives.
>> 
>> Cheers,
>>         Mark
>
>-- 
>Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 24 Apr 2000 17:06:55 -0400

Colin Perkins wrote:

> statement that some parameters are required.

Hmm. I still think this is a really bad idea.
draft-ietf-avt-rtp-mime-02.txt doesn't really mention parameters that
are necessary to do media type and capability negotiation. None of the
registrations included describe this case that a single MIME type
describes two different encodings (L16 does, but the parameter, the
clock rate, is part of the rtpmap parameter). I think this should be
fixed before it's too late. This should only affect a few encodings.

---

From: Jeff Ayars <[email-masked]>
Date: Mon, 24 Apr 2000 20:51:56 -0700

>fixed before it's too late. This should only affect a few encodings.

Using fmtp is how I would have expected it to be done.  I think using the 
rtpmap <optional parameters> part is a interop nightmare.  What about RFC 
2361?  If I want to send Microsoft G.723 from a .wav file to a player that 
played audio using ACM codecs I think

m= audio 0 RTP/AVP 101
a=rtpmap: 101 vnd.wav/22050/1
a=fmtp: 101 codec=42

is the right way to do it.

JEff

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 25 Apr 2000 09:40:26 -0400

> is the right way to do it.

I disagree. This is an implementation nightmare, since now the
negotiation code (which is often not the media agent) has to be aware of
all the possible codecs and their parameters that influence
interoperability. As long as I have names, I can easily export a table
of capabilities from the media agent, without having to grope through
assorted fmtp's.

If two codecs are different and not distinguishable at the bit-level
(such as G.723.1) and are usable independently (unlike G.723.1, where
the claim is that the ITU protocol police will pull you over if you
support 5.6 kb/s without supporting 6.3 kb/s), they deserve different
names, even though they might be lumped together in the same "marketing"
name. They have different bit patterns, different software for decoding
it - thus, for all technical purposes, they are different (albeit
technically related) codecs. If (to cite a recent example) Nuera had
chosen to name their codecs Alpha, Beta and Gamma, we wouldn't hesitate
a moment to register them under different names, even though they might
share some fundamental principles of audio signal compression.

Also, I don't think that using Wave codec names is the right solution,
as it is heavily OS dependent. Designation of codec 42 is meaningless to
those not running ACM. We have codec names, such as G.729, that are
standardized and widely recognized, with appropriate payload formats.
Note that codec 42 makes no sense since it does not describe the payload
format itself, just a file format. In all but trivial cases (like
mu-law), these are not likely to be the same.

---

From: Ashok Yerneni <[email-masked]>
Date: Tue, 25 Apr 2000 09:07:15 -0700

Where do I get detailed information about these protocols. Is there a 
public domain
library that implements these protocols?

thanks,

Ashok
Ashok Yerneni				(408) 366 8001,x501
VP of Engineering				(408) 366 8004(fax)
Graham Technology Solutions			[email-masked]
20823 Stevens Creek Blvd, 			www.graham.com
Cupertino, CA 95014-2111.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 25 Apr 2000 13:37:02 -0400

SAP:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sap-v2-06.txt

SDP:
rfc2327, http://www.ietf.org/rfc/rfc2327.txt

-Jonathan R.

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Jeff Ayars <[email-masked]>
Date: Tue, 25 Apr 2000 12:18:23 -0700

Comments inline...

>of capabilities from the media agent, without having to grope through

So you are saying that it's your wish that a=fmtp in SDP be explicitly 
excluded from consideration during any format negotiation phase?  I can see 
that makes it easier.

>share some fundamental principles of audio signal compression.

This is why in draft-ietf-avt-profile-new-08.txt the G.726 
bitrates/bitdepths are nudged in the direction of G726-16, G726-24, 
G726-32, and G726-40?

>mu-law), these are not likely to be the same.

I don't know that Wave codec names necessarily implies any OS 
dependency.  Sure the codec name is defined for a particular OS but the 
codec may exist on multiple platforms - Indio by Intel, Cenepac by 
Supermac.  There is a standard that registers a mime type for these codecs 
- RFC 2361.  It uses parameters to the general mime type to identify the 
encoding type.

Are you suggesting that SDP not support announcing sessions that use codecs 
defined in RFC 2361?

 From RFC 2361:

"The purpose of this paper is to establish a mechanism by which codecs 
registered within Microsoft's WAVE and AVI Registries may be referenced 
within the IANA Namespace by Internet applications."

So RFC 2361 isn't tied to a file format, but to the codec - the data type.

Or are you saying that every data type needs an explicit mime type 
registered for it's RTP payload format so if I wanted to send Cenepac via 
RTP I would need to register a new mime type, different from video/vnd.avi; 
codec=CVID, for to send it via RTP and that as above, I should include the 
codec in the mime name instead of as a parameter?

JEff

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 25 Apr 2000 21:35:21 -0400

> excluded from consideration during any format negotiation phase?  I can see

Yes, fmtp should be used to *configure* a codec, but not to decide
whether it's compatible. In my implementation model, the SIP agent (say)
would simply pass down the fmtp content to the media agent, completely
oblivious what it means. It simply gathers the 
advertised receive capabilities = codecs A, B, C, D (from the m and
rtpmap lines) and, for example, pops up a GUI panel of the sort after
subtracting the codecs that it doesn't know anything about: "The caller
can receive audio A, B, C (suitably non-techie descriptions). Which ones
do you want to use?" and then configures the media agent. At that point,
the GUI part can easily handle codecs that it has never heard about, as
long as it is given a simple list of names describing the media agent
capabilities.

> bitrates/bitdepths are nudged in the direction of G726-16, G726-24,

Yes, although I have to admit that the recent discussion has emphasized
the need for this even more.

> codec in the mime name instead of as a parameter?

Yes, as discussed in the RTP MIME registration document, just having a
file format description is not sufficient for RTP transport. We can now
do one of two things:

- make sure that there's an interoperable RTP packetization for each of
the video/vnd.avi codecs (probably a useful exercise)

- map these to the 'explicit' RTP codec names where possible to avoid
the former.