The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework
RFC 4091
Document | Type |
RFC - Proposed Standard
(June 2005; No errata)
Obsoleted by RFC 5245
|
|
---|---|---|---|
Authors | Gonzalo Camarillo , Jonathan Rosenberg | ||
Last updated | 2015-10-14 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | WG Document | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4091 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Jon Peterson | ||
Send notices to | mankin@psg.com, csp@csperkins.org |
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 2005Show full document text