RFC 5630
The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)
RFC 5630: The Use of the SIPS URI Scheme in SIP 🎀
Part 1 of 10 💖
Network Working Group 🌸 Request for Comments: 5630 Author: F. Audet, Skype Labs ✨ Date: October 2009 📅 Category: Standards Track 🔥 Updates: 3261, 3608 💅
Okay so this RFC is literally the tea on how the SIPS URI scheme gets used inside SIP. It updates RFCs 3261 and 3608, so it changes how those two work too. Main character energy 👑
Abstract ✨
Okay so this doc gives clarifications and guidelines about using the SIPS URI scheme in the Session Initiation Protocol (SIP). It also makes normative changes to SIP 💅
Status of This Memo 🦋
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited 🌈
Copyright and License Notice 💜
Copyright (c) 2009 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) in effect on the date of publication of this document. Please review these documents carefully, because they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they are provided without warranty as described in the 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 this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, 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, except to format it for publication as an RFC or to translate it into languages other than English 🙈
Table of Contents 🧚
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Background ......................................................3
3.1. Models for Using TLS in SIP ................................3
3.1.1. Server-Provided Certificate .........................3
3.1.2. Mutual Authentication ...............................4
3.1.3. Using TLS with SIP Instead of SIPS ..................4
3.1.4. Usage of the transport=tls URI Parameter and
the TLS Via Parameter ...............................5
3.2. Detection of Hop-by-Hop Security ...........................6
3.3. The Problems with the Meaning of SIPS in RFC 3261 ..........7
4. Overview of Operations ..........................................9
4.1. Routing ...................................................11
5. Normative Requirements .........................................13
5.1. General User Agent Behavior ...............................13
5.1.1. UAC Behavior .......................................13
5.1.1.1. Registration ..............................14
5.1.1.2. SIPS in a Dialog ..........................15
5.1.1.3. Derived Dialogs and Transactions ..........15
5.1.1.4. GRUU ......................................16
5.1.2. UAS Behavior .......................................17
5.2. Registrar Behavior ........................................18
5.2.1. GRUU ...............................................18
5.3. Proxy Behavior ............................................18
5.4. Redirect Server Behavior ..................................20
6. Call Flows .....................................................21
6.1. Bob Registers His Contacts ................................22
6.2. Alice Calls Bob's SIPS AOR ................................27
6.3. Alice Calls Bob's SIP AOR Using TCP .......................36
6.4. Alice Calls Bob's SIP AOR Using TLS .......................50
7. Further Considerations .........................................51
8. Security Considerations ........................................52
9. IANA Considerations ............................................52
10. Acknowledgments ...............................................52
11. References ....................................................53
11.1. Normative References .....................................53
11.2. Informative References ...................................53
Appendix A. Bug Fixes for RFC 3261 ..............................551. Introduction 💖
Okay so the meaning and usage of the SIPS URI scheme and of Transport Layer Security (TLS) [RFC5246] are underspecified in SIP [RFC3261], and honestly that has been a total source of confusion for implementers 😭
This document gives clarifications and guidelines about using the SIPS URI scheme in the Session Initiation Protocol (SIP). It also makes normative changes to SIP (including both [RFC3261] and [RFC3608]. 🔥
2. Terminology 🌈
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 [RFC2119]. The capitalized words are the ones that carry the rules, so read them carefully 🎀
3. Background 🧚
3.1. Models for Using TLS in SIP 🦋
This section briefly describes how TLS gets used in SIP ✨
3.1.1. Server-Provided Certificate 💅
Okay, so in this model only the TLS server provides a certificate during the TLS handshake. This is only applicable between a user agent (UA) and a proxy, where the UA is the TLS client and the proxy is the TLS server. The UA uses TLS to authenticate the proxy, but the proxy does not use TLS to authenticate the UA. If the proxy needs to authenticate the UA, that can be done with SIP HTTP digest authentication 🫶
This directionality means the TLS connection always needs to be set up by the UA (for example, during the registration phase). SIP allows requests in both directions (like an incoming call), so the UA is expected to keep the TLS connection alive, and that connection is expected to be reused for both incoming and outgoing requests. It's giving reliability 💜
This solution, where the UA always initiates and keeps the connection alive, also solves the Network Address Translation (NAT) and firewall problem. It makes sure that responses and further requests will always be deliverable on the existing connection 🌸
[RFC5626] provides the mechanism for initiating and maintaining outbound connections in a standard, interoperable way ✨
3.1.2. Mutual Authentication 🔥
In this model, both the TLS client and the TLS server provide a certificate in the TLS handshake phase. When used between a UA and a proxy (or between two UAs), this implies that a UA is in possession of a certificate. When sending a SIP request and there is not already a suitable TLS connection in place, a user agent client (UAC) takes on the role of TLS client in establishing a new TLS connection. When establishing a TLS connection for receipt of a SIP request, a user agent server (UAS) takes on the role of TLS server. Because in SIP a UA or a proxy acts as both UAC and UAS depending on whether it is sending or receiving requests, the symmetrical nature of mutual TLS is super convenient. This allows TLS connections to be set up or torn down at will, and it does not rely on keeping the TLS connection alive for further requests 👑
However, there are some significant limitations 🙈
The first obvious limitation is not with mutual authentication per se, but with the model where the underlying TCP connection can be established by either side, interchangeably, which is not possible in many environments. For example, NATs and firewalls will often allow TCP connections to be established in one direction only. This includes most residential SIP deployments, for example. Mutual authentication can be used in those environments, but only if the connection is always started by the same side, for example, by using [RFC5626] as described in Section 3.1.1. Having to rely on [RFC5626] in this case negates many of the advantages of mutual authentication 😭
The second significant limitation is that mutual authentication requires both sides to exchange a certificate. This has proven to be impractical in many environments, in particular for SIP UAs, because of the difficulties of setting up a certificate infrastructure for a wide population of users 💀
For these reasons, mutual authentication is mostly used in server-to-server communications (for example, between SIP proxies, or between proxies and gateways or media servers), and in environments where using certificates on both sides is possible (for example, high-security devices used within an enterprise) 🍓
3.1.3. Using TLS with SIP Instead of SIPS 🦋
Because a SIPS URI implies that requests sent to the resource identified by it be sent over each SIP hop over TLS, SIPS URIs are not suitable for "best-effort TLS." They are only suitable for "TLS-only" requests. This is recognized in Section 26.2.2 of [RFC3261] ✨
Users that distribute a SIPS URI as an address-of-record may elect to operate devices that refuse requests over insecure transports.
If you want to use "best-effort TLS" for SIP, you just need to use a SIP URI and send the request over TLS 🌈
Using SIP over TLS is very simple. A UA opens a TLS connection and uses SIP URIs instead of SIPS URIs for all the header fields in a SIP message (From, To, Request-URI, Contact header field, Route, etc.). When TLS is used, the Via header field indicates TLS 🎀
[RFC3261], Section 26.3.2.1, states:
When a UA comes online and registers with its local administrative domain, it SHOULD establish a TLS connection with its registrar (...). Once the registration has been accepted by the registrar, the UA SHOULD leave this TLS connection open provided that the registrar also acts as the proxy server to which requests are sent for users in this administrative domain. The existing TLS connection will be reused to deliver incoming requests to the UA that had just completed registration.
[RFC5626] describes how to establish and maintain a TLS connection in environments where it can only be initiated by the UA 🫶
Proxies work similarly: they can forward requests using TLS if they can open a TLS connection, even if the route set used SIP URIs instead of SIPS URIs. Proxies can insert Record-Route header fields using SIP URIs even if they use TLS transport. [RFC3261], Section 26.3.2.2, explains how interdomain requests can use TLS 💜
Some user agents, redirect servers, and proxies might have local policies that enforce TLS on all connections, independently of whether or not SIPS is used 🧚
3.1.4. Usage of the transport=tls URI Parameter and the TLS Via Parameter ✨
Okay, bestie, so [RFC3261], Section 26.2.2 deprecated the "transport=tls" URI transport parameter in SIPS or SIP URIs 💅:
Note that in the SIPS URI scheme, transport is independent of TLS, and thus "sips:alice@atlanta.com;transport=TCP" and "sips:alice@atlanta.com;transport=sctp" are both valid (although note that UDP is not a valid transport for SIPS). The use of "transport=tls" has consequently been deprecated, partly because it was specific to a single hop of the request. This is a change since RFC 2543.
The "tls" parameter is still hanging out in the ABNF in [RFC3261], Section 25, even though the parameter got deprecated 🥹. It stays there for backward compatibility, so parsers can still process the parameter correctly. The transport=tls parameter was never actually defined in an RFC. It only showed up in some of the Internet drafts between [RFC2543] and [RFC3261] 🧚.
This specification does not make use of the transport=tls parameter 🙅♀️.
Bringing back the transport=tls parameter, or coming up with some other way to indicate TLS on a single hop in a URI, is outside the scope of this specification. That's a whole different glow-up 🌸.
For Via header fields, the following transport protocols are defined in [RFC3261]: "UDP", "TCP", "TLS", "SCTP", and in [RFC4168]: "TLS-SCTP" 🫶.
3.2. Detection of Hop-by-Hop Security 🔍
Here's the tea 🍵: the presence of a SIPS Request-URI does not necessarily mean the request was sent securely on each hop. So how does a UAS know if SIPS was used for the entire request path, keeping things end-to-end secure? Effectively, the UAS cannot know for sure 😭. However, [RFC3261], Section 26.4.4, recommends how a UAS can make some checks to validate the security. Also, the History-Info header field [RFC4244] could be inspected for detecting retargeting from SIP and SIPS. Retargeting from SIP to SIPS by a proxy is an issue because it can leave the receiver of the request with the impression that the request was delivered securely on each hop, while in fact, it was not. Big yikes 💀.
To emphasize, all the checking can be circumvented by any proxies or back-to-back user agents (B2BUAs) on the path that do not follow the rules and recommendations of this specification and of [RFC3261] 🚫.
Proxies can have their own policies regarding routing of requests to SIP or SIPS URIs. For example, some proxies in some environments can be configured to only route SIPS URIs 🔒. Some proxies can be configured to detect non-compliances and reject unsecure requests. For example, proxies could inspect Request-URIs, Path, Record-Route, To, From, Contact header fields, and Via header fields to enforce SIPS 👑.
[RFC3261], Section 26.4.4, explains that S/MIME can also be used by the originating UAC to ensure that the original form of the To header field is carried end-to-end. While not specifically mentioned in [RFC3261], Section 26.4.4, this is meant to imply that [RFC3893] would be used to "tunnel" important header fields (such as To and From) in an encrypted and signed S/MIME body, replicating the information in the SIP message, and allowing the UAS to validate the content of those important header fields. While this approach is certainly legal, a preferable approach is to use the SIP Identity mechanism defined in [RFC4474] 💖. SIP Identity creates a signed identity digest, which includes, among other things, the Address of Record (AOR) of the sender (from the From header field) and the AOR of the original target (from the To header field) ✨.
3.3. The Problems with the Meaning of SIPS in RFC 3261 🎀
Okay, so [RFC3261], Section 19.1, describes a SIPS URI like this:
A SIPS URI specifies that the resource be contacted securely. This means, in particular, that TLS is to be used between the UAC and the domain that owns the URI. From there, secure communications are used to reach the user, where the specific security mechanism depends on the policy of the domain.
Section 26.2.2 says it again, but specifically for Request-URIs:
When used as the Request-URI of a request, the SIPS scheme signifies that each hop over which the request is forwarded, until the request reaches the SIP entity responsible for the domain portion of the Request-URI, must be secured with TLS; once it reaches the domain in question it is handled in accordance with local security and routing policy, quite possibly using TLS for any last hop to a UAS. When used by the originator of a request (as would be the case if they employed a SIPS URI as the address- of-record of the target), SIPS dictates that the entire request path to the target domain be so secured.
To explain what a sips:b@B URI really means, let's look at the classic SIP trapezoid 🦋. Instead of real domain names like example.com and example.net, we're using logical names like "A" and "B" so it's easier to follow 🧚.
.......................... ...........................
. . . .
. +-------+ . . +-------+ .
. | | . . | | .
. | Proxy |-----TLS---- | Proxy | .
. | A | . . | B | .
. | | . . | | .
. / +-------+ . . +-------+ \ .
. / . . \ .
. / . . \ .
. TLS . . Policy-based .
. / . . \ .
. / . . \ .
. / . . \ .
. +-------+ . . +-------+ .
. | | . . | | .
. | UAC a | . . | UAS b | .
. | | . . | | .
. +-------+ . . +-------+ .
. Domain A . . Domain B .
.......................... ...........................
SIP trapezoid with last-hop exceptionAccording to [RFC3261], if a@A is sending a request to sips:b@B, the following applies:
- TLS is required between UA a@A and Proxy A
- TLS is required between Proxy A and Proxy B
- TLS is required between Proxy B and UA b@B, depending on local policy
So you might be wondering: why is TLS mandatory between UA a@A and Proxy A, but not between Proxy B and UA b@B? 🤔 The main reason is that [RFC3261] was written before [RFC5626]. Back then, people realized that in lots of real deployments, Proxy B might not be able to set up a TLS connection with UA b, because only Proxy B would have a certificate to provide and UA b wouldn't. Since UA b would be the TLS server, it wouldn't be able to accept the incoming TLS connection. The consequence is that an [RFC3261]-compliant UAS b, while it might not need to support TLS for incoming requests, will nevertheless have to support TLS for outgoing requests as it takes the UAC role 🫠. Contrary to what many believed erroneously, the last-hop exception was not created to allow for using a SIPS URI to address a UAS that does not support TLS. The last-hop exception was an attempt to allow for incoming requests to not be transported over TLS when a SIPS URI is used, and it does not apply to outgoing requests. The rationale for this was somewhat flawed, and since then, [RFC5626] has provided a more satisfactory solution to this problem 🌈. [RFC5626] also solves the problem that if UA b is behind a NAT or firewall, Proxy B would not even be able to establish a TCP session in the first place.
Furthermore, let's think about the problem of using SIPS inside a dialog 🍓. If a@A sends a request to b@B using a SIPS Request-URI, then, according to [RFC3261], Section 8.1.1.8, "the Contact header field MUST contain a SIPS URI as well". This means that b@B, upon sending a new Request within the dialog (e.g., a BYE or re-INVITE), will have to use a SIPS URI. If there is no Record-Route entry, or if the last Record-Route entry consists of a SIPS URI, this implies that b@B is expected to understand SIPS in the first place, and is required to also support TLS. If the last Record-Route entry however is a sip URI, then b would be able to send requests without using TLS (but b would still have to be able to handle SIPS schemes when parsing the message). In either case, the Request-URI in the request from b@B to B would be a SIPS URI 💜.
4. Overview of Operations ✨
Okay bestie, so because of all the problems we just went over in Section 3.3, this spec deprecates the last-hop exception when a request gets forwarded to the last hop (see Section 5.3). That means TLS gets used on every single hop, all the way up to the remote target. 🔒💖
.......................... ...........................
. . . .
. +-------+ . . +-------+ .
. | | . . | | .
. | Proxy |-----TLS---- | Proxy | .
. | A | . . | B | .
. | | . . | | .
. / +-------+ . . +-------+ \ .
. / . . \ .
. / . . \ .
. TLS . . TLS .
. / . . \ .
. / . . \ .
. / . . \ .
. +-------+ . . +-------+ .
. | | . . | | .
. | UAC a | . . | UAS b | .
. | | . . | | .
. +-------+ . . +-------+ .
. Domain A . . Domain B .
.......................... ...........................
SIP trapezoid without last-hop exceptionReal talk, the SIPS scheme kinda implies transitive trust 👀. Obviously proxies can still cheat (see [RFC3261], Section 26.4.4), so SIPS is great for asking that a resource gets contacted securely, but it is NOT proof that it actually was. So you can't just assume that a request with a SIPS URI in its Request-URI (or even its To header field) was really sent over TLS on each hop. 🙅♀️
Some people have been tempted to think SIPS works like HTTPS, where you show a little padlock icon in the UI to say the session is secure. Iykyk, that's not the case at all 💀, so the meaning of a SIPS URI should not be oversold. Right now SIP has no mechanism that shows end-to-end security. Other mechanisms can give a more concrete indication of some level of security, though. For example, SIP Identity [RFC4474] provides an authenticated identity mechanism and a domain-to-domain integrity protection mechanism 🧚.
Now, the big question everyone asks: why is SIPS even useful on the open Internet if, when it's used in a Request-URI, it isn't an absolute guarantee that the request gets delivered over TLS on each hop? Why is SIPS any different from just running SIP over TLS transport? 🤔 The difference is this: a SIPS URI in a Request-URI means that if you're telling the network to use TLS on each hop, and it's not possible to reject the request, you would rather have the request fail than get delivered without TLS. Using TLS with a SIP Request-URI instead of a SIPS Request-URI is more of a "best-effort" service. The request can be delivered over TLS on each hop, but it doesn't have to be 🫶.
Another common question is why not just use a Proxy-Require and Require option tag to force TLS instead. The answer is that it would only be functionally equivalent to using SIPS in a Request-URI. SIPS URIs, however, can be used in many other header fields: in Contact for registration, Contact in dialog-creating requests, Route, Record-Route, Path, From, To, Refer-To, Referred-By, etc. They can also be used in human-usable formats (like business cards or user interfaces), and even in other protocols or document formats that allow for including SIPS URIs (e.g., HTML) ✨🎀.
This document specifies that SIPS means the SIP resource designated by the target SIPS URI is to be contacted securely, using TLS on each hop between the UAC and the remote UAS. That's different from only using TLS to the proxy responsible for the target domain of the Request-URI. It is outside the scope of this document to specify what happens when a SIPS URI identifies a UAS resource that "maps" outside the SIP network, for example, to other networks such as the Public Switched Telephone Network (PSTN) 📞.
4.1. Routing
SIP and SIPS URIs that are identical except for the scheme itself (e.g., sip:alice@example.com and sips:alice@example.com) refer to the same resource 💅. This requirement is implicit in [RFC3261], Section 19.1, which states that "any resource described by a SIP URI can be 'upgraded' to a SIPS URI by just changing the scheme, if it is desired to communicate with that resource securely". Doesn't mean the SIPS URI will necessarily be reachable, especially if the proxy can't establish a secure connection to a client or another proxy 😬. It also doesn't mean proxies would arbitrarily "upgrade" SIP URIs to SIPS URIs when forwarding a request (see Section 5.3). What it does mean is that when a resource is addressable with SIP, it's also addressable with SIPS. Main character energy for both schemes 👑.
Here's an example. Say a UA has registered with a SIPS Contact header field, and then a UAC addresses a request using a SIP Request-URI. The proxy forwards that request to the UAS, as illustrated by message F13 in Sections 6.3 and 6.4. The proxy forwards it to the UA using a SIP Request-URI, not the SIPS Request-URI from registration. It does this by replacing the SIPS scheme in the registered Contact header field binding with a SIP scheme, leaving the rest of the URI as is, and then using that new URI as the Request-URI. If the proxy didn't do this, and used a SIPS Request-URI instead, then the response (e.g., a 200 to an INVITE) would have to include a SIPS Contact header field. That SIPS Contact header field would then force the other UA to use a SIPS Contact header field in any mid-dialog request, including the ACK. That wouldn't work if that UA didn't support SIPS, so yeah, it's a whole mess 🙈.
This specification mandates that when a proxy is forwarding a request, a resource described by a SIPS Request-URI cannot be "downgraded" to a SIP URI by changing the scheme, or by sending the associated request over a nonsecure link. If a request would otherwise be a "downgrade" and needs to be rejected, it gets rejected with a 480 (Temporarily Unavailable) response, potentially with a Warning header carrying warn-code 380 "SIPS Not Allowed". Similarly, when a proxy is forwarding a request, a resource described by a SIP Request-URI cannot be "upgraded" to a SIPS URI by changing the scheme. Otherwise it would only be an "upgrade" for that hop onwards rather than on all hops, and would therefore mislead the UAS. If a request would be a misleading "upgrade" and needs to be rejected, it gets rejected with a 480 (Temporarily Unavailable) response, potentially with a Warning header field carrying warn-code 381 "SIPS Required". See Section 5.3 for more details.
Quick aside: "downgrade" and "upgrade" here are about the scheme changing while the request is being forwarded. Read Section 5.3 before you build anything with this 🧠.
For example, the sip:bob@example.com and sips:bob@example.com AORs refer to the same user "Bob" in the domain "example.com". The first URI is the SIP version and the second is the SIPS version. From a routing point of view, requests to either sip:bob@example.com or sips:bob@example.com are treated the same way. So when Bob registers, it doesn't really matter whether he uses a SIP or a SIPS AOR, because both refer to the same user 🦋. At first glance, Section 19.1.4 of [RFC3261] seems to contradict this idea, since it says a SIP and a SIPS URI are never equivalent. Specifically, it says they are never equivalent for the purpose of comparing bindings in Contact header field URIs in REGISTER requests. The key point is that this statement applies to the Contact header field bindings in a registration. It's the association of the Contact header field with the AOR that determines whether or not the user is reachable with a SIPS URI ✨.
Let's make it concrete. If Bob (AOR bob@example.com) registers with a SIPS Contact header field (e.g., sips:bob@bobphone.example.com), then the registrar and the location service know that Bob is reachable at sips:bob@bobphone.example.com and at sip:bob@bobphone.example.com.
If a request is sent to AOR sips:bob@example.com, Bob's proxy routes it to Bob at Request-URI sips:bob@bobphone.example.com. If a request is sent to AOR sip:bob@example.com, Bob's proxy routes it to Bob at Request-URI sip:bob@bobphone.example.com.
If Bob wants to make sure every request delivered to him is always transported over TLS, he can use [RFC5626] when registering 🔐.
But if Bob had registered with a SIP Contact header field instead of a SIPS one (e.g., sip:bob@bobphone.example.com), then a request to AOR sips:bob@example.com would not be routed to Bob. There's no SIPS Contact header field for Bob, and "downgrades" from SIPS to SIP aren't allowed 🚫.
See Section 6 for illustrative call flows 🌸.
5. Normative Requirements 🧾
This section is where all the normative requirements defined by this specification live, so it's the big one for implementers 🫶.
5.1. General User Agent Behavior
5.1.1. UAC Behavior ✨
Okay bestie, when a UAC is presented with a SIPS URI, it MUST NOT change it to a SIP URI 🙅♀️ So if a directory entry has a SIPS AOR, the UAC is not expected to send requests to that AOR with a SIP Request-URI. And if someone hands you a business card with a SIPS URI, you can't infer a SIP URI from it 💀 If a 3XX response includes a SIPS Contact header field, the UAC doesn't swap it for a SIP Request-URI (like by changing the SIPS scheme to a SIP one) when it sends the request that comes from the redirect 🦋
[RFC3261] says this too, in Section 8.1.1.8: in a request, "if the Request-URI or top Route header field value contains a SIPS URI, the Contact header field MUST contain a SIPS URI as well" 🔒
Now the big one 😤 If a UAC gets a 416 response, or a 480 (Temporarily Unavailable) response with a Warning header carrying warn-code 380 and the text "SIPS Not Allowed", it MUST NOT retry the request by automatically swapping the SIPS scheme for a SIP one, as described in [RFC3261], Section 8.1.3.5. That would be a security vulnerability, no cap 🚨 If the UAC does retry the call with a SIP URI anyway, it SHOULD get a confirmation from the user first, to authorize restarting the session with a SIP Request-URI instead of a SIPS Request-URI ✨
When the route set isn't empty (for example, when the registrar returns a service route [RFC3608]), it's on the UAC to use a Route header field made entirely of SIPS URIs whenever it uses a SIPS Request-URI 💅 Specifically, if the route set has any SIP URI in it, the UAC MUST change those SIP URIs to SIPS URIs by only changing the scheme from "sip" to "sips" before sending the request. This is so you can set up or discover one service route full of SIP URIs and still send requests to both SIP and SIPS URIs, which is honestly iconic 🌈
When the UAC is using a SIP Request-URI and the route set isn't empty, if the topmost Route header field entry is a SIPS URI with the lr parameter, the UAC MUST send the request over TLS (still with a SIP Request-URI) 🔐 If the route isn't empty and the Route header field entry is a SIPS URI without the lr parameter, the UAC MUST send the request over TLS using a SIPS Request-URI that matches the topmost entry in the route set 🫶
To emphasize what [RFC3261] already defines, UAs MUST NOT use the "transport=tls" parameter. Main character energy is not using it 💜
5.1.1.1. Registration 📇
The UAC registers Contact header fields to either a SIPS or a SIP AOR, babe 🎀
If a UA wants to be reachable with a SIPS URI, the UA MUST register with a SIPS Contact header field. Requests addressed to that UA's AOR using either a SIP or a SIPS Request-URI will get routed to that UA, and that includes UAs that support both SIP and SIPS 🦋 This spec doesn't give you any SIP-based mechanism for a UA to tell its proxy to only forward requests using a SIPS Request-URI. A non-SIP mechanism, like a web interface, could be used to set that preference. A SIP mechanism for provisioning that preference is outside the scope of this specification 🙈
If a UA does NOT want to be reached with a SIPS URI, it MUST register with a SIP Contact header field 🙅♀️ Wait, correction: the UA doesn't wish to be reached with SIPS, so it MUST register with a SIP Contact header field. Got it 💖
Because registering with a SIPS Contact header field implies binding both a SIPS Contact and a matching SIP Contact to the AOR, a UA MUST NOT include both the SIPS and SIP versions of the same Contact header field in a REGISTER request. It MUST only use the SIPS version in that case 🔐 It's also a SIP-free zone: a UA SHOULD NOT register both a SIP Contact header field and a SIPS Contact header field in separate registrations, because the SIP one would be superfluous 🥱 If it does anyway, the second registration replaces the first. For example, a UA could register first with a SIP Contact header field (meaning it doesn't support SIPS) and later register with a SIPS Contact header field (meaning it now does). And the reverse holds too: if a UA registers first with a SIPS Contact header field and later registers with a SIP Contact header field, the SIP one replaces the SIPS one 🔄
[RFC5626] can be used by a UA that wants to make sure no requests get delivered to it without going through the TLS connection it used when registering 🔒
If every Contact header field in a REGISTER request is SIPS, the UAC MUST use SIPS AORs in the From and To header fields of the REGISTER request. If at least one Contact header field is not SIPS (for example, sip, mailto, tel, http, https), the UAC MUST use SIP AORs in the From and To header fields of the REGISTER request 📋
To emphasize what [RFC3261] already defines, UACs MUST NOT use the "transport=tls" parameter. Again, we are not using it, period 💅
5.1.1.2. SIPS in a Dialog 💬
If the Request-URI in a request that starts a dialog is a SIP URI, the UAC needs to be careful about what goes in the Contact header field (in case Record-Route isn't used for this hop) 👀 If the Contact header field were a SIPS URI, the UAS would only accept mid-dialog requests sent over a secure transport on every hop. Since the Request-URI here is a SIP URI, the UA sending to it might not be able to send requests to SIPS URIs at all 🙃 So if the top Route header field doesn't contain a SIPS URI, the UAC MUST use a SIP URI in the Contact header field, even when the request goes over a secure transport. The first hop could, for example, be reusing a TLS connection to the proxy, as would happen with [RFC5626] 🔁
When a target refresh happens within a dialog (like a re-INVITE request or an UPDATE request), the UAC MUST include a Contact header field with a SIPS URI if the original request used a SIPS Request-URI 🫶
5.1.1.3. Derived Dialogs and Transactions 🧬
Sessions, dialogs, and transactions can be "derived" from existing ones. A really good example of a derived dialog is one set up because of a REFER request [RFC3515] 📞
As a general rule, derived dialogs and transactions cannot effectively downgrade SIPS to SIP without explicit authorization from the entities involved. That's the golden rule 👑
For example, when a REFER request is used to do a call transfer, an existing dialog gets terminated and another one is created based on the Refer-To URI. If that original dialog was set up using SIPS, the UAC MUST NOT establish a new one using SIP, unless the recipient of the REFER request has explicitly authorized it. That authorization could be a warning shown to the user. Such a warning could be really useful for, say, a secure directory service application, to tell a user that a request might get routed to a UA that doesn't support SIPS 🚨
A REFER request can also be used to refer to resources that don't create dialogs. In fact, a REFER request can point to resources of a different type than the original one (meaning, not SIP or SIPS). For security considerations related to this, please see [RFC3515], Section 5.2 📖
Other examples of derived dialogs and transactions include Third-Party Call Control [RFC3725], the Replaces header field [RFC3891], and the Join header field [RFC3911]. Again, the general principle is that these mechanisms SHOULD NOT result in an effective downgrading of SIPS to SIP without proper authorization 🙅♀️
5.1.1.4. GRUU 🎟️
When a Globally Routable User Agent URI (GRUU) [RFC5627] is assigned to an instance ID/AOR pair, both SIP and SIPS GRUUs get assigned. When you get a GRUU through registration, if the Contact header field in the REGISTER request has a SIP URI, you get the SIP version of the GRUU back. If it has a SIPS URI, you get the SIPS version back 🌸
If the wrong scheme shows up in the GRUU (which would be an error on the registrar's end), the UAC SHOULD treat it as if the proper scheme had been used. In other words, it SHOULD replace the scheme with the proper one before using the GRUU 🩹
5.1.2. UAS Behavior 🛎️
When a UAS is presented with a SIPS URI, it MUST NOT change it to a SIP URI 🙅♀️
As [RFC3261], Section 12.1.1 mandates:
If the request that initiated the dialog contained a SIPS URI in the Request-URI or in the top Record-Route header field value, if there was any, or the Contact header field if there was no Record-Route header field, the Contact header field in the response MUST be a SIPS URI.
If a UAS doesn't want to be reached with a SIPS URI but only with a SIP URI, the UAS MUST respond with a 480 (Temporarily Unavailable) response. The UAS SHOULD include a Warning header with warn-code 380 and "SIPS Not Allowed". [RFC3261], Section 8.2.2.1, says that UASs that don't support the SIPS URI scheme at all "SHOULD reject the request with a 416 (Unsupported URI scheme) response" 🙃
If a UAS doesn't want to be contacted with a SIP URI but only with a SIPS URI, it MUST reject a request to a SIP Request-URI with a 480 (Temporarily Unavailable) response. The UAS SHOULD include a Warning header with warn-code 381 and "SIPS Required" 🔐
It's a matter of local policy for a UAS to accept incoming requests addressed to a URI scheme that doesn't match what it used for registration 🧠 For example, a UA with an "always SIPS" policy would talk to the registrar using a SIPS Request-URI over TLS and register with a SIPS Contact header field. Its UAS would reject SIP-scheme requests with a 480 (Temporarily Unavailable) response and a Warning header with warn-code 381 and "SIPS Required" 🛡️ A UA with a "best-effort SIPS" policy would talk to the registrar using a SIPS Request-URI over TLS and register with a SIPS Contact header field, and its UAS would accept requests addressed to either a SIP or a SIPS Request-URI 🤝 A UA with a "No SIPS" policy would talk to the registrar using a SIP Request-URI (TLS or not), register with a SIP AOR and a SIP Contact header field, and its UAS would accept requests addressed to a SIP Request-URI 🌷
If a UAS has to reject a request because the URIs are used inconsistently (for example, the Request-URI is a SIPS URI but the Contact header field is a SIP URI), the UAS MUST reject the request with a 400 (Bad Request) response 🚫
When a target refresh happens within a dialog (like a re-INVITE request or an UPDATE request), the UAS MUST include a Contact header field with a SIPS URI if the original request used a SIPS Request-URI 💖
To emphasize what [RFC3261] already defines, UASs MUST NOT use the "transport=tls" parameter. Period, end of story, slay 💅✨
5.2. Registrar Behavior 📇
Okay so, the UAC registers Contacts header fields to either a SIPS or a SIP AOR 💅 From a routing perspective it does not matter which one you pick, because they identify the same resource 🫶 The registrar MUST consider AORs that are identical except for one having the SIP scheme and the other having the SIPS scheme to be equivalent 🦋
A registrar MUST accept a binding to a SIPS Contact header field only if all the appropriate URIs are of the SIPS scheme, bestie 🔒 Otherwise a secure resource (SIPS) could get inadvertently bound to an unsecured one (SIP), and that is NOT the vibe 😭 This covers the Request-URI, the Contacts, and all the Path header fields, but it does not include the From and To header fields ✨ If the URIs are not of the proper SIPS scheme, the registrar MUST reject the REGISTER with a 400 (Bad Request) 💀
A registrar can return a service route [RFC3608] and impose some constraints on whether or not TLS will be mandatory on specific hops 🎀 For example, if the topmost entry in the Path header field returned by the registrar is a SIPS URI, the registrar is basically telling the UAC that TLS is to be used for the first hop, even if the Request-URI is SIP 🧚
If a UA registered with a SIPS Contact header field, the registrar returning a service route [RFC3608] MUST return a service route consisting of SIP URIs if the intent of the registrar is to allow both SIP and SIPS to be used in requests sent by that client 🌈 If a UA registers with a SIPS Contact header field, the registrar returning a service route MUST return a service route consisting of SIPS URIs if the intent of the registrar is to allow only SIPS URIs to be used in requests sent by that UA 👑
5.2.1. GRUU 🌸
When a GRUU [RFC5627] is assigned to an instance ID/AOR pair through registration, the registrar MUST assign both a SIP GRUU and a SIPS GRUU 🍓 If the Contact header field in the REGISTER request contains a SIP URI, the registrar MUST return the SIP version of the GRUU 💜 If the Contact header field in the REGISTER request contains a SIPS URI, the registrar MUST return the SIPS version of the GRUU 🔥
5.3. Proxy Behavior 🌷
Proxies MUST NOT use the last-hop exception of [RFC3261] when forwarding or retargeting a request to the last hop, and this is a big one 🙈 Specifically, when a proxy receives a request with a SIPS Request-URI, the proxy MUST only forward or retarget the request to a SIPS Request-URI 🔐 If the target UAS had registered previously using a SIP Contact header field instead of a SIPS Contact header field, the proxy MUST NOT forward the request to the URI indicated in the Contact header field 🚫 If the proxy needs to reject the request for that reason, the proxy MUST reject it with a 480 (Temporarily Unavailable) response 🥲 In this case, the proxy SHOULD include a Warning header with warn-code 380 "SIPS Not Allowed" 💌
Proxies SHOULD transport requests using a SIP URI over TLS when it is possible to set up a TLS connection, or reuse an existing one 🦋 [RFC5626], for example, allows for re-using an existing TLS connection ✨ Some proxies could have policies that prohibit sending any request over anything but TLS, so keep that in mind 🫠
When a proxy receives a request with a SIP Request-URI, the proxy MUST NOT forward the request to a SIPS Request-URI 🙅♀️ If the target UAS had registered previously using a SIPS Contact header field, and the proxy decides to forward the request, the proxy MUST replace that SIPS scheme with a SIP scheme while leaving the rest of the URI as is, and use the resulting URI as the Request-URI of the forwarded request 🪄 The proxy MUST use TLS to forward the request to the UAS 🔒 Some proxies could have a policy of not forwarding at all requests using a non-SIPS Request-URI if the UAS had registered using a SIPS Contact header field 🧱 If the proxy elects to reject the request because it has such a policy or because it is not capable of establishing a TLS connection, the proxy MAY reject it with a 480 (Temporarily Unavailable) response with a Warning header with warn-code 381 "SIPS Required" 🍬
If a proxy needs to reject a request because the URIs are used inconsistently (e.g., the Request-URI is a SIPS URI, but the Contact header field is a SIP URI), the proxy SHOULD use response code 400 (Bad Request) 🙃
It is RECOMMENDED that the proxy use the outbound proxy procedures defined in [RFC5626] for supporting UACs that cannot provide a certificate for establishing a TLS connection (i.e., when server-side authentication is used) 🧸
When a proxy sends a request using a SIPS Request-URI and receives a 3XX response with a SIP Contact header field, or a 416 response, or a 480 (Temporarily Unavailable) response with a Warning header with warn-code 380 "SIPS Not Allowed" response, the proxy MUST NOT recurse on the response 🛑 In this case, the proxy SHOULD forward the best response instead of recursing, so the UAC can take the appropriate action 🎯
When a proxy sends a request using a SIP Request-URI and receives a 3XX response with a SIPS Contact header field, or a 480 (Temporarily Unavailable) response with a Warning header with warn-code 381 "SIPS Required", the proxy MUST NOT recurse on the response 🙃 In this case, the proxy SHOULD forward the best response instead of recursing, so the UAC can take the appropriate action 💅
To emphasize what is already defined in [RFC3261], proxies MUST NOT use the "transport=tls" parameter 📣
5.4. Redirect Server Behavior 🦢
Using a redirect server with TLS instead of using a proxy has some limitations that you have to take into account 🥺 Since there is no pre-established connection between the proxy and the UAS (such as with [RFC5626]), it is only appropriate for scenarios where inbound connections are allowed 🚪 For example, it could be used in a server-to-server environment (redirect server or proxy server) where TLS mutual authentication is used, and where there are no NAT traversal issues 🤝 A redirect server would not be able to redirect to an entity that does not have a certificate 📜 A redirect server might not be usable if there is a NAT between the server and the UAS 🌵
When a redirect server receives a request with a SIP Request-URI, the redirect server MAY redirect with a 3XX response to either a SIP or a SIPS Contact header field 🍭 If the target UAS had registered previously using a SIPS Contact header field, the redirect server SHOULD return a SIPS Contact header field if it is in an environment where TLS is usable (as described in the previous paragraph) 🔐 If the target UAS had registered previously using a SIP Contact header field, the redirect server MUST return a SIP Contact header field in a 3XX response if it redirects the request 🫶
When a redirect server receives a request with a SIPS Request-URI, the redirect server MAY redirect with a 3XX response to a SIP or a SIPS Contact header field 🌟 If the target UAS had registered previously using a SIPS Contact header field, the redirect server SHOULD return a SIPS Contact header field if it is in an environment where TLS is usable 🔒 If the target UAS had registered previously using a SIP Contact header field, the redirect server MUST return a SIP Contact header field in a 3XX response if it chooses to redirect; otherwise, the UAS MAY reject the request with a 480 (Temporarily Unavailable) response with a Warning header with warn-code 380 "SIPS Not Allowed" 😤 If a redirect server redirects to a UAS that it has no knowledge of (e.g., an AOR in a different domain), the Contact header field could be of any scheme 🌍
If a redirect server needs to reject a request because the URIs are used inconsistently (e.g., the Request-URI is a SIPS URI, but the Contact header field is a SIP URI), the redirect server SHOULD use response code 400 (Bad Request) 🙃
To emphasize what is already defined in [RFC3261], redirect servers MUST NOT use the "transport=tls" parameter 📣
6. Call Flows 🎀
The following diagram illustrates the topology used for the examples in this section 🗺️
example.com . example.net
.
|-------------| . |------------|
| Registrar/ |__________| Proxy A |
| Auth. Proxy | . | (proxya) |
| (pb) | . |------------|
|-------------| . |
| . |
| . |
|-----------| . |
| Edge | . |
| Proxy B | . |
| (eb) | . |
|-----------| . |
/ | . |
/ | . |
/ | . |
______ | . |
| | _____ . _____
|______| O / \ O . O / \ O
/_______/ /___\ . /___\
.
bob@bobpc bob@bobphone . alice
TopologyIn the following examples, Bob has two clients 📱💻 One is a SIP PC client running on his computer, and the other one is a SIP phone 🤳 The PC client does not support SIPS, and consequently only registers with a SIP Contact header field 🥀 The SIP phone however does support SIPS and TLS, and consequently registers with a SIPS Contact header field 🔐 Both of Bob's devices are going through Edge Proxy B, and consequently, they include a Route header field indicating eb.example.com 🛣️ Edge Proxy B removes the Route header field corresponding to itself, and adds itself in a Path header field 🧚 The registration process call flow is illustrated in Section 6.1 📞
After registration, there are two Contact bindings associated with Bob's AOR of bob@example.com: sips:bob@bobphone.example.com and sip:bob@bobpc.example.com 🎉
Alice then calls Bob through her own Proxy A 💁♀️ Proxy A locates Bob's domain example.com 🔍 In this example, that domain is owned by Bob's Registrar/Authoritative Proxy B 🏰 Proxy A removes the Route header field corresponding to itself, and inserts itself in the Record-Route and forwards the request to Registrar/Authoritative Proxy B 🦋
The following subsections illustrate registration and three examples 🌈 In the first example (Section 6.2), Alice calls Bob's SIPS AOR 🔐 In the second example (Section 6.3), Alice calls Bob's SIP AOR using TCP transport 🧦 In the third example (Section 6.4), Alice calls Bob's SIP AOR using TLS transport 🔒✨
6.1. Bob Registers His Contacts ✨
okay so this flow is all about how Bob's devices get registered 📞💖 His PC client (Bob@bobpc) registers using a SIP scheme, and his SIP phone (Bob@phone) registers using a SIPS scheme 🔐
(eb) (pb)
Edge Registrar/
Bob@bobpc Proxy B Auth. Proxy B
| | |
| REGISTER F1 | |
|------------------>| REGISTER F2 |
| |-------------->|
| | 200 F3 |
| 200 F4 |<--------------|
|<------------------| |
| | |
| Bob@bobphone | |
| | | |
| |REGISTER F5 | |
| |----------->| REGISTER F6 |
| | |-------------->|
| | | 200 F7 |
| | 200 F8 |<--------------|
| |<-----------| |
| | | |Bob Registers His Contacts 🦋
Message details
F1 REGISTER Bob's PC Client -> Edge Proxy B
REGISTER sip:pb.example.com SIP/2.0
Via: SIP/2.0/TCP bobpc.example.com:5060;branch=z9hG4bKnashds
Max-Forwards: 70
To: Bob <sip:bob@example.com>
From: Bob <sip:bob@example.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Supported: path, outbound
Route: <sip:eb.example.com;lr>
Contact: <sip:bob@bobpc.example.com>
;+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>"
;reg-id=1
Content-Length: 0F2 REGISTER Edge Proxy B -> Registrar/Authoritative Proxy B
REGISTER sip:pb.example.com SIP/2.0
Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bK87asdks7
Via: SIP/2.0/TCP bobpc.example.com:5060;branch=z9hG4bKnashds
Max-Forwards: 69
To: Bob <sip:bob@example.com>
From: Bob <sip:bob@example.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Supported: path, outbound
Path: <sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;ob>
Contact: <sip:bob@bobpc.example.com>
;+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>"
;reg-id=1
Content-Length: 0F3 200 (REGISTER) Registrar/Authoritative Proxy B -> Edge Proxy B
SIP/2.0 200 OK
Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bK87asdks7
Via: SIP/2.0/TCP bobpc.example.com:5060;branch=z9hG4bKnashds
To: Bob <sip:bob@example.com>;tag=2493K59K9
From: Bob <sip:bob@example.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Require: outbound
Supported: path, outbound
Path: <sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;ob>
Contact: <sip:bob@bobphone.example.com>
;+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>"
;reg-id=1
;expires=3600
Date: Mon, 12 Jun 2006 16:43:12 GMT
Content-Length: 0F4 200 (REGISTER) Edge Proxy B -> Bob's PC Client
SIP/2.0 200 OK
Via: SIP/2.0/TCP bobpc.example.com:5060;branch=z9hG4bKnashds
To: Bob <sip:bob@example.com>;tag=2493K59K9
From: Bob <sip:bob@example.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Require: outbound
Supported: path, outbound
Path: <sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;ob>
Contact: <sip:bob@bobphone.example.com>
;+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>"
;reg-id=1
;expires=3600
Date: Thu, 09 Aug 2007 16:43:12 GMT
Content-Length: 0F5 REGISTER Bob's Phone -> Edge Proxy B
REGISTER sips:pb.example.com SIP/2.0
Via: SIP/2.0/TLS bobphone.example.com:5061;branch=z9hG4bK9555
Max-Forwards: 70
To: Bob <sips:bob@example.com>
From: Bob <sips:bob@example.com>;tag=90210
Call-ID: faif9a@qwefnwdclk
CSeq: 12 REGISTER
Supported: path, outbound
Route: <sips:eb.example.com;lr>
Contact: <sips:bob@bobphone.example.com>
;+sip.instance="<urn:uuid:6F85D4E3-E8AA-46AA-B768-BF39D5912143>"
;reg-id=1
Content-Length: 0F6 REGISTER Edge Proxy B -> Registrar/Authoritative Proxy B
REGISTER sips:pb.example.com SIP/2.0
Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bK876354
Via: SIP/2.0/TLS bobphone.example.com:5061;branch=z9hG4bK9555
Max-Forwards: 69
To: Bob <sips:bob@example.com>
From: Bob <sips:bob@example.com>;tag=90210
Call-ID: faif9a@qwefnwdclk
CSeq: 12 REGISTER
Supported: path, outbound
Path: <sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>
Contact: <sips:bob@bobphone.example.com>
;+sip.instance="<urn:uuid:6F85D4E3-E8AA-46AA-B768-BF39D5912143>"
;reg-id=1
Content-Length: 0F7 200 (REGISTER) Registrar/Authoritative Proxy B -> Edge Proxy B
SIP/2.0 200 OK
Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bK876354
Via: SIP/2.0/TLS bobphone.example.com:5061;branch=z9hG4bK9555
To: Bob <sips:bob@example.com>;tag=5150
From: Bob <sips:bob@example.com>;tag=90210
Call-ID: faif9a@qwefnwdclk
CSeq: 12 REGISTER
Require: outbound
Supported: path, outbound
Path: <sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>
Contact: <sips:bob@bobphone.example.com>
;+sip.instance="<urn:uuid:6F85D4E3-E8AA-46AA-B768-BF39D5912143>"
;reg-id=1
;expires=3600
Date: Thu, 09 Aug 2007 16:43:50 GMT
Content-Length: 0F8 200 (REGISTER) Edge Proxy B -> Bob's Phone
SIP/2.0 200 OK
Via: SIP/2.0/TLS bobphone.example.com:5061;branch=z9hG4bK9555
To: Bob <sips:bob@example.com>;tag=5150
From: Bob <sips:bob@example.com>;tag=90210
Call-ID: faif9a@qwefnwdclk
CSeq: 12 REGISTER
Require: outbound
Supported: path, outbound
Path: <sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>
Contact: <sips:bob@bobphone.example.com>
;+sip.instance="<urn:uuid:6F85D4E3-E8AA-46AA-B768-BF39D5912143>"
;reg-id=1
;expires=3600
Date: Thu, 09 Aug 2007 16:43:50 GMT
Content-Length: 06.2. Alice Calls Bob's SIPS AOR 📞🌸
Bob's registration has already happened, as covered in Section 6.1 💅
so in this first example, Alice calls Bob's SIPS AOR (sips:bob@example.com) 💌 Registrar/Authoritative Proxy B checks the binding in the registration database and finds the two Contact header field bindings ✨ Alice addressed Bob with a SIPS Request-URI (sips:bob@example.com), so Registrar/Authoritative Proxy B decides the call should only go to bobphone (the one that registered with a SIPS Contact header field) 📱 That means the request is only sent to sips:bob@bobphone.example.com, through Edge Proxy B 🚀 Both Registrar/Authoritative Proxy B and Edge Proxy B put themselves in the Record-Route 🛣️ and Bob answers at sips:bob@bobphone.example.com 🎀
(eb) (pb)
Edge Registrar/
Bob@bobpc Proxy B Auth. Proxy B Proxy A Alice
| | | | |
| | | | INVITE F9 |
| Bob@bobphone | | INVITE F11 |<-----------|
| | | INVITE F13 |<-----------| 100 F10 |
| | INVITE F15 |<-----------| 100 F12 |----------->|
| |<-----------| 100 F14 |----------->| |
| | 180 F16 |----------->| | |
| |----------->| 180 F17 | | |
| | 200 F20 |----------->| 180 F18 | |
| |----------->| 200 F21 |----------->| 180 F19 |
| | |----------->| 200 F22 |----------->|
| | | |----------->| 200 F23 |
| | | | |----------->|
| | | | | ACK F24 |
| | | | ACK F25 |<-----------|
| | | ACK F26 |<-----------| |
| | ACK F27 |<-----------| | |
| |<-----------| | | |
| | | | | |Alice Calls Bob's SIPS AOR 🦋
Message details
F9 INVITE Alice -> Proxy A
INVITE sips:bob@example.com SIP/2.0
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
Max-Forwards: 70
To: Bob <sips:bob@example.com>
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Route: <sips:proxya.example.net;lr>
Contact: <sips:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}F10 100 (INVITE) Proxy A -> Alice
SIP/2.0 100 Trying
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sips:bob@example.com>
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Content-Length: 0F11 INVITE Proxy A -> Registrar/Authoritative Proxy B
INVITE sips:bob@example.com SIP/2.0
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
Max-Forwards: 69
To: Bob <sips:bob@example.com>
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route: <sips:proxya.example.net;lr>
Contact: <sips:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}F12 100 (INVITE) Registrar/Authoritative Proxy B -> Proxy A
SIP/2.0 100 Trying
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sips:bob@example.com>
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Content-Length: 0F13 INVITE Registrar/Authoritative Proxy B -> Edge Proxy B
INVITE sips:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bKbalouba
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
Max-Forwards: 68
To: Bob <sips:bob@example.com>
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Route:
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@edge.example.com;lr;ob>
Record-Route: <sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
Contact: <sips:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}F14 100 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
SIP/2.0 100 Trying
Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bKbalouba
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sips:bob@example.com>
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Content-Length: 0F15 INVITE Edge Proxy B -> Bob's phone
F16 180 (INVITE) Bob's Phone -> Edge Proxy B
SIP/2.0 180 Ringing
Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKbiba
Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bKbalouba
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
Contact: <sips:bob@bobphone.example.com>
Content-Length: 0F17 180 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
SIP/2.0 180 Ringing
Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bKbalouba
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
Contact: <sips:bob@bobphone.example.com>
Content-Length: 0F18 180 Registrar/Authoritative Proxy B -> Proxy A
SIP/2.0 180 Ringing
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
Contact: <sips:bob@bobphone.example.com>
Content-Length: 0F19 180 (INVITE) Proxy A -> Alice
SIP/2.0 180 Ringing
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
Contact: <sips:bob@bobphone.example.com>
Content-Length: 0F20 200 (INVITE) Bob's Phone -> Edge Proxy B
SIP/2.0 200 OK
Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKbiba
Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bKbalouba
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
Contact: <sips:bob@bobphone.example.com>
Content-Length: 0F21 200 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
SIP/2.0 200 OK
Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bKbalouba
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
Contact: <sips:bob@bobphone.example.com>
Content-Length: 0F22 200 Registrar/Authoritative Proxy B -> Proxy A
SIP/2.0 200 OK
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
Contact: <sips:bob@bobphone.example.com>
Content-Length: 0F23 200 (INVITE) Proxy A -> Alice
SIP/2.0 200 OK
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
Contact: <sips:bob@bobphone.example.com>
Content-Length: 0F24 ACK Alice -> Proxy A
ACK sips:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKksdjf
Max-Forwards: 70
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 ACK
Route: <sips:proxya.example.net;lr>, <sips:pb.example.com;lr>,
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@pb.example.com;lr;ob>
Content-Length: 0F25 ACK Proxy A -> Registrar/Authoritative Proxy B
ACK sips:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKplo7hy
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKksdjf
Max-Forwards: 69
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 ACK
Route: <sips:pb.example.com;lr>,
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@pb.example.com;lr;ob>
Content-Length: 0F26 ACK Registrar/Authoritative Proxy B -> Edge Proxy B
ACK sips:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bK8msdu2
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKplo7hy
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKksdjf
Max-Forwards: 69
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 ACK
Route: <sips:pb.example.com;lr>,
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@pb.example.com;lr;ob>
Content-Length: 0F27 ACK Proxy B -> Bob's Phone
ACK sips:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKkmfdgk
Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bK8msdu2
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKplo7hy
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKksdjf
Max-Forwards: 68
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 ACK
Content-Length: 06.3. Alice Calls Bob's SIP AOR Using TCP 🦋
Bob's registration has already occurred as per Section 6.1. Bestie, we're already set up, so no need to redo the setup! ✨
In this second example, Alice calls Bob's SIP AOR instead (sip:bob@example.com) 📞, and she uses TCP as her transport 🚂. Registrar/Authoritative Proxy B looks up the binding in the registration database and finds two Contact header field bindings 👀. Alice addressed Bob with a SIP Request-URI (sip:bob@example.com), so Registrar/Authoritative Proxy B decides the call needs to go to bobpc (which registered with a SIP Contact header field) AND bobphone (which registered with a SIPS Contact header field) 💅. So the request gets forked to sip:bob@bobpc.example.com and sip:bob@bobphone.example.com, going through Edge Proxy B 🌸.
Here's the cute part: Registrar/Authoritative Proxy B keeps the SIP scheme of the Request-URI instead of swapping it for the SIPS scheme from the Contact header field that was used for registration 🙈. Both Registrar/Authoritative Proxy B and Edge Proxy B insert themselves into the Record-Route 🛣️. Bob's phone's policy is to accept calls to SIP and SIPS (i.e., "best effort") 🫶, so his PC client and his SIP phone ring at the same time 🔔🔔. Bob answers on his SIP phone, and the forked call leg to the PC client gets canceled 💀. Iconic multitasking, honestly ✨.
(eb) (pb)
Edge Registrar/
Bob@bobpc Proxy B Auth. Proxy B Proxy A Alice
| | | | |
| | | | INVITE F9 |
| | | INVITE F11 |<-----------|
| | INVITE F13'|<-----------| 100 F10 |
| INVITE F15' |<-----------| 100 F12 |----------->|
|<------------------| 100 F14' |----------->| |
| 180 F16' |----------->| | |
|------------------>| 180 F17' | | |
| |----------->| 180 F18' | |
| Bob@bobphone | |----------->| 180 F19' |
| | | INVITE F13 | |----------->|
| | INVITE F15 |<-----------| | |
| |<-----------| 100 F14 | | |
| | 180 F16 |----------->| | |
| |----------->| 180 F17 | | |
| | 200 F20 |----------->| 180 F18 | |
| |----------->| 200 F21 |----------->| 180 F19 |
| | |----------->| 200 F22 |----------->|
| | | |----------->| 200 F23 |
| | | | |----------->|
| | | | | ACK F24 |
| | | | ACK F25 |<-----------|
| | | ACK F26 |<-----------| |
| | ACK F27 |<-----------| | |
| |<-----------| | | |
| | CANCEL F26'| | |
| CANCEL F27' |<-----------| | |
|<------------------| | | |
| 200 F28' | | | |
|------------------>| 200 F29' | | |
| 487 F30' |----------->| | |
|------------------>| 487 F31' | | |
| |----------->| | |Alice Calls Bob's SIP AOR 🍓
Message details
F9 INVITE Alice -> Proxy A
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
Max-Forwards: 70
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Route: <sip:proxya.example.net;lr>
Contact: <sip:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}F10 100 (INVITE) Proxy A -> Alice
okay so the first thing we see is a 100 Trying 🎀 it's Proxy A telling Alice "got it, working on it" 💅
SIP/2.0 100 Trying
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Content-Length: 0F11 INVITE Proxy A -> Registrar/Authoritative Proxy B 🦋 the INVITE is off to the big boss proxy, and look at Proxy A adding its own Via and Record-Route, very organised ✨
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
Max-Forwards: 69
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route: <sip:proxya.example.net;lr>
Contact: <sip:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}F12 100 (INVITE) Registrar/Authoritative Proxy B -> Proxy A 🌸 Proxy B says "yep, I've got this one" right back to Proxy A 🫶
SIP/2.0 100 Trying
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Content-Length: 0F13' INVITE Registrar/Authoritative Proxy B -> Edge Proxy B 🧚 this is the prime moment, Proxy B forwards the INVITE to the Edge Proxy B, and the Request-URI now points at Bob's PC, the Route header is doing its thing, and the Max-Forwards count goes down to 68 🔥
INVITE sip:bob@bobpc.example.com SIP/2.0
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
Max-Forwards: 68
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Route: <sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;ob>
Record-Route: <sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}F14' 100 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B 💜 Edge Proxy B says "on it" back to Proxy B
SIP/2.0 100 Trying
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Content-Length: 0F15' INVITE Edge Proxy B -> Bob's PC Client 💖 finally the INVITE lands on Bob's PC! Edge Proxy B adds its own Via and drops the Max-Forwards down to 67, and the Record-Route gets a brand new entry on top 🦋
INVITE sip:bob@bobpc.example.com SIP/2.0
Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bKbiba
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
Max-Forwards: 67
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}F16' 180 (INVITE) Bob's PC Client -> Edge Proxy B 🎀 Bob's PC is ringing! 180 Ringing comes back with a brand new To tag, and his Contact now points at his PC 💅
SIP/2.0 180 Ringing
Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bKbiba
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=963258
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:bob@bobpc.example.com>
Content-Length: 0F17' 180 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B 🌈 the 180 gets passed back up the chain, with the top Via peeled off
SIP/2.0 180 Ringing
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=963258
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:bob@bobpc.example.com>
Content-Length: 0F18' 180 (INVITE) Registrar/Authoritative Proxy B -> Proxy A ⭐ still ringing, still passing it along 🍓
SIP/2.0 180 Ringing
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=963258
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:bob@bobpc.example.com>
Content-Length: 0F19' 180 (INVITE) Proxy A -> Alice 🦋 Alice gets the ringing news, and the Via headers are down to just her own
SIP/2.0 180 Ringing
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=963258
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:bob@bobpc.example.com>
Content-Length: 0okay now the plot twist 😭 Bob's PC isn't the only place he's reachable, so Registrar/Authoritative Proxy B forks the INVITE again, this time to Bob's Phone 👑
F13 INVITE Registrar/Authoritative Proxy B -> Edge Proxy B 🧚 same flow, new destination, and this time the Route header points at a different Edge Proxy B entry
INVITE sip:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
Max-Forwards: 68
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Route: <sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>
Record-Route: <sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}F14 100 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B 💅 Edge Proxy B confirms receipt
SIP/2.0 100 Trying
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Content-Length: 0F15 INVITE Edge Proxy B -> Bob's Phone 🎀 the INVITE hits Bob's Phone, and this time the top Via is TLS on port 5061 🔐 so the hop to his phone is encrypted, lowkey iconic
INVITE sip:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKtroubaba
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
Max-Forwards: 68
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}F16 180 (INVITE) Bob's Phone -> Edge Proxy B 🔥 Bob's Phone is ringing too, and it picks its own To tag, 5551212
SIP/2.0 180 Ringing
Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKtroubaba
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:bob@bobphone.example.com>
Content-Length: 0F17 180 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B 🌸 passed back up to Proxy B
SIP/2.0 180 Ringing
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:bob@bobphone.example.com>
Content-Length: 0F18 180 (INVITE) Registrar/Authoritative Proxy B -> Proxy A 🫶 onward to Proxy A
SIP/2.0 180 Ringing
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:bob@bobphone.example.com>
Content-Length: 0F19 180 (INVITE) Proxy A -> Alice 🦋 Alice hears the ringing from Bob's Phone now
SIP/2.0 180 Ringing
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:bob@bobphone.example.com>
Content-Length: 0and then Bob picks up!! 💖🥹 the 200 OK starts its trip back
F20 200 (INVITE) Bob's Phone -> Edge Proxy B 🎀 Bob answers, the 200 OK goes out over TLS again, and it's giving confirmed call 💅
SIP/2.0 200 OK
Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKtroubaba
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:bob@bobphone.example.com>
Content-Length: 0F21 200 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B ✨ passed up to Proxy B
SIP/2.0 200 OK
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:bob@bobphone.example.com>
Content-Length: 0F22 200 (INVITE) Registrar/Authoritative Proxy B -> Proxy A 👑 almost there bestie
SIP/2.0 200 OK
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:bob@bobphone.example.com>
Content-Length: 0F23 200 (INVITE) Proxy A -> Alice 💜 and the 200 OK finally reaches Alice, the call is connected and the whole thing was so iconic 🌈✨
SIP/2.0 200 OK
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:bob@bobphone.example.com>
Content-Length: 0Okay so bestie, the call flow wraps up here with the ACK, CANCEL, and 487 messages all bouncing back to Alice 💖
F24 ACK Alice -> Proxy A
SIP/2.0 200 OK
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:bob@bobphone.example.com>
Content-Length: 0ACK sip:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
Max-Forwards: 70
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 ACK
Route: <sip:proxya.example.net;lr>, <sip:pb.example.com;lr>,
<sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@edge.example.com;lr;ob>
Content-Length: 0F25 ACK Proxy A -> Registrar/Authoritative Proxy B
ACK sip:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
Max-Forwards: 69
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 ACK
Route: <sip:pb.example.com;lr>,
<sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>
Content-Length: 0F26 ACK Registrar/Authoritative Proxy B -> Edge Proxy B
ACK sip:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
Max-Forwards: 69
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 ACK
Route: <sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>
Content-Length: 0F27 ACK Proxy B -> Bob's Phone
ACK sip:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKtroubaba
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
Max-Forwards: 68
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 ACK
Content-Length: 0F26' CANCEL Registrar/Authoritative Proxy B -> Edge Proxy B
CANCEL sip:bob@bobpc.example.com SIP/2.0
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
Max-Forwards: 70
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 CANCEL
Route: <sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>
Content-Length: 0F27' CANCEL Edge Proxy B -> Bob's PC Client
CANCEL sip:bob@bobpc.example.com SIP/2.0
Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bKtroubaba
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
Max-Forwards: 69
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 CANCEL
Content-Length: 0F28' 200 (CANCEL) Bob's PC Client -> Edge Proxy B
SIP/2.0 200 OK
Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bKtroubaba
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 CANCEL
Content-Length: 0F29' 200 (CANCEL) Edge Proxy B -> Registrar/Authoritative Proxy B
SIP/2.0 200 OK
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 CANCEL
Content-Length: 0F30' 487 (INVITE) Bob's PC Client -> Edge Proxy B
SIP/2.0 487 Request Terminated
Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bKtroubaba
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Content-Length: 0F31' 487 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
SIP/2.0 487 Request Terminated
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Content-Length: 06.4. Alice Calls Bob's SIP AOR Using TLS
Bob's registration has already happened, as covered in Section 6.1 ✨
This third example is basically the second one, with one twist: Alice uses TLS as the transport for her connection to her proxy 🔐 That setup would be common if Alice's UA supported TLS and wanted a single connection to the proxy (which is exactly the situation with [RFC5626]). In the example below, Proxy A also talks to Outbound Proxy B over TLS, but that doesn't have to be the case.
When you use a SIP URI in the Request-URI but TLS as the transport for sending the request, the Via field says TLS. The Route header field (if there is one) would typically use a SIP URI, though it could also be a SIPS URI. The Contact header fields, To, and From would also normally use a SIP URI 💅
The call flow is exactly the same as the second example (Section 6.3). The only difference is that all the Via header fields use TLS Via parameters. The URIs stay as SIP URIs, not SIPS URIs, periodt 🦋
7. Further Considerations ✨
Okay, now we get into the messy bits. [RFC3261] itself creates some complications with SIPS, like when Record-Route isn't used 🙈 If a SIPS URI shows up in a Contact header field in a dialog-initiating request and Record-Route isn't used, the other end might not be able to use that SIPS URI. If the other end doesn't support SIPS and/or TLS, it simply won't be able to use it. The last-hop exception is one example of when this can happen. In that case, using Record-Route so the requests go through proxies can help make it work 🧚
Another example: even when the Contact header field is a SIPS URI and Record-Route isn't used, and the far end supports SIPS and TLS, the far end might still be unable to set up a TLS connection with the SIP originating end if it can't validate the certificate. That could typically happen if the originating end was using server-side authentication (more on that below), or if the originating end isn't using a certificate that can be validated 😭
TLS itself has a big impact on how SIPS gets used. Server-side authentication, where the server side provides its certificate but the client side doesn't, is typically used between a SIP end-user device acting as the TLS client (like a phone or a personal computer) and its SIP server (a proxy or registrar) acting as the TLS server 📱 TLS mutual authentication, where both the client side and the server side provide their certificates, is typically used between SIP servers (proxies, registrars), or between statically configured devices such as PSTN gateways or media servers 🌐
With mutual authentication, for two entities to set up a TLS connection, both sides need to be able to validate each other's certificates, either through static configuration or by being able to recurse to a valid root certificate. With server-side authentication, only the client side can validate the server side's certificate, since the client side doesn't provide one. So the takeaway is: whenever a SIPS URI is used to set up a TLS connection, the entity setting up the connection (the client) is expected to be able to validate the server side's certificate 🫶 For server-side authentication, [RFC5626] is the recommended approach. For mutual authentication, you need to make sure the network architecture is set up so connections happen between entities that have access to each other's certificates 🔥
[RFC3261] Record-Route and [RFC3327] Path are super useful for making sure previously established TLS connections can be reused 🌸 Other mechanisms might also work in certain situations. For example, using widely recognized root certificates makes it easier to create TLS connections 👑
8. Security Considerations ✨
Honestly, most of this document can be considered security considerations, since it all applies to how the SIPS URI is used 🚨
The "last-hop exception" of [RFC3261] introduced significant potential vulnerabilities in SIP, so this specification has deprecated it 💀
Section 26.4.4 of [RFC3261] describes the security considerations for the SIPS URI scheme. Those security considerations also apply here, as modified by Appendix A 🔐
9. IANA Considerations ✨
Okay, IANA time 🎀 This specification registers two new warning codes: 380 "SIPS Not Allowed" and 381 "SIPS Required". They're defined as follows, and they've been added to the Warning Codes (warn-codes) sub-registry of the SIP Parameters registry, which lives at http://www.iana.org.
380 SIPS Not Allowed: The UAS or proxy cannot process the request
because the SIPS scheme is not allowed (e.g., because there are
currently no registered SIPS contacts).
381 SIPS Required: The UAS or proxy cannot process the request
because the SIPS scheme is required.
Reference: RFC 5630The note in the Warning Codes sub-registry reads:
Warning codes provide information supplemental to the status code
in SIP response messages.10. Acknowledgments 🫶
The author would like to thank Jon Peterson, Cullen Jennings, Jonathan Rosenberg, John Elwell, Paul Kyzivat, Eric Rescorla, Robert Sparks, Rifaat Shekh-Yusef, Peter Reissner, Tina Tsou, Keith Drage, Brian Stucker, Patrick Ma, Lavis Zhou, Joel Halpern, Hisham Karthabil, Dean Willis, Eric Tremblay, Hans Persson, and Ben Campbell for their careful review and input 💖 Huge thanks as well to Rohan Mahy for helping with the subtleties of [RFC5626] 🌈
11. References ✨
11.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.
- [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
- [RFC5626] Jennings, C., "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, October 2009.
11.2. Informative References 📚
Okay bestie, this is the extra-reading list 🤓 Every entry is a doc the RFC points to for more context, so here they all are, complete and unbothered.
- [RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
- [RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts", RFC 3327, December 2002.
- [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
- [RFC3608] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration", RFC 3608, October 2003.
- [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.
- [RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, September 2004.
- [RFC3893] Peterson, J., "Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format", RFC 3893, September 2004.
- [RFC3911] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP) "Join" Header", RFC 3911, October 2004.
- [RFC4168] Rosenberg, J., Schulzrinne, H., and G. Camarillo, "The Stream Control Transmission Protocol (SCTP) as a Transport for the Session Initiation Protocol (SIP)", RFC 4168, October 2005.
- [RFC4244] Barnes, M., "An Extension to the Session Initiation Protocol (SIP) for Request History Information", RFC 4244, November 2005.
- [RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
- [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUU) in the Session Initiation Protocol (SIP)", RFC 5627, October 2009.
Appendix A. Bug Fixes for RFC 3261 🛠️✨
Main character energy here: this appendix is the fix-it list for RFC 3261 💅 It's here so this document can actually work with it. Every change is spelled out below, so grab a snack and let's go.
The first fix is about Section 8.1.3.5. The last sentence of the fifth paragraph gets replaced by this:
The client SHOULD retry the request, this time, using a SIP URI
unless the original Request-URI used a SIPS scheme, in which case
the client MUST NOT retry the request automatically.Next up is Section 10.2.1. Its fifth paragraph gets swapped out for this:
If the Address of Record in the To header field of a REGISTER
request is a SIPS URI, then the UAC MUST also include only SIPS
URIs in any Contact header field value in the requests.Over in Section 16.7 on p. 112, which covers Record-Route, the second paragraph is deleted 🗑️ Bye bye!
The last paragraph of Section 19.1 gets reworded like this:
A SIPS URI specifies that the resource be contacted securely.
This means, in particular, that TLS is to be used on each hop
between the UAC and the resource identified by the target SIPS
URI. Any resources described by a SIP URI (...)In the third paragraph of Section 20.43, the words "the session description" in the first sentence get replaced with "SIP". Later in that same paragraph, "390" becomes "380", and "miscellaneous warnings" becomes "miscellaneous SIP-related warnings" 🌸
Section 26.2.2 gets a glow-up too. Its second paragraph is reworded as follows:
(...) When used as the Request-URI of a request, the SIPS scheme
signifies that each hop over which the request is forwarded, until
the request reaches the resource identified by the Request-URI, is
secured with TLS. When used by the originator of a request (as
would be the case if they employed a SIPS URI as the address-of-
record of the target), SIPS dictates that the entire request path
to the target domain be so secured.Now Section 26.4.4, which is a whole saga 🍿 The first paragraph gets replaced by the following:
Actually using TLS on every segment of a request path entails that
the terminating UAS is reachable over TLS (by registering with a
SIPS URI as a contact address). The SIPS scheme implies
transitive trust. Obviously, there is nothing that prevents
proxies from cheating. Thus, SIPS cannot guarantee that TLS usage
will be truly respected end-to-end on each segment of a request
path. Note that since many UAs will not accept incoming TLS
connections, even those UAs that do support TLS will be required
to maintain persistent TLS connections as described in the TLS
limitations section above in order to receive requests over TLS as
a UAS.The first sentence of the third paragraph of Section 26.4.4 gets replaced by this:
Ensuring that TLS will be used for all of the request segments up
to the target UAS is somewhat complex.The fourth paragraph of Section 26.4.4 is deleted 👋
The last sentence of the fifth paragraph of Section 26.4.4 gets reworded as follows:
S/MIME or, preferably, [RFC4474] may also be used by the
originating UAC to help ensure that the original form of the To
header field is carried end-to-end.Almost there! In the third paragraph of Section 27.2, the phrase "when the failure of the transaction results from a Session Description Protocol (SDP) (RFC 2327 [1]) problem" gets deleted 🫶
Last one: in the fifth paragraph of Section 27.2, "390" becomes "380", and "miscellaneous warnings" becomes "miscellaneous SIP-related warnings" 💖
Author's Address 🦋
Here's who wrote it, bestie. Reach out to them with the good questions:
Francois Audet
Skype Labs
EMail: francois.audet@skypelabs.comAnd that's the whole RFC, bestie 🎀✨ You made it to the end 😭🫶
📦 where this page comes from
- ietf: rfc5630 2009-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms