[ietf-types] registeration of audio EVRCNW, EVRCNW0 and EVRCNW1 media subtype

Roni even <Even.roni@huawei.com> Mon, 26 December 2011 08:09 UTC

Return-Path: <Even.roni@huawei.com>
X-Original-To: ietf-types@ietfa.amsl.com
Delivered-To: ietf-types@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FAB621F8ABD for <ietf-types@ietfa.amsl.com>; Mon, 26 Dec 2011 00:09:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.467
X-Spam-Level:
X-Spam-Status: No, score=-106.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_UNSUB18=0.131, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqAtb+WCd+3o for <ietf-types@ietfa.amsl.com>; Mon, 26 Dec 2011 00:09:03 -0800 (PST)
Received: from pechora1.lax.icann.org (unknown [IPv6:2620:0:2d0:201::1:71]) by ietfa.amsl.com (Postfix) with ESMTP id E728621F8ABB for <ietf-types@ietf.org>; Mon, 26 Dec 2011 00:09:02 -0800 (PST)
Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by pechora1.lax.icann.org (8.13.8/8.13.8) with ESMTP id pBQ88f2L015594 for <ietf-types@iana.org>; Mon, 26 Dec 2011 00:09:02 -0800
Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWS00AN6W503E@szxga05-in.huawei.com> for ietf-types@iana.org; Mon, 26 Dec 2011 15:43:48 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWS003QLW4OQI@szxga05-in.huawei.com> for ietf-types@iana.org; Mon, 26 Dec 2011 15:43:48 +0800 (CST)
Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGA30390; Mon, 26 Dec 2011 15:43:47 +0800
Received: from SZXEML424-HUB.china.huawei.com (10.82.67.163) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 26 Dec 2011 15:43:46 +0800
Received: from SZXEML519-MBS.china.huawei.com ([169.254.7.136]) by szxeml424-hub.china.huawei.com ([10.82.67.163]) with mapi id 14.01.0323.003; Mon, 26 Dec 2011 15:43:45 +0800
Date: Mon, 26 Dec 2011 07:43:44 +0000
From: Roni even <Even.roni@huawei.com>
X-Originating-IP: [172.24.1.70]
To: "ietf-types@iana.org" <ietf-types@iana.org>
Message-id: <EADCEEE0AE4A7F46BD61061696794D98F9188F@SZXEML519-MBS.china.huawei.com>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_+5GtDk5n2qAP/ytvKf850A)"
Content-language: en-US
Accept-Language: en-US, zh-CN
Thread-topic: registeration of audio EVRCNW, EVRCNW0 and EVRCNW1 media subtype
Thread-index: AQHMw6IYFHGBhQEdbUK2ukl7vCSsKg==
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
X-CFilter-Loop: Reflected
X-Greylist: Delayed for 00:24:24 by milter-greylist-4.0 (pechora1.lax.icann.org [192.0.33.71]); Mon, 26 Dec 2011 08:09:02 +0000 (UTC)
Cc: "payload@ietf.org" <payload@ietf.org>
Subject: [ietf-types] registeration of audio EVRCNW, EVRCNW0 and EVRCNW1 media subtype
X-BeenThere: ietf-types@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Media \(MIME\) type review" <ietf-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-types>, <mailto:ietf-types-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-types>
List-Post: <mailto:ietf-types@ietf.org>
List-Help: <mailto:ietf-types-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-types>, <mailto:ietf-types-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Dec 2011 08:09:04 -0000

Hi,


draft-ietf-avt-rtp-evrc-nw-05 has passed Working Group Last Call in the Payload Working Group.





The new registrations are in Section 3.1 of the document. http://tools.ietf.org/html/draft-ietf-avt-rtp-evrc-nw-05#section-9.1


The information is also available below.




Comments on the registration are welcome.

Roni Even
Payload co-chair


This document introduces a new EVRC-NW 'audio' media subtypes.

