Usage of the Session Description Protocol (SDP) Alternative Network Address Types (ANAT) Semantics in the Session Initiation Protocol (SIP)
RFC 4092

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

• Versions
• 00

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

            Usage of the Session Description Protocol (SDP)
          Alternative Network Address Types (ANAT) Semantics
                in the Session Initiation Protocol (SIP)

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 describes how to use the Alternative Network Address
   Types (ANAT) semantics of the Session Description Protocol (SDP)
   grouping framework in SIP.  In particular, we define the sdp-anat SIP
   option-tag.  This SIP option-tag ensures that SDP session
   descriptions that use ANAT are only handled by SIP entities with ANAT
   support.  To justify the need for such a SIP option-tag, we describe
   what could possibly happen if an ANAT-unaware SIP entity tried to
   handle media lines grouped with ANAT.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  2
   3.  The sdp-anat Option-Tag . . . . . . . . . . . . . . . . . . . . 2
   4.  Backward Compatibility . . . . . . . . . . . . . . . . . . . .  3
       4.1.  Answerer Supports All the Network Types Offered  . . . .  3
       4.2.  Answerer Does Not Support All the Network Types Offered.  3
       4.3.  OPTIONS Requests . . . . . . . . . . . . . . . . . . . .  4
   5.  Option-Tag Usage . . . . . . . . . . . . . . . . . . . . . . .  4
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  4
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  4
   8.  Normative References . . . . . . . . . . . . . . . . . . . . .  5

Camarillo & Rosenberg       Standards Track                     [Page 1]
RFC 4092                   ANAT Usage in SDP                   June 2005

1.  Introduction

   SIP [3] UAs (User Agents) often support different network address
   types.  For example, a UA may have an IPv6 address and an IPv4
   address.  Such a UA will typically be willing to use any of its
   addresses to establish a media session with a remote UA.  If the
   remote UA only supports IPv6, for instance, both UAs will use IPv6 to
   send and receive media.

   The Alternative Network Address Types (ANAT) semantics [7] of the SDP
   [2] grouping framework [5] allow UAs to offer [4] alternative
   addresses of different types in an SDP session description.  The
   IPv4/IPv6 dual-stack SIP UA of our previous example would generate an
   offer grouping an IPv6 media line and an IPv4 media line using ANAT.
   Upon receipt of this offer, the answerer [4] would accept one media
   line and reject the other.

   If the recipient of an offer that uses ANAT supports the ANAT
   semantics, everything works as described in the ANAT specification
   [7].  Nevertheless, the recipient of such an offer (i.e., the
   answerer) may not support ANAT.  In this case, different
   implementations of the answerer would react in different ways.  This
   document discusses the answerer's behaviors that are most likely to
   be found and describes their consequences.  To avoid these
   consequences, we define the sdp-anat SIP option-tag.

   The sdp-anat option-tag can be used to ensure that an offer using
   ANAT is not processed by answerers without support for ANAT.  This
   option-tag can also be used to explicitly discover the capabilities
   of a UA (i.e., whether it supports ANAT).

2.  Terminology

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
   RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
   described in BCP 14, RFC 2119 [1] and indicate requirement levels for
   compliant implementations.

3.  The sdp-anat Option-Tag

   We define the option-tag sdp-anat for use in the Require and
   Supported SIP [3] header fields.  SIP user agents that place this
   option-tag in a Supported header field understand the ANAT semantics
   as defined in [7].

Camarillo & Rosenberg       Standards Track                     [Page 2]
RFC 4092                   ANAT Usage in SDP                   June 2005

4.  Backward Compatibility

   Answerers without support for ANAT will react in different ways upon
   receipt of an offer using ANAT.  We expect that, even under the same