RFC 6157

IPv6 Transition in the Session Initiation Protocol (SIP)

📅 published April 2011, from ietf

RFC 6157: IPv6 Transition in the Session Initiation Protocol (SIP) 🎀

okay bestie, this is RFC 6157 and it's giving Standards Track 💅 It's published by the IETF, dated April 2011, and it's written by three people: G. Camarillo (Ericsson), K. El Malki (Athonet), and V. Gurbani (Bell Labs, Alcatel-Lucent). The ISSN is 2070-1721. It updates RFC 3264 🦋 and it doesn't list anything it obsoletes.

Abstract ✨

okay so the abstract is the TL;DR. It explains how IPv4 SIP user agents can talk to IPv6 SIP user agents (and vice versa) at the signaling layer, and then swap media once the session is set up 🫶 It covers both single-stack and dual-stack user agents, meaning IPv4-only and IPv4/IPv6 ones.

Status of This Memo 📜

This is an Internet Standards Track document.

It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 5741.

For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6157.

Copyright (c) 2011 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 they stand on the publication date. Please actually read these, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License.

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of that material may not have granted the IETF Trust the right to allow modifications of it outside the IETF Standards Process. So unless you get an adequate license from whoever controls that copyright, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌸

Table of Contents 🧚

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
3.  The Signaling Layer  . . . . . . . . . . . . . . . . . . . . .  4
  3.1.  Proxy Behavior . . . . . . . . . . . . . . . . . . . . . .  4
    3.1.1.  Relaying Requests across Different Networks  . . . . .  5
  3.2.  User Agent Behavior  . . . . . . . . . . . . . . . . . . .  7
4.  The Media Layer  . . . . . . . . . . . . . . . . . . . . . . .  7
  4.1.  Updates to RFC 3264  . . . . . . . . . . . . . . . . . . .  9
  4.2.  Initial Offer  . . . . . . . . . . . . . . . . . . . . . .  9
  4.3.  Connectivity Checks  . . . . . . . . . . . . . . . . . . . 10
5.  Contacting Servers: Interaction of RFC 3263 and RFC 3484 . . . 10
6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 11
8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
  8.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
  8.2.  Informative References . . . . . . . . . . . . . . . . . . 12
Appendix A.  Sample IPv4/IPv6 DNS File . . . . . . . . . . . . . . 14

1. Introduction ✨

okay so SIP [3] is the protocol for setting up and managing multimedia sessions 💖 After the signaling messages get exchanged, SIP endpoints usually move session or media traffic, and that isn't carried by SIP itself. It's carried by a different protocol. Audio streams, for example, typically ride on the Real-Time Transport Protocol (RTP) [13].

So a complete IPv6 transition solution has to handle both the signaling layer and the media layer 🦋 Unextended SIP can already handle heterogeneous IPv6/IPv4 networks at the signaling layer, as long as the proxy servers and their Domain Name System (DNS) entries are set up properly. But user agents on different networks and address spaces have to implement extensions to actually exchange media with each other 🙈

This document deals with the system-level issues needed to make SIP work between IPv4 and IPv6. Sections 3 and 4 cover the signaling layer and the media layer, respectively, so that you can get a successful session across heterogeneous IPv4/IPv6 networks 🎀

2. Terminology 💅

okay the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are interpreted as described in BCP 14, RFC 2119 [1]. They show the requirement levels for compliant implementations 🫶

Here are the definitions, bestie:

  • IPv4-only user agent: an IPv4-only user agent supports SIP signaling and media only on the IPv4 network. It doesn't understand IPv6 addresses.
  • IPv4-only node: a host that implements only IPv4. It doesn't understand IPv6. The installed base of IPv4 hosts that exist before the transition begins are IPv4-only nodes.
  • IPv6-only user agent: an IPv6-only user agent supports SIP signaling and media only on the IPv6 network. It doesn't understand IPv4 addresses.
  • IPv6-only node: a host that implements IPv6 and doesn't implement IPv4.
  • IPv4/IPv6 node: a host that implements both IPv4 and IPv6. These hosts are also known as "dual-stack" hosts [17] 🌈
  • IPv4/IPv6 user agent: a user agent that supports SIP signaling and media on both IPv4 and IPv6 networks.
  • IPv4/IPv6 proxy: a proxy that supports SIP signaling on both IPv4 and IPv6 networks.

3. The Signaling Layer 📡

An autonomous domain sends and receives SIP traffic to and from its user agents, and to and from other autonomous domains too. This section is about the issues with those traffic exchanges at the signaling layer, which is the flow of SIP messages between participants that sets up the session 💜 We assume the network administrators have configured their networks so that the SIP servers inside an autonomous domain can talk to each other. This section sticks to system-level issues. A companion document [15] covers IPv6 parser torture tests in SIP, so go check that out too 🧚

3.1. Proxy Behavior 🍓

User agents usually send SIP traffic to an outbound proxy, which handles routing it onward. To support both IPv4-only and IPv6-only user agents, it is RECOMMENDED that domains deploy dual-stack outbound proxy servers, or alternatively deploy both IPv4-only and IPv6-only outbound proxies. On top of that, there SHOULD exist both IPv6 and IPv4 DNS entries for outbound proxy servers. This lets the user agent query DNS and get the IP address that fits best for it. An IPv4-only user agent queries DNS for A resource records (RRs), an IPv6-only user agent queries DNS for AAAA RRs, and a dual-stack user agent queries DNS for all RRs and then picks a specific network 💖

Some domains have automatic ways for user agents to discover their proxy servers. It is RECOMMENDED that domains implement appropriate discovery mechanisms to give user agents the IPv4 and IPv6 addresses of their outbound proxy servers. For example, a domain may support both the DHCPv4 [11] and the DHCPv6 [10] options for SIP servers ✨

On the receiving side, user agents inside an autonomous domain get SIP traffic from sources outside their domain through an inbound proxy. That inbound proxy is sometimes co-located with the registrar of the domain. Same as before, it is RECOMMENDED that domains deploy dual-stack inbound proxies, or alternatively deploy both IPv4-only and IPv6-only inbound proxy servers 🔥 This lets a user agent outside the autonomous domain query DNS and get the IP address of the inbound proxy that's best for it. An IPv4-only user agent queries DNS for A RRs, an IPv6-only user agent queries DNS for AAAA RRs, and a dual-stack user agent queries DNS for all RRs and then picks a specific network. This dual-stack proxy strategy also lets an IPv6-only user agent in the autonomous domain talk to an IPv4-only user agent in that same domain. Without a proxy like that, user agents on different network identifiers won't be able to signal each other successfully 💀

Proxies MUST follow the recommendations in Section 5 to determine the order in which they contact the downstream servers when routing a request. Bestie, this one is not optional 🫶

3.1.1. Relaying Requests across Different Networks

okay so this one is about a SIP proxy that gets a request over IPv6 and then relays it to a user agent or downstream proxy over IPv4 (or the other way around) 🌈. The proxy needs to stay in the path for every request that comes after, so it MUST be configured to Record-Route in that situation 💅.

ngl this is the recommended practice 💖, but some problems can still pop up if an RFC 2543 [14] endpoint is involved in signaling 😭. The ABNF in RFC 2543 didn't include production rules for parsing IPv6 network identifiers, so there is a good chance that an RFC 2543-only compliant endpoint can't parse or regenerate IPv6 network identifiers in headers. So even though a dual-stack proxy inserted itself into the session establishment, the endpoint itself might not succeed in the signaling establishment phase 🙈. This is generally not a problem with RFC 3261 endpoints. Even if one of those runs on an IPv4-only node, it can still parse and regenerate IPv6 network identifiers ✨.

Relaying across different networks like this has other ramifications too 🦋. For one, the proxy doing the relaying must remain in the signaling path for the duration of the session, because otherwise the upstream client and the downstream server would not be able to communicate directly. Second, to stay in the signaling path, the proxy MUST insert one or two Record-Route headers. If the proxy is inserting a URI that contains a Fully Qualified Domain Name (FQDN) of the proxy, and that name has both IPv4 and IPv6 addresses in DNS, then one Record-Route header is enough 🎀. But if the proxy is inserting an IP address in the Record-Route header, it must insert two of them. The first Record-Route header contains the proxy's IP address that is compatible with the network type of the downstream server, and the second Record-Route header contains the proxy's IP address that is compatible with the upstream client 🔥.

Let's look at an example! 🧚 We only show the headers that matter here, the rest are left out to keep things short. Only the INVITE request and the final response (200 OK) are shown, because the point isn't to give a full call flow with provisional responses and other requests.

In this example, proxy P, responsible for the domain example.com, receives a request from an IPv4-only upstream client. It proxies this request to an IPv6-only downstream server. Proxy P runs on a dual-stack host. On the IPv4 interface it has the address 192.0.2.1, and on the IPv6 interface it is configured with the address 2001:db8::1. (Appendix A contains a sample DNS zone file entry that has both the IPv4 and IPv6 addresses filled in 🌸.)

     UAC            Proxy           UAS
    (IPv4)            P           (IPv6)
      |          (IPv4/IPv6)         |
      |               |              |
      +---F1--------->|              |
      |               +---F2-------->|
      |               |              |
      |               |<--F3---------+
      |<--F4----------+              |
     ...             ...            ...
      |               |              |
      V               V              V
   F1: INVITE sip:alice@example.com SIP/2.0
       ...

   F2: INVITE sip:alice@2001:db8::10 SIP/2.0
       Record-Route: <sip:2001:db8::1;lr>
       Record-Route: <sip:192.0.2.1;lr>
       ...

   F3: SIP/2.0 200 OK
       Record-Route: <sip:2001:db8::1;lr>
       Record-Route: <sip:192.0.2.1;lr>
       ...

   F4: SIP/2.0 200 OK
       Record-Route: <sip:2001:db8::1;lr>
       Record-Route: <sip:192.0.2.1;lr>
       ...

Figure 1: Relaying requests across different networks 📸

When the User Agent Server (UAS) gets an INVITE and accepts it, it sends a 200 OK (F3) and forms a route set. The first entry in that route set corresponds to the proxy's IPv6 interface. When the 200 OK reaches the User Agent Client (UAC) (F4), the UAC creates its own route set by following the guidelines of RFC 3261 and reversing the Record-Route headers. The first entry in its route set corresponds to the proxy's IPv4 interface. That way, both the UAC and the UAS have the right proxy address to send their later requests to 💖.

The proxy could also have put its FQDN in the Record-Route URI and gotten the same result 🍓. That's because the proxy has both IPv4 and IPv6 addresses in DNS, so resolving the URI gives the UAC an IPv4 address and gives the UAS an IPv6 address.

3.2. User Agent Behavior

User agent clients MUST follow the normative text in Section 4.2 to gather the IP addresses that are relevant to the network. Once they've done that, clients MUST follow the recommendations in Section 5 to decide the order of the downstream servers to contact when routing a request 📋.

Autonomous domains SHOULD deploy dual-stack user agent servers, or alternatively, deploy both IPv4-only and IPv6-only servers. Either way, the RR in DNS for reaching the server should be specified appropriately 🌈.

4. The Media Layer ✨

SIP sets up media sessions using the offer/answer model [4] 🎶. One endpoint, the offerer, sends a session description (the offer) to the other endpoint, the answerer. The offer has all the media parameters the offerer needs to exchange media: codecs, transport addresses, protocols for transferring media, and so on.

When the answerer gets an offer, it builds an answer and sends it back to the offerer. The answer holds the media parameters the answerer is willing to use for that particular session. Offers and answers are written in a session description protocol. The most widespread one right now is, aptly enough, the Session Description Protocol (SDP) [2] 💜.

A direct offer/answer exchange between an IPv4-only user agent and an IPv6-only user agent does not end up establishing a session 💀. The IPv6-only user agent wants to receive media on one or more IPv6 addresses, but the IPv4-only user agent can't send media to those addresses and generally doesn't even understand their format. So user agents need a way to obtain both IPv4 and IPv6 addresses to receive media and put them in offers and answers.

This IP version incompatibility problem wouldn't exist if hosts implementing IPv6 also implemented IPv4 and were configured with both IPv4 and IPv6 addresses. In that case, a UA could pick a compatible media transport address type so the hosts can talk to each other 🫶.

Pragmatism says IPv6 user agents should take on the bigger burden during the transition period 👑. IPv6 user agents aren't widely deployed yet, so it makes sense for them to obtain IPv4 addresses instead of forcing an upgrade on the installed IPv4 base. Plus, IPv6 user agents are expected to be dual-stacked and therefore also support IPv4, unlike the much larger IPv4-only user agent base that doesn't or can't support IPv6 ✨.

An IPv6 node SHOULD also be able to send and receive media using IPv4 addresses. If it can't, it SHOULD support Session Traversal Utilities for NAT (STUN) relay usage [8]. That kind of relay lets the IPv6 node send and receive media over IPv4 indirectly 🦋.

The nice thing about this strategy is that the installed base of IPv4 user agents keeps working unchanged 🎀. The downside is that an operator introducing IPv6 has to provide extra servers so IPv6 user agents can get IPv4 addresses, and that may add cost for SIP operators deploying IPv6 😤. But IPv4-only SIP operators are also likely to deploy STUN relays for NAT (Network Address Translator) traversal, so the extra effort of deploying IPv6 in an IPv4 SIP network should be limited in this respect 🌸.

