RFC 5626
Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)
RFC 5626: Managing Client-Initiated Connections in the Session Initiation Protocol (SIP) 🦋
Okay bestie, here's the title block facts first 📜 This one is from the Network Working Group and it's RFC 5626. It's a Standards Track document dated October 2009, and it updates 3261 and 3327. The editors are C. Jennings, Ed. from Cisco Systems, R. Mahy, Ed. (Unaffiliated), and F. Audet, Ed. from Skype Labs. 💖
Abstract 💖
Okay so SIP lets proxy servers open TCP connections or send asynchronous UDP datagrams to User Agents so they can deliver requests. 🌸 But in a lot of real deployments, stuff like firewalls, Network Address Translators (NATs), or TLS with server-provided certificates stops servers from connecting to User Agents that way. 😭 This spec defines behaviors for User Agents, registrars, and proxy servers so requests can be delivered over existing connections the User Agent already set up. It also defines keep-alive behaviors to keep NAT bindings open, and it spells out how a User Agent can use multiple connections to its registrar. Iconic, honestly. ✨
Status of This Memo 📝
This document is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited. 🌈
Copyright 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5
2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Summary of Mechanism . . . . . . . . . . . . . . . . . . . 6
3.2. Single Registrar and UA . . . . . . . . . . . . . . . . . 7
3.3. Multiple Connections from a User Agent . . . . . . . . . . 8
3.4. Edge Proxies . . . . . . . . . . . . . . . . . . . . . . . 10
3.5. Keep-Alive Technique . . . . . . . . . . . . . . . . . . . 11
3.5.1. CRLF Keep-Alive Technique . . . . . . . . . . . . . . 12
3.5.2. STUN Keep-Alive Technique . . . . . . . . . . . . . . 12
4. User Agent Procedures . . . . . . . . . . . . . . . . . . . . 13
4.1. Instance ID Creation . . . . . . . . . . . . . . . . . . . 13
4.2. Registrations . . . . . . . . . . . . . . . . . . . . . . 14
4.2.1. Initial Registrations . . . . . . . . . . . . . . . . 14
4.2.2. Subsequent REGISTER Requests . . . . . . . . . . . . . 16
4.2.3. Third-Party Registrations . . . . . . . . . . . . . . 17
4.3. Sending Non-REGISTER Requests . . . . . . . . . . . . . . 17
4.4. Keep-Alives and Detecting Flow Failure . . . . . . . . . . 18
4.4.1. Keep-Alive with CRLF . . . . . . . . . . . . . . . . . 19
4.4.2. Keep-Alive with STUN . . . . . . . . . . . . . . . . . 21
4.5. Flow Recovery . . . . . . . . . . . . . . . . . . . . . . 21
5. Edge Proxy Procedures . . . . . . . . . . . . . . . . . . . . 22
5.1. Processing Register Requests . . . . . . . . . . . . . . . 22
5.2. Generating Flow Tokens . . . . . . . . . . . . . . . . . . 23
5.3. Forwarding Non-REGISTER Requests . . . . . . . . . . . . . 23
5.3.1. Processing Incoming Requests . . . . . . . . . . . . . 24
5.3.2. Processing Outgoing Requests . . . . . . . . . . . . . 24
5.4. Edge Proxy Keep-Alive Handling . . . . . . . . . . . . . . 25
6. Registrar Procedures . . . . . . . . . . . . . . . . . . . . . 25
7. Authoritative Proxy Procedures: Forwarding Requests . . . . . 27
8. STUN Keep-Alive Processing . . . . . . . . . . . . . . . . . . 28
8.1. Use with SigComp . . . . . . . . . . . . . . . . . . . . . 29
9. Example Message Flow . . . . . . . . . . . . . . . . . . . . . 30
9.1. Subscription to Configuration Package . . . . . . . . . . 30
9.2. Registration . . . . . . . . . . . . . . . . . . . . . . . 32
9.3. Incoming Call and Proxy Crash . . . . . . . . . . . . . . 34
9.4. Re-Registration . . . . . . . . . . . . . . . . . . . . . 37
9.5. Outgoing Call . . . . . . . . . . . . . . . . . . . . . . 38
10. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
11.1. Flow-Timer Header Field . . . . . . . . . . . . . . . . . 40
11.2. "reg-id" Contact Header Field Parameter . . . . . . . . . 40
11.3. SIP/SIPS URI Parameters . . . . . . . . . . . . . . . . . 41
11.4. SIP Option Tag . . . . . . . . . . . . . . . . . . . . . . 41
11.5. 430 (Flow Failed) Response Code . . . . . . . . . . . . . 41
11.6. 439 (First Hop Lacks Outbound Support) Response Code . . . 42
11.7. Media Feature Tag . . . . . . . . . . . . . . . . . . . . 42
12. Security Considerations . . . . . . . . . . . . . . . . . . . 43
13. Operational Notes on Transports . . . . . . . . . . . . . . . 44
14. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 44
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 45
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45
16.1. Normative References . . . . . . . . . . . . . . . . . . . 45
16.2. Informative References . . . . . . . . . . . . . . . . . . 47
Appendix A. Default Flow Registration Backoff Times . . . . . . . 49
Appendix B. ABNF . . . . . . . . . . . . . . . . . . . . . . . . 491. Introduction 🌸
Okay so picture this: there are tons of places where SIP [RFC3261] gets deployed, and the User Agent (UA) can totally open a connection to a registrar or proxy, but connections going the other way, back to the UA, just aren't possible. 😭 This can happen for a few reasons, but the big culprit is usually a NAT or a firewall sitting between the SIP UA and the proxy. Lots of those boxes only let outgoing connections through. So this spec gives a SIP User Agent hiding behind a firewall or NAT the ability to receive inbound traffic tied to the registrations or dialogs it started itself. Iconic. 🦋
Most IP phones and personal computers get their network configurations automatically through something like the Dynamic Host Configuration Protocol (DHCP) [RFC2131]. These devices usually don't have a useful name in the Domain Name System (DNS) [RFC1035], and they almost never have a long-term, stable DNS name that's good for the subjectAltName of a certificate, as required by [RFC3261]. 💀 But they can still act as a Transport Layer Security (TLS) [RFC5246] client and make outbound connections to a proxy or registrar that proves itself with a server certificate. The server can then authenticate the UA with a shared secret in a digest challenge (as defined in Section 22 of RFC 3261) over that TLS connection. So this spec also lets a SIP User Agent that has to start the TLS connection itself receive inbound traffic tied to registrations or dialogs it initiated. 🎀
Here's the key idea 🔑: when a UA sends a REGISTER request or a dialog-forming request, the proxy can later reuse that same network "flow" to send along any incoming requests meant for this UA in the context of that registration or dialog. A flow can be a bidirectional stream of UDP datagrams, a TCP connection, or an analogous concept in another transport protocol. Same vibe, different transport. ✨
For a UA to receive incoming requests, it has to connect to a server. Since the server can't connect back to the UA, the UA has to make sure a flow is always active 🫶 That means the UA needs to detect when a flow fails. Detection takes time and leaves a window where incoming requests could get missed, so this mechanism lets the UA register over multiple flows at the same time. 🧚 This spec also defines two keep-alive schemes. The keep-alive mechanism keeps NAT bindings fresh and lets the UA detect when a flow has failed. 🌈
2. Conventions and Terminology 💅
Okay, the key words are the rules of the game here 💜 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]. Those capitals are doing serious work, so read them carefully. 🔥
Part 1 is done, bestie! More of the spec is coming in the next part 👑
2.1. Definitions
okay so let's get the vocab down first bestie 🎀 because this doc throws a lot of terms at you and you NEED them to follow along 💅
Authoritative Proxy: this is a proxy that handles non-REGISTER requests for a specific Address-of-Record (AOR), does the logical Location Server lookup described in [RFC3261], and forwards those requests to specific Contact URIs. 💖 (In [RFC3261], the one that's authoritative for REGISTER requests for a specific AOR is called a Registration Server. Different name, same energy 🫶)
Edge Proxy: an edge proxy is any proxy sitting topologically between the registering User Agent and the Authoritative Proxy. 🌸 The "first" edge proxy is just the first one a UA hits when it sends a request.
Flow: a Flow is a transport-layer association between two hosts. It's represented by the network address and port number of both ends, plus the transport protocol. 🦋 For TCP, a flow is equivalent to a TCP connection. For UDP, a flow is a bidirectional stream of datagrams between a single pair of IP addresses and ports of both peers. And with TCP, a flow often has a one-to-one correspondence with a single file descriptor in the operating system. 🧚
Flow Token: an identifier that uniquely identifies a flow, and it can be included in a SIP URI (Uniform Resource Identifier [RFC3986]). ✨
reg-id: this is the value of a new header field parameter for the Contact header field. 💜 When a UA registers multiple times, each for a different flow, each concurrent registration gets a unique reg-id value. 🎀
instance-id: this spec uses the word instance-id to refer to the value of the "sip.instance" media feature tag, which shows up as a +sip.instance Contact header field parameter. 🌈 It's a Uniform Resource Name (URN) that uniquely identifies this specific UA instance. 👑
"ob" Parameter: the "ob" parameter is a SIP URI parameter whose meaning depends on context. 🍓 In a Path header field value, the first edge proxy uses it to indicate that a flow token was added to the URI. In a Contact or Route header field value, it means the UA would like other requests in the same dialog to be routed over the same flow. 💅
outbound-proxy-set: this is a set of SIP URIs (Uniform Resource Identifiers) that represents each of the outbound proxies (often edge proxies) the UA will try to keep a direct flow open with. 🫶 The first URI in the set is often called the primary outbound proxy, and the second is the secondary outbound proxy. ⭐ But here's the tea: there's no difference between any of the URIs in this set, and the primary/secondary naming doesn't mean one is preferred over the other. 🙈
3. Overview ✨
okay this section is the big picture 🔥 the mechanisms here are useful in a few scenarios we'll dig into, like the simple co-located registrar and proxy, a User Agent that wants multiple connections to a resource (for redundancy, for example), and a system that uses edge proxies. 🦋
Heads up: this entire section is non-normative, so it's here to explain, not to tell implementers what they MUST do. 🌸
3.1. Summary of Mechanism 💖
each UA has a unique instance-id that stays the same even if the UA reboots or gets power cycled. 🎀 Each UA can register multiple times over different flows for the same SIP Address of Record (AOR) to get high reliability. 🫶 Each registration includes the instance-id for the UA and a reg-id label that's different for each flow. The registrar can use the instance-id to recognize that two different registrations both belong to the same UA. 🧚 And it can use the reg-id label to tell whether a UA is creating a new flow or refreshing or replacing an old one, maybe after a reboot or a network failure. 👑
when a proxy goes to route a message to a UA it has a binding for, it can use any one of the flows where a successful registration was completed. 💜 If delivering a request on one flow fails, it can be tried again on an alternate flow. 🌈 Proxies figure out which flows go to the same UA by comparing the instance-id, and they can tell that a flow replaces a previously abandoned one by looking at the reg-id. 🍓
when sending a dialog-forming request, a UA can also ask its first edge proxy to route subsequent requests in that dialog over the same flow. ✨ This is necessary whether the UA has registered or not. 💅
UAs use a simple periodic message as a keep-alive mechanism to keep their flow to the proxy or registrar alive. 🌸 For connection-oriented transports such as TCP, this is based on carriage-return and line-feed sequences (CRLF). For transports that aren't connection oriented, it's done using a SIP-specific usage profile of STUN (Session Traversal Utilities for NAT) [RFC5389]. 🔥
3.2. Single Registrar and UA 🎀
in the topology below, a single server is acting as both a registrar and a proxy. 🦋
+-----------+
| Registrar |
| Proxy |
+-----+-----+
|
|
+----+--+
| User |
| Agent |
+-------+User Agents that form only a single flow keep registering normally, but they include the instance-id as described in Section 4.1. 💖 The UA also includes a "reg-id" Contact header field parameter, which lets the registrar detect and avoid keeping invalid contacts when a UA reboots or reconnects after its old connection failed for some reason. 🫶
for clarity, here's an example. 🌈 Bob's UA creates a new TCP flow to the registrar and sends this REGISTER request:
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/TCP 192.0.2.2;branch=z9hG4bK-bad0ce-11-1036
Max-Forwards: 70
From: Bob <sip:bob@example.com>;tag=d879h76
To: Bob <sip:bob@example.com>
Call-ID: 8921348ju72je840.204
CSeq: 1 REGISTER
Supported: path, outbound
Contact: <sip:line1@192.0.2.2;transport=tcp>; reg-id=1;
;+sip.instance="<urn:uuid:00000000-0000-1000-8000-000A95A0E128>"
Content-Length: 0the registrar challenges this registration to authenticate Bob. 🔥 When the registrar adds an entry for this contact under Bob's AOR, it also keeps track of the connection it received the registration over. 🧚
the registrar saves the instance-id ("urn:uuid:00000000-0000-1000-8000-000A95A0E128") and reg-id ("1") along with the rest of the Contact header field. 💜 If the instance-id and reg-id match a previous registration for the same AOR, the registrar replaces the old Contact URI and flow information. 👑 This lets a UA that has rebooted replace its previous registration for each flow with minimal impact on overall system load. ✨
when Alice sends a request to Bob, his authoritative proxy selects the target set. 🦋 The proxy forwards the request to elements in the target set based on the proxy's policy. 💅 The proxy looks at the target set and uses the instance-id to understand whether two targets both end up routing to the same UA. 🌸 When the proxy goes to forward a request to a given target, it looks up the flows over which it received the registration. 🎀 Then it forwards the request over an existing flow, instead of resolving the Contact URI using the procedures in [RFC3263] and trying to form a new flow to that contact. 🫶
as described in the next section, if the proxy has multiple flows that all go to this UA, it can choose any one of the registration bindings for this AOR that has the same instance-id as the selected UA. 💖
3.3. Multiple Connections from a User Agent 🌈
there are lots of ways to deploy SIP to build a reliable and scalable system. 🧚 This section discusses one design that's possible with the mechanisms in this specification. Other designs are possible too. 🦋
in the example system below, the logical outbound proxy/registrar for the domain runs on two hosts that share the appropriate state and can both provide registrar and outbound proxy functionality for the domain. 💜 The UA forms connections to two of the physical hosts that can perform the authoritative proxy/registrar function for the domain. Reliability comes from having the UA form two TCP connections to the domain. 🔥
+-------------------+
| Domain |
| Logical Proxy/Reg |
| |
|+-----+ +-----+|
||Host1| |Host2||
|+-----+ +-----+|
+---\------------/--+
\ /
\ /
\ /
\ /
+------+
| User |
| Agent|
+------+the UA is configured with multiple outbound proxy registration URIs. 👑 These URIs get configured into the UA through whatever the normal mechanism is for configuring the proxy address and AOR in the UA. 🎀 If the AOR is alice@example.com, the outbound-proxy-set might look something like "sip:primary.example.com" and "sip:secondary.example.com". 💖 Note that each URI in the outbound-proxy-set could resolve to several different physical hosts. ⭐ The administrative domain that created these URIs should make sure the two URIs resolve to separate hosts. 🫶 These URIs are handled according to normal SIP processing rules, so mechanisms like DNS SRV [RFC2782] can be used to load-balance across a proxy farm. 🌸 The approach in this document does not prevent future extensions, such as the SIP UA configuration framework [CONFIG-FMWK], from adding other ways for a User Agent to discover its outbound-proxy-set. ✨
the domain also needs to make sure that a request for the UA sent to Host1 or Host2 is then sent across the appropriate flow to the UA. 🧚 The domain might choose to use the Path header approach (described in the next section) to store this internal routing information on Host1 or Host2. 🦋
when a single server fails, all the UAs that have a flow through it will detect a flow failure and try to reconnect. 😭 This can cause large loads on the server. When large numbers of hosts reconnect nearly simultaneously, that's called the avalanche restart problem, and it's discussed further in Section 4.5. 💀 Multiple flows to many servers help reduce the load caused by the avalanche restart. 🌈 If a UA has multiple flows and one of the servers fails, the UA delays a recommended amount of time before trying to form a new connection to replace the flow to the failed server. 🍓 By spreading out the time all the UAs take to reconnect to a server, the load on the server farm goes down. 🫶
scalability comes from using DNS SRV [RFC2782] to load-balance the primary connection across a set of machines that can service the primary connection, and also using DNS SRV to load-balance across a separate set of machines that can service the secondary connection. 💅 The deployment here requires that DNS is configured with one entry that resolves to all the primary hosts and another entry that resolves to all the secondary hosts. 🌸 Yes, this adds some extra DNS configuration, but the approach works and requires no additional SIP extensions to [RFC3263]. 🎀
another motivation for keeping multiple flows between the UA and its registrar is multihomed UAs. 💖 Such UAs can benefit from multiple connections from different interfaces, which protects against the failure of an individual access link. 👑
3.4. Edge Proxies ✨
Okay so some SIP deployments use edge proxies 💅. The UA sends its REGISTER to an edge proxy, and then that edge proxy forwards the REGISTER on to the registrar. There could also be a NAT or firewall sitting between the UA and the edge proxy 🧱
+---------+
|Registrar|
|Proxy |
+---------+
/ \
/ \
/ \
+-----+ +-----+
|Edge1| |Edge2|
+-----+ +-----+
\ /
\ /
----------------------------NAT/FW
\ /
\ /
+------+
|User |
|Agent |
+------+The edge proxy includes a Path header [RFC3327] so that when the proxy/registrar later forwards a request to this UA, the request gets routed back through the edge proxy 🦋
These systems can use basically the same mechanism we covered in the previous sections, but they need to use the Path header 🎀 When the edge proxy receives a registration, it needs to create an identifier value that is unique to this flow (and not to a later flow with the same addresses), and then put that identifier in the Path header URI. This identifier has two jobs ✨ First, it lets the edge proxy map future requests back to the correct flow. Second, because the identifier only gets returned if the user authenticates with the registrar successfully, the edge proxy can indirectly check the user's authentication information through the registrar. The identifier goes in the user portion of a loose route in the Path header. If the registration succeeds, the edge proxy needs to map future requests (the ones routed to the identifier value from the Path header) to the associated flow 🫶
The term edge proxy is often used for deployments where the edge proxy is in the same administrative domain as the registrar. In this specification, though, we use the term for any proxy between the UA and the registrar. For example, the edge proxy might be inside an enterprise that requires its use, while the registrar belongs to a service provider with no relationship to that enterprise. Whether or not they share an administrative domain, this specification requires that registrars and edge proxies support the Path header mechanism in [RFC3327] 💜
3.5. Keep-Alive Technique
3.5. Keep-Alive Technique 🌸
This document describes two keep-alive mechanisms: a CRLF keep-alive and a STUN keep-alive 🍓 Each one uses a client-to-server "ping" keep-alive and a matching server-to-client "pong" message. This ping-pong sequence lets the client (and optionally the server) tell whether its flow is still active and useful for SIP traffic. The server responds to pings by sending pongs. If the client does not receive a pong in response to its ping (allowing for retransmission for STUN, as described in Section 4.4.2), it declares the flow dead and opens a new flow in its place 💀
This document also suggests timer values for these client keep-alive mechanisms. These timer values were picked to keep most NAT and firewall bindings open, to detect unresponsive servers within 2 minutes, and to mitigate the avalanche restart problem. However, the client may choose different timer values to suit its needs, for example to optimize battery life 🔋 In some environments, the server can also keep track of the time since a ping was received over a flow, to guess how likely it is that the flow is still useful for delivering SIP messages 🧚
When the UA detects that a flow has failed, or that the flow definition has changed, the UA needs to re-register. It will use the back-off mechanism described in Section 4.5 to provide congestion relief when a large number of agents reboot at the same time 😭
A keep-alive mechanism needs to keep NAT bindings refreshed. For connections, it also needs to detect failure of the connection. For connectionless transports, it needs to detect flow failures, including changes to the NAT public mapping 🔥 For connection-oriented transports such as TCP [RFC0793] and SCTP [RFC4960], this specification describes a keep-alive approach based on sending CRLFs. For connectionless transport, such as UDP [RFC0768], this specification describes using STUN [RFC5389] over the same flow as the SIP traffic to perform the keep-alive ✨
UAs and Proxies are also free to use native transport keep-alives. However, the application may not be able to set these timers on a per-connection basis, and the server certainly cannot make any assumption about which values are used. Use of native transport keep-alives is outside the scope of this document 🙈
3.5.1. CRLF Keep-Alive Technique
3.5.1. CRLF Keep-Alive Technique 🌈
This approach can only be used with connection-oriented transports such as TCP or SCTP. The client periodically sends a double-CRLF (the "ping") and then waits to receive a single CRLF (the "pong"). If the client does not receive a "pong" within an appropriate amount of time, it considers the flow failed 🩷
Note: Sending a CRLF over a connection-oriented transport is backwards compatible (because of requirements in Section 7.5 of [RFC3261]), but only implementations which support this specification will respond to a "ping" with a "pong".
3.5.2. STUN Keep-Alive Technique
3.5.2. STUN Keep-Alive Technique 🦄
This approach can only be used for connectionless transports, such as UDP.
For connectionless transports, a flow definition could change because a NAT device in the network path reboots and the resulting public IP address or port mapping for the UA changes. To detect this, STUN requests are sent over the same flow that's being used for the SIP traffic. The proxy or registrar acts as a limited Session Traversal Utilities for NAT (STUN) [RFC5389] server on the SIP signaling port 🎯
Note: The STUN mechanism is very robust and allows the detection of a changed IP address and port. Many other options were considered, but the SIP Working Group selected the STUN-based approach. Approaches using SIP requests were abandoned because many believed that good performance and full backwards compatibility using this method were mutually exclusive.
4. User Agent Procedures 👑
4.1. Instance ID Creation 🎀
Each UA MUST have an Instance Identifier Uniform Resource Name (URN) [RFC2141] that uniquely identifies the device. Using a URN gives the UA instance a persistent, unique name, and it's also an easy way to guarantee uniqueness within the AOR 🧁 This URN MUST be persistent across power cycles of the device. The instance ID MUST NOT change as the device moves from one network to another 🛜
A UA SHOULD create a Universally Unique Identifier (UUID) URN [RFC4122] as its instance-id. The UUID URN allows for non-centralized computation of a URN based on time, unique names (such as a MAC address), or a random number generator ✨
Note: A device like a "soft phone", when first installed, can generate a UUID [RFC4122] and then save it in persistent storage for all future use. For a device such as a "hard phone", which will only ever have a single SIP UA present, the UUID can include the MAC address and be generated at any time, because it is guaranteed that no other UUID is being generated at the same time on that physical device. This means the value of the time component of the UUID can be arbitrarily selected to be any time less than the time when the device was manufactured. A time of 0 (as shown in the example in Section 3.2) is perfectly legal, as long as the device knows no other UUIDs were generated at this time on this device.
If a URN scheme other than UUID is used, the UA MUST only use URNs for which an RFC (from the IETF stream) defines how the specific URN needs to be constructed and used in the "+sip.instance" Contact header field parameter for outbound behavior 📜
To convey its instance-id in both requests and responses, the UA includes a "sip.instance" media feature tag as a UA characteristic [RFC3840]. This media feature tag is encoded in the Contact header field as the "+sip.instance" Contact header field parameter. One case where a UA could prefer to omit the "sip.instance" media feature tag is when it's making an anonymous request, or when some other privacy concern requires that the UA not reveal its identity 🙈
Note: [RFC3840] defines equality rules for callee capabilities parameters, and according to that specification, the "sip.instance" media feature tag will be compared by case-sensitive string comparison. This means the URN will be encapsulated by angle brackets ("<" and ">") when it's placed within the quoted string value of the "+sip.instance" Contact header field parameter. The case-sensitive matching rules apply only to the generic usages defined in the callee capabilities [RFC3840] and the caller preferences [RFC3841] specifications. When the instance ID is used in this specification, it is "extracted" from the value in the "sip.instance" media feature tag. Thus, equality comparisons are performed using the rules for URN equality that are specific to the scheme in the URN. If the element performing the comparisons does not understand the URN scheme, it performs the comparisons using the lexical equality rules defined in [RFC2141]. Lexical equality could result in two URNs being considered unequal when they are actually equal. In this specific usage of URNs, the only element that provides the URN is the SIP UA instance identified by that URN. As a result, the UA instance has to provide lexically equivalent URNs in each registration it generates. This is likely to be normal behavior in any case; clients are not likely to modify the value of the instance ID so that it remains functionally equivalent to (yet lexicographically different from) previous registrations 💅
4.2. Registrations ✨
4.2.1. Initial Registrations ✨
okay so at configuration time, UAs grab one or more SIP URIs for the default outbound-proxy-set 🎀. This spec just assumes the set gets figured out by some configuration mechanism (there are a bunch of them), and future specs can add others, like using DNS to find this set 🧚. How the UA gets configured is totally outside the scope of this spec 💅. BUT a UA MUST support sets with at least two outbound proxy URIs, and it SHOULD support sets with up to four URIs 🫶.
For each outbound proxy URI in the set, the UAC SHOULD send a REGISTER request using that URI as the default outbound proxy 🦋. (The UA could also limit the number of flows it forms to conserve battery power, for example 🔋.) If the set has more than one URI, the UAC MUST send a REGISTER request to at least two of the default outbound proxies from the set 💜. UAs that support this specification MUST include the outbound option tag in a Supported header field in a REGISTER request 🌸. Each of these REGISTER requests will use a unique Call-ID 🍓. Forming the route set for the request is outside the scope of this document, but it typically results in sending the REGISTER so that the topmost Route header field contains a loose route to the outbound proxy URI ✨.
REGISTER requests, other than those described in Section 4.2.3, MUST include an instance-id media feature tag as specified in Section 4.1 🔥.
A UAC conforming to this specification MUST include, in the Contact header field, a reg-id parameter that is distinct from the other reg-id parameters used in other registrations that use the same +sip.instance Contact header field parameter and AOR 👑. Each one of these registrations will form a new flow from the UA to the proxy 🌈. The sequence of reg-id values does not have to be sequential, but it MUST be exactly the same sequence of reg-id values each time the UA instance power cycles or reboots, so that the reg-id values collide with the previously used ones. This is so the registrar can replace the older registrations 🙈.
Note: The UAC can situationally decide whether to request outbound behavior by including or omitting thereg-idContact header field parameter. For example, imagine the outbound-proxy-set contains two proxies in different domains, EP1 and EP2. If an outbound-style registration succeeded for a flow through EP1, the UA might decide to includeoutboundin itsRequireheader field when registering with EP2, in order to ensure consistency. Similarly, if the registration through EP1 did not support outbound, the UA might not register with EP2 at all. 🧠
The UAC MUST support the Path header [RFC3327] mechanism, and it indicates that support by including the path option-tag in a Supported header field value in its REGISTER requests 🛣️. Other than optionally examining the Path vector in the response, this is all that is required of the UAC to support Path 🎀.
The UAC examines successful registration responses for the presence of an outbound option-tag in a Require header field value. Presence of this option-tag indicates that the registrar is compliant with this specification, and that any edge proxies which needed to participate are also compliant 💖. If the registrar did not support outbound, the UA has potentially registered an un-routable contact 😭. It is the responsibility of the UA to remove any inappropriate Contacts 🧹.
If outbound registration succeeded, as indicated by the presence of the outbound option-tag in the Require header field of a successful registration response, the UA begins sending keep-alives as described in Section 4.4 💓.
Note: The UA needs to honor 503 (Service Unavailable) responses to registrations as described in [RFC3261] and [RFC3263]. In particular, implementors should note that when receiving a 503 (Service Unavailable) response with aRetry-Afterheader field, the UA is expected to wait the indicated amount of time and retry the registration. ARetry-Afterheader field value of0is valid and indicates the UA is expected to retry the REGISTER request immediately. Implementations need to ensure that when retrying the REGISTER request, they revisit the DNS resolution results so that the UA can select an alternate host from the one chosen the previous time the URI was resolved. ⏰
If the registering UA receives a 439 (First Hop Lacks Outbound Support) response to a REGISTER request, it MAY re-attempt registration without using the outbound mechanism (subject to local policy at the client) 🙃. If the client has one or more alternate outbound proxies available, it MAY re-attempt registration through such outbound proxies 🔁. See Section 11.6 for more information on the 439 response code 📖.
4.2.2. Subsequent REGISTER Requests 🔄
Registrations for refreshing a binding and for removing a binding use the same instance-id and reg-id values as the corresponding initial registration where the binding was added 🫧. Registrations that merely refresh an existing binding are sent over the same flow as the original registration where the binding was added 🌷.
If a re-registration is rejected with a recoverable error response, for example a 503 (Service Unavailable) containing a Retry-After header, the UAC SHOULD NOT tear down the corresponding flow if the flow uses a connection-oriented transport such as TCP 🙌. As long as "pongs" are received in response to "pings", the flow SHOULD be kept active until a non-recoverable error response is received 🏓. This prevents unnecessary closing and opening of connections, which is honestly such a relief 😮💨✨.
4.2.3. Third-Party Registrations 🕵️♀️
In an initial registration or re-registration, a UA MUST NOT include a reg-id header field parameter in the Contact header field if the registering UA is not the same instance as the UA referred to by the target Contact header field 🚫. (This practice is occasionally used to install forwarding policy into registrars 📬.)
A UAC also MUST NOT include an instance-id feature tag or reg-id Contact header field parameter in a request to un-register all Contacts (a single Contact header field value with the value of *) 🧺.
4.3. Sending Non-REGISTER Requests 📨
When a UAC is about to send a request, it first performs normal processing to select the next hop URI 🎯. The UA can use a variety of techniques to compute the route set and, accordingly, the next hop URI. Discussion of these techniques is outside the scope of this document 🗺️. UAs that support this specification SHOULD include the outbound option tag in a Supported header field in a request that is not a REGISTER request 🌟.
The UAC performs normal DNS resolution on the next hop URI (as described in [RFC3263]) to find a protocol, IP address, and port 🔍. For protocols that don't use TLS, if the UAC has an existing flow to this IP address and port with the correct protocol, then the UAC MUST use the existing connection 🔗. For TLS protocols, there MUST also be a match between the host production in the next hop and one of the URIs contained in the subjectAltName in the peer certificate 🔐. If the UAC cannot use one of the existing flows, then it SHOULD form a new flow by sending a datagram or opening a new connection to the next hop, as appropriate for the transport protocol 🌊.
Typically, a UAC using the procedures of this document and sending a dialog-forming request will want all subsequent requests in the dialog to arrive over the same flow 🧵. If the UAC is using a Globally Routable UA URI (GRUU) [RFC5627] that was instantiated using a Contact header field value that included an ob parameter, the UAC sends the request over the flow used for registration, and subsequent requests will arrive over that same flow 🏠. If the UAC is not using such a GRUU, then the UAC adds an ob parameter to its Contact header field value 🏷️. This will cause all subsequent requests in the dialog to arrive over the flow instantiated by the dialog-forming request. This case is typical when the request is sent prior to registration, such as in the initial subscription dialog for the configuration framework [CONFIG-FMWK] 🛠️.
Note: If the UAC wants a UDP flow to work through NATs or firewalls, it still needs to put therportparameter [RFC3581] in itsViaheader field value, and send from the port it is prepared to receive on 🚪. More general information about NAT traversal in SIP is described in [NAT-SCEN] 🌐.
4.4. Keep-Alives and Detecting Flow Failure 💖
Okay so keep-alives are the little "still here!" pings 🦋 that do two jobs: they refresh NAT/firewall bindings and they detect when a flow dies. Flows can fail for loads of reasons, like a NAT rebooting or an edge proxy crashing 💀, so keep-alives are how everyone finds out 🙈
As described in Section 4.2, a UA that registers will begin sending keep-alives after an appropriate registration response. A UA that does not register (for example, a PSTN gateway behind a firewall) can also send keep-alives under certain circumstances 🌸
Under specific circumstances, a UAC might be allowed to send STUN keep-alives even if the procedures in Section 4.2 were not completed, as long as there is an explicit indication that the target first-hop SIP node supports STUN keep-alives ✨ For example, this applies to a non-registering UA, or to a case where the UA registration succeeded but the response did not include the outbound option-tag in the Require header field.
Note: A UA can "always" send a double CRLF (a "ping") over connection-oriented transports, because this is already allowed by Section 7.5 of [RFC3261]. However, a UA that did not register using outbound registration cannot expect a CRLF in response (a "pong") unless the UA has an explicit indication that CRLF keep-alives are supported, as described in this section. Likewise, a UA that did not successfully register with outbound procedures needs explicit indication that the target first-hop SIP node supports STUN keep-alives before it can send any STUN messages 💅
A configuration option indicating keep-alive support for a specific target is considered an explicit indication. If these conditions are satisfied, the UA sends its keep-alives according to the same guidelines as those used when UAs register. Those guidelines are described below 🎀
The UA needs to detect when a specific flow fails 👀 It actively tries to detect failure by periodically sending keep-alive messages, using one of the techniques described in Sections 4.4.1 or 4.4.2. If a flow with a registration has failed, the UA follows the procedures in Section 4.2 to form a new flow to replace the failed one 🫶
When a successful registration response contains the Flow-Timer header field, the value of that header field is the number of seconds the server is prepared to wait without seeing keep-alives before it could consider the corresponding flow dead. The server waits a bit longer than the Flow-Timer value, which gives a grace period for transport delay 🧚 The UA MUST send keep-alives at least as often as this number of seconds. If the UA uses the server-recommended keep-alive frequency, it SHOULD send its keep-alives so that the interval between each keep-alive is randomly distributed between 80% and 100% of the server-provided time. For example, if the server suggests 120 seconds, the UA would send each keep-alive with a different frequency between 95 and 120 seconds 🔥
If no Flow-Timer header field was present in a register response for this flow, the UA can send keep-alives at its discretion. The sections below provide RECOMMENDED default values for these keep-alives 🍓
The client needs to perform normal [RFC3263] SIP DNS resolution on the URI from the outbound-proxy-set to pick a transport. Once a transport is selected, the UA selects the keep-alive approach that is recommended for that transport ✨
Section 4.4.1 describes a keep-alive mechanism for connection-oriented transports such as TCP or SCTP. Section 4.4.2 describes a keep-alive mechanism for connection-less transports such as UDP. Support for other transports, such as DCCP [RFC4340], is for further study 🌈
4.4.1. Keep-Alive with CRLF 🌊
This approach MUST only be used with connection-oriented transports such as TCP or SCTP. It MUST NOT be used with connection-less transports such as UDP 🚫
A User Agent that forms flows checks whether the configured URI it is connecting to resolves to a connection-oriented transport (for example, TCP and TLS over TCP) 🔍
For this mechanism, the client "ping" is a double-CRLF sequence, and the server "pong" is a single CRLF, as defined in the ABNF below:
CRLF = CR LF
double-CRLF = CR LF CR LF
CR = %x0D
LF = %x0AThe "ping" and "pong" need to be sent between SIP messages. They cannot be sent in the middle of a SIP message 🙅 If sending over TLS, the CRLFs are sent inside the TLS protected channel. If sending over a SigComp [RFC3320] compressed data stream, the CRLF keep-alives are sent inside the compressed stream, and the double CRLF is considered a single SigComp message. The specific mechanism for representing these characters is an implementation-specific matter, to be handled by the SigComp compressor at the sending end 🧠
If a pong is not received within 10 seconds after sending a ping (or immediately after processing any incoming message received when that 10 seconds expires), then the client MUST treat the flow as failed. Clients MUST support this CRLF keep-alive 😤
Note: This 10-second timeout was selected to be long enough to give a server plenty of time to send a response, even if the server is temporarily busy with an administrative activity. At the same time, it was selected to be small enough that a UA registered to two redundant servers with unremarkable hardware uptime could still easily provide very high levels of overall reliability. Although some Internet protocols are designed for round-trip times over 10 seconds, SIP for real-time communications is not really usable in these types of environments, as users often abandon calls before waiting much more than a few seconds 📞💀
When a Flow-Timer header field is not provided in the most recent successful registration response, choosing the keep-alive frequency is mainly a trade-off between battery usage and availability 🔋 The UA MUST select a random number between a fixed or configurable upper bound and a lower bound, where the lower bound is 20% less than the upper bound. The fixed upper bound, or the default configurable upper bound, SHOULD be 120 seconds (95 seconds for the lower bound) where battery power is not a concern, and 840 seconds (672 seconds for the lower bound) where battery power is a concern. The random number will be different for each keep-alive "ping" 🎲
Note on selection of time values: The 120-second upper bound was chosen based on the idea that, for a good user experience, failures will normally be detected in this amount of time and a new connection will be set up. The 14-minute upper bound for battery-powered devices was selected based on NATs with TCP timeouts as low as 15 minutes. Operators who wish to change the relationship between load on servers and the expected time that a user might not receive inbound communications will probably adjust this time. The 95-second lower bound was chosen so that the jitter introduced will result in a relatively even load on the servers after 30 minutes 🧁
4.4.2. Keep-Alive with STUN 🛰️
This approach MUST only be used with connection-less transports, such as UDP. It MUST NOT be used for connection-oriented transports such as TCP and SCTP 🙅♀️
A User Agent that forms flows checks whether the configured URI it is connecting to resolves to use the UDP transport. The UA can periodically perform keep-alive checks by sending STUN [RFC5389] Binding Requests over the flow, as described in Section 8. Clients MUST support STUN-based keep-alives 💜
When a Flow-Timer header field is not included in a successful registration response, the time between each keep-alive request SHOULD be a random number between 24 and 29 seconds 🎀
Note on selection of time values: The upper bound of 29 seconds was selected because many NATs have UDP timeouts as low as 30 seconds. The 24-second lower bound was selected so that, after 10 minutes, the jitter introduced by different timers will make the keep-alive requests unsynchronized, which evenly spreads the load on the servers. Note that short NAT timeouts with UDP have a negative impact on battery life 🔋
If a STUN Binding Error Response is received, or if no Binding Response is received after 7 retransmissions (16 times the STUN "RTO" timer, where RTO is an estimate of round-trip time), the UA considers the flow failed. If the XOR-MAPPED-ADDRESS in the STUN Binding Response changes, the UA MUST treat this event as a failure on the flow 💥
4.5. Flow Recovery 🔁
When a flow used for registration (through a particular URI in the outbound-proxy-set) fails, the UA needs to form a new flow to replace the old one, and replace any registrations that were previously sent over that flow. Each new registration MUST have the same reg-id value as the registration it replaces 🫶 This is done in much the same way as forming a brand new flow, as described in Section 4.2. However, if forming this flow fails, the UA needs to wait a certain amount of time before retrying to form a flow to this particular next hop ⏳
The amount of time to wait depends on whether the previous attempt at establishing a flow was successful. For the purposes of this section, a flow is considered successful if outbound registration succeeded and, if keep-alives are in use on this flow, at least one subsequent keep-alive response was received ✅
The number of seconds to wait is computed in the following way. If all of the flows to every URI in the outbound proxy set have failed, the base-time is set to a lower value (with a default of 30 seconds). Otherwise, in the case where at least one of the flows has not failed, the base-time is set to a higher value (with a default of 90 seconds). The upper-bound wait time (W) is computed by taking two raised to the power of the number of consecutive registration failures for that URI, multiplying this by the base-time, up to a configurable maximum time (with a default of 1800 seconds) 🧮
W = min (max-time, (base-time * (2 ^ consecutive-failures)))These times MAY be configurable in the UA. The three times are:
max-time, with a default of 1800 secondsbase-time(if all failed), with a default of 30 secondsbase-time(if all have not failed), with a default of 90 seconds
For example, if the base-time is 30 seconds and there were three failures, then the upper-bound wait time is min(1800, 30*(2^3)), or 240 seconds. The actual amount of time the UA waits before retrying registration (the retry delay time) is computed by selecting a uniform random time between 50 and 100% of the upper-bound wait time. The UA MUST wait for at least the value of the retry delay time before trying another registration to form a new flow for that URI. A 503 response to an earlier failed registration attempt with a Retry-After header field value may cause the UA to wait longer 🕰️
To be explicitly clear on the boundary conditions: when the UA boots, it immediately tries to register. If this fails and no registration on other flows succeeds, the first retry happens somewhere between 30 and 60 seconds after the failure of the first registration request. If the number of consecutive-failures is large enough that the maximum of 1800 seconds is reached, the UA will keep trying indefinitely, with a random time of 15 to 30 minutes between each attempt 🌟
5. Edge Proxy Procedures ✨
5.1. Processing Register Requests 💖
okay so, when an edge proxy gets a registration request with a reg-id header field parameter in the Contact header field, it has to figure out whether it (the edge proxy) needs to be visited for any later requests headed to the User Agent named in that Contact header field. 🧚 If the edge proxy is the first hop, as the Via header field shows, it MUST insert its URI into a Path header field value as described in [RFC3327]. If it isn't the first hop, it might still add itself to the Path header based on local policy. ✨
It gets even more intense if the edge proxy is the first SIP node after the UAC. In that case, the edge proxy either MUST store a "flow token" (holding information about the flow from the previous hop) in its Path URI, or reject the request. 😭 The flow token MUST be an identifier that is unique to this network flow. The flow token MAY be placed in the userpart of the URI. On top of that, the first node MUST include an ob URI parameter in its Path header field value. If the edge proxy is not the first SIP node after the UAC, it MUST NOT place an ob URI parameter in a Path header field value. The edge proxy can tell whether it's the first hop by checking the Via header field. 🦋
5.2. Generating Flow Tokens 🌸
so there's a super simple way to meet the flow token requirement from Section 5.1, which is to keep a mapping between an incrementing counter and the connection info. 🙈 Honestly though, it's not practical. The edge proxy would have to keep an unreasonable amount of state, it's unclear when that state could ever be removed, and things get messy if the proxy crashes and loses the counter's value. 💀 Here's a stateless example instead. A proxy can use any algorithm it wants, as long as the flow token is unique to a flow, the flow can be recovered from the token, and attackers can't modify the token. 💅
Example Algorithm: When the proxy boots, it selects a 20-octet
crypto random key called K that only the edge proxy knows. A byte
array, called S, is formed that contains the following information
about the flow the request was received on: an enumeration
indicating the protocol, the local IP address and port, the remote
IP address and port. The HMAC of S is computed using the key K
and the HMAC-SHA1-80 algorithm, as defined in [RFC2104]. The
concatenation of the HMAC and S are base64 encoded, as defined in
[RFC4648], and used as the flow identifier. When using IPv4
addresses, this will result in a 32-octet identifier.5.3. Forwarding Non-REGISTER Requests 🎀
when an edge proxy gets a request, it runs normal routing procedures, plus a few extra bits. ✨ If the edge proxy is the host in the topmost Route header field value, and that Route header field value contains a flow token, the proxy follows the procedures in this section. Otherwise, the edge proxy skips this section, removes itself from the Route header field, and keeps processing the request. 👑
The proxy decodes the flow token and compares the flow in it with the source of the request. That tells it whether this is an "incoming" or "outgoing" request. 🫶
If the flow in the flow token identified by the topmost Route header field value matches the source IP address and port of the request, it's an "outgoing" request. Otherwise, it's an "incoming" request. 🌈
5.3.1. Processing Incoming Requests 🍓
if the Route header value has an ob URI parameter, the Route header was probably copied from the Path header in a registration. 🔥 And if the Route header value has an ob URI parameter and the request is a new dialog-forming request, the proxy has to adjust the route set. That way, later requests in the dialog can get delivered over a valid flow to the UA instance identified by the flow token. 🦋
Note: A simple approach to satisfy this requirement is for the proxy to add aRecord-Routeheader field value that contains the flow-token, by copying the URI in theRouteheader minus theobparameter.
Next, whether or not the Route header field had an ob URI parameter, the proxy removes the Route header field value and forwards the request over the 'logical flow' identified by the flow token. That logical flow is known to deliver data to the specific target UA instance. 💜 If the flow token has been tampered with, the proxy SHOULD send a 403 (Forbidden) response. If the flow no longer exists, the proxy SHOULD send a 430 (Flow Failed) response to the request. 😭
Proxies that used the example algorithm from Section 5.2 to form a flow token follow the steps below to find the correct flow. To decode the flow token, take the flow identifier from the user portion of the URI and base64 decode it. Then verify the HMAC by recomputing it and checking that it matches. If the HMAC isn't correct, the request has been tampered with. 🔐
5.3.2. Processing Outgoing Requests 🌷
for mid-dialog requests to work with outbound UAs, the requests need to be forwarded over some valid flow to the right UA instance. 💖 If the edge proxy receives an outgoing dialog-forming request, it can check for the ob URI parameter in the UAC's Contact URI (or topmost Route header field) to figure out whether it needs to help with mid-dialog request routing. 🧠
Implementation note: Specific procedures at the edge proxy to ensure that mid-dialog requests are routed over an existing flow are not part of this specification. However, an approach such as having the edge proxy add a Record-Route header with a flow token is one way to ensure that mid-dialog requests are routed over the correct flow.
5.4. Edge Proxy Keep-Alive Handling 🫧
every edge proxy that follows this specification MUST implement support for STUN NAT keep-alives on its SIP UDP ports, as described in Section 8. 🛡️
when a server gets a double CRLF sequence between SIP messages on a connection-oriented transport like TCP or SCTP, it MUST immediately respond with a single CRLF over the same connection. 🌊
the last proxy to forward a successful registration response to a UA MAY include a Flow-Timer header field if the response has the outbound option-tag in a Require header field value. 🎟️ A proxy would send a Flow-Timer if it wants to catch flow failures early and take action, like logging alarms or giving alternative treatment when incoming requests for the UA arrive. ⏰ The server MUST wait for longer than the Flow-Timer so there's a grace period for transport delay. 🌟
6. Registrar Procedures 💅
okay so this spec is literally updating what a binding means, like from [RFC3261], Section 10 and [RFC3327], Section 5.3 ✨
Registrars that implement this spec MUST support the Path header mechanism [RFC3327]. no skipping this one bestie 🫶
When a registrar gets a REGISTER request, it MUST check its Via header field to see if it's the first hop or not. If it's not the first hop, it MUST look at the Path header of the request. If the Path header field is missing, or it's there but the first URI doesn't have an "ob" URI parameter, then outbound processing MUST NOT be applied to the registration. In that case: if the REGISTER request has both the reg-id and the outbound option tag in a Supported header field, the registrar MUST respond with a 439 (First Hop Lacks Outbound Support) response. otherwise, the registrar MUST ignore the "reg-id" parameter of the Contact header. See Section 11.6 for more on the 439 response code 🙈
A Contact header field value with an +sip.instance media feature tag but no "reg-id" header field parameter is valid (this combo creates a GRUU, as described in the GRUU spec [RFC5627]) 💜 but one with a reg-id and no +sip.instance is NOT valid. if the registrar processes a Contact header field value with a reg-id but no instance-id, it just ignores the reg-id parameter.
A registration with a "reg-id" header field parameter and a non-zero expiration is used to register a single UA instance over a single flow. it can also de-register any Contact header fields with zero expiration. so if the Contact header field has more than one value with a non-zero expiration, and any of those values have a "reg-id" Contact header field parameter, the entire registration SHOULD be rejected with a 400 (Bad Request) response. the reason it's a SHOULD and not a MUST is that [RFC3261] lets the receiver squelch (not respond to) excessively malformed or malicious messages 🛡️
If the Contact header didn't have a "reg-id" Contact header field parameter, or if that parameter was ignored (like above), the registrar MUST NOT include the outbound option-tag in the Require header field of its response.
The registrar MUST be ready to receive, at the same time for the same AOR, some registrations that use instance-id and reg-id and some that don't. the registrar MAY be set up with local policy to reject any registrations that don't include the instance-id and reg-id, or with Path header field values that don't contain the "ob" URI parameter. if the Contact header field doesn't have a "+sip.instance" Contact header field parameter, the registrar processes the request using the Contact binding rules in [RFC3261] ✨
When a "+sip.instance" Contact header field parameter and a "reg-id" Contact header field parameter are both there in a Contact header field of a REGISTER request (after the Contact header validation above), the binding is between an AOR and the combo of the instance-id (from the "+sip.instance" parameter) and the value of the "reg-id" parameter. the registrar MUST store in the binding the Contact URI, all the Contact header field parameters, and any Path header field values. (even though the Contact URI isn't used for binding comparisons, the authoritative proxy still needs it to form the target set 🎯) As long as the UAC included an outbound option-tag (defined in Section 11.4) in a Supported header field value in the REGISTER request, the registrar MUST include the outbound option-tag in a Require header field value in its response to that REGISTER request 🔥
If the UAC has a direct flow with the registrar, the registrar MUST store enough info to uniquely identify the network flow the request arrived on. for common OSes with TCP, this is typically just the handle to the file descriptor, which becomes invalid if the TCP session gets closed. for common OSes with UDP, this is typically the file descriptor for the local socket that got the request, the local interface, and the IP address and port number of the remote side that sent it. the registrar MAY store this info by adding itself to the Path header field with an appropriate flow token 🧚
If the registrar gets a re-registration for a specific combo of AOR, instance-id and reg-id values, the registrar MUST update any info that uniquely identifies the network flow the request arrived on if that info has changed. it SHOULD also update the time the binding was last updated 🕰️
to be compliant with this spec, registrars that can receive SIP requests directly from a UAC without intervening edge proxies MUST implement the same keep-alive mechanisms as edge proxies (Section 5.4). Registrars with a direct flow with a UA MAY include a Flow-Timer header in a 2xx class registration response that includes the outbound option-tag in the Require header 💖
7. Authoritative Proxy Procedures: Forwarding Requests 🦋
so when a proxy uses the location service to look up a registration binding and then forwards a request to a particular contact, it picks a contact the normal way, with a few extra rules:
- the proxy MUST NOT put more than one contact with the same AOR and instance-id in the target set at a time 🙅♀️
- if a request for a particular AOR and instance-id fails with a 430 (Flow Failed) response, the proxy SHOULD swap the failed branch for another target (if one is available) with the same AOR and instance-id, but a different reg-id 🔄
- if the proxy gets a final response from a branch that isn't a 408 (Request Timeout) or 430 (Flow Failed) response, the proxy MUST NOT forward the same request to another target representing the same AOR and instance-id. the targeted instance already gave its answer, periodt 💅
the proxy uses the next-hop target of the message and the value of any stored Path header field vector in the registration binding to decide how to forward and fill in the Route header in the request. if the proxy is co-located with the registrar and has stored info about the flow to the UA that made the binding, then the proxy MUST send the request over the same 'logical flow' saved with the binding. that flow is known to deliver data to the specific target UA instance's network flow that was saved with the binding 🌸
Implementation note: Typically this means that for TCP, the request is sent on the same TCP socket that received the REGISTER request. For UDP, the request is sent from the same local IP address and port over which the registration was received, to the same IP address and port from which the REGISTER was received.
if a proxy or registrar gets info from the network that says no future messages will be delivered on a specific flow, then the proxy MUST invalidate all the bindings in the target set that use that flow (regardless of AOR). examples are a TCP socket closing, or getting a destination unreachable ICMP error on a UDP flow 💀 similarly, if a proxy closes a file descriptor, it MUST invalidate all the bindings in the target set with flows that use that file descriptor.
8. STUN Keep-Alive Processing 🌈
this section describes changes to the SIP transport layer that let SIP and STUN [RFC5389] Binding Requests get mixed over the same flow. this is a brand new STUN usage, iconic behavior ✨ the STUN messages verify that connectivity is still available over a UDP flow, and they provide periodic keep-alives. these STUN keep-alives are always sent to the next SIP hop. STUN messages are not delivered end-to-end, so don't expect them to go all the way 🙃
the only STUN messages this usage requires are Binding Requests, Binding Responses, and Binding Error Responses. the UAC sends Binding Requests over the same UDP flow it uses for sending SIP messages. these Binding Requests don't require any STUN attributes. the matching Binding Responses don't require any STUN attributes except the XOR-MAPPED-ADDRESS. the UAS, proxy, or registrar responds to a valid Binding Request with a Binding Response that MUST include the XOR-MAPPED-ADDRESS attribute 🎀
if a server that follows this section gets SIP requests on a given interface and UDP port, it MUST also provide a limited version of a STUN server on the same interface and UDP port 🫶
Note: It is easy to distinguish STUN and SIP packets sent over UDP, because the first octet of a STUN Binding method has a value of 0 or 1, while the first octet of a SIP message is never a 0 or 1.
because sending and receiving binary STUN data on the same ports used for SIP is a big, non-backwards-compatible change to [RFC3261], this section requires a bunch of checks before a SIP node sends STUN messages to another SIP node. if a SIP node sends STUN requests anyway (say, from bad config) despite these warnings, the node could get blacklisted for UDP traffic 😭
a SIP node MUST NOT send STUN requests over a flow unless it has an explicit indication that the target next-hop SIP server claims to support this spec. UACs MUST NOT use an ambiguous config option like "Work through NATs?" or "Do keep-alives?" to imply next-hop STUN support 🙅♀️ a UAC MAY use the presence of an "ob" URI parameter in the Path header in a registration response as an indication that its first edge proxy supports the keep-alives defined in this document 🧚
Note: Typically, a SIP node first sends a SIP request and waits to receive a 2xx class response over a flow to a new target destination, before sending any STUN messages. When scheduled for the next NAT refresh, the SIP node sends a STUN request to the target.
once a flow is established, failure of a STUN request (including its retransmissions) counts as a failure of the underlying flow. for SIP over UDP flows, if the XOR-MAPPED-ADDRESS returned over the flow changes, that means the underlying connectivity has changed, and it's considered a flow failure 🚨
the SIP keep-alive STUN usage requires no backwards compatibility with [RFC3489] 💅
8.1. Use with SigComp 🧠
when STUN is used together with SigComp [RFC3320] compressed SIP messages over the same flow, the STUN messages are just sent uncompressed, "outside" of SigComp. this works by multiplexing STUN messages with SigComp messages, checking the two topmost bits of the message. these bits are always one for SigComp, or zero for STUN ✨
Note: All SigComp messages contain a prefix (the five most significant bits of the first byte are set to one) that does not occur in UTF-8 [RFC3629] encoded text messages, so for applications that use this encoding (or ASCII encoding) it is possible to multiplex uncompressed application messages and SigComp messages on the same UDP port. The most significant two bits of every STUN Binding method are both zeroes. This, combined with the magic cookie, aids in differentiating STUN packets from other protocols when STUN is multiplexed with other protocols on the same port.
9. Example Message Flow ✨
Okay bestie, time for a call-flow walkthrough 🎀 This one shows off most of the stuff we've been talking about. To keep things readable, the Via, Content-Length, and Max-Forwards headers are left out of a lot of these examples 💅
In these examples, "EP1" and "EP2" are outbound proxies, and "Proxy" is the authoritativeProxy 🦋
The section is split into independent call flows, but they're lined up in order, like a hypothetical sequence of calls 🧚
9.1. Subscription to Configuration Package
If the outbound proxy set is already set up on Bob's UA, you can totally skip this part 🙈 But if the set gets learned through the configuration package, Bob's UA sends a SUBSCRIBE for the UA profile configuration package [CONFIG-FMWK]. This one's a poll (Expires is zero) 💜 After the NOTIFY comes back, Bob's UA grabs the external configuration over HTTPS (not shown) and gets a config file with the outbound-proxy-set "sip:ep1.example.com;lr" and "sip:ep2.example.com;lr" ✨
[----example.com domain-------------------------]
Bob EP1 EP2 Proxy Config
| | | | |
1)|SUBSCRIBE->| | | |
2)| |---SUBSCRIBE Event: ua-profile ->|
3)| |<--200 OK -----------------------|
4)|<--200 OK--| | | |
5)| |<--NOTIFY------------------------|
6)|<--NOTIFY--| | | |
7)|---200 OK->| | | |
8)| |---200 OK ---------------------->|
| | | | |Also, in this example the DNS server is set up so that sip:example.com resolves to EP1 and EP2 🌸
Here's Example Message #1:
SUBSCRIBE sip:00000000-0000-1000-8000-AABBCCDDEEFF@example.com
SIP/2.0
Via: SIP/2.0/TCP 192.0.2.2;branch=z9hG4bKnlsdkdj2
Max-Forwards: 70
From: <anonymous@example.com>;tag=23324
To: <sip:00000000-0000-1000-8000-AABBCCDDEEFF@example.com>
Call-ID: nSz1TWN54x7My0GvpEBj
CSeq: 1 SUBSCRIBE
Event: ua-profile ;profile-type=device
;vendor="example.com";model="uPhone";version="1.1"
Expires: 0
Supported: path, outbound
Accept: message/external-body, application/x-uPhone-config
Contact: <sip:192.0.2.2;transport=tcp;ob>
;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
Content-Length: 0In message #2, EP1 adds this Record-Route header 🦋
Record-Route:
<sip:GopIKSsn0oGLPXRdV9BAXpT3coNuiGKV@ep1.example.com;lr>In message #5, the configuration server sends a NOTIFY with an external URL so Bob can fetch his configuration. The NOTIFY has a Subscription-State header that ends the subscription, so it's giving closure 😭
Message #5
NOTIFY sip:192.0.2.2;transport=tcp;ob SIP/2.0
Via: SIP/2.0/TCP 192.0.2.5;branch=z9hG4bKn81dd2
Max-Forwards: 70
To: <anonymous@example.com>;tag=23324
From: <sip:00000000-0000-1000-8000-AABBCCDDEEFF@example.com>;tag=0983
Call-ID: nSz1TWN54x7My0GvpEBj
CSeq: 1 NOTIFY
Route: <sip:GopIKSsn0oGLPXRdV9BAXpT3coNuiGKV@ep1.example.com;lr>
Subscription-State: terminated;reason=timeout
Event: ua-profile
Content-Type: message/external-body; access-type="URL"
;expiration="Thu, 01 Jan 2009 09:00:00 UTC"
;URL="http://example.com/uPhone.cfg"
;size=9999;hash=10AB568E91245681AC1B
Content-Length: 0EP1 receives this NOTIFY, strips off the Route header, pulls out the flow-token, works out the correct flow, and forwards the request (message #6) over that flow to Bob 🫶
Bob's UA fetches the configuration file and learns the outbound proxy set 🎉
9.2. Registration
Now that Bob's UA is configured with the outbound-proxy-set, whether through configuration or using the configuration framework procedures from the previous section, Bob's UA sends REGISTER requests through each edge proxy in the set 💖 Once the registrations succeed, Bob's UA starts sending CRLF keep-alives about every 2 minutes. Main character energy ✨
Bob EP1 EP2 Proxy Alice
| | | | |
9)|-REGISTER->| | | |
10)| |---REGISTER-->| |
11)| |<----200 OK---| |
12)|<-200 OK---| | | |
13)|----REGISTER---->| | |
14)| | |--REG-->| |
15)| | |<-200---| |
16)|<----200 OK------| | |
| | | | |
| about 120 seconds later... |
| | | | |
17)|--2CRLF--->| | | |
18)|<--CRLF----| | | |
19)|------2CRLF----->| | |
20)|<------CRLF------| | |
| | | | |In message #9, Bob's UA sends its first registration through the first edge proxy in the outbound-proxy-set by including a loose route 🧚 The UA puts an instance-id and reg-id in its Contact header field value. Also, peep the option-tags in the Supported header 👀
Message #9
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/TCP 192.0.2.2;branch=z9hG4bKnashds7
Max-Forwards: 70
From: Bob <sip:bob@example.com>;tag=7F94778B653B
To: Bob <sip:bob@example.com>
Call-ID: 16CB75F21C70
CSeq: 1 REGISTER
Supported: path, outbound
Route: <sip:ep1.example.com;lr>
Contact: <sip:bob@192.0.2.2;transport=tcp>;reg-id=1
;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
Content-Length: 0Message #10 is basically the same 💅 EP1 removes the Route header field value, decrements Max-Forwards, and adds its Via header field value. Since EP1 is the first edge proxy, it adds a Path header with a flow token and includes the "ob" parameter 🦋
Path: <sip:VskztcQ/S8p4WPbOnHbuyh5iJvJIW3ib@ep1.example.com;lr;ob>Since the response to the REGISTER (message #11) contains the outbound option-tag in the Require header field, Bob's UA knows that the registrar used outbound binding rules 🔥 The response also includes the currently active Contacts, plus the Path for the current registration.
Message #11
SIP/2.0 200 OK
Via: SIP/2.0/TCP 192.0.2.15;branch=z9hG4bKnuiqisi
Via: SIP/2.0/TCP 192.0.2.2;branch=z9hG4bKnashds7
From: Bob <sip:bob@example.com>;tag=7F94778B653B
To: Bob <sip:bob@example.com>;tag=6AF99445E44A
Call-ID: 16CB75F21C70
CSeq: 1 REGISTER
Supported: path, outbound
Require: outbound
Contact: <sip:bob@192.0.2.2;transport=tcp>;reg-id=1;expires=3600
;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
Path: <sip:VskztcQ/S8p4WPbOnHbuyh5iJvJIW3ib@ep1.example.com;lr;ob>
Content-Length: 0The second registration through EP2 (message #13) is similar, except the Call-ID has changed, the reg-id is 2, and the Route header goes through EP2 👑
Message #13
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/TCP 192.0.2.2;branch=z9hG4bKnqr9bym
Max-Forwards: 70
From: Bob <sip:bob@example.com>;tag=755285EABDE2
To: Bob <sip:bob@example.com>
Call-ID: E05133BD26DD
CSeq: 1 REGISTER
Supported: path, outbound
Route: <sip:ep2.example.com;lr>
Contact: <sip:bob@192.0.2.2;transport=tcp>;reg-id=2
;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
Content-Length: 0Likewise, in message #14, EP2 adds a Path header with a flow token and the "ob" parameter 🌈
Path: <sip:wazHDLdIMtUg6r0I/oRZ15zx3zHE1w1Z@ep2.example.com;lr;ob>Message #16 tells Bob's UA that the outbound registration worked, and shows both Contacts. Note that only the Path for the current registration comes back 🍓
Message #16
SIP/2.0 200 OK
Via: SIP/2.0/TCP 192.0.2.2;branch=z9hG4bKnqr9bym
From: Bob <sip:bob@example.com>;tag=755285EABDE2
To: Bob <sip:bob@example.com>;tag=49A9AD0B3F6A
Call-ID: E05133BD26DD
Supported: path, outbound
Require: outbound
CSeq: 1 REGISTER
Contact: <sip:bob@192.0.2.2;transport=tcp>;reg-id=1;expires=3600
;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
Contact: <sip:bob@192.0.2.2;transport=tcp>;reg-id=2;expires=3600
;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
Path: <sip:wazHDLdIMtUg6r0I/oRZ15zx3zHE1w1Z@ep2.example.com;lr;ob>
Content-Length: 09.3. Incoming Call and Proxy Crash 💀
Okay so picture this, bestie 🎀 After registration, EP1 crashes and reboots. Bob's UA hasn't noticed yet that its flow to EP1 stopped responding, and right in that gap Alice calls Bob 📞. Bob's authoritative proxy tries the flow to EP1 first, but EP1 doesn't have a flow to Bob anymore, so it sends back a 430 (Flow Failed) response. The proxy deletes the stale registration and tries the next binding for the same instance ✨
Bob EP1 EP2 Proxy Alice
| | | | |
| CRASH X | | |
| Reboot | | |
| | | | |
21)| | | |<-INVITE-|
22)| |<---INVITE----| |
23)| |----430------>| |
24)| | |<-INVITE| |
25)|<---INVITE-------| | |
26)|----200 OK------>| | |
27)| | |200 OK->| |
28)| | | |-200 OK->|
29)| | |<----------ACK----|
30)|<---ACK----------| | |
| | | | |
31)| | |<----------BYE----|
32)|<---BYE----------| | |
33)|----200 OK------>| | |
34)| | |--------200 OK--->|
| | | | |Message #21
INVITE sip:bob@example.com SIP/2.0
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@a.example>;tag=02935
Call-ID: klmvCxVWGp6MxJp2T2mb
CSeq: 1 INVITEBob's proxy rewrites the Request-URI to the Contact URI used in Bob's registration, and puts the path for one of the registrations towards Bob's UA instance into a Route header field. That Route goes through EP1 🛣️
Message #22
INVITE sip:bob@192.0.2.2;transport=tcp SIP/2.0
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@a.example>;tag=02935
Call-ID: klmvCxVWGp6MxJp2T2mb
CSeq: 1 INVITE
Route: <sip:VskztcQ/S8p4WPbOnHbuyh5iJvJIW3ib@ep1.example.com;lr;ob>Since EP1 just rebooted, it doesn't have the flow described in the flow token. It returns a 430 (Flow Failed) response 💅
Message #23
SIP/2.0 430 Flow Failed
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@a.example>;tag=02935
Call-ID: klmvCxVWGp6MxJp2T2mb
CSeq: 1 INVITEThe proxy deletes the binding for this path and tries the INVITE again, this time through EP2 🔁
Message #24
INVITE sip:bob@192.0.2.2;transport=tcp SIP/2.0
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@a.example>;tag=02935
Call-ID: klmvCxVWGp6MxJp2T2mb
CSeq: 1 INVITE
Route: <sip:wazHDLdIMtUg6r0I/oRZ15zx3zHE1w1Z@ep2.example.com;lr;ob>In message #25, EP2 needs to add a Record-Route header field value so that any later in-dialog messages from Alice's UA reach Bob's UA. EP2 can tell it needs to Record-Route because the request is dialog-forming and the Route header had a flow token plus an "ob" parameter. That Record-Route info gets passed back to Alice's UA in the responses (messages #26, 27, and 28) 🦋
Message #25
INVITE sip:bob@192.0.2.2;transport=tcp SIP/2.0
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@a.example>;tag=02935
Call-ID: klmvCxVWGp6MxJp2T2mb
CSeq: 1 INVITE
Record-Route:
<sip:wazHDLdIMtUg6r0I/oRZ15zx3zHE1w1Z@ep2.example.com;lr>Message #26
SIP/2.0 200 OK
To: Bob <sip:bob@example.com>;tag=skduk2
From: Alice <sip:alice@a.example>;tag=02935
Call-ID: klmvCxVWGp6MxJp2T2mb
CSeq: 1 INVITE
Record-Route:
<sip:wazHDLdIMtUg6r0I/oRZ15zx3zHE1w1Z@ep2.example.com;lr>At this point, both UAs have the right route-set for the dialog, so any later requests in this dialog route correctly 🎉 For example, the ACK in message #29 goes straight from Alice's UA to EP2. The BYE in message #31 uses the same route-set 💜
Message #29
ACK sip:bob@192.0.2.2;transport=tcp SIP/2.0
To: Bob <sip:bob@example.com>;tag=skduk2
From: Alice <sip:alice@a.example>;tag=02935
Call-ID: klmvCxVWGp6MxJp2T2mb
CSeq: 1 ACK
Route: <sip:wazHDLdIMtUg6r0I/oRZ15zx3zHE1w1Z@ep2.example.com;lr>Message #31
BYE sip:bob@192.0.2.2;transport=tcp SIP/2.0
To: Bob <sip:bob@example.com>;tag=skduk2
From: Alice <sip:alice@a.example>;tag=02935
Call-ID: klmvCxVWGp6MxJp2T2mb
CSeq: 2 BYE
Route: <sip:wazHDLdIMtUg6r0I/oRZ15zx3zHE1w1Z@ep2.example.com;lr>9.4. Re-Registration 🔄
Somewhat later, Bob's UA sends keep-alives to both of its edge proxies, but it notices that the flow with EP1 has failed. So Bob's UA re-registers through EP1 using the same reg-id and Call-ID it used before 🫶
Bob EP1 EP2 Proxy Alice
| | | | |
35)|------2CRLF----->| | |
36)|<------CRLF------| | |
37)|--2CRLF->X | | | |
| | | | |
38)|-REGISTER->| | | |
39)| |---REGISTER-->| |
40)| |<----200 OK---| |
41)|<-200 OK---| | | |
| | | | |Message #38
REGISTER sip:example.com SIP/2.0
From: Bob <sip:bob@example.com>;tag=7F94778B653B
To: Bob <sip:bob@example.com>
Call-ID: 16CB75F21C70
CSeq: 2 REGISTER
Supported: path, outbound
Route: <sip:ep1.example.com;lr>
Contact: <sip:bob@192.0.2.2;transport=tcp>;reg-id=1
;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"In message #39, EP1 inserts a Path header with a brand new flow token ✨
Path: <sip:3yJEbr1GYZK9cPYk5Snocez6DzO7w+AX@ep1.example.com;lr;ob>9.5. Outgoing Call 📞💖
Finally, Bob makes an outgoing call to Alice 🥳 Bob's UA includes an "ob" parameter in its Contact URI in message #42. EP1 adds a Record-Route with a flow token in message #43. The route-set comes back to Bob in the responses (messages #45, 46, and 47), and then either Bob or Alice can send in-dialog requests. Main character energy 👑
Bob EP1 EP2 Proxy Alice
| | | | |
42)|--INVITE-->| | | |
43)| |---INVITE---->| |
44)| | | |-INVITE->|
45)| | | |<--200---|
46)| |<----200 OK---| |
47)|<-200 OK---| | | |
48)|--ACK----->| | | |
49)| |-----ACK--------------->|
| | | | |
50)|-- BYE---->| | | |
51)| |-----------BYE--------->|
52)| |<----------200 OK-------|
53)|<--200 OK--| | | |
| | | | |Message #42
INVITE sip:alice@a.example SIP/2.0
From: Bob <sip:bob@example.com>;tag=ldw22z
To: Alice <sip:alice@a.example>
Call-ID: 95KGsk2V/Eis9LcpBYy3
CSeq: 1 INVITE
Route: <sip:ep1.example.com;lr>
Contact: <sip:bob@192.0.2.2;transport=tcp;ob>In message #43, EP1 adds the following Record-Route header.
Record-Route:
<sip:3yJEbr1GYZK9cPYk5Snocez6DzO7w+AX@ep1.example.com;lr>When EP1 gets the BYE (message #50) from Bob's UA, it can tell the request is an "outgoing" one (because the source of the request matches the flow in the flow token). So it just deletes its Route header field value and forwards the request on to Alice's UA 🚀
Message #50
BYE sip:alice@a.example SIP/2.0
From: Bob <sip:bob@example.com>;tag=ldw22z
To: Alice <sip:alice@a.example>;tag=plqus8
Call-ID: 95KGsk2V/Eis9LcpBYy3
CSeq: 2 BYE
Route: <sip:3yJEbr1GYZK9cPYk5Snocez6DzO7w+AX@ep1.example.com;lr>
Contact: <sip:bob@192.0.2.2;transport=tcp;ob>10. Grammar 📜
This spec defines a new header field called "Flow-Timer", plus two new Contact header field parameters, "reg-id" and "+sip.instance". The grammar pulls in the definitions from [RFC3261]. Flow-Timer is an extension-header off the message-header in the [RFC3261] ABNF.
The ABNF [RFC5234] is:
Flow-Timer = "Flow-Timer" HCOLON 1*DIGIT
contact-params =/ c-p-reg / c-p-instance
c-p-reg = "reg-id" EQUAL 1*DIGIT ; 1 to (2^31 - 1)
c-p-instance = "+sip.instance" EQUAL
DQUOTE "<" instance-val ">" DQUOTE
instance-val = 1*uric ; defined in RFC 3261The value of the reg-id MUST NOT be 0 and MUST be less than 2^31. 🔢
11. IANA Considerations 🏳️🌈
11.1. Flow-Timer Header Field
This spec defines a new SIP header field called "Flow-Timer", and its syntax lives in Section 10 ✨
Header Name compact Reference
----------------- ------- ---------
Flow-Timer [RFC5626]11.2. "reg-id" Contact Header Field Parameter
This spec defines a new Contact header field parameter called reg-id in the "Header Field Parameters and Parameter Values" sub-registry, following the registry created by [RFC3968]. The syntax is in Section 10. The required info is:
Predefined
Header Field Parameter Name Values Reference
---------------------- --------------------- ---------- ---------
Contact reg-id No [RFC5626]11.3. SIP/SIPS URI Parameters
This spec augments the "SIP/SIPS URI Parameters" sub-registry, following the registry created by [RFC3969]. The required info is:
Parameter Name Predefined Values Reference
-------------- ----------------- ---------
ob No [RFC5626]11.4. SIP Option Tag 🏷️
This spec registers a new SIP option tag, following the guidelines in Section 27.1 of [RFC3261].
Name: outbound
Description: This option-tag identifies UAs and registrars that support extensions for Client-Initiated Connections. A UA puts this option in a Supported header to show it supports this extension. A registrar puts this option-tag in a Require header to tell the registering User Agent that the registrar used registrations following the binding rules defined in this extension.
11.5. 430 (Flow Failed) Response Code 🚫
This document registers a new SIP response code (430 Flow Failed), following the guidelines in Section 27.4 of [RFC3261]. An edge proxy uses this response code to tell the Authoritative Proxy that a specific flow to a UA instance has failed. Other flows to the same instance could still work. The Authoritative Proxy SHOULD attempt to forward to another target (flow) with the same instance-id and AOR. Endpoints should never receive a 430 response. If an endpoint does get a 430 response, it should treat it as a 400 (Bad Request) following normal procedures, as in Section 8.1.3.2 of [RFC3261]. This response code is defined by the following info, which has been added to the method and response-code sub-registry under the SIP Parameters registry.
Response Code Reference
------------------------------------------ ---------
Request Failure 4xx
430 Flow Failed [RFC5626]11.6. 439 (First Hop Lacks Outbound Support) Response Code
okay bestie, this part registers a brand new SIP response code, 439 First Hop Lacks Outbound Support 💅, following the guidelines in Section 27.4 of [RFC3261] 🎀. A registrar sends it to say "hey, I totally support the 'outbound' feature 💖, but the first outbound proxy you're trying to register through doesn't 😭."
This only applies when the registering User Agent says it supports outbound processing by including the outbound option tag in a Supported header field 🫶. Proxies MUST NOT send a 439 response to any request that doesn't have a "reg-id" parameter AND an outbound option tag in a Supported header field 🙈 (no sending it to random requests, periodt).
The code is now listed in the method and response-code sub-registry under the SIP Parameters registry 🧚:
Response Code Reference
------------------------------------------ ---------
Request Failure 4xx
439 First Hop Lacks Outbound Support [RFC&rfc.number;]11.7. Media Feature Tag
this section registers a new media feature tag using the procedures from [RFC2506] 🦋. The tag lives in the sip tree, which is defined in [RFC3840] 🌸.
- Media feature tag name:
sip.instance - ASN.1 Identifier:
23 - Summary of the media feature indicated by this tag: it holds a string containing a URN that uniquely identifies the UA instance registering the Contact 🆔
- Values appropriate for use with this feature tag:
String(equality relationship) - The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: it's most useful in a communications app for describing what a device can do, like a phone or a PDA 📱
- Examples of typical use: routing a call to a specific device 📞
- Related standards or documents: RFC 5626
Security Considerations: this tag can be used in ways that affect how applications behave 😳. For example, the SIP caller preferences extension [RFC3841] lets call routing decisions depend on the values of these parameters 🚦. So if an attacker can change this tag's values, they might be able to mess with how applications act 💀. Applications that use this media feature tag SHOULD provide a way to make sure it hasn't been tampered with 🔒. This tag should also only be trusted as valid when it comes from the user or User Agent it describes 🫵. That means the protocols that carry this feature tag SHOULD provide a way to guarantee authenticity ✅.
12. Security Considerations 🔐
okay this is the big one, so pay attention bestie 👑. One of the main security worries here is making sure an attacker can't hijack a valid user's sessions and redirect every call meant for that user to themselves 😱. The goal isn't to stop existing active attacks on SIP UDP and TCP traffic 🙅♀️. The goal is making sure the outbound mechanism doesn't add any new attacks 🛡️.
The simple case is when there are no edge proxies 🌷. Here, an entry can only be added to the routing for a given AOR when the registration succeeds ✨. SIP already protects against attackers successfully registering, and this scheme relies on that protection 💪. Some implementers have thought about just saving the instance-id without tying it to the AOR it registered with 🤔. That idea won't work, because an attacker's UA can impersonate a valid user's instance-id and hijack that user's calls 💀.
The more complex case involves one or more edge proxies 🧩. When a UA sends a REGISTER request through an edge proxy on its way to the registrar, the edge proxy inserts a Path header field value 📮. If the registration is successfully authenticated, the registrar stores the value of the Path header field 📦. Later, when the registrar forwards a request destined for the UA, it copies the stored Path value into the Route header field of the request and forwards the request to the edge proxy 🚀.
An edge proxy will only route over a particular flow when it has received a Route header carrying the flow identifier information it created itself 🪪. An incoming request gets this information from the registrar 📬. The registrar only saves this information for a given AOR if the registration for that AOR succeeded, and the registration only succeeds if the UA authenticates correctly 🔑. Even if an attacker spoofs some bad information in the Path header sent to the registrar, they still can't get the registrar to accept it for an AOR that doesn't belong to them 🙅. The registrar won't hand that bad info out to anyone else, so nobody gets misled into contacting the attacker 🎯.
The Security Considerations discussed in [RFC3261] and [RFC3327] are also relevant to this document 📚. For the security considerations of generating flow tokens, also check out Section 5.2 🔍. A discussion of preventing the avalanche restart problem is in Section 4.5 ❄️.
This document does not change the mandatory-to-implement security mechanisms in SIP 🙌. User Agents are already required to implement Digest authentication, while support for TLS is recommended 🔐. Proxy servers are already required to implement both Digest and TLS 💜.
13. Operational Notes on Transports 🚚
this entire section is non-normative, so it's just friendly advice 🫶.
[RFC3261] requires proxies, registrars, and User Agents to implement both TCP and UDP, but deployments can choose which transport protocols they want to use 🛣️. Deployments need to be careful about which transports they pick 🧐. Lots of SIP features and extensions, like large presence notification bodies, result in SIP requests that are too big to be reasonably transported over UDP 📦💥. [RFC3261] says that when a request is too large for UDP, the sending device tries to switch over to TCP 🔄. The important thing to note is that when using outbound, this only works if the UA has formed both UDP and TCP outbound flows 🌊. This specification lets the UA do that, but in most cases it'll probably make more sense for the UA to form only a TCP outbound connection, rather than both UDP and TCP flows 💅. One of the big reasons many deployments avoid TCP is the difficulty of building proxies that can maintain a very large number of active TCP connections 😵💫. Lots of deployments today use SIP in a way where messages are small enough to work over UDP, but they can not take advantage of all the functionality SIP offers 🥲. Deployments that only use UDP outbound connections are going to fail with sufficiently large SIP messages 🚫.
14. Requirements 📝
this specification was developed to meet the following requirements, and honestly they're very on-brand 💖:
- Must be able to detect that a UA supports these mechanisms. 🔍
- Support UAs behind NATs. 🏠
- Support TLS to a UA without a stable DNS name or IP address. 🔐
- Detect failure of a connection and be able to correct for this. 🛠️
- Support many UAs simultaneously rebooting. 🔁
- Support a NAT rebooting or resetting. 🌪️
- Minimize initial startup load on a proxy. 😌
- Support architectures with edge proxies. 🧚
15. Acknowledgments 🫶
Francois Audet acted as document shepherd for this document 🐑. He tracked hundreds of comments, incorporated many grammatical fixes, and kept prodding the editors to "get on with it" 😂. Jonathan Rosenberg, Erkki Koivusalo, and Byron Campen provided many comments and useful text 💜. Dave Oran came up with the idea of using the most recent registration first in the proxy 🧠. Alan Hawrylyshen co-authored the document that formed the initial text of this specification 📄. Many of the concepts here started at a connection reuse meeting at IETF 60, which included the authors Jon Peterson, Jonathan Rosenberg, Alan Hawrylyshen, and Paul Kyzivat 🌈. The TCP design team, made up of Chris Boulton, Scott Lawrence, Rajnish Jain, Vijay K. Gurbani, and Ganesh Jayadevan, provided input and text 🫡. Nils Ohlmeier provided many fixes and initial implementation experience 🛠️. Thanks also to these folks for useful comments: Francois Audet, Flemming Andreasen, Mike Hammer, Dan Wing, Srivatsa Srinivasan, Dale Worely, Juha Heinanen, Eric Rescorla, Lyndsay Campbell, Christer Holmberg, Kevin Johns, Jeroen van Bemmel, Derek MacDonald, Dean Willis, and Robert Sparks 💖✨.
16. References 📚
16.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
[RFC2506] Holtman, K., Mutz, A., and T. Hardie, "Media Feature
Tag Registration Procedure", BCP 31, RFC 2506,
March 1999.
[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.
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
Protocol (SIP): Locating SIP Servers", RFC 3263,
June 2002.
[RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation
Protocol (SIP) Extension Header Field for Registering
Non-Adjacent Contacts", RFC 3327, December 2002.
[RFC3581] Rosenberg, J. and H. Schulzrinne, "An Extension to the
Session Initiation Protocol (SIP) for Symmetric
Response Routing", RFC 3581, August 2003.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Caller Preferences for the Session Initiation
Protocol (SIP)", RFC 3841, August 2004.
[RFC3968] Camarillo, G., "The Internet Assigned Number Authority
(IANA) Header Field Parameter Registry for the Session
Initiation Protocol (SIP)", BCP 98, RFC 3968,
December 2004.
[RFC3969] Camarillo, G., "The Internet Assigned Number Authority
(IANA) Uniform Resource Identifier (URI) Parameter
Registry for the Session Initiation Protocol (SIP)",
BCP 99, RFC 3969, December 2004.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122,
July 2005.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)",
RFC 5389, October 2008.16.2. Informative References ✨
okay bestie, these are the "if you want the deep lore" references 📚 You don't need them to implement anything, but they're the receipts behind the spec 💅
[CONFIG-FMWK] Petrie, D. and S. Channabasappa, Ed., "A Framework for Session Initiation Protocol User Agent Profile Delivery", Work in Progress, February 2008.
[NAT-SCEN] Boulton, C., Rosenberg, J., Camarillo, G., and F. Audet, "Best Current Practices for NAT Traversal for Client-Server SIP", Work in Progress, September 2008.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. 🦋
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. 🦋
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. 🌸
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. 🔐
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. 🌸
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. 🧚
[RFC3320] Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu, Z., and J. Rosenberg, "Signaling Compression (SigComp)", RFC 3320, January 2003. 🌈
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003. ⭐
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. 💜
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 🍓
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006. 🎀
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007. 🫶
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. 🔥
[RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)", RFC 5627, October 2009. 👑
Appendix A. Default Flow Registration Backoff Times 🍓
okay so the re-registration backoff times from Section 4.5 are configurable, and the base-time is the knob you turn 🎛️ If base-time-all-fail is left at the default of 30 seconds and base-time-not-failed is left at the default of 90 seconds, this table shows how long the UA waits before it tries to register again ⏰
+-------------------+--------------------+---------------------+
| # of reg failures | all flows unusable | > 1 non-failed flow |
+-------------------+--------------------+---------------------+
| 0 | 0 s | 0 s |
| 1 | 30-60 s | 90-180 s |
| 2 | 1-2 min | 3-6 min |
| 3 | 2-4 min | 6-12 min |
| 4 | 4-8 min | 12-24 min |
| 5 | 8-16 min | 15-30 min |
| 6 or more | 15-30 min | 15-30 min |
+-------------------+--------------------+---------------------+the waits double every failure until they cap out, so don't be surprised when it gets slow 😭
Appendix B. ABNF 💅
this appendix is the ABNF we already met earlier in the doc, all gathered in one place so you can find it fast 🔍✨
CRLF = CR LF
double-CRLF = CR LF CR LF
CR = %x0D
LF = %x0A
Flow-Timer = "Flow-Timer" HCOLON 1*DIGIT
contact-params =/ c-p-reg / c-p-instance
c-p-reg = "reg-id" EQUAL 1*DIGIT ; 1 to (2^31 - 1)
c-p-instance = "+sip.instance" EQUAL
DQUOTE "<" instance-val ">" DQUOTE
instance-val = 1*uric ; defined in RFC 3261Authors' Addresses 🎀
meet the squad who wrote this thing 🫶
Cullen Jennings (editor) 👑
Cullen Jennings (editor)
Cisco Systems
170 West Tasman Drive
Mailstop SJC-21/2
San Jose, CA 95134
USA
Phone: +1 408 902-3341
EMail: fluffy@cisco.comRohan Mahy (editor) 🌸
Rohan Mahy (editor)
Unaffiliated
EMail: rohan@ekabal.comFrancois Audet (editor) 💜
Francois Audet (editor)
Skype Labs
EMail: francois.audet@skypelabs.comand that's a wrap on RFC 5626, periodt! 🌈💖
📦 where this page comes from
- ietf: rfc5626 2009-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms