Subject: [Gen-art] RE: Gen ART review of draft-ietf-avt-compact-bundled-evrc-09.txt

From: [email-masked]
Date: Mon, 9 Oct 2006 18:55:15 -0400

Qiaobing,

-- Draft Title

> Section 3.1 is essentially copied from RFC3558 word by word and dealt
> with in the same way here.
> 
> Since specifying a widely usable RTP format is NOT the focus of this
> work, we'd propose to remove section 3.1 and keep the current title.

If the authors believe that the formats defined here are essentially
only useful for the EVRC codecs, then removing Section 3.1 would be
fine.

-- Magic Number representation

> > Section 5: Remove the quotes surrounding the hexadecimal form of
> > the magic number in:
> >
> >     "0x23 0x21 0x45 0x56 0x52 0x43 0x2D 0x42 0x0A"
> >
> > as that's not supposed to be a text string - the text string
> > is given earlier as "#!EVRC-B\n" .
> 
> 
> We can either remove it as suggested, or change it as follows
(following
> the way it is dealt with in section 5.1 in RFC3267):
> 
>        "#!EVRC-B\n"
>        (or 0x2321455652432d420a in hexadecimal).

That'll work, and breaking it up into octets like this might be
easier on the eyes:

	0x2321 0x4556 0x5243 0x2d42 0x0a 

This is your choice - removing the quotes was a matter of correctness,
whether to break it up into octets or not is a matter of preference.

-- \n in the Magic Number

> >    Note, the "\n" is an important part of the magic number and MUST
be
> >    included in the comparison, since, otherwise, the EVRC-B magic
number
> >    will become indistinguishable from magic number used for EVRC.
> >
> > *** That's somewhat sloppy.  Can this magic number be changed to
> > actually have a different visual presentation, as opposed to only
> > differing in a non-printable character that is often stripped in
> > text string processing?  It would be ok (but disappointing) if this
> > were not possible due to the amount of installed base/running code
> > using that magic number.
> 
> This text is modeled (almost word by word) after section 5.1 of
RFC3267.
> The visual presentation is already different ("#!EVRC-B" vs.
"#!EVRC"), 
> the Note is just meant to be a friendly reminder to an inexperienced 
> programmer, which may be unnecessary. We can remove it if you feel 
> necessary.

My concern is with: "otherwise, the EVRC-B magic number
will become indistinguishable from magic number used for EVRC."
That text appears to be incorrect, as the real issue appears to be with
the existing magic number for EVRC.  The following text would make this
clear:

    Note, the "\n" is an important part of both this magic number and
the 
    "#!EVRC\n" magic number defined in Section 11 of RFC 3558 and the
"\n"
    MUST be included in any comparison of either magic number, since,
    otherwise, a prefix of the EVRC-B magic number could be mistaken for
    the EVRC magic number.

The "MUST" in the above text modifies RFC 3558, but this draft already
has
that effect.

-- Changes to Default Values

> > In the definition of dtxmin:
> >
> >          If this parameter is not present, the default value, 12, as
> >          specified in [8] MUST be assumed (note, if a later version
of
> >          [8] specifies a new, different value, the new value will
take
> >          precedence).
> > *** That's better, but the ability of 3GPP2 to change the default
looks
> > like it could cause an interoperability problem (applies to
silencesupp,
> > dtxmin, dtxmax, and hangover).  How will this be addressed? This
needs
> > to be explained.
> 
> A few thoughts:
> 
> 1. Due to the way the 4 parameters are used, even if the two ends
> mistakenly assume a different set of default values, they most likely
> should still be able to inter-operate, with *maybe* a bit suboptimal
> performance in some implementation.
> 
> 2. The note is meant for future-proof but maybe a bit unnecessary
since
> there is no evidence that I am aware of that 3GPP2 is going to change
> the default values soon. We can perhaps remove that note.  (Any spec
with
> default values would face the same situation if for some good reasons
> one or more default value needs to be changed in the future). There is
> nothing special for this document.
> 
> Our proposal is to remove the note.

I don't like that idea - if there are interoperability issues here, they
need to be documented, but if there aren't interoperability issues here,
the MUST was probably wrong.  I would advise consulting your WG chairs
(and possibly the responsible AD) about the importance and potential
impact of this issue, as I'm not sufficiently expert to make the call.

Off the top of my head, I would suggest:
	- using a "SHOULD" for the defaults instead of "MUST" (due to
		your point 1),
	- describe the consequences of changing the defaults (what could
		be suboptimal or broken in what ways), and
	- possibly add a "SHOULD" for explicitly negotiating the desired
		new value instead of changing the default
That way, 3GPP2 will understand the consequences of their actions if
they decide to make changes in this area.

Thanks,
--David

> -----Original Message-----
> From: Qiaobing Xie [mailto:[email-masked]] 
> Sent: Saturday, October 07, 2006 4:33 AM
> To: Black, David
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: Gen ART review of 
> draft-ietf-avt-compact-bundled-evrc-09.txt
> 
> Hi, David,
> 
> Thanks for the review and comments. Please see my response in-line.
> 
> [email-masked] wrote:
> 
> > I have been selected as the General Area Review Team 
> (Gen-ART) reviewer for this draft (for background on Gen-ART, please
see 
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
> > Please resolve these comments along with any other Last Call
comments you may receive.
> > Document:
> >        Enhancements to RTP Payload Formats for EVRC Family Codecs
> >                draft-ietf-avt-compact-bundled-evrc-09.txt
> > Reviewer: David L. Black
> > Review Date: September 29, 2006
> > IETF LC Date: Ends October 9
> >
> > Summary: This draft is on the right track, but has open issues
> > described in the review.
> >
> > Comments:
> >
> > This draft is in good shape.  There are two relatively small open
> > issues (marked with *** below):
> > - Magic number use of \n
> > - Ability to change defaults
> > Everything else is editorial.
> >
> > I think the draft should have it's title edited to better represent
> > what it specifies.  The title of the draft is:
> >
> >        Enhancements to RTP Payload Formats for EVRC Family Codecs
> >
> > but Section 3.1 says:
> >
> >    Other frame-based vocoders can be carried in the packet formats
> >    defined in this document, as long as they possess the following
> >    properties:
> >
> > This indicates that the new format is more widely usable.  There's
> > only one new format, so a better draft title would be:
> >
> >   The RTP Compact Bundled Format and Additional EVRC Family Codecs
> >
> > Also, since there's only one packet format defined in this draft,
> > change "packet formats" to "packet format" in the text quoted from
> > Section 3.1 above.
> 
> Section 3.1 is essentially copied from RFC3558 word by word and dealt
> with in the same way here.
> 
> Since specifying a widely usable RTP format is NOT the focus of this
> work, we'd propose to remove section 3.1 and keep the current title.
> 
> If you STILL feel a change to the title is necessary, we'd 
> like to propose:
> 
> "The RTP Compact Bundled Format and Enhancements to RTP Payload
Formats
> for EVRC Family Codecs"
> 
> >
> > Section 5: Remove the quotes surrounding the hexadecimal form of
> > the magic number in:
> >
> >     "0x23 0x21 0x45 0x56 0x52 0x43 0x2D 0x42 0x0A"
> >
> > as that's not supposed to be a text string - the text string
> > is given earlier as "#!EVRC-B\n" .
> 
> 
> We can either remove it as suggested, or change it as follows 
> (following
> the way it is dealt with in section 5.1 in RFC3267):
> 
>        "#!EVRC-B\n"
>        (or 0x2321455652432d420a in hexadecimal).
> 
> We prefer making the change but will be fine with either approach.
> 
> >
> >    Note, the "\n" is an important part of the magic number and MUST
be
> >    included in the comparison, since, otherwise, the EVRC-B magic
number
> >    will become indistinguishable from magic number used for EVRC.
> >
> > *** That's somewhat sloppy.  Can this magic number be changed to
> > actually have a different visual presentation, as opposed to only
> > differing in a non-printable character that is often stripped in
> > text string processing?  It would be ok (but disappointing) if this
> > were not possible due to the amount of installed base/running code
> > using that magic number.
> 
> 
> This text is modeled (almost word by word) after section 5.1 of
RFC3267.
> The visual presentation is already different ("#!EVRC-B" vs.
"#!EVRC"), 
> the Note is just meant to be a friendly reminder to an inexperienced 
> programmer, which may be unnecessary. We can remove it if you feel 
> necessary.
> 
> If you STILL feel the magic number needs to be changed, we'd propose 
> "#!EVCB\n" for EVRC-B.
> 
> >    The ToC field is extended to one octet by setting the four
> >    most significant bits of the octet to zero.  For example, a
> >    ToC value of 4 (a full-rate frame) is stored as 0x04.
> >
> > Explain where the ToC values come from.  Citing Section 5.1 of RFC
> > 3558 should be sufficient.
> 
> Ok.
> 
> >
> > Section 6: Add a note at the start of this section:
> >
> > -- RFC Editor: Please replace all instances of "RFC XXXX" in
> > this section with the RFC number of this document prior to
> > IANA registration and RFC publication, and remove this note.
> 
> Ok.
> 
> >
> > In the definition of silencesupp:
> >
> >          If this parameter is not present, the default value
specified
> >          in [8] MUST be assumed.
> >
> > Say what that default value is, especially as [8] is a 3GPP2
> > document, not an IETF document.
> 
> Ok.
> 
> >
> > In the definition of dtxmin:
> >
> >          If this parameter is not present, the default value, 12, as
> >          specified in [8] MUST be assumed (note, if a later version
of
> >          [8] specifies a new, different value, the new value will
take
> >          precedence).
> > *** That's better, but the ability of 3GPP2 to change the default
looks
> > like it could cause an interoperability problem (applies to
silencesupp,
> > dtxmin, dtxmax, and hangover).  How will this be addressed? This
needs
> > to be explained.
> 
> A few thoughts:
> 
> 1. Due to the way the 4 parameters are used, even if the two ends
> mistakenly assume a different set of default values, they most likely
> should still be able to inter-operate, with *maybe* a bit suboptimal
> performance in some implementation.
> 
> 2. The note is meant for future-proof but maybe a bit unnecessary
since
> there is no evidence that I am aware of that 3GPP2 is going to change
> the default values soon. We can perhaps remove that note.  (Any spec
with
> default values would face the same situation if for some good reasons
> one or more default value needs to be changed in the future). There is
> nothing special for this document.
> 
> Our proposal is to remove the note.
> 
> >
> > Sections 6.5 and 6.6 should instruct IANA to change the
registrations
> > of EVRC and EVRC0 to reference this RFC instead of RFC 3558.
> 
> Ok.
> 
> regards,
> -Qiaobing
> 
> >
> > Thanks,
> > --David
> > ----------------------------------------------------
> > David L. Black, Senior Technologist
> > EMC Corporation, 176 South St., Hopkinton, MA  01748
> > +1 (508) 293-7953             FAX: +1 (508) 293-7786
> > [email-masked]        Mobile: +1 (978) 394-7754
> > ----------------------------------------------------
> >

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Colin Perkins <[email-masked]>
Date: Tue, 10 Oct 2006 09:03:56 +0100

David, Qiaobing,

On 9 Oct 2006, at 23:55, [email-masked] wrote:
...
> impact of this issue, as I'm not sufficiently expert to make the call.

Qiaobing is the expert on this codec. As working group chair, I'm  
happy to go with his opinion on this issue. This seems like a minor  
issue, with no impact on the larger protocol design choices.

Colin

---

From: Qiaobing Xie <[email-masked]>
Date: Thu, 12 Oct 2006 00:38:20 -0500

Hi, David, Colin,

...
> Qiaobing is the expert on this codec. As working group chair, I'm happy
> to go with his opinion on this issue. This seems like a minor issue,
> with no impact on the larger protocol design choices.
>

I agree with Colin. There is no impact on the protocol design here.

In the rather unlikely event (I can't still think of a reason for it to
happen) that someone wants to change the defaults, a new RFC (or a new
3GPP2 spec) probably will have to be created to not only specify the
exact changes, but also give meaningful analysis and address any
potential inter-op issues. Those discussions seems out of scope of this
RFC. That's the reason I propose to remove the misleading note.

regards,
-Qiaobing

---

From: Qiaobing Xie <[email-masked]>
Date: Thu, 12 Oct 2006 00:38:20 -0500

Hi, David, Colin,

...

regards,
-Qiaobing

---

From: Qiaobing Xie <[email-masked]>
Date: Thu, 12 Oct 2006 00:32:46 -0500

Hi, David, Colin,

...

exact changes, but also give meaningful analysis and address on any 

regards,
-Qiaobing

[email-masked] Thu Oct 12 06:47:46 2006
Date: Thu, 12 Oct 2006 00:32:46 -0500
From: Qiaobing Xie <[email-masked]>
To: Colin Perkins <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked],
	[email-masked], [email-masked]
Subject: [Gen-art] Re: Gen ART review of
	draft-ietf-avt-compact-bundled-evrc-09.txt

Hi, David, Colin,

...

exact changes, but also give meaningful analysis and address on any 

regards,
-Qiaobing

---

From: [email-masked]
Date: Thu, 12 Oct 2006 10:37:19 -0400

"default change requires new RFC" is fine with me, and Qiaobing's
proposal to just remove the notes about possible 3GPP2 changes to
defaults is a reasonable way to get there.   Thanks, --David

> Sent: Thursday, October 12, 2006 1:33 AM
> To: Colin Perkins
> Cc: Black, David; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
happy

---

From: Colin Perkins <[email-masked]>
Date: Thu, 12 Oct 2006 22:59:48 +0100

Okay, so let's wait for a revised draft, then consider this again.

Thanks,
Colin

---

From: Qiaobing Xie <[email-masked]>
Date: Sat, 14 Oct 2006 08:53:05 -0500

Dear I-D Editor,

Please accept and publish the attached 
draft-ietf-avt-compact-bundled-evrc-10.txt.

Others,

This revision contains the following changes:

- Changed the title of Section 6 to "Media Type Definitions" and added 
Section 8 "IANA Considerations", per IANA review comments.

- Cited "Section 5.1 of RFC 3558" to explain where the ToC values come 
from, per Gen ART review comments

- Added a note to RFC Editor to replace all instances of "RFC XXXX" in 
final publication, per Gen ART review comments

- Specify silencesupp default value explicitly for all media types, per 
Gen ART review comments

- Removed old section 3.1 to clarify that this RFC defines only EVRC 
formats, per Gen ART review comments

- removed the quotes surrounding the hexadecimal form of the magic 
number to avoid confusion, per Gen ART review comments

- editorial clarification of the importance of the "\n" in EVRC-B magic 
number, per Gen ART review comments

- expanded EVRC near the start, per security directorate's review comments

regards,
-Qiaobing

Network Working Group                                             Q. Xie
Internet-Draft                                                  Motorola
Updates: RFC 3558 (if approved)                                R. Kapoor
Expires: April 17, 2007                                         Qualcomm
                                                        October 14, 2006

       Enhancements to RTP Payload Formats for EVRC Family Codecs
               draft-ietf-avt-compact-bundled-evrc-10.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 17, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document updates the Enhanced Variable Rate Codec (EVRC) RTP
   payload formats defined in RFC 3558 with several enhancements and
   extensions.  In particular, it defines support for the header-free
   and interleaved/bundled packet formats for the EVRC-B codec, a new
   compact bundled format for the EVRC and EVRC-B codecs, as well as
   discontinuous transmission (DTX) support for EVRC and EVRC-B encoded
   speech transported via RTP.  VoIP applications operating over low

Xie & Kapoor             Expires April 17, 2007                 [Page 1]

Internet-Draft        EVRC RTP Format Enhancements          October 2006

   bandwidth dial-up and wireless networks require such enhancements for
   efficient use of the bandwidth.

Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1  Support of EVRC-B Codec  . . . . . . . . . . . . . . . . .   3
     1.2  Compact (Header-free) Bundled Format . . . . . . . . . . .   3
     1.3  Discontinuous Transmission (DTX) . . . . . . . . . . . . .   4
   2.   Conventions  . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.   EVRC-B Codec . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.   Compact Bundled Format . . . . . . . . . . . . . . . . . . .   5
     4.1  Single Rate Operation  . . . . . . . . . . . . . . . . . .   5
   5.   Storage Format For EVRC-B Codec  . . . . . . . . . . . . . .   6
   6.   Media Type Definitions . . . . . . . . . . . . . . . . . . .   6
     6.1  Registration of Media Type EVRC1 . . . . . . . . . . . . .   6
     6.2  Registration of Media Type EVRCB . . . . . . . . . . . . .   9
     6.3  Registration of Media Type EVRCB0  . . . . . . . . . . . .  11
     6.4  Registration of Media Type EVRCB1  . . . . . . . . . . . .  12
     6.5  Updated Registration of Media Type EVRC  . . . . . . . . .  13
     6.6  Updated Registration of Media Type EVRC0 . . . . . . . . .  15
     6.7  Mapping MIME Parameters into SDP . . . . . . . . . . . . .  17
     6.8  Usage in Offer/Answer  . . . . . . . . . . . . . . . . . .  18
   7.   Backward Compatibility with RFC 3558 . . . . . . . . . . . .  19
   8.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .  19
   9.   Security Considerations  . . . . . . . . . . . . . . . . . .  19
   10.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  19
   11.  References . . . . . . . . . . . . . . . . . . . . . . . . .  20
     11.1   Normative References . . . . . . . . . . . . . . . . . .  20
     11.2   Informative References . . . . . . . . . . . . . . . . .  20
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  21
        Intellectual Property and Copyright Statements . . . . . . .  22

Xie & Kapoor             Expires April 17, 2007                 [Page 2]

Internet-Draft        EVRC RTP Format Enhancements          October 2006

1.  Introduction

   This document defines support for the header-free and interleaved/
   bundled packet formats for the EVRC-B codec, a new compact bundled
   format for the EVRC and EVRC-B codecs, as well as discontinuous
   transmission (DTX) support for EVRC and EVRC-B encoded speech
   transported via RTP.  VoIP applications operating over low bandwidth
   dial-up and wireless networks require such EVRC RTP payload
   capabilities for efficient use of the bandwidth.

1.1  Support of EVRC-B Codec

   EVRC-B [3] is an extension to [2] developed in 3GPP2.  EVRC-B [3]
   compresses each 20 milliseconds of 8000Hz, 16-bit sampled speech
   input into output frames of one of the four different sizes: Rate 1
   (171 bits), Rate 1/2 (80 bits), Rate 1/4 (40 bits), or Rate 1/8 (16
   bits).  In addition, there are two zero bit codec frame types: null
   frames and erasure frames, similar to EVRC [2].  One significant
   enhancement in EVRC-B is the use of 1/4 rate frames that were not
   used in EVRC.  This provides lower average data rates (ADRs) compared
   to EVRC, for a given voice quality.

   Since speech frames encoded by EVRC-B are different from those
   encoded by EVRC, EVRC-B and EVRC codecs do not interoperate with each
   other.  At the initiation of a RTP session, the RTP sender and
   receiver need to indicate (e.g., using MIME subtypes that are
   separate from those of EVRC) that EVRC-B is to be used for the
   ensuing session.

1.2  Compact (Header-free) Bundled Format

   The current interleaved/bundled packet format defined in RFC 3558
   allows bundling of multiple speech frames of different rate in a
   single RTP packet, sending mode change requests, and interleaving.
   To support these functions, a Table of Contents (ToC) is used in each
   RTP packet in addition to the standard RTP header.  The size of the
   ToC is variable, depending on the number of EVRC frames carried in
   the packet [4].

   The current header-free packet format defined in RFC 3558 is more
   compact and optimized for use over wireless links.  It eliminates the
   need for a ToC by requiring that each RTP packet contain only one
   speech frame (of any allowable rate), i.e., bundling is not allowed.
   Moreover, interleaving and mode change request are not supported in
   the header-free format [4].

   The compact bundled format described in this document presents the
   user an alternative to the header-free format defined in RFC 3558.

Xie & Kapoor             Expires April 17, 2007                 [Page 3]

Internet-Draft        EVRC RTP Format Enhancements          October 2006

   This format allows bundling of multiple EVRC or EVRC-B frames without
   the addition of extra headers, as would be in case of the
   interleaved/bundled format.  However, in order to use this compact
   bundled format, only one EVRC/EVRC-B rate (full rate or 1/2 rate) can
   be used in the session.  Similar to the header-free format defined in
   RFC 3558, interleaving and mode change request are not supported in
   the compact bundled format.

1.3  Discontinuous Transmission (DTX)

   Information carried in frames of EVRC and EVRC-B codecs varies little
   during periods of silence.  The transmission of these frames across
   the radio interface in a wireless system is expensive in terms of
   capacity, and therefore, suppression of these frames is desirable.
   Such an operation is called DTX, also known as silence suppression.

   In general, when DTX/silence suppression is applied, the first few
   frames of silence may be transmitted at the beginning of the period
   of silence to establish background noise.  Then a portion of the
   stream of subsequent silence frames is not transmitted and is
   discarded at the sender.  At the receiver, background or comfort
   noise may be generated by using the previously received silence
   frames.

   The full detail of DTX/silence suppression operation can be found in
   [8] as well as RFC 3551 [9] and RFC 3558 [4].  This document only
   defines the additional optional MIME parameters (silencesupp, dtxmax,
   dtxmin, and hangover) for setting up a DTX/silence suppression
   session, where "silencesupp" is for indicating the capability and
   willingness of using DTX/silence suppression, "dtxmax" and "dtxmin"
   for indicating the desired range of DTX update interval, and
   "hangover" for indicating the desired number of silence frames at the
   beginning of each silence period to establish background noise at the
   receiver (see Section 6.1 for detailed definition).

   The EVRC and EVRC-B codecs in variable rate operation mode send 1/8
   rate frames during periods of silence, while in single rate operation
   mode (see Section 4), silence is encoded and sent in frames of the
   same rate as that of speech frames.  The DTX parameters defined in
   this document apply to 1/8th rate frames in the variable rate mode
   and to silence frames in the single rate operation mode.

   For simplicity, in the rest of this document the term "silence frame"
   refers either to an 1/8th rate frame in variable rate operation or a
   frame that contains only silence in the signal rate operation.

Xie & Kapoor             Expires April 17, 2007                 [Page 4]

Internet-Draft        EVRC RTP Format Enhancements          October 2006

2.  Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [1].

3.  EVRC-B Codec

   Three RTP packet formats are supported for the EVRC-B codec - the
   interleaved/bundled packet format, the header-free packet format and
   the compact bundled packet format.  For the interleaved/bundled and
   header-free packet formats, the operational details and capabilities,
   such as ToC, interleaving, and bundling, of EVRC-B are exactly the
   same as those of EVRC, as defined in RFC 3558 [4], except that the
   mode change request field in the ToC MUST be interpreted according to
   the definition of the RATE_REDUC parameter in EVRC-B [3].  The
   compact bundled packet format for EVRC-B is defined in Section 4 of
   this document.

4.  Compact Bundled Format

   A packet in the compact bundled format consists of an RTP header
   followed by a sequence of one or more consecutive EVRC/EVRC-B codec
   data frames of the same rate, as shown below:

    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 [4]                           |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |                                                               |
   |       One or more EVRC/EVRC-B data frames of same rate        |
   |                             ....                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The codec data frames MUST be generated from the output of the codec
   following the procedure described in 5.2 in RFC 3558 [4] and all MUST
   be of the same rate and size.

4.1  Single Rate Operation

   As mentioned earlier, in order to use the compact bundled format, all
   the EVRC/EVRC-B data frames in the session MUST be of the same rate.
   This packet format may carry only full or half-rate frames.

   For a session that uses the compact bundled format, the rate for the
   session can be determined during the session setup signaling, for
   example, via SDP exchanges.  See Section 6 below for more details.

Xie & Kapoor             Expires April 17, 2007                 [Page 5]

Internet-Draft        EVRC RTP Format Enhancements          October 2006

5.  Storage Format For EVRC-B Codec

   The storage format is used for storing EVRC-B encoded speech frames,
   e.g., as a file or e-mail attachment.

   The file begins with a magic number to identify the vocoder that is
   used.  The magic number for EVRC-B corresponds to the ASCII character
   string:

          "#!EVRC-B\n"
          (or 0x2321 0x4556 0x5243 0x2d42 0x0a in hexadecimal).

   Note, the "\n" is an important part of both this magic number and the
   "#!EVRC\n" magic number defined in Section 11 of RFC 3558 and the
   "\n" MUST be included in any comparison of either magic number,
   since, otherwise, a prefix of the EVRC-B magic number could be
   mistaken for the EVRC magic number.

   The codec data frames are stored in consecutive order, with a single
   TOC entry field, extended to one octet, prefixing each codec data
   frame.  The ToC field as defined in Section 5.1 of [4] is extended to
   one octet by setting the four most significant bits of the octet to
   zero.  For example, a ToC value of 4 (a full-rate frame) is stored as
   0x04.

   Speech frames lost in transmission and non-received frames MUST be
   stored as erasure frames to maintain synchronization with the
   original media.

