[payload] EVRC-NW wideband encoding capability identification in "draft-ietf-avt-rtp-evrc-nw-03"
Chung Cheung Chu <email@example.com> Fri, 09 September 2011 20:00 UTC
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8147821F87FC for <firstname.lastname@example.org>; Fri, 9 Sep 2011 13:00:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([126.96.36.199]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D1MciwZQ47-B for <email@example.com>; Fri, 9 Sep 2011 13:00:06 -0700 (PDT)
Received: from imr4.ericy.com (imr4.ericy.com [188.8.131.52]) by ietfa.amsl.com (Postfix) with ESMTP id 7878221F8726 for <firstname.lastname@example.org>; Fri, 9 Sep 2011 13:00:06 -0700 (PDT)
Received: from eusaamw0712.eamcs.ericsson.se ([184.108.40.206]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p89K1l0C003745; Fri, 9 Sep 2011 15:02:02 -0500
Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.60]) by eusaamw0712.eamcs.ericsson.se ([220.127.116.11]) with mapi; Fri, 9 Sep 2011 16:01:39 -0400
From: Chung Cheung Chu <email@example.com>
To: "firstname.lastname@example.org" <email@example.com>, "Fang, Zheng" <firstname.lastname@example.org>
Date: Fri, 9 Sep 2011 16:01:37 -0400
Thread-Topic: [payload] EVRC-NW wideband encoding capability identification in "draft-ietf-avt-rtp-evrc-nw-03"
Content-Type: multipart/alternative; boundary="_000_26490BBDEEACA14EA1A0070367B3ADBDB9A56A164FEUSAACMS0702e_"
Subject: [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: Fri, 09 Sep 2011 20:00:07 -0000
Background Per "draft-ietf-avt-rtp-evrc-nw-03", an EVRC-NW wideband-capable system using interleaved/bundled format would transmit 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. 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 Mode4 narrowband traffic if the near end system prefers bandwidth conservation over better narrowband quality. The near end could alternatively request Mode1 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. Another potential issue is that in the event the near end wideband capable system switches the mode request value in MMM from Mode0 to non-Mode0 for narrowband traffic in the scenarios above, 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. Proposal In the EVRCNW 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 equested can match the far end's capability dynamically. 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. Regards, 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.
- Re: [payload] Mode request support in draft "draf… Fang, Zheng
- [payload] Mode request support in draft "draft-ie… Chung Cheung Chu
- [payload] EVRC-NW wideband encoding capability id… Chung Cheung Chu