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

[Colin Perkins <csp@csperkins.org>]

--> philkerr@elec.gla.ac.uk 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.

- 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
csp@csperkins.org

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt