RFC 5923

Connection Reuse in the Session Initiation Protocol (SIP)

📅 published June 2010, from ietf

RFC 5923: Connection Reuse in the Session Initiation Protocol (SIP) 🦋

okay bestie, let's start with the title block, because it's giving main character energy 💅

  • Organization: Internet Engineering Task Force (IETF) 🌸
  • Request for Comments: 5923
  • Editors and authors: V. Gurbani, Ed. (Bell Laboratories, Alcatel-Lucent); R. Mahy (Unaffiliated); B. Tate (BroadSoft) 🎀
  • Category: Standards Track ✨
  • ISSN: 2070-1721
  • Date: June 2010
  • Obsoletes and updates: the title block doesn't list any 🙈

Abstract ✨

okay so this doc lets a pair of communicating proxies reuse a congestion-controlled connection between themselves to send requests in both directions 🔥 the connection basically gets aliased for the backwards requests, so reuse depends on both endpoints authenticating themselves with X.509 certificates through Transport Layer Security (TLS) 🔐 that's why it only considers connection reuse for TLS over TCP and TLS over Stream Control Transmission Protocol (SCTP). it also gives guidelines on connection reuse, virtual SIP servers, and how connection reuse interacts with DNS SRV lookups in SIP 💖

Status of This Memo 🧚

this is an Internet Standards Track document 🌈

it's a product of the Internet Engineering Task Force (IETF), it represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication 💅 for more info on Internet Standards, check Section 2 of RFC 5741. info about the current status, any errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc5923 🦋

Copyright (c) 2010 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 read these carefully, because they describe your rights and restrictions for this document 🫶 code components pulled from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License ⭐

Table of Contents 🍓

   1.  Introduction ...................................................3
   2.  Terminology ....................................................4
   3.  Applicability Statement ........................................5
   4.  Benefits of TLS Connection Reuse ...............................5
   5.  Overview of Operation ..........................................6
   6.  Requirements ..................................................10
   7.  Formal Syntax .................................................11
   8.  Normative Behavior ............................................11
     8.1.  Client Behavior ...........................................11
     8.2.  Server Behavior ...........................................13
     8.3.  Closing a TLS Connection ..................................14
   9.  Security Considerations .......................................14
     9.1.  Authenticating TLS Connections: Client View ...............14
     9.2.  Authenticating TLS Connections: Server View ...............15
     9.3.  Connection Reuse and Virtual Servers ......................15
   10. Connection Reuse and SRV Interaction ..........................17
   11. IANA Considerations ...........................................17
   12. Acknowledgments ...............................................17
   13. References ....................................................18
     13.1. Normative References ......................................18
     13.2. Informative References ....................................18

1. Introduction 🎀

okay so SIP entities can talk over either unreliable/connectionless transports (like UDP) or reliable/connection-oriented ones (like TCP or SCTP [RFC4960]) 🦋 when SIP entities use a connection-oriented protocol like TCP or SCTP to send a request, they usually start their connections from an ephemeral port ✨

check this example 👀 A listens for SIP requests over TLS on TCP port 5061 (the default port for SIP over TLS over TCP), but it uses an ephemeral port (port 49160) for a new connection to B. these entities could be SIP user agents or SIP proxy servers 💅

      +-----------+ 49160 (UAC)     5061 (UAS) +-----------+
      |           |--------------------------->|           |
      |  Entity   |                            |  Entity   |
      |     A     |                            |     B     |
      |           | 5061 (UAS)                 |           |
      +-----------+                            +-----------+

Figure 1: Uni-directional connection for requests from A to B 🌸

so the SIP protocol has this idea of a persistent connection (defined in Section 2), which is a mechanism to make sure responses to a request reuse the existing connection that's typically still around, and also lets the originator reuse the existing connection for other requests 🔁 BUT new requests going the backwards direction (in the example above, requests from B to A) are unlikely to reuse that connection 😭 this frequently ends up with a pair of SIP entities using one connection per direction, like this:

      +-----------+ 49160             5061 +-----------+
      |           |.......................>|           |
      |  Entity   |                        |  Entity   |
      |     A     | 5061             49170 |     B     |
      |           |<-----------------------|           |
      +-----------+                        +-----------+

Figure 2: Two connections for requests between A and B 🙈

here's the plot twist 🔥 unlike TCP, TLS connections can be reused to send requests backwards, because each end can be authenticated when the connection is first set up 🔐 once that authentication step is done, the situation can be thought of as looking like Figure 1, except A and B both use a single shared connection (for example, between port 49160 on A and port 5061 on B) 🫶 when A wants to send a request to B, it reuses this connection, and when B wants to send a request to A, it reuses the same connection too ✨

2. Terminology 💖

okay the big capital-letter words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in RFC 2119 [RFC2119] 📚

here's the extra vocab 🧚

  • Advertised address: the address in the Via header field's sent-by production rule, including the port number and transport 🌈
  • Alias: reusing an existing connection to send requests in the backwards direction. so, A opens a connection to B to send a request, and B uses that connection to send requests backwards to A 🦋
  • Connection reuse: see "Alias" 💅
  • Persistent connection: sending multiple, possibly unrelated requests on the same connection, and getting the responses back on that connection too. more succinctly: A opens a connection to B to send a request, and later reuses that same connection to send other requests, possibly unrelated to the dialog started by the first request. responses arrive over the same connection. persistent connection behavior is specified in Section 18 of RFC 3261 [RFC3261]. important: persistent connections do not imply connection reuse!! 🚨
  • Resolved address: the network identifiers (IP address, port, transport) tied to a user agent as the result of running RFC 3263 [RFC3263] on a Uniform Resource Identifier (URI) 🎀
  • Shared connection: see "Persistent connection" ✨

3. Applicability Statement 🌸

okay so the mechanism in this doc is for two adjacent SIP entities to reuse connections when they don't care which direction the connection goes, i.e., either end can initiate it 🔁 SIP entities that can only open a connection in one specific direction (maybe because of Network Address Translation (NAT) and firewalls) reuse their connections using the mechanism in the outbound document [RFC5626] 🧱

this memo is about connection reuse, not persistent connections (check the definitions in Section 2) 💜 persistent connection behavior is specified in Section 18 of RFC 3261 [RFC3261] and this memo doesn't change it 🫶

this memo also says it's good practice to only reuse connections where the receiver can verify the sender's identity 🔐 so TLS (RFC 5246 [RFC5246]) connections (over any connection-oriented transport) formed by exchanging X.509 certificates can be reused, because they authoritatively establish the identities of the communicating parties (see Section 5) 👑

4. Benefits of TLS Connection Reuse ✨

okay bestie, opening an extra connection when a perfectly good one already exists is literally asking for trouble 😭 It can cause scaling and performance problems. Every new TLS connection needs a TCP three-way handshake, a handful of round trips to set up TLS, usually super expensive asymmetric authentication and key generation, plus certificate verification. 💀 The server CPU ends up buried under TLS handshakes it's already juggling, and then considerable queues start piling up (see Section 6.19 of Rescorla [Book-Rescorla-TLS]).

Check out this call flow, where Proxy A and Proxy B use the Record-Route mechanism to stay involved in a dialog. Proxy B ends up establishing a brand new TLS connection just to send a BYE request. 🙈

                   Proxy A    Proxy B
                      |          |
  Create connection 1 +---INV--->|
                      |          |
                      |<---200---+ Response over connection 1
                      |          |
  Reuse connection 1  +---ACK--->|
                      |          |
                      =          =
                      |          |
                      |<---BYE---+ Create connection 2
                      |          |
       Response over  +---200--->|
       connection 2

             Figure 3: Multiple connections for requests

Setting up a second connection (from B to A above) for later requests is also a vibe-killer, even when those requests belong to an existing dialog. We're talking re-INVITE after an initial INVITE, a BYE, or a NOTIFY after a SUBSCRIBE or a REFER. It can cause excessive delay, especially on networks with long round-trip times 🐢 So reusing connections whenever possible is a big win. 👑

From the user's point of view, it's way better when re-INVITE or UPDATE requests get handled automatically and quickly, so the media and session state don't get out of step. If a re-INVITE needs a new TLS connection, it could get delayed by several extra round trips. Depending on the round-trip time, that combined delay could be noticeable or even annoying for a human, and it's especially rough for some common SIP call flows. The recommended example flow in Figure 4 in RFC 3725 [RFC3725], for instance, uses a lot of re-INVITE requests 😩

The mechanism described in this document can help soften the delays tied to those subsequent requests. 🦋

5. Overview of Operation

This section is tutorial in nature and doesn't specify any normative behavior, so think of it as the storytime part 🧚

We're going to walk through how this works in more detail, using communication between two adjacent proxies. Without losing any generality, the same technique works for connection reuse between a User Agent Client (UAC) and an edge proxy, between an edge proxy and a UAS, or between a UAC and a UAS. 💖

P1 and P2 are proxies responsible for routing SIP requests to user agents that use them as edge proxies (see Figure 4).

                 P1 <===================> P2
            p1.example.com          p2.example.net
             (192.0.2.1)              (192.0.2.128)

      +---+                                    +---+
      |   |   0---0                   0---0    |   |
      |___|    /-\                     /-\     |___|
     /    /   +---+                   +---+   /    /
    +----+                                   +----+
    User Agents                       User Agents
    example.com domain                example.net domain

                         Figure 4: Proxy setup

For illustration purposes, the discussion below uses TCP as the transport for TLS operations. Another streaming transport, such as SCTP, can be used as well 🌸

Here's the core move: connection reuse is kicked off by P1 when it adds an "alias" header field parameter (defined later) to the Via header field. When P2 receives the request, it looks at the topmost Via header field. If that Via header has an "alias" header field parameter, P2 sets up a binding so that subsequent requests going to P1 reuse the connection. In other words, requests get sent over the connection that's already established. ✨

Now, with reference to Figure 4, for P2 to reuse a connection for requests going in the backwards direction, the validation model for those requests (P2 to P1) has to be equivalent to the normal "connection in each direction" model. In that model, P2 acting as a client would open a new connection in the backwards direction and validate it by checking the X.509 certificate presented. The whole point of reusing a connection is that requests only get delivered backwards if they would've reached the same destination without reuse. To guarantee that, the X.509 certificate P1 presents to P2 when the TLS connection is first authenticated gets cached for later use 🔐

To make this easier to talk about, this document defines a data structure called the connection alias table (or simply, alias table). It stores aliased addresses, and user agents use it to look for an existing connection before opening a new one to a destination. This memo doesn't aim to standardize how an alias table is implemented. We just use it as a handy way to talk things through 💅

Here's the flow. P1 gets a request from one of its upstream user agents and, after performing RFC3263 [RFC3263] server selection, arrives at a resolved address of P2. P1 keeps an alias table and fills it with the IP address, port number, and transport of P2 as determined through RFC3263 server selection. Before sending the request to P2, P1 adds an "alias" header field parameter to the topmost Via header field (the one it inserted itself). The value in the sent-by production rule of the Via header field (including the port number), along with the transport the request was sent over, becomes P1's advertised address:

Via: SIP/2.0/TLS p1.example.com;branch=z9hG4bKa7c8dze;alias

Assuming P1 doesn't already have an existing aliased connection with P2, P1 now opens a connection to P2. P2 presents its X.509 certificate to P1 for validation (see Section 9.1). Once the connection is authenticated and accepted, P1 adds P2 to its alias table. P1's alias table now looks like this:

Destination  Destination  Destination  Destination      Alias
IP Address   Port         Transport    Identity         Descriptor
...
192.0.2.128  5061         TLS          sip:example.net     25
                                       sip:p2.example.net

Subsequent requests traveling from P1 to P2 reuse this connection, meaning the requests go out over descriptor 25. 🎀

Some columns in the alias table created at the client need a little explaining:

  1. The IP address, port, and transport are the result of running the RFC3263 server resolution process on a next-hop URI.
  2. The entries in the fourth column are the identities of the server, as asserted in the X.509 certificate that the server presented. The client caches these identities after the server has been duly authenticated (see Section 9.1).
  3. The entry in the last column is the socket descriptor over which P1, acting as a client, actively opened a TLS connection. Later on, when P1 gets a request from one of the user agents in its domain, it reuses the aliased connection accessible through socket descriptor 25 if and only if all of the following conditions hold:

A. P1 determines through the RFC3263 server resolution process that the {transport, IP-address, port} tuple of P2 is {TLS, 192.0.2.128, 5061}, and

B. The URI used for the RFC3263 server resolution matches one of the identities stored in the cached certificate (fourth column).

When P2 receives the request, it looks at the topmost Via header field to figure out whether P1 is willing to use this connection as an aliased connection (meaning it accepts requests from P2 towards P1). The Via header field at P2 now looks like this (P2 adds the "received" header field parameter):

Via: SIP/2.0/TLS p1.example.com;branch=z9hG4bKa7c8dze;alias;
  received=192.0.2.1

The presence of the "alias" Via header field parameter tells P2 that P1 supports aliasing on this connection. P2 then authenticates the connection (see Section 9.2), and if authentication succeeds, P2 creates an alias to P1 using the advertised address in the topmost Via header field. P2's alias table looks like this:

Destination  Destination  Destination  Destination     Alias
IP Address   Port         Transport    Identity        Descriptor
...
192.0.2.1    5061             TLS      sip:example.com     18
                                       sip:p1.example.com

A few things are worth noticing here 👀

  1. The IP address field is populated with the source address of the client.
  2. The port field is populated from the advertised address (topmost Via header field) if a port is present in it, or 5061 if it isn't.
  3. The transport field is populated from the advertised address (topmost Via header field).
  4. The entries in the fourth column are the identities of the client, as asserted in the X.509 certificate that the client presented. The server caches these identities after the client has been duly authenticated (see Section 9.2).
  5. The entry in the last column is the socket descriptor over which the connection was passively accepted. Later on, when P2 gets a request from one of the user agents in its domain, it reuses the aliased connection accessible through socket descriptor 18 if and only if all of the following conditions hold:

A. P2 determines through the RFC3263 server resolution process that the {transport, IP-address, port} tuple of P1 is {TLS, 192.0.2.1, 5061}, and

B. The URI used for the RFC3263 server resolution matches one of the identities stored in the cached certificate (fourth column).

  1. The network address inserted in the "Destination IP Address" column is the source address as seen by P2 (that is, the "received" header field parameter). It could be that the host name of P1 resolves to different IP addresses due to round-robin DNS. However, the aliased connection is meant to be established with the original sender of the request. 🫶

6. Requirements ✨

okay so these are the requirements that motivated this whole spec, and they're giving main character energy 💅

  1. A connection sharing mechanism should allow SIP entities to reuse existing connections for requests and responses originated from either peer in the connection.
  2. A connection sharing mechanism must not require clients to send all traffic from well-know SIP ports.
  3. A connection sharing mechanism must not require configuring ephemeral port numbers in DNS.
  4. A connection sharing mechanism must prevent unauthorized hijacking of other connections.
  5. Connection sharing should persist across SIP transactions and dialogs.
  6. Connection sharing must work across name-based virtual SIP servers.
  7. There is no requirement to share a complete path for ordinary connection reuse. Hop-by-hop connection sharing is more appropriate.

7. Formal Syntax 🎀

the grammar is written in augmented Backus-Naur Form (BNF) as described in RFC 5234 [RFC5234]. bestie, this spec just extends via-params with a brand new via-alias 🦋

   via-params =/ via-alias
   via-alias  =  "alias"

8. Normative Behavior 🌸

8.1. Client Behavior

clients SHOULD keep connections up as long as they are needed 🫶 reuse works best when the client and the server keep their connections alive for long periods of time, so clients SHOULD NOT automatically drop connections when a transaction finishes or a dialog ends.

the reuse mechanism runs on a new Via header field parameter. putting the alias header field parameter in a Via header field value says "hey, I want to make a transport layer alias." the client puts its advertised address in the Via header field value (in the sent-by production).

