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