9.1.  Media Type Registrations
   Following the guidelines in RFC 4855 [8] and RFC 4288 [9], this
   section registers new 'audio' media subtypes for EVRC-NW.

9.1.1.  Registration of Media Type audio/EVRCNW
   Type name: audio
   Subtype names: EVRCNW
   Required parameters: None
   Optional parameters:
   These parameters apply to RTP transfer only.
   mode-set-recv: A subset of EVRC-NW modes.  Possible values are a
   comma separated list of modes from the set {0,1,2,3,4,5,6,7} (see
   Table 2.6.1.2-4 in 3GPP2 C.S0014-D).  A decoder can use this
   attribute to inform an encoder of its preference to operate in a
   specified subset of modes.  Absence of this parameter signals the
   mode set {1,2,3,4,5,6,7}.
   ptime: see RFC 4566 [10].
   maxptime: see RFC 4566.
   maxinterleave: Maximum number for interleaving length (field LLL in
   the Interleaving Octet)[0..7].  The interleaving lengths used in the
   entire session MUST NOT exceed this maximum value.  If not signaled,
   the maxinterleave length MUST be 5.
   silencesupp: see Section 6.1 in RFC 4788.
   dtxmax: see Section 6.1 in RFC 4788.
   dtxmin: see Section 6.1 in RFC 4788.
   hangover: see Section 6.1 in RFC 4788.
   Encoding considerations:
   This media type is framed binary data (see RFC 4288, Section 4.8) and
   is defined for transfer of EVRC-NW encoded data via RTP using the
   Interleaved/Bundled packet format specified in RFC 3558 [6].
   Security considerations: See Section 15.
   Interoperability considerations: None
   Published specification:
   The EVRC-NW vocoder is specified in 3GPP2 C.S0014-D.  The transfer
   method with the Interleaved/Bundled packet format via RTP is
   specified in RFC 3558 [6].  See Section 6 for details for EVRC-NW.
   Applications that use this media type:
   It is expected that many VoIP applications (as well as mobile
   applications) will use this type.
   Additional information:
   The following applies to stored-file transfer methods:
   Magic number: #!EVRCNW\n (see Section 8)
   File extensions: enw, ENW
   Macintosh file type code: None
   Object identifier or OID: None
   EVRC-NW speech frames may also be stored in the file format "3g2"
   defined in 3GPP2 C.S0050-B, which is identified using the media types
   "audio/3gpp2" or "video/3gpp2" registered by RFC 4393 [11].
   Person & email address to contact for further information:
   Zheng Fang <zfang@qualcomm.com<mailto:zfang@qualcomm.com>>
   Intended usage: COMMON
   Restrictions on usage:
   When this media type is used in the context of transfer over RTP, the
   RTP payload format specified in Section 4.1 of RFC 3558 [6] SHALL be
   used.  In all other contexts, the file format defined in Section 8
   SHALL be used.  See Section 6 for details for EVRC-NW.
   Author:
   Zheng Fang <zfang@qualcomm.com<mailto:zfang@qualcomm.com>>
   Change controller:
   IETF Payload working group delegated from the IESG.