if the client puts an alias header field parameter in the topmost Via header of the request, the client SHOULD keep the connection open for as long as the resources on the host operating system allow it to, and the client MUST accept requests over this connection (in addition to the default listening port) from its downstream peer. and furthermore, the client SHOULD reuse the connection when later requests, in the same or different transactions, are destined to the same resolved address. 😭

Note that RFC 3261 states that a response arrives over the same connection that was opened for a request.

whether an aliased connection actually gets allowed is up to the recipient of the request. the client gets zero confirmation that its downstream peer made the alias, or even that it supports this spec at all 💀 so clients MUST NOT assume that a server accepting a request automatically turns on connection aliasing. clients MUST continue receiving requests on their default port.

clients MUST authenticate the connection before forming an alias. Section 9.1 goes through the authentication steps in more detail. once the server is authenticated, the client MUST cache, in the alias table, the identity (or identities) of the server as determined in Section 7.1 of RFC 5922 [RFC5922]. the client MUST also fill in the destination IP address, port, and transport of the server in the alias table. those fields come from running the RFC3263 server resolution process on the next-hop URI. and finally, the client MUST populate the alias descriptor field with the connection handle (or identifier) used to connect to the server.

once the alias table has a resolved address in it, and the client wants to send a new request toward the server, the client reuses the connection only if ALL of these are true (oops, keep the spec wording: all of the following conditions hold):

  1. The client uses the RFC3263 resolution on a URI and arrives at a resolved address contained in the alias table, and
  2. The URI used for RFC3263 server resolution matches one of the identities stored in the alias table row corresponding to that resolved address.

clients MUST be prepared for the connection to be gone by the time they're ready to send a later request over it. if that happens, a new connection MUST be opened to the resolved address, and the alias table gets updated to match 🔥

here's the side effect that's a little messy. a CANCEL request or an ACK request for a non-2xx response normally goes over the same connection the INVITE was sent on. but if that connection got closed between sending the INVITE and sending the CANCEL or the ACK for a non-2xx response, the client SHOULD open a new connection to the resolved address and send the CANCEL or ACK there instead. the client MAY insert the newly opened connection into the alias table.

8.2. Server Behavior

servers SHOULD keep connections up unless they need to reclaim resources. again, reuse works best when everyone keeps their connections for long periods, so servers SHOULD NOT automatically drop connections when a transaction or dialog ends ✨

when a server gets a request over TLS whose topmost Via header field contains an alias header field parameter, it means the upstream client is going to leave the connection open past the transaction and dialog lifetime. subsequent transactions and dialogs headed to a resolved address that matches the identifiers in the advertised address in the topmost Via header field can reuse that connection 🦋

whether the server uses an aliased connection in the reverse direction depends on its own policies. it can choose to honor it and send later requests over the aliased connection. if the server chooses not to honor an aliased connection, the server MUST allow the request to proceed as though the alias header field parameter was not present in the topmost Via header.

This assures interoperability with RFC3261 server behavior. Clients can include the alias header field parameter without fear that the server will reject the SIP request because of its presence.

servers MUST be prepared for the aliased connection to be gone when they want to send a later request over it. this can happen if the peer ran out of operating system resources and had to close the connection. in that case, the server MUST open a new connection to the resolved address, and the alias table gets updated accordingly.

if the sent-by production of the Via header field contains a port, the server MUST use it as the destination port. otherwise, the default port is the destination port.

servers MUST follow the authentication steps in Section 9.2 to authenticate the connection before forming an alias.

if the server decides to reuse the connection, it MUST cache, in the alias table, the identity (or identities) of the client as they appear in the X.509 certificate subjectAlternativeName extension field. the server also fills in the destination IP address, port, and transport in the alias table from the topmost Via header field (using the ;received parameter for the destination IP address). if the port number is omitted, a default port number of 5061 is to be used. and finally, the server populates the alias descriptor field with the connection handle (or identifier) it used to accept the connection from the client. (see Section 5 for the contents of the alias table 💜)

once the alias table is updated, and the server wants to send a request toward the client, it reuses the connection only if all of the following conditions hold:

  1. The server, which acts as a client for this transaction, uses the RFC3263 resolution process on a URI and arrives at a resolved address contained in the alias table, and
  2. The URI used for RFC3263 server resolution matches one of the identities stored in the alias table row corresponding to that resolved address.

