The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework
RFC 4091

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 02

Network Working Group                                       G. Camarillo
Request for Comments: 4091                                      Ericsson
Category: Standards Track                                   J. Rosenberg
                                                           Cisco Systems
                                                               June 2005

         The Alternative Network Address Types (ANAT) Semantics
     for the Session Description Protocol (SDP) Grouping Framework

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 (2005).

Abstract

   This document defines the Alternative Network Address Types (ANAT)
   semantics for the Session Description Protocol (SDP) grouping
   framework.  The ANAT semantics allow alternative types of network
   addresses to establish a particular media stream.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
       1.1.  Scope and Relation with Interactive Connectivity
             Establishment. . . . . . . . . . . . . . . . . . . . . .  2
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  ANAT Semantics . . . . . . . . . . . . . . . . . . . . . . . .  3
   4.  Preference . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   5.  Offer/Answer and ANAT  . . . . . . . . . . . . . . . . . . . .  3
   6.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  4
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  5
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  5
       9.1.  Normative References . . . . . . . . . . . . . . . . . .  5
       9.2.  Informational References . . . . . . . . . . . . . . . .  5

Camarillo & Rosenberg       Standards Track                     [Page 1]
RFC 4091                     ANAT Semantics                    June 2005

1.  Introduction

   A Session Description Protocol (SDP) [2] session description contains
   the media parameters to be used in establishing a number of media
   streams.  For a particular media stream, an SDP session description
   contains, among other parameters, the network addresses and the codec
   to be used in transferring media.  SDP allows for a set of codecs per
   media stream, but only one network address.

   The ability to offer a set of network addresses to establish a media
   stream is useful in environments with both IPv4-only hosts and
   IPv6-only hosts, for instance.

   This document defines the Alternative Network Address Types (ANAT)
   semantics for the SDP grouping framework [4].  The ANAT semantics
   allow for the expression of alternative network addresses (e.g.,
   different IP versions) for a particular media stream.

1.1.  Scope and Relation with Interactive Connectivity Establishment

   The ANAT semantics are intended to address scenarios that involve
   different network address types (e.g., different IP versions).  They
   are not intended to provide alternative transport addresses with the
   same network type.  Systems that need to provide different transport
   addresses with the same network type should use the SDP format
   defined in ICE (Interactive Connectivity Establishment) [6] instead.

   ICE is used by systems that cannot determine their own transport
   address as seen from the remote end, but that can provide several
   possible alternatives.  ICE encodes the address that is most likely
   to be valid in an 'm' line, and the rest of addresses as a= lines
   after that 'm' line.  This way, systems that do not support ICE
   simply ignore the a= lines and only use the address in the 'm' line.
   This achieves good backward compatibility.

   We have chosen to group 'm' lines with different IP versions at the
   'm' level (ANAT semantics) rather than at the a= level (ICE format)
   in order to keep the IPv6 syntax free from ICE parameters used for
   legacy (IPv4) NATs (Network Address Translators).  This yields a
   syntax much closer to vanilla SDP, where IPv6 addresses are defined
   in their own 'm' line, rather than in parameters belonging to a
   different 'm' line.

   Additionally, ICE only allows us to provide a single primary address
   when the peer does not support ICE.  The ANAT semantics avoid
   relegating certain types of addresses (e.g., IPv6 addresses) to only
   be a secondary alternate to another address type (e.g., IPv4
   addresses).

Camarillo & Rosenberg       Standards Track                     [Page 2]
RFC 4091                     ANAT Semantics                    June 2005