Re: [payload] EVRC-NW wideband encoding capability identification in "draft-ietf-avt-rtp-evrc-nw-03"
"Fang, Zheng" <email@example.com> Tue, 25 October 2011 23:17 UTC
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 370C71F0C4B for <firstname.lastname@example.org>; Tue, 25 Oct 2011 16:17:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([220.127.116.11]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mDymW-O+eUn7 for <email@example.com>; Tue, 25 Oct 2011 16:16:57 -0700 (PDT)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [18.104.22.168]) by ietfa.amsl.com (Postfix) with ESMTP id BEA2D1F0C43 for <firstname.lastname@example.org>; Tue, 25 Oct 2011 16:16:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; email@example.com; q=dns/txt; s=qcdkim; t=1319584616; x=1351120616; h=from:to:cc:subject:thread-topic:thread-index:date: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: x-originating-ip:content-type:mime-version; z=From:=20"Fang,=20Zheng"=20<firstname.lastname@example.org>|To:=20Chu ng=20Cheung=20Chu=20<email@example.com>|CC: =20"firstname.lastname@example.org"=20<email@example.com>,=20"Fang,=20Zh eng"=20<firstname.lastname@example.org>|Subject:=20RE:=20[payload]=20 EVRC-NW=20wideband=20encoding=20capability=20identificati on=0D=0A=20in=20"draft-ietf-avt-rtp-evrc-nw-03" |Thread-Topic:=20[payload]=20EVRC-NW=20wideband=20encodin g=20capability=20identification=0D=0A=20in=20"draft-ietf- avt-rtp-evrc-nw-03"|Thread-Index:=20AQHMkZvs0qNuDMY3rk2If cqwuP1px5WNtAnQ|Date:=20Tue,=2025=20Oct=202011=2023:16:55 =20+0000|Message-ID:=20<E23CE350F3C94C4A834B4E7069CA56791 99F9D@nasanexd01a.na.qualcomm.com>|References:=20<26490BB DEEACA14EA1A0070367B3ADBDB9A5AD1797@EUSAACMS0702.eamcs.er icsson.se>=0D=0A=20<4E22682CC104CF4CAFD070A1C3E717772E8AB 960C5@EUSAACMS0714.eamcs.ericsson.se>=0D=0A=20<86EB726DBD D0F343A9BA78496339C717E437611B9E@EUSAACMS0702.eamcs.erics son.se>=0D=0A=20<26490BBDEEACA14EA1A0070367B3ADBDB9A5B3D9 86@EUSAACMS0702.eamcs.ericsson.se>=0D=0A=20<4E22682CC104C F4CAFD070A1C3E717772E8AB96A50@EUSAACMS0714.eamcs.ericsson .se>=0D=0A=20=20<26490BBDEEACA14EA1A0070367B3ADBDB9A5BABA 9D@EUSAACMS0702.eamcs.ericsson.se>=0D=0A=20<E23CE350F3C94 C4A834B4E7069CA567916BF71@nasanexd01a.na.qualcomm.com>=0D =0A=20<26490BBDEEACA14EA1A0070367B3ADBDB9A5D292FC@EUSAACM S0702.eamcs.ericsson.se>|In-Reply-To:=20<26490BBDEEACA14E A1A0070367B3ADBDB9A5D292FC@EUSAACMS0702.eamcs.ericsson.se >|Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|x-originating-ip: =20[172.30.48.1]|Content-Type:=20multipart/alternative=3B =0D=0A=09boundary=3D"_000_E23CE350F3C94C4A834B4E7069CA567 9199F9Dnasanexd01anaqual_"|MIME-Version:=201.0; bh=2tPoDz9Fa09Okc8R0j2rHPEl5fZLzbD0WUOS0KJoDEY=; b=QIhbIjTdW6GoEu3cYepTifj0OoYmaJfB26rjeBHRkosW+qeFqJE+MUAJ b/ToNOFJfPCeFeou2dL3ELRmiz0RY1PNL0u4MOekfoPLvebGU6eoV0EUW yJZ8691YUNrUxKxdZXaeji4v3uFTI/y4r1wT7zrHCwh/mTk14gnJhsTMp 0=;
X-IronPort-AV: E=McAfee;i="5400,1158,6510"; a="130744479"
Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine02.qualcomm.com with ESMTP; 25 Oct 2011 16:16:56 -0700
X-IronPort-AV: E=Sophos; i="4.69,404,1315206000"; d="scan'208,217"; a="174988876"
Received: from nasanexhc09.na.qualcomm.com ([172.30.39.8]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 25 Oct 2011 16:16:56 -0700
Received: from NASANEXD01A.na.qualcomm.com ([fe80::88b1:1c81:4562:8797]) by nasanexhc09.na.qualcomm.com ([::1]) with mapi id 14.01.0339.001; Tue, 25 Oct 2011 16:16:55 -0700
From: "Fang, Zheng" <email@example.com>
To: Chung Cheung Chu <firstname.lastname@example.org>
Thread-Topic: [payload] EVRC-NW wideband encoding capability identification in "draft-ietf-avt-rtp-evrc-nw-03"
Date: Tue, 25 Oct 2011 23:16:55 +0000
References: <26490BBDEEACA14EA1A0070367B3ADBDB9A5AD1797@EUSAACMS0702.eamcs.ericsson.se> <4E22682CC104CF4CAFD070A1C3E717772E8AB960C5@EUSAACMS0714.eamcs.ericsson.se> <86EB726DBDD0F343A9BA78496339C717E437611B9E@EUSAACMS0702.eamcs.ericsson.se> <26490BBDEEACA14EA1A0070367B3ADBDB9A5B3D986@EUSAACMS0702.eamcs.ericsson.se> <4E22682CC104CF4CAFD070A1C3E717772E8AB96A50@EUSAACMS0714.eamcs.ericsson.se> <26490BBDEEACA14EA1A0070367B3ADBDB9A5BABA9D@EUSAACMS0702.eamcs.ericsson.se> <E23CE350F3C94C4A834B4E7069CA567916BF71@nasanexd01a.na.qualcomm.com> <26490BBDEEACA14EA1A0070367B3ADBDB9A5D292FC@EUSAACMS0702.eamcs.ericsson.se>
Content-Type: multipart/alternative; boundary="_000_E23CE350F3C94C4A834B4E7069CA5679199F9Dnasanexd01anaqual_"
Cc: "email@example.com" <firstname.lastname@example.org>
Subject: Re: [payload] EVRC-NW wideband encoding capability identification in "draft-ietf-avt-rtp-evrc-nw-03"
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:email@example.com?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:firstname.lastname@example.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Oct 2011 23:17:03 -0000
Hi Chung-Cheung, Thank you for commenting and proposing the text changes. I've incorporated these changes into the newly submitted draft: http://tools.ietf.org/html/draft-ietf-avt-rtp-evrc-nw-05 Please let me know if you have any further comments. Thanks! Zheng From: Chung Cheung Chu [mailto:email@example.com] Sent: Sunday, October 23, 2011 8:53 AM To: firstname.lastname@example.org; Fang, Zheng Subject: [payload] EVRC-NW wideband encoding capability identification in "draft-ietf-avt-rtp-evrc-nw-03" Background Per "draft-ietf-avt-rtp-evrc-nw-03", a wideband-capable system using EVRC-NW interleaved/bundled format would set the mode request field to Mode-0 (MMM=0) to request the other end to encode and transmit EVRC-NW wideband encoded traffic. If both the near end and the far end of a call are capable of EVRC-NW wideband support, this mechanism will lead to the exchange of wideband traffic in both directions. If the far end of a call is not capable of wideband encoding, the far end will only encode and transmit traffic in narrowband mode despite the near end's repeated requests for wideband traffic. Per "draft-ietf-avt-rtp-evrc-nw-03.txt", the near end system will not know for certain of the far end's wideband encoding capability/incapability. Due to the limitations, an issue can arise in which the far end transmits using a different narrowband mode from the one preferred by the near end. Should the near end system be aware of the far end's incapability of wideband encoding, the near end can update the MMM bit-field to request the preferred narrowband traffic meeting the near end's local requirements. For example, the near end could request Mode-4 narrowband traffic if the near end system prefers bandwidth conservation over better narrowband quality. The near end could alternatively request Mode-1 narrowband traffic if the near end system prefers better narrowband quality over bandwidth conservation. The issue can manifest itself in another way where end-to-end wideband communication is established first but the far end becomes wideband encoding incapable during the call, due to RF change or hand-over for example. Due to the limitations, a second issue can arise. In the event the near end wideband capable system switches the mode request value in MMM from Mode-0 to non-Mode-0 for narrowband traffic in the scenarios above (in case logic is implemented to revert to requesting the most appropriate narrowband mode if the wideband mode request is not honored over a specific time duration) , the near end will not know if and when the far end would become wideband encoding capable again. End-to-end wideband communication, if desired, may never be realized again for the rest of the call. Per "draft-ietf-avt-rtp-evrc-nw-03", the MMM mode request in EVRC-NW interleaved/bundled format packet complements the mode set information in mode-set-recv. However, section 12 of the draft contains an out-dated text which states that "a remote sender shall not assume the other side can support mode 0, unless the offer includes mode 0 explicitly in 'mode-set-recv'." This inconsistency should be addressed. Proposal In the EVRC-NW interleaved/bundled format, define a dedicated bit-field to signal the instantaneous local EVRC-NW wideband encoding capability. This instantaneous wideband encoding capability identifier is sent together with the MMM field in the payload of each EVRC-NW packet to the other end. For example, this bit-field can be allocated out of the existing 2-bit reserved bit-field. A value of 0 (default) indicates the sending system is capable of EVRC-NW wideband encoding. A value of 1 indicates it is incapable of wideband encoding. The instantaneous wideband encoding capability identifier in each incoming packet is interpreted by the local control logic to determine the appropriate MMM mode request to the far end for wideband or narrowband encoded traffic. While the far end is not capable of wideband encoding, the near end will request with an explicit mode request the preferrerd narrowband encoding mode. Otherwise the near end can request wideband encoded traffic. The preferred encoding mode requested can match the far end's capability dynamically. It is also proposed that section 12 be updated to address its inconsistency with section 10. Proposed Text (section 6) (in black) 6. Payload format Three RTP packet formats are supported for the EVRC-NW codec - the interleaved/bundled packet format, the header-free packet format and the compact bundled packet format. For all these formats, the operational details and capabilities, such as ToC, interleaving, DTX, and bundling, of EVRC-NW are exactly the same as those defined in EVRC , EVRC-B  and EVRC-WB , except that 1. the mode change request field in the interleaved/bundled packet format MUST be interpreted according to the definition of the RATE_REDUC parameter as defined in EVRC-NW . 2. the mode change request field in the interleaved/bundled packet format SHOULD be honored by an EVRCNW encoding end point in an one-to-one session with a dedicated EVRCNW decoding end point such as in a two-party call or in a conference leg. 3. the reserved bit field in the first octet of the interleaved/bundled format has only one bit. Bit 1 of the first octet is an EVRC-NW wideband/narrowband encoding capability identification flag. The media type audio/EVRCNW maps to the interleaved/bundled packet format, audio/EVRCNW0 maps to the header-free packet format and audio/EVRCNW1 maps to the compact bundled packet format. 6.1 Encoding capability identification in EVRC-NW interleaved/bundled format The EVRC-NW interleaved/bundled format defines an encoding capability identification flag, which is used to signal the far end of a communication session of the instantaneous local EVRC-NW wideband/narrowband encoding capability. This capability identification flag allows the far end to use the MMM field in its out-going (returning) EVRC-NW interleaved/bundled format packets to request the desired EVRC-NW wideband or narrowband encoding mode in accordance with the dynamic/instantaneous encoding capability information. The following examples illustrate a few scenarios where the encoding capability information is used: - An end-to-end wideband communication is established first between two communication end points using EVRC-NW interleaved/bundled format. The called end point becomes wideband encoding incapable during the call and makes the other end aware of this change using the encoding capability identification flag. Based on the new information the calling end point could change the MMM value in its outgoing EVRC-NW packets from Mode-0 to Mode-4 to request narrowband encoded traffic for bandwidth efficiency or from Mode-0 to Mode-1 for best perceptual quality. - An end-to-end narrowband communication is established between an EVRC-NW wideband encoding capable calling end point and an EVRC-NW wideband encoding incapable called end point. The called end point becomes EVRC-NW wideband encoding capable during the call and makes the other end aware of this change using the encoding capability identification flag. Based on the new information the calling end point could change the MMM value in its outgoing EVRC-NW packets from non-Mode-0 to Mode-0 to request wideband traffic. EVRC-NW interleaved/bundled format defines the encoding capability identification flag in bit 1 of the first octet, as illustrated in the figure below. The flag shall be set to zero (C=0) when the local EVRC-NW encoder is capable of Mode-0 wideband encoding. The flag shall be set to one (C=1) when the local EVRC-NW encoder is capable of non-Mode-0 narrowband encoding only. See RFC 3558  for original definitions of other fields in the interleaved/bundled format. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP Header | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |R|C| LLL | NNN | MMM | Count | TOC | ... | TOC |padding| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | one or more codec data frames, one per TOC entry | | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved (R): 1 bit Reserved bit. MUST be set to zero by sender, SHOULD be ignored by receiver. Encoding capability identification (C): 1 bit Must be set to zero by sender to indicate wideband encoding capable or set to one to indicate narrowband encoding capable only. C = 0 : Mode-0 wideband encoding capable = 1 : Mode-0 wideband encoding incapable, i.e. narrowband encoding only. Proposed Text (section 9.1.1) (in black) 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 . See section 6 for details for EVRC-NW. Proposed Text (section 9.1.1) (in black) 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  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. Proposed Text (section 12) (in black) o An offerer can use 'mode-set-recv' to request that the remote sender's encoder be limited to the list of modes signaled in 'mode-set-recv'. A remote sender MAY ignore 'mode-set-recv' requests. However, a remote sender shall not assume the other side can support mode 0, unless the offer includes mode 0 explicitly in 'mode-set-recv' or the remote sender receives mode requests with MMM = 0 from the communication partner during an active call using EVRC-NW interleaved/bundled format. The suggested change is for media subtype EVRCNW payload format only. It is not applicable to media subtype EVRCNW0 and EVRCNW1 payload formats where the MMM mode request field is not supported. CC Chung-Cheung Chu Media Gateway DSP Design BCAM - Ericsson ECN: 810-16713 External: +514-461-6713 or +514 345-7900 x46489 This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer.
- [payload] EVRC-NW wideband encoding capability id… Chung Cheung Chu
- Re: [payload] EVRC-NW wideband encoding capabilit… Fang, Zheng