RFC 6947
The Session Description Protocol (SDP) Alternate Connectivity (ALTC) Attribute
The Session Description Protocol (SDP) Alternate Connectivity (ALTC) Attribute 🎀
okay bestie, here's the tea on RFC 6947 ✨
Category: Informational (an Independent Submission) 📚 ISSN: 2070-1721 Date: May 2013 📅 Authors: M. Boucadair (France Telecom), H. Kaplan (Acme Packet), R. Gilman (Independent), and S. Veikkolainen (Nokia) 💜 Obsoletes / Updates: the title block doesn't list anything this document obsoletes or updates 🫶
Abstract
okay so the big idea 🦋 this doc proposes a way for one SDP offer to carry multiple IP addresses from different address families (like IPv4 and IPv6) all at once. The new "altc" attribute is the fix for the backward-compatibility drama that Alternative Network Address Types (ANAT) ran into because of its syntax 😭
the proposed solution is for situations where connectivity checks aren't required. If connectivity checks are required, Interactive Connectivity Establishment (ICE), as specified in RFC 5245, already handles that 🌸
Status of This Memo
this document is not an Internet Standards Track specification. It's published for informational purposes 📖
it's a contribution to the RFC Series, independent of any other RFC stream. The RFC Editor chose to publish it at their discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor aren't candidates for any level of Internet Standard, see Section 2 of RFC 5741 🎀
info about the current status of this document, any errata, and how to give feedback on it can be found at http://www.rfc-editor.org/info/rfc6947 ✨
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved 💅
this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication. Please review those documents carefully, because they describe your rights and restrictions with respect to this document 🫶
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Overall Context . . . . . . . . . . . . . . . . . . . . . 3
1.2. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview of the ALTC Mechanism . . . . . . . . . . . . . . . 6
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Rationale for the Chosen Syntax . . . . . . . . . . . . . 7
4. Alternate Connectivity Attribute . . . . . . . . . . . . . . 8
4.1. ALTC Syntax . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Usage and Interaction . . . . . . . . . . . . . . . . . . 9
4.2.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2.2. Usage of ALTC in an SDP Answer . . . . . . . . . . . 11
4.2.3. Interaction with ICE . . . . . . . . . . . . . . . . 11
4.2.4. Interaction with SDP-Cap-Neg . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. ALTC Use Cases . . . . . . . . . . . . . . . . . . . 15
A.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 15
A.2. Multicast Use Case . . . . . . . . . . . . . . . . . . . 16
A.3. Introducing IPv6 into SIP-Based Architectures . . . . . . 17
A.3.1. Avoiding Crossing CGN Devices . . . . . . . . . . . . 17
A.3.2. Basic Scenario for IPv6 SIP Service Delivery . . . . 17
A.3.3. Avoiding IPv4/IPv6 Interworking . . . . . . . . . . . 18
A.3.4. DBE Bypass Procedure . . . . . . . . . . . . . . . . 20
A.3.5. Direct Communications between IPv6-Enabled User
Agents . . . . . . . . . . . . . . . . . . . . . . . 221. Introduction ✨
1.1. Overall Context
because of IPv4 address exhaustion, IPv6 deployment is becoming urgent 🚀 and so is handling IPv4 and IPv6 coexisting nicely. That coexistence gives us messy mixed scenarios: some nodes are dual-stack (DS), some can only do IPv4, and some can only do IPv6. In this world, Session Initiation Protocol (SIP) [RFC3261] User Agents (UAs) need a way to say what IP capabilities they have. That helps them set up sessions successfully, avoid adaptation functions like Application Layer Gateways (ALGs) and IPv4-IPv6 interconnection functions (for example NAT64 [RFC6146]), and avoid using private IPv4 addresses behind consumer NATs or Carrier-Grade NATs (CGNs) [RFC6888] 🙈
meanwhile, service providers are looking at upgrading their offerings to be IPv6 capable 💖 Current strategies are either IPv6 only (for example for mobile devices), or both IPv4 and IPv6 with private IPv4 addresses that get NATed by CGNs. In the second case, the end device might be using "normal" IPv4 and IPv6 stacks and interfaces, or it might tunnel IPv4 packets through a Dual-Stack Lite (DS-Lite) stack that's integrated into the host [RFC6333]. Either way, the device has both address families available from a SIP and media perspective 🌈
no matter which IPv6 transition strategy is used, it's obvious that dual-stack SIP devices will need to talk to IPv4-only legacy UAs, IPv6-only UAs, and other dual-stack UAs 👑 A dual-stack UA may not be able to reach an IPv6-only UA unless it has a way to give that UA an IPv6 address, and it obviously needs to give a legacy IPv4-only device an IPv4 address. The communication has to work in a backward-compatible way, so IPv4-only SIP devices don't need to support the new mechanism in order to talk to dual-stack UAs 🫶
the current ways to communicate multiple address families are ANAT [RFC4091] or ICE [RFC5245] 🧚 ANAT has serious backward-compatibility problems, as described in [RFC4092], which effectively make it unusable, and it has been deprecated by the IETF [RFC5245]. ICE at least allows interoperability with legacy devices, but it's complicated and processing-intensive, and it has seen limited deployment and implementation in SIP applications 😭
ALTC has been implemented as reported in [NAT64-EXP], and no issues have been reported in that document ✨
1.2. Purpose
this document proposes a new alternative: a backward-compatible syntax for indicating multiple media connection addresses and ports in an SDP offer, which can be selected from right away and used in an SDP answer 🦋
the proposed mechanism is independent of the model described in [RFC5939], and it doesn't require implementing SDP Capability Negotiations (a.k.a., SDPCapNeg) to work 💅
"backward-compatible" here generally means working with legacy IPv4-only devices 🎀 The choice has to be made one way or the other, because talking to legacy devices means building SDP bodies they understand and support, so they detect their local address family in the SDP connection line. It isn't possible to support interworking with both legacy IPv4-only and legacy IPv6-only devices using the same SDP offer. Since there are far more legacy IPv4-only devices out there, those are the ones this document assumes. That said, the syntax lets a UA choose which address family to be backward-compatible with, in case it has some way of figuring that out 🌸
even when both sides support the same address family, there should be a means of using the "best" address family transport, based on what the UAs decide 💜 The "best" address family for a particular session can't always be known in advance. For example, the IPv4 transport might be better even if both UAs support IPv6 🙈
the proposed solution provides the following benefits:
- Allows a UA to signal more than one IP address (type) in the same SDP offer. 🌈
- Is backward compatible. No parsing or semantic errors will be experienced by a legacy UA or by intermediary SIP nodes that don't understand this new mechanism. 🫶
- Is as lightweight as possible to achieve the goal, while still allowing and interoperating with nodes that support other similar or related mechanisms. ✨
- Is easily deployable in managed networks. 🚀
- Requires minimal increase of the length of the SDP offer (i.e., minimizes fragmentation risks). 💅
ALTC may also be useful for the multicast context (e.g., Section 3.4 of [MULTRANS-FW] or Section 3.3 of [ADDR-ACQ]) 🧚
more detailed information about ALTC use cases is provided in Appendix A 🎀
1.3. Scope
this document proposes an alternative scheme, as a replacement for the ANAT procedure [RFC4091], to carry several IP address types in the same SDP offer while keeping backward compatibility 🔥
two UAs talking directly at the SIP layer obviously need to support the same address family for SIP itself. But current SIP deployments almost always have proxy servers or back-to-back user agents (B2BUAs) in the SIP signaling path, and those can provide the interworking of IP address families at the SIP layer (e.g., [RFC6157]) 💖 SIP-layer address family interworking is out of scope for this document. Instead, this document focuses on communicating media address family capabilities in a backward-compatible way. Because media can go directly between two UAs, without the User Agent Client (UAC) knowing a priori which address family the far-end User Agent Server (UAS) supports, the offer has to include both, in a backward-compatible fashion 🦋
1.4. Requirements Language
these are the BCP 14 key words you'll see, and they're the ones with real force 💅 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 RFC 2119 [RFC2119] 🫶
2. Use Cases ✨
Okay bestie, let's talk about where ALTC actually shines 💖 It's mainly built for managed networks 🧚 (networks someone is actually looking after), and the authors explicitly thought about these use cases:
- A dual-stack UAC (the one starting the call) that kicks off a SIP session without knowing whether the final UAS is IPv4 or IPv6 🌸
- A UA that gets a SIP session request with an SDP offer and wants to avoid using IPv4 or IPv6 🙈
- An IPv6-only UA that wants to avoid using a NAT64 [RFC6146] 🦋
- A SIP UA behind a DS-Lite CGN [RFC6333] 🌈
- A SIP service provider or enterprise domain of an IPv4-only and/or IPv6-only UA that provides interworking by invoking IPv4-IPv6 media relays, and that wants to avoid invoking those functions and to let media go end to end as much as possible 💅
- A SIP service provider or enterprise domain of a UA that talks with other domains, and that wants either to avoid invoking IPv4-IPv6 interworking or to let media go end to end as much as possible ✨
- A SIP service provider that offers transit peering for SIP sessions which might need to modify SDP to provide IPv4-IPv6 interworking, but would rather avoid that interworking, or avoid relaying media in general, as much as possible 🍓
- SIP sessions that use the new mechanism when crossing legacy SDP-aware middleboxes, but that might not understand this new mechanism 😭
3. Overview of the ALTC Mechanism
3.1. Overview
Okay so the ALTC mechanism relies solely on the SDP offer/answer mechanism, with special syntax to show alternative connection addresses 🎀 The big idea is a brand new SDP attribute called altc, which lists the IP addresses that could be used as alternative connection addresses. The address most likely to get picked for the session lives in the normal c= line. In today's real-world networks, that's usually going to be an IPv4 address 👑 The a=altc lines hold the alternative addresses offered for the session.
So a dual-stack UA might put its IPv4 address in the c= line, but still prefer IPv6, and it can say so by spelling out the preference order in its a=altc lines 💜 One of the a=altc lines repeats the address from the c= line, and there's a reason for that, which Section 3.2 explains 🔥 When the SDP answerer picks an address, it just uses that address family in the c= line of its response. Iconic, right?
Here's an example SDP offer for when IPv4 is the most likely choice but IPv6 is preferred:
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
m=audio 12340 RTP/AVP 0 8
a=altc:1 IP6 2001:db8::1 45678
a=altc:2 IP4 192.0.2.1 12340And if IPv6 were the more likely choice for the session, the SDP offer would look like this:
v=0
o=- 25678 753849 IN IP6 2001:db8::1
s=
c=IN IP6 2001:db8::1
t=0 0
m=audio 45678 RTP/AVP 0 8
a=altc:1 IP6 2001:db8::1 45678
a=altc:2 IP4 192.0.2.1 12340Since an alternative address will probably need its own TCP/UDP port number too 🦋, the new altc attribute carries both an IP address and a transport port number (or several port numbers). The ALTC mechanism does not support offering a different transport type (UDP vs. TCP), codec, or any other attribute. It's only for offering an alternative IP address and port number, nothing more 🧚
3.2. Rationale for the Chosen Syntax
According to [RFC4566], an a= attribute line is the main way to extend SDP and tailor it to particular applications or media 🌸 A compliant SDP parser will just ignore attribute lines it doesn't support, which is the friendly part 🫶
Now the reason we repeat the same address and port in the a=altc line as in the m= and c= lines: it lets everyone detect legacy SDP-changing middleboxes 🙈 These boxes might change the connection address and media transport port numbers without supporting this mechanism, and then two UAs that do support it would try to connect to the wrong addresses 💀 That's the drama we're avoiding! So this document requires the SDP processor to go ahead with the matching rules defined in Section 4.2.1 ✨
4. Alternate Connectivity Attribute
4.1. ALTC Syntax
The altc attribute follows the [RFC4566] "attribute" production 💖 Here's the ABNF syntax [RFC5234] for altc:
altc-attr = "altc" ":" att-value
att-value = altc-num SP addrtype SP connection-address SP port
["/" rtcp-port]
altc-num = 1*DIGIT
rtcp-port = port
Figure 1: Connectivity Capability Attribute ABNFHere's what each field means:
- altc-num: a digit that uniquely refers to an address alternative 🔢 It sets the preference order, with "1" being the most preferred address 👑
- addrtype: the addrtype field as defined in [RFC4566] for connection data 🌈
- connection-address: a network address as defined in [RFC4566], matching the address type given by addrtype 🦋
- port: the port number to use, as defined in [RFC4566] 🎀 Different address types can use different port numbers. If the address type doesn't need a port number, a value defined for that address type SHOULD be used.
- rtcp-port: adding an RTP Control Protocol (RTCP) port is optional 🧚 You can put an RTCP port in the alternative
c=line when the RTCP port can't be worked out from the RTP port.
The altc attribute only shows up in an SDP offer 💅 It's a media-level-only attribute, so it MUST NOT appear at the SDP session level. (Since it defines a port number, it's inherently tied to the media level, so that makes total sense 🙈) There MUST NOT be more than one altc attribute per addrtype within each media description. This limit exists so the addrtype of the reply can tell the offerer which alternative got accepted 🔥
The addrtypes of the altc attributes MUST correspond to the nettype of the current connection (c=) line 💖
A media description MUST contain two altc attributes: one for the alternative address and one for an alternative port. It also MUST contain an address and a port that "duplicate" the address and port information from the current c= and m= lines 🫶 Every media level MUST contain at least one such duplicate altc attribute, with the same IP address family, address, and transport port number as the SDP connection and media lines at that level. Specifically, if a c= line shows up within a media description, the addrtype and connection-address from that c= line MUST be used in the duplicate altc attribute for that media description. If a c= line only appears at the session level and a given media description doesn't have its own connection line, then the duplicate altc attribute for that media description MUST be the same as the session-level address information 🌸
The altc attributes inside a media description MUST be prioritised 👑 The explicit preference order is in each line, where "1" means the highest priority. Because of this rule, plus the requirement that the address info in the m= and o= lines must also appear in an altc attribute, it's possible that the addresses in the m= and o= lines are not the preferred choice 🌈
If the addrtype of an altc attribute doesn't work with the transport protocol or media format in the media description, that altc attribute MUST be ignored 🙈
Heads up, though! a=altc lines describe alternative connection addresses, NOT addresses for parallel connections 💀 When several altc lines are present, establishing multiple sessions MUST be avoided. Only one session should be maintained with the remote party for the associated media description 💜
4.2. Usage and Interaction
4.2.1. Usage
In the SDP offer/answer model, the SDP offer includes altc attributes to show alternative connection information (address type, address, and port numbers), including the "duplicate" connection information already in the c= and m= lines ✨
Additional, subsequent offers MAY include altc attributes again, and they can change the IP address, port numbers, and order of preference 🦋 But they MUST include a duplicate altc attribute for the connection and media lines in that specific subsequent offer. So basically, every offered SDP media description with an alternative address in an altc attribute has two altc attributes:
- one that duplicates the
c=andm=line information for that media description - one for the alternative
These don't need to match the original SDP offer 🌈
The whole point of the duplicate altc attribute is to let receivers of the SDP offer detect whether a legacy SDP-changing middlebox has messed with the c= and/or m= line address/port info 🔥 If the SDP answerer can't find a duplicate altc attribute whose address and port exactly match those in the c= and m= lines, the SDP answerer MUST ignore the altc attributes and use the offered c= and m= addresses/ports for the entire SDP instead, as if no altc attributes were there at all 😭 The reason? Lots of SDP-changing middleboxes end media sessions if they don't see media flowing through them. And if a middlebox did modify the SDP addresses, media MUST be sent using the modified information 💖
Quick RTCP note: if RTCP applies to the given media types, each side acts as if the chosen altc attribute's port number were in the m= media line 🧚 Usually that means RTCP goes to the port number equal to RTP port + 1, unless some other attribute says otherwise. For example, the RTP/RTCP multiplexing mechanism in [RFC5761] can still be used with ALTC. If both sides support multiplexing, they signal it with the a=rtcp-mux attribute, as defined in [RFC5761], and the IP connection address and port they use can still be picked using the ALTC mechanism 🌸
If the SDP offerer wants to use the RTCP attribute defined in [RFC3605], things can get a bit messy, because it might not be clear which address choice the a=rtcp attribute applies to, compared with the choices ALTC offers 😭
Technically, RFC 3605 lets the RTCP address be spelled out right in the a=rtcp attribute itself, but that's optional and rarely used. So this document recommends using the a=rtcp attribute for the address choice in the m= line, and including an alternate RTCP port in the a=altc attribute for the alternative address 💅 In other words, if the a=rtcp attribute explicitly encodes an address, that address applies for ALTC, as per [RFC3605]. If it doesn't, then ALTC assumes the a=rtcp attribute is for the address in the m= line, and the alternative altc attribute includes an RTCP alternate port number 🎀
4.2.2. Usage of ALTC in an SDP Answer ✨
The SDP answer SHOULD NOT contain altc attributes, bestie 🙅♀️. The answer's c= line already locks in the address family from the offer and puts it in the c= and m= lines of the answer, so there's zero drama there. It also means you don't end up with several sessions running between the two peers at once, which is so much cleaner 🧹💅
Any solution that needs ALTC in the SDP answer SHOULD document its usage, especially how the sessions get set up between the participating peers 📝🎀
4.2.3. Interaction with ICE 🧚
Okay so ICE [RFC5245] also stuffs address and port info into its candidate attributes, which means there's a possible showdown: which one wins? 👀 Lowkey the drama gets avoided because ICE also adds its own ICE attributes to the SDP answer. If the SDP offerer supports both ALTC and ICE, it may put both sets of attributes in the same SDP offer 💜
Then it's a vibe check. A legacy ICE-only answerer just ignores the altc attributes and goes with ICE 🙃. An ALTC-only answerer ignores the ICE attributes and replies without them 🌸. An answerer that supports both MUST choose one and only one of the mechanisms to use, either ICE or ALTC. No picking both, no double dipping 💅✨
Heads up: if a middlebox changed them=orc=line, then the rules for both ALTC and ICE make the answerer fall back to basic SDP semantics. Not the vibe, but that's how it goes 😭
4.2.4. Interaction with SDP-Cap-Neg 🦋
ALTC is totally orthogonal to SDPCapNeg [RFC5939], which is a fancy way of saying they don't mess with each other 🫶. If the offerer supports both ALTC and SDPCapNeg, it may offer both 🌈
5. IANA Considerations 📋
Per this document, a brand-new SDP attribute has been assigned 🎉
SDP Attribute ("att-field"):
Attribute name altc
Long form Alternate Connectivity
Type of name att-field
Type of attribute Media level only
Subject to charset No
Purpose See Sections 1.2 and 3
Specification Section 4The contact person for this registration is Mohamed Boucadair (email: mohamed.boucadair@orange.com; phone: +33 2 99 12 43 71) 📞💖
6. Security Considerations 🔐
Okay, security in one line, no cap: the security implications for ALTC are effectively the same as they are for SDP in general [RFC4566]. So if you already have SDP security sorted, you're basically set 💅🛡️
7. Acknowledgements 🫶
Huge thanks to T. Taylor, F. Andreasen, and G. Camarillo for reviewing and commenting. Main character supporting cast energy 👑✨
8. References 📚
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute
in Session Description Protocol (SDP)", RFC 3605, October
2003.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761, April 2010.8.2. Informative References
[ADDR-ACQ]
Tsou, T., Clauberg, A., Boucadair, M., Venaas, S., and Q.
Sun, "Address Acquisition For Multicast Content When
Source and Receiver Support Differing IP Versions", Work
in Progress, January 2013.
[ADDR-FORMAT]
Boucadair, M., Ed., Qin, J., Lee, Y., Venaas, S., Li, X.,
and M. Xu, "IPv6 Multicast Address With Embedded IPv4
Multicast Address", Work in Progress, April 2013.
[MULTRANS-FW]
Venaas, S., Li, X., and C. Bao, "Framework for IPv4/IPv6
Multicast Translation", Work in Progress, June 2011.
[MULTRANS-PS]
Jacquenet, C., Boucadair, M., Lee, Y., Qin, J., Tsou, T.,
and Q. Sun, "IPv4-IPv6 Multicast: Problem Statement and
Use Cases", Work in Progress, March 2013.
[NAT64-EXP]
Abdesselam, M., Boucadair, M., Hasnaoui, A., and J.
Queiroz, "PCP NAT64 Experiments", Work in Progress,
September 2012.
[RFC2871] Rosenberg, J. and H. Schulzrinne, "A Framework for
Telephony Routing over IP", RFC 2871, June 2000.
[RFC4091] Camarillo, G. and J. Rosenberg, "The Alternative Network
Address Types (ANAT) Semantics for the Session Description
Protocol (SDP) Grouping Framework", RFC 4091, June 2005.
[RFC4092] Camarillo, G. and J. Rosenberg, "Usage of the Session
Description Protocol (SDP) Alternative Network Address
Types (ANAT) Semantics in the Session Initiation Protocol
(SIP)", RFC 4092, June 2005.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, April
2010.
[RFC5853] Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen,
A., and M. Bhatia, "Requirements from Session Initiation
Protocol (SIP) Session Border Control (SBC) Deployments",
RFC 5853, April 2010.
[RFC5939] Andreasen, F., "Session Description Protocol (SDP)
Capability Negotiation", RFC 5939, September 2010.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, April 2011.
[RFC6157] Camarillo, G., El Malki, K., and V. Gurbani, "IPv6
Transition in the Session Initiation Protocol (SIP)", RFC
6157, April 2011.
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4
Exhaustion", RFC 6333, August 2011.
[RFC6406] Malas, D. and J. Livingood, "Session PEERing for
Multimedia INTerconnect (SPEERMINT) Architecture", RFC
6406, November 2011.
[RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A.,
and H. Ashida, "Common Requirements for Carrier-Grade NATs
(CGNs)", BCP 127, RFC 6888, April 2013.Appendix A. ALTC Use Cases 🎀
A.1. Terminology 🧠
Here are the terms we'll be throwing around for the ALTC use cases:
- SBE (Signaling Path Border Element) is a functional element sitting at the edges of an ITAD (IP Telephony Administrative Domain) [RFC2871]. Its job is intercepting signaling flows from UAs and relaying them to the core service platform 📞. An SBE might live at the access segment (so it's the service contact point for UAs), or at the interconnection with adjacent domains [RFC6406]. An SBE controls one or more DBEs. The SBE and DBE can be in the same device (like the SBC [RFC5853]) or be separate 🧩
- DBE (Data Path Border Element) is a functional element at the edges of an ITAD too, and it intercepts media/data flows from UAs and relays them to another DBE (or media servers, like an announcement server or IVR) 🎶. A media gateway that intercepts RTP flows is an example of a DBE. An SBE might be at the access segment (service contact point for UAs) or at the interconnection with adjacent domains ([RFC6406]) 💅
- Core service platform ("core SPF") is a macro functional block that covers session routing, interfaces to advanced services, and access control 👑
Figure 2 gives you the overview of the whole architecture, including the SBE, DBE, and core service platform 🗺️
+----------+
| Core SIP |
+--------->| SPF |<---------+
| SIP +----------+ SIP |
v v
+-----------+ +-----------+
+-----+ SIP | SBE | | SBE | SIP
| S |<----->| | | |<----->
| I | +-----------+ +-----------+
| P | || ||
| | +-----------+ +-----------+
| U | RTP | DBE | RTP | DBE | RTP
| A |<----->| |<----------------->| | <----->
+-----+ +-----------+ +-----------+
SIP UA can be embedded in the CPE or in a host behind the CPE
Figure 2: Service Architecture OverviewA.2. Multicast Use Case 📡
Recently the IETF put a lot of effort into new mechanisms for connecting IPv6-only hosts to IPv4-only servers (e.g., [RFC6146]). That work only covered unicast transfer mode 🙄. So an ongoing initiative called "multrans" launched to tackle the multicast issues you hit during IPv6 transition 🌍. The overall problem statement lives in [MULTRANS-PS].
One particular headache with IPv4/IPv6 coexistence and IPv6 transition of multicast services is discovering the multicast group and source (refer to Section 3.4 of [MULTRANS-PS]):
- For an IPv6-only receiver asking for multicast content generated by an IPv4-only source:
- An ALG is required to help the IPv6 receiver pick the right IP address when only the IPv4 address is advertised (e.g., using SDP). Otherwise, the IPv6 receiver can't be offered access to the IPv4 multicast content 😬. The ALG may sit downstream of the receiver. So the ALG doesn't know ahead of time whether the receiver is dual-stack or IPv6-only 🤷♀️. The ALG may be tuned to insert both the original IPv4 address and the corresponding IPv6 multicast address using, for instance, the ALTC SDP attribute 💖
- To avoid involving an ALG in the path, an IPv4-only source can advertise both its IPv4 address and its IPv4-embedded IPv6 multicast address [ADDR-FORMAT] using, for instance, the ALTC SDP attribute 🧚
- For a dual-stack source sending its multicast content over IPv4 and IPv6, both IPv4 and IPv6 addresses need to be inserted in the SDP part. A means (e.g., ALTC) is needed for this purpose 🦋
A.3. Introducing IPv6 into SIP-Based Architectures 🌸
A.3.1. Avoiding Crossing CGN Devices 🚧
Some service providers are in the middle of turning on DS-Lite [RFC6333] so they can keep delivering IPv4 services to customers. Crossing four levels of NAT while setting up a media session is a lot (two NATs in the DS-Lite Address Family Transition Router (AFTR) and two NATs in the DBE) 😭. So it's recommended to enable IPv6 functions in some SBEs/DBEs. Then DS-Lite AFTRs won't be crossed for DS-Lite serviced customers whose UA is IPv6-enabled ✨
- For a SIP UA embedded in the CPE, this is easy to implement, since the SIP UA [RFC3261] can be tuned to behave as an IPv6-only UA when DS-Lite is enabled. No ALTC is required for this use case 💅
- For SIP UAs located behind the CPE, a solution to indicate both IPv4 and IPv6 (e.g., ALTC) is required in order to avoid crossing the DS-Lite CGN 🔥
A.3.2. Basic Scenario for IPv6 SIP Service Delivery ✨
okay so the basic way to deliver SIP services from an IPv4-only core service platform to an IPv6-enabled UA is to switch on the IPv4/IPv6 interworking function in the SBE/DBE 🎀. Signaling and media between two SBEs and DBEs stay on IPv4, and IPv6 is only used between the IPv6-enabled UA and the SBE/DBE 💖
Figure 3 shows what you get after session setup between UAs. The IPv4/IPv6 interworking function gets invoked even when both UAs are IPv6-enabled 🙈
+----------+
| Core SIP |
+--->|SPF (IPv4)|<---+
IPv4 SIP | +----------+ |IPv4 SIP
v v
+-----------+ +-----------+
| SBE | | SBE | SIP
+------->|IPv4/v6 IWF| | |<-------+
|IPv6 +-----------+ +-----------+ IPv4|
| SIP SIP|
+----+ | +-----------+ +-----------+ | +----+
|IPv6|-+IPv6 RTP| DBE |IPv4 RTP| DBE |IPv4 RTP+-|IPv4|
| UA |<-------->|IPv4/v6 IWF|<------>| |<-------->| UA |
+----+ +-----------+ +-----------+ +----+
+----------+
| Core SIP |
+--->|SPF (IPv4)|<---+
IPv4 SIP | +----------+ |IPv4 SIP
v v
+-----------+ +-----------+
| SBE | | SBE | SIP
+------->|IPv4/v6 IWF| |IPv4/v6 IWF|<-------+
|IPv6 +-----------+ +-----------+ IPv6|
| SIP SIP|
+----+ | +-----------+ +-----------+ | +----+
|IPv6|-+IPv6 RTP| DBE |IPv4 RTP| DBE |IPv6 RTP+-|IPv6|
| UA |<-------->|IPv4/v6 IWF|<------>|IPv4/v6 IWF|<-------->| UA |
+----+ +-----------+ +-----------+ +----+
Figure 3: Basic ScenarioIt may be valuable for service providers to consider solutions that avoid redundant IPv4/IPv6 NATs and that avoid involving several DBEs 🌸
A.3.3. Avoiding IPv4/IPv6 Interworking 🦋
A solution to indicate both IPv4 and IPv4 addresses is required for service providers that want the following:
- a way to get IPv6 transfer capabilities switched on without core service legacy nodes throwing parsing errors 😭
- to cut down the cost of IPv4-IPv6 translation licenses 💸
- to shorten the dual-stack lifetime 🧚
- to keep an IPv4-only core 🫶
- to have a crew of SBEs/DBEs that are IPv6-enabled 👑
This section gives you an overview of the procedure for avoiding IPv4/IPv6 interworking 💅
When an SBE receives an INVITE, it instantiates in its DBE an IPv6-IPv6 context and an IPv6-IPv4 context. Both an IPv6 address and an IPv4 address are returned, together with other information such as port numbers. The SBE builds an SDP offer that includes both the IPv4 and IPv6-related information using the "altc" attribute. IPv6 is indicated as the preferred connectivity type, see Figure 4 🌈
o=- 25678 753849 IN IP4 192.0.2.2
c=IN IP4 192.0.2.2
m=audio 12340 RTP/AVP 0 8
a=altc:1 IP6 2001:db8::2 6000
a=altc:2 IP4 192.0.2.2 12340
Figure 4: SDP Offer Updated by the SBEThen the request gets forwarded to the core SPF, which passes it along to the terminating SBE 🧚
- If this SBE is a legacy one, then it will ignore "altc" attributes and use the "c=" line.
- If the terminating SBE is IPv6-enabled:
- If the called UA is IPv4 only, then an IPv6-IPv4 context is created in the corresponding DBE.
- If the called UA is IPv6-enabled, then an IPv6-IPv6 context is created in the corresponding DBE.
Figure 5 shows the results when placing a session between an IPv4 UA and an IPv6 UA, and Figure 6 shows the results when a session is set up between two IPv6-enabled UAs. The result is still not optimal, since redundant NAT66 is required (Appendix A.3.4) 😬
+----------+
| Core SIP |
+--->|SPF (IPv4)|<---+
IPv4 SIP | +----------+ |IPv4 SIP
v v
+-----------+ +-----------+
| SBE | | SBE | SIP
+------->|IPv4/v6 IWF| |IPv4/v6 IWF|<-------+
|IPv6 +-----------+ +-----------+ IPv4|
| SIP SIP|
+----+ | +-----------+ +-----------+ | +----+
|IPv6|-+IPv6 RTP| DBE |IPv6 RTP| DBE |IPv4 RTP+-|IPv4|
| UA |<-------->| NAT66 |<------>|IPv4/v6 IWF|<-------->| UA |
+----+ +-----------+ +-----------+ +----+
2001:db8::2
Figure 5: Session Establishment between IPv4 and IPv6 UAs +----------+
| Core SIP |
+--->|SPF (IPv4)|<---+
IPv4 SIP | +----------+ |IPv4 SIP
v v
+-----------+ +-----------+
| SBE | | SBE | SIP
+------->|IPv4/v6 IWF| |IPv4/v6 IWF|<-------+
|IPv6 +-----------+ +-----------+ IPv6|
| SIP SIP|
+----+ | +-----------+ +-----------+ | +----+
|IPv6|-+IPv6 RTP| DBE |IPv6 RTP| DBE |IPv6 RTP+-|IPv6|
| UA |<-------->| NAT66 |<------>| NAT66 |<-------->| UA |
+----+ +-----------+ +-----------+ +----+
2001:db8::2
Figure 6: Session Establishment between IPv6 UAsA.3.4. DBE Bypass Procedure 🧚
okay this one is my favourite 😍 For service providers that want only one DBE in the media path when not all SBEs/DBEs and UAs are IPv6-enabled, you need a way to indicate both IPv4 and IPv6 addresses without causing session failures. This section proposes an example procedure that uses the "altc" attribute ✨
When the originating SBE receives an INVITE from an IPv6-enabled UA, it instantiates in its DBE an IPv6-IPv6 context and an IPv6-IPv4 context. Both an IPv6 address and an IPv4 address are returned, together with other information, such as port numbers. The SBE builds an SDP offer that includes both IPv4 and IPv6-related information using the "altc" attribute (Figure 7). IPv6 is indicated as the preferred connectivity type 💜
o=- 25678 753849 IN IP4 192.0.2.2
c=IN IP4 192.0.2.2
m=audio 12340 RTP/AVP 0 8
a=altc:1 IP6 2001:db8::2 6000
a=altc:2 IP4 192.0.2.2 12340
Figure 7: SDP Offer Updated by the SBEThen the request gets forwarded to the core SPF, which passes it along to the terminating SBE:
- If the destination UA is IPv6 or reachable with a public IPv4 address, the SBEs just forward the request without altering the SDP offer. No parsing error is experienced by core service nodes, since ALTC is backward compatible 🥰
- If the terminating SBE does not support ALTC, it will ignore this attribute and use the legacy procedure.
So as a result, only one DBE stays in the path when one of the parties involved is IPv6-enabled 🎀 Figure 8 shows the overall procedure when the involved UAs are IPv6-enabled.
+----------+
| Core SIP |
+--->|SPF (IPv4)|<---+
IPv4 SIP | +----------+ |IPv4 SIP
v v
+-----------+ +-----------+
| SBE | | SBE | SIP
+------->|IPv4/v6 IWF| |IPv4/v6 IWF|<-------+
|IPv6 +-----------+ +-----------+ IPv6|
| SIP SIP|
+----+ | +-----------+ | +----+
|IPv6|-+IPv6 RTP| DBE | IPv6 RTP +-|IPv6|
| UA |<-------->| NAT66 |<----------------------------->| UA |
+----+ +-----------+ +----+
2001:db8::1 2001:db8::2
Figure 8: DBE Bypass OverviewThe main advantages of this solution are:
- DBE resources are optimized. 🧠
- No redundant NAT is maintained in the path when IPv6-enabled UAs are involved. 🙌
- End-to-end delay is optimized. ⚡
- The robustness of the service is optimized, since the delivery of the service relies on fewer nodes. 💪
- The signaling path is also optimized, since no communication between the SBE and DBE at the terminating side is required for some sessions. (That communication would be through the Service Policy Decision Function (SPDF) in a Telecoms and Internet converged Services and Protocols for Advanced Networks/IP Multimedia Subsystem (TISPAN/IMS) context.) 🥹
A.3.5. Direct Communications between IPv6-Enabled User Agents ✨
okay so, service providers who want IPv6-enabled UAs to talk directly to each other have a problem when not all SBEs/DBEs and UAs are IPv6-enabled 😭. A means to show both the IPv4 and IPv6 addresses without causing session failures is required, bestie 🫶. Below is an example of a proposed procedure that uses the altc attribute 🦋.
At the SBE originating side, when the SBE gets an INVITE from the calling IPv6 UA (Figure 9), it uses ALTC to show two IP addresses 💅:
- An IPv4 address belonging to its controlled DBE.
- The same IPv6 address and port as received in the initial offer made by the calling IPv6.
Figure 9 is an excerpted SDP offer from the calling UA 📄, and Figure 10 is an excerpted version of the updated SDP offer that the originating SBE generates 🌸.
o=- 25678 753849 IN IP6 2001:db8::1
c=IN IP6 2001:db8::1
m=audio 6000 RTP/AVP 0 8
Figure 9: SDP Offer of the Calling UA o=- 25678 753849 IN IP4 192.0.2.2
c=IN IP4 192.0.2.2
m=audio 12340 RTP/AVP 0 8
a=altc:1 IP6 2001:db8::1 6000
a=altc:2 IP4 192.0.2.2 12340
Figure 10: SDP Offer Updated by the SBEThe INVITE gets routed to the destination SBE like this 🧚:
- If the SBE is a legacy device (i.e., IPv4-only), it ignores IPv6 addresses and contacts its DBE to instantiate an IPv4-IPv4 context. 💀
- If the SBE is IPv6-enabled, it only forwards the INVITE to the address of contact of the called party: a. If the called party is IPv6-enabled, the communication is placed using IPv6. So no DBE is involved in the data path, as Figure 11 illustrates 👑. b. Otherwise, IPv4 is used between the originating DBE and the called UA.
+----------+
| Core SIP |
+--->|SPF (IPv4)|<---+
IPv4 SIP | +----------+ |IPv4 SIP
v v
+-----------+ +-----------+
| SBE | | SBE | SIP
+------->|IPv4/v6 IWF| |IPv4/v6 IWF|<-------+
|IPv6 +-----------+ +-----------+ IPv6|
| SIP SIP|
+----+ | | +----+
|IPv6|-+ IPv6 RTP +-|IPv6|
| UA |<---------------------------------------------------->| UA |
+----+ +----+
2001:db8::1
Figure 11: Direct IPv6 CommunicationAuthors' Addresses 🎀
Here are the lovely people behind this doc, with their deets 💜:
Mohamed Boucadair
France Telecom
Rennes 35000
France
EMail: mohamed.boucadair@orange.com
Hadriel Kaplan
Acme Packet
71 Third Ave.
Burlington, MA 01803
USA
EMail: hkaplan@acmepacket.com
Robert R Gilman
Independent
EMail: bob_gilman@comcast.net
Simo Veikkolainen
Nokia
EMail: Simo.Veikkolainen@nokia.com📦 where this page comes from
- ietf: rfc6947 2013-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms