Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS)
RFC 4848

Network Working Group                                          S. Ahmadi
Request for Comments: 4348                                  January 2006
Category: Standards Track

       Real-Time Transport Protocol (RTP) Payload Format for the
         Variable-Rate Multimode Wideband (VMR-WB) Audio Codec

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document specifies a real-time transport protocol (RTP) payload
   format to be used for the Variable-Rate Multimode Wideband (VMR-WB)
   speech codec.  The payload format is designed to be able to
   interoperate with existing VMR-WB transport formats on non-IP
   networks.  A media type registration is included for VMR-WB RTP
   payload format.

   VMR-WB is a variable-rate multimode wideband speech codec that has a
   number of operating modes, one of which is interoperable with AMR-WB
   (i.e., RFC 3267) audio codec at certain rates.  Therefore, provisions
   have been made in this document to facilitate and simplify data
   packet exchange between VMR-WB and AMR-WB in the interoperable mode
   with no transcoding function involved.

Ahmadi                      Standards Track                     [Page 1]
RFC 4348               VMR-WB RTP Payload Format            January 2006

Table of Contents

   1. Introduction ....................................................3
   2. Conventions and Acronyms ........................................3
   3. The Variable-Rate Multimode Wideband (VMR-WB) Speech Codec ......4
      3.1. Narrowband Speech Processing ...............................5
      3.2. Continuous vs. Discontinuous Transmission ..................6
      3.3. Support for Multi-Channel Session ..........................6
   4. Robustness against Packet Loss ..................................7
      4.1. Forward Error Correction (FEC) .............................7
      4.2. Frame Interleaving and Multi-Frame Encapsulation ...........8
   5. VMR-WB Voice over IP Scenarios ..................................9
      5.1. IP Terminal to IP Terminal .................................9
      5.2. GW to IP Terminal .........................................10
      5.3. GW to GW (between VMR-WB- and AMR-WB-Enabled Terminals) ...10
      5.4. GW to GW (between Two VMR-WB-Enabled Terminals) ...........11
   6. VMR-WB RTP Payload Formats .....................................12
      6.1. RTP Header Usage ..........................................13
      6.2. Header-Free Payload Format ................................14
      6.3. Octet-Aligned Payload Format ..............................15
           6.3.1. Payload Structure ..................................15
           6.3.2. The Payload Header .................................15
           6.3.3. The Payload Table of Contents ......................18
           6.3.4. Speech Data ........................................20
           6.3.5. Payload Example: Basic Single Channel
                  Payload Carrying Multiple Frames ...................21
      6.4. Implementation Considerations .............................22
           6.4.1. Decoding Validation and Provision for Lost
                  or Late Packets ....................................22
   7. Congestion Control .............................................23
   8. Security Considerations ........................................23
      8.1. Confidentiality ...........................................24
      8.2. Authentication and Integrity ..............................24
   9. Payload Format Parameters ......................................24
      9.1. VMR-WB RTP Payload MIME Registration ......................25
      9.2. Mapping MIME Parameters into SDP ..........................27
      9.3. Offer-Answer Model Considerations .........................28
   10. IANA Considerations ...........................................29
   11. Acknowledgements ..............................................29
   12. References ....................................................30
      12.1. Normative References .....................................30
      12.2. Informative References ...................................30

Ahmadi                      Standards Track                     [Page 2]
RFC 4348               VMR-WB RTP Payload Format            January 2006

1.  Introduction

   This document specifies the payload format for packetization of VMR-
   WB-encoded speech signals into the Real-time Transport Protocol (RTP)
   [3].  The VMR-WB payload formats support transmission of single and
   multiple channels, frame interleaving, multiple frames per payload,
   header-free payload, the use of mode switching, and interoperation
   with existing VMR-WB transport formats on non-IP networks, as
   described in Section 3.

   The payload format is described in Section 6.  The VMR-WB file format
   (i.e., for transport of VMR-WB speech data in storage mode
   applications such as email) is specified in [7].  In Section 9, a
   media type registration for VMR-WB RTP payload format is provided.

   Since VMR-WB is interoperable with AMR-WB at certain rates, an
   attempt has been made throughout this document to maximize the
   similarities with RFC 3267 while optimizing the payload format for
   the non-interoperable modes of the VMR-WB codec.

2.  Conventions and Acronyms

   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 RFC2119 [2].

   The following acronyms are used in this document:

    3GPP   - The Third Generation Partnership Project
    3GPP2  - The Third Generation Partnership Project 2
    CDMA   - Code Division Multiple Access
    WCDMA  - Wideband Code Division Multiple Access
    GSM    - Global System for Mobile Communications
    AMR-WB - Adaptive Multi-Rate Wideband Codec
    VMR-WB - Variable-Rate Multimode Wideband Codec
    CMR    - Codec Mode Request
    GW     - Gateway
    DTX    - Discontinuous Transmission
    FEC    - Forward Error Correction
    SID    - Silence Descriptor
    TrFO   - Transcoder-Free Operation
    UDP    - User Datagram Protocol
    RTP    - Real-Time Transport Protocol
    RTCP   - RTP Control Protocol
    MIME   - Multipurpose Internet Mail Extension
    SDP    - Session Description Protocol
    VoIP   - Voice-over-IP

Ahmadi                      Standards Track                     [Page 3]
RFC 4348               VMR-WB RTP Payload Format            January 2006

   The term "interoperable mode" in this document refers to VMR-WB mode
   3, which is interoperable with AMR-WB codec modes 0, 1, and 2.

   The term "non-interoperable modes" in this document refers to VMR-WB
   modes 0, 1, and 2.

   The term "frame-block" is used in this document to describe the
   time-synchronized set of speech frames in a multi-channel VMR-WB
   session.  In particular, in an N-channel session, a frame-block will
   contain N speech frames, one from each of the channels, and all N
   speech frames represent exactly the same time period.

3.  The Variable-Rate Multimode Wideband (VMR-WB) Speech Codec

   VMR-WB is the wideband speech-coding standard developed by Third
   Generation Partnership Project 2 (3GPP2) for encoding/decoding
   wideband/narrowband speech content in multimedia services in 3G CDMA
   cellular systems [1].  VMR-WB is a source-controlled variable-rate
   multimode wideband speech codec.  It has a number of operating modes,
   where each mode is a tradeoff between voice quality and average data
   rate.  The operating mode in VMR-WB (as shown in Table 2) is chosen
   based on the traffic condition of the network and the desired quality
   of service.  The desired average data rate (ADR) in each mode is
   obtained by encoding speech frames at permissible rates (as shown in
   Tables 1 and 3) compliant with CDMA2000 system, depending on the
   instantaneous characteristics of input speech and the maximum and
   minimum rate constraints imposed by the network operator.

   While VMR-WB is a native CDMA codec complying with all CDMA system
   requirements, it is further interoperable with AMR-WB [4,12] at
   12.65, 8.85, and 6.60 kbps.  This is due to the fact that VMR-WB and
   AMR-WB share the same core technology.  This feature enables
   Transcoder-Free (TrFO) interconnections between VMR-WB and AMR-WB
   across different wireless/wireline systems (e.g., GSM/WCDMA and
   CDMA2000) without use of unnecessary complex media format conversion.

   Note that the concept of mode in VMR-WB is different from that of
   AMR-WB where each fixed-rate AMR-WB codec mode is adapted to
   prevailing channel conditions by a tradeoff between the total number
   of source-coding and channel-coding bits.

   VMR-WB is able to transition between various modes with no
   degradation in voice quality that is attributable to the mode
   switching itself.  The operating mode of the VMR-WB encoder may be
   switched seamlessly without prior knowledge of the decoder.  Any
   non-interoperable mode (i.e., VMR-WB modes 0, 1, or 2) can be chosen
   depending on the traffic conditions (e.g., network congestion) and
   the desired quality of service.

Ahmadi                      Standards Track                     [Page 4]
RFC 4848                   URI-Enabled NAPTR                  April 2007

4.7.  Valid Databases

   At present, only one DDDS Database is specified for this Application.
   [4] specifies a DDDS Database that uses the NAPTR DNS resource record
   to contain the rewrite rules.  The Keys for this database are encoded
   as domain names.

   The First Well Known Rule produces a domain name, and this is the Key
   that is used for the first lookup -- the NAPTR records for that
   domain are requested.

   DNS servers MAY interpret Flag values and use that information to
   include appropriate NAPTR, SRV, or A records in the Additional
   Information portion of the DNS packet.  Clients are encouraged to
   check for additional information but are not required to do so.  See
   the Additional Information Processing section of [4] for more
   information on NAPTR records and the Additional Information section
   of a DNS response packet.

5.  IANA Considerations

   This document does not itself place any requirements on IANA, but
   provides the basis upon which U-NAPTR-using services can make use of
   the existing IANA registries for application service tags and
   application protocol tags (defined in RFC 3958 [2]).

   As is the case for S-NAPTR, all application service and protocol tags
   that start with "x-" are considered experimental, and no provision is
   made to prevent duplicate use of the same string.  Use them at your
   own risk.

   All other application service and protocol tags are registered based
   on the "specification required" option defined in [6], with the
   further stipulation that the "specification" is an RFC (of any
   category).

   There are no further restrictions placed on the tags other than that
   they must conform with the syntax defined above (Section 4.5).

   The defining RFC must clearly identify and describe, for each tag
   being registered:

   o  Application protocol or service tag

   o  Intended usage

   o  Interoperability considerations

Daigle                      Standards Track                     [Page 7]
RFC 4848                   URI-Enabled NAPTR                  April 2007

   o  Security considerations (see Section 6 of this document for
      further discussion of the types of considerations that are
      applicable)

   o  Any relevant related publications

   The defining RFC may also include further application-specific
   restrictions, such as limitations on the types of URIs that may be
   returned for the application service.

6.  Security Considerations

   U-NAPTR has the same considerations for security as S-NAPTR; see
   Section 8 of [2].  U-NAPTR has the additional consideration that
   resolving URIs (from the result of the DDDS resolution) has its own
   set of security implications, covered in the URI specification (in
   particular, Section 7 of [8]).  In essence, using DNSSEC, client
   software can be confident that the URI obtained using U-NAPTR is
   indeed the one specified by the administrator of the domain from
   which it was retrieved; but the validity of the service reached by
   resolving that URI is a matter of URI resolution security practices.

7.  Acknowledgements

   Thanks to Martin Thomson, John Klensin, Bernard Aboba, Alfred Hoenes,
   Dan Romascanu, Suresh Krishnan, and Lars Eggert for reviewing earlier
   versions and catching errors!

8.  References

8.1.  Normative References

   [1]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
        Specifications: ABNF", RFC 4234, October 2005.

   [2]  Daigle, L. and A. Newton, "Domain-Based Application Service
        Location Using SRV RRs and the Dynamic Delegation Discovery
        Service (DDDS)", RFC 3958, January 2005.

   [3]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
        specifying the location of services (DNS SRV)", RFC 2782,
        February 2000.

   [4]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
        Three: The Domain Name System (DNS) Database", RFC 3403,
        October 2002.

Daigle                      Standards Track                     [Page 8]
RFC 4848                   URI-Enabled NAPTR                  April 2007

   [5]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
        Four: The Uniform Resource Identifiers (URI)", RFC 3404,
        October 2002.

   [6]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

8.2.  Informative References

   [7]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
        One: The Comprehensive DDDS", RFC 3401, October 2002.

   [8]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
        Resource Identifier (URI): Generic Syntax", RFC 3986, STD 66,
        January 2005.

   [9]  Malamud, C., "Attaching Meaning to Solicitation Class Keywords",
        RFC 4095, May 2005.

Author's Address

   Leslie L. Daigle
   Cisco Systems
   13615 Dulles Technology Drive
   Herndon, VA  20171
   US

   EMail: ledaigle@cisco.com; leslie@thinkingcat.com

Daigle                      Standards Track                     [Page 9]
RFC 4848                   URI-Enabled NAPTR                  April 2007

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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.

   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, THE IETF TRUST 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.

Intellectual Property

   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
   ietf-ipr@ietf.org.

Acknowledgement

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

Daigle                      Standards Track                    [Page 10]
RFC 4348               VMR-WB RTP Payload Format            January 2006