Subject: [AVT] Re: I-D ACTION:draft-herlein-speex-rtp-profile-02.txt

From: Colin Perkins <[email-masked]>
Date: Tue, 12 Apr 2005 18:03:23 +0100

Greg, [cc IETF AVT mailing list]

On 5 Apr 2005, at 20:31, [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts  
> directories.
>
>
> 	Title		: RTP Payload Format for the Speex Codec
> 	Author(s)	: G. Herlein, et al.
> 	Filename	: draft-herlein-speex-rtp-profile-02.txt
> 	Pages		: 15
> 	Date		: 2005-4-5
> 	
> Speex is an open-source, patent-free, 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) and a preliminary method
> of using Speex within H.323 applications.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-herlein-speex-rtp-profile 
> -02.txt

I have a few comments on this draft (see below). In general, I think  
it's a reasonable payload format, and would be appropriate as an AVT  
work item for eventual publication as a proposed standard RFC. If there  
are no objections from the group, I suggest you submit an update with  
filename draft-ietf-avt-rtp-speex-00.txt.

The description of use of the P bit in the RTP header notes that "P is  
set if the total packet size is less than the MTU". This makes it sound  
like P is always set when the packet is smaller than the MTU, whereas  
padding is actually very unusual. I suggest you remove that sentence,  
since the rest of the paragraph is sufficient without.

The use of the M bit in the RTP header to indicate comfort noise is  
unusual. Can you comment why it was used in this way, rather than being  
used to indicate the first packet after the "silence" period, as would  
be typical? The unusual semantics are not necessarily problematic, but  
we I'd like to understand what benefit we gain from the additional  
complexity of atypical usage.

Finally, I don't think it's appropriate for this draft to define how to  
use H.323/H.245 with Speex (since the ITU owns those protocols, not the  
IETF). Is it possible to remove sections 10-12 from future versions,  
replacing them with a reference to an external document (perhaps on the  
speex.org website)?

Colin

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

---

From: Phil Kerr <[email-masked]>
Date: Thu, 14 Apr 2005 23:03:53 +0100

Hi Colin,

Thanks for the feedback, comments in-line.

Colin Perkins wrote:

> work item for eventual publication as a proposed standard RFC. If 
> there  are no objections from the group, I suggest you submit an 
> update with  filename draft-ietf-avt-rtp-speex-00.txt.

Thanks for this.

>
> The description of use of the P bit in the RTP header notes that "P 
> is  set if the total packet size is less than the MTU". This makes it 
> sound  like P is always set when the packet is smaller than the MTU, 
> whereas  padding is actually very unusual. I suggest you remove that 
> sentence,  since the rest of the paragraph is sufficient without.

Will be fixed in the next update.

> unusual. Can you comment why it was used in this way, rather than 
> being  used to indicate the first packet after the "silence" period, 
> as would  be typical? The unusual semantics are not necessarily 
> problematic, but  we I'd like to understand what benefit we gain from 
> the additional  complexity of atypical usage.

We need to discuss if this is the best way to handle comfort noise, or 
should we switch to the standard RTP spec.

>
> Finally, I don't think it's appropriate for this draft to define how 
> to  use H.323/H.245 with Speex (since the ITU owns those protocols, 
> not the  IETF). Is it possible to remove sections 10-12 from future 
> versions,  replacing them with a reference to an external document 
> (perhaps on the  speex.org website)?

Yes, this should be easy to do.

Cheers

Phil