Subject: [payload] registeration of G7110 media subtype for G.711.0 payload

From: "Roni Even" <[email-masked]>
Date: Tue, 4 Mar 2014 16:18:32 +0200

Hi,

draft-ietf-payload-g7110-02
<http://tools.ietf.org/html/draft-ietf-payload-g7110-02>  has passed Working
Group Last Call in the Payload Working Group. 
The document registers media subtype G7110.  
 
The new registrations are in Section 5.1 of the document and is also given
bellow.

Comments on the registration are welcome.

Thanks

Roni Even

Payload WG co-chair

 

Media Type Registration

   Type name: audio

   Subtype name: G7110

   Required parameters:

      rate: The RTP timestamp clock rate, which is equal to the sampling

      rate.  The typical rate used with G.711 encoding is 8000, but

      other rates may be specified.  The default rate is 8000.

      complaw: Indicates the companding law (A-law or mu-law) employed.

      The case-insensitive values are "al" or "mu" for A-law and mu-law,

      respectively.

   Optional parameters:

      channels: See RFC 4566 [RFC4566] for definition.  Specifies how

      many audio streams are represented in the G.711.0 payload and MUST

      be present if the number of channels is greater than one.  This

      parameter defaults to 1 if not present (as per RFC 4566) and is

      typically a non-zero small-valued positive integer.  It is

      expected that implementations that specify multiple channels will

      also define a mechanism to map the channels appropriately within

      their system design, otherwise the channel order specified in RFC

      3551 [RFC3551] Section 4.1 will be assumed (e.g., left, right,

      center, ... ).

      maxptime: See RFC 4566 [RFC4566] for definition.

      ptime: See RFC 4566 [RFC4566] for definition.  The inclusion of

      "ptime" is RECOMMENDED and SHOULD be in the SDP unless there is an

      application specific reason not to include it (e.g., an

      application that has a variable ptime on a packet-by-packet

      basis).  For constant ptime applications, it is considered good

      form to include "ptime" in the SDP for session diagnostic

      purposes.  For the constant ptime multiple channel case described

      in Section 4.2.2, the inclusion of "ptime" can provide a desirable

      payload check.

   Encoding considerations:

      This media type is framed binary data (see Section 4.8 in RFC 6838

      [RFC6838]) compressed as per ITU-T Rec. G.711.0.

   Security considerations:

      See Section 10.

   Interoperability considerations: none

   Published specification:

      ITU-T Rec. G.711.0 and RFC XXXX.

      [ RFC Editor: please replace XXXXX with a reference to this RFC ]

   Applications that use this media type:

      Although initially conceived for VoIP, the use of G.711.0, like

      G.711 before it, may find use within audio and video streaming and

      /or conferencing applications for the audio portion of those

      applications.

   Additional information:

   The following applies to stored-file transfer methods:

         Magic numbers: #!G7110A\n or #!G7110M\n (for A-law or MU-law

         encodings respectively, see Section 6).

        File Extensions: None

         Macintosh file type code: None

         Object identifier or OIL: None

   Person & email address to contact for further information:

      Michael A. Ramalho <[email-masked]> or <[email-masked]>

   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: Michael A. Ramalho

   Change controller:

      IETF Payload working group delegated from the IESG.