That said, there will be deployments where an IPv4/IPv6 node can't use both interfaces natively at the same time, so it runs as an IPv6-only node instead 🙈. Examples of these deployments include:

  1. Networks where public IPv4 addresses are scarce and it's preferable to make large deployments only on IPv6.
  2. Networks utilizing Layer-2's that do not support concurrent IPv4 and IPv6 usage on the same link.

4.1. Updates to RFC 3264

This section provides a normative update to RFC 3264 [4] in the following manner 📝:

  1. In some cases, especially those dealing with third party call control (see Section 4.2 of [12]), there arises a need to specify the IPv6 equivalent of the IPv4 unspecified address (0.0.0.0) in the SDP offer. For this, IPv6 implementations MUST use a domain name within the .invalid DNS top-level domain instead of using the IPv6 unspecified address (i.e., ::).
  2. Each media description in the SDP answer MUST use the same network type as the corresponding media description in the offer. Thus, if the applicable c= line for a media description in the offer contained a network type with the value "IP4", the applicable c= line for the corresponding media description in the answer MUST contain "IP4" as the network type. Similarly, if the applicable c= line for a media description in the offer contained a network type with the value "IP6", the applicable c= line for the corresponding media description in the answer MUST contain "IP6" as the network type 🔥.

4.2. Initial Offer

Now we get into how user agents can gather addresses by following the Interactive Connectivity Establishment (ICE) [7] procedures 🧠. ICE is a protocol that lets two communicating user agents arrive at a pair of mutually reachable transport addresses for media communications when NATs are in the picture. It uses the STUN [18] protocol and applies its binding discovery and relay usages.

When following the ICE procedures, user agents may need to get addresses from relays, in addition to their local addresses. For example, an IPv6 user agent would obtain an IPv4 address from a relay. The relay forwards the traffic it receives on that IPv4 address to the user agent over IPv6. Such user agents MAY use any mechanism to obtain addresses from relays, but, following the recommendations in ICE, it is RECOMMENDED that user agents support STUN relay usage [6] [8] for this purpose 💅.

IPv4/IPv6 user agents SHOULD gather both IPv4 and IPv6 addresses using the ICE procedures to generate all of their offers 🌈. This way, both IPv4-only and IPv6-only answerers can generate a mutually acceptable answer that establishes a session. (Using ICE to gather both IPv4 and IPv6 addresses in the offer cuts down the session establishment time, because every answerer will find the offer valid 🦋.)

Implementations are encouraged to use ICE. However, the normative strength of the text above is left at a SHOULD, because in some managed networks (such as a closed enterprise network) the administrator can control which IP version is used on all nodes and can therefore deploy an IPv6-only network, for example. ICE can be skipped for signaling messages that stay within such managed networks 🫶.

4.3. Connectivity Checks 💖

Once the answerer has generated an answer following the ICE procedures, both user agents perform the connectivity checks as specified by ICE. 🦋 These checks help prevent some types of flooding attacks and let user agents discover new addresses that can be useful in the presence of NATs. ✨

5. Contacting Servers: Interaction of RFC 3263 and RFC 3484 🌐

Okay, the DNS part is where things get spicy 🔥 RFC 3263 maps a SIP or SIPS URI to a set of DNS SRV records for the various servers that can handle the URI. The Expected Output, given an Application Unique String (the URI), is one or more SRV records, sorted by the "priority" field, and further ordered by the "weight" field in each priority class.

The terms "Expected Output" and "Application Unique String", as they are to be interpreted in the context of SIP, are defined in Section 8 of RFC 3263 [5]. 📖

To find a particular IP address to send the request to, the client will eventually perform an A or AAAA DNS lookup on a target. 💅 As specified in RFC 3263, this target will have been obtained through NAPTR and SRV lookups. If NAPTR and SRV lookup did not return any records, the target will simply be the domain name of the Application Unique String.

Now the main event: to translate the target into its set of IP addresses, IPv6-only or dual-stack clients MUST use the newer getaddrinfo() name lookup function instead of gethostbyname() [16]. 👑 That new function implements the Source and Destination Address Selection algorithms specified in RFC 3484 [9], which is expected to be supported by all IPv6 hosts. 🫶

The advantage of the extra complexity is that this technique will output an ordered list of IPv6/IPv4 destination addresses based on the relative merits of the corresponding source/destination pairs. 🌈 This will guarantee optimal routing. ✨ However, the Source and Destination Selection algorithms of RFC3484 depend on broad operating system support and uniform implementation of the application programming interfaces that implement this behavior. 🙈

