RFC 4028
Session Timers in the Session Initiation Protocol (SIP)
okay bestie, let's do the paperwork first 📜🎀
RFC 4028 is called Session Timers in the Session Initiation Protocol (SIP) 🦋. It's from the Network Working Group and was written by S. Donovan and J. Rosenberg, both at Cisco Systems. It's on the Standards Track and dates from April 2005. The title block doesn't list any RFCs it obsoletes or updates, so it doesn't replace or change anything else 🫶
Status of This Memo 🌸
Okay so this one is an Internet standards track protocol for the Internet community, and it's asking everyone for discussion and suggestions for improvements 💬 If you want to know where SIP's standards status currently sits, go check the current edition of the "Internet Official Protocol Standards" (STD 1) ✨ Distribution is unlimited, so share it with whoever 💖
Copyright Notice 💜
Copyright (C) The Internet Society (2005). 🔐
Abstract 🦋
This doc adds an extension to the Session Initiation Protocol (SIP) 🎀 The extension lets SIP sessions get periodically refreshed with a re-INVITE or UPDATE request, so user agents and proxies can tell whether a session is still alive 💅 It introduces two new header fields. Session-Expires carries how long the session lasts, and Min-SE carries the smallest value the session timer is allowed to be ✨
Table of Contents 📋
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of Operation . . . . . . . . . . . . . . . . . . . 4
4. Session-Expires Header Field Definition . . . . . . . . . . 6
5. Min-SE Header Field Definition . . . . . . . . . . . . . . . 8
6. 422 Response Code Definition . . . . . . . . . . . . . . . . 8
7. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Generating an Initial Session Refresh Request . . . . 9
7.2. Processing a 2xx Response . . . . . . . . . . . . . . 9
7.3. Processing a 422 Response . . . . . . . . . . . . . . 11
7.4. Generating Subsequent Session Refresh Requests . . . . 11
8. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Processing of Requests . . . . . . . . . . . . . . . . 13
8.2. Processing of Responses . . . . . . . . . . . . . . . 14
8.3. Session Expiration . . . . . . . . . . . . . . . . . . 15
9. UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . . 15
10. Performing Refreshes . . . . . . . . . . . . . . . . . . . . 17
11. Security Considerations . . . . . . . . . . . . . . . . . . 18
11.1. Inside Attacks . . . . . . . . . . . . . . . . . . . . 18
11.2. Outside Attacks . . . . . . . . . . . . . . . . . . . 19
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 19
12.1. IANA Registration of Min-SE and Session-Expires
Header Fields . . . . . . . . . . . . . . . . . . . . 19
12.2. IANA Registration of the 422 (Session Interval Too
Small) Response Code . . . . . . . . . . . . . . . . . 20
12.3. IANA Registration of the 'timer' Option Tag . . . . . 20
13. Example Call Flow . . . . . . . . . . . . . . . . . . . . . 20
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
15.1. Normative References . . . . . . . . . . . . . . . . . 25
15.2. Informative References . . . . . . . . . . . . . . . . 26
Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . 26
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 271. Introduction ✨
Okay so SIP ([2]) doesn't have a keepalive mechanism for the sessions it sets up 😭 User agents might be able to figure out that a session timed out using session-specific tricks, but proxies can't 💀 That means call stateful proxies aren't always sure whether a session is still active. Like, if a user agent forgets to send a BYE when the call ends, or the BYE gets lost because of network issues, the call stateful proxy has no idea the call is over. It keeps the call state around and has no way to know when that state is no longer needed 🙈
So this extension adds a keepalive mechanism for SIP sessions 🫶 UAs send periodic re-INVITE or UPDATE [3] requests (we call these session refresh requests) to keep the session alive 🔥 The interval between those refreshes gets worked out through a negotiation mechanism that's defined right here 🎀 If a session refresh request doesn't show up before the interval runs out, the session is treated as terminated. Both UAs are supposed to send a BYE, and call stateful proxies can clear any state for the call ✨
This refresh mechanism is useful for more than that, too 💅 A user agent wants to know if a session is still active for the same reasons a call stateful proxy does. It can work that out at the user agent without any SIP-level mechanisms. For audio sessions, periodic RTCP packets act as a sign of liveness [5] 🌈 Still, it's better to keep signs of SIP session liveness separate from the details of the particular session 🦋
Another use for the session timer is in building a SIP Network Address Translator (NAT) Application Level Gateway (ALG) [6] 🧚 The ALG inside a NAT has to keep state for the whole length of a call, and that state eventually has to go away. Relying on a BYE to remove that state is unreliable, and it also opens up a potential denial of service attack 😭
This document gives SIP an extension that defines a session expiration mechanism 💖 Periodic refreshes, done with re-INVITEs or UPDATEs, keep the session active. The extension is backward compatible enough with SIP that it works as long as either one of the two participants in a dialog understands it 🫶 It defines two new header fields (Session-Expires and Min-SE) and a new response code (422) 👑 Session-Expires carries the duration of the session, Min-SE carries the smallest value allowed for the session expiration, and the 422 response code says the session timer duration was too small 🍓
2. Terminology 💅
In this document, the key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' are to be interpreted as described in RFC 2119 [1] and indicate requirement levels for compliant SIP implementations 🎀
Okay, now let's define some terms, bestie 🧠
Session Interval: This is the maximum amount of time that can pass between session refresh requests in a dialog before the session is considered timed out 💫 The session interval is carried in the Session-Expires header field, which is defined in this document. The UAS gets this value from the Session-Expires header field in a 2xx response to a session refresh request that it sends. Proxies and UACs work it out from the Session-Expires header field in a 2xx response to a session refresh request that they receive 🦋
Minimum Timer: Because mid-dialog requests add processing load, every element (proxy, UAC, UAS) can have a configured minimum value for the session interval that it's willing to accept 🌸 This value is called the minimum timer ✨
Session Expiration: This is the time when an element will consider the session timed out, if no successful session refresh transaction has happened before then ⏰
Session Refresh Request: An INVITE or UPDATE request processed according to the rules of this specification 💜 If the request gets a 2xx response, the session expiration is pushed out to the current time plus the session interval taken from that response. Don't mix this up with a target refresh request, which is defined in Section 6 of [2] and is a request that can update the remote target of a dialog 🙈
Initial Session Refresh Request: The first session refresh request sent with a particular Call-ID value 🥹
Subsequent Session Refresh Request: Any session refresh request sent with a particular Call-ID after the initial session refresh request 🫶
Refresh: Same as a session refresh request 🌈
3. Overview of Operation ✨
Okay bestie, this part is the friendly tour 🦋 It's tutorial-y and not normative, so think of it as the vibe check before the real rules show up. 🫶
The extension works even when only ONE UA in a dialog supports it 👀 Wait, I need to keep that calm: it works even when only one UA in a dialog supports it. There are four cases to handle (the UAC does or doesn't support it, and the UAS does or doesn't support it), but for simplicity this section walks through the case where both sides support it. 💅
A UAC starts things off by sending an INVITE. It includes a Supported header field with the option tag 'timer', which basically says "hey, I speak session timers" 🌸
That request then passes through proxies, and any one of them might be interested in setting up a session timer. Each proxy can insert a Session-Expires header field and a Min-SE header field into the request (if there isn't one already), or change the value of the existing ones, as described below. 🧚
Now let's talk about Min-SE, because it's giving protective big-sister energy 🛡️ It sets the lower bound for the session refresh interval, so it's the fastest rate any proxy handling this request is allowed to demand. The whole point is to stop sketchy proxies from setting super short refresh intervals just to overload their neighbors 😤 Every proxy can raise this lower bound (make the gap between refreshes longer), but it is not allowed to lower it. No cap, that's iconic. 👑
Next is Session-Expires, which sets the upper bound for the session refresh interval. This is the time window, after handling a request, during which any session-stateful proxy has to hold on to its state for the session 🧠 Any proxy handling the request can lower this value, but it is not allowed to drop it below whatever is in the Min-SE header field.
If the Session-Expires interval is too low for a proxy (lower than the Min-SE value that proxy would want to assert), the proxy rejects the request with a 422 response 🙅♀️ That response contains a Min-SE header field saying the smallest session interval it's willing to support. Then the UAC tries again, this time including the Min-SE header field in the request. That header field holds the largest Min-SE value it saw across all the 422 responses it had received before. This way, the minimum timer meets the constraints of every proxy on the path. It's teamwork, bestie 🫶
After a few INVITE/422 rounds, the request finally reaches the UAS 🎉 The UAS can adjust the session interval just like a proxy would. When it's done, it puts the final session interval into the Session-Expires header field of a 2xx response. That Session-Expires header field also carries a refresher parameter, which says who is doing the refreshing: the UA that is currently the UAC, or the UA that is currently the UAS 🔄 As the 2xx response travels back through the proxy chain, each proxy can see the final session interval, but it can't change it. Hands off, proxies 🙌
Once the Session-Expires header field shows up in the response, both UAs know a session timer is active, when it will expire, and who is refreshing 💖 Before the expiration, the refresher that's currently active sends a session refresh request, which is a re-INVITE or UPDATE [3] request. If the refresher never gets a response to that session refresh request, it sends a BYE to end the session 💀 And if the other side never receives the session refresh request before the session expires, it sends a BYE too.
Refresh requests sent after the session is set up are handled exactly like the initial requests, as described above. So a successful session refresh request will extend the session, as desired ✨
The extension adds some extra complications on top of this basic flow so it can handle cases where only one UA supports it 🤓 One of those is that a proxy may need to insert the Session-Expires header field into the response when the UAS doesn't support the extension. Also, the negotiation of the refresher role takes into account which participants support the extension, so it's not a one-size-fits-all situation 🌈
One more thing, and it's important: the session timer refreshes the session, not the dialog that was used to set up the session. Of course, the two are related 🦋 If the session expires, a BYE is sent, which terminates the session and, generally, the dialog too.
4. Session-Expires Header Field Definition
The Session-Expires header field conveys the session interval for a SIP session 🎀 It only shows up in INVITE or UPDATE requests, and in any 2xx response to an INVITE or UPDATE. Like the SIP Expires header field, it contains a delta-time ⏰
The absolute minimum for the Session-Expires header field is 90 seconds. That's a bit more than twice how long a SIP transaction can take when it times out 😮💨 This gives a UA enough room to try a refresh at the halfway point of the session interval, and to have that transaction finish normally before the session expires. However, 1800 seconds (30 minutes) is RECOMMENDED as the value for the Session-Expires header field. So, in other words, SIP entities MUST be prepared to handle Session-Expires header field values of any duration greater than 90 seconds, but entities that insert the Session-Expires header field SHOULD NOT choose values of less than 30 minutes 💅
Small session intervals are honestly kind of destructive to the network 😭 They cause a ton of extra messaging traffic that hits both user agents and proxy servers. They also make "glare" more likely, which is when both user agents send a re-INVITE or UPDATE at the same time 🙃 The main job of the session timer is to time out state in SIP elements, so really tiny values usually aren't needed. The 30 minutes was picked because 95% of phone calls are shorter than that ☎️ But the 30 minute minimum is listed as a SHOULD, not a MUST, because the exact right number depends on a lot of network stuff: bandwidths and latencies, computing power, memory availability, network topology, and, of course, the application scenario. After all, SIP can set up any kind of session, not just a phone call 🌍 At the time this document was published, 30 minutes seemed appropriate. Technology keeps moving, though, so the number could end up being excessively large five years from now 🔮
The default value of the Session-Expires header field is undefined. So if the Session-Expires header field is absent, it means the session doesn't expire using the mechanism defined in this specification 🙈 Other mechanisms that aren't defined in this specification, like locally configured timers, may still apply, though 🧚
Here's the syntax of the Session-Expires header field:
Session-Expires = ("Session-Expires" / "x") HCOLON delta-seconds
*(SEMI se-params)
se-params = refresher-param / generic-param
refresher-param = "refresher" EQUAL ("uas" / "uac")Quick side note: a compact form, the letter x, has been reserved for Session-Expires ✨ The BNF for delta-seconds and generic-param is defined in Section 25 of RFC 3261 [2].
Table 1 is an extension of Tables 2 and 3 in [2] for the Session-Expires and Min-SE header fields 📋 The column 'PRA' is for the PRACK method [7], 'UPD' is for the UPDATE method [3], 'SUB' is for the SUBSCRIBE method [8], and 'NOT' is for the NOTIFY method [8].
+---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+
| Header |where|proxy|ACK|BYE|CAN|INV|OPT|REG|PRA|UPD|SUB|NOT|
+---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+
|Session-Expires| R | amr | - | - | - | o | - | - | - | o | - | - |
| | | | | | | | | | | | | |
|Session-Expires| 2xx | ar | - | - | - | o | - | - | - | o | - | - |
| | | | | | | | | | | | | |
|Min-SE | R | amr | - | - | - | o | - | - | - | o | - | - |
| | | | | | | | | | | | | |
|Min-SE | 422 | | - | - | - | m | - | - | - | m | - | - |
+---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+
Table 1: Session-Expires and Min-SE Header Fields5. Min-SE Header Field Definition
The Min-SE header field indicates the minimum value for the session interval, in units of delta-seconds 📏 When it's used in an INVITE or UPDATE request, it says the smallest session interval that can be used for that session. When it's present in a request or response, its value MUST NOT be less than 90 seconds 🚫
When the header field is not present, its default value for is 90 seconds 🧁
The Min-SE header field MUST NOT be used in responses except for those with a 422 response code 🙅♀️ In those, it indicates the minimum session interval value that the server is willing to accept.
Here's the syntax of the Min-SE header field:
Min-SE = "Min-SE" HCOLON delta-seconds *(SEMI generic-param)6. 422 Response Code Definition
This extension introduces the 422 (Session Interval Too Small) response code 💌 A UAS or proxy generates it when a request contains a Session-Expires header field with a duration below the minimum timer for that server. The 422 response MUST contain a Min-SE header field with the minimum timer for that server 🫶
7. UAC Behavior 🎀
7.1. Generating an Initial Session Refresh Request
A UAC that supports the session timer extension defined here MUST include a Supported header field in each request (except ACK), listing the option tag 'timer' [2] 💖 It MUST do this even if the UAC isn't asking to use the session timer for this session 🙌
The UAC MAY include a Require header field in the request with the value 'timer' to say that the UAS must support the session timer in order to take part in the session. This doesn't mean the UAC is making the UAS do the refreshes, only that the UAS has to support the extension 🔥 The UAC MAY also include a Proxy-Require header field in the request with the value 'timer' to say that proxies must support the session timer to process the request correctly. However, using either Require or Proxy-Require from the UAC is NOT RECOMMENDED 🙅♀️ They aren't needed, since the extension works even when only the UAC supports it. The Supported header field containing 'timer' MUST still be included, even if the Require or Proxy-Require header fields are present with 'timer' in them ✨
A UAC MAY include the Min-SE header field in the initial INVITE request 🧚
A UAC MAY include a Session-Expires header field in an initial session refresh request if it wants a session timer applied to the session 💅 The value of that header field is the session interval the UAC would like. If a Min-SE header is included in the initial session refresh request, the value of the Session-Expires MUST be greater than or equal to the value in Min-SE 📏
The UAC MAY include the refresher parameter with the value 'uac' if it wants to do the refreshes itself. However, it is RECOMMENDED that the parameter be omitted, so it can be picked by the negotiation mechanisms described below 🌸
7.2. Processing a 2xx Response ✨
okay so the session timer has to keep track of some state 🧠. that includes the session interval, the session expiration, and the identity of the refresher. all of that lives on the dialog where the session got negotiated 🫶
when a 2xx response to a session refresh request comes back, it might have a Require header field with the value timer, or it might not 🤷♀️. if it does, the UAC MUST look for the Session-Expires header field to process the response.
if there was a Require header field with timer in the response, the Session-Expires header field will always be there 💅. UACs MUST be prepared to receive a Session-Expires header field in a response, even if the request didn't have one 😭. the refresher parameter will show up in the Session-Expires header field and tell everyone who's doing the refreshes 🎀. the UAC MUST set the identity of the refresher to whatever that parameter says. if it says uac, then the UAC is the one doing them 👑.
here's a lowkey tricky situation 👀. the UAC might have asked for the session timer (so it put a Session-Expires header field in the request), but the 2xx response has no Require or Session-Expires header field at all. this happens when the UAS doesn't support the session timer extension and only the UAC asked for a timer (no proxies asked for it either) 🙈. in that case, if the UAC still wants the session timer (which is purely for its own benefit, fr), it has to do the refreshes itself 🦋. to do that, the UAC follows the procedures in this specification as if the Session-Expires header field had been in the 2xx response, with the same value as in the request, but with a refresher parameter of uac 🧚.
if the 2xx response didn't have a Session-Expires header field, there's no session expiration 🌸. so no refreshes need to be sent. a 2xx without a Session-Expires can show up for both initial and subsequent session refresh requests, which means the session timer can be turned off in the middle of a dialog just by getting a response without a Session-Expires header field 💀.
the UAC remembers the session interval for a session as the delta-time value from the Session-Expires header field in the most recent 2xx response to a session refresh request on a dialog 📝. it's explicitly allowed for different dialogs that came from the same INVITE to have different session intervals (or none at all) 🍓. the UAC also remembers whether it or its peer is the refresher for the session ✨.
if the UAC has to do the refreshes, it computes the session expiration for that session 🧮. the session expiration is the time the last 2xx response to a session refresh request on that dialog was received, plus the session interval for that session. if the UA wants to keep the session going past the session expiration, it MUST generate a refresh before the session expiration 🔥. it is RECOMMENDED that this refresh gets sent once half the session interval has passed 💜. more procedures for this refresh are in Section 10.
also, a re-INVITE or UPDATE request sent within a dialog for reasons other than session refreshes will also refresh the session 🌈. its processing follows the procedures defined in this specification, so no extra steps there 🙌.
7.3. Processing a 422 Response 🎀
if the response to a session refresh request is a 422 (Session Interval Too Small) response message, the UAC MAY retry the request 🔁. the retry procedures are in Section 7.4. this new request counts as a brand new transaction and SHOULD have the same Call-ID, To, and From as the previous request 🫶. the only change is that the CSeq should have a new sequence number, one higher than the previous one 🔢.
7.4. Generating Subsequent Session Refresh Requests 🦋
the values of Supported, Require, and Proxy-Require from the initial session refresh request MUST be used again 💅.
the UAC MUST insert the Min-SE header field into a session refresh request for a particular dialog if it has ever gotten a 422 response to an earlier session refresh request on that same dialog, or if it has received a session refresh request on that dialog that had a Min-SE header field 😤. same deal before a dialog exists: a UAC MUST insert the Min-SE header field into an INVITE request if it has ever gotten a 422 response to an earlier INVITE request with the same Call-ID 🧚.
the value of the Min-SE header field in a session refresh request MUST be the largest value among all the Min-SE header field values returned in all 422 responses, or received in session refresh requests, on the same dialog (if a dialog has been established) 📈. if no dialog has been established yet, the Min-SE header field value is set to the largest value among all the Min-SE header field values returned in all 422 responses for an INVITE request with the same Call-ID 🌸. the result is that the maximum Min-SE value gets effectively "cleared" once the dialog is established, and from then on, only the values from proxies known to be on the proxy path get used 🧹✨.
the UAC may have its own opinions about the minimum session interval 🙋♀️. if that's the case and the value above is too small, the UAC MAY increase it 📏.
in a session refresh request sent within a dialog with an active session timer, the Session-Expires header field SHOULD be present 🎀. when it's there, it SHOULD be equal to the maximum of the Min-SE header field (its default when not present is 90 seconds, btw) and the current session interval ⏱️. including the Session-Expires header field with this value helps avoid certain denial-of-service attacks, as covered in Section 11 🛡️. so a UA should only ignore that SHOULD in unusual and singular cases, like when it actually wants to change the session interval mid-dialog 🙈.
if the session refresh request isn't the initial one, it is RECOMMENDED that the refresher parameter be set to uac if the element sending the request is doing the refreshes right now, and to uas if its peer is doing them 🔄. that way, the refresher role doesn't flip around on every refresh 💖. but if it wants to explicitly change roles, it MAY use a value of uas if it knows the other side supports the session timer 👑. it could know that by having received a request from its peer with a Supported header field containing the value timer ✨. and if it wants to reselect the roles, it MAY leave the parameter out completely 🫠.
a re-INVITE generated to refresh the session is a normal re-INVITE, and an UPDATE generated to refresh a session is a normal UPDATE 💅. if a UAC knows its peer supports the UPDATE method, it is RECOMMENDED that UPDATE be used instead of a re-INVITE 🥹. a UA can figure that out if it has seen an Allow header field from its peer with the value UPDATE, or through a mid-dialog OPTIONS request 🔍. it is RECOMMENDED that the UPDATE request not contain an offer [4] 🙅♀️. a re-INVITE SHOULD contain one though, even if the session details haven't changed 📨. in that case, the offer MUST indicate that nothing has changed. for SDP, that means using the same value for the origin field that previous SDP messages to that peer used 🧾. same goes for an answer exchanged as the result of a session refresh request: if it hasn't changed, that MUST be indicated 💜.
8. Proxy Behavior 🧚♀️
okay, session timers are mostly a big deal for call stateful proxy servers (the servers that keep track of calls and dialogs going through them) 📞. but a stateful proxy server (one that knows transaction state but doesn't keep call or dialog state) MAY also follow the rules here 🌈. stateless proxies MUST NOT try to request session timers 🚫. proxies that do ask for session timers SHOULD record-route, because otherwise they won't receive the refreshes 🗺️✨.
The proxy processing rules require the proxy to remember information between the request and response, ruling out stateless proxies. 🙈
8.1. Processing of Requests ✨
okay so processing requests is literally identical for every single session refresh request 💅 no exceptions, bestie
to ask for a session timer on a session, a proxy makes sure there's a Session-Expires header field in the session refresh request for that session 🎀 if there isn't one, the proxy MAY insert a Session-Expires header field before forwarding it. the value can be whatever expiration time the proxy wants, but it can't be lower than the Min-SE value in the request, if one is there. and the proxy MUST NOT include a refresher parameter in that header field value 🙈
if the request already has a Session-Expires header field, the proxy MAY lower its value, but it MUST NOT set it below the Min-SE value in the request, if that's present. now here's the tea 🍵 if the Session-Expires value is greater than or equal to the Min-SE value (remember the default is 90 seconds when there's no Min-SE header field), the proxy MUST NOT increase it. if the Session-Expires value is lower than the Min-SE value (maybe because the proxy bumped up Min-SE, which we'll get to), the proxy MUST increase Session-Expires so it matches the Min-SE value. and the proxy MUST NOT insert or modify the refresher parameter in the Session-Expires header field 🔥
if the request has a Supported header field with the value timer, the proxy MAY reject the INVITE with a 422 (Session Interval Too Small) response if the session interval in Session-Expires is smaller than the minimum interval from the proxy's local policy 🦋 when it sends that 422, the proxy MUST include a Min-SE header field set to its minimum interval. and that minimum MUST NOT be lower than 90 seconds 💖
if the request doesn't show support for the session timer but has a session interval that's too small, the proxy can't really reject it, because that would just mean a call failure 😭 so instead, the proxy SHOULD insert a Min-SE header field containing its minimum interval. if a Min-SE header field is already there, the proxy SHOULD increase it (but MUST NOT decrease it) to the minimum interval. then the proxy MUST increase the Session-Expires value to match Min-SE, like we covered above. and a proxy MUST NOT insert a Min-SE header field or change an existing one in a proxied request if that request has a Supported header field with the value timer 🫶 this is needed to protect against certain denial of service attacks, described in Section 11
⚠️ bestie this is the part that keeps the bad guys out. don't skip the Supported: timer check!
assuming the proxy asked for a session timer (so it maybe added Session-Expires or shrank it), the proxy MUST remember that it's using a session timer, and it MUST also remember the Session-Expires value from the proxied request. this MUST be remembered for the whole transaction 🧚
the proxy MUST also remember, for the whole transaction, whether the request had a Supported header field with the value timer. if the request did NOT have that, the proxy MAY insert a Require header field with the value timer into the request. however, that is NOT RECOMMENDED 🙈 it lets the proxy insist on a session timer for the session. the Require header field isn't needed if a Supported header field was in the request, because then the proxy already knows the session timer can be used 💜
8.2. Processing of Responses 🌸
when the final response to the request shows up, the proxy takes a look at it 👀
if the response doesn't have a Session-Expires header field, but the proxy remembers asking for a session timer in the request (by inserting, modifying, or checking and accepting the Session-Expires header field in the proxied request), that means the UAS didn't support the session timer 😭 if the proxy also remembers that the UAC didn't support it, the proxy just forwards the response upstream like normal. there's no session expiration for this session, no drama 🍓 but if the proxy remembers that the UAC DID support the session timer, extra processing is needed ✨
because there's no Session-Expires or Require header field in the response, the proxy knows it's the first session-timer-aware proxy to get this response 👑 so this proxy MUST insert a Session-Expires header field into the response, using the value it remembered from the forwarded request. it MUST set the refresher parameter to uac. the proxy MUST add the timer option tag to any Require header field in the response, and if there wasn't one, it MUST add a Require header field with that value before forwarding upstream 🌈
if the response that came back already has a Session-Expires header field, no changes are needed to the response 💅
in every case, if the 2xx response the proxy forwards upstream has a Session-Expires header field, that value is the session interval for the session tied to that response 🦋 the proxy works out the session expiration as the time it forwards the 2xx response upstream, plus the session interval. this session expiration MUST update any existing session expiration for the session. the refresher parameter in the Session-Expires header field of the 2xx response forwarded upstream will be there, and it tells you which UA is doing the refreshes 🎀 a single INVITE can get multiple 2xx responses, each for a different dialog, so you can end up with multiple session expirations, one for each session tied to each dialog ✨
the proxy MUST NOT modify the value of the Session-Expires header field in the response (if there was one) before forwarding it upstream 🫶
8.3. Session Expiration 💀
when the current time hits or passes the session expiration for a session, the proxy MAY remove the call state tied to it, and MAY free any resources tied to the call 🧹 unlike the UA, the proxy MUST NOT send a BYE 🙅♀️ it just cleans up quietly, no drama, iconic behavior 💜
9. UAS Behavior ✨
okay so the UAS must respond to a session timer request from the UAC or from a proxy along the path, or it may ask for a session timer itself 💅
If an incoming request has a Supported header field with the value timer and a Session Expires header field, the UAS MAY reject the INVITE with a 422 (Session Interval Too Small) response if the session interval in the Session-Expires header field is smaller than the minimum interval set by the UAS's local policy 🙈 When it sends that 422, the UAS MUST include a Min-SE header field with its minimum interval. This minimum interval MUST NOT be lower than 90 seconds, no exceptions bestie 🫶
If the UAS wants to accept the request, it copies the Session-Expires value from the request into the 2xx response. Easy peasy 🎀
The UAS response MAY reduce that value, but MUST NOT set it to a duration lower than the Min-SE value in the request, if one is present. If there isn't one, the UAS MAY reduce the value but MUST NOT set it lower than 90 seconds. The UAS MUST NOT increase the value of the Session-Expires header field 🚫📈
If the incoming request has a Supported header field with the value timer but no Session-Expires header, it means the UAS is saying "I support timers, but I'm not asking for one" 🦋 The UAS may still request a session timer in the 2XX response by including a Session-Expires header field. That value MUST NOT be set to a duration lower than the Min-SE value in the request, if one is present.
The UAS MUST set the refresher parameter in the Session-Expires header field of the 2xx response. This tells everyone who is going to do the refreshes for the dialog. The value depends on the refresher parameter in the request and on whether the UAC supports the session timer extension. The UAC supports it if the timer option tag was in a Supported header field in the request. Table 2 shows exactly how the response value gets set. A value of none in the second column means there was no refresher parameter in the request. A value of NA in the third column means that combination shouldn't happen, because the protocol doesn't allow it 🙅♀️
UAC supports? refresher parameter refresher parameter
in request in response
-------------------------------------------------------
N none uas
N uac NA
N uas NA
Y none uas or uac
Y uac uac
Y uas uas
Table 2: UAS BehaviorThe fourth row is the one I'm obsessed with 😭 It covers the case where both the UAC and the UAS support the extension, and the UAC didn't pick who does the refreshes. So the UAS gets to decide whether it or the UAC does them. BUT, as the table shows, the UAS can't override the UAC's pick if the UAC made one. Not me overriding someone else's choice 💅
If the refresher parameter in the Session-Expires header of the 2xx response is uac, the UAS MUST put a Require header field with the value timer into the response. That's because the UAC is doing the refreshes, and it has to process the response to know that 🧚 If the refresher parameter in the 2xx response is uas and the Supported header field in the request contained timer, the UAS SHOULD put a Require header field with the value timer into the response. In this case the UAC isn't refreshing, but it's supposed to send a BYE if it never gets a refresh. The call still works without that BYE, so adding the Require is a SHOULD here, not a MUST 🌸
Just like the UAC, the UAS stores state for the session timer. That state has the session interval, the session expiration, and who the refresher is. It's bound to the dialog that set up the session ✨ The session interval is set to the delta-time from the Session-Expires header in the most recent 2xx response to a session refresh request on that dialog. The UAS also remembers whether it or its peer is the refresher, based on the refresher parameter from that same most recent 2xx. If that response had no Session-Expires header, there's no session expiration and no refreshes are needed 🍓
If the UAS has to refresh the session, it works out the session expiration. That's the time the last 2xx response to a session refresh request on that dialog was sent, plus the session interval. If the UA wants to keep the session going past the expiration, it MUST generate a refresh before the session expiration. It is RECOMMENDED that this refresh go out once half the session interval has passed. More details on this refresh are in Section 10 🌈
10. Performing Refreshes 🔁
The side generating a refresh follows the UAC procedures from Section 7, so nothing new there 💖 Just remember that only a 2xx response to a session refresh request extends the session expiration. That means a UA could try a refresh, get a 422 with a Min-SE value way bigger than the current session interval 😬 The UA still has to send a session refresh request before the session expiration, which hasn't changed, even though this request will carry a Session-Expires value way bigger than the current interval.
If the session refresh request transaction times out, or gets a 408 or 481 response, then the UAC sends a BYE request as per Section 12.2.1.2 of RFC 3261 [2] 💀 If the refresh doesn't get a 2xx response (so the session isn't refreshed) and some response other than 408 or 481 comes back, the UAC SHOULD follow the rules for that response code and retry if it can. For example, if it's a 401, the UAC would retry with new credentials 🔑 However, the UAC SHOULD NOT keep retrying nonstop if the server keeps sending the same error response.
Similarly, if the side that isn't doing the refreshes doesn't get a session refresh request before the session expiration, it SHOULD send a BYE to end the session, slightly before the session expiration. It is RECOMMENDED to use the minimum of 32 seconds and one third of the session interval for that.
Firewalls and NAT ALGs can be super unforgiving about letting SIP traffic through after the session has expired 🙈 That's exactly why the BYE should go out before the expiration.
11. Security Considerations 🛡️
Okay this section is serious, so buckle up 😤 The session timer gives a proxy or UA element the power to force compliant UAs to send refreshes at a rate the element picks. That opens the door to denial-of-service attacks with serious amplification. These attacks can come from "outsiders" (elements that try to change messages in transit) or from "insiders" (elements that are legitimately on the request path but want to cause harm). Thankfully, this specification handles both cases well 💪
11.1. Inside Attacks 👀
This opens the door to rogue proxies or UAs launching denial-of-service attacks. The mechanisms in this specification stop that from happening ✅
First, think about a rogue UAC that wants to make a UAS generate refreshes super fast. It puts a Session-Expires header into an INVITE with a tiny duration and a refresher parameter set to uas. Say it also adds a Supported header field to the request. The UAS, or any proxy that objects to that low timer, will reject the request with a 422, which stops the attack 🚫 If no Supported header field was present, the proxies will add a Min-SE header field to the request before forwarding it. So the UAS won't pick a session timer lower than the minimum allowed by every element on the path. That stops it too 🙌
Next, think about a rogue UAS that wants to make a UAC generate refreshes super fast. For this to work, the UAC has to support the session timer. The initial INVITE reaches the rogue UAS, which sends back a 2xx with a very small session interval. The UAC uses that timer and quickly sends a refresh. Section 7.4 says the UAC has to copy the current session interval into the Session-Expires header field of the request. That lets the proxies see the current value. The proxies will reject this request and provide a Min-SE with a higher minimum, which the UAC then uses 🎯 Note that if the proxies didn't reject the request, but instead passed it along with a Min-SE header field, the attack would still be possible. The UAS could throw away that header field in a 2xx response and keep the UAC sending rapid requests 😤
In a similar way, a rogue proxy can't force either the UAC or the UAS to generate refreshes unless it stays on the signaling path and sees every request and response 👁️
11.2. Outside Attacks 🕵️♀️
An element that can watch and change a request or response in transit can force rapid session refreshes. To prevent this, requests and responses have to be protected by message integrity. The session timer header fields aren't end-to-end, and proxies change them, so the SIP S/MIME capabilities aren't suitable for this job 🙅♀️ Integrity has to be protected with hop-by-hop mechanisms instead. So it is RECOMMENDED that an element send a request with a Session-Expires header field, or a Supported header field with the value timer, by using TLS 🔐 Adequate protection is only obtained if security is applied on every hop, so it is RECOMMENDED that the SIPS URI scheme be used with this extension. That means proxies that record-route and request a session timer SHOULD record-route with a SIPS URI. A UA that puts a Session-Expires header into a request or response SHOULD include a Contact URI that is a SIPS URI 💜
12. IANA Considerations 📋
This extension defines two new header fields, a new response code, and a new option tag. SIP [2] defines the IANA procedures for registering these 🌷
12.1. IANA Registration of Min-SE and Session-Expires Header Fields 🧾
Here are the registrations for the two header fields:
The following is the registration for the Min-SE header field:
RFC Number: RFC 4028
Header Name: Min-SE
Compact Form: none
The following is the registration for the Session-Expires header
field:
RFC Number: RFC 4028
Header Name: Session-Expires
Compact Form: x12.2. IANA Registration of the 422 (Session Interval Too Small) Response Code 🎀
And here's the registration for the 422 (Session Interval Too Small) response code:
Response Code: 422
Default Reason Phrase: Session Interval Too Small
RFC Number: RFC 402812.3. IANA Registration of the 'timer' Option Tag ✨
Here's the registration for the timer option tag 🎀
- Name:
timer - Description: This option tag is for support of the session timer extension. Putting it in a
Supportedheader field in a request or response means the UA can do refreshes following that spec 💖 Putting it in aRequireheader in a request means the UAS must understand the session timer extension to process that request 🔥 Putting it in aRequireheader field in a response means the UAC has to look for theSession-Expiresheader field in the response and process it accordingly 💅
13. Example Call Flow 🦋
Example Session Timer Flow 🎬
Alice Proxy P1 Proxy P2 Bob
|(1) INVITE | | |
|SE: 50 | | |
|----------->| | |
|(2) 422 | | |
|MSE: 3600 | | |
|<-----------| | |
|(3) ACK | | |
|----------->| | |
|(4) INVITE | | |
|SE:3600 | | |
|MSE:3600 | | |
|----------->| | |
| |(5) INVITE | |
| |SE:3600 | |
| |MSE:3600 | |
| |----------->| |
| |(6) 422 | |
| |MSE:4000 | |
| |<-----------| |
| |(7) ACK | |
| |----------->| |
|(8) 422 | | |
|MSE:4000 | | |
|<-----------| | |
|(9) ACK | | |
|----------->| | |
|(10) INVITE | | |
|SE:4000 | | |
|MSE:4000 | | |
|----------->| | |
| |(11) INVITE | |
| |SE:4000 | |
| |MSE:4000 | |
| |----------->| |
| | |(12) INVITE |
| | |SE:4000 |
| | |MSE:4000 |
| | |----------->|
| | |(13) 200 OK |
| | |SE:4000 |
| | |<-----------|
| |(14) 200 OK | |
| |SE:4000 | |
| |<-----------| |
|(15) 200 OK | | |
|SE:4000 | | |
|<-----------| | |
|(16) ACK | | |
|----------->| | |
| |(17) ACK | |
| |------------------------>|
|(18) UPDATE | | |
|SE:4000 | | |
|----------->| | |
| |(19) UPDATE | |
| |SE:4000 | |
| |------------------------>|
| |(20) 200 OK | |
| |SE:4000 | |
| |<------------------------|
|(21) 200 OK | | |
|SE:4000 | | |
|<-----------| | |
| |(22) BYE | |
| |<------------------------|
|(23) BYE | | |
|<-----------| | |
| |(24) 408 | |
| |------------------------>|Figure 1: Example Session Timer Flow
Okay bestie, Figure 1 shows a whole call flow that uses the session timer, and it's giving everything 🌈 Both the UAC and the UAS support the session timer extension here. Alice is the UAC, and her very first INVITE (message 1) looks like this 🧚
INVITE sips:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8
Supported: timer
Session-Expires: 50
Max-Forwards: 70
To: Bob <sips:bob@biloxi.example.com>
From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sips:alice@pc33.atlanta.example.com>
Content-Type: application/sdp
Content-Length: 142
(Alice's SDP not shown)So Alice is saying she supports the session timer and wants refreshes every 50 seconds 🙈 That request lands at the first proxy, P1, but 50 is way below the minimum allowed value of 3600. P1 is not having it, so it rejects with a 422 (message 2) 💀
SIP/2.0 422 Session Interval Too Small
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8
;received=192.0.2.1
Min-SE: 3600
To: Bob <sips:bob@biloxi.example.com>;tag=9a8kz
From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITEThat response has a Min-SE header field with the value 3600 ✨ Alice takes the hint and retries. This time her request includes a Min-SE header, because she has already gotten a 422 for other INVITE requests with the same Call-ID 🫶 Her new request (message 4) looks like this:
INVITE sips:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9
Supported: timer
Session-Expires: 3600
Min-SE: 3600
Max-Forwards: 70
To: Bob <sips:bob@biloxi.example.com>
From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314160 INVITE
Contact: <sips:alice@pc33.atlanta.example.com>
Content-Type: application/sdp
Content-Length: 142
(Alice's SDP not shown)P1 record-routes 🛣️ Since 3600 is fine by P1, it forwards the request to P2 (message 5). But P2's minimum is 4000, and 3600 is below that. P2 rejects with a 422 (message 6) and includes a Min-SE header field with the value 4000 😭 Alice retries the INVITE once more. Now her Min-SE header field is the maximum of every Min-SE value she has received (3600 and 4000), so it's 4000 👑 Message 10 looks like this:
INVITE sips:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds10
Supported: timer
Session-Expires: 4000
Min-SE: 4000
Max-Forwards: 70
To: Bob <sips:bob@biloxi.example.com>
From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314161 INVITE
Contact: <sips:alice@pc33.atlanta.example.com>
Content-Type: application/sdp
Content-Length: 142
(Alice's SDP not shown)P1 record-routes again, but P2 doesn't. Ngl, that wouldn't normally happen, since P2 asked for the session timer, so it should record-route the next request too 🙈 Anyway, the UAS (Bob) gets the request. It copies the Session-Expires header from the request into the response and adds a refresher parameter with the value 'uac' 🎀 That 200 OK gets forwarded back to Alice, and the response she receives (message 15) looks like this:
SIP/2.0 200 OK
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds10
;received=192.0.2.1
Require: timer
Supported: timer
Record-Route: sips:p1.atlanta.example.com;lr
Session-Expires: 4000;refresher=uac
To: Bob <sips:bob@biloxi.example.com>;tag=9as888nd
From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314161 INVITE
Contact: <sips:bob@192.0.2.4>
Content-Type: application/sdp
Content-Length: 142
(Bob's SDP not shown)Alice generates an ACK (message 16), which goes through P1 and then on to Bob ✨ Since Alice is the refresher, around 2000 seconds later she sends an UPDATE to refresh the session 🦋 This request is part of an established dialog, and Alice hasn't gotten any 422 responses or requests on that dialog, so there's no Min-SE header field in it (message 18):
UPDATE sips:bob@192.0.2.4 SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds12
Route: sips:p1.atlanta.example.com;lr
Supported: timer
Session-Expires: 4000;refresher=uac
Max-Forwards: 70
To: Bob <sips:bob@biloxi.example.com>;tag=9as888nd
From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314162 UPDATE
Contact: <sips:alice@pc33.atlanta.example.com>That goes through P1 to Bob. Bob sends back a 200 OK, copying the Session-Expires header field into the response 💖 It gets forwarded through P1 and arrives at Alice. The response she receives (message 21) looks like this:
SIP/2.0 200 OK
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds12
;received=192.0.2.1
Require: timer
Session-Expires: 4000;refresher=uac
To: Bob <sips:bob@biloxi.example.com>;tag=9as888nd
From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314162 UPDATE
Contact: <sips:bob@192.0.2.4>Then, plot twist 😱 Alice's UA crashes right after this. She never sends another session refresh request. 3968 seconds later, Bob times out and sends a BYE (message 22), which goes to P1. P1 tries to deliver it but can't, because Alice's UA has crashed, so P1 sends a 408 (Request Timeout) back to Bob 🥀
14. Acknowledgements 🫶
The authors want to thank Brett Tate for his contributions to this work 💜 Brian Rosen finished the editing of the document 🌸
15. References 📚
15.1. Normative References
- [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
- [3] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
- [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
15.2. Informative References
- [5] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
- [6] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
- [7] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
- [8] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
Authors' Addresses 💌
Steve Donovan Cisco Systems, Inc. 2200 E. President George Bush Turnpike Richardson, Texas 75082 US
EMail: srd@cisco.com
Jonathan Rosenberg Cisco Systems, Inc. 600 Lanidex Plaza Parsippany, NJ 07054 US
EMail: jdrosen@cisco.com
Full Copyright Statement 🎀
okay so bestie, the copyright bit: The Internet Society owns the copyright here (2005 🌸). This document is under the rights, licenses and restrictions in BCP 78, and the authors keep all their rights, except where BCP 78 says otherwise 💜
The disclaimer is super serious, so here it is in full:
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Basically, nobody is promising this stuff works for your project 🙈
Intellectual Property 🦋
The IETF doesn't take a side on whether any intellectual property rights or other rights that someone might claim over the tech in this document are valid, or how far they reach. It also doesn't say whether licenses for those rights are actually available. And it hasn't done any independent digging to find out what rights might exist 🔍 If you want the rules on rights for RFC documents, check out BCP 78 and BCP 79 📚
Copies of IPR disclosures sent to the IETF Secretariat are a thing, and so are any assurances that licenses will be available. The same goes for the results of trying to get a general license or permission for implementers or users to use proprietary rights in this spec. You can find all of that in the IETF online IPR repository at http://www.ietf.org/ipr ✨
The IETF also invites anyone to flag any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 💌
Acknowledgement 🌈
The RFC Editor function is currently funded by the Internet Society 💖 Thank you, Internet Society 🫶
📦 where this page comes from
- ietf: rfc4028 2005-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms