Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-speex-01.txt

From: [email-masked]
Date: Mon, 11 Jun 2007 15:50:02 -0400

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Audio/Video Transport Working Group of the IETF.

	Title		: RTP Payload Format for the Speex Codec
	Author(s)	: G. Herlein, et al.
	Filename	: draft-ietf-avt-rtp-speex-01.txt
	Pages		: 21
	Date		: 2007-6-11
	
Speex is an open-source voice codec suitable for use in Voice over IP
   (VoIP) type applications.  This document describes the payload format
   for Speex generated bit streams within an RTP packet.  Also included
   here are the necessary details for the use of Speex with the Session
   Description Protocol (SDP).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-speex-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-avt-rtp-speex-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-avt-rtp-speex-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Colin Perkins <[email-masked]>
Date: Tue, 12 Jun 2007 13:43:17 +0100

> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-speex-01.txt

This looks to be in pretty good shape, the main issue being mapping  
parameters to the "a=fmtp:" line in SDP. Detailed comments follow:

Marker bit "to indicate that the RTP packet contains at least one  
complete frame" is unusual for audio (although typical for video). It  
would be better used to indicate first packet after a silent period,  
as is usual for audio codecs.

Section 3.3: "Sampling rate values of 8000, 16000 or 32000 Hz MUST be  
used.  Any other sampling rates MUST NOT be used" is confusing.  
Better to say "The sampling rate MUST be either 8000 Hz, 16000 Hz, or  
32000 Hz".

Section 4.1.1: "rate" needs to be listed a required parameter, since  
the codec supports several sampling rates.

Section 5: the "a=fmtp:" attribute is for media type parameters only.  
If you wish to define vbr, cng, and mode parameters, they must be  
defined as media type parameters in the IANA considerations, and then  
mapped into the "a=fmtp:" line. Section 6.2 of RFC 4749 is a good  
example of how to do this.

Cheers,
-- 
Colin Perkins
http://csperkins.org/

---

From: Luca Barbato <[email-masked]>
Date: Tue, 12 Jun 2007 14:54:50 +0200

Colin Perkins wrote:
> Section 4.1.1: "rate" needs to be listed a required parameter, since the
> codec supports several sampling rates.

Isn't it delivered in band/bitstream and subject to change every 20ms?

lu

-- 

Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

---

From: Aymeric Moizard <[email-masked]>
Date: Tue, 12 Jun 2007 18:03:23 +0200 (CEST)

On Tue, 12 Jun 2007, Colin Perkins wrote:

> Marker bit "to indicate that the RTP packet contains at least one complete 
> frame" is unusual for audio (although typical for video). It would be better 
> used to indicate first packet after a silent period, as is usual for audio 
> codecs.

Right that is confusing.

Marker (M) bit: The M bit is set to one on the first packet received 
after a silent period.

> Section 3.3: "Sampling rate values of 8000, 16000 or 32000 Hz MUST be used. 
> Any other sampling rates MUST NOT be used" is confusing. Better to say "The 
> sampling rate MUST be either 8000 Hz, 16000 Hz, or 32000 Hz".

I agree.

> codec supports several sampling rates.

agree too.

> Section 5: the "a=fmtp:" attribute is for media type parameters only. If you 
> wish to define vbr, cng, and mode parameters, they must be defined as media 
> type parameters in the IANA considerations, and then mapped into the 
> "a=fmtp:" line. Section 6.2 of RFC 4749 is a good example of how to do this.

But that's definitly what is being said in section 5: in the following
text, we wanted to inform that you MUST use a=fmtp for mode, vbr and cng:

    An other way to make recommendations to the remote Speex encoder is
    to use its specific parameters via the a=fmtp: directive.  The
    following parameters are defined for use in this way:

Would you advise to change it to this text?:

    An other way to make recommendations to the remote Speex encoder is
    to use its specific parameters via the a=fmtp: directive.  "mode",
    "cng" and "vbr" parameter MUST be specified using this directive. The
    parameters are defined for use in this way:

As I understand your comment, you mean that "mode", "vbr" and "cng" should
appear in the section "4.1.1.  Registration of media type audio/speex"? 
Right?

tks,
Aymeric MOIZARD / ANTISIP
amsip - http://www.antisip.com
osip2 - http://www.osip.org
eXosip2 - http://savannah.nongnu.org/projects/exosip/

---

From: "SOLLAUD Aurelien RD-TECH-LAN" <[email-masked]>
Date: Wed, 13 Jun 2007 09:34:53 +0200

> Marker (M) bit: The M bit is set to one on the first packet 
> received after a silent period.

Hi

I'd rather say:

   The M bit is set to one on the first packet _sent_ after a silent period 

because the M bit is set by the sender

In addition, you should precise
-> a silence period during which packets have not been transmitted contiguously

See RFC 3551 §4.1
   For applications which send either no packets or occasional comfort-
   noise packets during silence, the first packet of a talkspurt, that
   is, the first packet after a silence period during which packets have
   not been transmitted contiguously, SHOULD be distinguished by setting
   the marker bit in the RTP data header to one.  The marker bit in all
   other packets is zero.  The beginning of a talkspurt MAY be used to
   adjust the playout delay to reflect changing network delays.
   Applications without silence suppression MUST set the marker bit to
   zero.

---

From: Colin Perkins <[email-masked]>
Date: Wed, 13 Jun 2007 14:47:47 +0100

> On Tue, 12 Jun 2007, Colin Perkins wrote:
...
>> Section 5: the "a=fmtp:" attribute is for media type parameters  
>> only. If you wish to define vbr, cng, and mode parameters, they  
>> must be defined as media type parameters in the IANA  
>> considerations, and then mapped into the "a=fmtp:" line. Section  
>> 6.2 of RFC 4749 is a good example of how to do this.
>
> appear in the section "4.1.1.  Registration of media type audio/ 
> speex"? Right?

The problem is that this sounds, due to "An other way to make  
recommendations", that the "a=fmtp:" parameters are different from  
the media type parameters. In fact the "a=fmtp:" line is an encoding  
of (some of) the media type parameters. All the parameters should be  
listed in the media type registration for audio/speex, and the  
section on SDP usage should explain how to code those in "a=fmtp:"  
and/or other SDP attributes, rather than defining new parameters.

Cheers,
-- 
Colin Perkins
http://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Wed, 13 Jun 2007 14:49:26 +0100

> Isn't it delivered in band/bitstream and subject to change every 20ms?

That should probably be signalled by a change in payload type number,  
with several types being offered if the sender wants the ability to  
change codecs. Doing that has the advantage that the receiver can  
reject sample rates it doesn't support during session setup.

Cheers,
-- 
Colin Perkins
http://csperkins.org/

---

From: Randell Jesup <[email-masked]>
Date: Fri, 15 Jun 2007 22:48:22 -0400

Aymeric Moizard <[email-masked]> writes:
>> used. Any other sampling rates MUST NOT be used" is confusing. Better to
>> say "The sampling rate MUST be either 8000 Hz, 16000 Hz, or 32000 Hz".
>
>I agree.

The rate from rtpmap is not (necessarily) the sampling rate (witness
video); it's the rate for timestamp values, and typically (not always) will
be an integer multiple of the sampling rate or lowest common multiple of
the sampling rates, more or less.  I would dislike having the rtpmap rate
be a true codec parameter; there may be reasons for using values other than
the hardware sample rate.

Since another message indicated that the encoding could change on a
per-packet level (whether signalled in-bitstream and/or by payload value
change), it may make sense to use 32000 for the timestamp rate always.  It
is *really* problematic when the timestamp rate changes when you switch
payloads.  The only other value I can see making sense would be 8000, and
then only if you wanted to make it easier to switch between speex and
things like G.711 on the fly.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)

---

From: Jean-Marc Valin <[email-masked]>
Date: Sat, 16 Jun 2007 14:20:40 +1000

> things like G.711 on the fly.

Only the *bitrate* can change on a per-packet. The sampling rate has
always been fixed for a stream. In theory, a constant timestamp rate of
8000 would work even at 32 kHz because the frames have a multiple of 4
samples, but I think it's cleaner to just use the sampling rate as the
timestamp rate.

	Jean-Marc

---

From: Randell Jesup <[email-masked]>
Date: Sun, 17 Jun 2007 00:42:28 -0400

>samples, but I think it's cleaner to just use the sampling rate as the

The timestamp rate *can* change on a per-packet basis if you have something
like this:

m=audio 4321 RTP/AVP 99 98 97
a=rtpmap:99 foo/8000
a=rtpmap:98 foo/16000
a=rtpmap:97 foo/32000

If you get a packet of 99, then a packet of 98, then a packet of 97, life
is *interesting*.  And note that this says nothing about the sampling
rate, which might (or might not) change.  I know this draft allows for
different timestamp rates; if there's no restriction about mixing them in
a media line, any implementation must be ready to deal with the above
scenario (per-packet payload changes).  

Of course, anyone offering more than one payload and more than one
timestamp rate (even for different codecs, like G.711 and G.722 offered
in the same line) has to be able to deal (in some manner) with timestamp
rates changes in mid-stream.  Or they have to deal with it in theory; I
doubt many deal well with it, and most (at best) work by basically punting
the problem.

Not to mention the ever-so-fun edge cases like where an RFC 2833 packet
crosses the boundary between different timestamp rates....  I have *no*
idea there, other than you have to assume that the timestamps are in the
rate of the audio codec otherwise in use at the time.  You can't really use
the timestamp rate of the RFC 2833's rtpmap line.

---

From: "Alfred E. Heggestad" <[email-masked]>
Date: Sun, 17 Jun 2007 14:40:30 +0200

Colin,

many thanks for your comments. see inline..

Colin Perkins wrote:
> would be better used to indicate first packet after a silent period, as 
> is usual for audio codecs.
> 

fixed in my working copy of -02

I looked in some other RFCs/I-Ds and found this:

   http://www.ietf.org/rfc/rfc4749.txt
   "The M bit MUST be set to zero in all packets."

   http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc3047-bis-04.txt
   "The M bit is set to zero."

> used.  Any other sampling rates MUST NOT be used" is confusing. Better 
> to say "The sampling rate MUST be either 8000 Hz, 16000 Hz, or 32000 Hz".
> 

fixed in my working copy of -02

> codec supports several sampling rates.

I assume that you mean "rate=sampling rate" here. Not sure how to formulate
it in the best way, but I ended up with this:

       rate: The sampling rate MUST be either 8000 Hz, 16000 Hz, or 32000
       Hz.

in other wideband codec specs I found this:

http://www.ietf.org/rfc/rfc4749.txt
"Required parameters: none"

http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc3047-bis-04.txt

   Required parameters:

       bitrate: the data rate for the audio bit stream.  This parameter
       is mandatory because the bit rate is not signaled within the
       G.722.1 bit stream.  At the standard G.722.1 bit rates, the value
       MUST be either 24000 or 32000 at 16 Khz sample rate, and 24000,
       32000 or 48000 at 32 Khz sample rate.  If using the non-standard
       bit rates, then it is RECOMMENDED that values in the range 16000
       to 48000 be used.  Non standard rates MUST have a value that is a
       multiple of 400 (this maintains octet alignment and does not then
       require (undefined) padding bits for each frame if not octet
       aligned).

> Section 5: the "a=fmtp:" attribute is for media type parameters only. If 
> you wish to define vbr, cng, and mode parameters, they must be defined 
> as media type parameters in the IANA considerations, and then mapped 
> into the "a=fmtp:" line. Section 6.2 of RFC 4749 is a good example of 
> how to do this.
> 

thanks for this comment. I have moved the definition of the fmtp parameters
to the "IANA Considerations" section, which is then referenced from the
"SDP Usage" section.

unless there are any more comments, I will publish -02 within the next
few days.

/alfred

> --Colin Perkins

---

From: Colin Perkins <[email-masked]>
Date: Sun, 17 Jun 2007 17:50:54 +0100

Alfred,

On 17 Jun 2007, at 13:40, Alfred E. Heggestad wrote:
...
>> complete frame" is unusual for audio (although typical for video).  
>> It would be better used to indicate first packet after a silent  
>> period, as is usual for audio codecs.
>

The usual rules for audio are: if the codec doesn't support silence  
suppression, the marker should always be set to zero; otherwise, set  
the marker bit to one on the first packet after a silent period.

>> Section 4.1.1: "rate" needs to be listed a required parameter,  
>> since the codec supports several sampling rates.
>

The current guidelines are in RFC 4855 section 2. You should use  
something like:

Required parameters:
	rate: RTP timestamp clock rate, which is equal to the sampling rate  
in Hz.
	The sampling rate MUST be either 8000, 16000, or 32000.

> to the "IANA Considerations" section, which is then referenced from  

Not sure what you mean by this?

> unless there are any more comments, I will publish -02 within the next

Okay - I'll re-read and comment when -02 is submitted.

Cheers,
-- 
Colin Perkins
http://csperkins.org/

---

From: Randell Jesup <[email-masked]>
Date: Tue, 19 Jun 2007 01:32:12 -0400

"Alfred E. Heggestad" <[email-masked]> writes:
>    rate: The sampling rate MUST be either 8000 Hz, 16000 Hz, or 32000 Hz.

The overloading of sample rate onto the timestamp rate for RTP for (most)
audio codecs causes some real problems with certain cases.  

Switching (in-call) between codecs with different sample rates -
overloading means that playout time is tricky to calculate, and doubly so
if there was a lost packet at the boundary.  (It also could significantly
upset jitter buffers and the like, unless you do a full reset on codec
shift.)  It may also complicate related RFCs like 2833, since 2833 is
normally intermixed with regular codecs:

