Subject: [avtext] WGLC comments on draft-ietf-avtext-mixer-to-client-audio-level-03

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 19 Jul 2011 23:59:40 +0200

No technical issues identifies. These are editorial.

1)	Section 3:

   According to RFC 3550 [RFC3550] a mixer is expected to include in
   outgoing RTP packets a list of identifiers (CSRC IDs) indicating the
   sources that contributed to the resulting stream.  The presence of
   such CSRC IDs allows RTP clients to determine, in a binary way, the
   active speaker(s) in any given moment.  RTCP also provides a basic
   mechanism to map the CSRC IDs to user identities through the CNAME
   field.  More advanced mechanisms, may exist depending on the
   signaling protocol used to establish and control a conference.  In
   the case of the Session Initiation Protocol [RFC3261] for example,
   the Event Package for Conference State [RFC4575] defines a <src-id>
   tag which binds CSRC IDs to media streams and SIP URIs.

Change "may" to "can" to avoid using RFC 2119 language.

   According to RFC 3550 [RFC3550] a mixer is expected to include in
   outgoing RTP packets a list of identifiers (CSRC IDs) indicating the
   sources that contributed to the resulting stream.  The presence of
   such CSRC IDs allows RTP clients to determine, in a binary way, the
   active speaker(s) in any given moment.  RTCP also provides a basic
   mechanism to map the CSRC IDs to user identities through the CNAME
   field.  More advanced mechanisms, can exist depending on the
   signaling protocol used to establish and control a conference.  In
   the case of the Session Initiation Protocol [RFC3261] for example,
   the Event Package for Conference State [RFC4575] defines a <src-id>
   tag which binds CSRC IDs to media streams and SIP URIs.

2)	Section 3:

   It may sometimes happen that a conference involves more than a single
   mixer.  In such cases each of the mixers MAY choose to relay the CSRC
   list and audio-level information they receive from peer mixers (as
   long as the total CSRC count remains below 16).  Given that the
   maximum audio level is not precisely defined by this specification,
   it is likely that in such situations average audio levels would be
   perceptibly different for the participants located behind the
   different mixers.

Change "may" to "can" to avoid using RFC 2119 language.

   It can sometimes happen that a conference involves more than a single
   mixer.  In such cases each of the mixers MAY choose to relay the CSRC
   list and audio-level information they receive from peer mixers (as
   long as the total CSRC count remains below 16).  Given that the
   maximum audio level is not precisely defined by this specification,
   it is likely that in such situations average audio levels would be
   perceptibly different for the participants located behind the
   different mixers.

3)	Section 4

   Audio levels in this document are defined in the same manner as is
   audio noise level in the RTP Payload Comfort  Noise specification
   [RFC3389].  In the comfort noice specification, the overall magnitude
   of the noise level in comfort noise is encoded into the first byte of
   the payload, with spectral information about the noise in subsequent
   bytes.  This specification's audio level parameter is defined so as
   to be identical to the comfort noise payload's noise-level byte.

Typo "noice" --> "noise"

4)	Section 8

Presumably "dispatch" --> "avt" or "avtext".

5)	Section A.1

"singal" --> "single"

6)	Section A.1

     * @param overload the overload (point) of <tt>signal</tt>.
     * For example, <tt>overload</tt> may be {@link Byte#MAX_VALUE}
     * for 8-bit signed samples or {@link Short#MAX_VALUE} for
     * 16-bit signed samples.
     *

Change "may" to "can" to avoid using RFC 2119 language.

     * @param overload the overload (point) of <tt>signal</tt>.
     * For example, <tt>overload</tt> can be {@link Byte#MAX_VALUE}
     * for 8-bit signed samples or {@link Short#MAX_VALUE} for
     * 16-bit signed samples.
     *

Regards

Keith