Review requested: audio/G7221

[Tom Taylor]

Please review the following registration, which updates the existing audio/G7221 
registration provided by RFC 3047. The source documentation is 
draft-ietf-avt-rfc3047-bis-08.txt, which has passed AVT Working Group Last Call. 
(Big OOPS! for not invoking media type review at the same time.)

Tom Taylor, AVT Co-Chair

=============================================

Registration of media type audio/G7221

    Media type name: audio

    Media subtype name: G7221

    Required parameters:

       bitrate: the data rate for the audio bit stream.  This parameter
       is mandatory because the bit rate is not signaled within the
       G.722.1 bit stream.  At the standard G.722.1 bit rates, the value
       MUST be either 24000 or 32000 at 16 Khz sample rate, and 24000,
       32000 or 48000 at 32 Khz sample rate.  If using the non-standard
       bit rates, then it is RECOMMENDED that values in the range 16000
       to 48000 be used.  Non standard rates MUST have a value that is a
       multiple of 400 (this maintains octet alignment and does not then
       require (undefined) padding bits for each frame if not octet
       aligned).

    Optional parameters:

       rate: RTP timestamp clock rate, which is equal to the sampling
       rate.  If the parameter is not specified a clock rate of 16 Khz is
       assumed.

       ptime: see RFC 4566.  SHOULD be a multiple of 20 msec.

       maxptime: see RFC 4566.  SHOULD be a multiple of 20 msec.

    Encoding considerations:

       This media type is framed and binary, see section 4.8 in
       [RFC4288].

    Security considerations: See Section 6 [Quoted at the end of this note -- PTT]

    Interoperability considerations:

       Terminals SHOULD offer a media type at 16 Khz sample rate in order
       to interoperate with terminals that do not support the new 32 Khz
       sample rate.

    Published specification: RFC yyy [see RFCeditor notes].

    Applications which use this media type:

       Audio and Video streaming and conferencing applications.

    Additional information: none

    Person and email address to contact for further information :

       Roni Even: ron.even.tlv at gmail.com

    Intended usage: COMMON

    Restrictions on usage:

       This media type depends on RTP framing, and hence is only defined
       for transfer via RTP [RFC3550].  Transport within other framing
       protocols is not defined at this time.

    Author: Roni Even

    Change controller:

       IETF Audio/Video Transport working group delegated from the IESG.

=============================

6.  Security Considerations

    RTP packets using the payload format defined in this specification
    are subject to the security considerations discussed in the RTP
    specification [RFC3550], and any appropriate RTP profile.  This
    implies that confidentiality of the media streams is achieved by
    encryption.

    A potential denial-of-service threat exists for data encoding using
    compression techniques that have non-uniform receiver-end
    computational load.  The attacker can inject pathological datagrams
    into the stream which are complex to decode and cause the receiver to
    be overloaded.  However, this encoding does not exhibit any
    significant non-uniformity.