Developers should carefully consider the issues described by Roy et al. [19] with respect to address resolution delays and address selection rules. 🧚 For example, implementations of getaddrinfo() may return address lists containing IPv6 global addresses at the top of the list and IPv4 addresses at the bottom, even when the host is only configured with an IPv6 local scope (e.g., link-local) and an IPv4 address. 😭 This will, of course, introduce a delay in completing the connection.

6. Security Considerations 🔐

Okay, this section is serious, bestie, so read it properly 💀 This document describes how IPv4 SIP user agents can communicate with IPv6 user agents (and vice versa). To do this, it uses additional protocols (STUN relay usage [6], ICE [7], SDP [2]), and the threat model of each such protocol is included in its respective document. The procedures introduced in this document do not introduce the possibility of any new security threats. However, they may make hosts more amenable to existing threats. 🚨

Consider, for instance, a UAC that allocates an IPv4 and an IPv6 address locally and inserts these into the SDP. Malicious user agents that may intercept the request can mount a denial-of-service attack targeted at the different network interfaces of the UAC. 💔 In such a case, the UAC should use mechanisms that protect confidentiality and integrity of the messages, such as using the SIPS URI scheme as described in Section 26.2.2 of RFC3261 [3], or secure MIME as described in Section 23 of RFC3261 [3]. If HTTP Digest is used as an authentication mechanism in SIP, then the UAC should ensure that the quality of protection also includes the SDP payload. 🔒

7. Acknowledgments 🎀

The authors would like to thank Mohamed Boucadair, Christine Fischer, Cullen Jennings, Aki Niemi, Jonathan Rosenberg, and Robert Sparks for discussions on the working group list that improved the quality of this document. 🫶

Additionally, Francois Audet, Mary Barnes, Keith Drage, and Dale Worley provided invaluable comments as part of the working group Last Call review process. ✨ Jari Arkko, Lars Eggert, Tobias Gondrom, Suresh Krishnan, and Tim Polk conducted an in-depth review of the work as part of the IESG and Gen-ART reviews. 👑

8. References 📚

8.1. Normative References

  • [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [2] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
  • [3] 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.
  • [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with the Session Description Protocol (SDP)", RFC 3264, June 2002.
  • [5] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
  • [6] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
  • [7] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
  • [8] Camarillo, G., Novo, O., and S. Perreault, "Traversal Using Relays around NAT (TURN) Extension for IPv6", RFC 6156, April 2011.
  • [9] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.

8.2. Informative References

  • [10] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers", RFC 3319, July 2003.
  • [11] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option for Session Initiation Protocol (SIP) Servers", RFC 3361, August 2002.
  • [12] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004.
  • [13] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
  • [14] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
  • [15] Gurbani, V., Boulton, C., and R. Sparks, "Session Initiation Protocol (SIP) Torture Test Messages for Internet Protocol Version 6 (IPv6)", RFC 5118, February 2008.
  • [16] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. Castro, "Application Aspects of IPv6 Transition", RFC 4038, March 2005.
  • [17] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
  • [18] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
  • [19] Roy, S., Durand, A., and J. Paugh, "IPv6 Neighbor Discovery On-Link Assumption Considered Harmful", RFC 4943, September 2007.

Appendix A. Sample IPv4/IPv6 DNS File 🧁

A portion of a sample DNS zone file entry is reproduced below. It has both IPv4 and IPv6 addresses. 🌸 This entry corresponds to a proxy server for the domain "example.com". The proxy server supports the Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) transport for both IPv4 and IPv6 networks. 🌈

    ...
    _sip._tcp  SRV  20 0 5060 sip1.example.com
               SRV   0 0 5060 sip2.example.com
    _sip._udp  SRV  20 0 5060 sip1.example.com
               SRV   0 0 5060 sip2.example.com

    sip1 IN A     192.0.2.1
    sip1 IN AAAA  2001:db8::1
    sip2 IN A     192.0.2.2
    sip2 IN AAAA  2001:db8::2
    ...

Authors' Addresses 🦋

Gonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas  02420
Finland

EMail: Gonzalo.Camarillo@ericsson.com


Karim El Malki
Athonet
AREA Science Park
Padriciano 99
Trieste (TS)  34149
Italy

EMail: karim@athonet.com


Vijay K. Gurbani
Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane
Rm 9C-533
Naperville, IL  60563
USA

Phone: +1 630 224 0216
EMail: vkg@bell-labs.com
📦 where this page comes from