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

[[e-mail]]

Hi Colin,

Thanks for the feedback, comments in-line:


Quoting Colin Perkins <[e-mail]>:

> --> [e-mail] writes:
> > 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.
> 
> 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.

Submitting an IPR statement should be no problem.

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

Agreed.  This section can be expanded.

> 
> - 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?

Changing the Padding bit to MAY should be fine.

> 
> - 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).

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.

> 
> - 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?

There is a fixed range of values for the sample rate but the rate may change mid
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?

I will need to check this just to make sure.

> 
> - 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).

This can be made clearer.

> 
> - 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 text can be amended as suggested.

> 
> - 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.

Agreed, this will be changed.

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

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

> 
> - 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.

Agreed, this section will be split into two.

> 
> - 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.

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.

> 
> - 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.

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

> 
> - 
> Colin Perkins
> [e-mail]
> 

Thanks

Phil


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

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