6.  Media Type Definitions

   [-- RFC Editor: Please replace all instances of "RFC XXXX" in this
   and subsequent sections with the RFC number of this document prior to
   IANA registration and RFC publication, and remove this note.]

6.1  Registration of Media Type EVRC1

   Type name: audio

   Subtype names: EVRC1

   Required parameters: none

   Optional parameters:

Xie & Kapoor             Expires April 17, 2007                 [Page 6]

Internet-Draft        EVRC RTP Format Enhancements          October 2006

      ptime: see RFC 4566 [7].

      maxptime: The maximum amount of media which can be encapsulated in
         each packet, expressed as time in milliseconds.  The time MUST
         be calculated as the sum of the time the media present in the
         packet represents.  The time SHOULD be a multiple of the
         duration of a single codec data frame (20 msec).  If not
         signaled, the default maxptime value MUST be 200 milliseconds.

      fixedrate: Indicates the EVRC 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: Permissible values are 0 and 1.  A value of 1
         indicates that the sender of this parameter: a) is capable of
         receiving silence suppressed speech using DTX, AND b) is
         capable of and will send out silence suppressed speech using
         DTX, unless the other end indicates that it does not want to
         receive silence suppressed speech using DTX.

         A value of 0 indicates that the sender of this parameter: a)
         does NOT want to receive silence suppressed speech using DTX,
         AND b) will NOT send out silence suppressed speech using DTX.

         If this parameter is not present, the default value 0 MUST be
         assumed.  If the RTP receiver indicates through the use of SIP
         signaling or other means that it is incapable of or unwilling
         to use silence suppression using DTX, silence suppression using
         DTX as specified in this document MUST NOT be used for the
         session.

      dtxmax: Permissible values are from 0 to 255.  Indicates the
         maximum DTX update interval in number of frames.  During DTX,
         the RTP sender occasionally updates the RTP receiver about the
         change in background noise characteristics, etc., by sending a
         new silence frame to the RTP receiver.  The RTP receiver may
         use 'dtxmax' to indicate to the RTP sender the maximum interval
         (in number of frames) between any two DTX updates it expects to
         receive from the RTP sender.

         If this parameter is not present in a session that uses DTX,
         the default value, 32, as specified in [8] MUST be assumed.
         This parameter MUST be ignored if silence suppression using DTX
         is not used for the session.

         Note also that if the RTP receiver elects to detect DTX using

Xie & Kapoor             Expires April 17, 2007                 [Page 7]

Internet-Draft        EVRC RTP Format Enhancements          October 2006

         dtxmax, the dtxmax parameter will affect the amount of delay
         the RTP receiver sees before detecting DTX in the stream.

      dtxmin: Permissible values are from 0 to 255.  Indicates the
         minimum DTX update interval in number of frames.  The RTP
         receiver may use 'dtxmin' to indicate to the RTP sender the
         minimal interval (in number of frames) between any two DTX
         updates it expects to receive from the RTP sender.

         If this parameter is not present, the default value, 12, as
         specified in [8] MUST be assumed.  This parameter MUST be
         ignored if silence suppression using DTX is not used for the
         session.

      hangover: Permissible values are from 0 to 255.  Indicates the
         number of consecutive silence frames transmitted at the end of
         an active speech interval but before the DTX interval begins.
         When setting up an RTP session that uses DTX, an RTP receiver
         can use this parameter to signal the number of silence frames
         it expects to receive before the beginning of DTX.  While
         hangover=0 is allowed, it is RECOMMENDED that hangover be set
         to 1 or greater since the presence of silence frames at the end
         of active speech can help the RTP receiver to identify the
         beginning of the DTX period.

         If this parameter is not present for a session that uses DTX,
         the default value, 1, as specified in [8] MUST be assumed.
         This parameter MUST be ignored if silence suppression using DTX
         is not used for the session.

   Encoding considerations:
      This media type is framed binary data (see RFC 4288, Section 4.8)
      and is defined for transfer of EVRC encoded data via RTP using the
      compact bundled format as described in RFC XXXX.

   Security considerations: See Section 9 of RFC XXXX.

   Interoperability considerations: none

   Published specification:
      The EVRC vocoder is specified in 3GPP2 C.S0014 [2].  Transfer
      method with compact bundled RTP format is specified in RFC XXXX.

   Applications that use this media type:
      It is expected that many VoIP applications (as well as mobile
      applications) will use this type.

Xie & Kapoor             Expires April 17, 2007                 [Page 8]

Internet-Draft        EVRC RTP Format Enhancements          October 2006

   Additional information: none

   Person & email address to contact for further information:
      Qiaobing Xie <[email-masked]>

   Intended usage: COMMON

   Restrictions on usage:
      This media type depends on RTP framing, and hence is only defined
      for transfer via RTP (RFC 3550 [5]).  Transfer within other
      framing protocols is not defined at this time.

   Author:
      Qiaobing Xie

   Change controller:
      IETF Audio/Video Transport working group delegated from the IESG.

6.2  Registration of Media Type EVRCB

   Type name: audio

   Subtype names: EVRCB

   Required parameters: none

   Optional parameters:

      ptime: see RFC 4566 [7].

      maxptime: The maximum amount of media which can be encapsulated in
         each packet, expressed as time in milliseconds.  The time MUST
         be calculated as the sum of the time the media present in the
         packet represents.  The time SHOULD be a multiple of the
         duration of a single codec data frame (20 msec).  If not
         signaled, the default maxptime value MUST be 200 milliseconds.

      maxinterleave: Maximum number for interleaving length (field LLL
         in the Interleaving Octet).  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 for definition.  If this parameter is
         not present, the default value 0 MUST be assumed.

Xie & Kapoor             Expires April 17, 2007                 [Page 9]

