[xiph-rtp] Suggested changes to the Vorbis SDP attributes

[Tor-Einar Jarnbjo]

Hi!

With fragments of the discussion on the IETF mailing lists around the 
last RFC draft, I suggest the following changes to the Vorbis-specific 
SDP fields (the formatting of the SDP field descriptions is BTW broken 
after converting the XML version to text or HTML):

* The format specific fmtp bitrate attributes

a=fmtp:98 bitrate_min=<Bitrate Minimum>
a=fmtp:98 bitrate_norm=<Bitrate Normal>
a=fmtp:98 bitrate_max=<Bitrate Maximum>

are replaced with bitrate fields:

b=X-NOM:<nominal bitrate>
b=X-MAX:<maximum bitrate>
b=X-MIN:<minimum bitrate>


* The number of audio channels should not be specified with an fmtp 
attribute

a=fmtp:98 channels=<Num Audio Channels>

but as encoding parameter in the rtpmap attribute:

a=rtpmap:97 VORBIS/44100/2

If not specified, the number of channels defaults to one (RFC 2327, 
chapter 6).


* Meta data (artist, song title, track number, album title, encoder 
vendor) should not be included as codec specific attributes, except for 
the designated fields:

i=<sessoion title>
a=tool:<name and version of tool used to create the session description>

Reason: Adding a comprehensive list of meta data attributes to the SD, 
may easily cause it to grow too large for transport in a single UDP 
packet (as already mentioned in the draft) and it is not really needed here.


* md5key as attribute name for the setup header's md5 /hash/ should be 
replaced by something else, as we are not referring to a /key/ but a 
/hash/ value. I suggest sh for "setup header" and simply postfixed by 
-uri and -md5:

a=fmpt:97 sh-uri=http://...
a=fmpt:97 sh-md5=d41d8cd98f00b204e9800998ecf8427e

It should also be clearer in the RFC which codec specific attributes are 
mandatory and which are not (sh-uri should be mandatory, sd-md5 does not 
really have to be). Also the format of the MD5 hash as a 32 digit 
hexadecimal number should be specified and which URI schemas must be 
supported by the client for the setup header URI (http and rtsp?).

Something to think about would also be a URI reference to the comment 
header, containing Vorbis style meta data, instead of embedding this in 
the session descriptor:

a=fmpt:97 ch-uri=http://...


Another thing I'm wondering about: Is it really necessary to add 
complexity to the specification by allowing the headers to be 
transported in RTCP packets as well? Are there any advantages to this 
compared to putting some of the header informations in the session 
descriptor and referring to the rest using a URI?

Tor