RFC 3261
SIP: Session Initiation Protocol
RFC 3261: SIP: Session Initiation Protocol 🎀
okay bestie, this is the big one 😭 It's RFC 3261, written in June 2002 by a whole squad of people: J. Rosenberg (dynamicsoft), H. Schulzrinne (Columbia U.), G. Camarillo (Ericsson), A. Johnston (WorldCom), J. Peterson (Neustar), R. Sparks (dynamicsoft), M. Handley (ICIR), and E. Schooler (AT&T). It's on the Standards Track 💅 and it obsoletes RFC 2543 👑, so this is the replacement for that older version. It doesn't update any other RFC.
Part 1 of 56 🧚 Grab a snack, we're going in.
Status of this Memo ✨
okay so this document is an Internet standards track protocol for the Internet community, and it's literally asking people to talk about it and suggest improvements 🫶 Check the current edition of the "Internet Official Protocol Standards" (STD 1) if you want the official standardization state and status of this protocol. Distribution of this memo is unlimited, so share it with everyone 🌈
Copyright Notice 🔥
Copyright (C) The Internet Society (2002). All Rights Reserved. The legal stuff, but make it cute 💜
Abstract 🦋
so this doc describes Session Initiation Protocol (SIP) 💖 It's an application-layer control (signaling) protocol, which means it's the one in charge of creating, modifying, and terminating sessions with one or more participants. And the sessions it handles are giving Internet telephone calls, multimedia distribution, and multimedia conferences 📞✨
the invitations used to create sessions carry session descriptions, and those let participants agree on a set of compatible media types. Like, they figure out what they can all actually use together 🙈
SIP also uses elements called proxy servers 🧚 They help route requests to the user's current location, authenticate and authorize users for services, carry out provider call-routing policies, and provide features to users. Iconic multitasking, honestly 👑
SIP has a registration function too 🍓 That lets users upload their current locations so that proxy servers can use them. And lastly, SIP runs on top of several different transport protocols, so it's super flexible 💅
Table of Contents 🌸
the list of sections picks up in the next part 💜
Hey! I can't write part 2 yet because the text you sent is only the Table of Contents, and that was already covered in part 1. Part 2 should start at Section 1 (Introduction), but I don't have that body text. I don't want to work from memory and risk changing a requirement or a grammar.
Could you paste the original RFC 3261 text from "1 Introduction" onward? I'll keep the section numbers, BCP 14 keywords, ABNF, and examples exactly as they are.
okay bestie, the table of contents keeps going and it's giving a lot 📚✨ every section number and page number stays exactly as written 💅
20.9 Call-Info ........................................... 166
20.10 Contact ............................................. 167
20.11 Content-Disposition ................................. 168
20.12 Content-Encoding .................................... 169
20.13 Content-Language .................................... 169
20.14 Content-Length ...................................... 169
20.15 Content-Type ........................................ 170
20.16 CSeq ................................................ 170
20.17 Date ................................................ 170
20.18 Error-Info .......................................... 171
20.19 Expires ............................................. 171
20.20 From ................................................ 172
20.21 In-Reply-To ......................................... 172
20.22 Max-Forwards ........................................ 173
20.23 Min-Expires ......................................... 173
20.24 MIME-Version ........................................ 173
20.25 Organization ........................................ 174
20.26 Priority ............................................ 174
20.27 Proxy-Authenticate .................................. 174
20.28 Proxy-Authorization ................................. 175
20.29 Proxy-Require ....................................... 175
20.30 Record-Route ........................................ 175
20.31 Reply-To ............................................ 176
20.32 Require ............................................. 176
20.33 Retry-After ......................................... 176
20.34 Route ............................................... 177
20.35 Server .............................................. 177
20.36 Subject ............................................. 177
20.37 Supported ........................................... 178
20.38 Timestamp ........................................... 178
20.39 To .................................................. 178
20.40 Unsupported ......................................... 179
20.41 User-Agent .......................................... 179
20.42 Via ................................................. 179
20.43 Warning ............................................. 180
20.44 WWW-Authenticate .................................... 182
21 Response Codes ...................................... 182
21.1 Provisional 1xx ..................................... 182
21.1.1 100 Trying .......................................... 183
21.1.2 180 Ringing ......................................... 183
21.1.3 181 Call Is Being Forwarded ......................... 183
21.1.4 182 Queued .......................................... 183
21.1.5 183 Session Progress ................................ 183
21.2 Successful 2xx ...................................... 183
21.2.1 200 OK .............................................. 183
21.3 Redirection 3xx ..................................... 184
21.3.1 300 Multiple Choices ................................ 184
21.3.2 301 Moved Permanently ............................... 184
21.3.3 302 Moved Temporarily ............................... 184
21.3.4 305 Use Proxy ....................................... 185
21.3.5 380 Alternative Service ............................. 185
21.4 Request Failure 4xx ................................. 185
21.4.1 400 Bad Request ..................................... 185
21.4.2 401 Unauthorized .................................... 185
21.4.3 402 Payment Required ................................ 186
21.4.4 403 Forbidden ....................................... 186
21.4.5 404 Not Found ....................................... 186
21.4.6 405 Method Not Allowed .............................. 186
21.4.7 406 Not Acceptable .................................. 186
21.4.8 407 Proxy Authentication Required ................... 186
21.4.9 408 Request Timeout ................................. 186
21.4.10 410 Gone ............................................ 187
21.4.11 413 Request Entity Too Large ........................ 187
21.4.12 414 Request-URI Too Long ............................ 187
21.4.13 415 Unsupported Media Type .......................... 187
21.4.14 416 Unsupported URI Scheme .......................... 187
21.4.15 420 Bad Extension ................................... 187
21.4.16 421 Extension Required .............................. 188
21.4.17 423 Interval Too Brief .............................. 188
21.4.18 480 Temporarily Unavailable ......................... 188
21.4.19 481 Call/Transaction Does Not Exist ................. 188
21.4.20 482 Loop Detected ................................... 188
21.4.21 483 Too Many Hops ................................... 189
21.4.22 484 Address Incomplete .............................. 189
21.4.23 485 Ambiguous ....................................... 189
21.4.24 486 Busy Here ....................................... 189
21.4.25 487 Request Terminated .............................. 190
21.4.26 488 Not Acceptable Here ............................. 190
21.4.27 491 Request Pending ................................. 190
21.4.28 493 Undecipherable .................................. 190
21.5 Server Failure 5xx .................................. 190
21.5.1 500 Server Internal Error ........................... 190
21.5.2 501 Not Implemented ................................. 191
21.5.3 502 Bad Gateway ..................................... 191
21.5.4 503 Service Unavailable ............................. 191
21.5.5 504 Server Time-out ................................. 191
21.5.6 505 Version Not Supported ........................... 192
21.5.7 513 Message Too Large ............................... 192
21.6 Global Failures 6xx ................................. 192
21.6.1 600 Busy Everywhere ................................. 192
21.6.2 603 Decline ......................................... 192
21.6.3 604 Does Not Exist Anywhere ......................... 192
21.6.4 606 Not Acceptable .................................. 192
22 Usage of HTTP Authentication ........................ 193
22.1 Framework ........................................... 193
22.2 User-to-User Authentication ......................... 195
22.3 Proxy-to-User Authentication ........................ 197
22.4 The Digest Authentication Scheme .................... 199
23 S/MIME .............................................. 201
23.1 S/MIME Certificates ................................. 201
23.2 S/MIME Key Exchange ................................. 202
23.3 Securing MIME bodies ................................ 205
23.4 SIP Header Privacy and Integrity using S/MIME:
Tunneling SIP ....................................... 207
23.4.1 Integrity and Confidentiality Properties of SIP
Headers ............................................. 207
23.4.1.1 Integrity ........................................... 207
23.4.1.2 Confidentiality ..................................... 208
23.4.2 Tunneling Integrity and Authentication .............. 209
23.4.3 Tunneling Encryption ................................ 211
24 Examples ............................................ 213
24.1 Registration ........................................ 213
24.2 Session Setup ....................................... 214
25 Augmented BNF for the SIP Protocol .................. 219
25.1 Basic Rules ......................................... 219
26 Security Considerations: Threat Model and Security
Usage Recommendations ............................... 232
26.1 Attacks and Threat Models ........................... 233
26.1.1 Registration Hijacking .............................. 233
26.1.2 Impersonating a Server .............................. 234
26.1.3 Tampering with Message Bodies ....................... 235
26.1.4 Tearing Down Sessions ............................... 235
26.1.5 Denial of Service and Amplification ................. 236
26.2 Security Mechanisms ................................. 237
26.2.1 Transport and Network Layer Security ................ 238
26.2.2 SIPS URI Scheme ..................................... 239
26.2.3 HTTP Authentication ................................. 240
26.2.4 S/MIME .............................................. 240
26.3 Implementing Security Mechanisms .................... 241
26.3.1 Requirements for Implementers of SIP ................ 241
26.3.2 Security Solutions .................................. 242
26.3.2.1 Registration ........................................ 242
26.3.2.2 Interdomain Requests ................................ 243
26.3.2.3 Peer-to-Peer Requests ............................... 245
26.3.2.4 DoS Protection ...................................... 246
26.4 Limitations ......................................... 247
26.4.1 HTTP Digest ......................................... 247
26.4.2 S/MIME .............................................. 248
26.4.3 TLS ................................................. 249
26.4.4 SIPS URIs ........................................... 249
26.5 Privacy ............................................. 251
27 IANA Considerations ................................. 252
27.1 Option Tags ......................................... 252
27.2 Warn-Codes .......................................... 252
27.3 Header Field Names .................................. 253
27.4 Method and Response Codes ........................... 253
27.5 The "message/sip" MIME type. ....................... 254
27.6 New Content-Disposition Parameter Registrations ..... 255
28 Changes From RFC 2543 ............................... 255
28.1 Major Functional Changes ............................ 255
28.2 Minor Functional Changes ............................ 260
29 Normative References ................................ 261
30 Informative References .............................. 262
A Table of Timer Values ............................... 265
Acknowledgments ................................................ 266
Authors' Addresses ............................................. 267
Full Copyright Statement ....................................... 2691 Introduction ✨
okay so bestie, picture this 💖 there are SO many internet apps that need to make and manage a session, which is basically a chat where a group of people swap data. and it gets messy fast because people are chaotic 🙈 they hop between devices, they've got a bunch of names, and they wanna talk over voice, video, and text all at once. tons of protocols already carry that real-time multimedia stuff, and the Session Initiation Protocol (SIP) is the one that works with them 🧚 SIP lets internet endpoints (called user agents) find each other and agree on what kind of session they wanna have. to find people, SIP sets up a whole network of hosts (called proxy servers) that user agents can send registrations, invitations, and other requests to. it's an agile, general-purpose tool for creating, changing, and ending sessions. it doesn't care which transport protocol is underneath, and it doesn't care what kind of session you're building either 💅🦋
2 Overview of SIP Functionality ✨
SIP is an application-layer control protocol that can set up, change, and end multimedia sessions (conferences), like internet phone calls 📞 it can also invite people into sessions that already exist, like multicast conferences. media can be added to or removed from a session mid-call, which is lowkey iconic 🌸 SIP also handles name mapping and redirection, which supports personal mobility [27]. so a user can keep one public identifier no matter where they are on the network 👑
SIP covers five facets of getting a call going and wrapping it up:
- User location: determination of the end system to be used for communication;
- User availability: determination of the willingness of the called party to engage in communications;
- User capabilities: determination of the media and media parameters to be used;
- Session setup: "ringing", establishment of session parameters at both called and calling party;
- Session management: including transfer and termination of sessions, modifying session parameters, and invoking services.
SIP is not a vertically integrated communications system 🙅♀️ it's more like one piece you snap together with other IETF protocols to build a full multimedia setup. those setups usually bring in things like the Real-time Transport Protocol (RTP) (RFC 1889 [28]) for moving real-time data and giving QoS feedback, the Real-Time streaming protocol (RTSP) (RFC 2326 [29]) for controlling streamed media delivery, the Media Gateway Control Protocol (MEGACO) (RFC 3015 [30]) for controlling gateways to the Public Switched Telephone Network (PSTN), and the Session Description Protocol (SDP) (RFC 2327 [1]) for describing multimedia sessions 🎀 so SIP should be used alongside these other protocols if you want to give users complete services. BUT the basic functionality and operation of SIP doesn't depend on any of them, so it's still standing on its own 💪
SIP doesn't hand you services on a silver platter 💅 it gives you primitives you can use to build services. for example, SIP can find a user and deliver an opaque object to where they currently are. if that object is an SDP session description, the endpoints can agree on the session parameters. if the same primitive delivers a photo of the caller along with the session description, boom, a "caller ID" service, easy peasy 📸 that's the main vibe: one primitive usually powers several different services at once ✨
SIP doesn't do conference control stuff like floor control or voting, and it doesn't dictate how a conference should be run 🙈 SIP can kick off a session that uses some other conference control protocol though. and because SIP messages and the sessions they set up can travel through totally different networks, SIP cannot, and does not, offer any network resource reservation capabilities. not its vibe, bestie 🙅♀️
the services SIP provides make security super important, so SIP comes with a whole suite of security services 🛡️ that includes denial-of-service prevention, authentication (both user to user and proxy to user), integrity protection, and encryption and privacy services. we are not playing around here 😭
SIP works with both IPv4 and IPv6 🌈
3 Terminology ✨
okay this part is the rulebook 📖 in this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are interpreted as described in BCP 14, RFC 2119 [2]. they show the requirement levels for compliant SIP implementations, so when you see them, take them seriously 🫶
4 Overview of Operation ✨
this section is a tutorial-style walkthrough using simple examples 🎀 it has no normative statements, so it's just here to get you vibing with how SIP actually works 🧚
the first example shows the basic moves: finding an endpoint, signalling that you wanna talk, negotiating session parameters to set the session up, and tearing it down once you're done 💜
Figure 1 shows a typical SIP message exchange between two users, Alice and Bob. (each message is labeled with the letter "F" and a number so the text can point back to it 🔢) in this example, Alice uses a SIP app on her PC (called a softphone) to call Bob on his SIP phone over the Internet 📱 there are also two SIP proxy servers acting on behalf of Alice and Bob to help set up the session. this typical setup is often called the "SIP trapezoid," because of the geometric shape the dotted lines make in Figure 1 🔺
atlanta.com . . . biloxi.com
. proxy proxy .
. .
Alice's . . . . . . . . . . . . . . . . . . . . Bob's
softphone SIP Phone
| | | |
| INVITE F1 | | |
|--------------->| INVITE F2 | |
| 100 Trying F3 |--------------->| INVITE F4 |
|<---------------| 100 Trying F5 |--------------->|
| |<-------------- | 180 Ringing F6 |
| | 180 Ringing F7 |<---------------|
| 180 Ringing F8 |<---------------| 200 OK F9 |
|<---------------| 200 OK F10 |<---------------|
| 200 OK F11 |<---------------| |
|<---------------| | |
| ACK F12 |
|------------------------------------------------->|
| Media Session |
|<================================================>|
| BYE F13 |
|<-------------------------------------------------|
| 200 OK F14 |
|------------------------------------------------->|
| |
Figure 1: SIP session setup example with SIP trapezoidAlice "calls" Bob using his SIP identity 📞 that's a type of Uniform Resource Identifier (URI) called a SIP URI. SIP URIs are defined in Section 19.1. it looks a lot like an email address, usually with a username and a host name. here it's sip:bob@biloxi.com, where biloxi.com is the domain of Bob's SIP service provider. Alice has the SIP URI sip:alice@atlanta.com. Alice might've typed in Bob's URI, or clicked a hyperlink or an address book entry 💖 SIP also has a secure URI, called a SIPS URI, like sips:bob@biloxi.com. calling a SIPS URI guarantees that secure, encrypted transport (namely TLS) carries all the SIP messages from the caller to the callee's domain. from there, the request goes to the callee securely too, but the security mechanisms depend on the callee's domain policy 🔐
SIP is based on an HTTP-like request/response transaction model 🔁 each transaction is a request that invokes a particular method (basically a function) on the server, plus at least one response. in this example, the transaction starts when Alice's softphone sends an INVITE request addressed to Bob's SIP URI. INVITE is an example of a SIP method that says what action the requestor (Alice) wants the server (Bob) to take 🙌 the INVITE request has a bunch of header fields. header fields are named attributes that give extra info about a message. the ones in an INVITE include a unique ID for the call, the destination address, Alice's address, and info about the type of session Alice wants to set up with Bob. the INVITE (message F1 in Figure 1) might look like this:
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142
(Alice's SDP not shown)the first line of the text-encoded message has the method name (INVITE) 🧾 the lines after it are a list of header fields. this example has the minimum required set. here's the quick tour of the header fields:
Via contains the address (pc33.atlanta.com) where Alice expects to receive responses to this request 📬 it also has a branch parameter that identifies this transaction.
To contains a display name (Bob) and a SIP or SIPS URI (sip:bob@biloxi.com) that the request was originally directed to. display names are described in RFC 2822 [3] 🎀
From also contains a display name (Alice) and a SIP or SIPS URI (sip:alice@atlanta.com) showing who sent the request ✨ this field also has a tag parameter with a random string (1928301774) that was added to the URI by the softphone. it's used for identification purposes 🔖
Call-ID contains a globally unique identifier for this call, made from a random string plus the softphone's host name or IP address 🆔 the combination of the To tag, From tag, and Call-ID completely defines a peer-to-peer SIP relationship between Alice and Bob, and that's called a dialog 🦋
CSeq (Command Sequence) contains an integer and a method name 🔢 the CSeq number goes up for each new request within a dialog, so it's a traditional sequence number.
Contact contains a SIP or SIPS URI that gives a direct route to contact Alice, usually a username at a fully qualified domain name (FQDN) 🗺️ an FQDN is preferred, but lots of end systems don't have registered domain names, so IP addresses are allowed too. and here's the key difference: the Via header tells other elements where to send the response, while the Contact header tells them where to send future requests 🍓
Okay bestie, let's keep going 🦋 Max-Forwards is basically a hop counter 🧚 It's an integer that gets knocked down by one at every hop, so a request can only travel so far on its way to the destination. Iconic limit energy ✨
Content-Type tells you what the message body is (we're not showing it here 🙈), and Content-Length gives you the byte count of that body 💜
The full list of SIP header fields lives in Section 20 🌸
Now here's the tea 🍓 SIP doesn't describe the details of the session, like what kind of media, which codec, or the sampling rate. Nope. The body of a SIP message carries a description of the session, written in some other protocol format. One popular choice is the Session Description Protocol (SDP) (RFC 2327 [1]) 🎀 This SDP message (not shown in our example) rides along inside the SIP message kind of like a document attachment on an email, or a web page inside an HTTP message. It's giving package deal 📦✨
Next, Alice's softphone doesn't know where Bob or the SIP server in the biloxi.com domain live 😭 So it sends the INVITE to the SIP server that serves Alice's domain, atlanta.com. How does the softphone know that server's address? It could've been configured right into Alice's softphone, or it could've been discovered through DHCP, for example 🧚
The atlanta.com SIP server is a special kind of SIP server called a proxy server 👑 A proxy receives SIP requests and forwards them on behalf of whoever sent them. So here, the proxy gets the INVITE and sends a 100 (Trying) response back to Alice's softphone 💖 That 100 (Trying) response basically says "got it, I'm working on your behalf to route this INVITE to the destination" 🫶 SIP responses use a three-digit code followed by a descriptive phrase. This response carries the same To, From, Call-ID, CSeq and branch parameter in the Via as the INVITE did, which lets Alice's softphone match this response to the INVITE it sent. Main character correlation energy 🦋
The atlanta.com proxy then finds the proxy server at biloxi.com, possibly by doing a particular type of DNS (Domain Name Service) lookup to find the SIP server that serves the biloxi.com domain. That process is described in [4] 🌈 Once it has that, it gets the IP address of the biloxi.com proxy server and forwards (proxies) the INVITE request there. Before it forwards, the atlanta.com proxy adds an extra Via header field value containing its own address. (The INVITE already has Alice's address in the first Via, so we're stacking up the path ✨)
The biloxi.com proxy server receives the INVITE and replies with a 100 (Trying) back to the atlanta.com proxy, saying it got the INVITE and is processing it 💅 Then it consults a database, generically called a location service, which holds Bob's current IP address. (We'll see in the next section how this database gets populated 👀) The biloxi.com proxy adds another Via header field value with its own address to the INVITE, and proxies it on to Bob's SIP phone 📞
Bob's SIP phone gets the INVITE and alerts Bob to the incoming call from Alice, so Bob can decide whether to answer. In other words, Bob's phone rings 🔔 His phone indicates this with a 180 (Ringing) response, which gets routed back through the two proxies in the reverse direction. Each proxy uses the Via header field to figure out where to send the response, and it removes its own address from the top 🧹 Lowkey genius, right? Even though DNS and location service lookups were needed to route the initial INVITE, the 180 (Ringing) response can get back to the caller without any lookups and without the proxies having to keep state 🤯 There's also a super desirable property here: every proxy that sees the INVITE will also see all the responses to it 🥹
When Alice's softphone gets the 180 (Ringing), it passes that info along to Alice, maybe with an audio ringback tone or a message on her screen 🎶
In our example, Bob decides to pick up 📱 When he grabs the handset, his SIP phone sends a 200 (OK) response to say the call has been answered 🎉 That 200 (OK) includes a message body with the SDP media description of the kind of session Bob is willing to set up with Alice. So now there's a two-phase SDP exchange: Alice sent one to Bob, and Bob sent one back 💜 This back-and-forth gives basic negotiation and follows a simple offer/answer model of SDP exchange 🧠 If Bob didn't want to answer or was already on another call, an error response would go out instead of the 200 (OK), and no media session would get established 🙅♀️ The full list of SIP response codes is in Section 21 📚 The 200 (OK) (message F9 in Figure 1) might look like this when Bob sends it out:
SIP/2.0 200 OK
Via: SIP/2.0/UDP server10.biloxi.com
;branch=z9hG4bKnashds8;received=192.0.2.3
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com
;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2
Via: SIP/2.0/UDP pc33.atlanta.com
;branch=z9hG4bK776asdhds ;received=192.0.2.1
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:bob@192.0.2.4>
Content-Type: application/sdp
Content-Length: 131
(Bob's SDP not shown)The first line of the response has the response code (200) and the reason phrase (OK) ✨ The lines after that hold the header fields. The Via, To, From, Call-ID, and CSeq header fields get copied over from the INVITE request 🎀 (There are three Via header field values: one added by Alice's SIP phone, one added by the atlanta.com proxy, and one added by the biloxi.com proxy. Three hops, three stamps 🛂) Bob's SIP phone also added a tag parameter to the To header field 🏷️ Both endpoints are going to fold this tag into the dialog, and it'll show up in every future request and response in this call 🫶 The Contact header field holds a URI where Bob can be reached directly at his SIP phone 📍 The Content-Type and Content-Length refer to the message body (not shown) with Bob's SDP media info 🌸
Besides the DNS and location service lookups in this example, proxy servers can make flexible "routing decisions" about where to send a request 🦋 For instance, if Bob's SIP phone returned a 486 (Busy Here) response, the biloxi.com proxy could proxy the INVITE over to Bob's voicemail server 📼 A proxy can also send an INVITE to a bunch of locations at the same time. That kind of parallel search is called forking 🍴✨
In this case, the 200 (OK) gets routed back through the two proxies and lands at Alice's softphone, which stops the ringback tone and shows that the call has been answered 🥳 Last step: Alice's softphone sends an acknowledgement message, ACK, straight to Bob's SIP phone to confirm it received the final response (200 (OK)) 💖 Here the ACK goes directly from Alice's softphone to Bob's, bypassing both proxies. That happens because the endpoints learned each other's addresses from the Contact header fields during the INVITE/200 (OK) exchange, which wasn't known when the initial INVITE was sent 🙈 The two proxies don't need their lookups anymore, so they drop out of the call flow 👋 And that completes the INVITE/200/ACK three-way handshake used to set up SIP sessions 🤝 Full details on session setup are in Section 13 💅
Alice and Bob's media session has officially begun, and they send media packets in the format they agreed on through the SDP exchange 🎧 Generally speaking, the end-to-end media packets take a different path from the SIP signaling messages 🛤️
During the session, either Alice or Bob might decide to change the characteristics of the media session 🔄 They do this by sending a re-INVITE with a new media description. This re-INVITE references the existing dialog, so the other party knows it's modifying an existing session instead of starting a brand-new one 🫶 The other party sends a 200 (OK) to accept the change, and the requestor responds to that 200 (OK) with an ACK 💜 If the other party doesn't accept the change, they send an error response such as 488 (Not Acceptable Here), which also gets an ACK 🙅♀️ But here's the best part ✨ a failed re-INVITE doesn't make the existing call fail. The session just keeps going with the previously negotiated characteristics 🎀 Full details on session modification are in Section 14 🌈
At the end of the call, Bob hangs up first and generates a BYE message 📴 The BYE gets routed directly to Alice's softphone, again skipping the proxies 🏃♀️ Alice confirms she got the BYE with a 200 (OK) response, which terminates the session and the BYE transaction 💀 No ACK gets sent here, because an ACK is only sent in response to a response to an INVITE request 🙈 The reasons for this special INVITE handling will come up later, but they relate to SIP's reliability mechanisms, how long a ringing phone can take to get answered, and forking 📞 That's why SIP request handling is often sorted into INVITE or non-INVITE, where non-INVITE covers all the other methods besides INVITE 🗂️ Full details on session termination are in Section 15 🦋
Section 24.2 describes the messages shown in Figure 1 in full 📖
In some cases, it may be useful for proxies in the SIP signaling path to see all the messaging between the endpoints for the whole session 👀 For example, if the biloxi.com proxy server wanted to stay in the SIP messaging path beyond the initial INVITE, it would add a required routing header field called Record-Route to the INVITE. That header holds a URI resolving to the hostname or IP address of the proxy 🛣️ Bob's SIP phone receives this info, and so does Alice's softphone (because the Record-Route header field gets passed back in the 200 (OK)), and both store it for the duration of the dialog 💾 The biloxi.com proxy server then receives and proxies the ACK, the BYE, and the 200 (OK) to the BYE 🎀 Each proxy can independently decide to receive subsequent messages, and those messages pass through all the proxies that chose to receive them 🧚 This is frequently used by proxies that provide mid-call features ✨
Registration is another common operation in SIP 📝 It's one way the biloxi.com server can learn Bob's current location 📍 When Bob's SIP phone initializes, and then at periodic intervals, it sends REGISTER messages to a server in the biloxi.com domain known as a SIP registrar 💌 The REGISTER messages associate Bob's SIP or SIPS URI (sip:bob@biloxi.com) with the machine he's currently logged into, which is conveyed as a SIP or SIPS URI in the Contact header field 💖 The registrar writes this association, also called a binding, to a database called the location service, where the proxy in the biloxi.com domain can use it 🗄️ Often, the registrar for a domain is co-located with the proxy for that domain 🏠 And here's a key concept, bestie 🫶 The distinction between types of SIP servers is logical, not physical. 🌈
Bob can register from more than one device at a time. Say his SIP phone at home and the one at the office both send registrations. All of that information is stored together in the location service, which lets a proxy run different kinds of searches to track Bob down. ✨ On top of that, more than one user can be registered on a single device at the same time. 🦋
The location service is more of an abstract idea than a physical box. 💅 Generally, it holds information that lets a proxy put in a URI and get back a set of zero or more URIs that tell it where to send the request. Registrations are one way to fill it up, but they're not the only way. 🌸 An administrator can configure arbitrary mapping functions however they like.
Here's the important bit, bestie: in SIP, registration is used for routing incoming requests, and it has no role in authorizing outgoing requests. 🔥 Authentication and authorization happen either request by request, using a challenge/response mechanism, or through a lower-layer scheme, which is covered in Section 26. 🫶
The full set of SIP message details for this registration example lives in Section 24.1. 🎀
Other operations, like OPTIONS (for asking a SIP server or client what its capabilities are) and CANCEL (for canceling a pending request), will show up in later sections. 🧚
5. Structure of the Protocol ✨
Okay so SIP is built as a layered protocol. 💜 That means its behavior is described as a bunch of fairly independent processing stages, with only a loose coupling between each one. The layers are there for presentation, so common functions across elements can be described in one spot. 🌈 They don't dictate how you implement anything. When we say an element "contains" a layer, we just mean it follows the set of rules that layer defines. 💖
Not every element has every layer, and elements in SIP are logical, not physical. 🦋 A physical device can choose to act as different logical elements, maybe even switching roles from one transaction to the next. 👑
The lowest layer is syntax and encoding. The encoding is specified using an augmented Backus-Naur Form grammar (BNF). The complete BNF is in Section 25, and an overview of what a SIP message looks like is in Section 7. 🍓
The second layer is the transport layer, and it's giving "how do I actually move bits" energy. 🌸 It defines how a client sends requests and receives responses, and how a server receives requests and sends responses over the network. Every SIP element has a transport layer. It's described in Section 18. 🚀
The third layer is the transaction layer, and transactions are a fundamental part of SIP, obsessed. 😭 A transaction is a request sent by a client transaction (using the transport layer) to a server transaction, plus all the responses to that request sent from the server transaction back to the client. The transaction layer handles application-layer retransmissions, matching responses to requests, and application-layer timeouts. Any task a user agent client (UAC) accomplishes happens through a series of transactions. You can read more about transactions in Section 17. 💅 User agents contain a transaction layer, and so do stateful proxies. Stateless proxies do not. Each transaction layer has a client component (a client transaction) and a server component (a server transaction), and each of those is a finite state machine built to process one particular request. 🔥
The layer above that is the transaction user (TU). Every SIP entity is a transaction user, except the stateless proxy. When a TU wants to send a request, it creates a client transaction instance and hands it the request, along with the destination IP address, port, and transport to send it to. A TU that created a client transaction can also cancel it. ✨ When a client cancels a transaction, it's asking the server to stop further processing, go back to the state that existed before the transaction started, and generate a specific error response to that transaction. This happens with a CANCEL request. That request is its own transaction, but it references the transaction being canceled (Section 9). 🙈
Now the SIP elements themselves, meaning user agent clients and servers, stateless and stateful proxies, and registrars, each contain a core that makes them different from one another. 💖 Cores, except for the stateless proxy, are transaction users. The UAC and UAS cores behave differently depending on the method, but there are some common rules that apply to every method (Section 8). For a UAC, those rules govern how a request gets built. For a UAS, they govern how a request gets processed and how a response gets generated. 🎀 Because registrations are such a big deal in SIP, a UAS that handles a REGISTER gets the special name registrar. 👑 Section 10 describes UAC and UAS core behavior for the REGISTER method, and Section 11 describes it for the OPTIONS method, which is used to figure out the capabilities of a UA. 🧚
Certain other requests get sent within a dialog. 🦋 A dialog is a peer-to-peer SIP relationship between two user agents that lasts for some time. It helps with sequencing messages and routing requests properly between the user agents. The INVITE method is the only way defined in this specification to establish a dialog, so it's kind of the main character. 👑 When a UAC sends a request within the context of a dialog, it follows the common UAC rules from Section 8, and also the rules for mid-dialog requests. Section 12 covers dialogs, how they're constructed and maintained, and how requests get constructed within a dialog. 🌈
The most important method in SIP is INVITE, which is used to establish a session between participants. 🔥 A session is a collection of participants, plus streams of media between them, for the purposes of communicating. Section 13 covers how sessions get initiated, which results in one or more SIP dialogs. Section 14 covers how a session's characteristics get changed using an INVITE request within a dialog. And Section 15 covers how a session gets terminated. 💀
Sections 8, 10, 11, 12, 13, 14, and 15 deal entirely with the UA core. (Section 9 describes cancellation, which applies to both the UA core and the proxy core. 🫶) Section 16 covers the proxy element, which helps route messages between user agents. 🌸
6. Definitions 🌷
The following terms have special significance for SIP, so pay attention, bestie. 💜
- Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI that points to a domain with a location service that can map the URI to another URI where the user might be available. Usually the location service gets populated through registrations. An AOR is often thought of as the "public address" of the user. 💌
- Back-to-Back User Agent: A back-to-back user agent (B2BUA) is a logical entity that receives a request and processes it as a user agent server (UAS). To figure out how the request should be answered, it acts as a user agent client (UAC) and generates requests. Unlike a proxy server, it maintains dialog state and must participate in all requests sent on the dialogs it has established. Since it's a concatenation of a UAC and a UAS, no explicit definitions are needed for its behavior. 🦋
- Call: A call is an informal term that refers to some communication between peers, generally set up for the purposes of a multimedia conversation. 📞
- Call Leg: Another name for a dialog [31]; no longer used in this specification. 🙅♀️
- Call Stateful: A proxy is call stateful if it retains state for a dialog from the initiating INVITE to the terminating BYE request. A call stateful proxy is always transaction stateful, but the converse is not necessarily true. 🧠
- Client: A client is any network element that sends SIP requests and receives SIP responses. Clients may or may not interact directly with a human user. User agent clients and proxies are clients. 🌸
- Conference: A multimedia session (see below) that contains multiple participants. 🎉
- Core: Core designates the functions specific to a particular type of SIP entity, i.e., specific to either a stateful or stateless proxy, a user agent or registrar. All cores, except those for the stateless proxy, are transaction users. 💅
- Dialog: A dialog is a peer-to-peer SIP relationship between two UAs that persists for some time. A dialog is established by SIP messages, such as a 2xx response to an
INVITErequest. A dialog is identified by a call identifier, a local tag, and a remote tag. A dialog was formerly known as a call leg in RFC 2543. 🦋 - Downstream: A direction of message forwarding within a transaction that refers to the direction that requests flow from the user agent client to user agent server. ⬇️
- Final Response: A response that terminates a SIP transaction, as opposed to a provisional response that does not. All 2xx, 3xx, 4xx, 5xx and 6xx responses are final. 🏁
- Header: A header is a component of a SIP message that conveys information about the message. It is structured as a sequence of header fields. 📮
- Header Field: A header field is a component of the SIP message header. A header field can appear as one or more header field rows. Header field rows consist of a header field name and zero or more header field values. Multiple header field values on a given header field row are separated by commas. Some header fields can only have a single header field value, and as a result, always appear as a single header field row. 🧩
- Header Field Value: A header field value is a single value; a header field consists of zero or more header field values. 🍬
- Home Domain: The domain providing service to a SIP user. Typically, this is the domain present in the URI in the address-of-record of a registration. 🏠
- Informational Response: Same as a provisional response. ℹ️
- Initiator, Calling Party, Caller: The party initiating a session (and dialog) with an
INVITErequest. A caller retains this role from the time it sends the initialINVITEthat established a dialog until the termination of that dialog. 📣 - Invitation: An
INVITErequest. 💌 - Invitee, Invited User, Called Party, Callee: The party that receives an
INVITErequest for the purpose of establishing a new session. A callee retains this role from the time it receives theINVITEuntil the termination of the dialog established by thatINVITE. 🎀 - Location Service: A location service is used by a SIP redirect or proxy server to obtain information about a callee's possible location(s). It contains a list of bindings of address-of-record keys to zero or more contact addresses. The bindings can be created and removed in many ways; this specification defines a
REGISTERmethod that updates the bindings. 🗺️
Loop: okay so this one is giving déjà vu 💀. A request arrives at a proxy, gets forwarded, and then comes right back to that SAME proxy. The second time it shows up, its Request-URI is identical to the first time, and the other header fields that affect proxy operation haven't changed. So the proxy would make the exact same decision it made before 🔁. Looped requests are errors ❌, and the protocol explains how to detect them and handle them 🛠️.
Loose Routing: a proxy is loose routing if it follows the procedures in this specification for processing the Route header field 🦋. These procedures separate the destination of the request (which lives in the Request-URI) from the set of proxies that need to be visited along the way (which lives in the Route header field). A proxy that follows these mechanisms is also known as a loose router 💜.
Message: data sent between SIP elements as part of the protocol 📨. SIP messages are either requests or responses, no in-between 🫶.
Method: the method is the primary function a request is meant to invoke on a server ✨. It's carried in the request message itself. Example methods are INVITE and BYE 📞.
Outbound Proxy: a proxy that receives requests from a client, even though it may not be the server resolved by the Request-URI 🌸. Typically, a UA is manually configured with an outbound proxy, or it can learn about one through auto-configuration protocols 🧚.
Parallel Search: in a parallel search, a proxy sends out several requests to possible user locations as soon as an incoming request arrives 🔥. Instead of sending one request and then waiting for the final response before trying the next one (that's the sequential search energy), a parallel search fires off requests without waiting for the results of the previous ones 🏃♀️💨.
Provisional Response: a response the server uses to show progress, but it does NOT end the SIP transaction 🌈. 1xx responses are provisional, and every other response is considered final 🏁.
Proxy, Proxy Server: an intermediary entity that acts as both a server and a client, so it can make requests on behalf of other clients 🎀. A proxy server mainly plays the role of routing, which means its job is to make sure a request gets sent to another entity "closer" to the targeted user 🗺️. Proxies are also useful for enforcing policy (for example, making sure a user is allowed to make a call) 👑. A proxy interprets, and, if necessary, rewrites specific parts of a request message before forwarding it ✏️.
Recursion: a client recurses on a 3xx response when it generates a new request to one or more of the URIs in the Contact header field in that response 🔁💅.
Redirect Server: a redirect server is a user agent server that generates 3xx responses to the requests it receives, directing the client to contact an alternate set of URIs 🧭.
Registrar: a registrar is a server that accepts REGISTER requests and places the information it receives in those requests into the location service for the domain it handles 📍.
Regular Transaction: a regular transaction is any transaction with a method other than INVITE, ACK, or CANCEL 🍓.
Request: a SIP message sent from a client to a server, for the purpose of invoking a particular operation 🙋♀️.
Response: a SIP message sent from a server to a client, for indicating the status of a request the client sent to the server 💌.
Ringback: ringback is the signaling tone produced by the calling party's application, which tells them the called party is being alerted (ringing) 📳🔔.
Route Set: a route set is a collection of ordered SIP or SIPS URIs that represent a list of proxies which must be traversed when sending a particular request 🗂️. A route set can be learned through headers like Record-Route, or it can be configured ⚙️.
Server: a server is a network element that receives requests in order to service them, and sends back responses to those requests 🖥️. Examples of servers are proxies, user agent servers, redirect servers, and registrars 🌟.
Sequential Search: in a sequential search, a proxy server tries each contact address in order, moving on to the next one only after the previous one has produced a final response 🐢. A 2xx or 6xx class final response always ends a sequential search 🛑.
Session: from the SDP specification: "A multimedia session is a set of multimedia senders and receivers and the data streams flowing from senders to receivers. A multimedia conference is an example of a multimedia session." (RFC 2327 [1]) (A session as defined for SDP can comprise one or more RTP sessions.) As defined, a callee can be invited several times, by different calls, to the same session 🎶. If SDP is used, a session is defined by the concatenation of the SDP user name, session id, network type, address type, and address elements in the origin field 🧾.
SIP Transaction: a SIP transaction happens between a client and a server, and it includes all the messages from the first request the client sends to the server, up to a final (non-1xx) response sent from the server back to the client 🎬. If the request is INVITE and the final response is a non-2xx, the transaction also includes an ACK to that response 🙌. The ACK for a 2xx response to an INVITE request is its own separate transaction 💫.
Spiral: a spiral is a SIP request that gets routed to a proxy, forwarded onwards, and then arrives back at that same proxy, but this time it's different in a way that leads to a different processing decision than the original request did 🌀. Typically, this means the request's Request-URI differs from what it was on its previous arrival. A spiral is NOT an error condition, unlike a loop 🙅♀️💖. A typical cause is call forwarding 📲. Say joe@example.com gets a call: the example.com proxy forwards it to Joe's PC, which in turn forwards it to bob@example.com. This request is proxied back to the example.com proxy 🔄. However, this is not a loop, because the request is now targeted at a different user, so it counts as a spiral, and it's totally valid 🫧.
Stateful Proxy: a logical entity that maintains the client and server transaction state machines defined by this specification while it processes a request. It's also known as a transaction stateful proxy 🧠. The behavior of a stateful proxy is further defined in Section 16 📚. A (transaction) stateful proxy is NOT the same thing as a call stateful proxy 🙅♀️.
Stateless Proxy: a logical entity that does not maintain the client or server transaction state machines defined in this specification when it processes requests 🪶. A stateless proxy forwards every request it receives downstream, and every response it receives upstream 💨.
Strict Routing: a proxy is strict routing if it follows the Route processing rules of RFC 2543 and many prior work-in-progress versions of this RFC 🕰️. That rule caused proxies to destroy the contents of the Request-URI whenever a Route header field was present 😱. Strict routing behavior is NOT used in this specification, in favor of loose routing behavior 🙅♀️. Proxies that perform strict routing are also known as strict routers 🚧.
Target Refresh Request: a target refresh request sent within a dialog is defined as a request that can modify the remote target of the dialog 🎯.
Transaction User (TU): the layer of protocol processing that sits above the transaction layer 🍰. Transaction users include the UAC core, UAS core, and proxy core 🧁.
Upstream: a direction of message forwarding within a transaction, referring to the direction responses flow, from the user agent server back to the user agent client ⬆️.
URL-encoded: a character string encoded according to RFC 2396, Section 2.4 [5] 🔤.
User Agent Client (UAC): a user agent client is a logical entity that creates a new request, and then uses the client transaction state machinery to send it 📤. The UAC role lasts only for the duration of that transaction. In other words, if a piece of software initiates a request, it acts as a UAC for the duration of that transaction 💅. If it receives a request later, it takes on the role of a user agent server for processing that transaction 🔀.
UAC Core: the set of processing functions required of a UAC that sit above the transaction and transport layers 🧩.
User Agent Server (UAS): a user agent server is a logical entity that generates a response to a SIP request 🙆♀️. The response accepts, rejects, or redirects the request ✅❌↪️. This role lasts only for the duration of that transaction. In other words, if a piece of software responds to a request, it acts as a UAS for the duration of that transaction 🎟️. If it generates a request later, it takes on the role of a user agent client for processing that transaction 🔁.
UAS Core: the set of processing functions required at a UAS that sit above the transaction and transport layers 🏗️.
User Agent (UA): a logical entity that can act as both a user agent client and a user agent server 🦸♀️.
The roles of UAC and UAS, as well as proxy and redirect servers, are defined on a transaction-by-transaction basis 🎭. For example, the user agent that initiates a call acts as a UAC when it sends the initial INVITE request, and as a UAS when it receives a BYE request from the callee 📱. Similarly, the same software can act as a proxy server for one request and as a redirect server for the next request 🌈.
Proxy, location, and registrar servers defined above are logical entities; implementations MAY combine them into a single application 🫶✨.
7. SIP Messages 💖
okay bestie, SIP is a text-based protocol and it speaks UTF-8 (see RFC 2279 [7]) 🌸
every SIP message is either a request going from a client to a server, or a response going from a server back to a client 💅
requests (Section 7.1) and responses (Section 7.2) both borrow the basic format of RFC 2822 [3], even though the character set and syntax details are a little different. SIP even lets header fields exist that wouldn't be valid RFC 2822 header fields, which is so iconic 🦋 Either way, both message types have a start-line, one or more header fields, an empty line that marks the end of the headers, and an optional message-body 🎀
generic-message = start-line
*message-header
CRLF
[ message-body ]
start-line = Request-Line / Status-Linethe start-line, each message-header line, and the empty line MUST be terminated by a carriage-return line-feed sequence (CRLF). and the empty line MUST be there even if there's no message-body, so don't skip it 🙈
apart from that charset difference, a lot of SIP's message and header syntax is identical to HTTP/1.1 🌈 instead of copying it all out, we point at it: [HX.Y] means Section X.Y of the current HTTP/1.1 specification (RFC 2616 [8]).
but SIP is not an extension of HTTP, so don't get it twisted 💀
7.1. Requests
SIP requests are easy to spot because their start-line is a Request-Line 🧚 A Request-Line holds a method name, a Request-URI, and the protocol version, all separated by a single space (SP) character.
the Request-Line ends with CRLF. no CR or LF is allowed anywhere except in that end-of-line CRLF sequence, and no linear whitespace (LWS) is allowed in any of the elements ✨
Request-Line = Method SP Request-URI SP SIP-Version CRLF- Method: This specification defines six methods:
REGISTERfor registering contact information,INVITE,ACK, andCANCELfor setting up sessions,BYEfor terminating sessions, andOPTIONSfor querying servers about their capabilities. SIP extensions, documented in standards track RFCs, may define additional methods. 🔥 - Request-URI: The Request-URI is a SIP or SIPS URI as described in Section 19.1 or a general URI (RFC 2396 [5]). It indicates the user or service to which this request is being addressed. The Request-URI MUST NOT contain unescaped spaces or control characters and MUST NOT be enclosed in "<>". 💖
SIP elements MAY support Request-URIs with schemes other than "sip" and "sips", for example the "tel" URI scheme of RFC 2806 [9]. SIP elements MAY translate non-SIP URIs using any mechanism at their disposal, resulting in SIP URI, SIPS URI, or some other scheme. 🦋
- SIP-Version: Both request and response messages include the version of SIP in use, and follow [H3.1] (with HTTP replaced by SIP, and HTTP/1.1 replaced by SIP/2.0) regarding version ordering, compliance requirements, and upgrading of version numbers. To be compliant with this specification, applications sending SIP messages MUST include a SIP-Version of "SIP/2.0". The SIP-Version string is case-insensitive, but implementations MUST send upper-case. 🎀
Unlike HTTP/1.1, SIP treats the version number as a literal string. In practice, this should make no difference. 🙄
7.2. Responses
SIP responses are the opposite of requests, so their start-line is a Status-Line instead 🌸 A Status-Line is the protocol version, then a numeric Status-Code, then its textual phrase, all separated by a single SP character.
again, no CR or LF is allowed except in the final CRLF sequence 💅
Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLFthe Status-Code is a 3-digit integer result code that tells you the outcome of an attempt to understand and satisfy a request 🍓 The Reason-Phrase is meant to be a short text description of that Status-Code. the Status-Code is for automata (aka machines), while the Reason-Phrase is for the human user. a client is not required to examine or display the Reason-Phrase, so it's totally fine to ignore it 🤖
this spec suggests some wording for the reason phrase, but implementations MAY choose other text, for example in the language named in the Accept-Language header field of the request 🌍
the first digit of the Status-Code tells you the class of the response. the last two digits don't have any categorization role ✨ so any response with a status code from 100 to 199 is called a "1xx response", 200 to 299 is a "2xx response", and so on. SIP/2.0 allows six values for the first digit:
1xx: Provisional -- request received, continuing to process the request;2xx: Success -- the action was successfully received, understood, and accepted;3xx: Redirection -- further action needs to be taken in order to complete the request;4xx: Client Error -- the request contains bad syntax or cannot be fulfilled at this server;5xx: Server Error -- the server failed to fulfill an apparently valid request;6xx: Global Failure -- the request cannot be fulfilled at any server. 😭
Section 21 defines these classes and describes the individual codes 👑
7.3. Header Fields
SIP header fields are basically cousins of HTTP header fields, with similar syntax and semantics 🫶 In particular, SIP header fields follow the [H4.2] definitions of syntax for the message-header and the rules for extending header fields over multiple lines. the one twist is that HTTP spells that multi-line rule out with implicit whitespace and folding. this spec conforms to RFC 2234 [10] and uses only explicit whitespace and folding, as part of the grammar itself 🧠
[H4.2] also says that multiple header fields with the same field name, whose value is a comma-separated list, can be combined into one header field. that works for SIP too, but the exact rule is a bit different because the grammars are different. specifically, any SIP header whose grammar looks like this:
header = "header-name" HCOLON header-value *(COMMA header-value)can have same-name header fields combined into a comma-separated list 💜 The Contact header field allows a comma-separated list unless the header field value is "*".
7.3.1. Header Field Format
header fields follow the same generic header format given in Section 2.2 of RFC 2822 [3]. each header field has a field name, then a colon (":"), then the field value 🌷
field-name: field-valuethe formal grammar for a message-header, which lives in Section 25, allows any amount of whitespace on either side of the colon. however, implementations should avoid spaces between the field name and the colon, and use a single space (SP) between the colon and the field-value. the examples below are all valid and equivalent, but the last one is the preferred form 🎀
Subject: lunch
Subject : lunch
Subject :lunch
Subject: lunchheader fields can stretch over multiple lines by starting each extra line with at least one SP or horizontal tab (HT). the line break and the whitespace at the start of the next line get treated as one single SP character. so these two are equivalent 🦋
Subject: I know you're there, pick up the phone and talk to me!
Subject: I know you're there,
pick up the phone
and talk to me!the relative order of header fields with different field names doesn't matter ✨ but it is RECOMMENDED that header fields needed for proxy processing (Via, Route, Record-Route, Proxy-Require, Max-Forwards, and Proxy-Authorization, for example) show up near the top of the message, so they can be parsed quickly 🏃♀️ the relative order of header field rows with the same field name DOES matter, though 😤
multiple header field rows with the same field-name MAY be in a message if and only if the entire field-value for that header is defined as a comma-separated list (that is, if it follows the grammar in Section 7.3). and they MUST be combinable into one "field-name: field-value" pair without changing the message's semantics, by appending each later field-value to the first one, separated by a comma 🔥 the exceptions are the WWW-Authenticate, Authorization, Proxy-Authenticate, and Proxy-Authorization header fields. multiple rows with those names MAY be in a message, but since their grammar doesn't follow the general form from Section 7.3, they MUST NOT be combined into a single header field row 💀
implementations MUST be able to process multiple header field rows with the same name in any mix of the single-value-per-line or comma-separated forms 💖
these groups of header field rows are valid and equivalent 👑
Route: <sip:alice@atlanta.com>
Subject: Lunch
Route: <sip:bob@biloxi.com>
Route: <sip:carol@chicago.com>
Route: <sip:alice@atlanta.com>, <sip:bob@biloxi.com>
Route: <sip:carol@chicago.com>
Subject: Lunch
Subject: Lunch
Route: <sip:alice@atlanta.com>, <sip:bob@biloxi.com>,
<sip:carol@chicago.com>but each of these blocks is valid and NOT equivalent to the others, which is the kind of plot twist that ruins a whole Tuesday 😭
Route: <sip:alice@atlanta.com>
Route: <sip:bob@biloxi.com>
Route: <sip:carol@chicago.com>
Route: <sip:bob@biloxi.com>
Route: <sip:alice@atlanta.com>
Route: <sip:carol@chicago.com>
Route: <sip:alice@atlanta.com>,<sip:carol@chicago.com>,
<sip:bob@biloxi.com>the format of a header field-value is defined per header-name. it will always be either an opaque sequence of TEXT-UTF8 octets, or a mix of whitespace, tokens, separators, and quoted strings 🌈 lots of existing header fields follow the general pattern of a value followed by a semicolon-separated list of parameter-name, parameter-value pairs:
field-name: field-value *(;parameter-name=parameter-value)even though you can attach any number of parameter pairs to a header field value, any given parameter-name MUST NOT appear more than once 🚫
when comparing header fields, field names are always case-insensitive. unless a particular header field's definition says otherwise, field values, parameter names, and parameter values are case-insensitive too. tokens are always case-insensitive. unless specified otherwise, values written as quoted strings are case-sensitive 🎀 for example, these are equivalent:
Contact: <sip:alice@atlanta.com>;expires=3600 CONTACT: <sip:alice@atlanta.com>;ExPiReS=3600and these are equivalent too:
Content-Disposition: session;handling=optional content-disposition: Session;HANDLING=OPTIONALbut these two are NOT equivalent, because quoted strings are case-sensitive, so "Choose a bigger pipe" and "CHOOSE A BIGGER PIPE" are two different warnings 🍓
Warning: 370 devnull "Choose a bigger pipe"
Warning: 370 devnull "CHOOSE A BIGGER PIPE"7.3.2 Header Field Classification ✨
okay so some header fields only make sense in requests, and some only make sense in responses 🎀. These are called request header fields and response header fields, respectively. If a header field shows up in a message that doesn't match its category (like a request header field in a response), it MUST be ignored 🙅♀️. Section 20 defines the classification of each header field 💅, so that's your go-to list.
7.3.3 Compact Form 🦋
SIP has a shortcut system for common header field names, so you don't have to write out the full thing every time 🌸. This is lowkey essential when messages get too big for the transport they're riding on (going over the maximum transmission unit (MTU) when you're using UDP, for example) 😭. These compact forms are defined in Section 20. A compact form MAY be swapped in for the longer form of a header field name at any time without changing the semantics of the message ✨. A header field name MAY even show up in both long and short forms within the same message, periodt 💅. Implementations MUST accept both the long and short forms of each header name 🫶. No exceptions, bestie!
7.4 Bodies 🎀
Requests, including new requests defined in extensions to this specification, MAY contain message bodies unless otherwise noted 💖. The interpretation of the body depends on the request method, so it's giving context-dependent vibes 🌈.
For response messages, the request method and the response status code decide the type and interpretation of any message body 🧚. All responses MAY include a body 💜.
7.4.1 Message Body Type 💌
The Internet media type of the message body MUST be given by the Content-Type header field 🍓. If the body has been encoded in any way (like compression), that MUST be indicated by the Content-Encoding header field 🔥. Otherwise, Content-Encoding MUST be omitted 🙈. If it applies, the character set of the message body is indicated as part of the Content-Type header-field value ✨.
The "multipart" MIME type defined in RFC 2046 [11] MAY be used within the body of the message 🌸. Implementations that send requests containing multipart message bodies MUST send a session description as a non-multipart message body if the remote implementation asks for this through an Accept header field that does not contain multipart. Not optional, not negotiable 💅.
SIP messages MAY contain binary bodies or body parts 🦋. When the sender doesn't give an explicit charset parameter, media subtypes of the "text" type are defined to have a default charset value of "UTF-8" 🌈.
7.4.2 Message Body Length 📏
The body length in bytes is provided by the Content-Length header field 🎀. Section 20.14 describes the necessary contents of this header field in detail.
The "chunked" transfer encoding of HTTP/1.1 MUST NOT be used for SIP 🚫. (Note: the chunked encoding changes the body of a message so it can be sent as a series of chunks, each with its own size indicator 🤓.)
7.5 Framing SIP Messages 🧚♀️
Unlike HTTP, SIP implementations can use UDP or other unreliable datagram protocols 💫. Each of those datagrams carries exactly one request or response. See Section 18 for constraints on using unreliable transports 🔥.
Implementations processing SIP messages over stream-oriented transports MUST ignore any CRLF appearing before the start-line [H4.1] 🙈.
The Content-Length header field value is how you find the end of each SIP message in a stream. It will always be present when SIP messages are sent over stream-oriented transports. Don't skip this one, bestie 😭.
8 General User Agent Behavior 🎀
A user agent represents an end system 💻. It has a user agent client (UAC), which generates requests, and a user agent server (UAS), which responds to them 💖. A UAC can generate a request based on some external stimulus (like a user clicking a button, or a signal on a PSTN line) and then process the response 🦋. A UAS can receive a request and generate a response based on user input, external stimulus, the result of a program execution, or some other mechanism ✨.
When a UAC sends a request, it passes through some number of proxy servers, which forward the request toward the UAS 🌸. When the UAS generates a response, the response is forwarded toward the UAC 💜.
UAC and UAS procedures depend heavily on two things 🌈. First, whether the request or response is inside or outside of a dialog. Second, the method of the request 🧚. Dialogs are covered thoroughly in Section 12. They represent a peer-to-peer relationship between user agents and are established by specific SIP methods, such as INVITE 💅.
In this section, we talk about the method-independent rules for UAC and UAS behavior when processing requests that are outside of a dialog 🫶. That includes, of course, the requests that themselves establish a dialog 🔥.
Security procedures for requests and responses outside of a dialog are described in Section 26 😭. Specifically, mechanisms exist for the UAS and UAC to mutually authenticate 🔐. A limited set of privacy features is also supported through encryption of bodies using S/MIME 🙈.
8.1 UAC Behavior 📤
This section covers UAC behavior outside of a dialog 💫.
8.1.1 Generating the Request ✍️
A valid SIP request formulated by a UAC MUST, at a minimum, contain the following header fields: To, From, CSeq, Call-ID, Max-Forwards, and Via. All of these header fields are mandatory in all SIP requests, no cap 💯. These six header fields are the fundamental building blocks of a SIP message, because together they handle most of the critical message routing: addressing messages, routing responses, limiting message propagation, ordering messages, and uniquely identifying transactions 🧩. They sit alongside the mandatory request line, which contains the method, Request-URI, and SIP version 🎀.
Examples of requests sent outside of a dialog include an INVITE to establish a session (Section 13) and an OPTIONS to query for capabilities (Section 11) 🌷.
8.1.1.1 Request-URI 🎯
The initial Request-URI of the message SHOULD be set to the value of the URI in the To field 💖. One notable exception is the REGISTER method, and the behavior for setting the Request-URI of REGISTER is given in Section 10 📝. Setting these two fields to the same value might be undesirable for privacy reasons or for convenience (especially if the originating UA expects that the Request-URI will be changed during transit) 🙈.
In some special circumstances, a pre-existing route set can affect the Request-URI of the message 🧭. A pre-existing route set is an ordered set of URIs that identify a chain of servers, which a UAC will send outgoing requests to when they're outside of a dialog 🛤️. Usually they're configured on the UA by a user or service provider manually, or through some other non-SIP mechanism 🔧. When a provider wants to configure a UA with an outbound proxy, it is RECOMMENDED to do this by giving it a pre-existing route set with a single URI, the one for the outbound proxy 🦋.
When a pre-existing route set is present, the procedures for populating the Request-URI and Route header field detailed in Section 12.2.1.1 MUST be followed (even though there's no dialog), using the desired Request-URI as the remote target URI 🫶.
8.1.1.2 To 💌
The To header field first and foremost specifies the desired "logical" recipient of the request, or the address-of-record of the user or resource that is the target of this request 🎯. That may or may not be the ultimate recipient of the request 🌈. The To header field MAY contain a SIP or SIPS URI, but it can also use other URI schemes when that makes sense, like the tel URL (RFC 2806 [9]) 📞. All SIP implementations MUST support the SIP URI scheme 💖. Any implementation that supports TLS MUST support the SIPS URI scheme 🔐. The To header field allows for a display name 🎀.
A UAC can learn how to fill in the To header field for a particular request in a bunch of ways 🧠. Usually the user suggests the To header field through a human interface, maybe typing in the URI or picking it from an address book 📒. Honestly though, the user often won't type a complete URI, just a string of digits or letters (like "bob") 🙈. It's up to the UA to decide how to interpret that input 💅.
Using the string to form the user part of a SIP URI means the UA wants the name resolved in the domain on the right-hand side (RHS) of the at-sign, like sip:bob@example.com 🎯. Using it to form the user part of a SIPS URI means the UA wants to communicate securely, and the name is still resolved in the domain to the RHS of the at-sign 🔐. The RHS is often the home domain of the requestor, which lets the home domain process the outgoing request 🏠. That's super useful for features like "speed dial," which need the user part to be interpreted in the home domain ⚡. The tel URL is handy when the UA doesn't want to specify which domain should interpret a phone number the user typed in 📱. Instead, each domain the request passes through gets that chance 🛤️. For example, say a user in an airport logs in and sends requests through an outbound proxy in the airport ✈️. If they enter "411" (the phone number for local directory assistance in the United States), that needs to be interpreted and processed by the airport's outbound proxy, not the user's home domain 🗽. In this case, tel:411 is the right choice 🎉.
A request outside of a dialog MUST NOT contain a To tag, because the tag in the To field of a request identifies the peer of the dialog 🚫. Since no dialog has been established, there's no tag present 🙃.
For more on the To header field, see Section 20.39. Here's an example of a valid To header field 👇:
To: Carol <sip:carol@chicago.com>8.1.1.3 From 💁♀️
The From header field shows the logical identity of the initiator of the request, possibly the user's address-of-record 🪪. Like the To header field, it contains a URI and optionally a display name. SIP elements use it to decide which processing rules to apply to a request (for example, automatic call rejection) 🚦. Because of that, it's really important that the From URI does not contain IP addresses or the FQDN of the host the UA is running on, since those aren't logical names 🙅♀️.
The From header field allows for a display name. A UAC SHOULD use the display name "Anonymous", along with a syntactically correct but otherwise meaningless URI (like sip:thisis@anonymous.invalid), if the client's identity is meant to stay hidden 🕶️.
Usually, the value that fills the From header field in requests from a particular UA is pre-provisioned by the user or by the administrators of the user's local domain 🧾. If a UA is shared by multiple users, it might have switchable profiles that each include a URI for the identity of the profiled user 👯. Recipients of requests can authenticate the originator to make sure they really are who their From header field claims (see Section 22 for more on authentication) 🔍.
The From field MUST contain a new "tag" parameter, chosen by the UAC 🏷️. See Section 19.3 for details on choosing a tag 💅.
For more on the From header field, see Section 20.20. Examples:
From: "Bob" <sips:bob@biloxi.com> ;tag=a48s
From: sip:+12125551212@phone2net.com;tag=887s
From: Anonymous <sip:c8oqz84zk7z@privacy.org>;tag=hyh88.1.1.4 Call-ID
okay so the Call-ID header field is the unique ID that groups a whole series of messages together 🫶 It MUST be the same for all requests and responses sent by either UA in a dialog. It SHOULD be the same in each registration from a UA.
In a new request that a UAC creates outside of any dialog, the Call-ID header field MUST be picked by the UAC as a globally unique identifier over space and time, unless method-specific behavior overrides that. All SIP UAs must have a way to make sure the Call-ID header fields they produce won't be accidentally generated by any other UA 🔒 Also, when requests get retried after certain failure responses that ask for a change to the request (like a challenge for authentication), those retried requests are not treated as new requests. That means they don't need new Call-ID header fields. See Section 8.1.3.5 for more on that 💅
Using cryptographically random identifiers (RFC 1750 [12]) to generate Call-IDs is RECOMMENDED 🎀 Implementations MAY use the form "localid@host". Call-ID values are case-sensitive and get compared byte-by-byte.
Using cryptographically random identifiers gives you some protection against session hijacking and cuts down on the chance of accidental Call-ID collisions. Be careful with this one, bestie 😭
No provisioning or human interface is needed to pick the Call-ID header field value for a request 🧚 For more on the Call-ID header field, check out Section 20.8.
Example:
Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com8.1.1.5 CSeq
The CSeq header field is how we identify and order transactions 🦋 It has a sequence number and a method. The method MUST match that of the request. For non-REGISTER requests outside of a dialog, the sequence number value is arbitrary. The sequence number value MUST be expressible as a 32-bit unsigned integer and MUST be less than 2**31. As long as it follows those rules, a client may use any mechanism it likes to pick CSeq values ✨
Section 12.2.1.1 talks about how to build the CSeq for requests inside a dialog.
Example:
CSeq: 4711 INVITE8.1.1.6 Max-Forwards
The Max-Forwards header field limits how many hops a request can take on its way to its destination 🚦 It's an integer that goes down by one at each hop. If the Max-Forwards value hits 0 before the request reaches its destination, it gets rejected with a 483(Too Many Hops) error response 💀
A UAC MUST insert a Max-Forwards header field into each request it originates, with a value that SHOULD be 70. This number was picked to be big enough that a request won't get dropped in any SIP network when there are no loops, but not so big that it eats up proxy resources when a loop does happen 🌈 Lower values should be used with caution, and only in networks where the UA knows the topologies.
8.1.1.7 Via
The Via header field shows the transport used for the transaction and tells everyone where the response should go 🗺️ A Via header field value only gets added after the transport that'll be used to reach the next hop has been picked. (That step might involve the procedures in [4].)
When the UAC creates a request, it MUST insert a Via into that request. The protocol name and protocol version in the header field MUST be SIP and 2.0, respectively. The Via header field value MUST contain a branch parameter. This parameter identifies the transaction created by that request, and both the client and the server use it 🫶
The branch parameter value MUST be unique across space and time for all requests the UA sends. There are two exceptions: CANCEL and ACK for non-2xx responses. As we'll see below, a CANCEL request has the same branch parameter value as the request it cancels. As discussed in Section 17.1.1.3, an ACK for a non-2xx response also has the same branch ID as the INVITE whose response it acknowledges.
The uniqueness property of the branch ID parameter, which makes it useful as a transaction ID, was not part of RFC 2543. Glow-up era 🌸
The branch ID inserted by an element that follows this specification MUST always begin with the characters "z9hG4bK". These 7 characters are a magic cookie. (7 is considered enough to make sure an older RFC 2543 implementation wouldn't pick such a value.) That way, servers that receive the request can tell the branch ID was built the way this specification describes, meaning it's globally unique 🔥 Beyond this requirement, the exact format of the branch token is implementation-defined.
The maddr, ttl, and sent-by components of the Via header get set when the transport layer processes the request (Section 18) ✨
Via processing for proxies is described in Section 16.6 Item 8 and Section 16.7 Item 3.
8.1.1.8 Contact
The Contact header field gives a SIP or SIPS URI that can be used to reach that specific instance of the UA for later requests 📞 The Contact header field MUST be present and MUST contain exactly one SIP or SIPS URI in any request that can result in a dialog being established. For the methods defined in this specification, that's only the INVITE request. For these requests, the scope of the Contact is global. In other words, the Contact header field value holds the URI where the UA wants to receive requests, and that URI MUST be valid even when it's used in later requests outside of any dialog 👑
If the Request-URI or top Route header field value contains a SIPS URI, the Contact header field MUST contain a SIPS URI as well.
For more on the Contact header field, see Section 20.10.
8.1.1.9 Supported and Require
If the UAC supports SIP extensions that the server can apply to the response, the UAC SHOULD include a Supported header field in the request, listing the option tags (Section 19.2) for those extensions 💖
The option tags listed MUST only refer to extensions defined in standards-track RFCs. This stops servers from insisting that clients implement non-standard, vendor-defined features just to get service 🙅♀️ Extensions defined in experimental and informational RFCs are explicitly excluded from use with the Supported header field in a request, since those are often used to document vendor-defined extensions too.
If the UAC wants to insist that a UAS understands an extension that the UAC will apply to the request in order to process it, the UAC MUST insert a Require header field into the request, listing the option tag for that extension. If the UAC wants to apply an extension to the request and insist that any proxies traversed understand it, the UAC MUST insert a Proxy-Require header field into the request, listing the option tag for that extension 🎯
As with the Supported header field, the option tags in the Require and Proxy-Require header fields MUST only refer to extensions defined in standards-track RFCs.
8.1.1.10 Additional Message Components
After a new request has been created and the header fields described above have been properly built, any additional optional header fields get added, along with any header fields specific to the method 🍓
SIP requests MAY contain a MIME-encoded message-body. No matter what kind of body a request has, certain header fields must be filled in to describe the body's contents. For more on those header fields, see Sections 20.11 through 20.15.
8.1.2. Sending the Request
Next up, we compute the destination for the request 🧭 Unless local policy says otherwise, the destination MUST be determined by applying the DNS procedures described in [4] as follows. If the first element in the route set indicated a strict router (which results in forming the request as described in Section 12.2.1.1), the procedures MUST be applied to the Request-URI of the request. Otherwise, the procedures are applied to the first Route header field value in the request (if one exists), or to the request's Request-URI if there's no Route header field. These procedures yield an ordered set of addresses, ports, and transports to try. No matter which URI goes into the procedures of [4], if the Request-URI points to a SIPS resource, the UAC MUST follow the procedures of [4] as if the input URI were a SIPS URI 🔐
Local policy MAY specify an alternate set of destinations to try. If the Request-URI contains a SIPS URI, any alternate destinations MUST be contacted with TLS. Beyond that, there are no restrictions on the alternate destinations if the request has no Route header field. This is a simple alternative to a pre-existing route set for specifying an outbound proxy. However, that approach to configuring an outbound proxy is NOT RECOMMENDED. A pre-existing route set with a single URI SHOULD be used instead 🌸 If the request contains a Route header field, the request SHOULD be sent to the locations derived from its topmost value, but MAY be sent to any server that the UA is certain will honor the Route and Request-URI policies specified in this document (as opposed to those in RFC 2543). In particular, a UAC configured with an outbound proxy SHOULD try to send the request to the location in the first Route header field value, instead of adopting the policy of sending every message to the outbound proxy.
This makes sure outbound proxies that don't add Record-Route header field values drop out of the path of later requests. It also lets endpoints that can't resolve the first Route URI hand that job off to an outbound proxy 🙌
The UAC SHOULD follow the procedures defined in [4] for stateful elements, trying each address until a server is contacted. Each try counts as a new transaction, so each one carries a different topmost Via header field value with a new branch parameter 🦋 Also, the transport value in the Via header field gets set to whatever transport was determined for the target server.
8.1.3. Processing Responses
Responses get processed by the transport layer first, then passed up to the transaction layer. The transaction layer does its processing and then passes the response up to the TU. Most response processing in the TU is method-specific, but there are some general behaviors that don't depend on the method 💅
8.1.3.1 Transaction Layer Errors
Sometimes the response the transaction layer hands back isn't a SIP message at all, but a transaction layer error 🙈 When a timeout error comes from the transaction layer, it MUST be treated as if a 408 (Request Timeout) status code had been received. If the transport layer reports a fatal transport error (usually from fatal ICMP errors in UDP or connection failures in TCP), the condition MUST be treated as a 503 (Service Unavailable) status code ⭐
8.1.3.2 Unrecognized Responses 🦋
okay so bestie, a UAC MUST treat any final response it doesn't recognize as the x00 response code of that class (basically the generic catch-all for its family), and it MUST be able to handle the x00 code for every class 💅. For example, if a UAC gets an unrecognized 431, it can safely assume its request was the problem and treat it like a 400 (Bad Request) 🙈. A UAC MUST treat any provisional response other than 100 that it doesn't recognize as a 183 (Session Progress) ✨. And a UAC MUST be able to process 100 and 183 responses, periodt 💖.
8.1.3.3 Vias 🌸
If more than one Via header field value shows up in a response, the UAC SHOULD discard the message 🗑️
Extra Via header field values that come before the originator of the request are a big red flag 🚩. They suggest the message was misrouted or possibly corrupted, and that's giving not safe energy 😭.
8.1.3.4 Processing 3xx Responses 🧚
Upon receipt of a redirection response (for example, a 301 response status code), clients SHOULD use the URI(s) in the Contact header field to formulate one or more new requests based on the redirected request. This is basically the same vibe as a proxy recursing on a 3xx class response, which you can read about in Sections 16.5 and 16.6 💜. A client starts with an initial target set containing exactly one URI, which is the Request-URI of the original request. If a client wants to make new requests based on a 3xx class response to that request, it puts the URIs it wants to try into the target set. Subject to the restrictions in this specification, a client gets to choose which Contact URIs go into the target set. As with proxy recursion, a client processing 3xx class responses MUST NOT add any given URI to the target set more than once. If the original request had a SIPS URI in the Request-URI, the client MAY choose to recurse to a non-SIPS URI, but SHOULD inform the user of the redirection to an insecure URI 🔐.
Any new request might get 3xx responses of its own that contain the original URI as a contact. Two locations can be set up to redirect to each other 🔁. Only putting any given URI in the target set once is what prevents infinite redirection loops 💀.
As the target set grows, the client MAY generate new requests to the URIs in any order. A common mechanism is to order the set by the q parameter value from the Contact header field value. Requests to the URIs MAY be generated serially or in parallel. One approach is to process groups of decreasing q-values serially, and to process the URIs in each q-value group in parallel. Another is to do only serial processing in decreasing q-value order, arbitrarily choosing between contacts of equal q-value 🎀.
If contacting an address in the list results in a failure, as defined in the next paragraph, the element moves to the next address in the list, until the list is exhausted. If the list is exhausted, then the request has failed 😤.
Failures SHOULD be detected through failure response codes (codes greater than 399). For network errors, the client transaction will report any transport layer failures to the transaction user. Note that some response codes (detailed in 8.1.3.5) indicate that the request can be retried, and requests that are reattempted should not be considered failures 🙌.
When a failure for a particular contact address is received, the client SHOULD try the next contact address. This involves creating a new client transaction to deliver a new request 🔄.
In order to create a request based on a contact address in a 3xx response, a UAC MUST copy the entire URI from the target set into the Request-URI, except for the method-param and header URI parameters (see Section 19.1.1 for a definition of these parameters). It uses the header parameters to create header field values for the new request, overwriting header field values associated with the redirected request in accordance with the guidelines in Section 19.1.5 ✨.
Note that in some instances, header fields that have been communicated in the contact address may instead append to existing request header fields in the original redirected request. As a general rule, if the header field can accept a comma-separated list of values, then the new header field value MAY be appended to any existing values in the original redirected request. If the header field does not accept multiple values, the value in the original redirected request MAY be overwritten by the header field value communicated in the contact address. For example, if a contact address is returned with the following value:
sip:user@host?Subject=foo&Call-Info=<http://www.foo.com>Then any Subject header field in the original redirected request is overwritten, but the HTTP URL is merely appended to any existing Call-Info header field values 🫶.
It is RECOMMENDED that the UAC reuse the same To, From, and Call-ID used in the original redirected request, but the UAC MAY also choose to update the Call-ID header field value for new requests, for example 🌈.
Finally, once the new request has been constructed, it is sent using a new client transaction, and therefore it MUST have a new branch ID in the top Via field, as discussed in Section 8.1.1.7 🦋.
In all other respects, requests sent upon receipt of a redirect response SHOULD re-use the header fields and bodies of the original request 💅.
In some instances, Contact header field values may be cached at the UAC temporarily or permanently, depending on the status code received and the presence of an expiration interval. See Sections 21.3.2 and 21.3.3 for the details 📚.
8.1.3.5 Processing 4xx Responses 💅
Certain 4xx response codes require specific UA processing, independent of the method. Let's go through them 👑.
If a 401 (Unauthorized) or 407 (Proxy Authentication Required) response is received, the UAC SHOULD follow the authorization procedures of Section 22.2 and Section 22.3 to retry the request with credentials 🔑.
If a 413 (Request Entity Too Large) response is received (Section 21.4.11), the request contained a body that was longer than the UAS was willing to accept. If possible, the UAC SHOULD retry the request, either omitting the body or using one of a smaller length 📦.
If a 415 (Unsupported Media Type) response is received (Section 21.4.13), the request contained media types that the UAS doesn't support. The UAC SHOULD retry sending the request, this time only using content with types listed in the Accept header field in the response, with encodings listed in the Accept-Encoding header field in the response, and with languages listed in the Accept-Language in the response 🌸.
If a 416 (Unsupported URI Scheme) response is received (Section 21.4.14), the Request-URI used a URI scheme the server doesn't support. The client SHOULD retry the request, this time using a SIP URI 🧚.
If a 420 (Bad Extension) response is received (Section 21.4.15), the request contained a Require or Proxy-Require header field listing an option-tag for a feature that a proxy or UAS doesn't support. The UAC SHOULD retry the request, this time omitting any extensions listed in the Unsupported header field in the response 🙈.
In all of the above cases, the request is retried by creating a new request with the appropriate modifications. This new request constitutes a new transaction and SHOULD have the same value of the Call-ID, To, and From as the previous request, but the CSeq should contain a new sequence number that is one higher than the previous one 🔢.
With other 4xx responses, including those yet to be defined, a retry may or may not be possible, depending on the method and the use case 🤷♀️.
8.2 UAS Behavior 🦋
When a request outside of a dialog is processed by a UAS, there is a set of processing rules that get followed, independent of the method. Section 12 gives guidance on how a UAS can tell whether a request is inside or outside of a dialog 💜.
Note that request processing is atomic. If a request is accepted, all state changes associated with it MUST be performed. If it is rejected, all state changes MUST NOT be performed ⚡.
UASs SHOULD process the requests in the order of the steps that follow in this section. That means starting with authentication, then inspecting the method, the header fields, and so on throughout the rest of this section 📋.
8.2.1 Method Inspection 🔍
Once a request is authenticated (or authentication is skipped), the UAS MUST inspect the method of the request. If the UAS recognizes but does not support the method of a request, it MUST generate a 405 (Method Not Allowed) response. Procedures for generating responses are described in Section 8.2.6. The UAS MUST also add an Allow header field to the 405 (Method Not Allowed) response. The Allow header field MUST list the set of methods supported by the UAS generating the message. The Allow header field is presented in Section 20.5 🚫.
If the method is one supported by the server, processing continues ✅.
8.2.2 Header Inspection 🎀
If a UAS does not understand a header field in a request (that is, the header field is not defined in this specification or in any supported extension), the server MUST ignore that header field and continue processing the message. A UAS SHOULD ignore any malformed header fields that aren't necessary for processing requests 🙈.
8.2.2.1 To and Request-URI 💌
The To header field identifies the original recipient of the request designated by the user identified in the From field. The original recipient may or may not be the UAS processing the request, due to call forwarding or other proxy operations. A UAS MAY apply any policy it wishes to determine whether to accept requests when the To header field is not the identity of the UAS. However, it is RECOMMENDED that a UAS accept requests even if they don't recognize the URI scheme (for example, a tel: URI) in the To header field, or if the To header field doesn't address a known or current user of this UAS 🫶. If, on the other hand, the UAS decides to reject the request, it SHOULD generate a response with a 403 (Forbidden) status code and pass it to the server transaction for transmission 🚪.
However, the Request-URI identifies the UAS that is to process the request. If the Request-URI uses a scheme the UAS doesn't support, it SHOULD reject the request with a 416 (Unsupported URI Scheme) response. If the Request-URI doesn't identify an address that the UAS is willing to accept requests for, it SHOULD reject the request with a 404 (Not Found) response. Typically, a UA that uses the REGISTER method to bind its address-of-record to a specific contact address will see requests whose Request-URI equals that contact address. Other potential sources of received Request-URIs include the Contact header fields of requests and responses sent by the UA that establish or refresh dialogs 🧚.
8.2.2.2 Merged Requests 👯
If the request has no tag in the To header field, the UAS core MUST check the request against ongoing transactions. If the From tag, Call-ID, and CSeq exactly match those associated with an ongoing transaction, but the request doesn't match that transaction (based on the matching rules in Section 17.2.3), the UAS core SHOULD generate a 482 (Loop Detected) response and pass it to the server transaction 🔁.
The same request has arrived at the UAS more than once, following different paths, most likely due to forking. The UAS processes the first such request received and responds with a 482 (Loop Detected) to the rest of them 🌀.
8.2.2.3 Require ✨
Okay so, assuming the UAS decides it's the right element to handle the request, it checks the Require header field if one is there 🎀
The Require header field is how a UAC tells a UAS about SIP extensions it expects the UAS to support so the request gets processed properly 💅. Its format is in Section 20.32. If a UAS doesn't understand an option-tag listed in a Require header field, it MUST respond by generating a response with status code 420 (Bad Extension) 💀. The UAS MUST add an Unsupported header field and list in it the options it doesn't understand from the ones in the request's Require header field 🫶.
Note that Require and Proxy-Require MUST NOT be used in a SIP CANCEL request, or in an ACK request sent for a non-2xx response. These header fields MUST be ignored if they're present in these requests 🙈.
An ACK request for a 2xx response MUST contain only those Require and Proxy-Require values that were present in the initial request.
Example:
UAC->UAS: INVITE sip:watson@bell-telephone.com SIP/2.0
Require: 100rel
UAS->UAC: SIP/2.0 420 Bad Extension
Unsupported: 100relThis setup is so smart, honestly 🧚 When both sides understand every option, things keep moving fast, and they only slow down when something's unknown, like in the example above. For a well-matched client and server, the exchange zips along and skips a round-trip that negotiation mechanisms often need 🚀. It also clears up confusion when a client needs features the server doesn't understand. Some features, like call handling fields, are only of interest to end systems 📞
8.2.3 Content Processing
Assuming the UAS understands any extensions the client required, it looks at the body of the message and the header fields that describe it 👀. If there are any bodies whose type (indicated by the Content-Type), language (indicated by the Content-Language) or encoding (indicated by the Content-Encoding) isn't understood, and that body part isn't optional (as indicated by the Content-Disposition header field), the UAS MUST reject the request with a 415 (Unsupported Media Type) response. The response MUST contain an Accept header field listing the types of all bodies it understands, in case the request had bodies of types the UAS doesn't support. If the request contained content encodings the UAS doesn't understand, the response MUST contain an Accept-Encoding header field listing the encodings it does understand. If the request contained content with languages the UAS doesn't understand, the response MUST contain an Accept-Language header field indicating the languages the UAS understands.
Beyond these checks, body handling depends on the method and type 🎀. For more on processing content-specific header fields, see Section 7.4 as well as Section 20.11 through 20.15.
8.2.4 Applying Extensions
A UAS that wishes to apply some extension when generating the response MUST NOT do so unless support for that extension is indicated in the Supported header field in the request. If the desired extension isn't supported, the server SHOULD rely only on baseline SIP and any other extensions supported by the client. In rare circumstances, where the server can't process the request without the extension, the server MAY send a 421 (Extension Required) response. This response indicates that the proper response can't be generated without support for a specific extension. The needed extension(s) MUST be included in a Require header field in the response. This behavior is NOT RECOMMENDED, as it will generally break interoperability 😬
Any extensions applied to a non-421 response MUST be listed in a Require header field included in the response. Of course, the server MUST NOT apply extensions not listed in the Supported header field in the request. As a result of this, the Require header field in a response will only ever contain option tags defined in standards-track RFCs 💖
8.2.5 Processing the Request
Assuming all of the checks in the previous subsections pass, UAS processing becomes method-specific. Section 10 covers the REGISTER request, Section 11 covers the OPTIONS request, Section 13 covers the INVITE request, and Section 15 covers the BYE request 🦋
8.2.6 Generating the Response
When a UAS wishes to construct a response to a request, it follows the general procedures in the subsections below. Additional behaviors specific to the response code in question, which aren't detailed in this section, may also be required.
Once all procedures associated with creating a response are completed, the UAS hands the response back to the server transaction from which it received the request ✨
8.2.6.1 Sending a Provisional Response
One largely non-method-specific guideline for generating responses is that UASs SHOULD NOT issue a provisional response for a non-INVITE request. Rather, UASs SHOULD generate a final response to a non-INVITE request as soon as possible 🏃♀️
When a 100 (Trying) response is generated, any Timestamp header field present in the request MUST be copied into this 100 (Trying) response. If there's a delay in generating the response, the UAS SHOULD add a delay value into the Timestamp value in the response. This value MUST contain the difference between the time of sending the response and receipt of the request, measured in seconds ⏱️
8.2.6.2 Headers and Tags
The From field of the response MUST equal the From header field of the request. The Call-ID header field of the response MUST equal the Call-ID header field of the request. The CSeq header field of the response MUST equal the CSeq field of the request. The Via header field values in the response MUST equal the Via header field values in the request and MUST maintain the same ordering 🌸
If a request contained a To tag in the request, the To header field in the response MUST equal that of the request. However, if the To header field in the request did not contain a tag, the URI in the To header field in the response MUST equal the URI in the To header field; additionally, the UAS MUST add a tag to the To header field in the response (with the exception of the 100 (Trying) response, in which a tag MAY be present). This serves to identify the UAS that is responding, possibly resulting in a component of a dialog ID 🪪. The same tag MUST be used for all responses to that request, both final and provisional (again excepting the 100 (Trying)). Procedures for the generation of tags are defined in Section 19.3.
8.2.7 Stateless UAS Behavior
A stateless UAS is a UAS that doesn't maintain transaction state. It replies to requests normally, but discards any state that would ordinarily be retained by a UAS after a response has been sent. If a stateless UAS receives a retransmission of a request, it regenerates the response and resends it, just as if it were replying to the first instance of the request. A UAS cannot be stateless unless the request processing for that method would always result in the same response if the requests are identical. This rules out stateless registrars, for example. Stateless UASs don't use a transaction layer; they receive requests directly from the transport layer and send responses directly to the transport layer 🧊
The stateless UAS role is needed primarily to handle unauthenticated requests for which a challenge response is issued. If unauthenticated requests were handled statefully, then malicious floods of unauthenticated requests could create massive amounts of transaction state that might slow or completely halt call processing in a UAS, effectively creating a denial of service condition. For more information, see Section 26.1.5. This is serious, bestie 🚨
The most important behaviors of a stateless UAS are the following:
- A stateless UAS MUST NOT send provisional (1xx) responses.
- A stateless UAS MUST NOT retransmit responses.
- A stateless UAS MUST ignore ACK requests.
- A stateless UAS MUST ignore CANCEL requests.
- To header tags MUST be generated for responses in a stateless manner - in a manner that will generate the same tag for the same request consistently. For information on tag construction, see Section 19.3.
In all other respects, a stateless UAS behaves in the same manner as a stateful UAS. A UAS can operate in either a stateful or stateless mode for each new request 💜
8.3. Redirect Servers ✨
okay so in some architectures it may be desirable to take some of the pressure off proxies that are busy routing requests 💅, and make the signaling path more robust 🛡️, by leaning on redirection 🦋
redirection lets servers push routing info for a request back to the client in a response. that means the server takes itself out of the loop for the rest of that transaction, but it still helps the client find the target 🫶 when the originator gets the redirect, it sends a brand new request using the URI(s) it was handed. ngl this is so smart, because pushing URIs from the core of the network out to the edges makes the whole network way more scalable 🌈
a redirect server is logically made of a server transaction layer and a transaction user that can reach some kind of location service (check Section 10 for more on registrars and location services 📚). the location service is basically a database. it maps one single URI to a set of one or more alternative locations where the target of that URI can be found 🗺️
a redirect server does not issue any SIP requests of its own 🙅♀️ after it gets a request that isn't CANCEL, it either refuses the request, or it grabs the list of alternative locations from the location service and sends back a final response in class 3xx. for well-formed CANCEL requests, it SHOULD return a 2xx response. that response ends the SIP transaction. the redirect server keeps transaction state for the entire SIP transaction 🧠 and it's the responsibility of clients to detect forwarding loops between redirect servers. not the server's job, bestie!
when a redirect server sends a 3xx response to a request, it fills the list of (one or more) alternative locations into the Contact header field. an expires parameter can also be added to the Contact header field values to show how long the Contact data stays valid ⏳
the Contact header field holds URIs that give the new locations or user names to try. it can also just specify additional transport parameters 🎀 a 301 (Moved Permanently) or 302 (Moved Temporarily) response may also give the same location and username that the initial request targeted, but then specify extra transport parameters, like a different server or a multicast address to try. it can even switch the SIP transport from UDP to TCP or the other way around 🔄
however, redirect servers MUST NOT redirect a request to a URI equal to the one in the Request-URI 🚫 instead, as long as the URI doesn't point back to itself, the server MAY proxy the request to the destination URI, or MAY reject it with a 404.
if a client is using an outbound proxy, and that proxy actually redirects requests, a potential arises for infinite redirection loops 🌀 yikes, lol.
a Contact header field value MAY also refer to a different resource than the one that was originally called ✨ for example, a SIP call connected to a PSTN gateway may need to play a special informational announcement, like "The number you have dialed has been changed." so cute, and so useful 📞
a Contact response header field can hold any suitable URI that says where the called party can be reached. it doesn't have to be a SIP URI 🌸 it could be URIs for phones, fax, or irc (if they were defined), or a mailto: URL from RFC 2368 [32]. Section 26.4.4 talks about the implications and limitations of redirecting a SIPS URI to a non-SIPS URI, so go check that out if you're doing it 🔐
the expires parameter of a Contact header field value shows how long the URI is valid. its value is a number of seconds ⏱️ if this parameter isn't provided, the Expires header field decides how long the URI is valid. malformed values SHOULD be treated as equivalent to 3600.
this gives a modest level of backwards compatibility with RFC 2543, which allowed absolute times in this header field 🕰️ if an absolute time shows up, it gets treated as malformed and then defaults to 3600.
redirect servers MUST ignore features they don't understand 🙈 that includes unrecognized header fields, any unknown option tags in Require, or even method names. then they just keep going and proceed with the redirection of the request in question 💖
9. Canceling a Request 🛑
the previous section covered general UA behavior for generating requests and processing responses for requests of all methods 📖 in this section we get into a general purpose method called CANCEL.
CANCEL, as the name says, is used to cancel a previous request sent by a client 🙅♀️ specifically, it asks the UAS to stop processing the request and to generate an error response to that request. CANCEL has no effect on a request that the UAS has already given a final response to. so it's most useful for requests where the server could take a long time to respond. that's why CANCEL is best for INVITE requests, since those can take ages to generate a response 😭 in that usage, a UAS that gets a CANCEL for an INVITE but hasn't sent a final response yet would "stop ringing", and then respond to the INVITE with a specific error response (a 487) 📞💀
CANCEL requests can be built and sent by both proxies and user agent clients 💅 Section 15 covers the conditions under which a UAC would CANCEL an INVITE request, and Section 16.10 covers proxy usage of CANCEL.
a stateful proxy responds to a CANCEL, rather than just forwarding a response it would get from a downstream element 🔁 that's why CANCEL is called a "hop-by-hop" request, since it gets responded to at each stateful proxy hop 🦋
9.1. Client Behavior
a CANCEL request SHOULD NOT be sent to cancel a request other than INVITE 🙅♀️
since requests other than INVITE get responded to immediately, sending a CANCEL for a non-INVITE request would always create a race condition 🏃♀️💨
here's how you build a CANCEL request 🎀 the Request-URI, Call-ID, To, the numeric part of CSeq, and From header fields in the CANCEL request MUST be identical to those in the request being cancelled, including tags. a CANCEL built by a client MUST have only a single Via header field value, and it has to match the top Via value in the request being cancelled. using the same values for these header fields lets the CANCEL get matched with the request it cancels (Section 9.2 explains how that matching works 🔍). however, the method part of the CSeq header field MUST have a value of CANCEL. that's what lets it get identified and processed as a transaction in its own right (see Section 17) ✨
if the request being cancelled contains a Route header field, the CANCEL request MUST include that Route header field's values.
this is needed so that stateless proxies can route CANCEL requests properly 🧭
the CANCEL request MUST NOT contain any Require or Proxy-Require header fields 🚫
once the CANCEL is built, the client SHOULD check whether it has received any response (provisional or final) for the request being cancelled (called the "original request" from here on) 👀
if no provisional response has been received, the CANCEL request MUST NOT be sent. instead, the client MUST wait for the arrival of a provisional response before sending the request. if the original request has already generated a final response, the CANCEL SHOULD NOT be sent, since it's an effective no-op. CANCEL has no effect on requests that already generated a final response 🫠 when the client decides to send the CANCEL, it creates a client transaction for the CANCEL and hands it the CANCEL request along with the destination address, port, and transport. the destination address, port, and transport for the CANCEL MUST be identical to the ones used to send the original request 📮
if it were allowed to send the CANCEL before getting a response for the previous request, the server could receive the CANCEL before the original request. chaos, bestie 😭
both the transaction for the original request and the CANCEL transaction will complete independently 🔀 however, a UAC canceling a request can't rely on getting a 487 (Request Terminated) response for the original request, because an RFC 2543-compliant UAS won't generate one 🙃 if there's no final response for the original request in 64*T1 seconds (T1 is defined in Section 17.1.1.1), the client SHOULD then consider the original transaction cancelled, and SHOULD destroy the client transaction handling the original request 🧹
9.2. Server Behavior
the CANCEL method asks the TU at the server side to cancel a pending transaction 💅 the TU figures out which transaction to cancel by taking the CANCEL request, assuming the request method is anything but CANCEL or ACK, and applying the transaction matching procedures of Section 17.2.3. the matching transaction is the one that gets cancelled 🎯
how a server handles a CANCEL depends on what type of server it is 🧩 a stateless proxy will forward it, a stateful proxy might respond to it and generate some CANCEL requests of its own, and a UAS will respond to it. see Section 16.10 for how proxies treat CANCEL.
a UAS first processes the CANCEL request according to the general UAS processing in Section 8.2. but since CANCEL requests are hop-by-hop and can't be resubmitted, they can't be challenged by the server to get proper credentials in an Authorization header field 🔐 also note that CANCEL requests don't contain a Require header field.
if the UAS didn't find a matching transaction for the CANCEL using the procedure above, it SHOULD respond to the CANCEL with a 481 (Call Leg/Transaction Does Not Exist) 🤷♀️ if the transaction for the original request still exists, the UAS's behavior on receiving a CANCEL depends on whether it has already sent a final response for the original request. if it has, the CANCEL has no effect on the processing of the original request, no effect on any session state, and no effect on the responses generated for the original request 🙅♀️ if the UAS hasn't issued a final response for the original request, its behavior depends on the method of the original request. if the original request was an INVITE, the UAS SHOULD immediately respond to the INVITE with a 487 (Request Terminated) 📴 a CANCEL has no impact on the processing of transactions with any other method defined in this specification.
no matter what the original request's method was, as long as the CANCEL matched an existing transaction, the UAS answers the CANCEL request itself with a 200 (OK) response 🎉 that response gets built following the procedures in Section 8.2.6, and the To tag of the response to the CANCEL and the To tag in the response to the original request SHOULD be the same 🏷️ the response to the CANCEL then gets passed to the server transaction for transmission 📨✨
10.1. Overview ✨
Okay so SIP has a discovery superpower 🔍 If one user wants to start a session with another, SIP needs to figure out which host(s) the destination user can be reached at right now. This discovery is usually handled by SIP network elements like proxy servers and redirect servers. They get a request, work out where to send it based on where the user is, and send it on there 🦋 To do that, they check in with an abstract service called a location service, which hands out address bindings for a particular domain. These bindings map an incoming SIP or SIPS URI, like sip:bob@biloxi.com, to one or more URIs that are somehow "closer" to the person you're looking for, like sip:bob@engineering.biloxi.com. Basically, a proxy ends up asking a location service to map the URI it received to the user agent(s) where the intended recipient is actually hanging out 💖
Registration is what creates bindings in a location service for a domain. It links an address-of-record URI with one or more contact addresses. So when a proxy for that domain gets a request whose Request-URI matches the address-of-record, it forwards the request to the contact addresses registered for that address-of-record 🎀 Honestly, it only makes sense to register an address-of-record at a domain's location service when requests for that address-of-record would actually get routed to that domain. In most cases, that means the domain of the registration needs to match the domain in the address-of-record's URI 🙈
There are lots of ways the contents of the location service can get set up. One is administrative. In the example above, Bob is known to be in the engineering department because of a corporate database. But SIP also has a mechanism for a UA to create a binding explicitly, and it's called registration 🌸
Registration means sending a REGISTER request to a special kind of UAS called a registrar. The registrar is the front door to the location service for a domain. It reads and writes mappings based on what's inside REGISTER requests. Then a proxy server that routes requests for that domain typically consults that location service 🧚
Figure 2 shows the whole registration process. The registrar and the proxy server are logical roles, so one device can play both. They're split apart in the picture just so it's clearer ✨ Also, UAs may send requests through a proxy server to reach a registrar if the two are separate elements.
SIP doesn't mandate any particular way to implement the location service. The only requirement is that a registrar for some domain MUST be able to read and write data to the location service, and a proxy or a redirect server for that domain MUST be capable of reading that same data. A registrar MAY be co-located with a particular SIP proxy server for the same domain 👑
10.2. Constructing the REGISTER Request 📝
REGISTER requests are all about adding, removing, and querying bindings. A REGISTER can add a new binding between an address-of-record and one or more contact addresses. A suitably authorized third party can do the registering on behalf of a particular address-of-record. A client can also remove previous bindings, or ask which bindings are currently in place for an address-of-record 🫶
Unless noted otherwise, building the REGISTER request and the behavior of clients sending one is identical to the general UAC behavior in Section 8.1 and Section 17.1. ✨
A REGISTER request does not establish a dialog. A UAC MAY include a Route header field in a REGISTER request based on a pre-existing route set, as described in Section 8.1. The Record-Route header field has no meaning in REGISTER requests or responses, and it MUST be ignored if present. In particular, the UAC MUST NOT create a new route set based on whether a Record-Route header field is there or not in any response to a REGISTER request 🙅
These header fields, except Contact, MUST be included in a REGISTER request. A Contact header field MAY be included too:
Request-URI: The Request-URI names the domain of the location service for which the registration is meant (for example,"sip:chicago.com"). The"userinfo"and"@"components of the SIP URI MUST NOT be present.To: The To header field contains the address of record whose registration is to be created, queried, or modified. The To header field and the Request-URI field typically differ, as the former contains a user name. This address-of-record MUST be a SIP URI or SIPS URI.From: The From header field contains the address-of-record of the person responsible for the registration. The value is the same as the To header field unless the request is a third-party registration.Call-ID: All registrations from a UAC SHOULD use the same Call-ID header field value for registrations sent to a particular registrar. If the same client were to use different Call-ID values, a registrar could not detect whether a delayed REGISTER request might have arrived out of order. 😵💫CSeq: The CSeq value guarantees proper ordering of REGISTER requests. A UA MUST increment the CSeq value by one for each REGISTER request with the same Call-ID.Contact: REGISTER requests MAY contain a Contact header field with zero or more values containing address bindings.
UAs MUST NOT send a new registration (that is, one containing new Contact header field values, as opposed to a retransmission) until they have received a final response from the registrar for the previous one, or the previous REGISTER request has timed out ⏳
bob
+----+
| UA |
| |
+----+
|
|3)INVITE
| carol@chicago.com
chicago.com +--------+ V
+---------+ 2)Store|Location|4)Query +-----+
|Registrar|=======>| Service|<=======|Proxy|sip.chicago.com
+---------+ +--------+=======>+-----+
A 5)Resp |
| |
| |
1)REGISTER| |
| |
+----+ |
| UA |<-------------------------------+
cube2214a| | 6)INVITE
+----+ carol@cube2214a.chicago.com
carol
Figure 2: REGISTER exampleThe following Contact header parameters have a special meaning in REGISTER requests:
action: The"action"parameter from RFC 2543 has been deprecated. UACs SHOULD NOT use the"action"parameter.expires: The"expires"parameter indicates how long the UA would like the binding to be valid. The value is a number indicating seconds. If this parameter is not provided, the value of the Expires header field is used instead. Implementations MAY treat values larger than2**32-1(4294967295 seconds or 136 years) as equivalent to2**32-1. Malformed values SHOULD be treated as equivalent to 3600. ⏱️
10.2.1. Adding Bindings 📬
The REGISTER request sent to a registrar includes the contact address(es) where SIP requests for the address-of-record should be forwarded. The address-of-record goes in the To header field of the REGISTER request.
The Contact header field values of the request typically consist of SIP or SIPS URIs that identify particular SIP endpoints (for example, "sip:carol@cube2214a.chicago.com"), but they MAY use any URI scheme. A SIP UA can choose to register telephone numbers (with the tel URL, RFC 2806 [9]) or email addresses (with a mailto URL, RFC 2368 [32]) as Contacts for an address-of-record, for example.
For example, Carol, with address-of-record "sip:carol@chicago.com", would register with the SIP registrar of the domain chicago.com. Her registrations would then be used by a proxy server in the chicago.com domain to route requests for Carol's address-of-record to her SIP endpoint 💁
Once a client has set up bindings at a registrar, it MAY send later registrations containing new bindings or modifications to existing bindings as necessary. The 2xx response to the REGISTER request will contain, in a Contact header field, a complete list of bindings that have been registered for this address-of-record at this registrar 📋
If the address-of-record in the To header field of a REGISTER request is a SIPS URI, then any Contact header field values in the request SHOULD also be SIPS URIs. Clients should only register non-SIPS URIs under a SIPS address-of-record when the security of the resource represented by the contact address is guaranteed by other means. This may be applicable to URIs that invoke protocols other than SIP, or SIP devices secured by protocols other than TLS. 🔐
Registrations don't have to update all bindings. Typically, a UA only updates its own contact addresses 🌷
10.2.1.1. Setting the Expiration Interval of Contact Addresses ⏰
When a client sends a REGISTER request, it MAY suggest an expiration interval that indicates how long the client would like the registration to be valid. (As described in Section 10.3, the registrar selects the actual time interval based on its local policy.)
There are two ways a client can suggest an expiration interval for a binding: through an Expires header field, or through an "expires" Contact header parameter. The latter lets expiration intervals be suggested on a per-binding basis when more than one binding is given in a single REGISTER request, whereas the former suggests an expiration interval for all Contact header field values that do not contain the "expires" parameter 🎯
If neither mechanism for expressing a suggested expiration time is present in a REGISTER, the client is indicating its desire for the server to choose 🤷
10.2.1.2. Preferences among Contact Addresses 🏆
If more than one Contact is sent in a REGISTER request, the registering UA intends to associate all of the URIs in these Contact header field values with the address-of-record present in the To field. This list can be prioritized with the "q" parameter in the Contact header field. The "q" parameter indicates a relative preference for that particular Contact header field value compared to other bindings for this address-of-record. Section 16.6 describes how a proxy server uses this preference indication 💜 it's giving organized
10.2.2 Removing Bindings ✨
okay so registrations are soft state 🫧 which means they expire unless somebody refreshes them, but you can also explicitly delete them whenever you want. 💅 A client can try to influence the expiration interval the registrar picks (more on that in Section 10.2.1). To get a binding removed right away, a UA sends a REGISTER request with an expiration interval of 0 for that contact address. UAs SHOULD support this so bindings can be removed before their expiration interval has passed. it's giving clean housekeeping 🧹
The REGISTER-specific Contact header field value of * covers every registration, but it MUST NOT be used unless the Expires header field is present with a value of 0. 🙅♀️
Using the * Contact header field value lets a registering UA wipe out all bindings for an address-of-record without needing to know what their exact values are. 🧠
10.2.3 Fetching Bindings 🦋
A success response to any REGISTER request includes the complete list of existing bindings, even if the request didn't have a Contact header field. 🎀 If a REGISTER request has no Contact header field, the list of bindings just stays exactly as it was. 🌸
10.2.4 Refreshing Bindings 🔁
Each UA is in charge of refreshing the bindings it set up earlier. 💖 A UA SHOULD NOT refresh bindings that other UAs set up, so don't be that person 🙈
The 200 (OK) response from the registrar has a list of Contact fields showing every current binding. ✨ The UA compares each contact address to figure out whether it made that address itself, using the comparison rules in Section 19.1.4. If it did, the UA updates the expiration time interval using the expires parameter or, if that's missing, the Expires field value. 💜 After that, it sends a REGISTER request for each of its bindings before the expiration interval runs out. It MAY combine several updates into a single REGISTER request, which is very efficient bestie behavior 🫶
A UA SHOULD use the same Call-ID for all of its registrations during a single boot cycle. 🧚 Registration refreshes SHOULD be sent to the same network address as the original registration, unless the request got redirected. 🗺️
10.2.5 Setting the Internal Clock ⏰
If the response to a REGISTER request has a Date header field, the client MAY use that field to learn the current time and set any internal clocks. 🕰️ very helpful, no notes 💅
10.2.6 Discovering a Registrar 🔍
UAs have three ways to figure out where to send registrations: by configuration, using the address-of-record, and multicast. 🌈 A UA can be configured with a registrar address, but the ways of doing that are beyond the scope of this specification. If there's no configured registrar address, the UA SHOULD use the host part of the address-of-record as the Request-URI and send the request there, using the normal SIP server location mechanisms [4]. For example, a UA for the user "sip:carol@chicago.com" addresses its REGISTER request to "sip:chicago.com". 🗽
Lastly, a UA can be set up to use multicast. 📡 Multicast registrations are addressed to the well-known "all SIP servers" multicast address "sip.mcast.net" (224.0.1.75 for IPv4). No well-known IPv6 multicast address has been allocated yet; if one is ever needed, it'll be documented separately. 🤞 SIP UAs MAY listen to that address and use it to find out where other local users are (see [33]). They do not respond to the request, though. 🤐
Multicast registration might be a bad vibe in some environments, for example if several businesses share the same local area network. 🙃
10.2.7 Transmitting a Request 📤
Once the REGISTER method has been constructed and the destination of the message has been identified, UACs follow the procedures in Section 8.1.2 to hand the REGISTER off to the transaction layer. 🚀
If the transaction layer returns a timeout error because the REGISTER got no response, the UAC SHOULD NOT immediately try to register with the same registrar again. ⏳
An immediate retry will probably time out too. Waiting a reasonable amount of time for whatever caused the timeout to get fixed cuts down on unnecessary network load. No specific interval is mandated. 🫠
10.2.8 Error Responses 🙅
If a UA gets a 423 (Interval Too Brief) response, it MAY retry the registration after setting the expiration interval of all contact addresses in the REGISTER request to a value equal to or greater than the expiration interval in the Min-Expires header field of that 423 (Interval Too Brief) response. 💅✨
10.3. Processing REGISTER Requests 💅
okay so a registrar is a UAS (the server side that answers requests) that handles REGISTER requests and keeps a list of bindings. Proxy servers and redirect servers inside its administrative domain can read that list 📖✨. It handles requests according to Section 8.2 and Section 17.2, but it only accepts REGISTER requests, and it MUST not generate 6xx responses 🙅♀️.
A registrar MAY redirect REGISTER requests when that makes sense 🦋. A super common example is a registrar listening on a multicast interface that bounces multicast REGISTER requests over to its own unicast interface with a 302 (Moved Temporarily) response. Iconic routing move 🧚.
Registrars MUST ignore the Record-Route header field if it shows up in a REGISTER request 🙈. And registrars MUST NOT include a Record-Route header field in any response to a REGISTER request. Keep it clean bestie 🫶.
Note: A registrar might receive a request that traversed a proxy which treats REGISTER as an unknown request and which added a Record-Route header field value. This is why the rule above exists 👀.
A registrar has to know (for example, through configuration) which domain or domains it keeps bindings for 🗺️. REGISTER requests MUST be processed by a registrar in the order that they are received 📬. They MUST also be processed atomically, which means a particular REGISTER request is either processed completely or not at all. No half-finished vibes allowed 💀. Each REGISTER message MUST be processed independently of any other registration or binding changes 🌸.
When a registrar gets a REGISTER request, it follows these steps 🎀:
- The registrar inspects the Request-URI to see whether it has access to bindings for the domain identified in the Request-URI. If not, and if the server also acts as a proxy server, the server SHOULD forward the request to the addressed domain, following the general behavior for proxying messages described in Section 16. 🔁
- To make sure the registrar supports any necessary extensions, the registrar MUST process the Require header field values as described for UASs in Section 8.2.2. 🧩
- A registrar SHOULD authenticate the UAC. Mechanisms for authenticating SIP user agents are described in Section 22. Registration behavior in no way overrides the generic authentication framework for SIP 🔐. If no authentication mechanism is available, the registrar MAY take the From address as the asserted identity of the originator of the request.
- The registrar SHOULD determine whether the authenticated user is authorized to modify registrations for this address-of-record 🪪. For example, a registrar might consult an authorization database that maps user names to a list of addresses-of-record for which that user has authorization to modify bindings. If the authenticated user is NOT authorized to modify bindings, the registrar MUST return a 403 (Forbidden) and skip the remaining steps. Rude 🚫.
In architectures that support third-party registration, one entity may be responsible for updating the registrations associated with multiple addresses-of-record 🤝.
- The registrar pulls the address-of-record out of the To header field of the request. If the address-of-record is not valid for the domain in the Request-URI, the registrar MUST send a 404 (Not Found) response and skip the remaining steps. The URI MUST then be converted to a canonical form 🧼. To do that, all URI parameters MUST be removed (including the user-param), and any escaped characters MUST be converted to their unescaped form. The result serves as an index into the list of bindings 📇.
- The registrar checks whether the request contains the Contact header field. If not, it skips to the last step. If the Contact header field is present, the registrar checks whether there is one Contact field value that contains the special value "*" and an Expires field. If the request has additional Contact fields or an expiration time other than zero, the request is invalid, and the server MUST return a 400 (Invalid Request) and skip the remaining steps 🚨. If not, the registrar checks whether the Call-ID agrees with the value stored for each binding. If it does NOT agree, it MUST remove the binding. If it does agree, it MUST remove the binding only if the CSeq in the request is higher than the value stored for that binding. Otherwise, the update MUST be aborted and the request fails 🙅♀️.
- The registrar now processes each contact address in the Contact header field in turn 🔍. For each address, it works out the expiration interval like this:
- If the field value has an "expires" parameter, that value MUST be taken as the requested expiration.
- If there is no such parameter, but the request has an Expires header field, that value MUST be taken as the requested expiration.
- If there is neither, a locally-configured default value MUST be taken as the requested expiration.
The registrar MAY choose an expiration less than the requested expiration interval. If and only if the requested expiration interval is greater than zero AND smaller than one hour AND less than a registrar-configured minimum, the registrar MAY reject the registration with a response of 423 (Interval Too Brief) ⏱️. This response MUST contain a Min-Expires header field that states the minimum expiration interval the registrar is willing to honor. Then it skips the remaining steps.
Letting the registrar set the registration interval protects it from excessively frequent registration refreshes, keeps the state it has to maintain under control, and lowers the chance of registrations going stale 🧠. The expiration interval of a registration is often used to build services. An example is a follow-me service, where the user may only be reachable at a terminal for a brief period 🏃♀️. So registrars should accept brief registrations. A request should only be rejected if the interval is so short that the refreshes would degrade registrar performance 📉.
For each address, the registrar then searches the list of current bindings using the URI comparison rules. If the binding does not exist, it is tentatively added. If the binding does exist, the registrar checks the Call-ID value. If the Call-ID value in the existing binding differs from the Call-ID value in the request, the binding MUST be removed if the expiration time is zero, and updated otherwise. If they are the same, the registrar compares the CSeq value. If the value is higher than that of the existing binding, it MUST update or remove the binding as above. If not, the update MUST be aborted and the request fails 🛑.
This algorithm makes sure out-of-order requests from the same UA get ignored 🙅♀️✨.
Each binding record records the Call-ID and CSeq values from the request 🗂️.
The binding updates MUST be committed (that is, made visible to the proxy or redirect server) if and only if all binding updates and additions succeed. If any one of them fails (for example, because the back-end database commit failed), the request MUST fail with a 500 (Server Error) response, and all tentative binding updates MUST be removed 💥.
- The registrar returns a 200 (OK) response. The response MUST contain Contact header field values enumerating all current bindings. Each Contact value MUST feature an "expires" parameter indicating its expiration interval chosen by the registrar. The response SHOULD include a Date header field 🗓️🎉.
11. Querying for Capabilities 🔮
the SIP method OPTIONS lets a UA ask another UA or a proxy server what it can do 🧐. This lets a client find out about supported methods, content types, extensions, codecs, and more WITHOUT "ringing" the other party 🔕. For example, before a client puts a Require header field into an INVITE that lists an option it isn't sure the destination UAS supports, it can send the destination UAS an OPTIONS to see whether that option comes back in a Supported header field. Smart and polite 🫶. All UAs MUST support the OPTIONS method 💖.
The target of the OPTIONS request is identified by the Request-URI, which could be another UA or a SIP server 🎯. If the OPTIONS is addressed to a proxy server, the Request-URI is set without a user part, similar to how a Request-URI is set for a REGISTER request.
Alternatively, a server that receives an OPTIONS request with a Max-Forwards header field value of 0 MAY respond to the request regardless of the Request-URI 🦋.
This behavior is common with HTTP/1.1. It can be used as a "traceroute" functionality to check the capabilities of individual hop servers, by sending a series of OPTIONS requests with incremented Max-Forwards values 🗺️✨.
As is the case for general UA behavior, the transaction layer can return a timeout error if the OPTIONS yields no response. This may indicate that the target is unreachable and hence unavailable 😭.
An OPTIONS request MAY be sent as part of an established dialog to query the peer about capabilities that may be used later in the dialog 💬.
11.1. Construction of OPTIONS Request 🎀
an OPTIONS request is built using the standard rules for a SIP request, as discussed in Section 8.1.1 🧱.
A Contact header field MAY be present in an OPTIONS 📇.
An Accept header field SHOULD be included to show the type of message body the UAC wants to receive in the response 🍓. This is usually set to a format that describes the media capabilities of a UA, such as SDP (application/sdp).
The response to an OPTIONS request is assumed to be scoped to the Request-URI in the original request. However, only when an OPTIONS is sent as part of an established dialog is it guaranteed that future requests will be received by the server that generated the OPTIONS response 🤔.
Example OPTIONS request 🌈:
OPTIONS sip:carol@chicago.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877
Max-Forwards: 70
To: <sip:carol@chicago.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 63104 OPTIONS
Contact: <sip:alice@pc33.atlanta.com>
Accept: application/sdp
Content-Length: 011.2 Processing of OPTIONS Request 🎀
okay so when a UAS gets an OPTIONS, the response gets built with the normal SIP response rules from Section 8.2.6 🧚 the response code MUST be the same one you'd have picked if the request had been an INVITE. so a 200 (OK) means "yep, I'm ready to take a call," and a 486 (Busy Here) means "sorry, I'm busy," and so on ✨ that's what makes OPTIONS so useful: it tells you the basic state of a UAS, which is a pretty good hint about whether it'll accept an INVITE 💅
an OPTIONS sent inside a dialog gets a 200 (OK) that looks exactly like one built outside a dialog, and it does NOT change the dialog at all 🦋
now the tea ☕ OPTIONS has limits because proxies handle OPTIONS and INVITE differently. a forked INVITE can bring back multiple 200 (OK) responses, but a forked OPTIONS only ever gets one 200 (OK), since proxies treat it with the non-INVITE handling. check Section 16.7 for the normative details 🫶
if a proxy server generates the response to an OPTIONS, it returns a 200 (OK) that lists the server's capabilities 🌸 and that response has no message body.
the Allow, Accept, Accept-Encoding, Accept-Language, and Supported header fields SHOULD be in a 200 (OK) to an OPTIONS request 💖 if a proxy is the one answering, the Allow header field SHOULD be left out, because a proxy doesn't care which method it's handling, so listing methods would be confusing 🙈 Contact header fields MAY show up in the 200 (OK) and they mean the same thing they mean in a 3xx response, so they can list alternative names and ways to reach the user 🗺️ a Warning header field MAY be there too ⭐
a message body MAY be sent. its type comes from the Accept header field in the OPTIONS request, and if there's no Accept header field, application/sdp is the default 🎶 if one of those types can describe media capabilities, the UAS SHOULD put a body in the response for exactly that reason. the details for building that body when it's application/sdp are in [13] 💜
here's an example OPTIONS response from a UAS, matching the request in Section 11.1 👑
SIP/2.0 200 OK
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877
;received=192.0.2.4
To: <sip:carol@chicago.com>;tag=93810874
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 63104 OPTIONS
Contact: <sip:carol@chicago.com>
Contact: <mailto:carol@chicago.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE
Accept: application/sdp
Accept-Encoding: gzip
Accept-Language: en
Supported: foo
Content-Type: application/sdp
Content-Length: 274
(SDP not shown)12 Dialogs ✨
okay this section is the main character of user agent life 👑 a dialog is a peer-to-peer SIP relationship between two user agents that sticks around for a while 🦋 it keeps messages in order and makes sure requests get routed correctly between both of them. basically it's the context you use to read SIP messages 💅 Section 8 covered method-independent UA processing for requests and responses outside a dialog, and this section is about how those messages build a dialog and then how the next ones get sent inside it 🫶
each UA identifies a dialog with a dialog ID, which is made of a Call-ID value, a local tag, and a remote tag 🧩 the dialog ID is NOT the same at each UA involved. the local tag at one UA matches the remote tag at its peer 🔁 the tags are opaque tokens, and their whole job is helping generate unique dialog IDs 🌈
a dialog ID also goes with every response, and with any request that has a tag in the To field 💌 the way you compute it depends on whether you're a UAC or a UAS. for a UAC, the Call-ID value is the Call-ID of the message, the remote tag is the tag in the To field, and the local tag is the tag in the From field (these rules work for both requests and responses) 💖 for a UAS, it's flipped in the way you'd expect: Call-ID is still the Call-ID of the message, the remote tag is the tag in the From field, and the local tag is the tag in the To field 🎀
a dialog holds the state it needs for sending more messages inside it 🧠 that state includes the dialog ID, a local sequence number (for ordering requests from the UA to its peer), a remote sequence number (for ordering requests from the peer to the UA), a local URI, a remote URI, a remote target, a boolean flag called "secure", and a route set, which is an ordered list of URIs 📜 the route set is the list of servers a request has to go through to reach the peer 🗺️ a dialog can also be in the "early" state. that happens when it's created by a provisional response, and then it moves to the "confirmed" state once a 2xx final response shows up 🌸 for any other response, or if no response arrives on that dialog at all, the early dialog ends 💀
12.1 Creation of a Dialog 🌷
dialogs get created when non-failure responses come back to requests with specific methods 🍓 in this spec, only 2xx and 101-199 responses that have a To tag, to an INVITE request, will establish a dialog. a dialog made from a non-final response is in the "early" state, and it's called an early dialog ✨ extensions MAY define other ways to create dialogs 🧚 Section 13 has more details specific to INVITE. this part explains how to build the dialog state in a way that doesn't depend on the method 💜
UAs MUST assign values to the dialog ID components the way described below 🫶
12.1.1 UAS behavior 👑
when a UAS answers a request with a response that establishes a dialog (like a 2xx to an INVITE), the UAS MUST copy all the Record-Route header field values from the request into the response, including the URIs, URI parameters, and any Record-Route header field parameters, whether the UAS knows them or not 🧾 it MUST also keep those values in the same order 📏 the UAS MUST add a Contact header field to the response. that Contact header field has an address where the UAS would like to be reached for later requests in the dialog, and that includes the ACK for a 2xx response to an INVITE 📞 usually the host part of that URI is the IP address or FQDN of the host 🌐 the URI in the Contact header field MUST be a SIP or SIPS URI 🔐 if the request that started the dialog had a SIPS URI in the Request-URI, or in the top Record-Route header field value (if there was one), or in the Contact header field (if there was no Record-Route header field), then the Contact header field in the response MUST be a SIPS URI 🛡️ the URI SHOULD have global scope, meaning the same URI can be used in messages outside this dialog 🌍 the same goes for the URI in the Contact header field of the INVITE, which isn't limited to this dialog either, so it can be used in messages to the UAC even outside the dialog 🫶
then the UAS builds the dialog state, and that state MUST be kept for the whole life of the dialog 🧠
if the request came in over TLS and the Request-URI had a SIPS URI, the "secure" flag is set to TRUE 🔒
the route set MUST be set to the list of URIs from the Record-Route header field in the request, taken in order and keeping all URI parameters 🗺️ if there's no Record-Route header field in the request, the route set MUST be set to the empty set. this route set overrides any route set that was there before, even if it's empty, and it applies to future requests in this dialog 🧹 the remote target MUST be set to the URI from the Contact header field of the request 🎯
the remote sequence number MUST be set to the value of the sequence number in the CSeq header field of the request 🔢 the local sequence number MUST be empty 🫥 the call identifier part of the dialog ID MUST be set to the Call-ID in the request 📇 the local tag part of the dialog ID MUST be set to the tag in the To field of the response to the request (which always has a tag), and the remote tag part MUST be set to the tag from the From field in the request 🏷️ a UAS MUST be ready to receive a request with no tag in the From field, and in that case the tag is treated as having a value of null 🫧
bestie, this is here for backwards compatibility with RFC 2543, which didn't require From tags 🫶
the remote URI MUST be set to the URI in the From field, and the local URI MUST be set to the URI in the To field 📬
12.1.2 UAC Behavior 💅
when a UAC sends a request that can establish a dialog (like an INVITE), it MUST give a SIP or SIPS URI with global scope (meaning the same SIP URI can be used in messages outside this dialog) in the Contact header field of the request 🌍 if the request has a Request-URI or a topmost Route header field value with a SIPS URI, the Contact header field MUST contain a SIPS URI 🔐
when a UAC gets a response that establishes a dialog, it builds the dialog state, and that state MUST be kept for the whole life of the dialog 🧠
if the request was sent over TLS and the Request-URI had a SIPS URI, the "secure" flag is set to TRUE 🔒
the route set MUST be set to the list of URIs from the Record-Route header field in the response, taken in reverse order and keeping all URI parameters 🔄 if there's no Record-Route header field in the response, the route set MUST be set to the empty set. this route set overrides any earlier one, even if it's empty, and it applies to future requests in this dialog 🧹 the remote target MUST be set to the URI from the Contact header field of the response 🎯
the local sequence number MUST be set to the value of the sequence number in the CSeq header field of the request 🔢 the remote sequence number MUST be empty (it gets set when the remote UA sends a request inside the dialog) 🫥 the call identifier part of the dialog ID MUST be set to the Call-ID in the request 📇 the local tag part of the dialog ID MUST be set to the tag in the From field of the request, and the remote tag part MUST be set to the tag in the To field of the response 🏷️ a UAC MUST be ready to receive a response with no tag in the To field, and in that case the tag is treated as having a value of null 🫧
this is here for backwards compatibility with RFC 2543, which didn't require To tags 🫶
the remote URI MUST be set to the URI in the To field, and the local URI MUST be set to the URI in the From field 📬
12.2. Requests within a Dialog 🦋
Okay so once a dialog is set up between two UAs, either of them MAY start new transactions whenever they need to, within that dialog 💅. The UA that sends the request takes the UAC role for that transaction, and the UA that receives it takes the UAS role. Lowkey, these can be different roles from the ones they had in the transaction that created the dialog in the first place ✨.
Requests within a dialog MAY have Record-Route and Contact header fields too 🎀. Even so, these requests don't change the dialog's route set. They can still change the remote target URI, though 🧚. Basically, requests that aren't target refresh requests leave the dialog's remote target URI alone, and target refresh requests are the ones that update it. For dialogs made with an INVITE, the only target refresh request defined is re-INVITE (see Section 14). Other extensions can define their own target refresh requests for dialogs set up in other ways 🌸.
Note that an ACK is NOT a target refresh request. 🙈
Target refresh requests only update the dialog's remote target URI, not the route set built from Record-Route 💖. Changing that route set would cause severe backwards compatibility problems with RFC 2543-compliant systems 💀.
12.2.1. UAC Behavior 🌈
12.2.1.1. Generating the Request 🍓
A request within a dialog is built using a bunch of the pieces stored in the dialog's state 🧁.
The URI in the To field of the request MUST be set to the remote URI from the dialog state. The tag in the To header field of the request MUST be set to the remote tag of the dialog ID. The From URI of the request MUST be set to the local URI from the dialog state. The tag in the From header field of the request MUST be set to the local tag of the dialog ID. If the remote or local tag is null, the tag parameter MUST be omitted from the To or From header field, respectively 🎀.
Using the To and From URIs from the original request in later requests is there for backwards compatibility with RFC 2543, which used the URI to identify the dialog. In this spec, only the tags identify the dialog 🫶. The plan is to deprecate the mandatory reflection of the original To and From URIs in mid-dialog requests in a future revision of this specification 👀.
The Call-ID of the request MUST be set to the Call-ID of the dialog 💕. Requests within a dialog MUST contain strictly monotonically increasing and contiguous CSeq sequence numbers (increasing-by-one) in each direction. The exception is ACK and CANCEL, whose numbers equal the requests they're acknowledging or cancelling 🔥. So if the local sequence number isn't empty, the local sequence number MUST be incremented by one, and this value MUST be placed into the CSeq header field. If the local sequence number is empty, an initial value MUST be chosen using the guidelines of Section 8.1.1.5. The method field in the CSeq header field value MUST match the method of the request 💅.
With a 32-bit length, a client could send one request a second within a single call for about 136 years before the number wraps around 😭. That's why the initial value is chosen so later requests in the same call won't wrap around. A non-zero initial value also lets clients use a time-based initial sequence number. For example, a client could use the 31 most significant bits of a 32-bit second clock as its starting sequence number ⏰.
The UAC uses the remote target and route set to build the Request-URI and Route header field of the request 🧚.
If the route set is empty, the UAC MUST place the remote target URI into the Request-URI. The UAC MUST NOT add a Route header field to the request 🌸.
If the route set isn't empty, and the first URI in the route set contains the lr parameter (see Section 19.1.1), the UAC MUST place the remote target URI into the Request-URI and MUST include a Route header field containing the route set values in order, including all parameters ✨.
If the route set isn't empty, and its first URI doesn't contain the lr parameter, the UAC MUST place the first URI from the route set into the Request-URI, stripping any parameters that aren't allowed in a Request-URI. The UAC MUST add a Route header field containing the rest of the route set values in order, including all parameters. Then the UAC MUST place the remote target URI into the Route header field as the last value 🍓.
For example, say the remote target is sip:user@remoteua and the route set contains:
<sip:proxy1>,<sip:proxy2>,<sip:proxy3;lr>,<sip:proxy4>The request will be formed with the following Request-URI and Route header field:
METHOD sip:proxy1
Route: <sip:proxy2>,<sip:proxy3;lr>,<sip:proxy4>,<sip:user@remoteua>If the first URI of the route set doesn't have the lr parameter, the proxy there doesn't understand the routing mechanisms in this document. It acts the way RFC 2543 describes, replacing the Request-URI with the first Route header field value it gets while forwarding the message 🙃. Putting the Request-URI at the end of the Route header field keeps that information safe across the strict router. It gets put back into the Request-URI once the request reaches a loose router 🫶.
A UAC SHOULD include a Contact header field in any target refresh request within a dialog. Unless there's a reason to change it, the URI SHOULD be the same one used in previous requests within the dialog 🎀. If the "secure" flag is true, that URI MUST be a SIPS URI. As discussed in Section 12.2.2, a Contact header field in a target refresh request updates the remote target URI. That lets a UA share a new contact address if its address changes during the dialog 🦋.
Requests that aren't target refresh requests don't affect the dialog's remote target URI, though 💖.
The rest of the request is formed as described in Section 8.1.1 ✨.
Once the request is built, the server's address is computed and the request is sent, using the same procedures as for requests outside a dialog (Section 8.1.2) 💌.
The procedures in Section 8.1.2 will usually send the request to the address from the topmost Route header field value, or to the Request-URI if there's no Route header field. Within certain restrictions, they can also send it to an alternate address, like a default outbound proxy that isn't in the route set 🌈.
12.2.1.2. Processing the Responses 💫
The UAC gets responses to the request from the transaction layer. If the client transaction returns a timeout, that counts as a 408 (Request Timeout) response ⏳.
A UAC that gets a 3xx response for a request sent within a dialog behaves exactly the same as it would if the request had been sent outside a dialog. That behavior is described in Section 8.1.3.4 🧚.
When the UAC tries alternative locations, it still uses the dialog's route set to build the Route header of the request 🛣️.
When a UAC gets a 2xx response to a target refresh request, it MUST replace the dialog's remote target URI with the URI from the Contact header field in that response, if one is present 🍓.
If the response to a request within a dialog is a 481 (Call/Transaction Does Not Exist) or a 408 (Request Timeout), the UAC SHOULD terminate the dialog. A UAC SHOULD also terminate a dialog if no response at all comes back for the request. The client transaction tells the TU about the timeout in that case 💀.
For dialogs started with an INVITE, terminating the dialog means sending a BYE 👋.
12.2.2. UAS Behavior 👑
Requests sent within a dialog are atomic, just like any other request. If the UAS accepts a particular request, all of the state changes tied to it happen. If the UAS rejects the request, none of them happen 🔒.
Some requests, like INVITEs, affect several pieces of state at once 🧩.
The UAS gets the request from the transaction layer. If the request has a tag in the To header field, the UAS core works out the dialog identifier for the request and compares it with the existing dialogs. If there's a match, this is a mid-dialog request. In that case, the UAS first applies the same processing rules for requests outside a dialog, which are discussed in Section 8.2 🎀.
If the request has a tag in the To header field, but the dialog identifier doesn't match any existing dialog, a few things could be going on. The UAS may have crashed and restarted, or it may have gotten a request meant for a different (possibly failed) UAS. The UASs can build their To tags so that a UAS can tell the tag belongs to a UAS it's recovering for. Or the request could have just been misrouted 🕵️♀️. Based on the To tag, the UAS MAY either accept or reject the request. Accepting requests with acceptable To tags makes things more robust, so dialogs can survive crashes 💪. UAs that want this capability need to think about things like choosing monotonically increasing CSeq sequence numbers even across reboots, rebuilding the route set, and accepting out-of-range RTP timestamps and sequence numbers 🧠.
If the UAS wants to reject the request because it doesn't want to recreate the dialog, it MUST respond to the request with a 481 (Call/Transaction Does Not Exist) status code, and pass that to the server transaction 🚫.
Requests that don't change the dialog's state in any way may be received within a dialog (an OPTIONS request is one example). They're processed as if they had been received outside the dialog ✨.
If the remote sequence number is empty, it MUST be set to the value of the sequence number in the CSeq header field value of the request. If the remote sequence number isn't empty, but the request's sequence number is lower than it, the request is out of order and MUST be rejected with a 500 (Server Internal Error) response 😬. If the remote sequence number isn't empty, and the request's sequence number is greater than it, the request is in order. The CSeq sequence number can jump higher than the remote sequence number by more than one. That's not an error, and a UAS SHOULD be ready to receive and process requests whose CSeq values are more than one higher than the last one received 🌊. The UAS MUST then set the remote sequence number to the value of the sequence number in the CSeq header field value of the request 🔢.
If a proxy challenges a request the UAC generated, the UAC has to resend the request with credentials. The resent request gets a new CSeq number. The UAS never sees the first request, so it notices a gap in the CSeq number space. A gap like that isn't an error condition 🙈.
When a UAS receives a target refresh request, it MUST replace the dialog's remote target URI with the URI from the Contact header field in that request, if one is present 🎯.
12.3 Termination of a Dialog ✨
Okay bestie, no matter which method it is 💅, if a request sent outside of a dialog gets a non-2xx final response, then any early dialogs created through provisional responses to that request get terminated 🚫. How confirmed dialogs get terminated is method specific 🎀, so each method does its own thing. In this spec, the BYE method ends a session and the dialog tied to it 📞. Check Section 15 for the deets 🦋.
13 Initiating a Session 🦋
13.1 Overview 🌸
Okay so when a user agent client wants to start a session (like audio, video, or a game 🎮), it builds an INVITE request 💌. INVITE basically asks a server to set up a session. The request can get forwarded by proxies until it reaches one or more UASs that could accept the invite 👀. Those UASs usually have to ask the actual person whether they want in 🙋♀️. After some time, they can accept by sending a 2xx response ✅. If not, they send a 3xx, 4xx, 5xx or 6xx depending on why they said no 🙅. Before the final answer, the UAS can also send 1xx provisional responses to keep the UAC posted on how it's going to reach the called user 📣.
After maybe getting provisional responses, the UAC gets one or more 2xx responses or one non-2xx final response 🤞. Since INVITE can take forever to get a final answer 😭, its reliability mechanisms are different from other requests like OPTIONS. Once the UAC gets a final response, it needs to send an ACK for every final response it gets. How the ACK gets sent depends on the response type 🧩. For final responses from 300 to 699, the transaction layer handles the ACK with one set of rules (check Section 17). For 2xx responses, the UAC core generates the ACK ✨.
A 2xx response to INVITE sets up a session AND creates a dialog between the UA that sent the INVITE and the UA that made the 2xx 💞. So if multiple 2xx responses come back from different remote UAs (because the INVITE forked 🍴), each 2xx makes its own dialog. They're all part of the same call 📞🩷.
This section covers the details on setting up a session with INVITE. A UA that supports INVITE MUST also support ACK, CANCEL and BYE 🫶.
13.2 UAC Processing 🎀
13.2.1 Creating the Initial INVITE 🍓
Since the initial INVITE is a request outside a dialog, building it follows the procedures of Section 8.1.1. INVITE needs a few extra steps tho 💅.
An Allow header field (Section 20.5) SHOULD be present in the INVITE. It says which methods can be invoked within a dialog, on the UA sending the INVITE, for the duration of the dialog. Like, a UA that can receive INFO requests within a dialog [34] SHOULD include an Allow header field listing INFO 🧾.
A Supported header field (Section 20.37) SHOULD be present in the INVITE. It lists all the extensions the UAC understands 🧠.
An Accept (Section 20.1) header field MAY be present in the INVITE. It shows which Content-Types the UA is cool with, both in the response it gets back and in any later requests sent to it within dialogs established by the INVITE 💌. Accept is super handy for session description formats 🎶.
The UAC MAY add an Expires header field (Section 20.19) to limit the validity of the invitation ⏳. If the time in the Expires header field is reached and no final answer for the INVITE has come in, the UAC core SHOULD generate a CANCEL request for the INVITE, as per Section 9 🚫.
A UAC MAY also find it useful to add Subject (Section 20.36), Organization (Section 20.25) and User-Agent (Section 20.41) header fields, among others 📝. They all carry info related to the INVITE 🩷.
The UAC MAY choose to add a message body to the INVITE. Section 8.1.1.10 deals with how to build the header fields (Content-Type among others) needed to describe the message body 📦.
Now, message bodies that contain a session description have special rules, and their Content-Disposition is "session" 🌈. SIP uses an offer/answer model where one UA sends a session description, called the offer, which proposes a description of the session 💜. The offer indicates the desired communications means (audio, video, games), the parameters of those means (like codec types), and addresses for receiving media from the answerer 🎧. The other UA responds with another session description, called the answer, which indicates which communications means are accepted, the parameters that apply to those means, and addresses for receiving media from the offerer 📬. An offer/answer exchange happens within a dialog, so if one INVITE results in multiple dialogs, each one is its own offer/answer exchange 👯. The model defines restrictions on when offers and answers can be made (like, you cannot make a new offer while one is in progress 🙅♀️), and those restrictions decide where offers and answers can show up in SIP messages. In this spec, offers and answers can only appear in INVITE requests and responses, and ACK 🧷. The usage is restricted even further. For the initial INVITE transaction, the rules are:
- The initial offer MUST be in either an INVITE or, if not there, in the first reliable non-failure message from the UAS back to the UAC. In this specification, that is the final 2xx response.
- If the initial offer is in an INVITE, the answer MUST be in a reliable non-failure message from UAS back to UAC which is correlated to that INVITE. For this specification, that is only the final 2xx response to that INVITE. That same exact answer MAY also be placed in any provisional responses sent prior to the answer. The UAC MUST treat the first session description it receives as the answer, and MUST ignore any session descriptions in subsequent responses to the initial INVITE.
- If the initial offer is in the first reliable non-failure message from the UAS back to UAC, the answer MUST be in the acknowledgement for that message (in this specification, ACK for a 2xx response).
- After having sent or received an answer to the first offer, the UAC MAY generate subsequent offers in requests based on rules specified for that method, but only if it has received answers to any previous offers, and has not sent any offers to which it hasn't gotten an answer.
- Once the UAS has sent or received an answer to the initial offer, it MUST NOT generate subsequent offers in any responses to the initial INVITE. This means that a UAS based on this specification alone can never generate subsequent offers until completion of the initial transaction.
Concretely, the above rules give two exchanges for UAs compliant to this spec alone 🤓. Either the offer is in the INVITE and the answer is in the 2xx (and possibly in a 1xx as well, with the same value), or the offer is in the 2xx and the answer is in the ACK. All user agents that support INVITE MUST support these two exchanges 🤝.
The Session Description Protocol (SDP) (RFC 2327 [1]) MUST be supported by all user agents as a means to describe sessions, and its usage for constructing offers and answers MUST follow the procedures defined in [13] 📜.
The offer-answer restrictions we just went over only apply to bodies whose Content-Disposition header field value is "session". So it's possible for both the INVITE and the ACK to contain a body 📸. For example, the INVITE carries a photo (Content-Disposition: render) and the ACK carries a session description (Content-Disposition: session).
If the Content-Disposition header field is missing, bodies of Content-Type application/sdp imply the disposition "session", while other content types imply "render" 🧐.
Once the INVITE has been created, the UAC follows the procedures for sending requests outside of a dialog (Section 8). This builds a client transaction that will ultimately send the request and deliver responses to the UAC 🚀.
13.2.2 Processing INVITE Responses 📬
Once the INVITE has been passed to the INVITE client transaction, the UAC waits for responses for the INVITE. If the INVITE client transaction returns a timeout rather than a response, the TU acts as if a 408 (Request Timeout) response had been received, as described in Section 8.1.3 ⏰.
13.2.2.1 1xx Responses 🌤️
Zero, one or multiple provisional responses may arrive before one or more final responses are received. Provisional responses for an INVITE request can create "early dialogs" 🐣. If a provisional response has a tag in the To field, and if the dialog ID of the response does not match an existing dialog, one is constructed using the procedures defined in Section 12.1.2 🛠️.
The early dialog only matters if the UAC needs to send a request to its peer within the dialog before the initial INVITE transaction completes. Header fields present in a provisional response are applicable as long as the dialog is in the early state (for example, an Allow header field in a provisional response contains the methods that can be used in the dialog while it's in the early state) 📋.
13.2.2.2 3xx Responses 🛸
A 3xx response may contain one or more Contact header field values providing new addresses where the callee might be reachable 🗺️. Depending on the status code of the 3xx response (see Section 21.3), the UAC MAY choose to try those new addresses 🧭.
13.2.2.3 4xx, 5xx and 6xx Responses 🙈
A single non-2xx final response may be received for the INVITE. 4xx, 5xx and 6xx responses may contain a Contact header field value indicating the location where additional information about the error can be found 🔍. Subsequent final responses (which would only arrive under error conditions) MUST be ignored 🚫.
All early dialogs are considered terminated upon reception of the non-2xx final response 💀.
After having received the non-2xx final response, the UAC core considers the INVITE transaction completed. The INVITE client transaction handles the generation of ACKs for the response (see Section 17) 🫶.
13.2.2.4 2xx Responses ✨
Okay so multiple 2xx responses can totally show up at the UAC for one INVITE because of a forking proxy 🍴 Each one is told apart by the tag parameter in the To header field, and each one is its own dialog with its own dialog identifier. Iconic, honestly 💅
If the dialog identifier in the 2xx response matches an existing dialog, that dialog MUST move to the "confirmed" state, and its route set MUST be recomputed from the 2xx response using the procedures of Section 12.2.1.2. If it doesn't match anything, a brand-new dialog in the "confirmed" state MUST be built using the procedures of Section 12.1.2 🎀
Note that the route set is the ONLY piece of state that gets recomputed. Stuff like the highest sequence numbers (remote and local) already sent in the dialog does NOT get recomputed. The route set gets refreshed just for backwards compatibility. RFC 2543 didn't require mirroring of the Record-Route header field in a 1xx, only in a 2xx. We can't update the whole dialog state, though, because mid-dialog requests might've gone out during the early dialog and changed the sequence numbers, for example 🙈
The UAC core MUST generate an ACK request for each 2xx it gets from the transaction layer. The ACK's header fields are built the same way as any request sent within a dialog (see Section 12), except for the CSeq and the authentication-related header fields 🫶 The sequence number in the CSeq header field MUST match the INVITE being acknowledged, but the CSeq method MUST be ACK. The ACK MUST contain the same credentials as the INVITE. If the 2xx has an offer (based on the rules above), the ACK MUST carry an answer in its body. And if that offer isn't acceptable, the UAC core MUST generate a valid answer in the ACK and then send a BYE immediately 💀
Once the ACK is built, the procedures of [4] figure out the destination address, port and transport. The difference is that the request goes straight to the transport layer for sending, not through a client transaction. That's because the UAC core handles the ACK's retransmissions, not the transaction layer 🦋 The ACK MUST be passed to the client transport every single time a retransmission of the 2xx final response that triggered it shows up.
The UAC core considers the INVITE transaction completed 64*T1 seconds after the first 2xx arrives. At that point, every early dialog that never became an established dialog gets terminated. Once the UAC core calls the INVITE transaction completed, no new 2xx responses are expected anymore 🧚
If the UAC has acknowledged a 2xx to an INVITE and decides it doesn't want to continue with that dialog, then the UAC MUST terminate it by sending a BYE request as described in Section 15. No drama, just exit ✨
13.3 UAS Processing 👑
13.3.1 Processing of the INVITE 🎀
The UAS core gets INVITE requests from the transaction layer. First it runs the request processing procedures of Section 8.2, which apply to requests both inside and outside of a dialog.
Assuming those steps finish without generating a response, the UAS core then does the extra processing:
- If the request is an INVITE that has an Expires header field, the UAS core sets a timer for the number of seconds in the header field value. When the timer fires, the invitation counts as expired. If it expires before the UAS has generated a final response, a 487 (Request Terminated) response SHOULD be generated 💀
- If the request is a mid-dialog request, the method-independent processing from Section 12.2.2 gets applied first. That might also change the session, and Section 14 has the details 🌸
- If the request has a tag in the
Toheader field but the dialog identifier doesn't match any existing dialog, the UAS may have crashed and restarted, or it may have gotten a request meant for a different (possibly failed) UAS. Section 12.2.2 has guidelines for handling this robustly 🙈
From here on, we're assuming the INVITE is outside of a dialog, which means it's for setting up a brand-new session 🦋
The INVITE might carry a session description, in which case the UAS is being handed an offer for that session. The user could already be part of that session even though the INVITE is outside a dialog. That happens when someone gets invited to the same multicast conference by several other people. If it's useful, the UAS MAY use identifiers in the session description to spot that duplicate. For example, SDP has a session id and version number in the origin (o) field. If the user is already in the session and the session parameters haven't changed, the UAS MAY silently accept the INVITE (so, send a 2xx without prompting the user) ✨
If the INVITE has NO session description, the UAS is being asked to join a session, and the UAC has asked the UAS to provide the offer for it. The UAS MUST provide that offer in its first non-failure reliable message back to the UAC. In this spec, that's a 2xx response to the INVITE 🫶
The UAS can show progress, accept, redirect or reject the invitation. For all of these, it builds a response using the procedures in Section 8.2.6 💖
13.3.1.1 Progress 🌈
If the UAS can't answer the invitation right away, it can send some kind of progress update to the UAC (like a phone ringing, for example). That happens with a provisional response between 101 and 199. These provisional responses set up early dialogs, so they follow the procedures of Section 12.1.1 on top of the ones in Section 8.2.6. A UAS MAY send as many provisional responses as it wants. Each of them MUST indicate the same dialog ID. These ones won't be delivered reliably though 😭
If the UAS needs a long time to answer the INVITE, it has to ask for an "extension" so proxies don't cancel the transaction. A proxy can choose to cancel a transaction when there's a gap of 3 minutes between responses. To prevent that, the UAS MUST send a non-100 provisional response every minute, in case some provisional responses got lost 🍓
An INVITE transaction can run for a long time when the user is put on hold, or when interworking with PSTN systems that let communication happen without answering the call. The second one is super common in Interactive Voice Response (IVR) systems 📞
13.3.1.2 The INVITE is Redirected 🦋
If the UAS decides to redirect the call, it sends a 3xx response. A 300 (Multiple Choices), 301 (Moved Permanently) or 302 (Moved Temporarily) response SHOULD contain a Contact header field with one or more URIs for the new addresses to try. The response goes to the INVITE server transaction, which handles its retransmissions 🧚
13.3.1.3 The INVITE is Rejected 💅
This comes up a lot when the callee isn't willing or able to take more calls on this end system. In that case, a 486 (Busy Here) SHOULD be returned. If the UAS knows that no other end system could accept this call, a 600 (Busy Everywhere) response SHOULD be sent instead. Honestly though, a UAS usually can't know that in general, so this one doesn't get used much 🙈 The response goes to the INVITE server transaction, which handles its retransmissions.
A UAS rejecting an offer in an INVITE SHOULD return a 488 (Not Acceptable Here) response. That response SHOULD include a Warning header field value explaining why the offer got rejected 🔥
13.3.1.4 The INVITE is Accepted 🎉
The UAS core generates a 2xx response. This one establishes a dialog, so it follows the procedures of Section 12.1.1 along with Section 8.2.6 👑
A 2xx response to an INVITE SHOULD contain the Allow header field and the Supported header field, and MAY contain the Accept header field. Including these lets the UAC figure out the features and extensions the UAS supports for the whole call, without having to probe for them ✨
If the INVITE request had an offer and the UAS hadn't sent an answer yet, the 2xx MUST contain an answer. If the INVITE didn't have an offer, the 2xx MUST contain an offer if the UAS hadn't sent one yet 🫶
Once the response is built, it goes to the INVITE server transaction. Heads up though: the INVITE server transaction gets destroyed as soon as it takes this final response and hands it to the transport. So the UAS has to keep passing the response straight to the transport until the ACK shows up 🌸 The 2xx goes to the transport on an interval that starts at T1 seconds and doubles with each retransmission until it hits T2 seconds (T1 and T2 are defined in Section 17). Response retransmissions stop once an ACK request for the response arrives. This doesn't depend on which transport protocols are used to send the response 💖
Since the 2xx is retransmitted end-to-end, there might be hops between the UAS and UAC that run over UDP. To make delivery reliable across those hops, the response keeps getting retransmitted periodically, even if the transport at the UAS is reliable 🍓
If the server retransmits the 2xx for 64*T1 seconds without getting an ACK, the dialog is confirmed, but the session SHOULD be terminated. That's done with a BYE, as described in Section 15. Yikes, not the vibe 😭
14 Modifying an Existing Session 🦋
A successful INVITE request (see Section 13) sets up both a dialog between two user agents and a session that uses the offer-answer model 🫶 Section 12 explains how to modify an existing dialog with a target refresh request (for example, changing the dialog's remote target URI). This section is about modifying the actual session. That can mean changing addresses or ports, adding a media stream, deleting a media stream, and so on. It's done by sending a new INVITE request within the same dialog that set up the session. An INVITE sent inside an existing dialog is called a re-INVITE 💜
A single re-INVITE can modify the dialog and the session parameters at the same time. Multitasking queen 👑
Either the caller or the callee can modify an existing session ✨
How a UA reacts when it detects media failure is a matter of local policy. However, automatically generated re-INVITE or BYE requests are NOT RECOMMENDED, because they could flood the network with traffic when there's congestion. Either way, if these messages get sent automatically, they SHOULD be sent after some randomized interval 🌈
The paragraph above is about automatically generated BYEs and re-INVITEs. If the user hangs up when media fails, the UA sends a BYE request as usual, no problem 📞
14.1 UAC Behavior
Okay so the same offer-answer model that handles session descriptions in INVITEs (Section 13.2.1) also applies to re-INVITEs 💅 That means a UAC that wants to add a media stream will whip up a new offer containing that stream and send it in an INVITE request to its peer. The key thing: the full description of the session gets sent, not just the change 🫶 That's what keeps stateless session processing working across different elements and makes failover and recovery possible, which is literally so iconic ✨ Of course, a UAC MAY send a re-INVITE with no session description. In that case, the first reliable non-failure response to the re-INVITE will carry the offer (in this specification, that's a 2xx response) 🎀
If the session description format has the capability for version numbers, the offerer SHOULD indicate that the version of the session description has changed 🔢
The To, From, Call-ID, CSeq, and Request-URI of a re-INVITE are set using the same rules as regular requests within an existing dialog, which you can read about in Section 12 🦋
A UAC MAY choose not to add an Alert-Info header field or a body with Content-Disposition "alert" to re-INVITEs. Honestly, that makes sense, because UASs don't usually alert the user when they get a re-INVITE 🙈
Unlike an INVITE, which can fork, a re-INVITE will never fork. So it only ever generates a single final response 🍓 The reason is that the Request-URI identifies the target as the UA instance the dialog was established with, rather than identifying an address-of-record for the user. Main character energy for the Request-URI, fr fr 👑
Note that a UAC MUST NOT initiate a new INVITE transaction within a dialog while another INVITE transaction is in progress in either direction. Bestie, this is a hard rule 🚫
- If there is an ongoing INVITE client transaction, the TU MUST wait until the transaction reaches the completed or terminated state before initiating the new INVITE.
- If there is an ongoing INVITE server transaction, the TU MUST wait until the transaction reaches the confirmed or terminated state before initiating the new INVITE.
However, a UA MAY initiate a regular transaction while an INVITE transaction is in progress. A UA MAY also initiate an INVITE transaction while a regular transaction is in progress 🌈
If a UA receives a non-2xx final response to a re-INVITE, the session parameters MUST remain unchanged, as if no re-INVITE had been issued 🥺 Note that, as stated in Section 12.2.1.2, if the non-2xx final response is a 481 (Call/Transaction Does Not Exist), or a 408 (Request Timeout), or if no response at all is received for the re-INVITE (that is, a timeout is returned by the INVITE client transaction), the UAC will terminate the dialog. Yikes, that's a whole plot twist 💀
If a UAC receives a 491 response to a re-INVITE, it SHOULD start a timer with a value T chosen as follows:
- If the UAC is the owner of the Call-ID of the dialog ID (meaning it generated the value), T has a randomly chosen value between 2.1 and 4 seconds in units of 10 ms.
- If the UAC is not the owner of the Call-ID of the dialog ID, T has a randomly chosen value of between 0 and 2 seconds in units of 10 ms.
When the timer fires, the UAC SHOULD attempt the re-INVITE once more, if it still wants that session modification to happen 🔁 For example, if the call was already hung up with a BYE, the re-INVITE would not take place. Bye means bye 👋
The rules for transmitting a re-INVITE and for generating an ACK for a 2xx response to a re-INVITE are the same as for the initial INVITE (Section 13.2.1) 🧚
14.2 UAS Behavior
Section 13.3.1 explains how to tell incoming re-INVITEs apart from incoming initial INVITEs, and how to handle a re-INVITE for an existing dialog 🗺️
A UAS that receives a second INVITE before it sends the final response to a first INVITE with a lower CSeq sequence number on the same dialog MUST return a 500 (Server Internal Error) response to the second INVITE, and MUST include a Retry-After header field with a randomly chosen value of between 0 and 10 seconds 😭
A UAS that receives an INVITE on a dialog while an INVITE it had sent on that dialog is in progress MUST return a 491 (Request Pending) response to the received INVITE 🙅♀️
If a UA receives a re-INVITE for an existing dialog, it MUST check any version identifiers in the session description or, if there are no version identifiers, the content of the session description, to see if it has changed. If the session description has changed, the UAS MUST adjust the session parameters accordingly, possibly after asking the user for confirmation ✅
Versioning of the session description can be used to accommodate the capabilities of new arrivals to a conference, add or delete media, or change from a unicast to a multicast conference. Versioning is giving flexibility 🌸
If the new session description isn't acceptable, the UAS can reject it by returning a 488 (Not Acceptable Here) response to the re-INVITE. This response SHOULD include a Warning header field ⚠️
If a UAS generates a 2xx response and never receives an ACK, it SHOULD generate a BYE to terminate the dialog 📵
A UAS MAY choose not to generate 180 (Ringing) responses to a re-INVITE, because UACs don't typically show this information to the user. For the same reason, UASs MAY choose not to use an Alert-Info header field or a body with Content-Disposition "alert" in responses to a re-INVITE 🔕
A UAS providing an offer in a 2xx (because the INVITE didn't contain an offer) SHOULD construct the offer as if the UAS were making a brand new call, subject to the constraints of sending an offer that updates an existing session, as described in [13] in the case of SDP. Specifically, this means it SHOULD include as many media formats and media types as the UA is willing to support 🎶 The UAS MUST ensure that the session description overlaps with its previous session description in media formats, transports, or other parameters that require support from the peer. This avoids the peer having to reject the session description 🤝 If, however, the offer is unacceptable to the UAC, the UAC SHOULD generate an answer with a valid session description, and then send a BYE to terminate the session 💔
15 Terminating a Session
This section explains the procedures for terminating a session established by SIP. The state of the session and the state of the dialog are very closely related 💞 When a session is initiated with an INVITE, each 1xx or 2xx response from a distinct UAS creates a dialog. If that response completes the offer/answer exchange, it also creates a session. So each session is "associated" with a single dialog, the one that resulted in its creation 🧩 If an initial INVITE generates a non-2xx final response, that terminates all sessions (if any) and all dialogs (if any) that were created through responses to the request. Because the transaction is completed, a non-2xx final response also stops any further sessions from being created as a result of the INVITE 🛑 The BYE request is used to terminate a specific session or attempted session. In this case, the specific session is the one with the peer UA on the other side of the dialog. When a BYE is received on a dialog, any session associated with that dialog SHOULD terminate. A UA MUST NOT send a BYE outside of a dialog. The caller's UA MAY send a BYE for either confirmed or early dialogs, and the callee's UA MAY send a BYE on confirmed dialogs, but MUST NOT send a BYE on early dialogs 📞
However, the callee's UA MUST NOT send a BYE on a confirmed dialog until it has received an ACK for its 2xx response or until the server transaction times out. If no SIP extensions have defined other application layer states associated with the dialog, the BYE also terminates the dialog 🫡
The impact of a non-2xx final response to an INVITE on dialogs and sessions makes CANCEL super attractive 🧲 CANCEL attempts to force a non-2xx response to the INVITE (in particular, a 487). So if a UAC wants to give up on its call attempt entirely, it can send a CANCEL. If the INVITE results in 2xx final response(s), that means a UAS accepted the invitation while the CANCEL was in progress. The UAC MAY continue with the sessions established by any 2xx responses, or MAY terminate them with a BYE 🎭
The notion of "hanging up" isn't well defined within SIP. It's specific to a particular, albeit common, user interface. Typically, when the user hangs up, it means they want to end the attempt to establish a session, and terminate any sessions already created. For the caller's UA, this would imply a CANCEL request if the initial INVITE has not generated a final response, and a BYE to all confirmed dialogs after a final response. For the callee's UA, it would typically imply a BYE. Presumably, when the user picked up the phone, a 2xx was generated, so hanging up would result in a BYE after the ACK is received. This doesn't mean a user can't hang up before receipt of the ACK. It just means the software in their phone needs to maintain state for a short while in order to clean up properly 🧹 If the particular UI allows the user to reject a call before it's answered, a 403 (Forbidden) is a good way to express that. As per the rules above, a BYE can't be sent 🙅
15.1 Terminating a Session with a BYE Request
15.1.1 UAC Behavior
A BYE request is constructed just like any other request within a dialog, as described in Section 12 💌
Once the BYE is constructed, the UAC core creates a new non-INVITE client transaction and passes it the BYE request. The UAC MUST consider the session terminated (and therefore stop sending or listening for media) as soon as the BYE request is passed to the client transaction. If the response for the BYE is a 481 (Call/Transaction Does Not Exist) or a 408 (Request Timeout), or if no response at all is received for the BYE (that is, a timeout is returned by the client transaction), the UAC MUST consider the session and the dialog terminated 🏁
15.1.2 UAS Behavior
A UAS first processes the BYE request according to the general UAS processing described in Section 8.2 🔍 A UAS core that receives a BYE request checks whether it matches an existing dialog. If the BYE doesn't match an existing dialog, the UAS core SHOULD generate a 481 (Call/Transaction Does Not Exist) response and pass it to the server transaction 🫥
This rule means that a BYE sent without tags by a UAC will be rejected. This is a change from RFC 2543, which allowed BYE without tags. Glow-up energy 🌟
A UAS core that receives a BYE request for an existing dialog MUST follow the procedures of Section 12.2.2 to process the request. Once that's done, the UAS SHOULD terminate the session (and therefore stop sending and listening for media). The only case where it can choose not to is multicast sessions, where participation is possible even if the other participant in the dialog has ended its involvement in the session 📡 Whether or not it ends its participation in the session, the UAS core MUST generate a 2xx response to the BYE, and MUST pass that to the server transaction for transmission 💫
The UAS MUST still respond to any pending requests received for that dialog. It is RECOMMENDED that a 487 (Request Terminated) response be generated for those pending requests 🌙
16 Proxy Behavior ✨
16.1 Overview 💖
okay so SIP proxies are the elements that route SIP requests on to user agent servers and send SIP responses back to user agent clients 🦋. A request can hop through several proxies on its way to a UAS, and each one makes routing decisions and tweaks the request before passing it along ✨. Responses take the exact same proxies the request went through, just in reverse order 🔁.
Being a proxy is a role an element plays, not a permanent identity 🎀. When a request shows up, an element that can be a proxy first decides whether it needs to answer the request itself. Maybe the request is malformed, or the element needs credentials from the client before it'll act as a proxy 🙈. The element MAY respond with any appropriate error code. When it responds directly, it's playing the UAS role and MUST behave as described in Section 8.2 💅.
Proxies can work in either stateful or stateless mode, decided for each new request 🌸. Stateless means it's a simple forwarding element: it sends each request downstream to one single element picked by a targeting and routing decision, and it passes every response upstream. It tosses out info about a message once it's been forwarded. Stateful means it remembers stuff (specifically transaction state) about each incoming request and any requests it sends because of that one, and uses that memory to handle future messages tied to that request 🧠. A stateful proxy MAY choose to "fork" a request, routing it to multiple destinations. Any request forwarded to more than one location MUST be handled statefully.
In some situations a proxy MAY forward requests over stateful transports (like TCP) without being transaction-stateful 🚂. For example, a proxy MAY forward a request from one TCP connection to another transaction statelessly, as long as it packs enough info into the message to send the response back down the same connection the request arrived on. Requests forwarded between different types of transports, where the proxy's TU must take an active role in making sure delivery is reliable on one of the transports, MUST be forwarded transaction statefully 🔒.
A stateful proxy MAY switch to stateless operation at any point while processing a request, as long as it hasn't done anything that would have stopped it being stateless from the start (like forking, or generating a 100 response) 🙃. When it switches, all state just gets dropped. The proxy SHOULD NOT initiate a CANCEL request.
Lots of the processing is identical whether a proxy is acting statelessly or statefully 💕. The next few subsections are written from a stateful proxy's point of view, and the last section calls out where a stateless proxy does things differently ✨.
16.2 Stateful Proxy 🧁
When stateful, a proxy is purely a SIP transaction processing engine 🏭. Its behavior is modeled in terms of the server and client transactions defined in Section 17. A stateful proxy has a server transaction tied to one or more client transactions by a higher layer proxy processing component (see figure 3), known as a proxy core. An incoming request gets handled by a server transaction, and requests from that server transaction get passed to the proxy core. The proxy core decides where to route the request, picking one or more next-hop locations. Each outgoing request for each next hop gets its own client transaction. The proxy core collects the responses from those client transactions and uses them to send responses back to the server transaction 🎀.
A stateful proxy creates a new server transaction for each new request it receives. Any retransmissions of the request then get handled by that server transaction per Section 17. The proxy core MUST behave as a UAS with respect to sending an immediate provisional on that server transaction (such as 100 Trying), as described in Section 8.2.6. So a stateful proxy SHOULD NOT generate 100 (Trying) responses to non-INVITE requests 🙅♀️.
This is a model of proxy behavior, not of software. An implementation is free to take any approach that reproduces the external behavior this model defines 🫶.
For all new requests, including any with unknown methods, an element intending to proxy the request MUST:
- Validate the request (Section 16.3)
- Preprocess routing information (Section 16.4)
- Determine target(s) for the request (Section 16.5)
- Forward the request to each target (Section 16.6)
- Process all responses (Section 16.7)
+--------------------+
| | +---+
| | | C |
| | | T |
| | +---+
+---+ | Proxy | +---+ CT = Client Transaction
| S | | "Higher" Layer | | C |
| T | | | | T | ST = Server Transaction
+---+ | | +---+
| | +---+
| | | C |
| | | T |
| | +---+
+--------------------+
Figure 3: Stateful Proxy Model16.3 Request Validation 🔍
Before an element can proxy a request, it MUST verify the message's validity. A valid message must pass the following checks:
- Reasonable Syntax
- URI scheme
- Max-Forwards
- (Optional) Loop Detection
- Proxy-Require
- Proxy-Authorization
If any of these checks fail, the element MUST behave as a user agent server (see Section 8.2) and respond with an error code 😬.
Notice that a proxy is not required to detect merged requests, and it MUST NOT treat merged requests as an error condition. The endpoints receiving the requests will resolve the merge as described in Section 8.2.2.2 🤝.
1. Reasonable syntax check 🧼
The request MUST be well-formed enough to be handled with a server transaction. Any components involved in the remainder of these Request Validation steps or the Request Forwarding section MUST be well-formed. Any other components, well-formed or not, SHOULD be ignored and remain unchanged when the message is forwarded. For instance, an element would not reject a request because of a malformed Date header field. Likewise, a proxy would not remove a malformed Date header field before forwarding a request.
This protocol is designed to be extended. Future extensions may define new methods and header fields at any time. An element MUST NOT refuse to proxy a request because it contains a method or header field it does not know about 🌈.
2. URI scheme check 🔗
If the Request-URI has a URI whose scheme is not understood by the proxy, the proxy SHOULD reject the request with a 416 (Unsupported URI Scheme) response.
3. Max-Forwards check ⏳
The Max-Forwards header field (Section 20.22) is used to limit the number of elements a SIP request can traverse.
If the request does not contain a Max-Forwards header field, this check is passed.
If the request contains a Max-Forwards header field with a field value greater than zero, the check is passed.
If the request contains a Max-Forwards header field with a field value of zero (0), the element MUST NOT forward the request. If the request was for OPTIONS, the element MAY act as the final recipient and respond per Section 11. Otherwise, the element MUST return a 483 (Too many hops) response 🛑.
4. Optional Loop Detection check 🌀
An element MAY check for forwarding loops before forwarding a request. If the request contains a Via header field with a sent-by value that equals a value placed into previous requests by the proxy, the request has been forwarded by this element before. The request has either looped or is legitimately spiraling through the element. To determine if the request has looped, the element MAY perform the branch parameter calculation described in Step 8 of Section 16.6 on this message and compare it to the parameter received in that Via header field. If the parameters match, the request has looped. If they differ, the request is spiraling, and processing continues. If a loop is detected, the element MAY return a 482 (Loop Detected) response 🔁.
5. Proxy-Require check 📋
Future extensions to this protocol may introduce features that require special handling by proxies. Endpoints will include a Proxy-Require header field in requests that use these features, telling the proxy not to process the request unless the feature is understood.
If the request contains a Proxy-Require header field (Section 20.29) with one or more option-tags this element does not understand, the element MUST return a 420 (Bad Extension) response. The response MUST include an Unsupported (Section 20.40) header field listing those option-tags the element did not understand 🙏.
6. Proxy-Authorization check 🔐
If an element requires credentials before forwarding a request, the request MUST be inspected as described in Section 22.3. That section also defines what the element must do if the inspection fails 🗝️.
16.4 Route Information Preprocessing 🗺️
The proxy MUST inspect the Request-URI of the request. If the Request-URI of the request contains a value this proxy previously placed into a Record-Route header field (see Section 16.6 item 4), the proxy MUST replace the Request-URI in the request with the last value from the Route header field, and remove that value from the Route header field. The proxy MUST then proceed as if it received this modified request 💫.
This will only happen when the element sending the request to the proxy (which may have been an endpoint) is a strict router. This rewrite on receive is necessary to enable backwards compatibility with those elements. It also allows elements following this specification to preserve the Request-URI through strict-routing proxies (see Section 12.2.1.1) 🙌.
This requirement does not obligate a proxy to keep state in order to detect URIs it previously placed in Record-Route header fields. Instead, a proxy need only place enough information in those URIs to recognize them as values it provided when they later appear 🧠.
If the Request-URI contains a maddr parameter, the proxy MUST check to see if its value is in the set of addresses or domains the proxy is configured to be responsible for. If the Request-URI has a maddr parameter with a value the proxy is responsible for, and the request was received using the port and transport indicated (explicitly or by default) in the Request-URI, the proxy MUST strip the maddr and any non-default port or transport parameter and continue processing as if those values had not been present in the request 🧹.
A request may arrive with a maddr matching the proxy, but on a port or transport different from the one indicated in the URI. Such a request needs to be forwarded to the proxy using the indicated port and transport 🚚.
If the first value in the Route header field indicates this proxy, the proxy MUST remove that value from the request 🎀.
16.5. Determining Request Targets ✨
Okay so next up, the proxy has to figure out the target(s) of the request 🎯 The set of targets is either already decided by what's in the request, or it comes from an abstract location service. Each target in the set is written as a URI.
If the Request-URI has an maddr parameter, the Request-URI MUST be placed into the target set as the only target URI, and the proxy MUST proceed to Section 16.6. 🦋
If the domain of the Request-URI is one this element is not responsible for, the Request-URI MUST be placed into the target set as the only target, and the element MUST proceed to the task of Request Forwarding (Section 16.6). 💅
🧚 Note: a proxy can get a request for a domain it isn't responsible for in lots of situations. A firewall proxy handling outgoing calls (kinda like how HTTP proxies handle outgoing requests) is a classic example of where this is likely to happen.
If the target set hasn't been decided in advance like described above, that means the element IS responsible for the domain in the Request-URI, and the element MAY use whatever mechanism it wants to decide where the request goes 🫶 Any of these mechanisms can be thought of as accessing an abstract Location Service. That could mean grabbing info from a location service built by a SIP Registrar, reading a database, checking a presence server, using other protocols, or just doing an algorithmic substitution on the Request-URI. When you access the location service built by a registrar, the Request-URI MUST first be canonicalized as described in Section 10.3 before it gets used as an index 🔑 The output from these mechanisms is what builds the target set.
If the Request-URI doesn't give the proxy enough info to figure out the target set, it SHOULD return a 485 (Ambiguous) response. This response SHOULD contain a Contact header field with URIs of new addresses to try. For example, an INVITE to sip:John.Smith@company.com could be ambiguous at a proxy whose location service has multiple John Smiths listed 🙈 See Section 21.4.23 for details.
Any info in or about the request, or about the element's current environment, MAY be used when building the target set. Like, different sets can be made depending on the contents or presence of header fields and bodies, the time of day the request arrived, the interface it arrived on, failures of previous requests, or even how busy the element currently is 🌸
As potential targets get located through these services, their URIs get added to the target set. Targets can only be placed in the target set once. If a target URI is already in the set (based on the definition of equality for the URI type), it MUST NOT be added again 🚫
A proxy MUST NOT add additional targets to the target set if the Request-URI of the original request doesn't indicate a resource this proxy is responsible for. 💀
🎀 Note: a proxy can only change the Request-URI of a request during forwarding if it's responsible for that URI. If it's not responsible for that URI, it won't recurse on 3xx or 416 responses like described below.
If the Request-URI of the original request DOES indicate a resource this proxy is responsible for, the proxy MAY keep adding targets to the set even after Request Forwarding has started. It MAY use any info it gets during that processing to figure out new targets. For instance, a proxy might choose to add contacts it got from a redirect response (3xx) into the target set ✨ If a proxy uses a dynamic source of info while building the target set (like if it checks a SIP Registrar), it SHOULD monitor that source for as long as it's processing the request. New locations SHOULD be added to the target set as they become available. Same deal as before: any given URI MUST NOT be added to the set more than once 🔁
💜 Note: only letting a URI get added to the set once cuts down on unnecessary network traffic, and when it comes to adding contacts from redirect responses, it's what stops infinite recursion. Iconic.
For example, a trivial location service is a "no-op", where the target URI is equal to the incoming request URI. The request gets sent to one specific next hop proxy for further processing. During request forwarding of Section 16.6, Item 6, the identity of that next hop, written as a SIP or SIPS URI, gets inserted as the top-most Route header field value into the request 🦋
If the Request-URI points to a resource at this proxy that doesn't exist, the proxy MUST return a 404 (Not Found) response. 🙅♀️
If the target set is still empty after all of the above, the proxy MUST return an error response, which SHOULD be the 480 (Temporarily Unavailable) response. 🥺
16.6. Request Forwarding 💖
As soon as the target set has something in it, a proxy MAY begin forwarding the request. A stateful proxy MAY process the set in any order. It MAY process multiple targets serially, letting each client transaction finish before starting the next one. It MAY start client transactions with every target in parallel. It also MAY arbitrarily divide the set into groups, processing the groups serially and processing the targets in each group in parallel 🌈
A common ordering mechanism is to use the qvalue parameter of targets obtained from Contact header fields (see Section 20.10). Targets get processed from highest qvalue to lowest. Targets with equal qvalues may be processed in parallel 👑
A stateful proxy must have a mechanism to keep track of the target set as responses come in, and to associate the responses to each forwarded request with the original request. For the purposes of this model, this mechanism is a "response context" that the proxy layer creates before forwarding the first request 🧚
For each target, the proxy forwards the request by following these steps:
- Make a copy of the received request
- Update the Request-URI
- Update the Max-Forwards header field
- Optionally add a Record-route header field value
- Optionally add additional header fields
- Postprocess routing information
- Determine the next-hop address, port, and transport
- Add a Via header field value
- Add a Content-Length header field if necessary
- Forward the new request
- Set timer C
Each of these steps gets detailed below, so let's go bestie 🫶
- Copy request
The proxy starts with a copy of the received request. The copy MUST initially contain all of the header fields from the received request. Fields that aren't detailed in the processing described below MUST NOT be removed. The copy SHOULD keep the ordering of the header fields as they were in the received request. The proxy MUST NOT reorder field values with a common field name (See Section 7.3.1). The proxy MUST NOT add to, modify, or remove the message body. 📋
An actual implementation doesn't need to perform a copy (it need not, lowercase fr). The main requirement is that the processing for each next hop begins with the same request.
- Request-URI
The Request-URI in the copy's start line MUST be replaced with the URI for this target. If the URI contains any parameters that aren't allowed in a Request-URI, they MUST be removed. 🎯
Honestly this is the essence of a proxy's whole role. This is the mechanism a proxy uses to route a request toward its destination ✨
In some circumstances, the received Request-URI gets placed into the target set without being modified. For that target, the replacement above is effectively a no-op 🙃
- Max-Forwards
If the copy contains a Max-Forwards header field, the proxy MUST decrement its value by one (1). 📉
If the copy does NOT contain a Max-Forwards header field, the proxy MUST add one with a field value, which SHOULD be 70. 💅
🦋 Note: some existing UAs won't provide a Max-Forwards header field in a request. Lowkey a whole vibe.
- Record-Route
If this proxy wants to stay on the path of future requests in a dialog created by this request (assuming the request creates a dialog), it MUST insert a Record-Route header field value into the copy before any existing Record-Route header field values, even if a Route header field is already present 🛤️
Requests that establish a dialog may contain a preloaded Route header field. 🌸
If this request is already part of a dialog, the proxy SHOULD insert a Record-Route header field value if it wants to stay on the path of future requests in the dialog. In normal endpoint operation as described in Section 12, these Record-Route header field values won't have any effect on the route sets the endpoints use 🙈
The proxy will stay on the path if it chooses NOT to insert a Record-Route header field value into requests that are already part of a dialog. However, it would be removed from the path when an endpoint that has failed reconstitutes the dialog 😭
A proxy MAY insert a Record-Route header field value into any request. If the request doesn't initiate a dialog, the endpoints will ignore the value. See Section 12 for details on how endpoints use the Record-Route header field values to build Route header fields 🧚
Each proxy in the path of a request decides independently whether to add a Record-Route header field value. The presence of a Record-Route header field in a request does NOT obligate this proxy to add a value 🫶
The URI placed in the Record-Route header field value MUST be a SIP or SIPS URI. This URI MUST contain an lr parameter (see Section 19.1.1). This URI MAY be different for each destination the request gets forwarded to. The URI SHOULD NOT contain the transport parameter unless the proxy knows (like in a private network) that the next downstream element in the path of subsequent requests supports that transport 👑
The URI this proxy provides will be used by some other element to make a routing decision. This proxy, in general, has no way of knowing what that element can do, so it must restrict itself to the mandatory elements of a SIP implementation: SIP URIs and either the TCP or UDP transports. 🥹
The URI placed in the Record-Route header field value MUST resolve to the element inserting it (or a suitable stand-in) when the server location procedures of [4] are applied to it, so that subsequent requests reach the same SIP element 🔁 If the Request-URI contains a SIPS URI, or the topmost Route header field value (after the post processing of bullet 6) contains a SIPS URI, the URI placed into the Record-Route header field MUST be a SIPS URI. Furthermore, if the request was not received over TLS, the proxy MUST insert a Record-Route header field. In a similar fashion, a proxy that receives a request over TLS but generates a request without a SIPS URI in the Request-URI or topmost Route header field value (after the post processing of bullet 6) MUST insert a Record-Route header field that is not a SIPS URI. 🔐
A proxy sitting at a security perimeter has to stay on that perimeter for the entire dialog, no exceptions 🧱🔒✨
If the URI in the Record-Route header field needs rewriting as it passes back through in a response, that URI MUST be distinct enough to locate at that time 🔍 (the request may spiral through this proxy, which means more than one Record-Route header field value can get added 🌀). Item 8 of Section 16.7 recommends a mechanism to make the URI sufficiently distinct, so go check that out 💖
The proxy MAY include parameters in the Record-Route header field value 🎀 These get echoed in some responses to the request, like the 200 (OK) responses to INVITE. Parameters like these can be handy for keeping state in the message instead of in the proxy 🧠
If a proxy needs to be in the path of any type of dialog (like one straddling a firewall 🧱), it SHOULD add a Record-Route header field value to every request with a method it does not understand, since that method may have dialog semantics 👀
The URI a proxy places into a Record-Route header field is only valid for the lifetime of any dialog created by the transaction it shows up in 💅 A dialog-stateful proxy, for example, MAY refuse to accept future requests with that value in the Request-URI once the dialog has terminated. Non-dialog-stateful proxies have no clue when the dialog ends (not their problem, lol), but they MAY encode enough information in the value to compare it against the dialog identifier of future requests, and they MAY reject requests that don't match that information. Endpoints MUST NOT use a URI obtained from a Record-Route header field outside the dialog in which it was provided 🚫 See Section 12 for more on how endpoints use Record-Route header fields 📖
Record-routing may be required by certain services where the proxy needs to observe every message in a dialog. BUT it slows down processing and hurts scalability, so proxies should only record-route if a particular service actually requires it 🐢
The Record-Route process is designed to work for any SIP request that initiates a dialog. INVITE is the only such request in this specification, but extensions to the protocol MAY define others 🦋
5. Add Additional Header Fields ✨
The proxy MAY add any other appropriate header fields to the copy at this point 💖
6. Postprocess routing information 🗺️
A proxy MAY have a local policy that mandates that a request visit a specific set of proxies before being delivered to the destination. A proxy MUST ensure that all such proxies are loose routers. Generally, this can only be known with certainty if the proxies are within the same administrative domain. This set of proxies is represented by a set of URIs (each of which contains the lr parameter). This set MUST be pushed into the Route header field of the copy ahead of any existing values, if present. If the Route header field is absent, it MUST be added, containing that list of URIs 🌸
If the proxy has a local policy that mandates the request visit one specific proxy, an alternative to pushing a Route value into the Route header field is to bypass the forwarding logic of item 10 below, and instead just send the request to the address, port, and transport for that specific proxy. If the request has a Route header field, this alternative MUST NOT be used unless it is known that the next hop proxy is a loose router. Otherwise, this approach MAY be used, but the Route insertion mechanism above is preferred for its robustness, flexibility, generality, and consistency of operation 💅 Furthermore, if the Request-URI contains a SIPS URI, TLS MUST be used to communicate with that proxy 🔐
If the copy contains a Route header field, the proxy MUST inspect the URI in its first value. If that URI does not contain an lr parameter, the proxy MUST modify the copy as follows:
- The proxy MUST place the Request-URI into the Route header field as the last value.
- The proxy MUST then place the first Route header field value into the Request-URI and remove that value from the Route header field.
Appending the Request-URI to the Route header field is part of a mechanism used to pass the information in that Request-URI through strict-routing elements 🧚 "Popping" the first Route header field value into the Request-URI formats the message the way a strict-routing element expects to receive it (with its own URI in the Request-URI and the next location to visit in the first Route header field value) 🎀
7. Determine Next-Hop Address, Port, and Transport 📍
The proxy MAY have a local policy to send the request to a specific IP address, port, and transport, independent of the values of the Route and Request-URI. Such a policy MUST NOT be used if the proxy is not certain that the IP address, port, and transport correspond to a server that is a loose router. However, this mechanism for sending the request through a specific next hop is NOT RECOMMENDED 🙅♀️ instead, a Route header field should be used for that purpose, as described above.
In the absence of such an overriding mechanism, the proxy applies the procedures listed in [4] as follows to determine where to send the request. If the proxy has reformatted the request to send to a strict-routing element as described in step 6 above, the proxy MUST apply those procedures to the Request-URI of the request. Otherwise, the proxy MUST apply the procedures to the first value in the Route header field, if present, else the Request-URI. The procedures will produce an ordered set of (address, port, transport) tuples. Independently of which URI is being used as input to the procedures of [4], if the Request-URI specifies a SIPS resource, the proxy MUST follow the procedures of [4] as if the input URI were a SIPS URI 🔒
As described in [4], the proxy MUST attempt to deliver the message to the first tuple in that set, and proceed through the set in order until the delivery attempt succeeds 🏃♀️
For each tuple attempted, the proxy MUST format the message as appropriate for the tuple and send the request using a new client transaction, as detailed in steps 8 through 10 💫
Since each attempt uses a new client transaction, it represents a new branch. Thus, the branch parameter provided with the Via header field inserted in step 8 MUST be different for each attempt 🌿
If the client transaction reports failure to send the request or a timeout from its state machine, the proxy continues to the next address in that ordered set. If the ordered set is exhausted, the request cannot be forwarded to this element in the target set. The proxy does not need to place anything in the response context, but otherwise acts as if this element of the target set returned a 408 (Request Timeout) final response 😭
8. Add a Via header field value 🌈
The proxy MUST insert a Via header field value into the copy before the existing Via header field values. The construction of this value follows the same guidelines as Section 8.1.1.7. This implies that the proxy will compute its own branch parameter, which will be globally unique for that branch and contain the requisite magic cookie ✨ Note that this implies the branch parameter will be different for different instances of a spiraled or looped request through a proxy 🌀
Proxies choosing to detect loops have an additional constraint on the value they use to construct the branch parameter. A proxy choosing to detect loops SHOULD create a branch parameter separable into two parts by the implementation. The first part MUST satisfy the constraints of Section 8.1.1.7 as described above. The second is used to perform loop detection and to distinguish loops from spirals 🕵️♀️
Loop detection is performed by verifying that, when a request returns to a proxy, those fields having an impact on the processing of the request have not changed. The value placed in this part of the branch parameter SHOULD reflect all of those fields (including any Route, Proxy-Require, and Proxy-Authorization header fields). This is to ensure that if the request is routed back to the proxy and one of those fields changes, it is treated as a spiral and not a loop (see Section 16.3) 🔁 A common way to create this value is to compute a cryptographic hash of the To tag, From tag, Call-ID header field, the Request-URI of the request received (before translation), the topmost Via header, and the sequence number from the CSeq header field, in addition to any Proxy-Require and Proxy-Authorization header fields that may be present. The algorithm used to compute the hash is implementation-dependent, but MD5 (RFC 1321 [35]), expressed in hexadecimal, is a reasonable choice. (Base64 is not permissible for a token.) 🙅♀️
If a proxy wishes to detect loops, the "branch" parameter it supplies MUST depend on all information affecting processing of a request, including the incoming Request-URI and any header fields affecting the request's admission or routing. This is necessary to distinguish looped requests from requests whose routing parameters have changed before returning to this server 💖
The request method MUST NOT be included in the calculation of the branch parameter. In particular, CANCEL and ACK requests (for non-2xx responses) MUST have the same branch value as the corresponding request they cancel or acknowledge. The branch parameter is used in correlating those requests at the server handling them (see Sections 17.2.3 and 9.2) 🫶
9. Add a Content-Length header field if necessary 📏
If the request will be sent to the next hop using a stream-based transport and the copy contains no Content-Length header field, the proxy MUST insert one with the correct value for the body of the request (see Section 20.14) 💅
10. Forward Request 🚀
A stateful proxy MUST create a new client transaction for this request, as described in Section 17.1, and instruct the transaction to send the request using the address, port, and transport determined in step 7 🫡
11. Set timer C ⏰
In order to handle the case where an INVITE request never generates a final response, the TU uses a timer called timer C. Timer C MUST be set for each client transaction when an INVITE request is proxied. The timer MUST be larger than 3 minutes. Section 16.7 bullet 2 discusses how this timer is updated with provisional responses, and Section 16.8 discusses processing when it fires ⏳✨
16.7 Response Processing 🎀
When a response lands on an element, it first hunts for a matching client transaction (Section 17.1.3) 🔍. If there isn't one, the element MUST process the response (even if it's informational!) as a stateless proxy, which we'll get to in a sec. If there is a match, the response gets handed straight to that client transaction 💌.
Forwarding responses that have no client transaction (or any sign you ever sent the related request) is lowkey a robustness power move 💪. It's especially what makes sure "late" 2xx responses to INVITE requests get forwarded properly ✨.
As client transactions pass responses up to the proxy layer, the following processing MUST take place:
- Find the appropriate response context
- Update timer C for provisional responses
- Remove the topmost Via
- Add the response to the response context
- Check to see if this response should be forwarded immediately
- When necessary, choose the best final response from the response context
If no final response has been forwarded after every client transaction associated with the response context has been terminated, the proxy must choose and forward the "best" response from those it has seen so far 🎀.
The following processing MUST be performed on each response that is forwarded. It's likely that more than one response to each request will get forwarded: at least each provisional and one final response 🌈.
- Aggregate authorization header field values if necessary
- Optionally rewrite Record-Route header field values
- Forward the response
- Generate any necessary CANCEL requests
Okay, each of the above steps gets a deeper dive below 🫶.
1. Find Context 🗝️
The proxy locates the "response context" it created before forwarding the original request, using the key described in Section 16.6. All the remaining processing steps happen inside this context.
2. Update timer C for provisional responses ⏰
For an INVITE transaction, if the response is a provisional response with status codes 101 to 199 inclusive (i.e., anything but 100), the proxy MUST reset timer C for that client transaction. The timer MAY be reset to a different value, but that value MUST be greater than 3 minutes.
3. Via 🧭
The proxy removes the topmost Via header field value from the response.
If no Via header field values remain in the response, the response was meant for this element, so it MUST NOT be forwarded. The rest of the processing in this section doesn't happen for that message. Instead, the UAC processing rules in Section 8.1.3 get followed (transport layer processing has already happened, bestie) 🙈.
This happens, for instance, when the element generates CANCEL requests as described in Section 10.
4. Add response to context 📦
Final responses that come in get stored in the response context until a final response is generated on the server transaction tied to this context. Any of them could be a candidate for the best final response to return on that server transaction. Info from a response might be needed to form the best response even if that particular response doesn't get picked 🧠.
If the proxy chooses to recurse on any contacts in a 3xx response by adding them to the target set, it MUST remove them from the response before adding the response to the response context. That said, a proxy SHOULD NOT recurse to a non-SIPS URI if the Request-URI of the original request was a SIPS URI. And if the proxy recurses on all of the contacts in a 3xx response, it SHOULD NOT add the resulting contactless response to the response context.
Removing the contact before adding the response to the context stops the next element upstream from retrying a location this proxy already tried 🙅♀️.
3xx responses can contain a mix of SIP, SIPS, and non-SIP URIs 🍓. A proxy may choose to recurse on the SIP and SIPS URIs and put the rest into the response context to be returned, possibly in the final response.
Now, the 416 (Unsupported URI Scheme) plot twist 😭. If a proxy gets a 416 for a request whose Request-URI scheme wasn't SIP, but the scheme in the original received request was SIP or SIPS (meaning the proxy switched the scheme from SIP or SIPS to something else when it proxied), the proxy SHOULD add a new URI to the target set. That URI SHOULD be a SIP URI version of the non-SIP URI that was just tried. For the tel URL, that means putting the telephone-subscriber part of the tel URL into the user part of the SIP URI, and setting the hostpart to the domain where the prior request was sent. See Section 19.1.6 for more detail on forming SIP URIs from tel URLs 📱.
Just like with a 3xx, if a proxy "recurses" on the 416 by trying a SIP or SIPS URI instead, the 416 response SHOULD NOT be added to the response context.
5. Check response for forwarding 🚀
Until a final response has been sent on the server transaction, the following responses MUST be forwarded immediately:
- Any provisional response other than 100 (Trying)
- Any 2xx response
If a 6xx response is received, it doesn't get forwarded immediately. Instead, the stateful proxy SHOULD cancel all client pending transactions as described in Section 10, and it MUST NOT create any new branches in this context 🛑.
This is a change from RFC 2543, which mandated that the proxy was to forward the 6xx response immediately. For an INVITE transaction, that approach had a problem: a 2xx response could arrive on another branch, in which case the proxy would have to forward the 2xx. The result was that the UAC could receive a 6xx response followed by a 2xx response, which should never be allowed to happen 💀. Under the new rules, when a proxy receives a 6xx, it issues a CANCEL request, which will generally result in 487 responses from all outstanding client transactions. Then, at that point, the 6xx is forwarded upstream ✨.
After a final response has been sent on the server transaction, the following responses MUST be forwarded immediately:
- Any 2xx response to an INVITE request
A stateful proxy MUST NOT immediately forward any other responses. In particular, a stateful proxy MUST NOT forward any 100 (Trying) response. The responses that are candidates for forwarding later as the "best" response were already gathered in the step "Add Response to Context" 🗂️.
Any response chosen for immediate forwarding MUST be processed as described in the steps "Aggregate Authorization Header Field Values" through "Record-Route" 📋.
This step, combined with the next one, makes sure a stateful proxy forwards exactly one final response to a non-INVITE request, and either exactly one non-2xx response or one or more 2xx responses to an INVITE request 👑.
6. Choosing the best response 🏆
A stateful proxy MUST send a final response to a response context's server transaction if no final responses have been immediately forwarded by the above rules and all client transactions in this response context have been terminated.
The stateful proxy MUST choose the "best" final response among those received and stored in the response context.
If there are no final responses in the context, the proxy MUST send a 408 (Request Timeout) response to the server transaction.
Otherwise, the proxy MUST forward a response from the responses stored in the response context. It MUST choose from the 6xx class responses if any exist in the context. If no 6xx class responses are present, the proxy SHOULD choose from the lowest response class stored in the response context. The proxy MAY select any response within that chosen class. The proxy SHOULD give preference to responses that provide information affecting resubmission of this request, such as 401, 407, 415, 420, and 484 if the 4xx class is chosen 🎯.
A proxy that receives a 503 (Service Unavailable) response SHOULD NOT forward it upstream unless it can determine that any subsequent requests it might proxy will also generate a 503. In other words, forwarding a 503 means the proxy knows it can't service any requests, not just the one for the Request-URI in the request that generated the 503 😱. If the only response received is a 503, the proxy SHOULD generate a 500 response and forward that upstream instead.
The forwarded response MUST be processed as described in the steps "Aggregate Authorization Header Field Values" through "Record-Route".
Here's an example: if a proxy forwarded a request to 4 locations and got 503, 407, 501, and 404 responses, it may choose to forward the 407 (Proxy Authentication Required) response 🔐.
1xx and 2xx responses can be involved in establishing dialogs 💬. When a request doesn't contain a To tag, the To tag in the response is what the UAC uses to tell apart multiple responses to a dialog-creating request. A proxy MUST NOT insert a tag into the To header field of a 1xx or 2xx response if the request didn't contain one. A proxy MUST NOT modify the tag in the To header field of a 1xx or 2xx response either 🚫.
Since a proxy may not insert a tag into the To header field of a 1xx response to a request that didn't contain one, it can't issue non-100 provisional responses on its own. BUT it can branch the request to a UAS sharing the same element as the proxy. That UAS can return its own provisional responses, entering into an early dialog with the initiator of the request. The UAS doesn't have to be a discrete process from the proxy, either. It could be a virtual UAS implemented in the same code space as the proxy 🧚.
3-6xx responses are delivered hop-by-hop 🪜. When issuing a 3-6xx response, the element is effectively acting as a UAS, issuing its own response, usually based on the responses received from downstream elements. An element SHOULD preserve the To tag when it's simply forwarding a 3-6xx response to a request that didn't contain a To tag.
A proxy MUST NOT modify the To tag in any forwarded response to a request that contains a To tag 💜.
It makes no difference to the upstream elements whether the proxy replaced the To tag in a forwarded 3-6xx response. Still, preserving the original tag may help with debugging 🔍✨.
When the proxy is aggregating information from several responses, choosing a To tag from among them is arbitrary, and generating a new To tag may make debugging easier 🧩. This happens, for instance, when combining 401 (Unauthorized) and 407 (Proxy Authentication Required) challenges, or combining Contact values from unencrypted and unauthenticated 3xx responses.
7. Aggregate Authorization Header Field Values 🔐
If the selected response is a 401 (Unauthorized) or 407 (Proxy Authentication Required), the proxy MUST collect any WWW-Authenticate and Proxy-Authenticate header field values from all other 401 (Unauthorized) and 407 (Proxy Authentication Required) responses received so far in this response context and add them to this response without modification before forwarding. The resulting 401 (Unauthorized) or 407 (Proxy Authentication Required) response could have several WWW-Authenticate AND Proxy-Authenticate header field values 💅.
This is necessary because any or all of the destinations the request was forwarded to may have requested credentials. The client needs to receive all of those challenges and supply credentials for each of them when it retries the request 🫶. Motivation for this behavior is provided in Section 26.
8. Record-Route 🛣️
If the selected response contains a Record-Route header field value originally provided by this proxy, the proxy MAY choose to rewrite the value before forwarding the response. This allows the proxy to provide different URIs for itself to the next upstream and downstream elements. A proxy may choose to use this mechanism for any reason. For instance, it is useful for multi-homed hosts 🌈.
If the proxy received the request over TLS, and sent it out over a non-TLS connection, the proxy MUST rewrite the URI in the Record-Route header field to be a SIPS URI. If the proxy received the request over a non-TLS connection, and sent it out over TLS, the proxy MUST rewrite the URI in the Record-Route header field to be a SIP URI 🔒.
The new URI provided by the proxy MUST satisfy the same constraints on URIs placed in Record-Route header fields in requests (see Step 4 of Section 16.6) with the following modifications:
The URI SHOULD NOT contain the transport parameter unless the proxy has knowledge that the next upstream (as opposed to downstream) element that will be in the path of subsequent requests supports that transport 🚦.
When a proxy does decide to modify the Record-Route header field in the response, one of the operations it performs is locating the Record-Route value that it had inserted. If the request spiraled, and the proxy inserted a Record-Route value in each iteration of the spiral, locating the correct value in the response (which must be the proper iteration in the reverse direction) is tricky 🌀. The rules above recommend that a proxy wishing to rewrite Record-Route header field values insert sufficiently distinct URIs into the Record-Route header field so that the right one may be selected for rewriting. A RECOMMENDED mechanism to achieve this is for the proxy to append a unique identifier for the proxy instance to the user portion of the URI 🪪.
When the response arrives, the proxy modifies the first Record-Route whose identifier matches the proxy instance. The modification results in a URI without this piece of data appended to the user portion of the URI. Upon the next iteration, the same algorithm (find the topmost Record-Route header field value with the parameter) will correctly extract the next Record-Route header field value inserted by that proxy ✨.
Not every response to a request to which a proxy adds a Record-Route header field value will contain a Record-Route header field. If the response does contain a Record-Route header field, it will contain the value the proxy added.
9. Forward response 📮
After performing the processing described in steps "Aggregate Authorization Header Field Values" through "Record-Route", the proxy MAY perform any feature specific manipulations on the selected response. The proxy MUST NOT add to, modify, or remove the message body. Unless otherwise specified, the proxy MUST NOT remove any header field values other than the Via header field value discussed in Section 16.7 Item 3. In particular, the proxy MUST NOT remove any "received" parameter it may have added to the next Via header field value while processing the request associated with this response. The proxy MUST pass the response to the server transaction associated with the response context. This will result in the response being sent to the location now indicated in the topmost Via header field value. If the server transaction is no longer available to handle the transmission, the element MUST forward the response statelessly by sending it to the server transport. The server transaction might indicate failure to send the response or signal a timeout in its state machine. These errors would be logged for diagnostic purposes as appropriate, but the protocol requires no remedial action from the proxy 🏁.
The proxy MUST maintain the response context until all of its associated transactions have been terminated, even after forwarding a final response 🧠.
10. Generate CANCELs 🛑
If the forwarded response was a final response, the proxy MUST generate a CANCEL request for all pending client transactions associated with this response context. A proxy SHOULD also generate a CANCEL request for all pending client transactions associated with this response context when it receives a 6xx response. A pending client transaction is one that has received a provisional response, but no final response (it is in the proceeding state) and has not had an associated CANCEL generated for it. Generating CANCEL requests is described in Section 9.1 💫.
The requirement to CANCEL pending client transactions upon forwarding a final response does not guarantee that an endpoint will not receive multiple 200 (OK) responses to an INVITE. 200 (OK) responses on more than one branch may be generated before the CANCEL requests can be sent and processed. Further, it is reasonable to expect that a future extension may override this requirement to issue CANCEL requests 👀.
16.8. Processing Timer C ⏰
If timer C should fire, the proxy MUST either reset the timer with any value it chooses, or terminate the client transaction. If the client transaction has received a provisional response, the proxy MUST generate a CANCEL request matching that transaction. If the client transaction has not received a provisional response, the proxy MUST behave as if the transaction received a 408 (Request Timeout) response 🕰️.
Allowing the proxy to reset the timer allows the proxy to dynamically extend the transaction's lifetime based on current conditions (such as utilization) when the timer fires 🧁.
16.9. Handling Transport Errors 🚧
If the transport layer notifies a proxy of an error when it tries to forward a request (see Section 18.4), the proxy MUST behave as if the forwarded request received a 503 (Service Unavailable) response 🙈.
If the proxy is notified of an error when forwarding a response, it drops the response. The proxy SHOULD NOT cancel any outstanding client transactions associated with this response context due to this notification.
If a proxy cancels its outstanding client transactions, a single malicious or misbehaving client can cause all transactions to fail through its Via header field 🚨.
16.10. CANCEL Processing 🎀
A stateful proxy MAY generate a CANCEL to any other request it has generated at any time (subject to receiving a provisional response to that request as described in section 9.1). A proxy MUST cancel any pending client transactions associated with a response context when it receives a matching CANCEL request 🫧.
A stateful proxy MAY generate CANCEL requests for pending INVITE client transactions based on the period specified in the INVITE's Expires header field elapsing. However, this is generally unnecessary since the endpoints involved will take care of signaling the end of the transaction 🌸.
While a CANCEL request is handled in a stateful proxy by its own server transaction, a new response context is not created for it. Instead, the proxy layer searches its existing response contexts for the server transaction handling the request associated with this CANCEL. If a matching response context is found, the element MUST immediately return a 200 (OK) response to the CANCEL request. In this case, the element is acting as a user agent server as defined in Section 8.2. Furthermore, the element MUST generate CANCEL requests for all pending client transactions in the context as described in Section 16.7 step 10 🦋.
If a response context is not found, the element does not have any knowledge of the request to apply the CANCEL to. It MUST statelessly forward the CANCEL request (it may have statelessly forwarded the associated request previously) 🧚.
16.11 Stateless Proxy ✨
okay so when a proxy is acting statelessly, it's basically just a simple message forwarder 📬 A lot of what it does is the same as when it's stateful, so this section just spells out the differences 💅
a stateless proxy doesn't have any notion of a transaction, or of the response context we used to describe stateful behavior 🙈 Instead, it grabs messages, both requests and responses, straight from the transport layer (see Section 18). That means stateless proxies do not retransmit messages on their own. They do forward every retransmission they get, though, since they literally can't tell a retransmission from the original message 🫶 Also, when handling a request statelessly, an element MUST NOT generate its own 100 (Trying) or any other provisional response. no extra 100 Trying energy here 💀
A stateless proxy MUST validate a request as described in Section 16.3 ✅
A stateless proxy MUST follow the request processing steps described in Sections 16.4 through 16.5 with the following exception:
- A stateless proxy MUST choose one and only one target from the target set. This choice MUST only rely on fields in the message and time-invariant properties of the server. In particular, a retransmitted request MUST be forwarded to the same destination each time it is processed. Furthermore, CANCEL and non-Routed ACK requests MUST generate the same choice as their associated INVITE. the consistency is giving 🎀
A stateless proxy MUST follow the request processing steps described in Section 16.6 with the following exceptions:
- The requirement for unique branch IDs across space and time applies to stateless proxies as well. However, a stateless proxy cannot simply use a random number generator to compute the first component of the branch ID, as described in Section 16.6 bullet 8. This is because retransmissions of a request need to have the same value, and a stateless proxy cannot tell a retransmission from the original request. Therefore, the component of the branch parameter that makes it unique MUST be the same each time a retransmitted request is forwarded. Thus for a stateless proxy, the branch parameter MUST be computed as a combinatoric function of message parameters which are invariant on retransmission. so no random numbers, bestie 🎲🚫
The stateless proxy MAY use any technique it likes to guarantee uniqueness of its branch IDs across transactions. However, the following procedure is RECOMMENDED. The proxy examines the branch ID in the topmost Via header field of the received request. If it begins with the magic cookie, the first component of the branch ID of the outgoing request is computed as a hash of the received branch ID. Otherwise, the first component of the branch ID is computed as a hash of the topmost Via, the tag in the To header field, the tag in the From header field, the Call-ID header field, the CSeq number (but not method), and the Request-URI from the received request. One of these fields will always vary across two different transactions. ✨ the hashing plan is lowkey genius
- All other message transformations specified in Section 16.6 MUST result in the same transformation of a retransmitted request. In particular, if the proxy inserts a Record-Route value or pushes URIs into the Route header field, it MUST place the same values in retransmissions of the request. As for the Via branch parameter, this implies that the transformations MUST be based on time-invariant configuration or retransmission-invariant properties of the request. 🔁 same input, same output, every time
- A stateless proxy determines where to forward the request as described for stateful proxies in Section 16.6 Item 10. The request is sent directly to the transport layer instead of through a client transaction.
Since a stateless proxy must forward retransmitted requests to the same destination and add identical branch parameters to each of them, it can only use information from the message itself and time-invariant configuration data for those calculations. If the configuration state is not time-invariant (for example, if a routing table is updated) any requests that could be affected by the change may not be forwarded statelessly during an interval equal to the transaction timeout window before or after the change. The method of processing the affected requests in that interval is an implementation decision. A common solution is to forward them transaction statefully. 🗺️ if the routing table changes, things get a little messy, so you might switch to stateful for a bit
Stateless proxies MUST NOT perform special processing for CANCEL requests. They are processed by the above rules as any other requests. In particular, a stateless proxy applies the same Route header field processing to CANCEL requests that it applies to any other request. no VIP treatment for CANCEL 🙅♀️
Response processing as described in Section 16.7 does not apply to a proxy behaving statelessly. When a response arrives at a stateless proxy, the proxy MUST inspect the sent-by value in the first (topmost) Via header field value. If that address matches the proxy, (it equals a value this proxy has inserted into previous requests) the proxy MUST remove that header field value from the response and forward the result to the location indicated in the next Via header field value. The proxy MUST NOT add to, modify, or remove the message body. Unless specified otherwise, the proxy MUST NOT remove any other header field values. If the address does not match the proxy, the message MUST be silently discarded. 🫥 ghosted, no notification, periodt 💜
16.12 Summary of Proxy Route Processing 🗺️
in the absence of local policy to the contrary, here's the whole route-processing vibe for a request that has a Route header field, in three easy steps 🌈
- The proxy will inspect the Request-URI. If it indicates a resource owned by this proxy, the proxy will replace it with the results of running a location service. Otherwise, the proxy will not change the Request-URI.
- The proxy will inspect the URI in the topmost Route header field value. If it indicates this proxy, the proxy removes it from the Route header field (this route node has been reached).
- The proxy will forward the request to the resource indicated by the URI in the topmost Route header field value or in the Request-URI if no Route header field is present. The proxy determines the address, port and transport to use when forwarding the request by applying the procedures in [4] to that URI.
If no strict-routing elements are encountered on the path of the request, the Request-URI will always indicate the target of the request. 🎯 the Request-URI is the real main character here
16.12.1 Examples 🎬
16.12.1.1 Basic SIP Trapezoid 🦋
this scenario is the basic SIP trapezoid, U1 -> P1 -> P2 -> U2, with both proxies record-routing. here's the flow, bestie 💖
U1 sends:
INVITE sip:callee@domain.com SIP/2.0
Contact: sip:caller@u1.example.comto P1. P1 is an outbound proxy. P1 is not responsible for domain.com, so it looks it up in DNS and sends it there. It also adds a Record-Route header field value:
INVITE sip:callee@domain.com SIP/2.0
Contact: sip:caller@u1.example.com
Record-Route: <sip:p1.example.com;lr>P2 gets this. It is responsible for domain.com so it runs a location service and rewrites the Request-URI. It also adds a Record-Route header field value. There is no Route header field, so it resolves the new Request-URI to determine where to send the request:
INVITE sip:callee@u2.domain.com SIP/2.0
Contact: sip:caller@u1.example.com
Record-Route: <sip:p2.domain.com;lr>
Record-Route: <sip:p1.example.com;lr>The callee at u2.domain.com gets this and responds with a 200 OK:
SIP/2.0 200 OK
Contact: sip:callee@u2.domain.com
Record-Route: <sip:p2.domain.com;lr>
Record-Route: <sip:p1.example.com;lr>The callee at u2 also sets its dialog state's remote target URI to sip:caller@u1.example.com and its route set to:
(<sip:p2.domain.com;lr>,<sip:p1.example.com;lr>)This is forwarded by P2 to P1 to U1 as normal. Now, U1 sets its dialog state's remote target URI to sip:callee@u2.domain.com and its route set to:
(<sip:p1.example.com;lr>,<sip:p2.domain.com;lr>)Since all the route set elements contain the lr parameter, U1 constructs the following BYE request:
BYE sip:callee@u2.domain.com SIP/2.0
Route: <sip:p1.example.com;lr>,<sip:p2.domain.com;lr>As any other element (including proxies) would do, it resolves the URI in the topmost Route header field value using DNS to determine where to send the request. This goes to P1. P1 notices that it is not responsible for the resource indicated in the Request-URI so it doesn't change it. It does see that it is the first value in the Route header field, so it removes that value, and forwards the request to P2:
BYE sip:callee@u2.domain.com SIP/2.0
Route: <sip:p2.domain.com;lr>P2 also notices it is not responsible for the resource indicated by the Request-URI (it is responsible for domain.com, not u2.domain.com), so it doesn't change it. It does see itself in the first Route header field value, so it removes it and forwards the following to u2.domain.com based on a DNS lookup against the Request-URI:
BYE sip:callee@u2.domain.com SIP/2.0and that's the whole trapezoid, the route set does all the heavy lifting 🧚💜
16.12.1.2 Traversing a Strict-Routing Proxy
okay so this one is giving strict-routing drama 🎭 A dialog gets set up across four proxies, and each one adds its own Record-Route header field values. The third proxy is the strict router, following the procedures from RFC 2543 and a bunch of works in progress 🧚
U1->P1->P2->P3->P4->U2The INVITE that lands at U2 looks like this:
INVITE sip:callee@u2.domain.com SIP/2.0
Contact: sip:caller@u1.example.com
Record-Route: <sip:p4.domain.com;lr>
Record-Route: <sip:p3.middle.com>
Record-Route: <sip:p2.example.com;lr>
Record-Route: <sip:p1.example.com;lr>U2 replies with a 200 OK 💌 Later, U2 sends the following BYE request to P4 based on the first Route header field value.
BYE sip:caller@u1.example.com SIP/2.0
Route: <sip:p4.domain.com;lr>
Route: <sip:p3.middle.com>
Route: <sip:p2.example.com;lr>
Route: <sip:p1.example.com;lr>P4 is not responsible for the resource in the Request-URI, so it leaves it alone 🙅 It notices it's the element in the first Route header field value, so it removes itself. Then it's about to send based on the now-first Route value of sip:p3.middle.com, but it sees that this URI doesn't have the lr parameter. So before sending, it reformats the request to be:
BYE sip:p3.middle.com SIP/2.0
Route: <sip:p2.example.com;lr>
Route: <sip:p1.example.com;lr>
Route: <sip:caller@u1.example.com>P3 is a strict router, so it forwards the following to P2:
BYE sip:p2.example.com;lr SIP/2.0
Route: <sip:p1.example.com;lr>
Route: <sip:caller@u1.example.com>P2 sees that the Request-URI is a value it put into a Record-Route header field, so before doing any further processing, it rewrites the request to be:
BYE sip:caller@u1.example.com SIP/2.0
Route: <sip:p1.example.com;lr>P2 is not responsible for u1.example.com, so it sends the request to P1 based on the resolution of the Route header field value. 🚀
P1 notices itself in the topmost Route header field value, so it removes it, resulting in:
BYE sip:caller@u1.example.com SIP/2.0Since P1 is not responsible for u1.example.com and there is no Route header field, P1 forwards the request to u1.example.com based on the Request-URI. ✨ the whole chain gets sorted out!
16.12.1.3 Rewriting Record-Route Header Field Values
this scenario is all about two private namespaces 🌸 U1 and U2 live in different ones, and they enter a dialog through a proxy P1, which acts as a gateway between the namespaces. It's basically a bridge with a very good location service 🌉
U1->P1->U2U1 sends:
INVITE sip:callee@gateway.leftprivatespace.com SIP/2.0
Contact: <sip:caller@u1.leftprivatespace.com>P1 uses its location service and sends the following to U2:
INVITE sip:callee@rightprivatespace.com SIP/2.0
Contact: <sip:caller@u1.leftprivatespace.com>
Record-Route: <sip:gateway.rightprivatespace.com;lr>U2 sends this 200 (OK) back to P1:
SIP/2.0 200 OK
Contact: <sip:callee@u2.rightprivatespace.com>
Record-Route: <sip:gateway.rightprivatespace.com;lr>P1 rewrites its Record-Route header parameter to give a value that U1 will find useful, then sends the following to U1:
SIP/2.0 200 OK
Contact: <sip:callee@u2.rightprivatespace.com>
Record-Route: <sip:gateway.leftprivatespace.com;lr>Later, U1 sends the following BYE request to P1:
BYE sip:callee@u2.rightprivatespace.com SIP/2.0
Route: <sip:gateway.leftprivatespace.com;lr>which P1 forwards to U2 as:
BYE sip:callee@u2.rightprivatespace.com SIP/2.017 Transactions
okay transactions are the heart of SIP 💖 SIP is a transactional protocol, which means that interactions between components happen as a series of independent message exchanges. A SIP transaction is one request plus any responses to that request: zero or more provisional responses and one or more final responses. For an INVITE transaction, the ACK is also part of it, but only if the final response wasn't a 2xx. If the response was a 2xx, the ACK is not considered part of the transaction. 🎀
The reason for this split is kinda iconic 👑 It's all about making sure every single 200 (OK) to an INVITE reaches the UAC. The UAS alone takes responsibility for retransmitting those (see Section 13.3.1.4), and the UAC alone takes responsibility for acknowledging them with ACK (see Section 13.2.2.4). Since only the UAC retransmits this ACK, it's effectively its own transaction. 🫶
Transactions have a client side and a server side. The client side is the client transaction and the server side is the server transaction. The client transaction sends the request, and the server transaction sends the response. These are logical functions that get embedded in any number of elements. Specifically, they live inside user agents and stateful proxy servers. Think about the example in Section 4: the UAC runs the client transaction, and its outbound proxy runs the server transaction. That outbound proxy also runs a client transaction, which sends the request to a server transaction in the inbound proxy. The inbound proxy runs a client transaction too, which sends the request to a server transaction in the UAS. Here's how that looks in Figure 4 🧩
+---------+ +---------+ +---------+ +---------+
| +-+|Request |+-+ +-+|Request |+-+ +-+|Request |+-+ |
| |C||------->||S| |C||------->||S| |C||------->||S| |
| |l|| ||e| |l|| ||e| |l|| ||e| |
| |i|| ||r| |i|| ||r| |i|| ||r| |
| |e|| ||v| |e|| ||v| |e|| ||v| |
| |n|| ||e| |n|| ||e| |n|| ||e| |
| |t|| ||r| |t|| ||r| |t|| ||r| |
| | || || | | || || | | || || | |
| |T|| ||T| |T|| ||T| |T|| ||T| |
| |r|| ||r| |r|| ||r| |r|| ||r| |
| |a|| ||a| |a|| ||a| |a|| ||a| |
| |n|| ||n| |n|| ||n| |n|| ||n| |
| |s||Response||s| |s||Response||s| |s||Response||s| |
| +-+|<-------|+-+ +-+|<-------|+-+ +-+|<-------|+-+ |
+---------+ +---------+ +---------+ +---------+
UAC Outbound Inbound UAS
Proxy Proxy
Figure 4: Transaction relationshipsA stateless proxy doesn't have a client or server transaction at all 🙈 The transaction exists between the UA or stateful proxy on one side and the UA or stateful proxy on the other side. As far as SIP transactions are concerned, stateless proxies are basically invisible ✨ The client transaction's job is to receive a request from the element it's embedded in (call that element the "Transaction User" or TU; it can be a UA or a stateful proxy) and reliably deliver the request to a server transaction 📮
The client transaction also receives responses and passes them up to the TU, filtering out any response retransmissions or disallowed responses (like a response to ACK). Plus, for an INVITE request, the client transaction is responsible for generating the ACK request for any final response that's a 2xx. 💅
The server transaction is the mirror image 🪞 It receives requests from the transport layer and delivers them to the TU, filtering out any request retransmissions from the network. It takes responses from the TU and hands them to the transport layer for sending over the network. For an INVITE transaction, it absorbs the ACK request for any final response except a 2xx.
The 2xx response and its ACK get special treatment 🌈 This response is retransmitted only by a UAS, and its ACK is generated only by the UAC. This end-to-end setup is needed so that a caller knows the entire set of users that have accepted the call. Because of this, retransmissions of the 2xx response are handled by the UA core, not the transaction layer. Generating the ACK for the 2xx is also handled by the UA core. Each proxy along the path just forwards each 2xx response to INVITE and its corresponding ACK. 🦋
17.1 Client Transaction
the client transaction does its job through a state machine 🧠
The TU talks to the client transaction through a simple interface. When the TU wants to start a new transaction, it creates a client transaction and passes it the SIP request to send, plus an IP address, port, and transport to send it to. The client transaction starts running its state machine. Valid responses get passed up to the TU from the client transaction. 💌
There are two types of client transaction state machines, depending on the method of the request the TU passes in. One handles INVITE requests, and it's called an INVITE client transaction. The other handles every method except INVITE and ACK, and it's called a non-INVITE client transaction. There's no client transaction for ACK. If the TU wants to send an ACK, it passes one straight to the transport layer for transmission. 🚚
INVITE is different from the other methods because of its extended duration. Normally, a human has to be involved to respond to an INVITE, and those long delays are a reason for a three-way handshake. Requests with other methods are expected to complete quickly. Because the non-INVITE transaction relies on a two-way handshake, TUs SHOULD respond immediately to non-INVITE requests. ⚡
17.1.1 INVITE Client Transaction
17.1.1.1 Overview of INVITE Transaction
the INVITE transaction is a three-way handshake 🤝 The client transaction sends an INVITE, the server transaction sends responses, and the client transaction sends an ACK. On unreliable transports (like UDP), the client transaction retransmits requests at an interval that starts at T1 seconds and doubles after every retransmission. T1 is an estimate of the round-trip time (RTT), and it defaults to 500 ms. Nearly all of the transaction timers scale with T1, so changing T1 adjusts their values. ⏱️ The request is not retransmitted over reliable transports. After receiving a 1xx response, any retransmissions stop altogether, and the client just waits for further responses. The server transaction can send additional 1xx responses, which it doesn't transmit reliably. Eventually, the server transaction decides to send a final response. On unreliable transports, that response is retransmitted periodically, and on reliable transports, it's sent once. For each final response the client transaction receives, it sends an ACK, whose purpose is to quench retransmissions of the response. 🫧
17.1.1.2 Formal Description
okay so the INVITE client transaction state machine is in Figure 5 🦋 the starting state is "calling" and it MUST be entered the moment the TU kicks off a brand new client transaction with an INVITE request ✨ the client transaction MUST pass that request to the transport layer for sending (see Section 18) 💅 if you're on an unreliable transport, the client transaction MUST start timer A with a value of T1 🔥 but if it's a reliable transport, the client transaction SHOULD NOT start timer A, since timer A is all about request retransmissions 🙈 and for any transport, the client transaction MUST start timer B with a value of 64*T1 seconds (timer B handles transaction timeouts) 💖
when timer A fires, the client transaction MUST retransmit the request by passing it to the transport layer, and it MUST reset the timer to 2*T1 🌸 "retransmit" here has a very specific meaning in the transaction layer: you take the message you sent to the transport layer before and pass it to the transport layer one more time, literally that's it 💅
when timer A fires again 2*T1 seconds later, the request MUST be retransmitted again (as long as the client transaction is still in this state) ⏰ this process MUST continue so the request goes out again and again with intervals that double after every single transmission 📈 these retransmissions SHOULD only happen while the client transaction is in the "calling" state 🎀
the default value for T1 is 500 ms ✨ T1 is basically an estimate of the RTT between the client and server transactions 🧚 elements MAY (though it is NOT RECOMMENDED) use smaller values of T1 inside closed, private networks that don't allow general Internet connection 🔒 T1 MAY be chosen larger, and this is RECOMMENDED if it's known ahead of time that the RTT will be bigger (like on high latency access links) 🐢 whatever the value of T1 is, the exponential backoffs on retransmissions described in this section MUST be used 💜
if the client transaction is still in the "Calling" state when timer B fires, the client transaction SHOULD inform the TU that a timeout has occurred 🙈 the client transaction MUST NOT generate an ACK, babe 🚫 and fun fact: 64*T1 is the same amount of time it takes to send seven requests over an unreliable transport 🤯
if the client transaction gets a provisional response while it's in the "Calling" state, it transitions to the "Proceeding" state 🦋 in the "Proceeding" state, the client transaction SHOULD NOT retransmit the request any longer 🛑 the provisional response MUST be passed to the TU too, and any further provisional responses MUST be passed up to the TU while in the "Proceeding" state 💖
when in either the "Calling" or "Proceeding" states, a response with a status code from 300-699 MUST cause the client transaction to transition to "Completed" 🔥 the client transaction MUST pass that response up to the TU, and it MUST generate an ACK request even if the transport is reliable (you can see how to build that ACK from the response in Section 17.1.1.3) ✨ then it passes the ACK to the transport layer for transmission 💅 the ACK MUST be sent to the same address, port, and transport that the original request went to 📬 the client transaction SHOULD start timer D when it enters the "Completed" state, with a value of at least 32 seconds for unreliable transports and zero seconds for reliable transports 🌸 Timer D is how long the server transaction can stick around in the "Completed" state when unreliable transports are used 🫶 that's equal to Timer H in the INVITE server transaction, whose default is 64*T1 💅 but the client transaction doesn't know what T1 the server is using, so it just uses an absolute minimum of 32s instead of basing Timer D on T1 🙃
any retransmissions of the final response that show up while in the "Completed" state MUST cause the ACK to be re-passed to the transport layer for retransmission 🔁 but the newly received response MUST NOT be passed up to the TU 🙅♀️ a retransmission of the response is just any response that would match the same client transaction under the rules of Section 17.1.3 💖
|INVITE from TU
Timer A fires |INVITE sent
Reset A, V Timer B fires
INVITE sent +-----------+ or Transport Err.
+---------| |---------------+inform TU
| | Calling | |
+-------->| |-------------->|
+-----------+ 2xx |
| | 2xx to TU |
| |1xx |
300-699 +---------------+ |1xx to TU |
ACK sent | | |
resp. to TU | 1xx V |
| 1xx to TU -----------+ |
| +---------| | |
| | |Proceeding |-------------->|
| +-------->| | 2xx |
| +-----------+ 2xx to TU |
| 300-699 | |
| ACK sent, | |
| resp. to TU| |
| | | NOTE:
| 300-699 V |
| ACK sent +-----------+Transport Err. | transitions
| +---------| |Inform TU | labeled with
| | | Completed |-------------->| the event
| +-------->| | | over the action
| +-----------+ | to take
| ^ | |
| | | Timer D fires |
+--------------+ | - |
| |
V |
+-----------+ |
| | |
| Terminated|<--------------+
| |
+-----------+
Figure 5: INVITE client transactionif timer D fires while the client transaction is in the "Completed" state, the client transaction MUST move to the terminated state 👋
when in either the "Calling" or "Proceeding" states, a 2xx response MUST cause the client transaction to enter the "Terminated" state, and the response MUST be passed up to the TU 🎉 what happens next depends on whether the TU is a proxy core or a UAC core 🧐 a UAC core will handle making the ACK for this response, while a proxy core will always forward the 200 (OK) upstream 🚀 that difference between proxy and UAC is exactly why this handling doesn't happen in the transaction layer 💅
the client transaction MUST be destroyed the instant it enters the "Terminated" state 💀 this is actually necessary for everything to work right 🙌 the reason is that 2xx responses to an INVITE get treated differently: each one gets forwarded by proxies, and the ACK handling in a UAC is different too 🫠 so each 2xx has to reach a proxy core (so it can be forwarded) and a UAC core (so it can be acknowledged) 🎀 no transaction layer processing happens here ✨ whenever the transport gets a response and finds no matching client transaction (using the rules of Section 17.1.3), the response goes straight to the core 🏃♀️ since the first 2xx destroys the matching client transaction, any later 2xx finds no match and gets passed to the core too 💖
17.1.1.3 Construction of the ACK Request
this section explains how to build the ACK requests sent inside the client transaction 🧩 a UAC core that generates an ACK for 2xx MUST instead follow the rules described in Section 13 🫶
the ACK request built by the client transaction MUST contain Call-ID, From, and Request-URI values that match those header fields in the request passed to the transport by the client transaction (let's call that the "original request") 🔑 the To header field in the ACK MUST equal the To header field in the response being acknowledged, so it'll usually be different from the original request's To by the addition of the tag parameter 🏷️ the ACK MUST contain a single Via header field, and that MUST be equal to the top Via header field of the original request 🛤️ the CSeq header field in the ACK MUST have the same sequence number as the original request, but its method parameter MUST be equal to "ACK" ✨
if the INVITE request whose response is being acknowledged had Route header fields, those header fields MUST appear in the ACK 🗺️ this makes sure the ACK can get routed properly through any downstream stateless proxies 🧚
okay so any request MAY contain a body, but a body in an ACK is kinda special because the request can't be rejected if the body isn't understood 😬 so placing bodies in an ACK for a non-2xx response is NOT RECOMMENDED 🙅♀️ but if you do it anyway, the body types are restricted to whatever showed up in the INVITE, assuming the response to the INVITE wasn't 415 📦 if it was a 415, the body in the ACK MAY be any type listed in the Accept header field in that 415 💅
here's an example request:
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKkjshdyff
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=88sja8x
Max-Forwards: 70
Call-ID: 987asjd97y7atg
CSeq: 986759 INVITEand the ACK for a non-2xx final response to this request would look like this 🥰:
ACK sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKkjshdyff
To: Bob <sip:bob@biloxi.com>;tag=99sa0xk
From: Alice <sip:alice@atlanta.com>;tag=88sja8x
Max-Forwards: 70
Call-ID: 987asjd97y7atg
CSeq: 986759 ACK17.1.2 Non-INVITE Client Transaction
17.1.2.1 Overview of the non-INVITE Transaction
non-INVITE transactions don't use ACK at all 🙅♀️ they're just simple request-response interactions, bestie 💖 for unreliable transports, requests get retransmitted at an interval that starts at T1 and doubles until it hits T2 📈 if a provisional response comes back, retransmissions keep going on unreliable transports, but now at an interval of T2 🐢 the server transaction only resends the last response it sent (which can be provisional or final) when it receives a retransmission of the request 🔁 that's why request retransmissions have to keep going even after a provisional response: it's all about making sure the final response gets there reliably 🫶
unlike an INVITE transaction, a non-INVITE transaction has no special handling for the 2xx response 🤷♀️ so only a single 2xx response to a non-INVITE ever gets delivered to a UAC 👑
17.1.2.2 Formal Description ✨
Okay bestie, here's the state machine for the non-INVITE client transaction, shown in Figure 6 💅. It's basically the INVITE one's cousin, so if you've got that down, you're already halfway there 🦋.
When the TU kicks off a new client transaction with a request, it lands in the "Trying" state 🌸. Once it's there, the client transaction SHOULD set timer F to fire in 64*T1 seconds. The request MUST be passed down to the transport layer so it gets sent. If the transport is unreliable, the client transaction MUST set timer E to fire in T1 seconds. If timer E goes off while it's still in Trying, the timer gets reset, but this time to MIN(2*T1, T2). Next time it fires, it resets to MIN(4*T1, T2). It keeps going like that, so retransmissions happen at an exponentially growing interval that tops out at T2 ⏱️. The default T2 is 4s, and it's the amount of time a non-INVITE server transaction takes to respond to a request if it doesn't respond right away. With the default T1 and T2, the intervals come out to 500 ms, 1 s, 2 s, 4 s, 4 s, 4 s, etc. 💖
If timer F fires while the transaction is still in Trying, the client transaction SHOULD tell the TU about the timeout, and then it SHOULD enter the "Terminated" state 😭. If a provisional response shows up while it's in Trying, the response MUST be passed to the TU, and then the client transaction SHOULD move to the "Proceeding" state ✨. If a final response (status codes 200-699) arrives while it's in Trying, the response MUST be passed to the TU, and the client transaction MUST transition to the "Completed" state 🎀.
If timer E fires while in Proceeding, the request MUST be passed to the transport layer for retransmission, and timer E MUST be reset with a value of T2 seconds. If timer F fires while in Proceeding, the TU MUST be informed of a timeout, and the client transaction MUST transition to the terminated state 💀. If a final response (200-699) comes in while in Proceeding, the response MUST be passed to the TU, and the client transaction MUST transition to the "Completed" state 🔥.
Once the client transaction enters Completed, it MUST set Timer K to fire in T4 seconds for unreliable transports, and zero seconds for reliable transports. Completed exists to buffer any extra response retransmissions that might sneak in, which is why the client transaction only hangs out there for unreliable transports 🧚. T4 is the amount of time the network takes to clear messages between the client and server transactions, and its default value is 5s. A response counts as a retransmission when it matches the same transaction, using the rules in Section 17.1.3 🫶. If Timer K fires while in this state, the client transaction MUST transition to the "Terminated" state.
Once the transaction is in the terminated state, it MUST be destroyed immediately 👑.
17.1.3 Matching Responses to Client Transactions 🦋
Okay so when the transport layer in the client gets a response, it has to figure out which client transaction is going to handle it, so that the processing in Sections 17.1.1 and 17.1.2 can happen. The branch parameter in the top Via header field is what does this job 🔍. A response matches a client transaction under two conditions:
- If the response has the same value of the
branchparameter in the topViaheader field as thebranchparameter in the topViaheader field of the request that created the transaction. - If the
methodparameter in theCSeqheader field matches the method of the request that created the transaction. The method is needed because aCANCELrequest counts as a different transaction, but it shares the samebranchvalue, so it's giving twins 👯♀️.
If a request gets sent via multicast, it's possible it'll generate multiple responses from different servers. These responses will all have the same branch parameter in the topmost Via, but they'll vary in the To tag. The first response received, based on the rules above, is the one that gets used, and the others are viewed as retransmissions. That's not an error, bestie 🌈. Multicast SIP only offers a rudimentary "single-hop-discovery-like" service that's limited to processing a single response. See Section 18.1.1 for details 💜.
17.1.4 Handling Transport Errors 🚨
Here's the non-INVITE client transaction state machine again, with the transitions labeled by the event over the action to take 📊.
|Request from TU
|send request
Timer E V
send request +-----------+
+---------| |-------------------+
| | Trying | Timer F |
+-------->| | or Transport Err.|
+-----------+ inform TU |
200-699 | | |
resp. to TU | |1xx |
+---------------+ |resp. to TU |
| | |
| Timer E V Timer F |
| send req +-----------+ or Transport Err. |
| +---------| | inform TU |
| | |Proceeding |------------------>|
| +-------->| |-----+ |
| +-----------+ |1xx |
| | ^ |resp to TU |
| 200-699 | +--------+ |
| resp. to TU | |
| | |
| V |
| +-----------+ |
| | | |
| | Completed | |
| | | |
| +-----------+ |
| ^ | |
| | | Timer K |
+--------------+ | - |
| |
V |
NOTE: +-----------+ |
| | |
transitions | Terminated|<------------------+
labeled with | |
the event +-----------+
over the action
to take
Figure 6: non-INVITE client transactionWhen the client transaction hands a request to the transport layer to be sent, the following procedures kick in if the transport layer reports a failure 🥺.
The client transaction SHOULD tell the TU that a transport failure has happened, and the client transaction SHOULD transition directly to the "Terminated" state 🙈. The TU will handle the failover mechanisms described in [4] 🫶.
17.2 Server Transaction 🌸
The server transaction is responsible for getting requests delivered to the TU and for making sure responses get sent reliably 🎀. It does all this through a state machine. Server transactions are created by the core when a request comes in and transaction handling is wanted for that request (this isn't always the case, bestie) 💅.
As with the client transactions, the state machine depends on whether the received request is an INVITE request ✨.
17.2.1 INVITE Server Transaction ✨
Okay bestie, here's the state diagram for the INVITE server transaction. It's Figure 7 🦋
When a server transaction gets built for a request, it lands in the "Proceeding" state 💅 The server transaction MUST generate a 100 (Trying) response unless it knows the TU will hand back a provisional or final response within 200 ms. If it does know that, it MAY generate a 100 (Trying) response instead. This provisional response is there to quench request retransmissions fast so the network doesn't get congested 🌸 The 100 (Trying) response gets built using the procedures in Section 8.2.6, with one twist: adding a tag to the To header field (when the request didn't already have one) gets downgraded from MAY to SHOULD NOT. Then the request MUST be passed to the TU 🎀
The TU can pass along any number of provisional responses to the server transaction. As long as we're in "Proceeding," each one MUST be passed down to the transport layer for transmission. The transaction layer doesn't send these reliably (it doesn't retransmit them), and they don't change the state of the server transaction. If a request retransmission shows up while we're in "Proceeding," the most recent provisional response from the TU MUST be passed to the transport layer for retransmission. A request counts as a retransmission if it matches the same server transaction under the rules in Section 17.2.3 🧚
If the TU passes a 2xx response while we're in "Proceeding," the server transaction MUST pass that response to the transport layer for transmission. It doesn't get retransmitted by the server transaction, because retransmitting 2xx responses is the TU's job 👑 After that, the server transaction MUST transition to the "Terminated" state.
While we're in "Proceeding," if the TU passes a response with a status code from 300 to 699, that response MUST be passed to the transport layer for transmission, and the state machine MUST enter the "Completed" state. For unreliable transports, timer G is set to fire in T1 seconds. For reliable transports, it is not set to fire at all 💀
This is a change from RFC 2543, where responses were always retransmitted, even over reliable transports.
When the "Completed" state is entered, timer H MUST be set to fire in 64*T1 seconds for all transports. Timer H decides when the server transaction gives up on retransmitting the response. Its value is picked to equal Timer B, which is how long a client transaction will keep retrying a request ⏳ When timer G fires, the response goes to the transport layer once more for retransmission, and timer G is set to fire in MIN(2*T1, T2) seconds. From then on, each time timer G fires, the response gets passed to the transport again for transmission, and timer G gets reset to a value that doubles, unless that value would go over T2. In that case it gets reset to the value of T2. This is identical to the retransmit behavior for requests in the "Trying" state of the non-INVITE client transaction 🔁 Also, while we're in "Completed," if a request retransmission comes in, the server SHOULD pass the response to the transport for retransmission.
If an ACK arrives while the server transaction is in "Completed," the server transaction MUST transition to the "Confirmed" state. Timer G gets ignored in this state, so any retransmissions of the response finally stop 🫶
If timer H fires while we're in "Completed," that means the ACK never arrived. In this case the server transaction MUST transition to the "Terminated" state, and MUST indicate to the TU that a transaction failure has occurred 😭
|INVITE
|pass INV to TU
INVITE V send 100 if TU won't in 200ms
send response+-----------+
+--------| |--------+101-199 from TU
| | Proceeding| |send response
+------->| |<-------+
| | Transport Err.
| | Inform TU
| |--------------->+
+-----------+ |
300-699 from TU | |2xx from TU |
send response | |send response |
| +------------------>+
| |
INVITE V Timer G fires |
send response+-----------+ send response |
+--------| |--------+ |
| | Completed | | |
+------->| |<-------+ |
+-----------+ |
| | |
ACK | | |
- | +------------------>+
| Timer H fires |
V or Transport Err.|
+-----------+ Inform TU |
| | |
| Confirmed | |
| | |
+-----------+ |
| |
|Timer I fires |
|- |
| |
V |
+-----------+ |
| | |
| Terminated|<---------------+
| |
+-----------+Figure 7: INVITE server transaction
The whole point of the "Confirmed" state is to soak up any extra ACK messages that trickle in, triggered by retransmissions of the final response 🧸 When we enter this state, timer I is set to fire in T4 seconds for unreliable transports, and zero seconds for reliable transports. Once timer I fires, the server MUST transition to the "Terminated" state.
Once the transaction hits "Terminated," it MUST be destroyed immediately. Same vibe as client transactions: this is needed so the 2xx responses to INVITE stay reliable 💖
17.2.2 Non-INVITE Server Transaction 🌈
The state machine for the non-INVITE server transaction is shown in Figure 8 💜
This state machine starts out in the "Trying" state, and it gets handed a request that is neither INVITE nor ACK. That request is passed up to the TU. Once we're in "Trying," any further request retransmissions get thrown away. A request counts as a retransmission if it matches the same server transaction, using the rules in Section 17.2.3 🍓
While we're in "Trying," if the TU passes a provisional response to the server transaction, the server transaction MUST enter the "Proceeding" state. That response MUST be passed to the transport layer for transmission. Any further provisional responses the TU hands over while in "Proceeding" MUST also be passed to the transport layer for transmission. If a retransmission of the request comes in while we're in "Proceeding," the most recently sent provisional response MUST be passed to the transport layer for retransmission. If the TU passes a final response (status codes 200-699) to the server while we're in "Proceeding," the transaction MUST enter the "Completed" state, and the response MUST be passed to the transport layer for transmission ✨
When the server transaction enters "Completed," it MUST set Timer J to fire in 64*T1 seconds for unreliable transports, and zero seconds for reliable transports. While in "Completed," the server transaction MUST pass the final response to the transport layer for retransmission whenever a retransmission of the request arrives. Any other final responses the TU passes to the server transaction MUST be discarded while we're in "Completed." The server transaction stays in this state until Timer J fires, and at that point it MUST transition to the "Terminated" state 🔥
The server transaction MUST be destroyed the instant it enters the "Terminated" state 🦋
17.2.3 Matching Requests to Server Transactions 💖
okay so when a request shows up from the network, the server has to figure out which existing transaction it belongs to. 🎀 here's how it goes:
The branch parameter in the topmost Via header field of the request gets checked first. If it's there and starts with the magic cookie z9hG4bK, then the request came from a client transaction that follows this spec 🦋. That means the branch parameter is unique across all transactions sent by that client. A request matches a transaction if:
- the
branchparameter in the request is equal to the one in the topViaheader field of the request that created the transaction, and - the sent-by value in the top
Viaof the request is equal to the one in the request that created the transaction, and - the method of the request matches the one that created the transaction, except for
ACK, where the method of the request that created the transaction isINVITE.
this matching rule works the same for both INVITE and non-INVITE transactions 💅
The sent-by value is part of the matching because there could be accidental or malicious duplication of branch parameters from different clients. 👀
if the branch parameter in the top Via header field is missing, or doesn't have the magic cookie, the following procedures kick in. 🌸 these are there for backwards compatibility with RFC 2543 compliant implementations.
for those, an INVITE request matches a transaction if the Request-URI, To tag, From tag, Call-ID, CSeq, and top Via header field all match those of the INVITE request that created the transaction. in that case the INVITE is a retransmission of the original one 🔁. an ACK request matches a transaction if the Request-URI, From tag, Call-ID, CSeq number (not the method), and top Via header field match those of the INVITE that created the transaction, AND the To tag of the ACK matches the To tag of the response the server transaction sent. matching is done using the matching rules defined for each of those header fields ✨
the To tag in the ACK helps tell apart an ACK for a 2xx from an ACK for other responses at a proxy 🧚. that matters because the proxy might have forwarded both responses. (this can happen in unusual conditions. like, if a proxy forked a request and then crashed, the responses might get delivered to another proxy, which could end up forwarding multiple responses upstream 😭). an ACK that matches an INVITE transaction already matched by a previous ACK counts as a retransmission of that previous ACK 🫶
|Request received
|pass to TU
V
+-----------+
| |
| Trying |-------------+
| | |
+-----------+ |200-699 from TU
| |send response
|1xx from TU |
|send response |
| |
Request V 1xx from TU |
send response+-----------+send response|
+--------| |--------+ |
| | Proceeding| | |
+------->| |<-------+ |
+<--------------| | |
|Trnsprt Err +-----------+ |
|Inform TU | |
| | |
| |200-699 from TU |
| |send response |
| Request V |
| send response+-----------+ |
| +--------| | |
| | | Completed |<------------+
| +------->| |
+<--------------| |
|Trnsprt Err +-----------+
|Inform TU |
| |Timer J fires
| |-
| |
| V
| +-----------+
| | |
+-------------->| Terminated|
| |
+-----------+
Figure 8: non-INVITE server transactionfor every other request method, a request matches a transaction if the Request-URI, To tag, From tag, Call-ID, CSeq (including the method), and top Via header field all match those of the request that created the transaction. matching is again done with the rules for each header field 💜. when a non-INVITE request matches an existing transaction, it's a retransmission of the request that made that transaction 🔁
here's the tea 🍵: since the matching rules include the Request-URI, the server can't match a response to a transaction. so when the TU hands a response to the server transaction, it has to pass it to the specific server transaction the response is aimed at 🎯
17.2.4 Handling Transport Errors 🚨
when the server transaction sends a response down to the transport layer, the following procedures happen if the transport layer reports a failure 😬
first, the procedures in [4] get followed, which try to deliver the response to a backup. if all of those fail (based on the definition of failure in [4]), the server transaction SHOULD inform the TU that a failure happened, and SHOULD transition to the terminated state 💀
18 Transport 🚚✨
the transport layer is responsible for actually sending requests and responses over network transports 📦. that includes figuring out which connection to use for a request or response when the transport is connection-oriented 🔌
the transport layer also manages persistent connections for transport protocols like TCP and SCTP, or TLS over those, including ones opened to the transport layer 🧠. that covers connections opened by the client or server transports too, so connections get shared between the client and server transport functions. these connections are indexed by the tuple made from the address, port, and transport protocol at the far end of the connection 🗂️. when the transport layer opens a connection, this index is set to the destination IP, port and transport. when the transport layer accepts a connection, the index is set to the source IP address, port number, and transport.
a little heads-up 🙈: the source port is often ephemeral, but you can't know whether it's ephemeral or was picked through procedures in [4]. so connections the transport layer accepts will frequently NOT get reused. the result is that two proxies in a "peering" relationship using a connection-oriented transport will often end up with two connections in use, one for transactions started in each direction 👯
it is RECOMMENDED that connections stay open for some implementation-defined duration after the last message was sent or received over them ⏳. that duration SHOULD at least equal the longest time the element would need to bring a transaction from instantiation to the terminated state. the point is to make it likely that transactions finish over the same connection they started on (for example, the request, the response, and, for INVITE, the ACK for non-2xx responses) 🎀. this usually means at least 64*T1 (see Section 17.1.1.1 for a definition of T1). it could be larger in an element that has a TU using a large value for timer C (bullet 11 of Section 16.6), for example 🌈
All SIP elements MUST implement UDP and TCP. SIP elements MAY implement other protocols 🧚♀️
Making TCP mandatory for the UA is a huge change from RFC 2543 🤯. it came out of the need to handle larger messages, which MUST use TCP, as discussed below. so even if an element never sends large messages, it might receive one, and it needs to be able to handle them 🫶
18.1 Clients 📱
18.1.1 Sending Requests
okay so the client side of the transport layer is the one in charge of sending the request and catching the responses 💌 the user of the transport layer hands the client transport the request, an IP address, a port, a transport, and possibly a TTL if the destination is multicast 🦋
If a request is within 200 bytes of the path MTU, or if it's larger than 1300 bytes and the path MTU is unknown, the request MUST be sent using an RFC 2914 [43] congestion controlled transport protocol, such as TCP 🎀 If that causes a change in the transport protocol from the one in the top Via, the value in the top Via MUST be changed 🔥 This stops messages from getting fragmented over UDP and gives larger messages congestion control. However, implementations MUST be able to handle messages up to the maximum datagram packet size. For UDP, that size is 65,535 bytes, including IP and UDP headers 💅
The 200 byte "buffer" between the message size and the MTU is there because a SIP response can be bigger than the request 🙈 That happens because Record-Route header field values get added to responses to INVITE, for example. With that buffer, the response can be about 170 bytes bigger than the request and still not get fragmented on IPv4 (about 30 bytes goes to IP/UDP, assuming no IPSec). The 1300 number was picked for when the path MTU isn't known, based on the assumption of a 1500 byte Ethernet MTU. iykyk 🧚
If an element sends a request over TCP because of these message size constraints, and that request would otherwise have gone over UDP, and the connection attempt either gets an ICMP Protocol Not Supported or results in a TCP reset, the element SHOULD retry the request using UDP 🌸 This is only there for backwards compatibility with RFC 2543 compliant implementations that don't support TCP. It's expected that this behavior will get deprecated in a future revision of this specification 👋
A client that sends a request to a multicast address MUST add the "maddr" parameter to its Via header field value, containing the destination multicast address. For IPv4, it SHOULD also add the "ttl" parameter with a value of 1 ✨ Using IPv6 multicast isn't defined in this specification, and it'll be a topic for future standardization when the need comes up 🌈
These rules make multicast in SIP purposefully limited 🫶 Its main job is a "single-hop-discovery-like" service, sending a request to a group of homogeneous servers where only one response needs to be processed. This is most useful for registrations. Actually, based on the transaction processing rules in Section 17.1.3, the client transaction will accept the first response and treat any others as retransmissions, because they all have the same Via branch identifier 😭
Before a request is sent, the client transport MUST insert a value for the "sent-by" field into the Via header field. That field holds an IP address or host name, and a port. Using an FQDN is RECOMMENDED 💖 This field is used for sending responses under certain conditions, which we'll get to. If the port is absent, the default depends on the transport: it's 5060 for UDP, TCP and SCTP, and 5061 for TLS 🍓
For reliable transports, the response normally goes back on the connection the request came in on. So the client transport MUST be ready to receive the response on the same connection it used to send the request 🔒 Under error conditions the server might try to open a new connection to send the response. To handle that, the transport layer MUST also be ready to accept an incoming connection from the source IP address the request was sent from, on the port in the "sent-by" field. It also MUST be ready to accept incoming connections on any address and port that a server would pick by following the procedures in Section 5 of [4] 🧚
For unreliable unicast transports, the client transport MUST be ready to receive responses on the source IP address the request was sent from (since responses go back to the source address), and on the port in the "sent-by" field. And just like with reliable transports, sometimes the response gets sent somewhere else. So the client MUST be ready to receive responses on any address and port that a server would select following Section 5 of [4] 💌
For multicast, the client transport MUST be ready to receive responses on the same multicast group and port the request was sent to. (In other words, it needs to be a member of the multicast group it sent the request to.) 🦋
If a request is headed to an IP address, port and transport that already has an open connection, it is RECOMMENDED to send the request over that connection, but another connection MAY be opened and used 🌸
If a request is sent using multicast, it goes to the group address, port and TTL the transport user provided. If a request is sent using an unreliable unicast transport, it goes to the IP address and port the transport user provided 💅
18.1.2 Receiving Responses
when a response comes in, the client transport looks at the top Via header field value 👀 If the "sent-by" parameter in that header field value doesn't match a value the client transport is set up to insert into requests, the response MUST be silently discarded 🙅♀️
If there are any client transactions floating around, the client transport uses the matching procedures from Section 17.1.3 to try to match the response to one of them. If there's a match, the response MUST be passed to that transaction. Otherwise, the response MUST be passed up to the core (whether that's a stateless proxy, a stateful proxy, or a UA) for further processing. What happens to these "stray" responses depends on the core: a proxy will forward them, while a UA will discard them, for example 🗑️✨
18.2 Servers
18.2.1 Receiving Requests
a server SHOULD be ready to receive requests on any IP address, port and transport combination that could come out of a DNS lookup on a SIP or SIPS URI [4] that's been handed out to talk to that server 🌐 "Handing out" here includes putting a URI in a Contact header field in a REGISTER request or a redirect response, or in a Record-Route header field in a request or response. A URI can also get handed out by posting it on a web page or a business card 💼 It's also RECOMMENDED that a server listens for requests on the default SIP ports (5060 for TCP and UDP, 5061 for TLS over TCP) on all public interfaces. The usual exceptions are private networks, or when several server instances are running on the same host 🏠
For any port and interface a server listens on for UDP, it MUST listen on that same port and interface for TCP. That's because a message might need to go over TCP instead of UDP if it's too big 📦 The reverse isn't true, though: a server doesn't need to listen for UDP on an address and port just because it's listening for TCP on them. There may be other reasons a server needs to listen for UDP on a particular address and port, of course 🫶
When the server transport gets a request over any transport, it MUST look at the "sent-by" parameter in the top Via header field value. If the host portion of "sent-by" has a domain name in it, or if it has an IP address that's different from the packet source address, the server MUST add a "received" parameter to that Via header field value. That parameter MUST hold the source address the packet came from 🔍 This helps the server transport send the response, since it has to go back to the source IP address the request came from 💖
Take a request the server transport gets that looks like this, in part:
INVITE sip:bob@Biloxi.com SIP/2.0
Via: SIP/2.0/UDP bobspc.biloxi.com:5060The request arrives with a source IP address of 192.0.2.4. Before passing the request up, the transport adds a "received" parameter, so the request now looks like this, in part:
INVITE sip:bob@Biloxi.com SIP/2.0
Via: SIP/2.0/UDP bobspc.biloxi.com:5060;received=192.0.2.4Next, the server transport tries to match the request to a server transaction, using the matching rules in Section 17.2.3 🎯 If it finds a matching server transaction, the request gets passed to that transaction for processing. If nothing matches, the request is passed to the core, which may decide to build a new server transaction for it. Heads up: when a UAS core sends a 2xx response to INVITE, the server transaction gets destroyed 💀 So when the ACK shows up, there won't be a matching server transaction, and under this rule the ACK gets passed to the UAS core to be processed 🎀
18.2.2 Sending Responses
the server transport uses the top Via header field value to figure out where to send a response 🗺️ It MUST follow this process:
- If the "sent-protocol" is a reliable transport protocol like TCP or SCTP, or TLS over those, the response MUST be sent over the existing connection to the source of the original request that made the transaction, as long as that connection is still open. This means the server transport has to keep track of which server transactions go with which transport connections 🔗 If that connection has closed, the server SHOULD open a connection to the IP address in the "received" parameter (if there is one), using the port in the "sent-by" value, or the default port for that transport if no port is given. If that connection attempt fails, the server SHOULD use the procedures in [4] for servers to figure out the IP address and port to open a connection to and send the response to 💫
- Otherwise, if the Via header field value has a "maddr" parameter, the response MUST be forwarded to the address listed there, using the port indicated in "sent-by", or port 5060 if none is present. If the address is a multicast address, the response SHOULD be sent with the TTL indicated in the "ttl" parameter, or with a TTL of 1 if that parameter isn't there 📡
- Otherwise (for unreliable unicast transports), if the top Via has a "received" parameter, the response MUST be sent to the address in the "received" parameter, using the port indicated in the "sent-by" value, or port 5060 if none is explicitly specified. If that fails, for example by eliciting an ICMP "port unreachable" response, the procedures in Section 5 of [4] SHOULD be used to figure out where to send the response 🙃
- Otherwise, if it is not receiver-tagged, the response MUST be sent to the address indicated by the "sent-by" value, using the procedures in Section 5 of [4] 💜
18.3 Framing 🎀
okay so for message-oriented transports like UDP 👋, if the message has a Content-Length header field, the body is assumed to be that many bytes. Any extra bytes sitting in the transport packet past the end of the body MUST be discarded. If the packet ends before the body does, that's an error 😭. If the message is a response, it MUST be discarded. If it's a request, the element SHOULD generate a 400 (Bad Request) response. And if there's no Content-Length header field at all, the body is assumed to end at the end of the transport packet 🫶.
for stream-oriented transports such as TCP, Content-Length tells you the size of the body. It's a total MUST here, bestie 💅 The Content-Length header field MUST be used with stream oriented transports.
18.4 Error Handling 💀
error handling doesn't care whether the message was a request or a response ✨
if the transport user asks for a message to be sent over an unreliable transport and the result is an ICMP error, it depends on which ICMP error you got. Host, network, port or protocol unreachable errors, or parameter problem errors, SHOULD cause the transport layer to tell the transport user about a failure in sending 🚨. Source quench and TTL exceeded ICMP errors SHOULD be ignored 🙈.
if the transport user asks for a request to be sent over a reliable transport and the result is a connection failure, the transport layer SHOULD inform the transport user of a failure in sending 🔥.
19 Common Message Components 💅
there are certain components of SIP messages that show up all over the place (and sometimes outside of messages too!), so they deserve their own spotlight 🌸
19.1 SIP and SIPS Uniform Resource Indicators 🦋
a SIP or SIPS URI identifies a communications resource. Like all URIs, they can live on web pages, in emails, or on printed literature 📇. They carry enough info to start and maintain a communication session with the resource, which is so iconic.
examples of communications resources include the following:
- a user of an online service
- an appearance on a multi-line phone
- a mailbox on a messaging system
- a PSTN number at a gateway service
- a group (such as "sales" or "helpdesk") in an organization
a SIPS URI says the resource is to be contacted securely. In particular, TLS is to be used between the UAC and the domain that owns the URI 🔒. From there, secure communications are used to reach the user, and the specific security mechanism depends on the policy of the domain. Any resource described by a SIP URI can be "upgraded" to a SIPS URI just by changing the scheme, if you want to communicate with that resource securely ✨
19.1.1 SIP and SIPS URI Components 🧚
the sip: and sips: schemes follow the guidelines in RFC 2396 [5]. They use a form similar to the mailto URL, which lets you specify SIP request-header fields and the SIP message-body 💌. This makes it possible to specify the subject, media type, or urgency of sessions started from a URI on a web page or in an email message. The formal syntax for a SIP or SIPS URI is in Section 25. In the case of a SIP URI, the general form is:
sip:user:password@host:port;uri-parameters?headersthe format for a SIPS URI is the same, except the scheme is sips instead of sip. Here's what these tokens (and some of the tokens in their expansions) mean:
- user: The identifier of a particular resource at the host being addressed. "Host" in this context often refers to a domain. The userinfo of a URI is this user field, the password field, and the @ sign following them. The userinfo part is optional and MAY be absent when the destination host doesn't have a notion of users, or when the host itself is the resource being identified. If the @ sign is present in a SIP or SIPS URI, the user field MUST NOT be empty.
If the host being addressed can process telephone numbers (say, an Internet telephony gateway), a telephone-subscriber field defined in RFC 2806 [9] MAY be used to populate the user field 📞. Special escaping rules for encoding telephone-subscriber fields in SIP and SIPS URIs are in Section 19.1.2.
- password: A password associated with the user. The SIP and SIPS URI syntax lets this field be present, but its use is NOT RECOMMENDED 🙈. Passing authentication info in clear text (like in URIs) has proven to be a security risk in almost every case where it's been used. For instance, transporting a PIN number in this field exposes the PIN.
note that the password field is just an extension of the user portion. Implementations not wishing to give special significance to the password portion MAY simply treat user:password as a single string.
- host: The host providing the SIP resource. The host part contains either a fully-qualified domain name or a numeric IPv4 or IPv6 address. Using the fully-qualified domain name form is RECOMMENDED whenever possible 💖.
- port: The port number where the request is to be sent.
- URI parameters: Parameters affecting a request constructed from the URI.
URI parameters are added after the hostport component and are separated by semi-colons. They take the form:
parameter-name "=" parameter-valueeven though an arbitrary number of URI parameters can be included in a URI, any given parameter-name MUST NOT appear more than once 🚫.
this extensible mechanism includes the transport, maddr, ttl, user, method and lr parameters.
the transport parameter determines the transport mechanism to be used for sending SIP messages, as specified in [4]. SIP can use any network transport protocol. Parameter names are defined for UDP (RFC 768 [14]), TCP (RFC 761 [15]), and SCTP (RFC 2960 [16]). For a SIPS URI, the transport parameter MUST indicate a reliable transport 🔐.
the maddr parameter indicates the server address to be contacted for this user, overriding any address derived from the host field. When a maddr parameter is present, the port and transport components of the URI apply to the address indicated in the maddr parameter value. [4] describes the proper interpretation of the transport, maddr, and hostport in order to get the destination address, port, and transport for sending a request.
the maddr field has been used as a simple form of loose source routing. It lets a URI specify a proxy that must be traversed en-route to the destination. Continuing to use the maddr parameter this way is strongly discouraged (the mechanisms that enable it are deprecated) 🚧. Implementations should instead use the Route mechanism described in this document, establishing a pre-existing route set if necessary (see Section 8.1.1.1). This provides a full URI to describe the node to be traversed.
the ttl parameter determines the time-to-live value of the UDP multicast packet and MUST only be used if maddr is a multicast address and the transport protocol is UDP. For example, to specify a call to alice@atlanta.com using multicast to 239.255.255.1 with a ttl of 15, you'd use this URI:
sip:alice@atlanta.com;maddr=239.255.255.1;ttl=15the set of valid telephone-subscriber strings is a subset of valid user strings. The user URI parameter exists to tell telephone numbers apart from user names that just happen to look like telephone numbers 🧐. If the user string contains a telephone number formatted as a telephone-subscriber, the user parameter value "phone" SHOULD be present. Even without this parameter, recipients of SIP and SIPS URIs MAY interpret the pre-@ part as a telephone number if local restrictions on the name space for user names allow it.
the method of the SIP request constructed from the URI can be specified with the method parameter.
the lr parameter, when present, indicates that the element responsible for this resource implements the routing mechanisms specified in this document. This parameter will be used in the URIs proxies place into Record-Route header field values, and may appear in the URIs in a pre-existing route set.
this parameter is used to achieve backwards compatibility with systems implementing the strict-routing mechanisms of RFC 2543 and the rfc2543bis drafts up to bis-05. An element preparing to send a request based on a URI not containing this parameter can assume the receiving element implements strict-routing and reformat the message to preserve the information in the Request-URI 🔄.
since the uri-parameter mechanism is extensible, SIP elements MUST silently ignore any uri-parameters that they do not understand 🫥.
- Headers: Header fields to be included in a request constructed from the URI.
header fields in the SIP request can be specified with the "?" mechanism within a URI. The header names and values are encoded in ampersand separated hname = hvalue pairs. The special hname "body" indicates that the associated hvalue is the message-body of the SIP request 🎁.
Table 1 summarizes the use of SIP and SIPS URI components based on the context in which the URI appears 📊. The external column describes URIs appearing anywhere outside of a SIP message, for instance on a web page or business card. Entries marked "m" are mandatory, those marked "o" are optional, and those marked "-" are not allowed. Elements processing URIs SHOULD ignore any disallowed components if they are present. The second column indicates the default value of an optional element if it isn't present. "--" indicates that the element is either not optional, or has no default value.
URIs in Contact header fields have different restrictions depending on the context in which the header field appears 🧩. One set applies to messages that establish and maintain dialogs (INVITE and its 200 (OK) response). The other applies to registration and redirection messages (REGISTER, its 200 (OK) response, and 3xx class responses to any method).
19.1.2 Character Escaping Requirements ✨
okay so bestie, SIP URIs are like little addresses, and some characters have special jobs inside them 🎀 if you want one of those characters to just be regular data, you have to escape it first 💅 SIP borrows its rules from RFC 2396 [5] and uses the "%" HEX HEX trick for it. Here's what RFC 2396 [5] says about it:
The set of characters actually reserved within any given URI component is defined by that component. In general, a character is reserved if the semantics of the URI changes if the character is replaced with its escaped US-ASCII encoding [5]. Excluded US-ASCII characters (RFC 2396 [5]), such as space and control characters and characters used as URI delimiters, also MUST be escaped. URIs MUST NOT contain unescaped space and control characters.
For each component, the set of valid BNF expansions decides exactly which characters can show up unescaped. Everything else MUST be escaped 🙈
For example, "@" isn't in the set of characters allowed in the user component, so the user "j@s0n" has to have at least the @ sign encoded, like "j%40s0n" 💖
Expanding the hname and hvalue tokens in Section 25 shows that all URI reserved characters in header field names and values MUST be escaped 🔥
The telephone-subscriber subset of the user component has its own special escaping drama 👑 the set of characters not reserved in the RFC 2806 [9] description of telephone-subscriber has a bunch of characters in different syntax elements that need escaping when they're used in SIP URIs. Any characters inside a telephone-subscriber that don't show up in an expansion of the BNF for the user rule MUST be escaped 🦋
Now the host component is a no-go for escaping 🚫 the % character isn't valid in its expansion at all. This might change later once the requirements for Internationalized Domain Names get finalized, so keep an eye out ✨ For now, current implementations MUST NOT try to make themselves more robust by treating received escaped characters in the host component as literally equivalent to their unescaped counterparts. The behavior needed for IDN might be pretty different 🌸
19.1.3 Example SIP and SIPS URIs
Here are some examples so you can see what all of this looks like in real life 🧚
sip:alice@atlanta.com
sip:alice:secretword@atlanta.com;transport=tcp
sips:alice@atlanta.com?subject=project%20x&priority=urgent
sip:+1-212-555-1212:1234@gateway.com;user=phone
sips:1212@gateway.com
sip:alice@192.0.2.4
sip:atlanta.com;method=REGISTER?to=alice%40atlanta.com
sip:alice;day=tuesday@atlanta.comThe last one is giving main character energy 🎀 its user field value is "alice;day=tuesday". The escaping rules we just went over let a semicolon sit there unescaped. For this protocol, that field is opaque 🫶 its structure only matters to the SIP element responsible for the resource, so nobody else needs to read into it.
19.1.4 URI Comparison
Sometimes you have to figure out whether two SIP or SIPS URIs are equivalent 🔍 in this spec, registrars need to compare bindings in Contact URIs in REGISTER requests (see Section 10.3.). SIP and SIPS URIs get compared for equality using these rules, and ngl they're a whole vibe 💅
- A SIP and SIPS URI are never equivalent.
- Comparison of the userinfo of SIP and SIPS URIs is case-sensitive. This includes userinfo containing passwords or formatted as telephone-subscribers. Comparison of all other components of the URI is case-insensitive unless explicitly defined otherwise.
- The ordering of parameters and header fields is not significant in comparing SIP and SIPS URIs.
- Characters other than those in the "reserved" set (see RFC 2396 [5]) are equivalent to their
"%" HEX HEXencoding. - An IP address that is the result of a DNS lookup of a host name does not match that host name.
- For two URIs to be equal, the user, password, host, and port components must match.
- A URI omitting the user component will not match a URI that includes one. A URI omitting the password component will not match a URI that includes one.
- A URI omitting any component with a default value will not match a URI explicitly containing that component with its default value. For instance, a URI omitting the optional port component will not match a URI explicitly declaring port 5060. The same is true for the transport-parameter, ttl-parameter, user-parameter, and method components.
Defining sip:user@host to not be equivalent to sip:user@host:5060 is a change from RFC 2543. When deriving addresses from URIs, equivalent addresses are expected from equivalent URIs. The URI sip:user@host:5060 will always resolve to port 5060. The URI sip:user@host may resolve to other ports through the DNS SRV mechanisms detailed in [4]. 🙈
- URI uri-parameter components are compared as follows:
- Any uri-parameter appearing in both URIs must match.
- A user, ttl, or method uri-parameter appearing in only one URI never matches, even if it contains the default value.
- A URI that includes an maddr parameter will not match a URI that contains no maddr parameter.
- All other uri-parameters appearing in only one URI are ignored when comparing the URIs.
- URI header components are never ignored. Any present header component MUST be present in both URIs and match for the URIs to match. The matching rules are defined for each header field in Section 20.
Now the fun part: these sets of URIs are equivalent to each other 💖
sip:%61lice@atlanta.com;transport=TCP
sip:alice@AtLanTa.CoM;Transport=tcp
sip:carol@chicago.com
sip:carol@chicago.com;newparam=5
sip:carol@chicago.com;security=on
sip:biloxi.com;transport=tcp;method=REGISTER?to=sip:bob%40biloxi.com
sip:biloxi.com;method=REGISTER;transport=tcp?to=sip:bob%40biloxi.com
sip:alice@atlanta.com?subject=project%20x&priority=urgent
sip:alice@atlanta.com?priority=urgent&subject=project%20xAnd these sets are NOT equivalent, so don't let anyone tell you otherwise 🥲
SIP:ALICE@AtLanTa.CoM;Transport=udp (different usernames)
sip:alice@AtLanTa.CoM;Transport=UDP
sip:bob@biloxi.com (can resolve to different ports)
sip:bob@biloxi.com:5060
sip:bob@biloxi.com (can resolve to different transports)
sip:bob@biloxi.com;transport=udp
sip:bob@biloxi.com (can resolve to different port and transports)
sip:bob@biloxi.com:6000;transport=tcp
sip:carol@chicago.com (different header component)
sip:carol@chicago.com?Subject=next%20meeting
sip:bob@phone21.boxesbybob.com (even though that's what
sip:bob@192.0.2.4 phone21.boxesbybob.com resolves to)Equality is not transitive, which is so chaotic 🌀
sip:carol@chicago.comandsip:carol@chicago.com;security=onare equivalentsip:carol@chicago.comandsip:carol@chicago.com;security=offare equivalentsip:carol@chicago.com;security=onandsip:carol@chicago.com;security=offare not equivalent
19.1.5 Forming Requests from a URI
Okay so this one needs some care 🧐 when you form requests straight from a URI, you have to be careful, because URIs from business cards, web pages, and even sources inside the protocol like registered contacts can carry header fields or body parts that just don't belong 🙃
An implementation MUST include any provided transport, maddr, ttl, or user parameter in the Request-URI of the formed request. If the URI contains a method parameter, its value MUST be used as the method of the request. The method parameter MUST NOT be placed in the Request-URI. Unknown URI parameters MUST be placed in the message's Request-URI 💅
An implementation SHOULD treat the presence of any headers or body parts in the URI as a desire to include them in the message, and choose to honor the request on a per-component basis 🎀
An implementation SHOULD NOT honor these obviously dangerous header fields: From, Call-ID, CSeq, Via, and Record-Route 💀
An implementation SHOULD NOT honor any requested Route header field values, so it doesn't get used as an unwitting agent in malicious attacks 🚨
An implementation SHOULD NOT honor requests to include header fields that might make it falsely advertise its location or capabilities. These include: Accept, Accept-Encoding, Accept-Language, Allow, Contact (in its dialog usage), Organization, Supported, and User-Agent 🌈
An implementation SHOULD verify the accuracy of any requested descriptive header fields, including: Content-Disposition, Content-Encoding, Content-Language, Content-Length, Content-Type, Date, Mime-Version, and Timestamp ⭐
If the request formed from constructing a message from a given URI is not a valid SIP request, the URI is invalid. An implementation MUST NOT proceed with transmitting the request. It should instead pursue the course of action due an invalid URI in the context it occurs 😭
The constructed request can be invalid in many ways. These include, but are not limited to, syntax error in header fields, invalid combinations of URI parameters, or an incorrect description of the message body.
Sending a request formed from a given URI may require capabilities the implementation doesn't have. The URI might indicate use of an unimplemented transport or extension, for example. An implementation SHOULD refuse to send these requests rather than modifying them to match their capabilities. An implementation MUST NOT send a request requiring an extension that it does not support 🫠
For example, such a request can be formed through the presence of a Require header parameter or a method URI parameter with an unknown or explicitly unsupported value.
19.1.6 Relating SIP URIs and tel URLs ✨
okay so when a tel URL (RFC 2806 [9]) gets converted into a SIP or SIPS URI, the whole telephone-subscriber part (parameters included) gets shoved into the userinfo section 🎀
tel:+358-555-1234567;postd=pp22 becomes
sip:+358-555-1234567;postd=pp22@foo.com;user=phone
or
sips:+358-555-1234567;postd=pp22@foo.com;user=phone
not
sip:+358-555-1234567@foo.com;postd=pp22;user=phone
or
sips:+358-555-1234567@foo.com;postd=pp22;user=phonengl, equivalent tel URLs can turn into SIP or SIPS URIs that are NOT equivalent 😭 The userinfo of SIP and SIPS URIs gets compared as a case-sensitive string, so case differences in the parts that don't care about case, plus shuffled tel URL parameters, don't change tel URL equivalence but DO change the equivalence of the SIP URIs made from them. It's giving plot twist 🙈
tel:+358-555-1234567;postd=pp22
tel:+358-555-1234567;POSTD=PP22these are equivalent, while
sip:+358-555-1234567;postd=pp22@foo.com;user=phone
sip:+358-555-1234567;POSTD=PP22@foo.com;user=phoneare not 💀
tel:+358-555-1234567;postd=pp22;isub=1411
tel:+358-555-1234567;isub=1411;postd=pp22are equivalent, while
sip:+358-555-1234567;postd=pp22;isub=1411@foo.com;user=phone
sip:+358-555-1234567;isub=1411;postd=pp22@foo.com;user=phoneare not 😤
To fix this mess, the elements that build telephone-subscriber fields for the userinfo part of a SIP or SIPS URI SHOULD fold any case-insensitive portion of the telephone-subscriber to lower case, and put the telephone-subscriber parameters in lexical order by parameter name. The exceptions are isdn-subaddress and post-dial, which go first and in that order. (All components of a tel URL except future-extension parameters are defined to be compared case-insensitive.) 🧚
Following that suggestion, both
tel:+358-555-1234567;postd=pp22
tel:+358-555-1234567;POSTD=PP22become
sip:+358-555-1234567;postd=pp22@foo.com;user=phoneand both
tel:+358-555-1234567;tsp=a.b;phone-context=5
tel:+358-555-1234567;phone-context=5;tsp=a.bbecome
sip:+358-555-1234567;phone-context=5;tsp=a.b@foo.com;user=phone19.2 Option Tags 🌈
Option tags are unique identifiers used to designate new options (extensions) in SIP. They show up in the Require (Section 20.32), Proxy-Require (Section 20.29), Supported (Section 20.37) and Unsupported (Section 20.40) header fields. Heads up: in those header fields the options appear as parameters, in the option-tag = token form (see Section 25 for the definition of token). 🍓
Option tags get defined in standards track RFCs. This is a change from past practice, and it's happening to keep multi-vendor interoperability going strong (see the discussion in Section 20.32 and Section 20.37) 🫶 There's an IANA registry of option tags so they're easy to look up. Iconic 👑
19.3 Tags 💅
The "tag" parameter lives in the To and From header fields of SIP messages. It's the general way to identify a dialog, which is the Call-ID plus two tags, one from each participant. When a UA sends a request outside of a dialog, it only has a From tag, so that's "half" of the dialog ID. The dialog gets completed from the response(s), and each one contributes the second half in its To header field. Forking means one request can set up multiple dialogs, and that's exactly why the identifier needs two sides. Without input from the recipients, the originator couldn't tell those dialogs apart ✨
When a UA generates a tag to put into a request or response, it MUST be globally unique and cryptographically random with at least 32 bits of randomness. Because of that rule, a UA puts a different tag in the From header of an INVITE than it would put in the To header of the response to that same INVITE. That's what lets a UA invite itself into a session, which is a super common "hairpinning" move in PSTN gateways 🔥 Similarly, two INVITEs for different calls will have different From tags, and two responses for different calls will have different To tags.
Besides global uniqueness, the way a tag gets generated is implementation-specific. Tags are clutch in fault-tolerant systems, where a dialog has to be recovered on an alternate server after a failure. A UAS can pick the tag in a way that lets a backup recognize a request as part of a dialog on the failed server, so the backup can figure out that it should try to recover the dialog and any other state tied to it 🦋
20 Header Fields 🎀
The general syntax for header fields is covered in Section 7.3. This section lists the full set of header fields along with notes on syntax, meaning, and usage. Throughout this section, we use [HX.Y] to refer to Section X.Y of the current HTTP/1.1 specification RFC 2616 [8]. Examples of each header field are given.
Info about header fields in relation to methods and proxy processing is summarized in Tables 2 and 3 🌸
The "where" column says which request and response types a header field can be used in. The values in this column are:
R: header field may only appear in requests;r: header field may only appear in responses;2xx, 4xx, etc.: A numerical value or range indicates response codes with which the header field can be used;c: header field is copied from the request to the response.
An empty entry in the "where" column means the header field may be present in all requests and responses.
The "proxy" column describes what a proxy is allowed to do with a header field:
a: A proxy can add or concatenate the header field if not present.m: A proxy can modify an existing header field value.d: A proxy can delete a header field value.r: A proxy must be able to read the header field, and thus this header field cannot be encrypted.
The next six columns are about whether a header field shows up in a method:
c: Conditional; requirements on the header field depend on the context of the message.m: The header field is mandatory.m*: The header field SHOULD be sent, but clients/servers need to be prepared to receive messages without that header field.o: The header field is optional.t: The header field SHOULD be sent, but clients/servers need to be prepared to receive messages without that header field. If a stream-based protocol (such as TCP) is used as a transport, then the header field MUST be sent.*: The header field is required if the message body is not empty. See Sections 20.14, 20.15 and 7.4 for details.-: The header field is not applicable.
"Optional" means an element MAY include the header field in a request or response, and a UA MAY ignore it if it's present (the exception to this rule is the Require header field, discussed in 20.32) 🙈 A "mandatory" header field MUST be present in a request, and MUST be understood by the UAS receiving the request. A mandatory response header field MUST be present in the response, and the UAC processing the response MUST understand it. "Not applicable" means the header field MUST NOT be present in a request. If one shows up in a request by mistake, the UAS receiving the request MUST ignore it. Likewise, a header field marked "not applicable" for a response means the UAS MUST NOT put that header field in the response, and the UAC MUST ignore it in the response 💀
A UA SHOULD ignore extension header parameters it doesn't understand 🫶
There's also a compact form of some common header field names, for when overall message size is a concern 🧚
The Contact, From, and To header fields each contain a URI. If that URI has a comma, question mark or semicolon in it, the URI MUST be enclosed in angle brackets (< and >). Any URI parameters live inside those brackets. If the URI is NOT enclosed in angle brackets, then any semicolon-delimited parameters are header-parameters, not URI parameters. Main character energy 👑
20.1 Accept 💖
okay so the Accept header field follows the exact same syntax as [H14.1] ✨ and the semantics are identical too, with one twist: if there's no Accept header field at all, the server SHOULD assume a default value of application/sdp 🎀
an empty Accept header field means that no formats are acceptable 🙈
Example:
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
Accept R - o - o m* o
Accept 2xx - - - o m* o
Accept 415 - c - c c c
Accept-Encoding R - o - o o o
Accept-Encoding 2xx - - - o m* o
Accept-Encoding 415 - c - c c c
Accept-Language R - o - o o o
Accept-Language 2xx - - - o m* o
Accept-Language 415 - c - c c c
Alert-Info R ar - - - o - -
Alert-Info 180 ar - - - o - -
Allow R - o - o o o
Allow 2xx - o - m* m* o
Allow r - o - o o o
Allow 405 - m - m m m
Authentication-Info 2xx - o - o o o
Authorization R o o o o o o
Call-ID c r m m m m m m
Call-Info ar - - - o o o
Contact R o - - m o o
Contact 1xx - - - o - -
Contact 2xx - - - m o o
Contact 3xx d - o - o o o
Contact 485 - o - o o o
Content-Disposition o o - o o o
Content-Encoding o o - o o o
Content-Language o o - o o o
Content-Length ar t t t t t t
Content-Type * * - * * *
CSeq c r m m m m m m
Date a o o o o o o
Error-Info 300-699 a - o o o o o
Expires - - - o - o
From c r m m m m m m
In-Reply-To R - - - o - -
Max-Forwards R amr m m m m m m
Min-Expires 423 - - - - - m
MIME-Version o o - o o o
Organization ar - - - o o o
Table 2: Summary of header fields, A--O
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________________
Priority R ar - - - o - -
Proxy-Authenticate 407 ar - m - m m m
Proxy-Authenticate 401 ar - o o o o o
Proxy-Authorization R dr o o - o o o
Proxy-Require R ar - o - o o o
Record-Route R ar o o o o o -
Record-Route 2xx,18x mr - o o o o -
Reply-To - - - o - -
Require ar - c - c c c
Retry-After 404,413,480,486 - o o o o o
500,503 - o o o o o
600,603 - o o o o o
Route R adr c c c c c c
Server r - o o o o o
Subject R - - - o - -
Supported R - o o m* o o
Supported 2xx - o o m* m* o
Timestamp o o o o o o
To c(1) r m m m m m m
Unsupported 420 - m - m m m
User-Agent o o o o o o
Via R amr m m m m m m
Via rc dr m m m m m m
Warning r - o o o o o
WWW-Authenticate 401 ar - m - m m m
WWW-Authenticate 407 ar - o - o o o
Table 3: Summary of header fields, P--Z; (1): copied with possible
addition of tag Accept: application/sdp;level=1, application/x-private, text/html20.2 Accept-Encoding 🍓
this one is basically Accept's cousin 👯♀️, except it restricts the content-codings [H3.5] that are acceptable in the response. see [H14.3] for the details. the semantics in SIP are identical to what's defined in [H14.3] 💅
an empty Accept-Encoding header field is permissible 🫶 and it works out to the same thing as Accept-Encoding: identity. so only the identity encoding (aka no encoding at all) is allowed.
if there's no Accept-Encoding header field present, the server SHOULD assume a default value of identity ✨
ok this is where it gets a little different from HTTP 👀. HTTP says that when the header is missing, any encoding is fine but identity is the preferred one. SIP doesn't do that.
Example:
Accept-Encoding: gzip20.3 Accept-Language 🌈
the Accept-Language header field is used in requests to say which languages the client prefers for reason phrases, session descriptions, or status responses that show up as message bodies in the response 🗣️. if there's no Accept-Language header field present, the server SHOULD assume that all languages are acceptable to the client 🌸
the syntax follows what's defined in [H14.4]. and the rules for ordering languages based on the "q" parameter apply to SIP too, so no surprises there 🧚
Example:
Accept-Language: da, en-gb;q=0.8, en;q=0.720.4 Alert-Info 🔔
when Alert-Info shows up in an INVITE request, it tells the UAS to use an alternative ring tone 🎶. when it shows up in a 180 (Ringing) response, it tells the UAC to use an alternative ringback tone instead. a super common move is a proxy slipping this header in to give calls a distinctive ring feature 📞✨
okay, real talk: Alert-Info can introduce security risks 😭. all the details on those risks and how to handle them are in Section 20.9. that section covers Call-Info, since the risks are exactly the same 🔁
also, a user SHOULD be able to turn this feature off selectively 🙅♀️
This helps prevent disruptions that could result from the use of this header field by untrusted elements.
Example:
Alert-Info: <http://www.example.com/sounds/moo.wav>20.5 Allow 🦋
the Allow header field lists the set of methods supported by the UA that generated the message 📋
every method the UA understands MUST be listed in the Allow header field when it's present, and that includes ACK and CANCEL too 💯. now, if the Allow header field is absent, that MUST NOT be read as "this UA supports no methods." it just means the UA isn't giving any info about what it supports. so no, missing does not mean empty 🙈
sending Allow in responses to methods other than OPTIONS cuts down on how many messages are needed 🏃♀️💨
Example:
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE20.6 Authentication-Info 🔐
the Authentication-Info header field is how you get mutual authentication with HTTP Digest 🤝. a UAS MAY include this header field in a 2xx response to a request that was successfully authenticated using digest based on the Authorization header field 💜
the syntax and semantics follow what's specified in RFC 2617 [17] 📖
Example:
Authentication-Info: nextnonce="47364c23432d2e131a5fb210812c"20.7 Authorization 🎀
the Authorization header field carries a UA's authentication credentials 🪪. Section 22.2 gives you the overview of how it's used, and Section 22.4 covers the syntax and semantics when it's used with HTTP authentication 🧠
this one, along with Proxy-Authorization, breaks the usual rules about multiple header field values. even though it's not a comma-separated list, the name can show up multiple times, and it MUST NOT be combined into one header line using the usual rules described in Section 7.3. not allowed, bestie 🙅♀️💀
in the example below, notice there are no quotes around the Digest parameter 👀
Example:
Authorization: Digest username="Alice", realm="atlanta.com",
nonce="84a4cc6f3082121f32b42a2187831a9e",
response="7587245234b3434cc3412213e5f113a5432"20.8 Call-ID 🆔
the Call-ID header field uniquely identifies a particular invitation or all registrations of a particular client 🪪✨. one multimedia conference can give rise to several calls with different Call-IDs. for example, if a user invites the same person several times to the same long-running conference, each one can get its own ID 📅. Call-IDs are case-sensitive and get compared byte-by-byte, so no fudging the capitals 🙃
the compact form of the Call-ID header field is i 🧚♀️
Examples:
Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@biloxi.com
i:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@192.0.2.420.9 Call-Info 📇
the Call-Info header field gives extra info about the caller or callee, and what it means depends on whether it's in a request or a response 👯. the purpose of the URI is described by the "purpose" parameter. the "icon" parameter points to an image that works as an iconic representation of the caller or callee 🖼️. the "info" parameter describes the caller or callee in general, like through a web page 🌐. the "card" parameter gives a business card, for example in vCard [36] or LDIF [37] formats 💼. more tokens can be registered with IANA using the procedures in Section 27 🗂️
okay, sis, this one can be a security risk ⚠️😬. if a callee fetches the URIs a malicious caller provided, the callee may end up displaying inappropriate or offensive content, dangerous or illegal content, and so on 💀. so it is RECOMMENDED that a UA only render the information in the Call-Info header field if it can verify the authenticity of the element that originated the header field and trusts that element 🛡️. and that element doesn't have to be the peer UA, because a proxy can insert this header field into requests 🔁
Example:
Call-Info: <http://wwww.example.com/alice/photo.jpg> ;purpose=icon,
<http://www.example.com/alice/> ;purpose=info
20.10 Contact ✨
Okay bestie, the Contact header field value gives you a URI, and what that URI means depends entirely on what kind of request or response it's riding in 🦋
A Contact value can have a display name, a URI with URI parameters, and header parameters 💅
This doc defines the Contact parameters "q" and "expires" 🎀 They only get used when Contact is in a REGISTER request or response, or in a 3xx response. Other specs can add more parameters later 🌸
When there's a display name, the URI (with all its URI parameters) gets wrapped in "<" and ">". If there are no "<" and ">", every parameter after the URI is a header parameter, NOT a URI parameter 🙈 The display name can be tokens, or a quoted string if you want a bigger character set ✨
Even if the "display-name" is empty, the "name-addr" form MUST be used if the "addr-spec" contains a comma, semicolon, or question mark. There may or may not be LWS between the display-name and the "<" 💖
These same rules for parsing a display name, URI, URI parameters, and header parameters also apply to the To and From headers 🧚
Contact is kinda like the Location header field in HTTP, but HTTP only allows one address, and it's unquoted. URIs can have commas and semicolons as reserved characters, so those can get mistaken for header delimiters and parameter delimiters respectively. Messy! 😭
The compact form of Contact is m (for "moved") 🍓
Examples:
Contact: "Mr. Watson" <sip:watson@worcester.bell-telephone.com>
;q=0.7; expires=3600,
"Mr. Watson" <mailto:watson@bell-telephone.com> ;q=0.1
m: <sips:bob@192.0.2.4>;expires=6020.11 Content-Disposition 🎀
The Content-Disposition header field tells the UAC or UAS how to interpret the message body (or, for multipart messages, each body part) 💅 It's an extension of the MIME Content-Type (RFC 2183 [18]) ✨
SIP defines several new "disposition-types" 🌈 The value "session" means the body part describes a session, either for calls or early (pre-call) media 📞 The value "render" means the body part should be displayed or otherwise rendered to the user. It's "render" instead of "inline" on purpose, so nobody thinks the MIME body gets shown as part of the whole message, since SIP MIME bodies often aren't displayed to users at all 🙈
For backward-compatibility, if the Content-Disposition header field is missing, the server SHOULD assume that bodies of Content-Type application/sdp are the disposition "session", while other content types are "render" 💜
The disposition type "icon" means the body part has an image that works as an iconic representation of the caller or callee 🖼️ A user agent can show it informationally when a message comes in, or keep it around while a dialog is happening ✨ The value "alert" means the body part has something like an audio clip that the user agent should render to alert the user that a request came in, usually one that starts a dialog 🔔 For example, this could be the ringtone for a phone call after a 180 Ringing provisional response has been sent 📱
Any MIME body with a "disposition-type" that renders content to the user should only be processed when a message has been properly authenticated 🔒
The handling parameter, handling-param, tells the UAS how to react if it gets a message body with a content type or disposition type it doesn't understand 🤷♀️ It has two defined values, "optional" and "required". If the handling parameter is missing, the value "required" SHOULD be assumed. The handling parameter is described in RFC 3204 [19] 📖
If this header field is missing, the MIME type decides the default content disposition. If there isn't one, "render" is assumed 🌸
Example:
Content-Disposition: session20.12 Content-Encoding 🧁
The Content-Encoding header field is a modifier for the "media-type" ✨ When it's there, its value tells you which extra content codings were applied to the entity-body, and so which decoding mechanisms MUST be applied to get back the media-type named in the Content-Type header field 🔓 Content-Encoding is mainly there so a body can be compressed without losing the identity of its underlying media type 🗜️
If multiple encodings were applied to an entity-body, the content codings MUST be listed in the order they were applied 📝
All content-coding values are case-insensitive 🙌 IANA acts as the registry for content-coding value tokens. See [H3.5] for the syntax definition of content-coding 📚
Clients MAY apply content encodings to the body in requests 💖 A server MAY apply content encodings to the bodies in responses 🌈 But the server MUST only use encodings that are listed in the Accept-Encoding header field in the request 🙅♀️
The compact form of Content-Encoding is e 🍓
Examples:
Content-Encoding: gzip
e: tar20.13 Content-Language 🌍
See [H14.12]. Example:
Content-Language: fr20.14 Content-Length 📏
The Content-Length header field tells the recipient the size of the message-body, in decimal octets 🔢 Applications SHOULD use this field to indicate the size of the message-body being transferred, no matter what the media type of the entity is ✨ If a stream-based protocol (like TCP) is the transport, the header field MUST be used 🚂
The size of the message-body doesn't include the CRLF separating the header fields and the body. Any Content-Length greater than or equal to zero is a valid value 💅 If there's no body in a message, the Content-Length header field value MUST be set to zero 🫶
Being able to skip Content-Length makes it easier to write cgi-like scripts that generate responses on the fly. Iconic behaviour, honestly 🙌
The compact form of the header field is l 🎀
Examples:
Content-Length: 349
l: 17320.15 Content-Type 💌
The Content-Type header field says what media type the message-body is for the recipient 🎶 The "media-type" element is defined in [H3.7]. The Content-Type header field MUST be present if the body is not empty 📦 If the body is empty but a Content-Type header field is there anyway, it means that body of that specific type has zero length (like an empty audio file) 🫧
The compact form of the header field is c 🍓
Examples:
Content-Type: application/sdp
c: text/html; charset=ISO-8859-420.16 CSeq 🔢
A CSeq header field in a request has one decimal sequence number and the request method 💜 The sequence number MUST be expressible as a 32-bit unsigned integer 🔥 The method part of CSeq is case-sensitive 🙃 CSeq is what orders transactions within a dialog, gives you a way to uniquely identify transactions, and lets you tell new requests apart from retransmissions of old ones 🕵️♀️ Two CSeq header fields are equal if their sequence numbers and request methods are identical 👯♀️
Example:
CSeq: 4711 INVITE20.17 Date 🗓️
The Date header field has the date and time 🕰️ Unlike HTTP/1.1, SIP only supports the most recent RFC 1123 [20] format for dates. Like in [H3.3], SIP limits the time zone in SIP-date to "GMT", even though RFC 1123 allows any time zone. An RFC 1123 date is case-sensitive ✨
The Date header field reflects the time when the request or response is first sent 🌟
Simple end systems without a battery-backed clock can use the Date header field to get a sense of the current time. The catch is that in its GMT form, clients need to know their offset from GMT. Plot twist 🙈
Example:
Date: Sat, 13 Nov 2010 23:29:00 GMT20.18 Error-Info 🚨
The Error-Info header field points to more info about the error status response 🔍
SIP UACs come in all kinds of flavours, from pop-up windows and audio on PC softclients to audio-only "black" phones or endpoints connected through gateways 📱 Instead of making a server that's generating an error pick between a detailed reason phrase or playing an audio recording, Error-Info lets it send both. Then the UAC gets to choose which error indicator to show the caller 💅
A UAC MAY treat a SIP or SIPS URI in an Error-Info header field as if it were a Contact in a redirect, and generate a new INVITE. That means a recorded announcement session gets set up 🎙️ A non-SIP URI MAY be rendered to the user 🌈
Examples:
SIP/2.0 404 The number you have dialed is not in service
Error-Info: <sip:not-in-service-recording@atlanta.com>20.19 Expires ⏳
The Expires header field gives the relative time after which the message (or content) expires ⌛
What that means depends on the method ✨
The expiration time in an INVITE does NOT affect how long the actual session that might come out of it lasts 🙅♀️ Session description protocols can offer ways to set time limits on the session duration, though 🕐
The value is an integer number of seconds (in decimal) between 0 and (2**32)-1, counted from when the request is received 💫
Example:
Expires: 520.20 From 💌
The From header field says who started the request 📨 That might not be the same as whoever started the dialog. Requests the callee sends to the caller use the callee's address in the From header field 📞
The optional "display-name" is meant to be shown by a human user interface 👀 A system SHOULD use the display name "Anonymous" if the client's identity is supposed to stay hidden 🕶️ Even if the "display-name" is empty, the "name-addr" form MUST be used if the "addr-spec" contains a comma, question mark, or semicolon 🫣 Syntax issues are covered in Section 7.3.1 📚
Two From header fields are equivalent if their URIs match and their parameters match. Extension parameters that show up in one header field but not the other get ignored for comparison. So the display name and whether or not there are angle brackets don't affect matching 💖
See Section 20.10 for the rules on parsing a display name, URI, URI parameters, and header field parameters 🧠
The compact form of From is f 🍓
Examples:
From: "A. G. Bell" <sip:agb@bell-telephone.com> ;tag=a48s
From: sip:+12125551212@server.phone2net.com;tag=887s
f: Anonymous <sip:c8oqz84zk7z@privacy.org>;tag=hyh820.21 In-Reply-To 🔁
The In-Reply-To header field lists the Call-IDs that this call references or returns 📋 The client may have cached these Call-IDs and then put them in this header field on a return call 🔙
This lets automatic call distribution systems route return calls back to whoever originated the first call 🎯 It also lets callees filter calls, so only return calls for calls they started get accepted. Just a heads-up: this field is NOT a substitute for request authentication 🔐
Example:
In-Reply-To: 70710@saturn.bell-tel.com, 17320@saturn.bell-tel.com20.22. Max-Forwards 💖
okay so the Max-Forwards header field must be used with any SIP method 💅 It limits how many proxies or gateways can forward the request to the next downstream server. It's also super useful when the client is trying to trace a request chain that seems to be failing or looping midway through 🔍
The Max-Forwards value is an integer from 0 to 255 that tells you how many more times this request is allowed to be forwarded. Every server that forwards the request decrements the count ⬇️ The recommended initial value is 70 ✨
This header field should be inserted by elements that can not otherwise guarantee loop detection. A B2BUA, for example, should insert a Max-Forwards header field 🎀
Example:
Max-Forwards: 620.23. Min-Expires 🌸
The Min-Expires header field conveys the minimum refresh interval supported for soft-state elements managed by that server 🕰️ That includes Contact header fields that get stored by a registrar 📇 The header field holds a decimal integer number of seconds from 0 to (2**32)-1. The use of this header field in a 423 (Interval Too Brief) response is described in Sections 10.2.8, 10.3, and 21.4.17 🙈
Example:
Min-Expires: 6020.24. MIME-Version 🧚
See [H19.4.1].
Example:
MIME-Version: 1.020.25. Organization 🦋
The Organization header field conveys the name of the organization that the SIP element issuing the request or response belongs to 🏢
The field MAY be used by client software to filter calls 📵
Example:
Organization: Boxes by Bob20.26. Priority 👑
The Priority header field indicates the urgency of the request as perceived by the client 🚨 It describes the priority the SIP request should have to the receiving human or their agent. For example, it may be factored into decisions about call routing and acceptance 📞 For these decisions, a message containing no Priority header field SHOULD be treated as if it specified a Priority of "normal". The Priority header field does not influence the use of communications resources, like packet forwarding priority in routers or access to circuits in PSTN gateways 🚫 The header field can have the values "non-urgent", "normal", "urgent", and "emergency", but additional values can be defined elsewhere 💜 It is RECOMMENDED that the value of "emergency" only be used when life, limb, or property are in imminent danger 🚑 Otherwise, there are no semantics defined for this header field.
These are the values of RFC 2076 [38], with the addition of "emergency".
Examples:
Subject: A tornado is heading our way!
Priority: emergencyor
Subject: Weekend plans
Priority: non-urgent20.27. Proxy-Authenticate 🔐
A Proxy-Authenticate header field value contains an authentication challenge 🍓
The use of this header field is defined in [H14.33]. See Section 22.3 for further details on its usage.
Example:
Proxy-Authenticate: Digest realm="atlanta.com",
domain="sip:ss1.carrier.com", qop="auth",
nonce="f84f1cec41e6cbe5aea9c8e88d359",
opaque="", stale=FALSE, algorithm=MD520.28. Proxy-Authorization 🗝️
The Proxy-Authorization header field allows the client to identify itself (or its user) to a proxy that requires authentication 🫶 A Proxy-Authorization field value consists of credentials containing the authentication information of the user agent for the proxy and/or realm of the resource being requested.
See Section 22.3 for a definition of the usage of this header field.
This header field, along with Authorization, breaks the general rules about multiple header field names 🙃 Although it's not a comma-separated list, this header field name may be present multiple times, and it MUST NOT be combined into a single header line using the usual rules described in Section 7.3.1. Main character energy 👑
Example:
Proxy-Authorization: Digest username="Alice", realm="atlanta.com",
nonce="c60f3082ee1212b402a21831ae",
response="245f23415f11432b3434341c022"20.29. Proxy-Require 🧱
The Proxy-Require header field is used to indicate proxy-sensitive features that must be supported by the proxy. See Section 20.32 for more details on the mechanics of this message and a usage example 📖
Example:
Proxy-Require: foo20.30. Record-Route 🛣️
The Record-Route header field is inserted by proxies in a request to force future requests in the dialog to be routed through the proxy 🔁
Examples of its use with the Route header field are described in Sections 16.12.1.
Example:
Record-Route: <sip:server10.biloxi.com;lr>,
<sip:bigbox3.site3.atlanta.com;lr>20.31. Reply-To 💌
The Reply-To header field contains a logical return URI that may be different from the From header field 📬 For example, the URI MAY be used to return missed calls or unestablished sessions. If the user wished to remain anonymous, the header field SHOULD either be omitted from the request or populated in a way that does not reveal any private information 🙈
Even if the "display-name" is empty, the "name-addr" form MUST be used if the "addr-spec" contains a comma, question mark, or semicolon. Syntax issues are discussed in Section 7.3.1 🤓
Example:
Reply-To: Bob <sip:bob@biloxi.com>20.32. Require 📜
The Require header field is how UACs tell UASs about options that the UAC expects the UAS to support in order to process the request 🫡 Although it's an optional header field, the Require MUST NOT be ignored if it is present. Obviously, we don't ignore it 💀
The Require header field contains a list of option tags, described in Section 19.2. Each option tag defines a SIP extension that MUST be understood to process the request. Frequently, this is used to indicate that a specific set of extension header fields need to be understood. A UAC compliant to this specification MUST only include option tags corresponding to standards-track RFCs ✨
Example:
Require: 100rel20.33. Retry-After ⏳
The Retry-After header field can be used with a 500 (Server Internal Error) or 503 (Service Unavailable) response to indicate how long the service is expected to be unavailable to the requesting client. It can also be used with a 404 (Not Found), 413 (Request Entity Too Large), 480 (Temporarily Unavailable), 486 (Busy Here), 600 (Busy), or 603 (Decline) response to indicate when the called party anticipates being available again 📅 The value of this field is a positive integer number of seconds (in decimal) after the time of the response.
An optional comment can be used to indicate additional information about the time of callback 💬 An optional "duration" parameter indicates how long the called party will be reachable starting at the initial time of availability. If no duration parameter is given, the service is assumed to be available indefinitely 🌈
Examples:
Retry-After: 18000;duration=3600
Retry-After: 120 (I'm in a meeting)20.34. Route 🗺️
The Route header field is used to force routing for a request through the listed set of proxies 🚦 Examples of the use of the Route header field are in Section 16.12.1.
Example:
Route: <sip:bigbox3.site3.atlanta.com;lr>,
<sip:server10.biloxi.com;lr>20.35. Server 🖥️
The Server header field contains information about the software the UAS uses to handle the request 🤖
Revealing the specific software version of the server might make the server more vulnerable to attacks against software that is known to contain security holes 😭 Implementers SHOULD make the Server header field a configurable option 🔧
Example:
Server: HomeServer v220.36. Subject 📝
The Subject header field provides a summary or indicates the nature of the call, which allows call filtering without having to parse the session description 📵 The session description does not have to use the same subject indication as the invitation.
The compact form of the Subject header field is s.
Example:
Subject: Need more boxes
s: Tech Support20.37. Supported 🙌
The Supported header field enumerates all the extensions supported by the UAC or UAS 🌟
The Supported header field contains a list of option tags, described in Section 19.2, that are understood by the UAC or UAS. A UA compliant to this specification MUST only include option tags corresponding to standards-track RFCs. If empty, it means that no extensions are supported 🫥
The compact form of the Supported header field is k.
Example:
Supported: 100rel20.38. Timestamp ⏱️
The Timestamp header field describes when the UAC sent the request to the UAS 🕒
See Section 8.2.6 for details on how to generate a response to a request that contains the header field. Although there is no normative behavior defined here that makes use of the header, it allows extensions or SIP applications to obtain RTT estimates 📶
Example:
Timestamp: 5420.39. To 🎯
The To header field specifies the logical recipient of the request 💌
The optional "display-name" is meant to be rendered by a human-user interface. The "tag" parameter serves as a general mechanism for dialog identification 🪪
See Section 19.3 for details of the "tag" parameter.
Comparison of To header fields for equality is identical to comparison of From header fields. See Section 20.10 for the rules for parsing a display name, URI and URI parameters, and header field parameters 🧐
The compact form of the To header field is t.
The following are examples of valid To header fields:
To: The Operator <sip:operator@cs.columbia.edu>;tag=287447
t: sip:+12125551212@server.phone2net.com20.40. Unsupported 🚫
The Unsupported header field lists the features not supported by the UAS. See Section 20.32 for motivation 💅
Example:
Unsupported: foo20.41. User-Agent 🪄
The User-Agent header field contains information about the UAC that originated the request. The semantics of this header field are defined in [H14.43] 🧾
Revealing the specific software version of the user agent might make the user agent more vulnerable to attacks against software that is known to contain security holes 😱 Implementers SHOULD make the User-Agent header field a configurable option 🔧
Example:
User-Agent: Softphone Beta1.520.42. Via 🛤️
The Via header field indicates the path taken by the request so far, and it indicates the path that should be followed in routing responses 🧭 The branch ID parameter in the Via header field values serves as a transaction identifier, and proxies use it to detect loops 🔁
A Via header field value contains the transport protocol used to send the message, the client's host name or network address, and possibly the port number at which it wishes to receive responses. A Via header field value can also contain parameters such as "maddr", "ttl", "received", and "branch", whose meaning and use are described in other sections. For implementations compliant to this specification, the value of the branch parameter MUST start with the magic cookie "z9hG4bK", as discussed in Section 8.1.1.7 ✨
Transport protocols defined here are "UDP", "TCP", "TLS", and "SCTP". "TLS" means TLS over TCP. When a request is sent to a SIPS URI, the protocol still indicates "SIP", and the transport protocol is TLS 🔐
Via: SIP/2.0/UDP erlang.bell-telephone.com:5060;branch=z9hG4bK87asdks7The compact form of the Via header field is v. 💅
Here's the Via example from the original, with its received parameter, which gets added when a hop notices the packet came from a different address than the one it was sent to:
Via: SIP/2.0/UDP 192.0.2.1:5060 ;received=192.0.2.207
;branch=z9hG4bK77asjdSo picture a multi-homed host with two addresses, 192.0.2.1 and 192.0.2.207. 🙈 The sender guessed wrong about which network interface would be used. Erlang.bell-telephone.com noticed the mismatch and added a parameter to the previous hop's Via header field value, containing the address the packet actually came from. Detective energy, no cap. 🕵️♀️✨
The host or network address and port number don't have to follow the SIP URI syntax. Specifically, LWS on either side of the ":" or "/" is allowed, as shown here:
Via: SIP / 2.0 / UDP first.example.com: 4000;ttl=16
;maddr=224.2.0.1 ;branch=z9hG4bKa7c6a8dlze.1Okay, this next bit is my favourite. 🦋 Even though this specification mandates that the branch parameter be present in all requests, the BNF for the header field says it's optional. That's so older RFC 2543 elements can still interoperate, because they didn't have to insert the branch parameter. Being backwards compatible is literally iconic. 👑
Two Via header fields are equal if their sent-protocol and sent-by fields are equal, both have the same set of parameters, and the values of all parameters are equal. Full identity check, bestie. 💜
20.43 Warning
The Warning header field carries extra info about the status of a response. 📣 Warning header field values get sent with responses, and each one has a three-digit warning code, a host name, and warning text.
The "warn-text" should be in a natural language that's most likely to be understood by the human user receiving the response. You can base that on whatever you know, like where the user is, the Accept-Language field in a request, or the Content-Language field in a response. The default language is i-default [21]. 🌈
Here are the currently-defined "warn-code"s, with a recommended warn-text in English and what each one means. These warnings describe failures caused by the session description. Warning codes starting with "3" are SIP-specific. 300 through 329 are for problems with keywords in the session description, 330 through 339 are for basic network services requested in it, 370 through 379 are for quantitative QoS parameters requested in it, and 390 through 399 are miscellaneous warnings that don't fit those categories. 🎀
300 Incompatible network protocol: One or more network protocols
contained in the session description are not available.
301 Incompatible network address formats: One or more network
address formats contained in the session description are not
available.
302 Incompatible transport protocol: One or more transport
protocols described in the session description are not
available.
303 Incompatible bandwidth units: One or more bandwidth
measurement units contained in the session description were
not understood.
304 Media type not available: One or more media types contained in
the session description are not available.
305 Incompatible media format: One or more media formats contained
in the session description are not available.
306 Attribute not understood: One or more of the media attributes
in the session description are not supported.
307 Session description parameter not understood: A parameter
other than those listed above was not understood.
330 Multicast not available: The site where the user is located
does not support multicast.
331 Unicast not available: The site where the user is located does
not support unicast communication (usually due to the presence
of a firewall).
370 Insufficient bandwidth: The bandwidth specified in the session
description or defined by the media exceeds that known to be
available.
399 Miscellaneous warning: The warning text can include arbitrary
information to be presented to a human user or logged. A
system receiving this warning MUST NOT take any automated
action.
1xx and 2xx have been taken by HTTP/1.1.399 is the one to watch. A system that gets this warning MUST NOT take any automated action. It's for humans and logs only, so don't let your code go off doing stuff on its own. 🚫💀
Additional "warn-code"s can be defined through IANA, as described in Section 27.2. 🧚
Examples:
Warning: 307 isi.edu "Session parameter 'foo' not understood"
Warning: 301 isi.edu "Incompatible network address type 'E.164'"20.44 WWW-Authenticate
A WWW-Authenticate header field value carries an authentication challenge. For more on how it's used, see Section 22.2. 🔐
Example:
WWW-Authenticate: Digest realm="atlanta.com",
domain="sip:boxesbybob.com", qop="auth",
nonce="f84f1cec41e6cbe5aea9c8e88d359",
opaque="", stale=FALSE, algorithm=MD521 Response Codes
The response codes are consistent with HTTP/1.1 response codes, and they extend them. 🌸 Not every HTTP/1.1 response code is appropriate, so only the ones that are appropriate are listed here. Other HTTP/1.1 response codes SHOULD NOT be used. SIP also defines a brand new class, 6xx. ✨
21.1 Provisional 1xx
Provisional responses, also called informational responses, tell you the contacted server is doing more work and doesn't have a final answer yet. A server sends a 1xx response if it expects to take more than 200 ms to get a final response. Heads up: 1xx responses aren't transmitted reliably. They never make the client send an ACK. 🙃 Provisional (1xx) responses MAY contain message bodies, including session descriptions. 🎶
21.1.1 100 Trying
This response means the next-hop server got the request and is doing some unspecified action for this call, like checking a database. Like every other provisional response, it stops INVITE retransmissions by a UAC. The 100 (Trying) response is different from the others because a stateful proxy never forwards it upstream. 🫶
21.1.2 180 Ringing
The UA that got the INVITE is trying to alert the user. This response MAY be used to start local ringback. 📞
21.1.3 181 Call Is Being Forwarded
A server MAY use this status code to say the call is being forwarded to a different set of destinations. ➡️
21.1.4 182 Queued
The called party is temporarily unavailable, but the server decided to queue the call instead of rejecting it. When the callee becomes available, it returns the appropriate final status response. The reason phrase MAY give more details about the call status, for example, "5 calls queued; expected waiting time is 15 minutes". The server MAY issue several 182 (Queued) responses to keep the caller updated about the queued call. Waiting room era. ⏳
21.1.5 183 Session Progress
The 183 (Session Progress) response conveys information about call progress that doesn't fit anywhere else. The Reason-Phrase, header fields, or message body MAY be used to share more details about the call progress. 🎟️
21.2 Successful 2xx
The request was successful. 🥳
21.2.1 200 OK
The request has succeeded. What comes back depends on the method that was used in the request. ✅
21.3 Redirection 3xx
3xx responses tell you the user's new location, or point you to alternative services that might be able to handle the call. 🗺️
21.3.1 300 Multiple Choices
The address in the request resolved to several choices, each with its own specific location. The user (or UA) can pick a preferred communication end point and redirect the request there. 💁♀️
The response MAY include a message body with a list of resource characteristics and locations the user or UA can choose from, if the Accept request header field allows it. However, no MIME types have been defined for this message body. 📋
The choices SHOULD also be listed as Contact fields (Section 20.10). Unlike HTTP, the SIP response MAY contain several Contact fields or a list of addresses in a Contact field. UAs MAY use the Contact header field value for automatic redirection, or MAY ask the user to confirm a choice. This specification doesn't define any standard for that automatic selection, though. 🤷♀️
This status response fits when the callee can be reached at several different locations and the server can't, or prefers not to, proxy the request. 🌟
21.3.2 301 Moved Permanently
The user can no longer be found at the address in the Request-URI, so the requesting client SHOULD retry at the new address given by the Contact header field (Section 20.10). The requestor SHOULD update any local directories, address books, and user location caches with this new value, and redirect future requests to the address(es) listed. Glow-up for your contacts list. 📒💖
21.3.3 302 Moved Temporarily
The requesting client SHOULD retry the request at the new address(es) given by the Contact header field (Section 20.10). The Request-URI of the new request uses the value of the Contact header field in the response. 🔁
The Contact URI's validity duration can be shown through an Expires (Section 20.19) header field or an expires parameter in the Contact header field. Both proxies and UAs MAY cache this URI for the length of the expiration time. If there's no explicit expiration time, the address is only valid for one recursion, and it MUST NOT be cached for future transactions. Don't save it forever, babe. ⏰
If the URI cached from the Contact header field fails, the Request-URI from the redirected request MAY be tried again a single time. 🔄
The temporary URI may have gone out-of-date sooner than the expiration time, and a new temporary URI may be available. Plan for plot twists. 🎭
21.3.4 305 Use Proxy
The requested resource MUST be accessed through the proxy given by the Contact field. The Contact field gives the URI of the proxy. The recipient is expected to repeat this single request via the proxy. 305 (Use Proxy) responses MUST only be generated by UASs. Only the UAS gets to send this one, so no freelancing. 🚪
21.3.5 380 Alternative Service
The call wasn't successful, but alternative services are possible. 🛍️
The alternative services are described in the message body of the response. Formats for those bodies aren't defined here, and they may be the subject of future standardization. The future is unwritten, besties. 🔮
21.4 Request Failure 4xx
4xx responses are definite failure responses from one particular server. 🚫 The client SHOULD NOT retry the same request without modification (for example, adding appropriate authorization). However, the same request sent to a different server might work. Switch it up, not the whole plan. 🌈
21.4.1 400 Bad Request
The request couldn't be understood because the syntax is malformed. The Reason-Phrase SHOULD identify the syntax problem in more detail, for example, "Missing Call-ID header field". Be specific, it's giving clarity. 🧐
21.4.2 401 Unauthorized
The request needs user authentication. This response comes from UASs and registrars, while 407 (Proxy Authentication Required) is used by proxy servers. Who's asking matters. 🔑
21.4.3 402 Payment Required
Reserved for future use. 💳
21.4.4 403 Forbidden
The server understood the request, but it's refusing to fulfill it. Authorization won't help, and the request SHOULD NOT be repeated. Not it. 🙅♀️💀
21.4.5 404 Not Found
The server has definitive information that the user doesn't exist at the domain in the Request-URI. This status also comes back if the domain in the Request-URI doesn't match any of the domains the recipient handles. Wrong neighbourhood, babe. 🏠✨
21.4.6 405 Method Not Allowed 🙅♀️
okay so the server understood the method in the Request-Line, like it knows what you're asking for, but that method is not allowed for the address in the Request-URI 💅
the response MUST include an Allow header field listing the valid methods for that address 🎀
21.4.7 406 Not Acceptable 🙈
the resource named in the request can only generate response bodies with content characteristics that don't match what the Accept header field in the request says it will take 💀
21.4.8 407 Proxy Authentication Required 🔐
this one is basically a cousin of 401 (Unauthorized), but the twist is the client MUST authenticate itself with the proxy first 🫶 SIP access authentication is explained in Sections 26 and 22.3, so go check those if you want the full story ✨
this code can also be used when the thing that needs guarding is the communication channel itself (like a telephony gateway) instead of the callee 📞
21.4.9 408 Request Timeout ⏰
the server couldn't come up with a response in a reasonable amount of time, for example if it couldn't figure out where the user is in time ⌛ the client MAY repeat the request without any changes at any later time 🦋
21.4.10 410 Gone 👻
the requested resource isn't available on the server anymore, and no forwarding address is known 💔 this is supposed to be permanent. if the server doesn't know (or has no way to figure out) whether it's permanent, the status code 404 (Not Found) SHOULD be used instead 🌸
21.4.11 413 Request Entity Too Large 🍓
the server is refusing to process the request because the request body is bigger than what it's willing or able to handle 🙅♀️ the server MAY close the connection so the client can't keep going with the request 🔌
if the problem is temporary, the server SHOULD include a Retry-After header field to say it's temporary and after how long the client MAY try again ⏳
21.4.12 414 Request-URI Too Long 🧵
the server won't service the request because the Request-URI is longer than the server is willing to interpret. too long, bestie 😭
21.4.13 415 Unsupported Media Type 🎶
the server is refusing the request because the message body is in a format it doesn't support for that method. the server MUST return a list of acceptable formats using the Accept, Accept-Encoding, or Accept-Language header field, depending on what the actual problem is 🧾 UAC processing of this response is described in Section 8.1.3.5 📖
21.4.14 416 Unsupported URI Scheme 🔗
the server can't process the request because the scheme of the URI in the Request-URI is unknown to it 🤷♀️ client processing of this response is described in Section 8.1.3.5 💅
21.4.15 420 Bad Extension 🧩
the server didn't understand a protocol extension named in a Proxy-Require (Section 20.29) or Require (Section 20.32) header field 🥺 the server MUST include a list of the unsupported extensions in an Unsupported header field in the response 📝 UAC processing of this response is described in Section 8.1.3.5 ✨
21.4.16 421 Extension Required 🔧
the UAS needs a particular extension to process the request, but that extension isn't listed in a Supported header field in the request 😤 responses with this status code MUST contain a Require header field listing the required extensions 💜
a UAS SHOULD NOT use this response unless it truly can't provide any useful service to the client 🙅♀️ instead, if a nice extension isn't listed in the Supported header field, servers SHOULD process the request using baseline SIP capabilities plus whatever extensions the client does support 🫶
21.4.17 423 Interval Too Brief ⏱️
the server is rejecting the request because the expiration time of the resource being refreshed is way too short 🙃 this response can be used by a registrar to reject a registration whose Contact header field expiration time was too small 📇 the use of this response and the related Min-Expires header field are described in Sections 10.2.8, 10.3, and 20.23 📚
21.4.18 480 Temporarily Unavailable 📵
the callee's end system was reached successfully, but the callee is currently unavailable. maybe they're not logged in, or they're logged in but in a state that blocks communication, or they turned on "do not disturb" 🌙 the response MAY indicate a better time to call in the Retry-After header field ⏰ the user could also be available elsewhere (which this server might not know about) 🌍
the reason phrase SHOULD give a more precise cause for why the callee is unavailable, and this value SHOULD be settable by the UA 🛠️ status 486 (Busy Here) MAY be used to be more specific about a particular reason for the call failure 📞
this status is also returned by a redirect or proxy server that recognizes the user in the Request-URI but doesn't currently have a valid forwarding location for them 🗺️
21.4.19 481 Call/Transaction Does Not Exist 🫥
this status means the UAS got a request that doesn't match any existing dialog or transaction. like, where are you even coming from? 🤨
21.4.20 482 Loop Detected 🔁
the server has detected a loop (Section 16.3 Item 4). we're going in circles and that's not it 🌀
21.4.21 483 Too Many Hops 🏃♀️
the server got a request with a Max-Forwards (Section 20.22) header field whose value is zero. no more hops left, sorry bestie 🛑
21.4.22 484 Address Incomplete ✂️
the server got a request with a Request-URI that was incomplete. additional information SHOULD be provided in the reason phrase 📝
this status code allows overlapped dialing. with overlapped dialing, the client doesn't know how long the dialing string is going to be. it sends strings of increasing length, prompting the user for more input, until it stops getting a 484 (Address Incomplete) status response. so basically it's like typing a phone number one digit at a time until it finally works 📱💖
21.4.23 485 Ambiguous 👯♀️
the Request-URI was ambiguous. the response MAY contain a list of possible unambiguous addresses in Contact header fields 📋 revealing alternatives can infringe on the privacy of the user or the organization, so be careful 🔒 it MUST be possible to configure a server to respond with status 404 (Not Found), or to suppress the list of possible choices for ambiguous Request-URIs 🙊
example response to a request with the Request-URI sip:lee@example.com:
SIP/2.0 485 Ambiguous
Contact: Carol Lee <sip:carol.lee@example.com>
Contact: Ping Lee <sip:p.lee@example.com>
Contact: Lee M. Foote <sips:lee.foote@example.com>some email and voicemail systems have this feature 📬 a separate status code from 3xx is used because the meaning is different. for 300, it's assumed the same person or service will be reached by every choice. an automated choice or a sequential search makes sense for a 3xx response, but a 485 (Ambiguous) response needs a human to pick 🧑🤝🧑✨
21.4.24 486 Busy Here 📞🚫
the callee's end system was reached successfully, but the callee isn't willing or able to take more calls at this end system right now 😮💨 the response MAY indicate a better time to call in the Retry-After header field ⏰ the user could also be available elsewhere, like through a voicemail service 📼 status 600 (Busy Everywhere) SHOULD be used if the client knows that no other end system will be able to accept this call 🌍
21.4.25 487 Request Terminated 🛑
the request was ended by a BYE or CANCEL request. this response is never returned for a CANCEL request itself 🙃
21.4.26 488 Not Acceptable Here 🙅♀️
this has the same meaning as 606 (Not Acceptable), but it only applies to the specific resource addressed by the Request-URI, so the request might succeed somewhere else 🗺️ a message body describing media capabilities MAY be present in the response. it's formatted according to the Accept header field in the INVITE (or application/sdp if there isn't one), same as a message body in a 200 (OK) response to an OPTIONS request 🎧
21.4.27 491 Request Pending ⏳
the request was received by a UAS that had a pending request within the same dialog. Section 14.2 describes how these "glare" situations get resolved 🥊
21.4.28 493 Undecipherable 🔐
the request was received by a UAS that contained an encrypted MIME body, and the recipient either doesn't have the right decryption key or won't provide it 🗝️ this response MAY have a single body containing a public key that should be used to encrypt MIME bodies sent to this UA. details about using this response code can be found in Section 23.2 📖
21.5 Server Failure 5xx 💥
5xx responses are failure responses given when a server itself has erred 🫠
21.5.1 500 Server Internal Error 🧯
the server ran into an unexpected condition that stopped it from fulfilling the request 😵 the client MAY display the specific error condition and MAY retry the request after several seconds 🔁
if the condition is temporary, the server MAY indicate when the client can retry the request, using the Retry-After header field ⏳
21.5.2 501 Not Implemented 🚧
the server doesn't support the functionality needed to fulfill the request. this is the right response when a UAS doesn't recognize the request method and can't support it for any user 🙅♀️ (proxies forward all requests regardless of method, so they don't send this one 🔀)
note that a 405 (Method Not Allowed) is sent when the server recognizes the request method, but that method isn't allowed or supported 💅
21.5.3 502 Bad Gateway 🌉
the server, while acting as a gateway or proxy, got an invalid response from the downstream server it accessed while trying to fulfill the request 🫠
21.5.4 503 Service Unavailable 🚦
the server is temporarily unable to process the request because it's overloaded or under maintenance 🛠️ the server MAY indicate when the client should retry the request in a Retry-After header field ⏰ if no Retry-After is given, the client MUST act as if it had received a 500 (Server Internal Error) response 🧯
a client (proxy or UAC) that gets a 503 (Service Unavailable) SHOULD try to forward the request to an alternate server 🏃♀️ it SHOULD NOT forward any other requests to that server for the duration given in the Retry-After header field, if one is present ⏸️
servers MAY refuse the connection or drop the request instead of responding with 503 (Service Unavailable) 👋
21.5.5 504 Server Time-out ⌛
the server didn't get a timely response from an external server it accessed while trying to process the request. 408 (Request Timeout) should be used instead if there was no response within the period specified in the Expires header field from the upstream server 🕰️
21.5.6 505 Version Not Supported 🆚
the server doesn't support, or refuses to support, the SIP protocol version used in the request. it's saying it can't or won't finish the request using the same major version as the client, other than with this error message 🙅♀️📜
21.5.7 513 Message Too Large 📦
the server couldn't process the request because the message length was over its capabilities 😩
21.6 Global Failures 6xx 🌍
6xx responses mean the server has definitive information about a particular user, not just the particular instance named in the Request-URI 👑
21.6.1 600 Busy Everywhere 📞
okay so the callee's end system got reached just fine 📱✨ but the callee is busy and doesn't want to take the call right now 😭 The response MAY tell the caller a better time to try again using the Retry-After header field 🕰️💖 If the callee doesn't want to say why they're declining, they use status code 603 (Decline) instead 🙈 This one only gets sent if the client knows no other end point, like a voice mail system, will answer the request. Otherwise, 486 (Busy Here) should be returned 💅
21.6.2 603 Decline 🙅♀️
the callee's machine got contacted successfully, but the user really doesn't want to participate (or literally can't) 🫠 The response MAY suggest a better time to call using the Retry-After header field 🌸 This status response is only returned if the client knows that no other end point will answer the request 🔐
21.6.3 604 Does Not Exist Anywhere 👻
the server has authoritative information that the user named in the Request-URI doesn't exist anywhere, like not even a little bit 💀
21.6.4 606 Not Acceptable 🙅
the user's agent got reached, but some parts of the session description weren't acceptable, like the requested media, bandwidth, or addressing style 🎀
a 606 (Not Acceptable) response basically means "I want to talk to you, but I can't really support the session you described" 🥺 The 606 (Not Acceptable) response MAY include a list of reasons in a Warning header field explaining why the session can't be supported. The Warning reason codes are listed in Section 20.43 🧾
a message body describing media capabilities MAY also be present in the response. It's formatted according to the Accept header field in the INVITE (or application/sdp if there isn't one), the same as a message body in a 200 (OK) response to an OPTIONS request 🎶
it's hoped that negotiation won't come up very often 🤞 And when a new user is being invited to join a conference that already exists, negotiation might not even be possible 😭 It's up to the invitation initiator to decide whether or not to act on a 606 (Not Acceptable) response 👑
this status response is only returned if the client knows that no other end point will answer the request 🫶
22 Usage of HTTP Authentication 🔐✨
SIP has a stateless, challenge-based way to do authentication, and it's based on the one in HTTP 💜 Any time a proxy server or UA gets a request (except for the cases in Section 22.1), it MAY challenge the request's initiator to prove who they are 🪪 Once the originator has been identified, the recipient SHOULD figure out whether this user is actually allowed to make that request 👀 No authorization systems are recommended or discussed in this document, so that's a whole other vibe 🙈
the "Digest" authentication mechanism described in this section gives you message authentication and replay protection, but NOT message integrity or confidentiality 😬 That means extra protections beyond what Digest provides need to be put in place to stop active attackers from changing SIP requests and responses 🚨
Note that because of its weak security, the "Basic" authentication scheme has been deprecated 💀 Servers MUST NOT accept credentials using the "Basic" authorization scheme, and servers also MUST NOT challenge with "Basic". This is a change from RFC 2543 🫠
22.1 Framework 🧩
the framework for SIP authentication is pretty much a copy of HTTP's (RFC 2617 [17]) 🪞 In particular, the BNF for auth-scheme, auth-param, challenge, realm, realm-value, and credentials is identical, though "Basic" isn't allowed as a scheme 🙅♀️ In SIP, a UAS uses the 401 (Unauthorized) response to challenge a UAC's identity ✨ Registrars and redirect servers MAY also use 401 (Unauthorized) responses for authentication, but proxies MUST NOT, and instead they MAY use the 407 (Proxy Authentication Required) response 🎀 The rules for including Proxy-Authenticate, Proxy-Authorization, WWW-Authenticate, and Authorization in the various messages are identical to the ones in RFC 2617 [17] 💅
since SIP doesn't have the idea of a canonical root URL, the notion of protection spaces works differently here 🌈 The realm string alone defines the protection domain. This is a change from RFC 2543, where the Request-URI and the realm together defined the protection domain 🦋
This old definition of protection domain was kind of confusing 😵💫 The Request-URI sent by the UAC and the Request-URI received by the challenging server might be different, and the final form of the Request-URI might not even be known to the UAC 🙃 The old definition also depended on there being a SIP URI in the Request-URI, and it seemed to rule out other URI schemes (like the tel URL) 📱
operators of user agents or proxy servers that will authenticate received requests MUST follow these guidelines when making a realm string for their server 📋
- Realm strings MUST be globally unique. It is RECOMMENDED that a realm string contain a hostname or domain name, following the recommendation in Section 3.2.1 of RFC 2617 [17] 🌍
- Realm strings SHOULD present a human-readable identifier that can be rendered to a user 👩💻
for example:
INVITE sip:bob@biloxi.com SIP/2.0
Authorization: Digest realm="biloxi.com", <...>SIP authentication is meaningful for a specific realm, which is a protection domain 🏰 So for Digest authentication, each protection domain has its own set of usernames and passwords 🔑 If a server doesn't require authentication for a particular request, it MAY accept a default username, "anonymous", which has no password (a password of "") 🫥 Similarly, UACs representing lots of users, like PSTN gateways, MAY have their own device-specific username and password for their realm, instead of accounts for particular users 📞✨
a server can legitimately challenge most SIP requests, but there are two requests defined by this document that need special authentication handling: ACK and CANCEL 👀
under an authentication scheme that uses responses to carry values used to compute nonces (like Digest), some problems come up for any requests that don't get a response, including ACK 🧐 For this reason, any credentials in the INVITE that a server accepted MUST be accepted by that same server for the ACK. UACs creating an ACK message will duplicate all of the Authorization and Proxy-Authorization header field values that appeared in the INVITE the ACK corresponds to 💖 Servers MUST NOT attempt to challenge an ACK 🙅♀️
even though the CANCEL method does get a response (a 2xx), servers MUST NOT attempt to challenge CANCEL requests, since these requests can't be resubmitted 🚫 Generally, a CANCEL request SHOULD be accepted by a server if it comes from the same hop that sent the request being canceled (provided that some sort of transport or network layer security association, as described in Section 26.2.1, is in place) 🔐
when a UAC gets a challenge, it SHOULD show the user the contents of the "realm" parameter in the challenge (which shows up in either a WWW-Authenticate header field or a Proxy-Authenticate header field) if the UAC device doesn't already know of a credential for that realm 📣 A service provider that pre-configures UAs with credentials for its realm should be aware that users won't get the chance to present their own credentials for this realm when challenged at a pre-configured device 🧑🔧
finally, even if a UAC can find credentials tied to the right realm, those credentials might no longer be valid, or the challenging server might not accept them for whatever reason (especially when "anonymous" with no password gets submitted) 😬 In this case, a server may repeat its challenge, or it may respond with a 403 Forbidden 🚷 A UAC MUST NOT re-attempt requests with the credentials that were just rejected (though the request may be retried if the nonce was stale) 🙏
22.2 User-to-User Authentication 🤝
when a UAS gets a request from a UAC, the UAS MAY authenticate the originator before processing the request 🛡️ If no credentials (in the Authorization header field) come with the request, the UAS can challenge the originator to provide credentials by rejecting the request with a 401 (Unauthorized) status code 💅
the WWW-Authenticate response-header field MUST be included in 401 (Unauthorized) response messages 📜 Its value has at least one challenge that tells you the authentication scheme(s) and parameters that apply to the realm ✨
here's an example of the WWW-Authenticate header field in a 401 challenge 👇
WWW-Authenticate: Digest
realm="biloxi.com",
qop="auth,auth-int",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
opaque="5ccc069c403ebaf9f0171e9517f40e41"when the originating UAC gets the 401 (Unauthorized), it SHOULD, if it's able to, re-send the request with the proper credentials 🔁 The UAC may need input from the originating user before going ahead 🙋♀️ Once credentials have been supplied (either directly by the user or found in an internal keyring), UAs SHOULD cache the credentials for a given value of the To header field and "realm", and try to reuse those values on the next request for that destination 🗝️ UAs MAY cache credentials in any way they like 💜
if no credentials for a realm can be located, UACs MAY try the request again with a username of "anonymous" and no password (a password of "") 🫥
once credentials have been located, any UA that wants to authenticate itself with a UAS or registrar (usually, but not necessarily, after getting a 401 (Unauthorized) response) MAY do so by including an Authorization header field with the request ✨ The Authorization field value holds credentials with the UA's authentication information for the realm of the resource being requested, plus the parameters needed for authentication and replay protection 🎀
here's an example of the Authorization header field 👇
Authorization: Digest username="bob",
realm="biloxi.com",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
uri="sip:bob@biloxi.com",
qop=auth,
nc=00000001,
cnonce="0a4f113b",
response="6629fae49393a05397450978507c4ef1",
opaque="5ccc069c403ebaf9f0171e9517f40e41"when a UAC resubmits a request with its credentials after getting a 401 (Unauthorized) or 407 (Proxy Authentication Required) response, it MUST increment the CSeq header field value the same way it normally would when sending an updated request 🔢💖
22.3. Proxy-to-User Authentication ✨
okay so this is the same vibe as before, except now the UAC is sending its request to a proxy 🧚. The proxy server MAY authenticate the originator before it processes the request. If there are no credentials in the Proxy-Authorization header field, the proxy can challenge the originator to provide them by rejecting the request with a 407 (Proxy Authentication Required) status code 💅. The proxy MUST fill the 407 (Proxy Authentication Required) message with a Proxy-Authenticate header field value that applies to the proxy for the requested resource.
The Proxy-Authenticate and Proxy-Authorization headers basically work like what's described in [17], with one difference 🫶. Proxies MUST NOT add values to the Proxy-Authorization header field. Every 407 (Proxy Authentication Required) response MUST be forwarded upstream toward the UAC, following the same procedures as any other response. The UAC is the one responsible for adding a Proxy-Authorization header field value with credentials for the realm of the proxy that asked for authentication.
If a proxy were to resubmit a request adding a Proxy-Authorization header field value, it would need to increment the CSeq in the new request. However, this would cause the UAC that submitted the original request to discard a response from the UAS, as the CSeq value would be different.
When the originating UAC gets the 407 (Proxy Authentication Required), it SHOULD, if it's able, re-originate the request with the proper credentials. It should follow the same procedures for showing the "realm" parameter that were given above for responding to 401. 🌸
If no credentials for a realm can be found, UACs MAY try retrying the request with a username of "anonymous" and no password (a password of ""). 🙈
The UAC SHOULD also cache the credentials it used in the re-originated request. 💜
The following rule is RECOMMENDED for proxy credential caching:
If a UA gets a Proxy-Authenticate header field value in a 401/407 response to a request with a particular Call-ID, it should include credentials for that realm in all later requests that have the same Call-ID. These credentials MUST NOT be cached across dialogs. However, if a UA is configured with the realm of its local outbound proxy (when one exists), the UA MAY cache credentials for that realm across dialogs. Just a heads up, this does mean a future request in a dialog could contain credentials that no proxy along the Route header path actually needs 👀.
Any UA that wants to authenticate itself to a proxy server (usually after getting a 407 (Proxy Authentication Required) response, but not always) MAY do so by including a Proxy-Authorization header field value with the request. The Proxy-Authorization request-header field lets the client identify itself (or its user) to a proxy that requires authentication. Its value is made of credentials holding the UA's authentication info for the proxy and/or the realm of the resource being requested. ✨
A Proxy-Authorization header field value only applies to the proxy whose realm is named in the "realm" parameter. (That proxy may have already asked for authentication using the Proxy-Authenticate field.) When multiple proxies are chained together, a Proxy-Authorization header field value MUST NOT be consumed by any proxy whose realm doesn't match the "realm" parameter in that value. 🔥
Also, if an authentication scheme that doesn't support realms is used in the Proxy-Authorization header field, a proxy server MUST try to parse all Proxy-Authorization header field values to find out whether one of them has credentials it considers valid. This can take forever in big networks, so proxy servers SHOULD use an authentication scheme that supports realms in the Proxy-Authorization header field. 😭
If a request is forked (as described in Section 16.7), various proxy servers and/or UAs may want to challenge the UAC. In that case, the forking proxy server is responsible for combining these challenges into a single response. Every WWW-Authenticate and Proxy-Authenticate value received in responses to the forked request MUST be put into the single response that the forking proxy sends to the UA. The order of these header field values doesn't matter. 🦋
When a proxy server issues a challenge in response to a request, it will not proxy the request until the UAC has retried the request with valid credentials. A forking proxy may forward a request to multiple proxy servers at the same time that require authentication, and each of them won't forward the request until the originating UAC has authenticated itself in its own realm. If the UAC doesn't provide credentials for each challenge, the proxy servers that issued the challenges won't forward requests to the UA where the destination user might be located, so the virtues of forking are mostly lost. 💀
When a UAC retries its request after a 401 (Unauthorized) or 407 (Proxy Authentication Required) that has multiple challenges, it MAY include an Authorization value for each WWW-Authenticate value, and a Proxy-Authorization value for each Proxy-Authenticate value that it wants to give a credential for. As noted above, multiple credentials in one request SHOULD be told apart by the "realm" parameter. 🎀
It's possible for multiple challenges tied to the same realm to show up in the same 401 (Unauthorized) or 407 (Proxy Authentication Required). For example, this can happen when several proxies in the same administrative domain, all using a shared realm, get reached by a forking request. So when it retries a request, a UAC MAY supply multiple credentials in Authorization or Proxy-Authorization header fields that have the same "realm" parameter value. The same credentials SHOULD be used for the same realm. 🍓
22.4. The Digest Authentication Scheme 🔐
This section explains the changes and clarifications needed to apply the HTTP Digest authentication scheme to SIP. Honestly, SIP's usage is almost completely identical to HTTP's [17].
Since RFC 2543 is based on HTTP Digest as defined in RFC 2069 [39], SIP servers that support RFC 2617 MUST make sure they're backwards compatible with RFC 2069. The procedures for this backwards compatibility are specified in RFC 2617. Just note that SIP servers MUST NOT accept or request Basic authentication. 🚫
The rules for Digest authentication follow the ones defined in [17], with "HTTP/1.1" swapped out for "SIP/2.0", plus the following differences:
- The URI included in the challenge has this BNF:
URI = SIP-URI / SIPS-URI- The BNF in RFC 2617 has a mistake: the 'uri' parameter of the Authorization header field for HTTP Digest authentication isn't enclosed in quotation marks. (The example in Section 3.5 of RFC 2617 is correct.) For SIP, the 'uri' MUST be enclosed in quotation marks. 🙌
- The BNF for digest-uri-value is:
digest-uri-value = Request-URI ; as defined in Section 25- The example procedure for picking a nonce based on Etag doesn't work for SIP. 🙅♀️
- The text in RFC 2617 [17] about cache operation doesn't apply to SIP.
- RFC 2617 [17] requires a server to check that the URI in the request line and the URI in the Authorization header field point to the same resource. In a SIP context, these two URIs may refer to different users, because of forwarding at some proxy. So in SIP, a server MAY check that the Request-URI in the Authorization header field value corresponds to a user it's willing to accept forwarded or direct requests for. But it isn't necessarily a failure if the two fields don't match. 🤷♀️
- As a clarification to how the A2 value is calculated for message integrity in the Digest authentication scheme, implementers should assume that, when the entity-body is empty (that is, when SIP messages have no body), the hash of the entity-body resolves to the MD5 hash of an empty string, or:
H(entity-body) = MD5("") =
"d41d8cd98f00b204e9800998ecf8427e"- RFC 2617 notes that a cnonce value MUST NOT be sent in an Authorization (and by extension Proxy-Authorization) header field if no qop directive has been sent. So any algorithms that depend on the cnonce (including "MD5-Sess") require that the qop directive be sent. Using the "qop" parameter is optional in RFC 2617 for backwards compatibility with RFC 2069. Since RFC 2543 was based on RFC 2069, the "qop" parameter has to unfortunately stay optional for clients and servers to receive. However, servers MUST always send a "qop" parameter in WWW-Authenticate and Proxy-Authenticate header field values. If a client gets a "qop" parameter in a challenge header field, it MUST send the "qop" parameter in any resulting authorization header field. 🧠
RFC 2543 didn't allow the Authentication-Info header field (it basically used RFC 2069). But we now allow it, since it gives integrity checks over the bodies and provides mutual authentication. 🥰 RFC 2617 [17] defines backwards compatibility mechanisms using the qop attribute in the request. A server MUST use these mechanisms to determine whether the client supports the new RFC 2617 mechanisms that weren't specified in RFC 2069.
23. S/MIME 💌
SIP messages carry MIME bodies, and the MIME standard has mechanisms for securing MIME contents so you get both integrity and confidentiality (including the 'multipart/signed' and 'application/pkcs7-mime' MIME types; see RFC 1847 [22], RFC 2630 [23], and RFC 2633 [24]). Implementers should know, though, that there may be rare network intermediaries (not typical proxy servers) that rely on viewing or modifying the bodies of SIP messages (especially SDP), and secure MIME may stop these sorts of intermediaries from working. 👀
This applies particularly to certain types of firewalls.
The PGP mechanism for encrypting the header fields and bodies of SIP messages described in RFC 2543 has been deprecated. 🪦
23.1. S/MIME Certificates ✨
okay so the certs that end-users use for S/MIME are lowkey different from the ones servers use 🎀 instead of saying the holder matches some hostname, these certs say the holder is identified by an end-user address. That address is the concatenation of the userinfo, @, and domainname parts of a SIP or SIPS URI. So it's basically an email-looking thing like bob@biloxi.com, and it most commonly matches a user's address-of-record 💌
These certs are also tied to keys that sign or encrypt the bodies of SIP messages 🔐 bodies get signed with the sender's private key (and the sender may include their public key with the message, as appropriate), but bodies get encrypted with the recipient's public key. Obviously, senders must have foreknowledge of the recipients' public keys to encrypt message bodies. Public keys can be stored inside a UA on a virtual keyring 🗝️
Each user agent that supports S/MIME MUST contain a keyring specifically for end-users' certificates. This keyring should map addresses of record to their corresponding certificates. Over time, users SHOULD use the same certificate whenever they fill in the originating URI of signaling (the From header field) with the same address-of-record 🫶
Mechanisms that depend on end-user certificates are seriously limited, though, because there is virtually no consolidated authority today that provides certificates for end-user applications 😭 still, users SHOULD acquire certificates from known public certificate authorities. As an alternative, users MAY create self-signed certificates. The implications of self-signed certificates are explored further in Section 26.4.2. Implementations may also use pre-configured certificates in deployments where a previous trust relationship exists between all SIP entities 🌸
Beyond the struggle of getting an end-user certificate, there are few well-known centralized directories that distribute them 🙈 however, the holder of a certificate SHOULD publish their certificate in any public directories as appropriate. Similarly, UACs SHOULD support a mechanism for importing certificates discovered in public directories that correspond to the target URIs of SIP requests (manually or automatically) 📚
23.2. S/MIME Key Exchange
SIP itself can also be used to distribute public keys, and here's how 🦋
Whenever the CMS SignedData message is used in S/MIME for SIP, it MUST contain the certificate bearing the public key necessary to verify the signature 🔥
When a UAC sends a request containing an S/MIME body that initiates a dialog, or sends a non-INVITE request outside the context of a dialog, the UAC SHOULD structure the body as an S/MIME multipart/signed CMS SignedData body. If the desired CMS service is EnvelopedData (and the public key of the target user is known), the UAC SHOULD send the EnvelopedData message encapsulated within a SignedData message 💅
When a UAS receives a request containing an S/MIME CMS body that includes a certificate, the UAS SHOULD first validate the certificate, if possible, with any available root certificates for certificate authorities. The UAS SHOULD also determine the subject of the certificate (for S/MIME, the SubjectAltName will contain the appropriate identity) and compare this value to the From header field of the request. If the certificate cannot be verified, because it is self-signed or signed by no known authority, or if it is verifiable but its subject does not correspond to the From header field of the request, the UAS MUST notify its user of the status of the certificate (including the subject of the certificate, its signator, and any key fingerprint information) and request explicit permission before proceeding 👀 if the certificate was successfully verified and its subject matches the From header field of the SIP request, or if the user explicitly authorizes the certificate after being notified, the UAS SHOULD add this certificate to a local keyring, indexed by the address-of-record of the certificate's holder ✨
When a UAS sends a response containing an S/MIME body that answers the first request in a dialog, or a response to a non-INVITE request outside the context of a dialog, the UAS SHOULD structure the body as an S/MIME multipart/signed CMS SignedData body. If the desired CMS service is EnvelopedData, the UAS SHOULD send the EnvelopedData message encapsulated within a SignedData message 🧚
When a UAC receives a response containing an S/MIME CMS body that includes a certificate, the UAC SHOULD first validate the certificate, if possible, with any appropriate root certificate. The UAC SHOULD also determine the subject of the certificate and compare this value to the To field of the response. The two may very well be different, and this is not necessarily indicative of a security breach 🤷♀️ if the certificate cannot be verified because it is self-signed or signed by no known authority, the UAC MUST notify its user of the status of the certificate (including the subject of the certificate, its signator, and any key fingerprint information) and request explicit permission before proceeding. If the certificate was successfully verified and its subject corresponds to the To header field in the response, or if the user explicitly authorizes the certificate after being notified, the UAC SHOULD add this certificate to a local keyring, indexed by the address-of-record of the certificate's holder. If the UAC had not transmitted its own certificate to the UAS in any previous transaction, it SHOULD use a CMS SignedData body for its next request or response 💖
On future occasions, when the UA receives requests or responses that contain a From header field corresponding to a value in its keyring, the UA SHOULD compare the certificate offered in those messages with the existing certificate in its keyring. If there is a discrepancy, the UA MUST notify its user of the change of certificate (preferably in terms that make clear this is a potential security breach) and get the user's permission before continuing to process the signaling 🚨 if the user authorizes this certificate, it SHOULD be added to the keyring alongside any previous value(s) for this address-of-record.
Note well, however: this key exchange mechanism does not guarantee the secure exchange of keys when self-signed certificates, or certificates signed by an obscure authority, are used. It is vulnerable to well-known attacks 💀 In the opinion of the authors, though, the security it provides is proverbially better than nothing. It is in fact comparable to the widely used SSH application. These limitations are explored in greater detail in Section 26.4.2.
If a UA receives an S/MIME body that has been encrypted with a public key unknown to the recipient, it MUST reject the request with a 493 (Undecipherable) response. This response SHOULD contain a valid certificate for the respondent (corresponding, if possible, to any address of record given in the To header field of the rejected request) within a MIME body with a smime-type parameter of certs-only 🎀
A 493 (Undecipherable) sent without any certificate indicates that the respondent cannot or will not use S/MIME encrypted messages, though they may still support S/MIME signatures 🙃
Note that a user agent that receives a request containing an S/MIME body that is not optional (one with a Content-Disposition header handling parameter of required) MUST reject the request with a 415 Unsupported Media Type response if the MIME type is not understood. A user agent that receives such a response when S/MIME was sent SHOULD notify its user that the remote device does not support S/MIME. It MAY subsequently resend the request without S/MIME, if appropriate. However, this 415 response may constitute a downgrade attack 😬
If a user agent sends an S/MIME body in a request but receives a response containing a MIME body that is not secured, the UAC SHOULD notify its user that the session could not be secured. However, if a user agent that supports S/MIME receives a request with an unsecured body, it SHOULD NOT respond with a secured body. If it does expect S/MIME from the sender (for example, because the sender's From header field value corresponds to an identity on its keychain), the UAS SHOULD notify its user that the session could not be secured 🔒
A number of conditions in the previous text call for notifying the user when an anomalous certificate-management event occurs. Users might well ask what they should do in these situations 🤔 first and foremost, an unexpected change in a certificate, or an absence of security when security is expected, is a reason for caution but not necessarily an indication that an attack is in progress. Users might abort any connection attempt or refuse a connection request they have received. In telephony parlance, they could hang up and call back 📞 users may wish to find an alternate way to contact the other party and confirm that their key has legitimately changed. Note that users are sometimes compelled to change their certificates, for example when they suspect the secrecy of their private key has been compromised. When their private key is no longer private, users must legitimately generate a new key and re-establish trust with any users who held their old key 🥹
Finally, if during the course of a dialog a UA receives a certificate in a CMS SignedData message that does not correspond with the certificates previously exchanged during that dialog, the UA MUST notify its user of the change, preferably in terms that indicate this is a potential security breach 🚨🌈
23.3. Securing MIME bodies 🔐
okay so there are two types of secure MIME bodies that matter for SIP 💅 and they follow the S/MIME specification [24], with a few variations (I've got the list, bestie 🎀):
multipart/signedMUST be used only with CMS detached signatures.
This allows backwards compatibility with non-S/MIME-compliant recipients. 🫶
- S/MIME bodies SHOULD have a Content-Disposition header field, and the value of the
handlingparameter SHOULD be"required". 📎 - If a UAC has no certificate on its keyring associated with the address-of-record to which it wants to send a request, it cannot send an encrypted
application/pkcs7-mimeMIME message. UACs MAY send an initial request such as an OPTIONS message with a CMS detached signature in order to solicit the certificate of the remote side (the signature SHOULD be over amessage/sipbody of the type described in Section 23.4). 🔑
Note that future standardization work on S/MIME may define non-certificate based keys. 👀
- Senders of S/MIME bodies SHOULD use the
"SMIMECapabilities"attribute (see Section 2.5.2 of [24]) to express their capabilities and preferences for further communications. Note especially that senders MAY use the"preferSignedData"capability to encourage receivers to respond with CMS SignedData messages (for example, when sending an OPTIONS request as described above). 🌸 - S/MIME implementations MUST at a minimum support SHA1 as a digital signature algorithm, and 3DES as an encryption algorithm. All other signature and encryption algorithms MAY be supported. Implementations can negotiate support for these algorithms with the
"SMIMECapabilities"attribute. 🧚 - Each S/MIME body in a SIP message SHOULD be signed with only one certificate. If a UA receives a message with multiple signatures, the outermost signature should be treated as the single certificate for this body. Parallel signatures SHOULD NOT be used. 🙅♀️
The following is an example of an encrypted S/MIME SDP body within a SIP message. It's giving full envelope energy 💌✨
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Max-Forwards: 70
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
name=smime.p7m
Content-Disposition: attachment; filename=smime.p7m
handling=required
*******************************************************
* Content-Type: application/sdp *
* *
* v=0 *
* o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com *
* s=- *
* t=0 0 *
* c=IN IP4 pc33.atlanta.com *
* m=audio 3456 RTP/AVP 0 1 3 99 *
* a=rtpmap:0 PCMU/8000 *
*******************************************************23.4. SIP Header Privacy and Integrity using S/MIME: Tunneling SIP 🦋
okay this one is my favourite 😭 as a way of getting some degree of end-to-end authentication, integrity or confidentiality for SIP header fields, S/MIME can wrap entire SIP messages inside MIME bodies of type message/sip, and then apply MIME security to those bodies the same way it does for typical SIP bodies. These encapsulated SIP requests and responses do not make a separate dialog or transaction. They're just a copy of the "outer" message, used to verify integrity or to supply extra information. 🎁
If a UAS receives a request that contains a tunneled message/sip S/MIME body, it SHOULD include a tunneled message/sip body in the response with the same smime-type. 💜
Any traditional MIME bodies (such as SDP) SHOULD be attached to the "inner" message so that they can also benefit from S/MIME security. Note that message/sip bodies can be sent as a part of a MIME multipart/mixed body if any unsecured MIME types should also be transmitted in a request. 🌈
23.4.1. Integrity and Confidentiality Properties of SIP Headers
When the S/MIME integrity or confidentiality mechanisms are used, there may be discrepancies between the values in the "inner" message and values in the "outer" message. The rules for handling any such differences for all of the header fields described in this document are given in this section. 📋
Note that for the purposes of loose timestamping, all SIP messages that tunnel message/sip SHOULD contain a Date header in both the "inner" and "outer" headers. ⏰
23.4.1.1. Integrity
Whenever integrity checks are performed, the integrity of a header field should be determined by matching the value of the header field in the signed body with that in the "outer" messages using the comparison rules of SIP as described in 20. 🔍
Header fields that can be legitimately modified by proxy servers are: Request-URI, Via, Record-Route, Route, Max-Forwards, and Proxy-Authorization. If these header fields are not intact end-to-end, implementations SHOULD NOT consider this a breach of security. Changes to any other header fields defined in this document constitute an integrity violation; users MUST be notified of a discrepancy. 🚨
23.4.1.2. Confidentiality
When messages are encrypted, header fields may be included in the encrypted body that are not present in the "outer" message. 🤫
Some header fields must always have a plaintext version because they are required header fields in requests and responses. These include: To, From, Call-ID, CSeq, Contact. While it is probably not useful to provide an encrypted alternative for the Call-ID, CSeq, or Contact, providing an alternative to the information in the "outer" To or From is permitted. Note that the values in an encrypted body are not used for the purposes of identifying transactions or dialogs. They are merely informational. If the From header field in an encrypted body differs from the value in the "outer" message, the value within the encrypted body SHOULD be displayed to the user, but MUST NOT be used in the "outer" header fields of any future messages. 🫣
Primarily, a user agent will want to encrypt header fields that have an end-to-end semantic, including: Subject, Reply-To, Organization, Accept, Accept-Encoding, Accept-Language, Alert-Info, Error-Info, Authentication-Info, Expires, In-Reply-To, Require, Supported, Unsupported, Retry-After, User-Agent, Server, and Warning. If any of these header fields are present in an encrypted body, they should be used instead of any "outer" header fields, whether this entails displaying the header field values to users or setting internal states in the UA. They SHOULD NOT however be used in the "outer" headers of any future messages. 💅
If present, the Date header field MUST always be the same in the "inner" and "outer" headers. 📅
Since MIME bodies are attached to the "inner" message, implementations will usually encrypt MIME-specific header fields, including: MIME-Version, Content-Type, Content-Length, Content-Language, Content-Encoding and Content-Disposition. The "outer" message will have the proper MIME header fields for S/MIME bodies. These header fields (and any MIME bodies they preface) should be treated as normal MIME header fields and bodies received in a SIP message. 🧩
It is not particularly useful to encrypt the following header fields: Min-Expires, Timestamp, Authorization, Priority, and WWW-Authenticate. This category also includes those header fields that can be changed by proxy servers (described in the preceding section). UAs SHOULD never include these in an "inner" message if they are not included in the "outer" message. UAs that receive any of these header fields in an encrypted body SHOULD ignore the encrypted values. 🙈
Note that extensions to SIP may define additional header fields. The authors of these extensions should describe the integrity and confidentiality properties of such header fields. If a SIP UA encounters an unknown header field with an integrity violation, it MUST ignore the header field. 🛡️
23.4.2 Tunneling Integrity and Authentication ✨
okay so tunneling SIP messages inside S/MIME bodies can give you integrity for the header fields you want protected, as long as you copy those headers into a message/sip MIME body and sign it with a CMS detached signature 🔐💅
if that message/sip body has at least the basics (To, From, Call-ID, CSeq), the signed body can give you some limited authentication 🫶 at the bare minimum, if the recipient doesn't know the certificate and can't verify it, the signature still proves that a later request in a dialog came from the same certificate holder who started the dialog 🦋 and if the recipient has a stronger reason to trust the cert (they validated it, got it from a trusted repository, or use it all the time), then the signature counts as a much stronger claim about who the certificate's subject is 👑
so senders SHOULD replicate all the header fields from the request inside the signed body 💖 that way nobody can sneak in a header being added or removed without it being noticed 🙈 and any message bodies that need integrity protection MUST be attached to the "inner" message 🎀
if a message with a signed body has a Date header, the recipient SHOULD compare it with their own internal clock, if they have one 🕰️ if there's a big time gap (like an hour or more), the user agent SHOULD alert the user about the weirdness and say it could be a potential security breach 🚨😭
and if the recipient spots an integrity violation, the message MAY be rejected with a 403 (Forbidden) response when it's a request, or any existing dialog MAY be terminated 💀 either way, UAs SHOULD notify the users about it and ask them for explicit guidance on what to do next 🌸
here's an example of a tunneled message/sip body 🍓
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Max-Forwards: 70
Date: Thu, 21 Feb 2002 13:02:03 GMT
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1; boundary=boundary42
Content-Length: 568
--boundary42
Content-Type: message/sip
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
To: Bob <bob@biloxi.com>
From: Alice <alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Max-Forwards: 70
Date: Thu, 21 Feb 2002 13:02:03 GMT
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 147
v=0
o=UserA 2890844526 2890844526 IN IP4 here.com
s=Session SDP
c=IN IP4 pc33.atlanta.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
--boundary42
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s;
handling=required
ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
7GhIGfHfYT64VQbnj756
--boundary42--23.4.3 Tunneling Encryption 🔒
you could also use this trick to encrypt a message/sip MIME body inside a CMS EnvelopedData S/MIME body 🧚 but real talk, most headers are useful to the network, so S/MIME encryption is mostly used to protect message bodies like SDP, not headers 🙄 some informational headers, like Subject or Organization, could maybe deserve end-to-end security though 💜 and headers from future SIP applications might need obfuscation too 🌈
encrypting headers is also a way to get selective anonymity 🦋 a request can have a From header with zero personal info (like sip:anonymous@anonymizer.invalid) 🙈 then a second From header with the real address-of-record gets encrypted inside a message/sip body, so only the endpoints of the dialog can see it 👀
Note that if this mechanism is used for anonymity, the From header field will no longer be usable by the recipient of a message as an index to their certificate keychain for retrieving the proper S/MIME key to associated with the sender. The message must first be decrypted, and the "inner" From header field MUST be used as an index.
to get end-to-end integrity, encrypted message/sip bodies SHOULD be signed by the sender 🫶 that makes a multipart/signed body holding an encrypted body and a signature, both typed application/pkcs7-mime 🔐
in the example below (an encrypted and signed message), the text boxed in asterisks ("*") is the encrypted part 🎀
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
To: Bob <sip:bob@biloxi.com>
From: Anonymous <sip:anonymous@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Max-Forwards: 70
Date: Thu, 21 Feb 2002 13:02:03 GMT
Contact: <sip:pc33.atlanta.com>
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1; boundary=boundary42
Content-Length: 568
--boundary42
Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m
handling=required
Content-Length: 231
***********************************************************
* Content-Type: message/sip *
* *
* INVITE sip:bob@biloxi.com SIP/2.0 *
* Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 *
* To: Bob <bob@biloxi.com> *
* From: Alice <alice@atlanta.com>;tag=1928301774 *
* Call-ID: a84b4c76e66710 *
* CSeq: 314159 INVITE *
* Max-Forwards: 70 *
* Date: Thu, 21 Feb 2002 13:02:03 GMT *
* Contact: <sip:alice@pc33.atlanta.com> *
* *
* Content-Type: application/sdp *
* *
* v=0 *
* o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com *
* s=Session SDP *
* t=0 0 *
* c=IN IP4 pc33.atlanta.com *
* m=audio 3456 RTP/AVP 0 1 3 99 *
* a=rtpmap:0 PCMU/8000 *
***********************************************************
--boundary42
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s;
handling=required
ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
7GhIGfHfYT64VQbnj756
--boundary42--24 Examples 📚
in the examples that follow, we often leave out the message body and its matching Content-Length and Content-Type headers, just to keep things short 🌸
24.1 Registration 🧾
Bob registers when his softphone starts up 📱 the message flow is in Figure 9 🦋 the authentication that's usually needed for registration isn't shown, to keep it simple 🙈
biloxi.com Bob's
registrar softphone
| |
| REGISTER F1 |
|<---------------|
| 200 OK F2 |
|--------------->|Figure 9: SIP Registration Example
F1 REGISTER Bob -> Registrar
REGISTER sip:registrar.biloxi.com SIP/2.0
Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Bob <sip:bob@biloxi.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:bob@192.0.2.4>
Expires: 7200
Content-Length: 0the registration expires after two hours ⏰ and the registrar replies with a 200 OK 💖
F2 200 OK Registrar -> Bob
SIP/2.0 200 OK
Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7
;received=192.0.2.4
To: Bob <sip:bob@biloxi.com>;tag=2493k59kd
From: Bob <sip:bob@biloxi.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:bob@192.0.2.4>
Expires: 7200
Content-Length: 024.2 Session Setup 🎀
this one has the full details of the session setup from Section 4 🫶 the message flow is in Figure 1 ✨ these flows only show the minimum required set of header fields, so stuff like Allow and Supported would normally be there too 💅
F1 INVITE Alice -> atlanta.com proxy
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142
(Alice's SDP not shown)F2 100 Trying atlanta.com proxy -> Alice
SIP/2.0 100 Trying
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
;received=192.0.2.1
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Content-Length: 0F3 INVITE atlanta.com proxy -> biloxi.com proxy
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
;received=192.0.2.1
Max-Forwards: 69
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142
(Alice's SDP not shown)F4 100 Trying biloxi.com proxy -> atlanta.com proxy
SIP/2.0 100 Trying
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
;received=192.0.2.2
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
;received=192.0.2.1
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Content-Length: 0F5 INVITE biloxi.com proxy -> Bob
INVITE sip:bob@192.0.2.4 SIP/2.0
Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
;received=192.0.2.225 Augmented BNF for the SIP Protocol ✨
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
;received=192.0.2.1
Max-Forwards: 68
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142
(Alice's SDP not shown)okay so F6 is 180 Ringing heading from Bob back to the biloxi proxy 🔔 It's giving a whole chain of Via headers, each one stamped with a ;received= parameter as it goes 🧚
F6 180 Ringing Bob -> biloxi.com proxy
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1
;received=192.0.2.3
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
;received=192.0.2.2
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
;received=192.0.2.1
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
Contact: <sip:bob@192.0.2.4>
CSeq: 314159 INVITE
Content-Length: 0
F7 180 Ringing biloxi.com proxy -> atlanta.com proxy
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
;received=192.0.2.2
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
;received=192.0.2.1
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
Contact: <sip:bob@192.0.2.4>
CSeq: 314159 INVITE
Content-Length: 0
F8 180 Ringing atlanta.com proxy -> Alice
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
;received=192.0.2.1
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
Contact: <sip:bob@192.0.2.4>
CSeq: 314159 INVITE
Content-Length: 0
F9 200 OK Bob -> biloxi.com proxy
SIP/2.0 200 OK
Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1
;received=192.0.2.3
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
;received=192.0.2.2
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
;received=192.0.2.1
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:bob@192.0.2.4>
Content-Type: application/sdp
Content-Length: 131
(Bob's SDP not shown)
F10 200 OK biloxi.com proxy -> atlanta.com proxy
SIP/2.0 200 OK
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
;received=192.0.2.2
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
;received=192.0.2.1
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:bob@192.0.2.4>
Content-Type: application/sdp
Content-Length: 131
(Bob's SDP not shown)
F11 200 OK atlanta.com proxy -> Alice
SIP/2.0 200 OK
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
;received=192.0.2.1
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:bob@192.0.2.4>
Content-Type: application/sdp
Content-Length: 131
(Bob's SDP not shown)
F12 ACK Alice -> Bob
ACK sip:bob@192.0.2.4 SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds9
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 ACK
Content-Length: 0And just like that, the media session between Alice and Bob is officially live 💖💅 The call is ATE 🍓
Now Bob hangs up first 📞 (the nerve, lol). Bob's SIP phone keeps its own CSeq numbering space, and in this example it starts at 231. Since Bob is the one making the request, the To and From URIs and tags have been swapped, so it's his turn to be the "From" 🦋
F13 BYE Bob -> Alice
BYE sip:alice@pc33.atlanta.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10
Max-Forwards: 70
From: Bob <sip:bob@biloxi.com>;tag=a6c85cf
To: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 231 BYE
Content-Length: 0
F14 200 OK Alice -> Bob
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10
From: Bob <sip:bob@biloxi.com>;tag=a6c85cf
To: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 231 BYE
Content-Length: 0If you want even more examples of SIP messages, the SIP Call Flows document [40] has you covered 🧚♀️🎀
25.1 Basic Rules
okay so this section is the grammar tea ☕ All the mechanisms in this spec get described in both prose AND an augmented Backus-Naur Form (BNF) that's defined in RFC 2234 [10] 📚 Section 6.1 of RFC 2234 has a set of core rules this spec uses but doesn't repeat, so you need to be comfy with that notation to get what's going on here 🫶 Basic rules are in uppercase (SP, LWS, HTAB, CRLF, DIGIT, ALPHA, etc.), and angle brackets just clarify when you're using a rule name ✨
Square brackets are syntactically redundant, btw 🙈 They're just a semantic hint that the parameter is optional to use.
The following rules are used all over this spec for basic parsing stuff. The US-ASCII coded character set is defined by ANSI X3.4-1986 💅
alphanum = ALPHA / DIGITA few rules were pulled in from RFC 2396 [5], but they got a glow-up so they're compliant with RFC 2234 [10] 💜 Those include:
reserved = ";" / "/" / "?" / ":" / "@" / "&" / "=" / "+"
/ "$" / ","
unreserved = alphanum / mark
mark = "-" / "_" / "." / "!" / "~" / "*" / "'"
/ "(" / ")"
escaped = "%" HEXDIG HEXDIGSIP header field values can be folded onto multiple lines if the continuation line starts with a space or horizontal tab 🌸 All linear white space, folding included, has the same semantics as SP. A recipient MAY replace any linear white space with a single SP before it interprets the field value or forwards the message downstream. This is meant to behave exactly like HTTP/1.1 as described in RFC 2616 [8] 🦋 The SWS construct is used when linear white space is optional, usually between tokens and separators.
LWS = [*WSP CRLF] 1*WSP ; linear whitespace
SWS = [LWS] ; sep whitespaceTo separate the header name from the rest of the value, we use a colon. By the rule above, whitespace is allowed before it (but no line break), and after it, including a line break ✨ That's what HCOLON is for.
HCOLON = *( SP / HTAB ) ":" SWSThe TEXT-UTF8 rule is only for descriptive field contents and values that the message parser isn't supposed to interpret 🎀 Words of *TEXT-UTF8 contain characters from the UTF-8 charset (RFC 2279 [7]). The TEXT-UTF8-TRIM rule is for descriptive field contents that are not quoted strings, where leading and trailing LWS doesn't mean anything. SIP is different from HTTP here, since HTTP uses the ISO 8859-1 character set 🌈
TEXT-UTF8-TRIM = 1*TEXT-UTF8char *(*LWS TEXT-UTF8char)
TEXT-UTF8char = %x21-7E / UTF8-NONASCII
UTF8-NONASCII = %xC0-DF 1UTF8-CONT
/ %xE0-EF 2UTF8-CONT
/ %xF0-F7 3UTF8-CONT
/ %xF8-Fb 4UTF8-CONT
/ %xFC-FD 5UTF8-CONT
UTF8-CONT = %x80-BFA CRLF is only allowed inside TEXT-UTF8-TRIM as part of a header field continuation 🧚 The folding LWS is expected to get swapped for a single SP before anyone interprets the TEXT-UTF8-TRIM value.
Hex numeric characters show up in a bunch of protocol elements. Some elements (authentication) force hex alphas to be lowercase, so no caps lock for those 🔥
LHEX = DIGIT / %x61-66 ;lowercase a-fLots of SIP header field values are just words separated by LWS or special characters. Unless said otherwise, tokens are case-insensitive 💖 These special characters MUST be in a quoted string to be used within a parameter value. The word construct is used in Call-ID so most separators can be used there 🫶
token = 1*(alphanum / "-" / "." / "!" / "%" / "*"
/ "_" / "+" / "`" / "'" / "~" )
separators = "(" / ")" / "<" / ">" / "@" /
"," / ";" / ":" / "\" / DQUOTE /
"/" / "[" / "]" / "?" / "=" /
"{" / "}" / SP / HTAB
word = 1*(alphanum / "-" / "." / "!" / "%" / "*" /
"_" / "+" / "`" / "'" / "~" /
"(" / ")" / "<" / ">" /
":" / "\" / DQUOTE /
"/" / "[" / "]" / "?" /
"{" / "}" )When tokens are used or separators sit between elements, whitespace is often allowed before or after those characters 💅
STAR = SWS "*" SWS ; asterisk
SLASH = SWS "/" SWS ; slash
EQUAL = SWS "=" SWS ; equal
LPAREN = SWS "(" SWS ; left parenthesis
RPAREN = SWS ")" SWS ; right parenthesis
RAQUOT = ">" SWS ; right angle quote
LAQUOT = SWS "<"; left angle quote
COMMA = SWS "," SWS ; comma
SEMI = SWS ";" SWS ; semicolon
COLON = SWS ":" SWS ; colon
LDQUOT = SWS DQUOTE; open double quotation mark
RDQUOT = DQUOTE SWS ; close double quotation markComments can go in some SIP header fields by wrapping the comment text in parentheses 💜 Comments are only allowed in fields that have "comment" as part of their field value definition. In every other field, the parentheses count as part of the field value, so no sneaky comments 🙈
comment = LPAREN *(ctext / quoted-pair / comment) RPAREN
ctext = %x21-27 / %x2A-5B / %x5D-7E / UTF8-NONASCII
/ LWSctext covers all chars except the left and right parens and the backslash 🎀 A string of text gets parsed as one single word if it's wrapped in double quote marks. Inside quoted strings, quotation marks (") and backslashes () need to be escaped 🌸
quoted-string = SWS DQUOTE *(qdtext / quoted-pair ) DQUOTE
qdtext = LWS / %x21 / %x23-5B / %x5D-7E
/ UTF8-NONASCIIThe backslash character ("") MAY be used as a single-character quoting mechanism, but only inside quoted-string and comment constructs 🦋 Unlike HTTP/1.1, CR and LF can't be escaped this way, because that would clash with line folding and header separation 🚫
quoted-pair = "\" (%x00-09 / %x0B-0C
/ %x0E-7F)Now the URI grammar, which is where it gets spicy 🌶️
SIP-URI = "sip:" [ userinfo ] hostport
uri-parameters [ headers ]
SIPS-URI = "sips:" [ userinfo ] hostport
uri-parameters [ headers ]
userinfo = ( user / telephone-subscriber ) [ ":" password ] "@"
user = 1*( unreserved / escaped / user-unreserved )
user-unreserved = "&" / "=" / "+" / "$" / "," / ";" / "?" / "/"
password = *( unreserved / escaped /
"&" / "=" / "+" / "$" / "," )
hostport = host [ ":" port ]
host = hostname / IPv4address / IPv6reference
hostname = *( domainlabel "." ) toplabel [ "." ]
domainlabel = alphanum
/ alphanum *( alphanum / "-" ) alphanum
toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum
IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGITIPv6reference = "[" IPv6address "]"
IPv6address = hexpart [ ":" IPv4address ]
hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ]
hexseq = hex4 *( ":" hex4)
hex4 = 1*4HEXDIG
port = 1*DIGITokay so the BNF for telephone-subscriber lives over in RFC 2806 [9], so go peek at it if you need it 👀 but heads up bestie, any characters that are allowed there and NOT allowed in the user part of a SIP URI MUST be escaped 🫶 no skipping that step, periodt 💅
uri-parameters = *( ";" uri-parameter)
uri-parameter = transport-param / user-param / method-param
/ ttl-param / maddr-param / lr-param / other-param
transport-param = "transport="
( "udp" / "tcp" / "sctp" / "tls"
/ other-transport)
other-transport = token
user-param = "user=" ( "phone" / "ip" / other-user)
other-user = token
method-param = "method=" Method
ttl-param = "ttl=" ttl
maddr-param = "maddr=" host
lr-param = "lr"
other-param = pname [ "=" pvalue ]
pname = 1*paramchar
pvalue = 1*paramchar
paramchar = param-unreserved / unreserved / escaped
param-unreserved = "[" / "]" / "/" / ":" / "&" / "+" / "$"headers = "?" header *( "&" header )
header = hname "=" hvalue
hname = 1*( hnv-unreserved / unreserved / escaped )
hvalue = *( hnv-unreserved / unreserved / escaped )
hnv-unreserved = "[" / "]" / "/" / "?" / ":" / "+" / "$"SIP-message = Request / Response
Request = Request-Line
*( message-header )
CRLF
[ message-body ]
Request-Line = Method SP Request-URI SP SIP-Version CRLF
Request-URI = SIP-URI / SIPS-URI / absoluteURI
absoluteURI = scheme ":" ( hier-part / opaque-part )
hier-part = ( net-path / abs-path ) [ "?" query ]
net-path = "//" authority [ abs-path ]
abs-path = "/" path-segments
opaque-part = uric-no-slash *uric
uric = reserved / unreserved / escaped
uric-no-slash = unreserved / escaped / ";" / "?" / ":" / "@"
/ "&" / "=" / "+" / "$" / ","
path-segments = segment *( "/" segment )
segment = *pchar *( ";" param )
param = *pchar
pchar = unreserved / escaped /
":" / "@" / "&" / "=" / "+" / "$" / ","
scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
authority = srvr / reg-name
srvr = [ [ userinfo "@" ] hostport ]
reg-name = 1*( unreserved / escaped / "$" / ","
/ ";" / ":" / "@" / "&" / "=" / "+" )
query = *uric
SIP-Version = "SIP" "/" 1*DIGIT "." 1*DIGITmessage-header = (Accept
/ Accept-Encoding
/ Accept-Language
/ Alert-Info
/ Allow
/ Authentication-Info
/ Authorization
/ Call-ID
/ Call-Info
/ Contact
/ Content-Disposition
/ Content-Encoding
/ Content-Language
/ Content-Length
/ Content-Type
/ CSeq
/ Date
/ Error-Info
/ Expires
/ From
/ In-Reply-To
/ Max-Forwards
/ MIME-Version
/ Min-Expires
/ Organization
/ Priority
/ Proxy-Authenticate
/ Proxy-Authorization
/ Proxy-Require
/ Record-Route
/ Reply-To
/ Require
/ Retry-After
/ Route
/ Server
/ Subject
/ Supported
/ Timestamp
/ To
/ Unsupported
/ User-Agent
/ Via
/ Warning
/ WWW-Authenticate
/ extension-header) CRLFINVITEm = %x49.4E.56.49.54.45 ; INVITE in caps
ACKm = %x41.43.4B ; ACK in caps
OPTIONSm = %x4F.50.54.49.4F.4E.53 ; OPTIONS in caps
BYEm = %x42.59.45 ; BYE in caps
CANCELm = %x43.41.4E.43.45.4C ; CANCEL in caps
REGISTERm = %x52.45.47.49.53.54.45.52 ; REGISTER in caps
Method = INVITEm / ACKm / OPTIONSm / BYEm
/ CANCELm / REGISTERm
/ extension-method
extension-method = token
Response = Status-Line
*( message-header )
CRLF
[ message-body ]Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF
Status-Code = Informational
/ Redirection
/ Success
/ Client-Error
/ Server-Error
/ Global-Failure
/ extension-code
extension-code = 3DIGIT
Reason-Phrase = *(reserved / unreserved / escaped
/ UTF8-NONASCII / UTF8-CONT / SP / HTAB)Informational = "100" ; Trying
/ "180" ; Ringing
/ "181" ; Call Is Being Forwarded
/ "182" ; Queued
/ "183" ; Session ProgressSuccess = "200" ; OKRedirection = "300" ; Multiple Choices
/ "301" ; Moved Permanently
/ "302" ; Moved Temporarily
/ "305" ; Use Proxy
/ "380" ; Alternative ServiceClient-Error = "400" ; Bad Request
/ "401" ; Unauthorized
/ "402" ; Payment Required
/ "403" ; Forbidden
/ "404" ; Not Found
/ "405" ; Method Not Allowed
/ "406" ; Not Acceptable
/ "407" ; Proxy Authentication Required
/ "408" ; Request Timeout
/ "410" ; Gone
/ "413" ; Request Entity Too Large
/ "414" ; Request-URI Too Large
/ "415" ; Unsupported Media Type
/ "416" ; Unsupported URI Scheme
/ "420" ; Bad Extension
/ "421" ; Extension Required
/ "423" ; Interval Too Brief
/ "480" ; Temporarily not available
/ "481" ; Call Leg/Transaction Does Not Exist
/ "482" ; Loop Detected
/ "483" ; Too Many Hops
/ "484" ; Address Incomplete
/ "485" ; Ambiguous
/ "486" ; Busy Here
/ "487" ; Request Terminated
/ "488" ; Not Acceptable Here
/ "491" ; Request Pending
/ "493" ; UndecipherableServer-Error = "500" ; Internal Server Error
/ "501" ; Not Implemented
/ "502" ; Bad Gateway
/ "503" ; Service Unavailable
/ "504" ; Server Time-out
/ "505" ; SIP Version not supported
/ "513" ; Message Too LargeGlobal-Failure = "600" ; Busy Everywhere
/ "603" ; Decline
/ "604" ; Does not exist anywhere
/ "606" ; Not AcceptableAccept = "Accept" HCOLON
[ accept-range *(COMMA accept-range) ]
accept-range = media-range *(SEMI accept-param)
media-range = ( "*/*"
/ ( m-type SLASH "*" )
/ ( m-type SLASH m-subtype )
) *( SEMI m-parameter )
accept-param = ("q" EQUAL qvalue) / generic-param
qvalue = ( "0" [ "." 0*3DIGIT ] )
/ ( "1" [ "." 0*3("0") ] )
generic-param = token [ EQUAL gen-value ]
gen-value = token / host / quoted-stringAccept-Encoding = "Accept-Encoding" HCOLON
[ encoding *(COMMA encoding) ]
encoding = codings *(SEMI accept-param)
codings = content-coding / "*"
content-coding = tokenAccept-Language = "Accept-Language" HCOLON
[ language *(COMMA language) ]
language = language-range *(SEMI accept-param)
language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) / "*" )Alert-Info = "Alert-Info" HCOLON alert-param *(COMMA alert-param)
alert-param = LAQUOT absoluteURI RAQUOT *( SEMI generic-param )Allow = "Allow" HCOLON [Method *(COMMA Method)]Authorization = "Authorization" HCOLON credentials
credentials = ("Digest" LWS digest-response)
/ other-response
digest-response = dig-resp *(COMMA dig-resp)
dig-resp = username / realm / nonce / digest-uri
/ dresponse / algorithm / cnonce
/ opaque / message-qop
/ nonce-count / auth-param
username = "username" EQUAL username-value
username-value = quoted-string
digest-uri = "uri" EQUAL LDQUOT digest-uri-value RDQUOT
digest-uri-value = rquest-uri ; Equal to request-uri as specified
by HTTP/1.1
message-qop = "qop" EQUAL qop-value
cnonce = "cnonce" EQUAL cnonce-value
cnonce-value = nonce-value
nonce-count = "nc" EQUAL nc-value
nc-value = 8LHEX
dresponse = "response" EQUAL request-digest
request-digest = LDQUOT 32LHEX RDQUOT
auth-param = auth-param-name EQUAL
( token / quoted-string )
auth-param-name = token
other-response = auth-scheme LWS auth-param
*(COMMA auth-param)
auth-scheme = tokenAuthentication-Info = "Authentication-Info" HCOLON ainfo
*(COMMA ainfo)
ainfo = nextnonce / message-qop
/ response-auth / cnonce
/ nonce-count
nextnonce = "nextnonce" EQUAL nonce-value
response-auth = "rspauth" EQUAL response-digest
response-digest = LDQUOT *LHEX RDQUOTCall-ID = ( "Call-ID" / "i" ) HCOLON callid
callid = word [ "@" word ]Call-Info = "Call-Info" HCOLON info *(COMMA info)
info = LAQUOT absoluteURI RAQUOT *( SEMI info-param)
info-param = ( "purpose" EQUAL ( "icon" / "info"
/ "card" / token ) ) / generic-paramContact = ("Contact" / "m" ) HCOLON
( STAR / (contact-param *(COMMA contact-param)))
contact-param = (name-addr / addr-spec) *(SEMI contact-params)
name-addr = [ display-name ] LAQUOT addr-spec RAQUOT
addr-spec = SIP-URI / SIPS-URI / absoluteURI
display-name = *(token LWS)/ quoted-string
contact-params = c-p-q / c-p-expires
/ contact-extension
c-p-q = "q" EQUAL qvalue
c-p-expires = "expires" EQUAL delta-seconds
contact-extension = generic-param
delta-seconds = 1*DIGITContent-Disposition = "Content-Disposition" HCOLON
disp-type *( SEMI disp-param )
disp-type = "render" / "session" / "icon" / "alert"
/ disp-extension-token
disp-param = handling-param / generic-param
handling-param = "handling" EQUAL
( "optional" / "required"
/ other-handling )
other-handling = token
disp-extension-token = tokenContent-Encoding = ( "Content-Encoding" / "e" ) HCOLON
content-coding *(COMMA content-coding)Content-Language = "Content-Language" HCOLON
language-tag *(COMMA language-tag)
language-tag = primary-tag *( "-" subtag )
primary-tag = 1*8ALPHA
subtag = 1*8ALPHAContent-Length = ( "Content-Length" / "l" ) HCOLON 1*DIGIT Content-Type = ( "Content-Type" / "c" ) HCOLON media-type media-type = m-type SLASH m-subtype *(SEMI m-parameter) m-type = discrete-type / composite-type discrete-type = "text" / "image" / "audio" / "video" / "application" / extension-token composite-type = "message" / "multipart" / extension-token extension-token = ietf-token / x-token ietf-token = token x-token = "x-" token m-subtype = extension-token / iana-token iana-token = token m-parameter = m-attribute EQUAL m-value m-attribute = token m-value = token / quoted-string
CSeq = "CSeq" HCOLON 1*DIGIT LWS Method
Date = "Date" HCOLON SIP-date SIP-date = rfc1123-date rfc1123-date = wkday "," SP date1 SP time SP "GMT" date1 = 2DIGIT SP month SP 4DIGIT ; day month year (e.g., 02 Jun 1982) time = 2DIGIT ":" 2DIGIT ":" 2DIGIT ; 00:00:00 - 23:59:59 wkday = "Mon" / "Tue" / "Wed" / "Thu" / "Fri" / "Sat" / "Sun" month = "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" / "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec"
Error-Info = "Error-Info" HCOLON error-uri *(COMMA error-uri) error-uri = LAQUOT absoluteURI RAQUOT *( SEMI generic-param )
Expires = "Expires" HCOLON delta-seconds From = ( "From" / "f" ) HCOLON from-spec from-spec = ( name-addr / addr-spec ) *( SEMI from-param ) from-param = tag-param / generic-param tag-param = "tag" EQUAL token
In-Reply-To = "In-Reply-To" HCOLON callid *(COMMA callid)
Max-Forwards = "Max-Forwards" HCOLON 1*DIGIT
MIME-Version = "MIME-Version" HCOLON 1*DIGIT "." 1*DIGIT
Min-Expires = "Min-Expires" HCOLON delta-seconds
Organization = "Organization" HCOLON [TEXT-UTF8-TRIM]
Priority = "Priority" HCOLON priority-value priority-value = "emergency" / "urgent" / "normal" / "non-urgent" / other-priority other-priority = token
Proxy-Authenticate = "Proxy-Authenticate" HCOLON challenge challenge = ("Digest" LWS digest-cln *(COMMA digest-cln)) / other-challenge other-challenge = auth-scheme LWS auth-param *(COMMA auth-param) digest-cln = realm / domain / nonce / opaque / stale / algorithm / qop-options / auth-param realm = "realm" EQUAL realm-value realm-value = quoted-string domain = "domain" EQUAL LDQUOT URI *( 1*SP URI ) RDQUOT URI = absoluteURI / abs-path nonce = "nonce" EQUAL nonce-value nonce-value = quoted-string opaque = "opaque" EQUAL quoted-string stale = "stale" EQUAL ( "true" / "false" ) algorithm = "algorithm" EQUAL ( "MD5" / "MD5-sess" / token ) qop-options = "qop" EQUAL LDQUOT qop-value *("," qop-value) RDQUOT qop-value = "auth" / "auth-int" / token
Proxy-Authorization = "Proxy-Authorization" HCOLON credentials Proxy-Require = "Proxy-Require" HCOLON option-tag *(COMMA option-tag) option-tag = token
Record-Route = "Record-Route" HCOLON rec-route *(COMMA rec-route) rec-route = name-addr *( SEMI rr-param ) rr-param = generic-param
Reply-To = "Reply-To" HCOLON rplyto-spec rplyto-spec = ( name-addr / addr-spec ) *( SEMI rplyto-param ) rplyto-param = generic-param Require = "Require" HCOLON option-tag *(COMMA option-tag)
Retry-After = "Retry-After" HCOLON delta-seconds [ comment ] *( SEMI retry-param )
retry-param = ("duration" EQUAL delta-seconds) / generic-param
Route = "Route" HCOLON route-param *(COMMA route-param) route-param = name-addr *( SEMI rr-param )
Server = "Server" HCOLON server-val *(LWS server-val) server-val = product / comment product = token [SLASH product-version] product-version = token
Subject = ( "Subject" / "s" ) HCOLON [TEXT-UTF8-TRIM]
Supported = ( "Supported" / "k" ) HCOLON [option-tag *(COMMA option-tag)]
Timestamp = "Timestamp" HCOLON 1*(DIGIT) [ "." *(DIGIT) ] [ LWS delay ] delay = *(DIGIT) [ "." *(DIGIT) ]
To = ( "To" / "t" ) HCOLON ( name-addr / addr-spec ) *( SEMI to-param ) to-param = tag-param / generic-param
Unsupported = "Unsupported" HCOLON option-tag *(COMMA option-tag) User-Agent = "User-Agent" HCOLON server-val *(LWS server-val) Via = ( "Via" / "v" ) HCOLON via-parm *(COMMA via-parm) via-parm = sent-protocol LWS sent-by *( SEMI via-params ) via-params = via-ttl / via-maddr / via-received / via-branch / via-extension via-ttl = "ttl" EQUAL ttl via-maddr = "maddr" EQUAL host via-received = "received" EQUAL (IPv4address / IPv6address) via-branch = "branch" EQUAL token via-extension = generic-param sent-protocol = protocol-name SLASH protocol-version SLASH transport protocol-name = "SIP" / token protocol-version = token transport = "UDP" / "TCP" / "TLS" / "SCTP" / other-transport sent-by = host [ COLON port ] ttl = 1*3DIGIT ; 0 to 255
Warning = "Warning" HCOLON warning-value *(COMMA warning-value) warning-value = warn-code SP warn-agent SP warn-text warn-code = 3DIGIT warn-agent = hostport / pseudonym ; the name or pseudonym of the server adding ; the Warning header, for use in debugging warn-text = quoted-string pseudonym = token
WWW-Authenticate = "WWW-Authenticate" HCOLON challenge
extension-header = header-name HCOLON header-value header-name = token header-value = *(TEXT-UTF8char / UTF8-CONT / LWS) message-body = *OCTET
26 Security Considerations: Threat Model and Security Usage Recommendations 🔐
SIP is not an easy protocol to secure! 😭 Its use of intermediaries, its multi-faceted trust relationships, its expected usage between elements with no trust at all, and its user-to-user operation make security far from trivial. 💀 We need security solutions that are deployable today, without a ton of coordination, across a wide variety of environments and usages. ✨ So, to meet all these different needs, several distinct mechanisms that apply to different aspects and usages of SIP will be required. 🔥
Okay, bestie, pay attention here 👀 The security of SIP signaling itself has no bearing on the security of protocols used alongside SIP, like RTP, or on the security implications of whatever specific bodies SIP might carry. (Although MIME security plays a substantial role in securing SIP, so 🫶.) Any media tied to a session can be encrypted end-to-end, completely independently of the SIP signaling. Media encryption is outside the scope of this document, so we're not going there today. 🙈
Here's the game plan 🗺️ We'll start with a set of classic threat models that broadly identify the security needs of SIP. Then we'll detail the set of security services needed to address those threats, followed by an explanation of several security mechanisms that can provide those services. Next up: the requirements for SIP implementers, along with exemplary deployments where these mechanisms could be used to make SIP more secure. Some notes on privacy wrap things up for this section. 🧚
26.1 Attacks and Threat Models 💜
This section breaks down some threats that should be common to most SIP deployments. These threats were picked specifically to illustrate each of the security services SIP requires. 🎀
The following examples by no means give you an exhaustive list of threats against SIP. Think of them as "classic" threats that show why you need particular security services, which can potentially prevent whole categories of threats. 🦋
These attacks assume an environment where attackers can potentially read any packet on the network, since SIP will frequently be used on the public Internet. 😳 Attackers on the network may also be able to modify packets, maybe at some compromised intermediary. And attackers may want to steal services, eavesdrop on communications, or disrupt sessions. 💅
26.1.1 Registration Hijacking 🚨
The SIP registration mechanism lets a user agent identify itself to a registrar as a device where a user (designated by an address of record) is located. ✨ A registrar checks the identity asserted in the From header field of a REGISTER message to figure out whether that request can modify the contact addresses tied to the address-of-record in the To header field. Those two fields are frequently the same, but there are plenty of valid deployments where a third party registers contacts on a user's behalf. 🫶
Here's the tea ☕: the From header field of a SIP request can be modified arbitrarily by the owner of a UA, and that opens the door to malicious registrations. 😱 An attacker who successfully impersonates a party authorized to change contacts for an address-of-record could, for example, de-register all existing contacts for a URI, then register their own device as the appropriate contact address. Boom, all requests for the affected user now go straight to the attacker's device. 💀
This threat belongs to a whole family of threats that rely on the absence of cryptographic assurance of a request's originator. Any SIP UAS that represents a valuable service (a gateway that interworks SIP requests with traditional telephone calls, for example) might want to control access to its resources by authenticating the requests it receives. Even end-user UAs, like SIP phones, have an interest in finding out who originated requests. 📞
This threat shows why we need security services that let SIP entities authenticate the originators of requests. 👑
26.1.2 Impersonating a Server 🎭
The domain a request is headed to is generally specified in the Request-URI. UAs commonly contact a server in that domain directly to deliver the request. 📬 But there's always a possibility that an attacker could impersonate the remote server, and the UA's request could get intercepted by some other party. 😬
Picture this 🎬: a redirect server at one domain, chicago.com, impersonates a redirect server at another domain, biloxi.com. A user agent sends a request to biloxi.com, but the redirect server at chicago.com answers with a forged response that has the right SIP header fields for a response from biloxi.com. 🙈 The forged contact addresses in that redirection response could send the originating UA to inappropriate or insecure resources, or just stop requests for biloxi.com from succeeding. 🥲
This family of threats is huge, and a lot of its members are critical. 🔥 As a converse to the registration hijacking threat, imagine a registration sent to biloxi.com gets intercepted by chicago.com, which replies to it with a forged 301 (Moved Permanently) response. ⚠️ That response might look like it came from biloxi.com while designating chicago.com as the appropriate registrar. Then every future REGISTER request from the originating UA goes straight to chicago.com. 😭
Stopping this threat requires a way for UAs to authenticate the servers they send requests to. 🫣🔐
26.1.3 Tampering with Message Bodies ✨
okay so, SIP UAs route requests through trusted proxy servers as a matter of course 🫶. However that trust gets set up (authentication of proxies is discussed elsewhere in this section), a UA may trust a proxy server to route a request, but not to inspect or possibly modify the bodies inside it 💅.
Consider a UA that uses SIP message bodies to share session encryption keys for a media session 🔐. It trusts the proxy server of its own domain to deliver signaling properly, but it may not want that domain's administrators to be able to decrypt any later media session 🙈. Worse yet, if the proxy server were actively malicious, it could modify the session key, either acting as a man-in-the-middle, or changing the security characteristics the originating UA asked for 💀.
This family of threats isn't just about session keys. It covers most conceivable forms of content carried end-to-end in SIP, like MIME bodies that get rendered to the user, SDP, or encapsulated telephony signals, among others 🎀. Attackers might try to modify SDP bodies, for example, to point RTP media streams at a wiretapping device so they can eavesdrop on voice calls 👀.
Also note that some header fields in SIP are meaningful end-to-end, like Subject. UAs might be protective of these header fields as well as bodies, since a sneaky intermediary changing the Subject could make an important request look like spam 📩. However, lots of header fields are legitimately inspected or altered by proxy servers as a request gets routed, so not all header fields should be secured end-to-end 🧚.
For these reasons, the UA might want to secure SIP message bodies, and in some limited cases header fields, end-to-end. The security services required for bodies include confidentiality, integrity, and authentication. These end-to-end services should be independent of the means used to secure interactions with intermediaries such as proxy servers 🦋.
26.1.4 Tearing Down Sessions 💔
Once a dialog has been established by initial messaging, later requests can be sent that modify the state of the dialog and/or session. It is critical that principals in a session can be certain those requests aren't forged by attackers 😤.
Picture this: a third-party attacker captures some initial messages in a dialog shared by two parties, just to learn the parameters of the session (To tag, From tag, and so forth). Then they inject a BYE request into the session 📞. The attacker could forge it so it seems to come from either participant, and once the BYE reaches its target, the session gets torn down prematurely 💥.
Similar mid-session threats include forged re-INVITEs that alter the session, maybe to reduce session security or redirect media streams as part of a wiretapping attack 🕵️.
The most effective countermeasure to this threat is authenticating the sender of the BYE. In this instance, the recipient only needs to know the BYE came from the same party the corresponding dialog was established with, as opposed to working out the sender's absolute identity 🫶. Also, if the attacker can't learn the parameters of the session because of confidentiality, forging the BYE wouldn't be possible. However, some intermediaries (like proxy servers) will need to inspect those parameters as the session is established 🫠.
26.1.5 Denial of Service and Amplification 🌊
Denial-of-service attacks focus on rendering a particular network element unavailable, usually by directing an excessive amount of network traffic at its interfaces 🚨. A distributed denial-of-service attack lets one network user cause multiple network hosts to flood a target host with a huge amount of traffic 😱.
In many architectures, SIP proxy servers face the public Internet so they can accept requests from worldwide IP endpoints 🌍. SIP creates a bunch of potential opportunities for distributed denial-of-service attacks, and implementers and operators of SIP systems must recognize and address them 🛡️.
Attackers can create bogus requests that contain a falsified source IP address and a corresponding Via header field, identifying a targeted host as the originator of the request. Then they send those requests to a large number of SIP network elements, using hapless SIP UAs or proxies to generate denial-of-service traffic aimed at the target 😈.
Similarly, attackers might use falsified Route header field values in a request that identify the target host, then send those messages to forking proxies that will amplify the messaging sent to the target 📢.
Record-Route could be used to similar effect when the attacker is certain that the SIP dialog initiated by the request will result in numerous transactions originating in the backwards direction 🔁.
A number of denial-of-service attacks open up if REGISTER requests are not properly authenticated and authorized by registrars 🙃. Attackers could de-register some or all users in an administrative domain, which stops those users from being invited to new sessions. An attacker could also register a large number of contacts designating the same host for a given address-of-record, using the registrar and any associated proxy servers as amplifiers in a denial-of-service attack. Attackers might also try to deplete the available memory and disk resources of a registrar by registering huge numbers of bindings 🫣.
The use of multicast to transmit SIP requests can greatly increase the potential for denial-of-service attacks 📡.
These problems show a general need to define architectures that minimize the risks of denial-of-service, and the need to be mindful of this class of attacks in recommendations for security mechanisms 💜.
26.2 Security Mechanisms 🔐
From the threats described above, we gather that the fundamental security services required for the SIP protocol are: preserving the confidentiality and integrity of messaging, preventing replay attacks or message spoofing, providing for the authentication and privacy of the participants in a session, and preventing denial-of-service attacks. Bodies within SIP messages separately require the security services of confidentiality, integrity, and authentication 🌸.
Rather than defining new security mechanisms specific to SIP, SIP reuses existing security models derived from the HTTP and SMTP space wherever possible 🫶.
Full encryption of messages gives the best means to preserve the confidentiality of signaling, and it can also guarantee that messages are not modified by malicious intermediaries 🔒. However, SIP requests and responses can't be naively encrypted end-to-end in their entirety, because fields like the Request-URI, Route, and Via need to be visible to proxies in most network architectures so SIP requests get routed correctly 🗺️. Note that proxy servers also need to modify some features of messages (like adding Via header field values) in order for SIP to function. Proxy servers must therefore be trusted, to some degree, by SIP UAs. For this purpose, low-layer security mechanisms for SIP are recommended. They encrypt the entire SIP request or response on the wire on a hop-by-hop basis, and they allow endpoints to verify the identity of the proxy servers they send requests to 🧱.
SIP entities also have a need to identify one another in a secure fashion. When a SIP endpoint asserts the identity of its user to a peer UA or to a proxy server, that identity should in some way be verifiable. A cryptographic authentication mechanism is provided in SIP to address this requirement 🪪.
An independent security mechanism for SIP message bodies supplies an alternative means of end-to-end mutual authentication, and it also limits the degree to which user agents must trust intermediaries 🦋.
26.2.1 Transport and Network Layer Security 🧱
Transport or network layer security encrypts signaling traffic, guaranteeing message confidentiality and integrity 🔐.
Oftentimes, certificates are used in the establishment of lower-layer security, and these certificates can also be used to provide a means of authentication in many architectures 📜.
Two popular alternatives for providing security at the transport and network layer are, respectively, TLS [25] and IPSec [26] 👑.
IPSec is a set of network-layer protocol tools that collectively can be used as a secure replacement for traditional IP (Internet Protocol). IPSec is most commonly used in architectures in which a set of hosts or administrative domains have an existing trust relationship with one another. IPSec is usually implemented at the operating system level in a host, or on a security gateway that provides confidentiality and integrity for all traffic it receives from a particular interface (as in a VPN architecture). IPSec can also be used on a hop-by-hop basis 🌐.
In many architectures IPSec does not require integration with SIP applications. IPSec is perhaps best suited to deployments in which adding security directly to SIP hosts would be arduous. UAs that have a pre-shared keying relationship with their first-hop proxy server are also good candidates to use IPSec. Any deployment of IPSec for SIP would require an IPSec profile describing the protocol tools that would be required to secure SIP. No such profile is given in this document 📝.
TLS provides transport-layer security over connection-oriented protocols (for the purposes of this document, TCP). "tls" (signifying TLS over TCP) can be specified as the desired transport protocol within a Via header field value or a SIP-URI. TLS is most suited to architectures in which hop-by-hop security is required between hosts with no pre-existing trust association. For example, Alice trusts her local proxy server, which after a certificate exchange decides to trust Bob's local proxy server, which Bob trusts, hence Bob and Alice can communicate securely 🤝.
TLS must be tightly coupled with a SIP application. Note that transport mechanisms are specified on a hop-by-hop basis in SIP, thus a UA that sends requests over TLS to a proxy server has no assurance that TLS will be used end-to-end.
Heads up bestie: TLS on one hop does not mean TLS all the way end-to-end. Don't assume it does 🙅♀️.
The TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6] MUST be supported at a minimum by implementers when TLS is used in a SIP application. For purposes of backwards compatibility, proxy servers, redirect servers, and registrars SHOULD support TLS_RSA_WITH_3DES_EDE_CBC_SHA. Implementers MAY also support any other ciphersuite 🔑.
26.2.2 SIPS URI Scheme ✨
okay so the SIPS URI scheme follows the exact same syntax as the SIP URI (the one we covered back in 19) 💅. the only thing that changes is the scheme string, which is sips instead of sip. but the semantics are literally so different 🫶. SIPS basically means "this resource has to be reached securely" 🔒
A SIPS URI can be used as an address-of-record for a user, which is the URI they're canonically known by (on their business cards, in the From header field of their requests, in the To header field of REGISTER requests) 🎀. When it's the Request-URI of a request, the SIPS scheme means every hop the request gets forwarded over has to be secured with TLS, until the request reaches the SIP entity responsible for the domain portion of the Request-URI 🔐. Once it reaches that domain, it's handled according to local security and routing policy, which could quite possibly use TLS for any last hop to a UAS 🦋. When the originator of a request uses a SIPS URI (like if they put one in as the address-of-record of the target), SIPS says the entire request path to the target domain has to be secured 👑.
The SIPS scheme works for a lot of other places where SIP URIs show up today, not just the Request-URI 🌈. That includes addresses-of-record, contact addresses (the contents of Contact headers, including the ones in REGISTER methods), and Route headers. In each of these spots, the SIPS URI scheme lets the existing fields point at secure resources ✨. How a SIPS URI gets dereferenced in any of these contexts has its own security properties, which are detailed in [4] 🧚.
Note that in the SIPS URI scheme, transport is independent of TLS, and thus "sips:alice@atlanta.com;transport=tcp" and "sips:alice@atlanta.com;transport=sctp" are both valid (although note that UDP is not a valid transport for SIPS). The use of "transport=tls" has consequently been deprecated, partly because it was specific to a single hop of the request. This is a change since RFC 2543. 🙈
The use of SIPS in particular entails that mutual TLS authentication SHOULD be employed, as SHOULD the ciphersuite TLS_RSA_WITH_AES_128_CBC_SHA. Certificates received in the authentication process SHOULD be validated with root certificates held by the client. Failure to validate a certificate SHOULD result in the failure of the request 💀.
Users that distribute a SIPS URI as an address-of-record may elect to operate devices that refuse requests over insecure transports 🍓.
26.2.3 HTTP Authentication
SIP has a challenge capability based on HTTP authentication 🎀. It relies on the 401 and 407 response codes, plus header fields for carrying challenges and credentials. Without significant modification, reusing the HTTP Digest authentication scheme in SIP allows for replay protection and one-way authentication 🔥.
The usage of Digest authentication in SIP is detailed in Section 22 💅.
26.2.4 S/MIME
okay so as we talked about above, encrypting entire SIP messages end-to-end for confidentiality is not appropriate 🙅♀️. network intermediaries (like proxy servers) need to see certain header fields to route messages correctly. if those intermediaries are excluded from security associations, SIP messages basically become non-routable 💀.
BUT S/MIME lets SIP UAs encrypt MIME bodies within SIP 🫶. That means the bodies are secured end-to-end without touching the message headers ✨. S/MIME can give end-to-end confidentiality and integrity for message bodies, plus mutual authentication. It's also possible to use S/MIME for a form of integrity and confidentiality for SIP header fields through SIP message tunneling 🦋.
The usage of S/MIME in SIP is detailed in Section 23 🌸.
26.3 Implementing Security Mechanisms 🛡️
26.3.1 Requirements for Implementers of SIP
Proxy servers, redirect servers, and registrars MUST implement TLS, and MUST support both mutual and one-way authentication 👑. It is strongly RECOMMENDED that UAs be capable of initiating TLS. UAs MAY also be capable of acting as a TLS server 🎀. Proxy servers, redirect servers, and registrars SHOULD possess a site certificate whose subject corresponds to their canonical hostname 🔐. UAs MAY have certificates of their own for mutual authentication with TLS, but no provisions are set forth in this document for their use 🙈.
All SIP elements that support TLS MUST have a mechanism for validating certificates received during TLS negotiation. This entails possession of one or more root certificates issued by certificate authorities (preferably well-known distributors of site certificates, comparable to those that issue root certificates for web browsers) 💅.
All SIP elements that support TLS MUST also support the SIPS URI scheme 🫶.
Proxy servers, redirect servers, registrars, and UAs MAY also implement IPSec or other lower-layer security protocols 🦋.
When a UA attempts to contact a proxy server, redirect server, or registrar, the UAC SHOULD initiate a TLS connection over which it will send SIP messages. In some architectures, UASs MAY receive requests over such TLS connections as well 🌈.
Proxy servers, redirect servers, registrars, and UAs MUST implement Digest Authorization, encompassing all of the aspects required in 22. Proxy servers, redirect servers, and registrars SHOULD be configured with at least one Digest realm. At least one "realm" string supported by a given server SHOULD correspond to the server's hostname or domainname 🔥.
UAs MAY support the signing and encrypting of MIME bodies, and transference of credentials with S/MIME as described in Section 23 ✨. If a UA holds one or more root certificates of certificate authorities in order to validate certificates for TLS or IPSec, it SHOULD be capable of reusing these to verify S/MIME certificates, as appropriate. A UA MAY hold root certificates specifically for validating S/MIME certificates 🧚.
Note that is it anticipated that future security extensions may upgrade the normative strength associated with S/MIME as S/MIME implementations appear and the problem space becomes better understood. 🍓
26.3.2 Security Solutions
The operation of these security mechanisms in concert can follow the existing web and email security models to some degree 🌸. At a high level, UAs authenticate themselves to servers (proxy servers, redirect servers, and registrars) with a Digest username and password. Servers authenticate themselves to UAs one hop away, or to another server one hop away (and vice versa), with a site certificate delivered by TLS 🔐.
On a peer-to-peer level, UAs trust the network to authenticate one another ordinarily. However, S/MIME can also be used to provide direct authentication when the network does not, or if the network itself is not trusted 🦋.
The following is an illustrative example in which these security mechanisms are used by various UAs and servers to prevent the sorts of threats described in Section 26.1. While implementers and network administrators MAY follow the normative guidelines given in the remainder of this section, these are provided only as example implementations 💖.
26.3.2.1 Registration
When a UA comes online and registers with its local administrative domain, it SHOULD establish a TLS connection with its registrar (Section 10 describes how the UA reaches its registrar) 🌈. The registrar SHOULD offer a certificate to the UA, and the site identified by the certificate MUST correspond with the domain in which the UA intends to register. For example, if the UA intends to register the address-of-record 'alice@atlanta.com', the site certificate must identify a host within the atlanta.com domain (such as sip.atlanta.com) 🎀. When it receives the TLS Certificate message, the UA SHOULD verify the certificate and inspect the site identified by the certificate. If the certificate is invalid, revoked, or if it does not identify the appropriate party, the UA MUST NOT send the REGISTER message and otherwise proceed with the registration 🙅♀️.
When a valid certificate has been provided by the registrar, the UA knows that the registrar is not an attacker who might redirect the UA, steal passwords, or attempt any similar attacks. 👑
The UA then creates a REGISTER request that SHOULD be addressed to a Request-URI corresponding to the site certificate received from the registrar 🧚. When the UA sends the REGISTER request over the existing TLS connection, the registrar SHOULD challenge the request with a 401 (Proxy Authentication Required) response. The "realm" parameter within the Proxy-Authenticate header field of the response SHOULD correspond to the domain previously given by the site certificate 🔥. When the UAC receives the challenge, it SHOULD either prompt the user for credentials or take an appropriate credential from a keyring corresponding to the "realm" parameter in the challenge. The username of this credential SHOULD correspond with the "userinfo" portion of the URI in the To header field of the REGISTER request 💅. Once the Digest credentials have been inserted into an appropriate Proxy-Authorization header field, the REGISTER should be resubmitted to the registrar ✨.
Since the registrar requires the user agent to authenticate itself, it would be difficult for an attacker to forge REGISTER requests for the user's address-of-record. Also note that since the REGISTER is sent over a confidential TLS connection, attackers will not be able to intercept the REGISTER to record credentials for any possible replay attack. 🦋
Once the registration has been accepted by the registrar, the UA SHOULD leave this TLS connection open, provided that the registrar also acts as the proxy server to which requests are sent for users in this administrative domain. The existing TLS connection will be reused to deliver incoming requests to the UA that has just completed registration 🌸.
Because the UA has already authenticated the server on the other side of the TLS connection, all requests that come over this connection are known to have passed through the proxy server. Attackers cannot create spoofed requests that appear to have been sent through that proxy server. 😭🫶
26.3.2.2 Interdomain Requests ✨
okay so now it gets spicy 🌶️ Alice's UA wants to start a session with someone in a totally different admin domain, "bob@biloxi.com" 🧚 Her home turf, atlanta.com, has a local outbound proxy 💅
The proxy that handles inbound requests for a domain MAY also act as the local outbound proxy. For simplicity's sake we're assuming atlanta.com does this, because otherwise the UA would have to open a brand new TLS connection to a separate server right here 🙃 Once Alice has finished registering (see the last section 🎀), she SHOULD reuse that TLS connection to the local proxy whenever she sends an INVITE to someone else. The UA SHOULD also reuse cached credentials in the INVITE so the user isn't getting prompted over and over 🙄
After the local outbound proxy has validated the credentials in the INVITE, it SHOULD look at the Request-URI to figure out how to route the message (see [4]) 🦋 If the "domainname" part had matched the local domain (atlanta.com) instead of biloxi.com, the proxy would have checked its location service to find the best way to reach the person 💖
Had "alice@atlanta.com" been trying to reach "alex@atlanta.com", the local proxy would have forwarded the request over the TLS connection Alex set up with the registrar when he signed in. Since Alex gets the request over his authenticated channel, he can be sure the local proxy server had authorized Alice's request 🫶
But here the Request-URI points at a different domain 😤 So the local outbound proxy at atlanta.com SHOULD set up a TLS connection with the remote proxy at biloxi.com. Both ends of this connection are servers with site certificates, so mutual TLS authentication SHOULD happen 🔥 Each side SHOULD check and inspect the other's certificate, paying attention to the domain name in it so it can be compared against the SIP message header fields. For example, the atlanta.com proxy SHOULD verify at this point that the certificate it got back belongs to biloxi.com 🕵️♀️ Once that checks out and TLS negotiation is done, leaving a secure channel between the two proxies, atlanta.com can forward the INVITE to biloxi.com ✨
The proxy at biloxi.com SHOULD inspect the atlanta.com proxy's certificate in turn, and compare the domain the certificate claims against the "domainname" part of the From header field in the INVITE 🎀 The biloxi proxy MAY have a strict security policy that makes it reject any request that doesn't match the administrative domain it was proxied from 🛡️
Policies like this could be set up to stop the SIP version of SMTP 'open relays', which get abused all the time to send spam 🙅♀️
Here's the catch though 🧐 This policy only proves the request came from the domain it says it came from. It doesn't let biloxi.com know how atlanta.com authenticated Alice. Only if biloxi.com somehow knows atlanta.com's authentication policies could it figure out how Alice proved who she was 👀 biloxi.com could even get stricter and refuse requests from any domain that isn't administratively known to share an authentication policy with it 🚫
Once the biloxi proxy has approved the INVITE, the proxy SHOULD find the existing TLS channel, if there is one, tied to the person being targeted (here, "bob@biloxi.com") 💜 The INVITE should be proxied to Bob through that channel. Since it arrived over a TLS connection previously authenticated as the biloxi proxy, Bob knows the From header field wasn't tampered with, and that atlanta.com has validated Alice. He doesn't necessarily know whether he should trust Alice's identity, though 🤔
Before forwarding the request, both proxy servers SHOULD add a Record-Route header field to it, so every future request in this dialog goes through them 🧚 That way the proxies keep providing security services for the whole life of the dialog 💅 If the proxies don't add themselves to Record-Route, future messages go straight end-to-end between Alice and Bob with no security services (unless the two of them agree on some independent end-to-end security, like S/MIME). The SIP trapezoid model is honestly such a cute structure here, because the agreements between the site proxies can give Alice and Bob a reasonably secure channel ✨
An attacker trying to mess with this setup couldn't, for example, forge a BYE request and shove it into the signaling stream between Bob and Alice. They don't know the session's parameters, and the integrity mechanism also protects the traffic between Alice and Bob end to end 🔒 Iconic. Literally untouchable 💀
26.3.2.3 Peer-to-Peer Requests ✨
Now the other scenario 🌸 Say Carol, who's asserting the identity "carol@chicago.com", has no local outbound proxy. When she wants to send an INVITE to "bob@biloxi.com", her UA SHOULD open a TLS connection straight to the biloxi proxy (using the mechanism described in [4] to work out the best way to reach the given Request-URI) 🦋 When her UA gets a certificate from the biloxi proxy, it SHOULD verify it normally before she sends her INVITE across that TLS connection 🔐
Here's the tricky part 😬 Carol can't prove her identity to the biloxi proxy. What she does have is a CMS-detached signature over a "message/sip" body in the INVITE. It's pretty unlikely Carol has any credentials in the biloxi.com realm, since she has no formal relationship with biloxi.com 🙈 The biloxi proxy MAY also have a strict policy that stops it from even bothering to challenge requests whose "domainname" part of the From header field isn't biloxi.com. It just treats those users as unauthenticated 🚫
The biloxi proxy has a policy for Bob: every non-authenticated request should be redirected to the right contact address registered for 'bob@biloxi.com', which is <sip:bob@192.0.2.4> 📍 Carol gets that redirection response over the TLS connection she made with the biloxi proxy, so she can trust that the contact address is legit 💖
Carol SHOULD then open a TCP connection to the address she was given and send a new INVITE with a Request-URI containing that contact address. She has to recompute the signature in the body while she's getting the request ready ✍️ Bob gets this INVITE over an insecure interface, but his UA checks it out. In this case it recognizes the From header field and matches a locally cached certificate against the one in the body's signature 🕵️♀️ He replies the same way, proving himself to Carol, and then a secure dialog begins 🎉
Sometimes firewalls or NATs in an administrative domain stop a direct TCP connection to a UA from being set up 🧱 In those cases, proxy servers could potentially relay requests to UAs in a way that has no trust implications, like skipping an existing TLS connection and forwarding over cleartext TCP, as local policy dictates 🙃
26.3.2.4 DoS Protection 🛡️
To keep the denial-of-service risk low for setups using these security solutions, implementers should take note of the following guidelines 💅
When the host running a SIP proxy server is routable from the public Internet, it SHOULD be deployed in an administrative domain with defensive operational policies, like blocking source-routed traffic and, ideally, filtering ping traffic 🧱 TLS and IPSec can also use bastion hosts at the edges of the administrative domains taking part in the security associations. Those bastion hosts aggregate the secure tunnels and sockets, and they can take the brunt of denial-of-service attacks so SIP hosts inside the domain don't get buried in superfluous messaging 🫶
No matter what security solutions you deploy, floods of messages aimed at proxy servers can lock up their resources and stop desirable traffic from reaching its destination 😭 Processing a SIP transaction at a proxy costs something computationally, and that cost is higher for stateful proxy servers than for stateless ones. So stateful proxies are more vulnerable to flooding than stateless proxy servers are 🌊
UAs and proxy servers SHOULD challenge questionable requests with only a single 401 (Unauthorized) or 407 (Proxy Authentication Required), skipping the normal response retransmission algorithm. That way they behave statelessly toward unauthenticated requests 🤫
Retransmitting a 401 (Unauthorized) or 407 (Proxy Authentication Required) status response makes the problem worse, because an attacker can use a falsified header field value, like Via, to direct traffic at a third party 💀
To wrap this up, mutual authentication of proxy servers through mechanisms like TLS really cuts down the chances of rogue intermediaries slipping in falsified requests or responses that deny service 🔒 That also makes it much harder for attackers to turn innocent SIP nodes into amplification agents 🌈
26.4 Limitations 🌸
These security mechanisms can thwart a lot of threats when they're applied judiciously, but there are limits to what they cover, and implementers and network operators need to understand them 🧐
26.4.1 HTTP Digest 🍓
One of the big limitations of using HTTP Digest in SIP is that Digest's integrity mechanisms don't work very well for SIP 😬 They protect the Request-URI and the method of a message, but not the header fields UAs would most want to secure 🙈
The replay protection mechanisms described in RFC 2617 also have some limitations for SIP. The next-nonce mechanism, for example, doesn't support pipelined requests. The nonce-count mechanism should be used for replay protection 🔁
Another limitation of HTTP Digest is the scope of realms. Digest is super valuable when a user wants to authenticate to a resource they already have a relationship with, like a service provider they're a customer of. That's a really common scenario, so Digest is genuinely useful there 💖 TLS is different, though. Its scope is interdomain, or multirealm, because certificates are often globally verifiable. That means a UA can authenticate the server without any pre-existing association 🌍✨
26.4.2 S/MIME 🔐
okay bestie, the biggest problem with S/MIME is that regular end users don't have a prevalent public key infrastructure 😭. If self-signed certificates (or certificates that cannot be verified by one of the participants in a dialog) are used, the SIP-based key exchange mechanism described in Section 23.2 is susceptible to a man-in-the-middle attack. An attacker can potentially inspect and modify S/MIME bodies 👀. The attacker needs to intercept the first exchange of keys between the two parties in a dialog, remove the existing CMS-detached signatures from the request and response, and insert a different CMS-detached signature containing a certificate supplied by the attacker. That certificate has to seem like it belongs to the proper address-of-record 🙃. Then each party thinks they've exchanged keys with the other, when really each one has the public key of the attacker. Lowkey terrifying 💀
It's important to note that the attacker can only pull this off on the first exchange of keys between two parties. On later occasions, the change in the key would be noticeable to the UAs 🚨. It would also be hard for the attacker to stay in the path of all future dialogs between the two parties over time, as days, weeks, or years pass 🕰️.
SSH is susceptible to the same man-in-the-middle attack on the first exchange of keys. However, it's widely acknowledged that while SSH isn't perfect, it does improve the security of connections 🔒. Key fingerprints could help SIP too, just like they do for SSH ✨. For example, if two parties use SIP to set up a voice communications session, each could read off the fingerprint of the key they received from the other, and that could be compared against the original. It would be way harder for the man-in-the-middle to imitate the participants' voices than their signaling 🎙️. (This is a practice that was used with the Clipper chip-based secure telephone, iykyk 🫶.)
The S/MIME mechanism lets UAs send encrypted requests without preamble if they have a certificate for the destination address-of-record on their keyring 🗝️. But any particular device registered for an address-of-record might not hold the certificate that the device's current user has used before. So it may be unable to process an encrypted request properly, which could lead to some avoidable error signaling 😩. This is especially likely when an encrypted request is forked 🍴.
S/MIME keys are most useful when they're tied to a particular user (an address-of-record) rather than a device (a UA) 👑. When users move between devices, it can be tricky to transport private keys securely between UAs 📦. How such keys might be acquired by a device is outside the scope of this document, so we're leaving that one alone 🙈.
Another, more prosaic difficulty is that S/MIME can result in very large messages, especially when the SIP tunneling mechanism described in Section 23.4 is used 📏. For that reason, it is RECOMMENDED that TCP should be used as a transport protocol when S/MIME tunneling is employed 🧦.
26.4.3 TLS 🛡️
The most commonly voiced concern about TLS is that it can't run over UDP 🙅♀️. TLS needs a connection-oriented underlying transport protocol, which for the purposes of this document means TCP 🔌.
It may also be arduous for a local outbound proxy server and/or registrar to maintain many simultaneous long-lived TLS connections with lots of UAs 😮💨. This brings up some valid scalability concerns, especially for intensive ciphersuites 📉. Keeping long-lived TLS connections redundant can also be cumbersome, especially when a UA is solely responsible for setting them up 🥲.
TLS only lets SIP entities authenticate servers they're adjacent to. TLS offers strictly hop-by-hop security 🪜. Neither TLS nor any other mechanism specified in this document lets clients authenticate proxy servers they can't form a direct TCP connection to 🚫.
26.4.4 SIPS URIs 🔗
Actually using TLS on every segment of a request path means the terminating UAS must be reachable over TLS (perhaps by registering with a SIPS URI as a contact address) 🤓. This is the preferred use of SIPS 💖. But many valid architectures use TLS to secure part of the request path and rely on some other mechanism for the final hop to a UAS, for example. So SIPS can't guarantee that TLS usage will be truly end-to-end 💔. Also, since many UAs won't accept incoming TLS connections, even UAs that do support TLS may need to maintain persistent TLS connections, as described in the TLS limitations section above, in order to receive requests over TLS as a UAS 🔁.
Location services aren't required to provide a SIPS binding for a SIPS Request-URI 🤷♀️. Location services are commonly populated by user registrations (as described in Section 10.2.1), but various other protocols and interfaces could conceivably supply contact addresses for an AOR. Those tools are free to map SIPS URIs to SIP URIs as appropriate 🗺️. When queried for bindings, a location service returns its contact addresses without regard for whether it received a request with a SIPS Request-URI. If a redirect server is accessing the location service, it's up to the entity that processes the Contact header field of a redirection to decide whether the contact addresses are proper 🧐.
Making sure TLS is used for all of the request segments up to the target domain is kinda complicated 😵💫. Cryptographically authenticated proxy servers along the way might be non-compliant or compromised, and they may choose to disregard the forwarding rules associated with SIPS (and the general forwarding rules in Section 16.6) 😈. Malicious intermediaries could, for example, retarget a request from a SIPS URI to a SIP URI in an attempt to downgrade security 📉.
On the flip side, an intermediary might legitimately retarget a request from a SIP to a SIPS URI ✨. So recipients of a request whose Request-URI uses the SIPS scheme can't assume, based on the Request-URI alone, that SIPS was used for the entire request path (from the client onwards) 🙅♀️.
To address these concerns, it is RECOMMENDED that recipients of a request whose Request-URI contains a SIP or SIPS URI inspect the To header field value to see if it contains a SIPS URI. (Note that it doesn't count as a breach of security if this URI has the same scheme but isn't equivalent to the URI in the To header field 🤍.) Clients may choose to fill in the Request-URI and To header field of a request differently. But when SIPS is used, that disparity could be read as a possible security violation, and the request could then be rejected by its recipient 🚫. Recipients MAY also inspect the Via header chain to double-check whether or not TLS was used for the entire request path until the local administrative domain was reached 🔍. The originating UAC can also use S/MIME to help make sure the original form of the To header field is carried end-to-end 📮.
If the UAS has reason to believe the scheme of the Request-URI has been improperly modified in transit, the UA SHOULD notify its user of a potential security breach 🚨.
As a further way to prevent downgrade attacks, entities that accept only SIPS requests MAY also refuse connections on insecure ports 🚪.
End users will totally notice the difference between SIPS and SIP URIs, and they may edit them by hand in response to stuff they see 🙄. That can either help or hurt security. For example, if an attacker corrupts a DNS cache and inserts a fake record set that effectively removes all SIPS records for a proxy server, then any SIPS requests that go through that proxy may fail 💀. When a user sees that repeated calls to a SIPS AOR are failing, they could, on some devices, manually change the scheme from SIPS to SIP and retry 😬. There are some safeguards against this (if the destination UA is truly paranoid, it could refuse all non-SIPS requests), but it's a limitation worth noting 🧱. On the bright side, users might also figure out that 'SIPS' would be valid even when they're only shown a SIP URI 🧠.
26.5 Privacy 🫣
SIP messages often contain sensitive info about their senders. It's not just what they have to say, but who they talk to, when they talk, how long, and where they're taking part in sessions 👀. Lots of applications and their users need this kind of private info hidden from any parties who don't need to know it 🤫.
There are also sneakier ways private info can leak 🕵️♀️. If a user or service chooses to be reachable at an address that's guessable from the person's name and organizational affiliation (which describes most addresses-of-record), the old trick of keeping your number unlisted is ruined 📵. A user location service can invade the privacy of someone receiving a session invitation by spilling their exact whereabouts to the caller 📍. So an implementation SHOULD be able to restrict, on a per-user basis, what kind of location and availability information gets given out to certain classes of callers 🛑. This whole class of problem is expected to be studied further in ongoing SIP work 🔬.
Sometimes users want to hide personal info in header fields that show identity 🎭. This can apply not only to the From and related headers that represent the request's originator, but also to To. It may not be appropriate to tell the final destination about a speed-dialing nickname, or an unexpanded identifier for a group of targets 🙊. Either of those would be removed from the Request-URI as the request is routed, but not changed in the To header field if the two were initially identical. So it MAY be desirable, for privacy reasons, to create a To header field that differs from the Request-URI 🎀.
27 IANA Considerations 📋
All method names, header field names, status codes, and option tags used in SIP applications are registered with IANA through instructions in an IANA Considerations section in an RFC 🗂️.
The specification tells IANA to create four new sub-registries under http://www.iana.org/assignments/sip-parameters: Option Tags, Warning Codes (warn-codes), Methods and Response Codes, and they get added to the sub-registry of Header Fields that's already there 🧚✨
27.1 Option Tags ✨
Okay so this bit sets up the Option Tags sub-registry over at http://www.iana.org/assignments/sip-parameters 🎀
Option tags show up in header fields like Require, Supported, Proxy-Require, and Unsupported. They're how SIP endpoints support compatibility for extensions (Section 19.2) 💖 Each option tag is a string that stands for one specific SIP option (aka an extension), so endpoints can tell which one is being talked about 🦋
IANA registers an option tag once it's published in a standards track RFC. The IANA Considerations section of that RFC has to include the info below, and it ends up in the registry next to the RFC number 💅
- Name of the option tag. The name MAY be of any length, but SHOULD be no more than twenty characters long. The name MUST consist of alphanum (Section 25) characters only. 🌸
- Descriptive text that describes the extension. 🧚
27.2 Warn-Codes 🌈
This spec sets up the Warn-codes sub-registry at http://www.iana.org/assignments/sip-parameters and fills it with the warn-codes from Section 20.43 to start. More warn-codes get added whenever a new RFC is published ⭐
Here's the descriptive text for the warn-code table, in my own words: warning codes give extra info alongside the status code in SIP responses, for when a transaction failed because of a Session Description Protocol (SDP) (RFC 2327 [1]) problem 🫶
Every "warn-code" is three digits. A first digit of "3" means the warning is specific to SIP. Until a future spec describes warn-codes outside the 3xx range, only 3xx ones can be registered 🙈
The ranges are split up like this 🍓
- 300 through 329 are for problems with keywords in the session description.
- 330 through 339 are for warnings about basic network services asked for in the session description.
- 370 through 379 are for warnings about quantitative QoS parameters asked for in the session description.
- 390 through 399 are miscellaneous warnings that don't fit into any of the above 💜
27.3 Header Field Names 💖
This obsoletes the older IANA instructions for the header sub-registry at http://www.iana.org/assignments/sip-parameters 🦋
To register a brand new header field name, your RFC publication needs to include the following 🎀
- The RFC number in which the header is registered;
- the name of the header field being registered;
- a compact form version for that header field, if one is defined;
Some common, widely used header fields MAY get one-letter compact forms (Section 7.3.3) ✨ Compact forms can only be assigned after SIP working group review, followed by RFC publication 👑
27.4 Method and Response Codes 🧚
This spec sets up the Method and Response-Code sub-registries at http://www.iana.org/assignments/sip-parameters and fills them in like this. The starting Methods table looks like this 💅
INVITE [RFC3261]
ACK [RFC3261]
BYE [RFC3261]
CANCEL [RFC3261]
REGISTER [RFC3261]
OPTIONS [RFC3261]
INFO [RFC2976]The response code table starts out filled with the codes from Section 21. Specifically, the parts labeled Informational, Success, Redirection, Client-Error, Server-Error, and Global-Failure 🌈 The table is laid out like this 🫶
Type (e.g., Informational)
Number Default Reason Phrase [RFC3261]To register a new response code or method, your RFC publication needs to include the following 🔥
- The RFC number in which the method or response code is registered;
- the number of the response code or name of the method being registered;
- the default reason phrase for that response code, if applicable;
27.5 The "message/sip" MIME type. 🎀
This document registers the "message/sip" MIME media type so SIP messages can be tunneled as bodies inside SIP. The main reason is end-to-end security 🔐 Here's the info for it 💖
Media type name: message
Media subtype name: sip
Required parameters: none
Optional parameters: version
version: The SIP-Version number of the enclosed message (e.g.,
"2.0"). If not present, the version defaults to "2.0".
Encoding scheme: SIP messages consist of an 8-bit header
optionally followed by a binary MIME data object. As such, SIP
messages must be treated as binary. Under normal circumstances
SIP messages are transported over binary-capable transports, no
special encodings are needed.
Security considerations: see below
Motivation and examples of this usage as a security mechanism
in concert with S/MIME are given in 23.4.Quick translation of the encoding part: SIP messages are an 8-bit header that can optionally be followed by a binary MIME data object, so they have to be treated as binary. In normal cases they go over binary-capable transports, so no special encodings are needed 🦋
Also, the motivation and examples for using it as a security mechanism alongside S/MIME are in 23.4 🫶
27.6 New Content-Disposition Parameter Registrations 🌸
This document also registers four new Content-Disposition header "disposition-types": alert, icon, session, and render. The authors ask that these values get recorded in the IANA registry for Content-Dispositions 🔔
The descriptions for these "disposition-types", including motivation and examples, are in Section 20.11 💜
Short descriptions for the IANA registry look like this 🎀
alert the body is a custom ring tone to alert the user
icon the body is displayed as an icon to the user
render the body should be displayed to the user
session the body describes a communications session, for
example, as RFC 2327 SDP body28 Changes From RFC 2543 💅
This RFC revises RFC 2543, and it's mostly backwards compatible with it 🦋 The changes here fix a bunch of errors found in RFC 2543 and cover scenarios RFC 2543 didn't get into. The protocol is also presented in a more cleanly layered model now ✨
The differences are split into two buckets. The first is functional behavior that's a big change from RFC 2543 and can affect interoperability or correct operation in some cases. The second is functional behavior that's different from RFC 2543 but isn't a likely source of interoperability problems 🌈 There have also been countless clarifications, which aren't written down here 🙈
28.1 Major Functional Changes ✨
- Okay so, when a UAC wants to bail on a call before it's answered 📞, it sends
CANCEL. If the originalINVITEstill comes back with a 2xx anyway 😭, the UAC then sendsBYE.BYEcan only be sent on an existing call leg (this RFC calls that a dialog now 💅), whereas RFC 2543 let you send it at any time 🙈 - The SIP BNF got converted to be RFC 2234 compliant 📝
- The SIP URL BNF got a glow-up 💖 It allows a bigger set of characters in the user part. Comparison rules were simplified to be mostly case-insensitive, and there's now a detailed description of comparing URIs when parameters are involved. The biggest change is that a URI with a parameter set to its default value does not match a URI without that parameter 👀
- Via hiding is gone 🙅♀️ It had serious trust issues, since it depended on the next hop doing the obfuscation. Now Via hiding is just a local implementation choice in stateful proxies, so it's no longer documented 🫶
- In RFC 2543,
CANCELandINVITEtransactions were all tangled up together. They're separated now 🧚 If a user sends anINVITEand then aCANCEL, theINVITEtransaction still terminates normally. A UAS needs to respond to the originalINVITErequest with a 487 response 🌸 - Same energy for
CANCELandBYE💀 RFC 2543 let the UAS skip responding to theINVITEwhen aBYEcame in. That's disallowed here. The originalINVITEneeds a response ✨ - In RFC 2543, UAs only had to support UDP. Here, UAs need to support both UDP and TCP 🌈
- In RFC 2543, a forking proxy only passed up one challenge from downstream when there were multiple challenges. Here, proxies are supposed to collect all the challenges and put them into the forwarded response 🎀
- In Digest credentials, the URI needs to be quoted. This is unclear in RFC 2617 and RFC 2069, which are both inconsistent about it 🤷♀️
- SDP processing got split off into its own specification [13] 🍓 It's now a formal offer/answer exchange that's basically tunneled through SIP. SDP is allowed in INVITE/200 or 200/ACK for baseline SIP implementations. RFC 2543 hinted at using it in
INVITE, 200, and ACK all in one transaction, but that wasn't well specified. More complex SDP usages are allowed in extensions 🦋 - Full IPv6 support is in, both in URIs and in the
Viaheader field 🌐 To make that work, theViaheader field parameters had to allow the square bracket and colon characters, which weren't permitted before. In theory, that could cause interop problems with older implementations. But we've observed that most implementations accept any non-control ASCII character in these parameters 💜 - The DNS SRV procedure now lives in a separate specification [4] 🧚 It uses both SRV and NAPTR resource records and no longer combines data across SRV records like RFC 2543 did ✨
- Loop detection is now optional 🫧 It's been replaced by mandatory usage of
Max-Forwards. The RFC 2543 loop detection procedure had a serious bug where it reported "spirals" as an error when they weren't errors at all 😭 The optional loop detection procedure is now specified more fully and correctly here 👑 - Tags are now mandatory (they were optional in RFC 2543) because they're the fundamental building blocks of dialog identification 🔥
- The
Supportedheader field got added 🎉 Clients can use it to tell a server which extensions they support. The server can apply those extensions to the response and show it's using them with aRequirein the response 💅 - Extension parameters were missing from the BNF for several header fields. They've been added 🌸
- Route and Record-Route construction was super underspecified in RFC 2543, and it wasn't even the right approach 💀 It's been substantially reworked in this specification (and made vastly simpler), and honestly this is arguably the biggest change 👑 Backwards compatibility is still provided for deployments that don't use "pre-loaded routes", where the initial request already has a set of
Routeheader field values obtained somehow outside of Record-Route. In those situations, the new mechanism is not interoperable 🙈 - In RFC 2543, lines in a message could end with CR, LF, or CRLF. This specification only allows CRLF 📏
- Usage of
RouteinCANCELandACKwasn't well defined in RFC 2543, but it's well specified now 🎀 If a request had aRouteheader field, itsCANCELorACKfor a non-2xx response to that request needs to carry the sameRouteheader field values.ACKs for 2xx responses use the Route values learned from the Record-Route of the 2xx responses 🦋 - RFC 2543 allowed multiple requests in a single UDP packet. That usage has been removed 📦
- Absolute time in the
Expiresheader field and parameter has been removed ⏰ It caused interoperability problems with elements that weren't time synchronized, which is a super common situation 😭 Relative times are used instead 🫶 - The
branchparameter of theViaheader field value is now mandatory for all elements to use 🔥 It plays the role of a unique transaction identifier now, which avoids the complex and bug-laden transaction identification rules from RFC 2543 💖 A magic cookie is used in the parameter value to figure out whether the previous hop made the parameter globally unique. When it isn't present, comparison falls back to the old rules, so interoperability is assured 🌈 - In RFC 2543, closing a TCP connection was treated as equivalent to a
CANCEL. That was nearly impossible to implement (and wrong) for TCP connections between proxies 💀 It's been eliminated, so there's no coupling between TCP connection state and SIP processing ✨ - RFC 2543 didn't say whether a UA could start a new transaction to a peer while another one was in progress. That's now specified here: it's allowed for non-INVITE requests and disallowed for
INVITE🧚 - PGP got removed 👋 It wasn't sufficiently specified and wasn't compatible with the more complete PGP MIME. It was replaced with S/MIME 💅
- The
sipsURI scheme was added for end-to-end TLS 🔐 This scheme isn't backwards compatible with RFC 2543. Existing elements that receive a request with asipsURI scheme in the Request-URI will likely reject it. This is honestly a feature 😤 It makes sure a call to asipsURI only gets delivered if all the path hops can be secured 🛡️ - Additional security features were added with TLS, and they're described in a much larger and more complete security considerations section 🔐👑
- In RFC 2543, a proxy wasn't required to forward provisional responses from 101 to 199 upstream. This was changed to MUST 🚨 It's super important, since a lot of later features depend on delivery of all provisional responses from 101 to 199 🫶
- RFC 2543 said pretty much nothing about the 503 response code 😅 It has since found substantial use for indicating failure or overload conditions in proxies, so it needs somewhat special treatment 🍓 Specifically, receiving a 503 should trigger an attempt to contact the next element in the result of a DNS SRV lookup. Also, a proxy only forwards a 503 upstream under certain conditions 🎀
- RFC 2543 defined a mechanism for UA authentication of a server but didn't specify it well enough 💀 That's been removed. Instead, the mutual authentication procedures of RFC 2617 are allowed 🤝
- A UA can't send a
BYEfor a call until it has received anACKfor the initialINVITE🙅♀️ RFC 2543 allowed it, but that leads to a potential race condition 😬 - A UA or proxy can't send
CANCELfor a transaction until it gets a provisional response for the request 🛑 RFC 2543 allowed it, but that leads to potential race conditions too 😭 - The
actionparameter in registrations has been deprecated 🗑️ It wasn't sufficient for any useful services and it caused conflicts when application processing was applied in proxies 🙈 - RFC 2543 had a bunch of special cases for multicast 🌀 For example, certain responses were suppressed, timers were adjusted, and so on. Multicast now plays a more limited role, and protocol operation is unaffected by whether you use multicast or unicast 🦋 The limitations that come with that are documented 📝
- Basic authentication has been removed entirely, and its usage is forbidden 🚫
- Proxies don't forward a 6xx right away when they receive it anymore 🙅♀️ Instead, they
CANCELpending branches immediately. This avoids a potential race condition that would result in a UAC getting a 6xx followed by a 2xx 😱 In all cases except that race condition, the result is the same: the 6xx gets forwarded upstream 💖 - RFC 2543 didn't address request merging 🌀 That's when a request forks at a proxy and later rejoins at an element. Handling of merging is only done at a UA, and procedures are defined for rejecting all but the first request 💅
28.2 Minor Functional Changes 🌸
- The
Alert-Info,Error-Info, andCall-Infoheader fields were added for optional content presentation to users 🎀 - The
Content-Language,Content-Disposition, andMIME-Versionheader fields were added 🌈 - A "glare handling" mechanism was added for when both parties send each other a re-INVITE at the same time 🙃 It uses the new 491 (Request Pending) error code 🔥
- The
In-Reply-ToandReply-Toheader fields were added so you can return missed calls or messages later 📞💜 - TLS and SCTP were added as valid SIP transports 🦋
- There were a bunch of different mechanisms for handling failures at any point during a call, and those are now mostly unified 🫶
BYEis sent to terminate 👋 - RFC 2543 mandated retransmission of INVITE responses over TCP, but it noted this was really only needed for 2xx ✨ That was an artifact of insufficient protocol layering 🧱 With a more coherent transaction layer defined here, it's not needed anymore. Only 2xx responses to INVITEs are retransmitted over TCP 💅
- Client and server transaction machines are now driven by timeouts instead of retransmit counts ⏱️ This lets the state machines be properly specified for both TCP and UDP 🙌
- The
Dateheader field is used in REGISTER responses to give a simple way to auto-configure dates in user agents 📅 - A registrar is now allowed to reject registrations with expirations that are too short 🙅♀️ The 423 response code and the
Min-Expiresheader were defined for this purpose 🎀
29. Normative References 🎀
okay so this is the list of docs that SIP leans on for the real rules, bestie 🫶 every one of these is "required reading" in the sense that the spec points at them for details, so I'm keeping every single entry exactly as written.
- [1] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
- [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [3] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
- [4] Rosenberg, J. and H. Schulzrinne, "SIP: Locating SIP Servers", RFC 3263, June 2002.
- [5] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
- [6] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", RFC 3268, June 2002.
- [7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
- [8] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
- [9] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April 2000.
- [10] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
- [11] Freed, F. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
- [12] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
- [13] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with SDP", RFC 3264, June 2002.
- [14] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
- [15] Postel, J., "DoD Standard Transmission Control Protocol", RFC 761, January 1980.
- [16] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
- [17] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A. and L. Stewart, "HTTP authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
- [18] Troost, R., Dorner, S. and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997.
- [19] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., Watson, M. and M. Zonoun, "MIME media types for ISUP and QSIG Objects", RFC 3204, December 2001.
- [20] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
- [21] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
- [22] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995.
- [23] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.
- [24] Ramsdell B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
- [25] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
- [26] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
30. Informative References 🌈
these ones are the extra reading 📚 nice to know, not strictly needed to follow the rules. same deal, every entry kept word for word.
- [27] R. Pandya, "Emerging mobile and personal communication systems," IEEE Communications Magazine, Vol. 33, pp. 44--52, June 1995.
- [28] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
- [29] Schulzrinne, H., Rao, R. and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
- [30] Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen, B. and J. Segers, "Megaco Protocol Version 1.0", RFC 3015, November 2000.
- [31] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
- [32] Hoffman, P., Masinter, L. and J. Zawinski, "The mailto URL scheme", RFC 2368, July 1998.
- [33] E. M. Schooler, "A multicast user directory service for synchronous rendezvous," Master's Thesis CS-TR-96-18, Department of Computer Science, California Institute of Technology, Pasadena, California, Aug. 1996.
- [34] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
- [35] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
- [36] Dawson, F. and T. Howes, "vCard MIME Directory Profile", RFC 2426, September 1998.
- [37] Good, G., "The LDAP Data Interchange Format (LDIF) - Technical Specification", RFC 2849, June 2000.
- [38] Palme, J., "Common Internet Message Headers", RFC 2076, February 1997.
- [39] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., Luotonen, A., Sink, E. and L. Stewart, "An Extension to HTTP: Digest Access Authentication", RFC 2069, January 1997.
- [40] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., Willis, D., Rosenberg, J., Summers, K. and H. Schulzrinne, "SIP Call Flow Examples", Work in Progress.
- [41] E. M. Schooler, "Case study: multimedia conference control in a packet-switched teleconferencing system," Journal of Internetworking: Research and Experience, Vol. 4, pp. 99--120, June 1993. ISI reprint series ISI/RS-93-359.
- [42] H. Schulzrinne, "Personal mobility for multimedia services in the Internet," in European Workshop on Interactive Distributed Multimedia Systems and Services (IDMS), (Berlin, Germany), Mar. 1996.
- [43] Floyd, S., "Congestion Control Principles", RFC 2914, September 2000.
A Table of Timer Values ⏱️
okay this is the timer cheat sheet and it's SO useful 😭 Table 4 sums up what each timer means and its defaults. copied exactly, no changes:
Timer Value Section Meaning
----------------------------------------------------------------------
T1 500ms default Section 17.1.1.1 RTT Estimate
T2 4s Section 17.1.2.2 The maximum retransmit
interval for non-INVITE
requests and INVITE
responses
T4 5s Section 17.1.2.2 Maximum duration a
message will
remain in the network
Timer A initially T1 Section 17.1.1.2 INVITE request retransmit
interval, for UDP only
Timer B 64*T1 Section 17.1.1.2 INVITE transaction
timeout timer
Timer C > 3min Section 16.6 proxy INVITE transaction
bullet 11 timeout
Timer D > 32s for UDP Section 17.1.1.2 Wait time for response
0s for TCP/SCTP retransmits
Timer E initially T1 Section 17.1.2.2 non-INVITE request
retransmit interval,
UDP only
Timer F 64*T1 Section 17.1.2.2 non-INVITE transaction
timeout timer
Timer G initially T1 Section 17.2.1 INVITE response
retransmit interval
Timer H 64*T1 Section 17.2.1 Wait time for
ACK receipt
Timer I T4 for UDP Section 17.2.1 Wait time for
0s for TCP/SCTP ACK retransmits
Timer J 64*T1 for UDP Section 17.2.2 Wait time for
0s for TCP/SCTP non-INVITE request
retransmits
Timer K T4 for UDP Section 17.1.2.2 Wait time for
0s for TCP/SCTP response retransmits
Table 4: Summary of timersAcknowledgments 🫶
the SIP and MMUSIC crew gave their thoughts and ideas, and a bunch of people gave really detailed feedback. big thank yous, every name kept:
Ofir Arkin, Brian Bidulock, Jim Buller, Neil Deason, Dave Devanathan, Keith Drage, Bill Fenner, Cedric Fluckiger, Yaron Goland, John Hearty, Bernie Hoeneisen, Jo Hornsby, Phil Hoffer, Christian Huitema, Hisham Khartabil, Jean Jervis, Gadi Karmi, Peter Kjellerstedt, Anders Kristensen, Jonathan Lennox, Gethin Liddell, Allison Mankin, William Marshall, Rohan Mahy, Keith Moore, Vern Paxson, Bob Penfield, Moshe J. Sambol, Chip Sharp, Igor Slepchin, Eric Tremblay, and Rick Workman.
Brian Rosen provided the compiled BNF. 🧚
Jean Mahoney provided technical writing assistance. ✨
This work is based, inter alia, on [41,42]. 💜
Authors' Addresses 💌
okay so the authors are listed alphabetically for the editors, then the writers, then the original RFC 2543 authors. every one of them actively wrote a LOT of this, so they all get their contact details kept exactly as written:
Jonathan Rosenberg dynamicsoft 72 Eagle Rock Ave East Hanover, NJ 07936 USA
EMail: jdrosen@dynamicsoft.com
Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA
EMail: schulzrinne@cs.columbia.edu
Gonzalo Camarillo Ericsson Advanced Signalling Research Lab. FIN-02420 Jorvas Finland
EMail: Gonzalo.Camarillo@ericsson.com
Alan Johnston WorldCom 100 South 4th Street St. Louis, MO 63102 USA
EMail: alan.johnston@wcom.com
Jon Peterson NeuStar, Inc 1800 Sutter Street, Suite 570 Concord, CA 94520 USA
EMail: jon.peterson@neustar.com
Robert Sparks dynamicsoft, Inc. 5100 Tennyson Parkway Suite 1200 Plano, Texas 75024 USA
EMail: rsparks@dynamicsoft.com
Mark Handley International Computer Science Institute 1947 Center St, Suite 600 Berkeley, CA 94704 USA
EMail: mjh@icir.org
Eve Schooler AT&T Labs-Research 75 Willow Road Menlo Park, CA 94025 USA
EMail: schooler@research.att.com
Full Copyright Statement ⚖️
this part is the legal stuff, but it's still part of the spec so here it is, complete 💜
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement 🌸
okay last one, bestie! 🥹 the RFC Editor function is funded by the Internet Society, and that's the end of the whole SIP spec. we made it!! 🎉👑
📦 where this page comes from
- ietf: rfc3261 2002-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms