Subject: [AVT] draft-herlein-speex-rtp-profile-01

From: [email-masked]
Date: Wed, 2 Jul 2003 20:43:39 +0100

Dear all,

An -01 update to draft-herlein-speex-rtp-profile is now available:

http://www.ietf.org/internet-drafts/draft-herlein-speex-rtp-profile-01.txt

Comments and feedback welcomed.

Regards

Phil

-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Colin Perkins <[email-masked]>
Date: Thu, 3 Jul 2003 11:21:26 +0200

> Comments and feedback welcomed.

Can you summarize the changes from the previous version, and areas where
input is needed?

-- 
Colin Perkins
[email-masked]

---

From: [email-masked]
Date: Fri, 4 Jul 2003 09:53:34 +0100

Colin / all, 

Sorry for missing this information out.

Changes in the -01 draft.

Expanded RTP header section detailing bitfield usage particularly the M bit at
the suggestion of Henning Schulzrinne.

Expanded payload section detailing frame packing and fragmentation handling at
the suggestion of Federico Montesino Pouzols.

Expanded example packet section detailing single Speex frame with padding and
multiple Speex frame packing at the suggestion of Magnus Westerlund and Ross
Finlayson.

MIME type section expanded to clarify usage scenario of audio/speex.

General text changes to improve clarity.

Open issues:

Maximum path-MTU discovery to prevent fragmentation.

I've booked a slot in Vienna for the Speex I-D, as well as the Vorbis RTP draft.

Regards

Phil

---

From: Colin Perkins <[email-masked]>
Date: Wed, 9 Jul 2003 11:05:22 +0200

> Comments and feedback welcomed.

I have a number of questions and comments:

- It's not appropriate for the draft to claim that the Speex codec is free
  from patents and/or royalties.  If you wish to make an IPR statement, it
  should be separately submitted to the IESG Secretary for inclusion on the
  IPR-claims page the IETF maintains. See also section 10 of RFC 2026.

- The draft would benefit from a little more introduction to Speex at the
  beginning.

- The definition of the Padding bit in the RTP header is unusual. It may be
  better to state that padding MAY be used in the usual RTP manner, unless
  there is a specific reason why a different padding scheme is needed?

- The use of the M bit in the RTP header to signify comfort noise is also
  unusual. This is not necessarily inappropriate, but it is important to
  consider if the advantages of this use outweigh the costs of being
  different to other audio payload formats (which use the M bit to signal
  the first packet after a silent period).

- The definition of the timestamp says "Speex uses 20 msec frames and a
  variable sampling rate clock". Does this mean that the sample rate can
  change at anytime within a session? Or is the sample rate chosen from
  one of a number of values, and then fixed within the session?

- Section 3.2 is unclear if the bit rate and sample rate are coupled. Can
  Speex vary the compression ratio to change the bit rate without changing
  the sampling rate?

- In Section 3.2, it is important to be clear that the padding needed to
  ensure that the payload is octet aligned is independent of the padding
  at the RTP level (i.e. the P bit in the RTP header).

- The examples in Section 3.3 and 3.4 might be clearer if they show the
  actual length of the Speex data frames. An example showing two Speex
  frames in an RTP packet, with the first Speex frame being non-octet
  aligned, would be useful (to make it clear how to handle padding in
  this case).

- Section 4 "MIME registration of Speex" should be renamed to "IANA 
  considerations", and needs an introductory sentence saying something 
  like "The following MIME type and associated RTP payload format are 
  to be registered".

- The usual way in which a MIME type is registered only for particular
  use is to define the use in the "Encoding considerations" section of
  the MIME registration form. In this case, you might say something like:

        This type is defined only for transfer within RTP as specified in
        Section 4 of RFC XXXX. For file storage, or for transmission over
        lossless channels (such as TCP), Speex data is transported within
        an Ogg bitstream [RFC 3534].

  This would replace the introductory sentence and last paragraph of the
  current section 4. If there is a need to register parameters of the Ogg
  bitstream, that should be done as a separate subsection under section 4.