Internet-Draft        EVRC RTP Format Enhancements          October 2006

      dtxmax: see Section 6.1

      dtxmin: see Section 6.1

      hangover: see Section 6.1

   Encoding considerations:
      This media type is framed binary data (see RFC 4288, Section 4.8)
      and is defined for transfer of EVRC-B encoded data via RTP using
      the Interleaved/Bundled packet format specified in RFC 3558 [4].

   Security considerations: See Section 9 of RFC XXXX.

   Interoperability considerations: none

   Published specification:
      The EVRC-B vocoder is specified in 3GPP2 C.S0014-B [3].  Transfer
      method with Interleaved/Bundled packet format via RTP is specified
      in RFC 3558.

   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 information applies for storage format only.

      Magic number: #!EVRC-B\n (see Section 5 of RFC XXXX)
      File extensions: evb, EVB
      Macintosh file type code: none
      Object identifier or OID: none

   Person & email address to contact for further information:
      Qiaobing Xie <[email-masked]>

   Intended usage: COMMON

   Restrictions on usage:
      This media type may be used with RTP framing (RFC 3550 [5]) and as
      a storage format.  When used with RTP, the procedures in Section 3
      MUST be followed.  In all other contexts, the storage format
      defined in Section 5 MUST be used.

   Author:
      Qiaobing Xie

Xie & Kapoor             Expires April 17, 2007                [Page 10]

Internet-Draft        EVRC RTP Format Enhancements          October 2006

   Change controller:
      IETF Audio/Video Transport working group delegated from the IESG.

6.3  Registration of Media Type EVRCB0

   Type name: audio

   Subtype names: EVRCB0

   Required parameters: none

   Optional parameters:

      silencesupp: see Section 6.1 for definition.  If this parameter is
         not present, the default value 0 MUST be assumed.

      dtxmax: see Section 6.1

      dtxmin: see Section 6.1

      hangover: see Section 6.1

   Encoding considerations:
      This media type is framed binary data (see RFC 4288, Section 4.8)
      and is defined for transfer of EVRC-B encoded data via RTP using
      the Header-Free packet format specified in RFC 3558 [4].

   Security considerations: See Section 9 of RFC XXXX.

   Interoperability considerations: none

   Published specification:
      The EVRC-B vocoder is specified in 3GPP2 C.S0014-B [3].  Transfer
      method with Header-Free packet format via RTP is specified in RFC
      3558 and RFC XXXX.

   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:
      Qiaobing Xie <[email-masked]>

Xie & Kapoor             Expires April 17, 2007                [Page 11]

Internet-Draft        EVRC RTP Format Enhancements          October 2006

   Intended usage: COMMON

   Restrictions on usage:
      This media type depends on RTP framing, and hence is only defined
      for transfer via RTP (RFC 3550 [5]).  Transfer within other
      framing protocols is not defined at this time.

   Author:
      Qiaobing Xie

   Change controller:
      IETF Audio/Video Transport working group delegated from the IESG.

6.4  Registration of Media Type EVRCB1

   Type name: audio

   Subtype names: EVRCB1

   Required parameters: none

   Optional parameters:

      ptime: see RFC 4566 [7].

      maxptime: The maximum amount of media which can be encapsulated in
         each packet, expressed as time in milliseconds.  The time MUST
         be calculated as the sum of the time the media present in the
         packet represents.  The time SHOULD be a multiple of the
         duration of a single codec data frame (20 msec).  If not
         signaled, the default maxptime value MUST be 200 milliseconds.

      fixedrate: Indicates the EVRC-B 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 for definition.  If this parameter is
         not present, the default value 0 MUST be assumed.

      dtxmax: see Section 6.1

      dtxmin: see Section 6.1

Xie & Kapoor             Expires April 17, 2007                [Page 12]

Internet-Draft        EVRC RTP Format Enhancements          October 2006

      hangover: see Section 6.1

   Encoding considerations:
      This media type is framed binary data (see RFC 4288, Section 4.8)
      and is defined for transfer of EVRC-B encoded data via RTP using
      the compact bundled format as described in RFC XXXX.

   Security considerations: See Section 9 of RFC XXXX.

   Interoperability considerations: none.

   Published specification:
      The EVRC-B vocoder is specified in 3GPP2 C.S0014-B [3].  Transfer
      method with compact bundled RTP format is specified in RFC XXXX.

   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:
      Qiaobing Xie <[email-masked]>

   Intended usage: COMMON

   Restrictions on usage:
      This media type depends on RTP framing, and hence is only defined
      for transfer via RTP (RFC 3550 [5]).  Transfer within other
      framing protocols is not defined at this time.

   Author:
      Qiaobing Xie

   Change controller:
      IETF Audio/Video Transport working group delegated from the IESG.

6.5  Updated Registration of Media Type EVRC

   (The definition is from RFC 3558, added with the optional DTX
   parameters, and updated with the new template specified in [10].)

   Type name: audio

Xie & Kapoor             Expires April 17, 2007                [Page 13]

Internet-Draft        EVRC RTP Format Enhancements          October 2006

   Subtype names: EVRC

   Required parameters: none

   Optional parameters:

      ptime: Defined as usual for RTP audio (see RFC 4566).

      maxptime: The maximum amount of media which can be encapsulated in
         each packet, expressed as time in milliseconds.  The time SHALL
         be calculated as the sum of the time the media present in the
         packet represents.  The time SHOULD be a multiple of the
         duration of a single codec data frame (20 msec).  If not
         signaled, the default maxptime value SHALL be 200 milliseconds.

      maxinterleave: Maximum number for interleaving length (field LLL
         in the Interleaving Octet).  The interleaving lengths used in
         the entire session MUST NOT exceed this maximum value.  If not
         signaled, the maxinterleave length SHALL be 5.

      silencesupp: see Section 6.1 for definition.  If this parameter is
         not present, the default value 1 MUST be assumed.

      dtxmax: see Section 6.1

      dtxmin: see Section 6.1

      hangover: see Section 6.1

   Encoding considerations:
      This media type is framed binary data (see RFC 4288, Section 4.8)
      and is defined for transfer of EVRC-encoded data via RTP using the
      Interleaved/Bundled packet format specified in Sections 4.1, 6,
      and 7 of RFC 3558.  It is also defined for other transfer methods
      using the storage format specified in Section 11 of RFC 3558.

   Security considerations: See Section 14 "Security Considerations" of
      RFC 3558.

   Interoperability considerations:
      The DTX parameters are receiver options.  Existing RFC 3558
      implementations will not send any of the DTX parameters in their
      SDP and will ignore any DTX parameters they receive.  The adaptive
      DTX behavior of DTX-capable EVRC codecs (as detailed in [8],
      Section 4.3.5) ensures interoperability with non-DTX EVRC codecs.