m=audio 4321 RTP/AVP 98 99 100 101
a=rtpmap:98 ILBC/8000
a=rtpmap:99  G7221/16000
a=rtpmap:100 G7221/32000
a=rtpmap:101 telephone-event/8000
(a=fmtp's would be needed too)

Ok: what's the timestamp rate?  :-)  And when can it change?

Note 2833 encodes offsets and durations using timestamp values.  The
receiver *may* not be able to accurately determine the point of switching.
In some cases, the multiple switches could be missed in a burst loss (even
of 2 packets).

For example consider an application that offers and agrees to G.722.1 and
G.711 (it doesn't matter if this particular set is smart), and switches
between them based on apparent bandwidth or even based on the apparent
audio content (G.711 in quiet/silence periods, G.722.1 in
noisy/speaking/music).  You might see multiple shifts within an even fairly
short burst loss, and twice in 2 packets at the extreme.

The base problem is that timestamp in an RTP packet is both a presentation
time, and a sample time, and the rate isn't fixed (per the SDP above).
RTCP indicates current timestamp and current time, but says nothing
(directly) about rate.

It probably would have made more sense if (long ago), the timestamp rate
had been set on the media line, with a suggestion that something like the
smallest value that can (sufficiently) accurately encode the presentation
time be selected.  (Example: for 8000 and 16000, choose 16000.  For 7000
and 8000, you might need to choose 56000.)  In some cases, a rate that's
not an exact multiple of the sample rate might need to be used, to avoid
needing to use a Very Large timestamp rate.

So - What *should* an application do?  Full reset on codec rate shift,
which may imply a short gap in playout, but may let you ignore packet loss?
What about 2833/etc?  Only allow codecs with identical timestamp rates on a
single media line?  (Causes all sorts of problems if someone wants to use
(for example) G.722).

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 19 Jun 2007 10:38:44 +0200

> Ok: what's the timestamp rate?  :-)  And when can it change?

For this case to have a chance to work you need three telephone-event 
lines like this:
  a=rtpmap:101 telephone-event/8000
  a=rtpmap:102 telephone-event/16000
  a=rtpmap:103 telephone-event/32000

So that the packets sent is sent at the same timestamp rate as used by 
the main codec.

> single media line?  (Causes all sorts of problems if someone wants to use

I agree that timestamp rate switching is problematic. And if you have 
the sampling rate switching capability integrated into the codec, then I 
would recommend that you actually use the highest sample rate as RTP 
timestamp rate and ensure that it always provide integer timestamp ticks 
per frame. But for 8, 16 and 32k that is not an issue. Then you include 
a separate parameter to negotiate which sampling rates that really are 
allowed. But if the case really is that you anyway is reseting the codec 
between sample rate switching I think using the timestamp rate would be 
more correct.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Aymeric Moizard <[email-masked]>
Date: Tue, 19 Jun 2007 10:45:41 +0200 (CEST)

> audio codecs causes some real problems with certain cases.

I understand your point, but I don't think the speex draft can solve this!
right?

---

From: Aymeric Moizard <[email-masked]>
Date: Tue, 19 Jun 2007 11:15:37 +0200 (CEST)

There is an issue with section:
"	4.1.1. Registration of media type audio/speex"

First, the mode parameter text is defined using the same text as for the 
SDP usage text: It sounds clear to me that in case "mode" is used as a
media parameter, it cannot be possible to specify several "mode".

Although, I don't know much about media type.

Thus, I think we have to keep the definition of mode in the SDP
usage section.

Because cng has also dissapeared from section SDP usage, we should
add an example (or complete the existing ones) so that at least one
SDP example include the cvg parameter.

tks,

---

From: Colin Perkins <[email-masked]>
Date: Tue, 19 Jun 2007 10:51:12 +0100

On 19 Jun 2007, at 10:15, Aymeric Moizard wrote:
> First, the mode parameter text is defined using the same text as  
> for the SDP usage text: It sounds clear to me that in case "mode"  
> is used as a

There shouldn't be any parameter definitions in the SDP usage  
section. That section is only used to specify how the media type  
parameters are represented in SDP.

-- 
Colin Perkins
http://csperkins.org/

---

From: Randell Jesup <[email-masked]>
Date: Wed, 20 Jun 2007 02:39:23 -0400

Magnus Westerlund <[email-masked]> writes:

>> audio codecs causes some real problems with certain cases.  Switching
>> (in-call) between codecs with different sample rates -
>For this case to have a chance to work you need three telephone-event lines
>like this:
>So that the packets sent is sent at the same timestamp rate as used by the
>main codec.

So long as none of the events span a timestamp rate change...

I have a strong suspicion that including the above is likely to cause
compatibility problems in practice (in addition to being lengthy, plus the
related fmtp lines, and so adding to the overall SIP/UDP problem).

Perhaps the real issue here comes down to a media stream is really a form
of multiplexed channel.  Some payload "switches" are real switches, others
are just passing additional streams of related data (like 2833 DTMF data).
There are no limits on when payloads can switch, or on overlap between
different payloads.  You *could* create a stream with 10 G.711 payloads,
with all 10 arriving at all times, and each one being a different language.
This might even be useful for RTSP, IPTV, etc.

Now in practice devices won't overlap or even switch often, at least for
VoIP devices, with rare exceptions like 2833.  Switches are usually to
respond to network (or processor) impairments, quality, etc.  The probably
works moderately well today in narrowband VoIP devices.  Mixing wideband
(G.722/etc) into the mix really does confuse things if the device doesn't
pick one at call setup and stick with it (or others of the same timestamp
rate).

Either we need to provide guidance on how to handle timestamp shifts, or
we need to move away from them (tough), or we need to move away from
timestamp rate == sample rate.  (Tough, but will help us in the long run.)

>I agree that timestamp rate switching is problematic. And if you have the
>sampling rate switching capability integrated into the codec, then I would
>recommend that you actually use the highest sample rate as RTP timestamp
>rate and ensure that it always provide integer timestamp ticks per
>frame. But for 8, 16 and 32k that is not an issue. Then you include a
>separate parameter to negotiate which sampling rates that really are

You can only use the "highest" timestamp rate if the RFC for that encoding
allows it.  As an example, the Speex draft that started this does not allow
that.

Note: by "codec rate shift" I was planning to refer to the general case of
"shift from codec with sample rate N to codec with sample rate M", whether
the two codecs are the same or not.  For example, G.711 to G.722.1.

Full reset is something to avoid if possible, since users of VoIP want to
switch codecs on the fly in mid-call based on network conditions, etc.  You
want to be able to (fairly) seamlessly have a call be G.711 up to 1999ms,
and G.722.1 starting at 2000ms, if possible, and play with little or no gap
or artifacts.  The user might have just pressed a DTMF button before this
happened, and still be holding it down.

---

From: Colin Perkins <[email-masked]>
Date: Thu, 21 Jun 2007 11:04:08 +0100

> parameters are represented in SDP.

Having now had time to read the draft in detail, what's needed is  
something like:

    The information carried in the media type specification has a
    specific mapping to fields in the Session Description Protocol (SDP)
    [5], which is commonly used to describe RTP sessions.  When SDP is
    used to specify sessions employing the Speex codec, the mapping is
    as follows:

    o  The media type ("audio") goes in SDP "m=" as the media name.

    o  The media subtype ("speex") goes in SDP "a=rtpmap" as the  
encoding
       name. The required parameter "rate" also goes in "a=rtpmap" as  
the
       clock rate.

    o  The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and
       "a=maxptime" attributes, respectively.

    o  Any remaining parameters go in the SDP "a=fmtp" attribute by
       copying them directly from the media type string as a semicolon
       separated list of parameter=value pairs.

    Some example SDP session descriptions utilizing Speex encodings
    follow.

To replace much of the existing text in the first half of Section 5.  
The rationale is that all parameters are defined as parameters of the  
media type, and the SDP usage just describes how those media type  
parameters are encoded into SDP.

-- 
Colin Perkins
http://csperkins.org/

---

From: Aymeric Moizard <[email-masked]>
Date: Thu, 21 Jun 2007 13:15:40 +0200 (CEST)

On Thu, 21 Jun 2007, Colin Perkins wrote:

>> There shouldn't be any parameter definitions in the SDP usage section. That 
>> section is only used to specify how the media type parameters are 
>> represented in SDP.

The text you proposed seems fine to me: However, there is one point where
you could probably help again.

Is it acceptable for section defining media type and parameters that
"mode" parameter can be specified several times? I wanted this to
be possible for SDP usage but I'm not sure it is authorized to allow
multiple "mode" to appear in section 4.1.1.

tks,
Aymeric

> Having now had time to read the draft in detail, what's needed is something 
> like:
>
>  o  The media subtype ("speex") goes in SDP "a=rtpmap" as the encoding
>     name. The required parameter "rate" also goes in "a=rtpmap" as the
>     clock rate.
>
> To replace much of the existing text in the first half of Section 5. The 
> rationale is that all parameters are defined as parameters of the media type, 
> and the SDP usage just describes how those media type parameters are encoded 
> into SDP.
>
> -- 
> Colin Perkins
> http://csperkins.org/
>

---

From: Colin Perkins <[email-masked]>
Date: Thu, 21 Jun 2007 12:23:39 +0100

> multiple "mode" to appear in section 4.1.1.

I'm not sure why you'd want to include multiple mode parameters, each  
containing a single list. Why not define a single mode parameter,  
supporting multiple lists of modes?

Colin

---

From: Aymeric Moizard <[email-masked]>
Date: Thu, 21 Jun 2007 14:39:31 +0200 (CEST)

On Thu, 21 Jun 2007, Colin Perkins wrote:

>>>> There shouldn't be any parameter definitions in the SDP usage section. 
>>>> That section is only used to specify how the media type parameters are 
>>>> represented in SDP.
>> 
> containing a single list.

Each mode only contains ONE value. This is what should be understood
from the draft.

> Why not define a single mode parameter, supporting multiple lists of 
> modes?

I find it easier to have several "mode=X;mode=Y" rather than a "mode=X|Y".

What only question is about the meaning of "mode=X;mode=Y" -> It's usefull
for SDP usage (some speex implementation will support only mode X and Y), 
For media type registration? I don't know what could be the meaning: I'm
only a SDP offer/answer user and have no knowledge on media type use.

Aymeric

---

From: Colin Perkins <[email-masked]>
Date: Sun, 24 Jun 2007 19:58:56 +0100

On 21 Jun 2007, at 13:39, Aymeric Moizard wrote:
>>>>> section. That section is only used to specify how the media  
>>>>> type parameters are represented in SDP.
>> I'm not sure why you'd want to include multiple mode parameters,  
>> each containing a single list.
>
>> Why not define a single mode parameter, supporting multiple lists  
>> of modes?
>

The former is generally easier to specify, and understand, in the  
ABNF, so I'd recommend that, rather than duplicating the parameter.

-- 
Colin Perkins
http://csperkins.org/