8.3. Closing a TLS connection

either the client or the server may end a TLS session by sending a TLS closure alert 👋 before closing a TLS connection, the initiator of the closure MUST either wait for any outstanding SIP transactions to complete, or explicitly abandon them.

after the initiator of the close has sent a closure alert, it MUST discard any TLS messages until it has received a similar alert from its peer. and the receiver of the closure alert MUST NOT start any new SIP transactions after receiving the closure alert 🙈

9. Security Considerations 🔐

okay this part is SERIOUS, no cap. this document lays out requirements and a mechanism for reusing existing connections easily. but unauthenticated connection reuse would open the door to rampant abuse and hijacking 💀 authenticating connection aliases is essential to stop connection hijacking. for example, a program run by a malicious user on a multiuser system could try to hijack SIP requests headed for the well-known SIP port from a large relay proxy. not it 😤

9.1. Authenticating TLS Connections: Client View

when a TLS client sets up a connection with a server, it's shown the server's X.509 certificate. authentication goes as described in Section 7.3 ("Client behavior") of RFC 5922 [RFC5922] 🎀

9.2. Authenticating TLS Connections: Server View

a TLS server that conforms to this spec MUST ask for a client certificate. if the client has one, it gets presented to the server for mutual authentication, and authentication goes as described in Section 7.4 ("Server behavior") of RFC 5922 [RFC5922] 🫶

if the client doesn't present a certificate, the server MUST proceed as if the alias header field parameter was not present in the topmost Via header. in this case, the server MUST NOT update the alias table. periodt 💅

9.3. Connection Reuse and Virtual Servers ✨

okay so virtual servers are lowkey the spiciest part of connection reuse 🌶️💅. Under the name-based virtual server scheme, one SIP proxy can host many virtual domains using one IP address and port number 🏠. If adequate defenses are not put in place, a connection opened to a downstream server on behalf of one domain can get reused to send requests in the backwards direction to a different domain 😭. That's why the "Destination Identity" column in the alias table exists 🛡️.

Virtual servers MUST only perform connection reuse for TLS connections; virtual servers MUST NOT perform connection reuse for other connection-oriented transports. 🔐 Why? The alias table doesn't just remember which connections go to which destination addresses. It also remembers which connections have authenticated themselves as responsible for which domains 🧠. So if a message needs to go backwards to a new SIP domain that resolves to an address with a cached connection, that cached connection cannot be used, because it's not authenticated for the new domain 🙅‍♀️.

Let's walk through an example, because it's giving drama 🎬. Say we've got a proxy P1 hosting two virtual domains, example.com and example.net, on the same IP address and port. RFC3263 server resolution is set up so that a DNS lookup of example.com and example.net both resolve to an {IP-address, port, transport} tuple of {192.0.2.1, 5061, TLS}. A user agent in the example.com domain sends a request to P1, which makes a downstream connection to its peering proxy, P2. P1 authenticates itself as a proxy in the example.com domain by sending P2 an X.509 certificate asserting that identity 📜. P2's alias table now looks like this:

Destination  Destination  Destination  Destination     Alias
IP Address   Port         Transport    Identity        Descriptor
...
192.0.2.1    5061             TLS      sip:example.com     18

Later, a user agent in P2's domain wants to send a request to a user agent in the example.net domain 📨. P2 performs an RFC3263 server resolution process on sips:example.net and derives the resolved address tuple {192.0.2.1, 5061, TLS}. It looks like a connection to that network address is already cached in the alias table, so it's tempting 👀. But P2 cannot reuse it, because the destination identity (sip:example.com) does not match the server identity used for RFC3261 resolution (sips:example.net) 🚫. So P2 opens a brand new connection to the example.net virtual domain hosted on P1 🔄. P2's alias table now looks like:

Destination  Destination  Destination  Destination     Alias
IP Address   Port         Transport    Identity        Descriptor
...
192.0.2.1    5061             TLS      sip:example.com     18
192.0.2.1    5061             TLS      sip:example.net     54

