[payload] EVRC-NW wideband encoding capability identification in "draft-ietf-avt-rtp-evrc-nw-03"

[Chung Cheung Chu <[e-mail]>]

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 [6], EVRC-B [2] and EVRC-WB [3], 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 [4].
   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 [6] 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 [6].  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 [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.



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: [phone]   or   [phone] 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.