Usage of the Session Description Protocol (SDP) Alternative Network Address Types (ANAT) Semantics in the Session Initiation Protocol (SIP)
RFC 4092
Document | Type |
RFC - Proposed Standard
(June 2005; No errata)
Obsoleted by RFC 5245
|
|
---|---|---|---|
Authors | Gonzalo Camarillo , Jonathan Rosenberg | ||
Last updated | 2015-10-14 | ||
Stream | Internent Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Stream | WG state | WG Document | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4092 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Allison Mankin | ||
Send notices to | rohan@ekabal.com |
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 sameShow full document text