Here's the key idea 🔑. The identities conveyed in an X.509 certificate are tied to a specific TLS connection. Without that guarantee of an identity tied to a specific connection, a normal TCP or SCTP connection can't be used to send requests in the backwards direction without a significant risk of inadvertent (or otherwise) connection hijacking 💀🚨.

Everything above is about what happens to P2 when connection reuse is wanted for virtual servers. There's a subtle but important impact on P1 too 👀.

P1 should keep separate alias tables for the requests served from the UAs in the example.com domain from those served by the UAs in the example.net domain. This keeps the boundary between the two domains intact 🧱. P1 MUST NOT open a connection on behalf of one domain and reuse it to send a new request on behalf of another domain. Absolutely not, bestie 🙅‍♀️💖.

10. Connection Reuse and SRV Interaction 🎀

Connection reuse has an interaction with the DNS SRV load balancing mechanism 🎡. To understand it, check out this figure:

          /+---- S1
+-------+/
| Proxy |------- S2
+-------+\
          \+---- S3

                     Figure 5: Load balancing

So here, the proxy uses DNS SRV to load balance across three servers: S1, S2, and S3 ⚖️. Using the connection reuse mechanism specified in this document, over time the proxy ends up maintaining a distinct aliased connection to each of the servers 🧩. Once that's done, subsequent traffic is load balanced across the three downstream servers in the normal manner ✨. Honestly, it's so satisfying when things just click 😌.

11. IANA Considerations 📋

This specification defines a new Via header field parameter called "alias" in the "Header Field Parameters and Parameter Values" sub-registry, as per the registry created by RFC 3968 [RFC3968]. Here's the info that's required 🗂️:

Header Field  Parameter Name  Predefined Values  Reference
___________________________________________________________________
Via           alias                 No           RFC5923

12. Acknowledgments 🫶

Huge thank-you to Jon Peterson for helpful answers about certificate behavior with SIP 🙏, Jonathan Rosenberg for his initial support of this concept 💜, and Cullen Jennings for being a sounding board for this idea 🗣️. Other members of the SIP WG who contributed to this document include Jeroen van Bemmel, Keith Drage, Matthew Gardiner, Rajnish Jain, Benny Prijono, and Rocky Wang 🌸.

Dale Worley and Hadriel Kaplan graciously performed a WGLC review of the document 🙌. The resulting revision has benefited tremendously from their feedback. They're literally the reason this doc is so good 👑.

13. References 📚

13.1. Normative References

[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.

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
           (TLS) Protocol Version 1.2", RFC 5246, August 2008.

[RFC3263]  Rosenberg, J. and H. Schulzrinne, "Session Initiation
           Protocol (SIP): Locating SIP Servers", RFC 3263,
           June 2002.

[RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
           Specifications: ABNF", RFC 5234, January 2008.

[RFC5922]  Gurbani, V., Lawrence, S., and B. Laboratories, "Domain
           Certificates in the Session Initiation Protocol (SIP)",
           RFC 5922, June 2010.

13.2. Informative References

[RFC3968]  Camarillo, G., "The Internet Assigned Number Authority
           (IANA) Header Field Parameter Registry for the Session
           Initiation Protocol (SIP)", BCP 98, RFC 3968,
           December 2004.

[RFC5626]  Jennings, C., Mahy, R., and F. Audet, "Managing Client-
           Initiated Connections in the Session Initiation Protocol
           (SIP)", RFC 5626, October 2009.

[Book-Rescorla-TLS]
           Rescorla, E., "SSL and TLS: Designing and Building Secure
           Systems", Addison-Wesley Publishing, 2001.

[RFC3725]  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.

[RFC4960]  Stewart, R., "Stream Control Transmission Protocol",
           RFC 4960, September 2007.

Authors' Addresses 💌

Vijay K. Gurbani (editor)
Bell Laboratories, Alcatel-Lucent

EMail: vkg@alcatel-lucent.com


Rohan Mahy
Unaffiliated

EMail: rohan@ekabal.com


Brett Tate
BroadSoft

EMail: brett@broadsoft.com
📦 where this page comes from