- The "a=fmtp:" parameters from Section 5 should be defined in Section 4,
  as Optional Parameters to the audio/speex type, and section 5 should be
  an explanation of how the parameters are mapped onto SDP.

- The "ebw" parameter may be redundant, since the clock rate is signalled
  in the "a=rtpmap:" line?

- It may be clearer to separate out the explanation of how parameters are
  mapped to SDP from the description of how the SDP is used with the offer/
  answer model (as two subsections). There are uses of SDP that don't use
  offer/answer.

- Section 6 (use with H.323) is not appropriate in an IETF document. You
  can include a reference to an ITU - or other - document explaining how
  to use Speex with H.323, but the IETF can't mandate use of H.245
  parameters.

- Section 10: RFCs are published using strict US ASCII. If there is an
  acceptable transliteration of the non-ASCII characters in Jean-Marc
  Valin's address, it will save a "discussion" with the RFC Editor. See
  draft-rfc-editor-rfc2223bis-06.txt.

- 
Colin Perkins
[email-masked]

---

From: "Michael A. Ramalho" <[email-masked]>
Date: Wed, 09 Jul 2003 15:16:55 -0400

Comment on M bit below.

>   the first packet after a silent period).

Colin,

This may be contrary to the guidance I got from Steve a while back.

A little background first ..

 From RFC 1889:

"marker (M): 1 bit The interpretation of the marker is defined by a 
profile. It
is intended to allow significant events such as frame boundaries to be marked
in the packet stream. A profile may define additional marker bits or specify
that there is no marker bit by changing the number of bits in the payload type
field (see Section 5.3)."

But from RFC 1890 (Audio and Video Conferences with Minimal Control
that can be used with G.711):

"For applications which send no packets during silence, the first packet of
a talk spurt (first packet after a silence period) is distinguished by setting
the marker bit in the RTP data header. Applications without silence
suppression set the bit to zero."

Then Steve said on 2/2/2003 (in regards to the RGL codec) ...

"I believe you should follow the marker bit convention as specified in
RFC 1890. The RGL codec is likely to be used in implementations that
also use other payload formats (such as PCMU) specified in RFC 1890,
and the behavior should be consistent."

Thus, since I think that speex will also be used in similar
deployments (i.e., packet voice) ... I would think Steve's
guidance should apply here as well.

My question to the speex authors is that if they simply define
the periods in which they desire to send comfort noise to be
*identically* the same definition as a RFC 1890 "beginning or
ending of a talk spurt", then there would be no inconsistency
in the bit's meaning.

My $0.02,

Michael Ramalho

Michael A. Ramalho, Ph.D.
Office email: [email-masked]
Personal email: [email-masked]
Office: +1.941.708.4650
Cell: +1.941.544.2844

---

From: [email-masked]
Date: Wed, 9 Jul 2003 23:57:16 +0100

Hi Colin,

Thanks for the feedback, comments in-line:

>   IPR-claims page the IETF maintains. See also section 10 of RFC 2026.

Submitting an IPR statement should be no problem.

> - The draft would benefit from a little more introduction to Speex at the

Agreed.  This section can be expanded.

>   there is a specific reason why a different padding scheme is needed?

Changing the Padding bit to MAY should be fine.

>   the first packet after a silent period).

Its use was suggested by Henning Schulzrinne to the other Speex draft authors
and I've based it on their notes and Section 4.1 of RFC 1890.  If there is some
discrepency in its use, as highlighted in the feedback by  Michael Ramalho, then
we may need to look at this section again to determine best practice.

>   one of a number of values, and then fixed within the session?

There is a fixed range of values for the sample rate but the rate may change mid
session.  

>   Speex vary the compression ratio to change the bit rate without changing

I will need to check this just to make sure.

>   at the RTP level (i.e. the P bit in the RTP header).

This can be made clearer.

>   bitstream, that should be done as a separate subsection under section 4.

The text can be amended as suggested.

>   an explanation of how the parameters are mapped onto SDP.

Agreed, this will be changed.

> - The "ebw" parameter may be redundant, since the clock rate is signalled

I'll need to check this, but if it is redundant it can be removed.

>   answer model (as two subsections). There are uses of SDP that don't use

Agreed, this section will be split into two.

>   to use Speex with H.323, but the IETF can't mandate use of H.245

Agreed.  I presume we can also link back to a Speex document if further
explanation is required, with the usual proviso about linking to URLs as
mentioned in the ID-nits.

>   draft-rfc-editor-rfc2223bis-06.txt.

I will check with Jean-Marc to see if his address can be written in US ASCII.

> [email-masked]

Thanks

Phil

---

From: Colin Perkins <[email-masked]>
Date: Fri, 11 Jul 2003 21:57:19 +0200

Michael,

--> "Michael A. Ramalho" <[email-masked]> writes:
>--> Colin Perkins writes:
>>   unusual. This is not necessarily inappropriate, but it is important
>>   to consider if the advantages of this use outweigh the costs of being
>>   different to other audio payload formats (which use the M bit to
>>   signal the first packet after a silent period).
> 
> is intended to allow significant events such as frame boundaries to be
> marked in the packet stream. A profile may define additional marker bits
> or specify that there is no marker bit by changing the number of bits in
> the payload type field (see Section 5.3)."
> 
> "For applications which send no packets during silence, the first packet
> of a talk spurt (first packet after a silence period) is distinguished by
> setting the marker bit in the RTP data header. Applications without
> silence suppression set the bit to zero."
> 

I'm not sure I understand your suggestion. I was expecting a period of
comfort noise to be treated identically to a silent period.  Hence the
M bit would be set on the first packet after the comfort noise (and not
set on any of the comfort noise packet).

-- 
Colin Perkins
[email-masked]

---

From: Colin Perkins <[email-masked]>
Date: Fri, 11 Jul 2003 22:20:03 +0200

Hi,

...
> > I have a number of questions and comments:
...
> > - The definition of the Padding bit in the RTP header is unusual. It
> >   may be better to state that padding MAY be used in the usual RTP
> >   manner, unless there is a specific reason why a different padding
> >   scheme is needed?
> 

The main issue is the text "P is set if the total packet size is less than
the MTU" which implies that padding is used to bring the packet size up to
the MTU. I'm assuming that is not intended!

> Its use was suggested by Henning Schulzrinne to the other Speex draft
> authors and I've based it on their notes and Section 4.1 of RFC 1890.  If
> there is some discrepency in its use, as highlighted in the feedback by 
> Michael Ramalho, then we may need to look at this section again to
> determine best practice.

Does my reply to Michael clarify?

> >   variable sampling rate clock". Does this mean that the sample rate
> >   can change at anytime within a session? Or is the sample rate chosen
> >   from one of a number of values, and then fixed within the session?
> 
> There is a fixed range of values for the sample rate but the rate may
> change mid session.  

It's easier from the point of view of RTP and signalling in SDP if each
different sample rate is sent using a different payload type number. In
SDP, something like:

	m=audio 49170 RTP/AVP 97 98
	a=rtpmap:97 speex/8000
	a=rtpmap:98 speex/16000

Might be useful to make this mandatory in the draft?

> >   Speex vary the compression ratio to change the bit rate without
> >   changing the sampling rate?
> 
...
> >   can include a reference to an ITU - or other - document explaining
> >   how to use Speex with H.323, but the IETF can't mandate use of H.245
> >   parameters.
> 

Correct. How is Speex itself being referenced?

Cheers,
-- 
Colin Perkins
[email-masked]

---

From: [email-masked]
Date: Fri, 11 Jul 2003 21:54:40 +0100

Thanks Colin,

> the MTU. I'm assuming that is not intended!

It was, but can be changed so it is not intended.

> Does my reply to Michael clarify?

Yes.

> Might be useful to make this mandatory in the draft?

Agreed.

> Correct. How is Speex itself being referenced?

A reference needs to be added pointing back to the website.

Cheers

Phil