[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Comment on M bit below.

At 11:05 AM 7/9/2003 +0200, Colin Perkins wrote:

--> 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).
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: mramalho@cisco.com
Personal email: mar42@cornell.edu
Office: +1.941.708.4650
Cell: +1.941.544.2844


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