Xie & Kapoor             Expires April 17, 2007                [Page 14]

Internet-Draft        EVRC RTP Format Enhancements          October 2006

   Published specification: The EVRC vocoder is specified in 3GPP2
      C.S0014.  Transfer methods are specified in RFC 3558.

   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 information applies for storage format only.

         Magic number: #!EVRC\n (see Section 11 of RFC 3558)
         File extensions: evc, EVC
         Macintosh file type code: none
         Object identifier or OID: none

   Person & email address to contact for further information:
      Qiaobing Xie <[email-masked]>

   Intended usage: COMMON

   Restrictions on usage:
      This media type may be used with RTP framing (RFC 3550 [5]) and as
      a storage format.  When used with RTP, the procedures in RFC 3558,
      Section 4.1 MUST be followed.  In all other contexts, the storage
      format defined in RFC 3558, Section 11 MUST be used.

   Author:
      Adam Li/Qiaobing Xie

   Change controller:
      IETF Audio/Video Transport working group delegated from the IESG.

6.6  Updated Registration of Media Type EVRC0

   (The definition is from RFC 3558, added with the optional DTX
   parameters, and updated with the new template specified in [10].)

   Type name: audio

   Subtype names: EVRC0

   Required parameters: none

   Optional parameters:

Xie & Kapoor             Expires April 17, 2007                [Page 15]

Internet-Draft        EVRC RTP Format Enhancements          October 2006

      silencesupp: see Section 6.1 for definition.  If this parameter is
         not present, the default value 1 MUST be assumed.

      dtxmax: see Section 6.1

      dtxmin: see Section 6.1

      hangover: see Section 6.1

   Encoding considerations:
      This media type is framed binary data (see RFC 4288, Section 4.8)
      and is only defined for transfer of EVRC-encoded data via RTP
      using the Header-Free packet format specified in Section 4.2 of
      RFC 3558.

   Security considerations: See Section 14 "Security Considerations" of
      RFC 3558.

   Interoperability considerations:
      The DTX parameters are receiver options.  Existing RFC 3558
      implementations will not send any of the DTX parameters in their
      SDP and will ignore any DTX parameters they receive.  The adaptive
      DTX behavior of DTX-capable EVRC codecs (as detailed in [8],
      Section 4.3.5) ensures interoperability with non-DTX EVRC codecs.

   Published specification:
      The EVRC vocoder is specified in 3GPP2 C.S0014.  Transfer methods
      are specified in RFC 3558.

   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:
      Qiaobing Xie <[email-masked]>

   Intended usage: COMMON

   Restrictions on usage:
      This media type depends on RTP framing, and hence is only defined
      for transfer via RTP (RFC 3550 [5]).  Transfer within other
      framing protocols is not defined at this time.

Xie & Kapoor             Expires April 17, 2007                [Page 16]

Internet-Draft        EVRC RTP Format Enhancements          October 2006

   Author:
      Adam Li/Qiaobing Xie

   Change controller:
      IETF Audio/Video Transport working group delegated from the IESG.

6.7  Mapping MIME Parameters into SDP

   The information carried in the MIME media type specification has a
   specific mapping to fields in the Session Description Protocol (SDP)
   [7], which is commonly used to describe RTP sessions.  When SDP is
   used to specify sessions employing the compact bundled format for
   EVRC/EVRC-B encoded speech, the mapping is as follows:

   o  The MIME type ("audio") goes in SDP "m=" as the media name.

   o  The MIME subtype ("EVRC", "EVRC0", "EVRC1", "EVRCB", EVRCB0", or
      "EVRCB1") goes in SDP "a=rtpmap" as the encoding name.

   o  The optional parameters "ptime" and "maxptime" (for subtypes EVRC,
      EVRC1, EVRCB, and EVRCB1) go in the SDP "a=ptime" and "a=maxptime"
      attributes, respectively.

   o  The optional parameter "maxinterleave" (for subtypes EVRC and
      EVRCB) goes in the SDP "a=fmtp" attribute by copying it directly
      from the MIME media type string as "maxinterleave=value".

   o  The optional parameter "fixedrate" (for subtypes EVRC1 and EVRCB1)
      goes in "a=fmtp" attribute by copying it directly from the MIME
      media type string as "fixedrate=value".

   o  The optional parameters "silencesupp", "dtxmax", "dtxmin", and
      "hangover" go in "a=fmtp" attribute by copying it directly from
      the MIME media type string as "silencesupp=value", "dtxmax=value",
      "dtxmin=value", and "hangover=value", respectively.

   Example of usage of EVRC1:

     m=audio 49120 RTP/AVP 97
     a=rtpmap:97 EVRC1/8000
     a=fmtp:97 fixedrate=0.5
     a=maxptime:120

   Example of usage of EVRCB:

     m=audio 49120 RTP/AVP 97
     a=rtpmap:97 EVRCB/8000

Xie & Kapoor             Expires April 17, 2007                [Page 17]

Internet-Draft        EVRC RTP Format Enhancements          October 2006

     a=maxptime:120

   Example of usage of EVRCB0:

     m=audio 49120 RTP/AVP 97
     a=rtpmap:97 EVRCB0/8000

   Example of usage of EVRCB1:

     m=audio 49120 RTP/AVP 97
     a=rtpmap:97 EVRCB1/8000
     a=fmtp:97 fixedrate=0.5
     a=maxptime:100

   Example of usage of EVRC with DTX with silencesupp=1:

     m=audio 49120 RTP/AVP 97
     a=rtpmap:97 EVRC/8000
     a=fmtp:97 silencesupp=1 dtxmax=32 dtxmin=12 hangover=1

   Examples of usage of EVRC with DTX with silencesupp=0:

     m=audio 49120 RTP/AVP 97
     a=rtpmap:97 EVRC/8000
     a=fmtp:97 silencesupp=0

6.8  Usage in Offer/Answer

   All SDP parameters in this payload format are declarative, and all
   reasonable values are expected to be supported.  In particular, when
   DTX is supported, the RTP sender implementation SHOULD support
   hangover, dtxmin, and dtxmax values from 0 to 255.  Thus, the
   standard usage of Offer/Answer as described in RFC 3264 [6] SHOULD be
   followed.

   In addition, the following rules MUST be followed while negotiating
   DTX parameters:

   1.  If any DTX parameter is not present in either offer and/or
       answer, the default value of the DTX parameter MUST be assumed.

   2.  If silencesupp is present and set to 0 in either offer or answer,
       the values of all received DTX parameters other than silencesupp
       SHOULD be ignored.

   3.  In an offer or answer, the value of dtxmax SHOULD always be
       larger than or equal to the value of dtxmin, regardless of

Xie & Kapoor             Expires April 17, 2007                [Page 18]

Internet-Draft        EVRC RTP Format Enhancements          October 2006

       whether the values are indicated explicitly or implicitly by
       default.  Moreover, if the indicated value of dtxmin is larger
       than that of dtxmax, an RTP sender MUST ignore the indicated
       values and MUST fall back on using the default dtxmin and dtxmax
       values.

7.  Backward Compatibility with RFC 3558

   This document adds new optional DTX parameters to the original EVRC
   payload subtypes "EVRC" and "EVRC0" defined in RFC 3558.  Since the
   new DTX parameters are receiver options, we expect the existing RFC
   3558 implementations will not send any of the DTX parameters in their
   SDP and will ignore any DTX parameters they receive.  The adaptive
   DTX behavior of DTX-capable EVRC codecs (as detailed in [8], Section
   4.3.5) ensures the backward interoperability between the DTX-capable
   EVRC codec and non-DTX EVRC codecs.

8.  IANA Considerations

   Four (4) new MIME subtype registrations - "EVRC1", "EVRCB", "EVRCB0",
   and "EVRCB1" - are defined in this document (see Section 6.1 -
   Section 6.4) for EVRC-B and compact bundled payload format support.

   For all the EVRC and EVRC-B RTP payload formats defined in RFC 3558
   [4] and RFC XXXX, four additional optional parameters -
   "silencesupp", "dtxmax", "dtxmin", and "hangover" - are defined and
   used in DTX.

   The MIME subtype registrations, "EVRC" and "EVRC0" originally defined
   in RFC 3558 [4], are updated with the optional DTX parameters (see
   Section 6.5 and Section 6.6).

9.  Security Considerations

   Implementations using the payload defined in this specification are
   subject to the security considerations discussed in RFC 3558 [4], RFC
   3550 [5], and any appropriate profile (for example RFC 3551 [9]).
   This payload does not specify any different security services.

10.  Acknowledgments

   The following people have made significant contributions to this
   document (in alphabetic order): Parag Agashe, Jim Ashley, Harikishan
   Desineni, Serafin Diaz, Harinath Garudadri, Gouri Johanssen, Ananth
   Kandhadai, Waqar Mohsin, Ashok Roy, Gino Scribano, and Gajinder Singh
   Vij.

Xie & Kapoor             Expires April 17, 2007                [Page 19]

Internet-Draft        EVRC RTP Format Enhancements          October 2006

   Special thanks to Colin Perkins, Magnus Westerlund, and Adam Li for
   their careful review and comments that significantly improved the
   quality of this document.

11.  References

11.1  Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [2]  "Enhanced Variable Rate Codec, Speech Service Option 3 for
        Wideband Spread Spectrum Digital Systems", 3GPP2 C.S0014,
        January 1997.

   [3]  "Enhanced Variable Rate Codec, Speech Service Option 68 for
        Wideband Spread Spectrum Digital Systems", 3GPP2 C.S0014-B, in
        progress.

   [4]  Li, A., "RTP Payload Format for Enhanced Variable Rate Codecs
        (EVRC) and Selectable Mode Vocoders (SMV)", RFC 3558, July 2003.

   [5]  Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
        "RTP: A Transport Protocol for Real-Time Applications",
        RFC 3550, July 2003.

   [6]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
        the Session Description Protocol (SDP)", RFC 3264, June 2002.

   [7]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
        Description Protocol", RFC 4566, July 2006.

   [8]  "Discontinuous Transmission (DTX) of Speech in cdma2000
        Systems", 3GPP2 C.S0076-0, Version 1.0, December 2005.

11.2  Informative References

   [9]   Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
         Conferences with Minimal Control", RFC 3551, July 2003.

   [10]  Casner, S., "Media Type Registration of RTP Payload Formats",
         draft-ietf-avt-rfc3555bis-03.txt (work in progress),
         March 2006.

Xie & Kapoor             Expires April 17, 2007                [Page 20]

Internet-Draft        EVRC RTP Format Enhancements          October 2006

Authors' Addresses

   Qiaobing Xie
   Motorola, Inc.
   1501 W. Shure Drive, 2-F9
   Arlington Heights, IL  60004
   US

   Phone: +1-847-632-3028
   Email: [email-masked]

   Rohit Kapoor
   Qualcomm Inc.
   US

   Phone: +1-858-845-1161
   Email: [email-masked]

Xie & Kapoor             Expires April 17, 2007                [Page 21]

Internet-Draft        EVRC RTP Format Enhancements          October 2006

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Xie & Kapoor             Expires April 17, 2007                [Page 22]

---

From: "Kapoor, Rohit" <[email-masked]>
Date: Tue, 17 Oct 2006 13:43:50 -0700

Dear I-D Editor,

Please accept and publish the attached
draft-ietf-avt-compact-bundled-evrc-11.txt.

The revision contains the following changes:

-- While making the changes below, a couple of incorrect default values
had been entered by mistake (in Sections 6.1, 6.2 and 6.3). These have
been corrected.

Thanks,
Rohit

> Sent: Saturday, October 14, 2006 6:53 AM
> To: Colin Perkins; Drafts Editor
> Cc: Cullen Jennings; [email-masked]; [email-masked]; Kapoor,
Rohit;
> Tom-PT Taylor; Roni Even; [email-masked]
> Subject: RE: draft-ietf-avt-compact-bundled-evrc-10.txt
> 
> Dear I-D Editor,
>