draft-ietf-avt-rtp-evrc-nw-02.txt   draft-ietf-avt-rtp-evrc-nw-03.txt 
Network Working Group Z. Fang Network Working Group Z. Fang
Internet-Draft Qualcomm Internet-Draft Qualcomm
Intended status: Standards Track November 30, 2010 Intended status: Standards Track April 23, 2011
Expires: June 3, 2011 Expires: October 25, 2011
RTP payload format for Enhanced Variable Rate Narrowband-Wideband Codec RTP payload format for Enhanced Variable Rate Narrowband-Wideband Codec
(EVRC-NW) (EVRC-NW)
draft-ietf-avt-rtp-evrc-nw-02 draft-ietf-avt-rtp-evrc-nw-03
Abstract Abstract
This document specifies real-time transport protocol (RTP) payload This document specifies real-time transport protocol (RTP) payload
formats to be used for the Enhanced Variable Rate Narrowband-Wideband formats to be used for the Enhanced Variable Rate Narrowband-Wideband
Codec (EVRC-NW). Three media type registrations are included for Codec (EVRC-NW). Three media type registrations are included for
EVRC-NW RTP payload formats. In addition, a file format is specified EVRC-NW RTP payload formats. In addition, a file format is specified
for transport of EVRC-NW speech data in storage mode applications for transport of EVRC-NW speech data in storage mode applications
such as e-mail. such as e-mail.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 3, 2011. This Internet-Draft will expire on October 25, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 8, line 12 skipping to change at page 8, line 12
talkspurt. For all other packets the marker bit SHALL be set to zero talkspurt. For all other packets the marker bit SHALL be set to zero
(M=0). (M=0).
6. Payload format 6. Payload format
Three RTP packet formats are supported for the EVRC-NW codec - the Three RTP packet formats are supported for the EVRC-NW codec - the
interleaved/bundled packet format, the header-free packet format and interleaved/bundled packet format, the header-free packet format and
the compact bundled packet format. For all these formats, the the compact bundled packet format. For all these formats, the
operational details and capabilities, such as ToC, interleaving, DTX, operational details and capabilities, such as ToC, interleaving, DTX,
and bundling, of EVRC-NW are exactly the same as those of EVRC-B and and bundling, of EVRC-NW are exactly the same as those of EVRC-B and
EVRC-WB, as defined in [2] and [3], except that the mode change EVRC-WB, as defined in [2] and [3], except that
request field in the ToC MUST be interpreted according to the
definition of the RATE_REDUC parameter as defined in EVRC-NW [4]. 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.
The media type audio/EVRCNW maps to the interleaved/bundled packet The media type audio/EVRCNW maps to the interleaved/bundled packet
format, audio/EVRCNW0 maps to the header-free packet format and format, audio/EVRCNW0 maps to the header-free packet format and
audio/EVRCNW1 maps to the compact bundled packet format. audio/EVRCNW1 maps to the compact bundled packet format.
7. Congestion Control Considerations 7. Congestion Control Considerations
Congestion control for RTP SHALL be used in accordance with RFC 3550 Congestion control for RTP SHALL be used in accordance with RFC 3550
[5], and with any applicable RTP profile; e.g., RFC 3551 [6]. [5], and with any applicable RTP profile; e.g., RFC 3551 [6].
Due to the header overhead, the number of frames encapsulated in each Due to the header overhead, the number of frames encapsulated in each
skipping to change at page 11, line 33 skipping to change at page 11, line 33
These parameters apply to RTP transfer only. These parameters apply to RTP transfer only.
mode-set-recv: A subset of EVRC-NW modes. Possible values are a 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 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 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 attribute to inform an encoder of its preference to operate in a
specified subset of modes. Absence of this parameter signals the specified subset of modes. Absence of this parameter signals the
mode set {1,2,3,4,5,6,7}. mode set {1,2,3,4,5,6,7}.
sendmode: A mode of the EVRC-NW codec. An encoder can use this to sendmode: The "sendmode" parameter is deprecated for EVRCNW. An
signal its current mode of operation. Possible values are EVRCNW receiver MUST ignore this parameter if present.
0,1,2,3,4,5,6,7 (see Table 2.6.1.2-4 in 3GPP2 C.S0014-D). Absence of
this parameter signals mode 4.
ptime: see RFC 4566 [9]. ptime: see RFC 4566 [9].
maxptime: see RFC 4566. maxptime: see RFC 4566.
maxinterleave: Maximum number for interleaving length (field LLL in maxinterleave: Maximum number for interleaving length (field LLL in
the Interleaving Octet)[0..7]. The interleaving lengths used in the the Interleaving Octet)[0..7]. The interleaving lengths used in the
entire session MUST NOT exceed this maximum value. If not signaled, entire session MUST NOT exceed this maximum value. If not signaled,
the maxinterleave length MUST be 5. the maxinterleave length MUST be 5.
skipping to change at page 13, line 35 skipping to change at page 13, line 33
These parameters apply to RTP transfer only. These parameters apply to RTP transfer only.
mode-set-recv: A subset of EVRC-NW modes. Possible values are a 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 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 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 attribute to inform an encoder of its preference to operate in a
specified subset of modes. Absence of this parameter signals the specified subset of modes. Absence of this parameter signals the
mode set {1,2,3,4,5,6,7}. mode set {1,2,3,4,5,6,7}.
sendmode: A mode of the EVRC-NW codec. An encoder can use this to sendmode: The "sendmode" parameter is deprecated for EVRCNW. An
signal its current mode of operation. Possible values are EVRCNW receiver MUST ignore this parameter if present.
0,1,2,3,4,5,6,7 (see Table 2.6.1.2-4 in 3GPP2 C.S0014-D). Absence of
this parameter signals mode 4.
ptime: see RFC 4566. ptime: see RFC 4566.
silencesupp: see Section 6.1 in RFC 4788. silencesupp: see Section 6.1 in RFC 4788.
dtxmax: see Section 6.1 in RFC 4788. dtxmax: see Section 6.1 in RFC 4788.
dtxmin: see Section 6.1 in RFC 4788. dtxmin: see Section 6.1 in RFC 4788.
hangover: see Section 6.1 in RFC 4788. hangover: see Section 6.1 in RFC 4788.
skipping to change at page 15, line 20 skipping to change at page 15, line 17
mode-set-recv: A subset of EVRC-NW modes. Possible values are a 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 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 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. 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 A value of 0 signals the support for wideband fixed rate (full or
half rate, depending on the value of 'fixedrate' parameter). A value half rate, depending on the value of 'fixedrate' parameter). A value
of 1 signals narroband fixed rate (full or half rate, depending on of 1 signals narroband fixed rate (full or half rate, depending on
the value of 'fixedrate' parameter). Absence of this parameter the value of 'fixedrate' parameter). Absence of this parameter
signals the mode 1. signals the mode 1.
sendmode: A mode of the EVRC-NW codec. An encoder can use this to sendmode: The "sendmode" parameter is deprecated for EVRCNW. An
signal its current mode of operation. Possible values are 0,1 (see EVRCNW receiver MUST ignore this parameter if present.
Table 2.6.1.2-4 in 3GPP2 C.S0014-D). 'sendmode' with value 0 signals
wideband fixed rate operation (full or half rate, depending on the
value of the 'fixedrate' parameter). 'sendmode' with value 1 signals
narrowband fixed rate operation (full or half rate, depending on the
value of the 'fixedrate' parameter). Absence of this parameter
signals mode 1.
ptime: see RFC 4566. ptime: see RFC 4566.
maxptime: see RFC 4566. maxptime: see RFC 4566.
fixedrate: Indicates the EVRC-NW rate of the session while in single 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 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 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. rate. If this parameter is not present, 1/2 rate is assumed.
skipping to change at page 17, line 16 skipping to change at page 17, line 16
'mode-set-recv' can be used by a decoder to inform an encoder of its 'mode-set-recv' can be used by a decoder to inform an encoder of its
preference to operate in a specified subset of modes. Note that preference to operate in a specified subset of modes. Note that
indicating a preference, implicitly indicates support for that indicating a preference, implicitly indicates support for that
capability. Conversely, if mode 0 is not preferred, then there is no capability. Conversely, if mode 0 is not preferred, then there is no
indication that mode 0 is supported. indication that mode 0 is supported.
1. To inform the capability of wideband mode support: A decoder can 1. To inform the capability of wideband mode support: A decoder can
always decode all the narrowband modes (modes 1 to 7). Unless always decode all the narrowband modes (modes 1 to 7). Unless
the decoder indicates the support of mode 0 (i.e., preference) in the decoder indicates the support of mode 0 (i.e., preference) in
this parameter, an encoder at the other side shall not operate in this parameter or in the MMM mode request field in interleaved/
mode 0. bundled payload format, an encoder at the other side shall not
operate in mode 0.
2. To inform the preference to operate in a subset of modes: A set 2. To inform the preference to operate in a subset of modes: A set
has been defined so that several modes can be expressed as a has been defined so that several modes can be expressed as a
preference in one attempt. For instance, the set {4,5,6,7} preference in one attempt. For instance, the set {4,5,6,7}
signals that the receiver perfers the sender to operate in signals that the receiver perfers the sender to operate in
bandwidth-efficient narrowband modes of EVRC-NW. bandwidth-efficient narrowband modes of EVRC-NW.
'sendmode' can be used by a sender to announce its encoder's current Note, during an active call session using the interleaved/bundled
mode of operation. A sender can change its mode among modes 1 to 7 packet format, the MMM mode request received from a communication
(or among modes 0 to 7 if the receiver supports wideband mode) partner complements the mode set information in mode-set-recv. A
anytime and this does not cause any decoding problems at the mode request with MMM=0 from a communication partner is an implicit
receiver. indication of the partner's EVRCNW wideband decoding capability and
preference. An EVRCNW wideband capable node receiving the request
can operate in wideband mode. A mode request with MMM=1, 2, ..., or
7 from a communication partner is an implicit indication of the
partner's EVRCNW narrowband decoding preference. The encoder of an
EVRCNW node receiving the request should honor the request and
operate in narrowband mode.
11. Mapping EVRC-NW media type parameters into SDP 11. Mapping EVRC-NW media type parameters into SDP
Information carried in the media type specification has a specific Information carried in the media type specification has a specific
mapping to fields in the Session Description Protocol (SDP) [9], mapping to fields in the Session Description Protocol (SDP) [9],
which is commonly used to describe RTP sessions. When SDP is used to which is commonly used to describe RTP sessions. When SDP is used to
specify sessions employing EVRC-NW encoded speech, the mapping is as specify sessions employing EVRC-NW encoded speech, the mapping is as
follows. follows.
o The media type ("audio") goes in SDP "m=" as the media name. o The media type ("audio") goes in SDP "m=" as the media name.
skipping to change at page 19, line 23 skipping to change at page 19, line 23
"m=audio" lines, with EVRC-NW as the preferred codec. This will "m=audio" lines, with EVRC-NW as the preferred codec. This will
allow interoperability with an answerer which supports only EVRC-B allow interoperability with an answerer which supports only EVRC-B
and/or EVRC-WB. and/or EVRC-WB.
Below is an example of such an offer: Below is an example of such an offer:
m=audio 55954 RTP/AVP 98 99 100 m=audio 55954 RTP/AVP 98 99 100
a=rtpmap:98 EVRCNW0/16000 a=rtpmap:98 EVRCNW0/16000
a=rtpmap:99 EVRCWB0/16000 a=rtpmap:99 EVRCWB0/16000
a=rtpmap:100 EVRCB0/8000 a=rtpmap:100 EVRCB0/8000
a=fmtp:98 mode-set-recv=0,1,2,3,4,5,6;sendmode=0 a=fmtp:98 mode-set-recv=0,1,2,3,4,5,6
a=fmtp:99 mode-set-recv=0,4;sendmode=0 a=fmtp:99 mode-set-recv=0,4
a=fmtp:100 recvmode=0;sendmode=4 a=fmtp:100 recvmode=0
If the answerer supports EVRC-NW then the answerer can keep the If the answerer supports EVRC-NW then the answerer can keep the
payload type 98 in its answer and the conversation can be done using payload type 98 in its answer and the conversation can be done using
EVRC-NW. Else, if the answerer supports only EVRC-WB and/or EVRC-B EVRC-NW. Else, if the answerer supports only EVRC-WB and/or EVRC-B
then the answerer will leave only the payload type 99 and/or 100 then the answerer will leave only the payload type 99 and/or 100
respectively in its answer and the conversation will be done using respectively in its answer and the conversation will be done using
EVRC-WB and/or EVRC-B respectively. EVRC-WB and/or EVRC-B respectively.
An example answer for the above offer: An example answer for the above offer:
m=audio 55954 RTP/AVP 98 m=audio 55954 RTP/AVP 98
a=rtpmap:98 EVRCNW0/16000 a=rtpmap:98 EVRCNW0/16000
a=fmtp:98 mode-set-recv=4;sendmode=4 a=fmtp:98 mode-set-recv=4
o 'mode-set-recv' is a uni-directional receive only parameter. o 'mode-set-recv' is a uni-directional receive only parameter.
o 'sendmode' is a uni-directional send only parameter.
o Using 'sendmode', a sender can signal its current mode of
operation. Note that a receiver may receive RTP media well before
the arrival of SDP with a (first time, or updated) 'sendmode'
parameter.
o An offerer can use 'mode-set-recv' to request that the remote 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 sender's encoder be limited to the list of modes signaled in
'mode-set-recv'. A remote sender MAY ignore 'mode-set-recv' 'mode-set-recv'. A remote sender MAY ignore 'mode-set-recv'
requests. However, a remote sender shall not assume the other requests. However, a remote sender shall not assume the other
side can support mode 0, unless the offer includes mode 0 side can support mode 0, unless the offer includes mode 0
explicitly in 'mode-set-recv'. explicitly in 'mode-set-recv'.
o The parameters 'maxptime' and 'ptime' will in most cases not o The parameters 'maxptime' and 'ptime' will in most cases not
affect interoperability, however the setting of the parameters can affect interoperability, however the setting of the parameters can
affect the performance of the application. The SDP offer-answer affect the performance of the application. The SDP offer-answer
handling of the 'ptime' parameter is described in RFC 3264 [11]. handling of the 'ptime' parameter is described in RFC 3264 [11].
The 'maxptime' parameter MUST be handled in the same way. The 'maxptime' parameter MUST be handled in the same way.
o For a sendonly stream, the 'mode-set-recv' parameter is not useful o For a sendonly stream, the 'mode-set-recv' parameter is not useful
and SHOULD NOT be used. and SHOULD NOT be used.
o For a recvonly stream, the 'sendmode' parameter is not useful and
SHOULD NOT be used.
o When using EVRCNW1, the entire session MUST use the same fixed o When using EVRCNW1, the entire session MUST use the same fixed
rate and mode (0-Wideband or 1-Narrowband). rate and mode (0-Wideband or 1-Narrowband).
o For additional rules which MUST be followed while negotiating DTX o For additional rules which MUST be followed while negotiating DTX
parameters, see Section 6.8 in RFC 4788 [2]. parameters, see Section 6.8 in RFC 4788 [2].
o Any unknown parameter in an SDP offer MUST be ignored by the o Any unknown parameter in an SDP offer MUST be ignored by the
receiver and MUST NOT be included in the SDP answer. receiver and MUST NOT be included in the SDP answer.
13. Declarative SDP Considerations 13. Declarative SDP Considerations
skipping to change at page 22, line 21 skipping to change at page 22, line 21
ignored. Note that media subtype names are case-insensitive. ignored. Note that media subtype names are case-insensitive.
Parameter names are case-insensitive both in media types and in the Parameter names are case-insensitive both in media types and in the
mapping to the SDP a=fmtp attribute. mapping to the SDP a=fmtp attribute.
Example usage of EVRCNW if wideband mode is supported: Example usage of EVRCNW if wideband mode is supported:
m=audio 49120 RTP/AVP 97 98 99 m=audio 49120 RTP/AVP 97 98 99
a=rtpmap:97 EVRCNW/16000 a=rtpmap:97 EVRCNW/16000
a=rtpmap:98 EVRCWB/16000 a=rtpmap:98 EVRCWB/16000
a=rtpmap:99 EVRCB/8000 a=rtpmap:99 EVRCB/8000
a=fmtp:97 mode-set-recv=0,1,2,3,4,5,6;sendmode=0 a=fmtp:97 mode-set-recv=0,1,2,3,4,5,6
a=fmtp:98 mode-set-recv=0,4;sendmode=0 a=fmtp:98 mode-set-recv=0,4
a=fmtp:99 recvmode=0;sendmode=0 a=fmtp:99 recvmode=0
a=maxptime:120 a=maxptime:120
Example usage of EVRCNW if wideband mode is not supported: Example usage of EVRCNW if wideband mode is not supported:
m=audio 49120 RTP/AVP 97 98 99 m=audio 49120 RTP/AVP 97 98 99
a=rtpmap:97 EVRCNW/16000 a=rtpmap:97 EVRCNW/16000
a=rtpmap:98 EVRCWB/16000 a=rtpmap:98 EVRCWB/16000
a=rtpmap:99 EVRCB/8000 a=rtpmap:99 EVRCB/8000
a=fmtp:97 mode-set-recv=1,2,3,4,5,6;sendmode=4 a=fmtp:97 mode-set-recv=1,2,3,4,5,6
a=fmtp:98 mode-set-recv=4;sendmode=4 a=fmtp:98 mode-set-recv=4
a=fmtp:99 recvmode=0;sendmode=0 a=fmtp:99 recvmode=0
a=maxptime:120 a=maxptime:120
Example usage of EVRCNW0: Example usage of EVRCNW0:
m=audio 49120 RTP/AVP 97 98 99 m=audio 49120 RTP/AVP 97 98 99
a=rtpmap:97 EVRCNW0/16000 a=rtpmap:97 EVRCNW0/16000
a=rtpmap:98 EVRCWB0/16000 a=rtpmap:98 EVRCWB0/16000
a=rtpmap:99 EVRCB0/8000 a=rtpmap:99 EVRCB0/8000
a=fmtp:97 mode-set-recv=0,1,2,3,4,5,6;sendmode=0 a=fmtp:97 mode-set-recv=0,1,2,3,4,5,6
a=fmtp:98 mode-set-recv=0,4;sendmode=0 a=fmtp:98 mode-set-recv=0,4
a=fmtp:99 recvmode=0;sendmode=0 a=fmtp:99 recvmode=0
Example SDP answer from a media gateway requesting a terminal to Example SDP answer from a media gateway requesting a terminal to
limit its encoder operation to EVRC-NW mode 4. limit its encoder operation to EVRC-NW mode 4.
m=audio 49120 RTP/AVP 97 m=audio 49120 RTP/AVP 97
a=rtpmap:97 EVRCNW0/16000 a=rtpmap:97 EVRCNW0/16000
a=fmtp:97 mode-set-recv=4;sendmode=4 a=fmtp:97 mode-set-recv=4
Example usage of EVRCNW1: Example usage of EVRCNW1:
m=audio 49120 RTP/AVP 97 98 99 m=audio 49120 RTP/AVP 97 98 99
a=rtpmap:97 EVRCNW1/16000 a=rtpmap:97 EVRCNW1/16000
a=rtpmap:98 EVRCWB1/16000 a=rtpmap:98 EVRCWB1/16000
a=rtpmap:99 EVRCB1/8000 a=rtpmap:99 EVRCB1/8000
a=fmtp:97 fixedrate=0.5 a=fmtp:97 fixedrate=0.5
a=fmtp:98 fixedrate=0.5 a=fmtp:98 fixedrate=0.5
a=fmtp:99 fixedrate=0.5 a=fmtp:99 fixedrate=0.5
a=maxptime:100 a=maxptime:100
Example usage of EVRCNW with DTX with silencesupp=1: Example usage of EVRCNW with DTX with silencesupp=1:
m=audio 49120 RTP/AVP 97 98 99 m=audio 49120 RTP/AVP 97 98 99
a=rtpmap:97 EVRCNW/16000 a=rtpmap:97 EVRCNW/16000
a=rtpmap:98 EVRCWB/16000 a=rtpmap:98 EVRCWB/16000
a=rtpmap:99 EVRCB/8000 a=rtpmap:99 EVRCB/8000
a=fmtp:97 silencesupp=1;dtxmax=32;dtxmin=12;hangover=1 \ a=fmtp:97 silencesupp=1;dtxmax=32;dtxmin=12;hangover=1; \
mode-set-recv=0,1,2,3,4,5,6;sendmode=0 mode-set-recv=0,1,2,3,4,5,6
a=fmtp:98 silencesupp=1;dtxmax=32;dtxmin=12;hangover=1 \ a=fmtp:98 silencesupp=1;dtxmax=32;dtxmin=12;hangover=1; \
mode-set-recv=0,4;sendmode=0 mode-set-recv=0,4
a=fmtp:99 recvmode=0;sendmode=0 a=fmtp:99 recvmode=0
a=maxptime:120 a=maxptime:120
Examples usage of EVRCNW with DTX with silencesupp=0: Examples usage of EVRCNW with DTX with silencesupp=0:
m=audio 49120 RTP/AVP 97 98 99 m=audio 49120 RTP/AVP 97 98 99
a=rtpmap:97 EVRCNW/16000 a=rtpmap:97 EVRCNW/16000
a=rtpmap:98 EVRCWB/16000 a=rtpmap:98 EVRCWB/16000
a=rtpmap:99 EVRCB/8000 a=rtpmap:99 EVRCB/8000
a=fmtp:97 silencesupp=0;dtxmax=32;dtxmin=12;hangover=1 \ a=fmtp:97 silencesupp=0;dtxmax=32;dtxmin=12;hangover=1; \
mode-set-recv=0,1,2,3,4,5,6;sendmode=0 mode-set-recv=0,1,2,3,4,5,6
a=fmtp:98 silencesupp=0;dtxmax=32;dtxmin=12;hangover=1 \ a=fmtp:98 silencesupp=0;dtxmax=32;dtxmin=12;hangover=1; \
mode-set-recv=0,4;sendmode=0 mode-set-recv=0,4
a=fmtp:99 recvmode=0;sendmode=0 a=fmtp:99 recvmode=0
a=maxptime:120 a=maxptime:120
Example offer answer exchange between EVRC-NW and legacy EVRC-B (RFC Example offer answer exchange between EVRC-NW and legacy EVRC-B (RFC
4788): 4788):
Offer: Offer:
m=audio 55954 RTP/AVP 97 98 99 m=audio 55954 RTP/AVP 97 98 99
a=rtpmap:97 EVRCNW0/16000 a=rtpmap:97 EVRCNW0/16000
a=rtpmap:98 EVRCWB0/16000 a=rtpmap:98 EVRCWB0/16000
a=rtpmap:99 EVRCB0/8000 a=rtpmap:99 EVRCB0/8000
a=rtpmap:97 mode-set-recv=0,1,2,3,4,5,6;sendmode=0 a=rtpmap:97 mode-set-recv=0,1,2,3,4,5,6
a=fmtp:98 mode-set-recv=0,4;sendmode=0 a=fmtp:98 mode-set-recv=0,4
a=fmtp:99 recvmode=0;sendmode=0 a=fmtp:99 recvmode=0
Answer: Answer:
m=audio 55954 RTP/AVP 99 m=audio 55954 RTP/AVP 99
a=rtpmap:99 EVRCB0/8000 a=rtpmap:99 EVRCB0/8000
Example offer answer exchange between EVRC-NW and legacy EVRC-WB (RFC Example offer answer exchange between EVRC-NW and legacy EVRC-WB (RFC
5188): 5188):
Offer: Offer:
m=audio 55954 RTP/AVP 97 98 99 m=audio 55954 RTP/AVP 97 98 99
a=rtpmap:97 EVRCNW0/16000 a=rtpmap:97 EVRCNW0/16000
a=rtpmap:98 EVRCWB0/16000 a=rtpmap:98 EVRCWB0/16000
a=rtpmap:99 EVRCB0/8000 a=rtpmap:99 EVRCB0/8000
a=rtpmap:97 mode-set-recv=0,1,2,3,4,5,6;sendmode=0 a=rtpmap:97 mode-set-recv=0,1,2,3,4,5,6
a=fmtp:98 mode-set-recv=0,4;sendmode=0 a=fmtp:98 mode-set-recv=0,4
a=fmtp:99 recvmode=0;sendmode=0 a=fmtp:99 recvmode=0
Answer: Answer:
m=audio 55954 RTP/AVP 98 99 m=audio 55954 RTP/AVP 98 99
a=rtpmap:98 EVRCWB0/16000 a=rtpmap:98 EVRCWB0/16000
15. Security Considerations 15. Security Considerations
Since compression is applied to the payload formats end-to-end, and Since compression is applied to the payload formats end-to-end, and
the encodings do not exhibit significant non-uniformity, the encodings do not exhibit significant non-uniformity,
 End of changes. 22 change blocks. 
71 lines changed or deleted 66 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/