9.1.2.  Registration of Media Type audio/EVRCNW0
   Type name: audio
   Subtype names: EVRCNW0
   Required parameters: None
   Optional parameters:
   These parameters apply to RTP transfer only.
   mode-set-recv: A subset of EVRC-NW modes.  Possible values are a
   comma separated list of modes from the set {0,1,2,3,4,5,6,7} (see
   Table 2.6.1.2-4 in 3GPP2 C.S0014-D).  A decoder can use this
   attribute to inform an encoder of its preference to operate in a
   specified subset of modes.  Absence of this parameter signals the
   mode set {1,2,3,4,5,6,7}.
   ptime: see RFC 4566.
   silencesupp: see Section 6.1 in RFC 4788.
   dtxmax: see Section 6.1 in RFC 4788.
   dtxmin: see Section 6.1 in RFC 4788.
   hangover: see Section 6.1 in RFC 4788.
   Encoding considerations:
   This media type is framed binary data (see RFC 4288, Section 4.8) and
   is defined for transfer of EVRC-NW encoded data via RTP using the
   Header-Free packet format specified in RFC 3558 [6].
   Security considerations: See Section 15.
   Interoperability considertaions: None
   Published specification:
   The EVRC-NW vocoder is specified in 3GPP2 C.S0014-D.  The transfer
   method with the Header-Free packet format via RTP is specified in RFC
   3558 [6].
   Applications that use this media type:
   It is expected that many VoIP applications (as well as mobile
   applications) will use this type.
   Additional information: None
   Person & email address to contact for further information:
   Zheng Fang <zfang@qualcomm.com<mailto:zfang@qualcomm.com>>
   Intended usage: COMMON
   Restrictions on usage:
   This media type depends on RTP framing, and hence is only defined for
   transfer via RTP [5], the RTP payload format specified in Section 4.2
   of RFC 3558 [6] SHALL be used.  This media type SHALL NOT be used for
   storage or file transfer, instead audio/EVRCNW SHALL be used.
   Author:
   Zheng Fang <zfang@qualcomm.com<mailto:zfang@qualcomm.com>>
   Change controller:
   IETF Payload working group delegated from the IESG.


9.1.3.  Registration of Media Type audio/EVRCNW1
   Type name: audio
   Subtype names: EVRCNW1
   Required parameters: None
   Optional parameters:
   These parameters apply to RTP transfer only.
   mode-set-recv: A subset of EVRC-NW modes.  Possible values are a
   comma separated list of modes from the set {0,1} (see Table 2.6.1.2-4
   in 3GPP2 C.S0014-D).  A decoder can use this attribute to inform an
   encoder of its preference to operate in a specified subset of modes.
   A value of 0 signals the support for wideband fixed rate (full or
   half rate, depending on the value of 'fixedrate' parameter).  A value
   of 1 signals narroband fixed rate (full or half rate, depending on
   the value of 'fixedrate' parameter).  Absence of this parameter
   signals the mode 1.
   ptime: see RFC 4566.
   maxptime: see RFC 4566.
   fixedrate: Indicates the EVRC-NW rate of the session while in single
   rate operation.  Valid values include: 0.5 and 1, where a value of
   0.5 indicates the 1/2 rate while a value of 1 indicates the full
   rate.  If this parameter is not present, 1/2 rate is assumed.
   silencesupp: see Section 6.1 in RFC 4788.
   dtxmax: see Section 6.1 in RFC 4788.
   dtxmin: see Section 6.1 in RFC 4788.
   hangover: see Section 6.1 in RFC 4788.
   Encoding considerations:
   This media type is framed binary data (see RFC 4288, Section 4.8) and
   is defined for transfer of EVRC-NW encoded data via RTP using the
   Compact Bundled packet format specified in RFC 4788.
   Security considerations: See Section 15
   Interoperability considertaions: None
   Published specification:
   The EVRC-NW vocoder is specified in 3GPP2 C.S0014-D.  The transfer
   method with the Compact Bundled packet format via RTP is specified in
   RFC 4788.
   Applications that use this media type:
   It is expected that many VoIP applications (as well as mobile
   applications) will use this type.
   Additional information: None
   Person & email address to contact for further information:
   Zheng Fang <zfang@qualcomm.com<mailto:zfang@qualcomm.com>>
   Intended usage: COMMON
   Restrictions on usage:
   This media type depends on RTP framing, and hence is only defined for
   transfer via RTP [5], the RTP payload format specified in Section 4
   of RFC 4788 SHALL be used.  This media type SHALL NOT be used for
   storage or file transfer, instead audio/EVRCNW SHALL be used.
   Author:
   Zheng Fang <zfang@qualcomm.com<mailto:zfang@qualcomm.com>>
   Change controller:
   IETF Payload working group delegated from the IESG.