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