Internet Engineering Task Force SIP WG Internet Draft S.Donovan,J.Rosenberg draft-ietf-sip-session-timer-07.txt dynamicsoft October 1, 2001 Expires: April 2002 The SIP Session Timer STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Abstract This document proposes an extension to the Session Initiation Protocol (SIP). This extension allows for a periodic refresh of SIP sessions through a re-INVITE. The refresh allows both user agents and proxies to determine if the SIP session is still active. The extension defines two new general headers, Session-Expires, which conveys the lifetime of the session, and Min-SE, which conveys the minimum allowed value for the session timer. 1 Introduction The Session Initiation Protocol (SIP) [1], does not define a keepalive mechanism. The result is that call stateful proxies will not always be able to determine whether a call is still active or not. For instance, when a user agent fails to send a BYE message at S.Donovan,J.Rosenberg [Page 1]
Internet Draft Session Timer October 1, 2001 the end of a session, or the BYE message gets lost due to network problems, a call stateful proxy will not know when the session has ended. In this situation, the call stateful proxy will retain state for the call and has no deterministic method of determining when the call state information no longer applies. To resolve this problem, this extension defines a keepalive mechanism for SIP sessions. UAs send periodic re-INVITEs to keep the session alive. The interval for the re-INVITEs is determined through a negotiation mechanism defined here. If a re-INVITE is not received before the interval passes, the session is considered terminated. Both UAs are supposed to send a BYE, and call stateful proxies can remove any state for the call. INVITE is used as a refresh, as opposed to another method, to allow sessions to be recovered after a crash and restart of one of the UAs. It makes SIP sessions soft state. This refresh mechanism has additional applications. For the same reasons a call stateful proxy server would like to determine whether the session is still active, a user agent would like to make this determination. This determination can be made at a user agent without the use of SIP level mechanisms; for audio sessions, periodic RTCP packets serve as an indication of liveness [2]. However, it is desirable to separate SIP call liveness from the details of the particular session. Another application of the session timer is in the construction of a SIP NAT ALG. The ALG embedded in a NAT will need to maintain state for the duration of a call. This state must eventually be removed. Relying on a BYE to trigger the removal of state, besides being unreliable, introduces a potential denial of service attack. This document proposes an extension to SIP that defines a session expiration mechanism. Periodic refreshes, through re-INVITEs, are used to keep the session active. The extension is sufficiently backwards compatible with SIP that it works so long as either one of the two participants in a call leg understand the extension. Two new general headers, Session-Expires and Min-SE, and a new response code, 422, are defined. Session-Expires conveys the duration of the session, and Min-SE conveys the minimum allowed value for the session expiration. The 422 response code indicates that the session timer duration was too small. 2 Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", S.Donovan,J.Rosenberg [Page 2]
Internet Draft Session Timer October 1, 2001 "SHALL", "SHALLNOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [3] and indicate requirement levels for compliant SIP implementations. Additionally, we define the following terms: Session Interval: The largest amount of time that can occur between INVITE requests in a call before it will be considered timed out. The session interval is conveyed in the Session-Expires header defined here. The UAS obtains this value from the Session-Expires header of a 2xx INVITE response that it sends. Proxies and UACs determine this value from the Session-Expires header in a 2xx INVITE response they receive. Minimum Timer: Because of the processing load of INVITE requests, all elements (proxy, UAC, UAS) can have a configured minimum value for the session interval that they are willing to accept. This value is called the minimum timer. Session Expiration: The time at which an element will consider the call timed out, if no successful INVITE transaction occurs beforehand. Refresh: An INVITE request sent during an active call leg. If the request generates a 2xx response, the session expiration is increased to the current time plus the session interval from the response. 3 Protocol Overview This section provides a brief overview of operation of the protocol. It is tutorial in nature and should not be considered as normative. Session refreshes are accomplished using SIP INVITEs. The initial INVITE establishes the duration of the session, which is carried in the Session-Expires header in the 2xx response to the INVITE. The Session-Expires header in the 2xx response also indicates which side will be responsible for generating these refreshes - the uac or uas. The responsible side then generates a refresh (using a re-INVITE) before the session expires. If the refreshes never gets a response to that re-INVITE, it sends a BYE to terminate the call. Similarly, if the other side never gets the re-INVITE before the session expires, it sends a BYE. The refreshes themselves are processed identically to a regular INVITE, so that the response to a re-INVITE carries the new time at which the session will expire. S.Donovan,J.Rosenberg [Page 3]
Internet Draft Session Timer October 1, 2001 It is an explicit goal of the protocol to operate so long as one of the two UAs in a call leg support the extension. That side, of course, ends up performing the refreshes. The other side will merely see them as repetitive re-INVITEs. This facilitates interoperability. The details of the protocol relate to negotiation of a reasonable value for the session interval, and negotiation of which side of the call leg is performing the refreshes. Negotiation of the session interval is critical. The value must be small enough to provide a useful expiration, but not so small to overload the proxies with re- INVITEs. The goal of the protocol is to choose a session interval that is the smallest of all the values requested by all elements, but only if that value is larger than the largest minimum timer requested by all elements. Negotiation of the refresher role is simpler. If only one side supports the extension, that side acts as refresher. Otherwise, one side chooses who will refresh. This negotiation takes place as part of INVITE processing, and due to the idempotency of INVITE requests, is effectively redone each time the session is refreshed with another re-INVITE. To negotiate the value of the refresh interval, the Min-SE and Session-Expires headers are used. The UAC generates an INVITE, and includes a Session-Expires if it wishes to use the session timer. As the INVITE traverses proxies, the proxies (and the UAS) can reduce the value of the session timer, but not lower than the value of the Min-SE header. If a proxy or UAS receives a request with a Session- Expires lower than a configured minimum, it can reject the request with a 422 response. This response contains a Min-SE header with the minimum allowed value. The client retries the request, inserting a Min-SE header containing the maximum value of the Min-SE headers returned in previous 422 responses for the call. In the case where the client isn't aware of the session timer extension, a proxy that receives a request with a Session-Expires lower than the configured minimum places the Min-SE header in the proxied request, and increases the Session-Expires header to that minimum. When the request eventually reaches the UAS (potentially after a few retries from 422), it will do so containing a Session-Expires header that meets the design criteria described above. The UAS returns a 200 OK with a Session-Expires header containing the final duration of the session. The header also contains a parameter, called refresher, that indicates which side is performing the refreshes. This basic behavior is built upon to handle the case where only one side supports the extension. When only the UAC supports it, one of the proxies "fills the shoes" of the UAS. Specifically, when the UAS does support session timer, it places the value of the session timer into the Session-Expires header in the 2xx response. When the UAS doesn't support it, the proxy closest to the UAS performs that job, S.Donovan,J.Rosenberg [Page 4]
Internet Draft Session Timer October 1, 2001 and inserts the value of the timer into the 2xx response as it passes by. 4 Session-Expires Header Field Definition The Session-Expires general header conveys the session interval for a SIP call. It is placed only in INVITE requests, and is allowed in any 200 class response to an INVITE. Unlike the SIP Expires header, it can only contain a delta-time. The session expiration is defined as that delta plus the time at which the header is observed in a final response. For example, if a UAS generates a 200 OK response to a re- INVITE that contained a Session-Expires header with a value of 3600, the UAS computes the session expiration as one hour after the time when the 200 OK was sent. For each proxy, the session expiration is one hour after the time when the 2xx was received or sent (assuming these two are sufficiently close together). For the UAC, the expiration time is one hour after the receipt of the final response. There is no absolute minimum value for the Session-Expires header. However, 1800 seconds (30 minutes) is RECOMMENDED. In other words, SIP entites MUST be prepared to handle Session-Expires values of any duration, but entities that insert the Session-Expires header SHOULD NOT choose values less than 30 minutes. Small session intervals can be destructive to the network. They cause excessive messaging traffic that affects both user agents and proxy servers. They increase the possibility of re-INVITE collisions (when both parties re-INVITE each other at the same time). Since the primary purpose of session timer is to provide a means to time out state in SIP elements, very small values won't generally be needed. 30 minutes was chosen since 95% of phone calls are less than this duration. However, the 30 minute minimum is listed as a SHOULD, and not a MUST, since the exact value for this number is dependent on many network factors, including network 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 of publication of this document, 30 minutes seems appropriate. Advances in technologies may result in the number being excessively large five years in the future. The syntax of the Session-Expires header is: Session-Expires = ("Session-Expires" | "x") ":" delta-seconds [refresher] refresher = ";" "refresher" "=" "uas"|"uac" S.Donovan,J.Rosenberg [Page 5]
Internet Draft Session Timer October 1, 2001 The optional refresher parameter indicates who will be doing the refreshing. It is RECOMMENDED that this parameter not be present in an initial INVITE, so that the negotiation mechanisms can successfully determine who will perform them. A 2xx response with the Session-Expires header MUST contain this parameter, indicating who will perform the refreshes. If the UAC wishes to insist on performing the refreshes, it MAY insert the parameter with a value of "uac" in the INVITE. It MAY use a value of "uas" if it knows that the other side supports session timer. It could know this by having received a request with a Supported header containing the value "timer" from its peer, or because a 2xx response received from the peer had a refresher parameter with the value "uas". Note that a compact form, the letter 'x', has been reserved for Session-Expires. The BNF for delta-seconds is defined in Section 6.20 of RFC 2543 [1]. Table 1 is an extension of tables 4 and 5 in [1] for the Session- Expires header: where enc e-e ACK BYE CAN INV OPT REG _____________________________________________________ Session-Expires R n h - - - o - - Session-Expires 2xx n h - - - o - - Table 1: Summary of header fields. "o": optional "-": not applicable, "R': request header, "r": response header, "g": general header, "*": needed if message body is not empty. A numeric value in the "type" column indicates the status code the header field is used with. 5 Min-SE Header Field Definition The Min-SE general header indicates the minimum value for the session interval, in units of delta-seconds. When used in an INVITE request, it indicates the smallest value of the session interval which can be used for that session. A proxy or UAS MUST NOT reduce the value of the session interval below the value in this header, when present in an INVITE request. When not present, the default value for this header is zero. The Min-SE header MUST NOT be used in responses except those with a 422 response code. It indicates the minimum value of the session interval that the server is willing to accept. S.Donovan,J.Rosenberg [Page 6]
Internet Draft Session Timer October 1, 2001 The syntax of the Min-SE header is: Min-SE = "Min-SE" ":" delta-seconds A UAC MAY include the Min-SE in an INVITE request, even if it never received a 422 previously. Table 2 is an extension of tables 4 and 5 in [1] for the Min-SE header: where enc e-e ACK BYE CAN INV OPT REG ____________________________________________ Min-SE R n h - - - o - - Min-SE 422 n h - - - m - - Table 2: Summary of header fields. "o": optional, "m": mandatory, "- ": not applicable, "R': request header, "r": response header, "g": general header, "*": needed if message body is not empty. A numeric value in the "type" column indicates the status code the header field is used with. 6 422 Response Code Definition This extension introduces the 422 response code. The default reason phrase for this code is "Session Timer Too Small". It is generated by a UAS or proxy when a request contains a Session-Expires header with a duration that is below the minimum timer for the server. The 422 response MUST contain a Min-SE header with the minimum timer for that server. 7 UAC Behavior 7.1 Generating an INVITE Request The rules for an initial INVITE are identical to those for a re- INVITE. An re-INVITE generated to refresh the session is a normal re-INVITE. It SHOULD contain SDP that describes the session, even if that SDP has not changed. In that case, the session description MUST somehow indicate that it has not changed. In the case of SDP, this is accomplished by including the same value for the origin field as previous messages to its peer. The same is true for the 200 class response to a re-INVITE used solely for refreshing. The response MUST contain a session description with an indication that it has not S.Donovan,J.Rosenberg [Page 7]
Internet Draft Session Timer October 1, 2001 changed. This is accomplished in the same way as for the request. It is possible for a UAS to believe that an INVITE is an initial INVITE, and for the UAC to believe it is a re-INVITE. This happens when a UA crashes and reboots between refreshes. When the refresh arrives at the rebooted UA, it decides to reject the call (generally, it will reject the call unless it explicitly is capable of recovering lost calls). If From tags are used, the UAS can detect that the re- INVITE is for an existing call by the existence of the tag in the To field of the re-INVITE. Therefore, a UAC MUST insert a From tag in an initial INVITE if it supports session timer. A UAS that wishes to reject a re-INVITE for a call that it believes is already terminated SHOULD respond with a 481. A UAC receiving a 481 to a session timer refresh MUST generate a BYE to terminate that call leg. If From tags were not mandatory, A could INVITE B without a From tag. B inserts a tag in the 200 OK. Now, B sends a re-INVITE to A. Meantime, A has crashed and rebooted. This re-INVITE has a From tag, but no To tag. It therefore cannot be distinguished for a new INVITE in which the UAC inserts a From tag. This ambiguity is resolved by mandating use of From tag with session timer. The requirement for From tags and responding with a 481 to stale re-INVITEs has been added to the updated version of RFC2543. However, to eliminate a dependency between this spec and the new version of SIP, these two features are specified here as well. A UAC which supports the session timer extension defined here MUST include a Supported header in each request (except ACK), listing the option tag "timer" [4]. It MUST do so even if the UAC is not requesting keepalives for the call. A UAC MAY include a Session-Expires in an initial INVITE request if it wishes for a session timer to be applied. The value of this header indicates session interval desired by the UAC. In an INVITE that is within a call leg with an active session timer, the header SHOULD be present, and SHOULD contain the current value of the session interval. If the INVITE is a re-INVITE it is RECOMMENDED that the refresher be set to "uac" if the element sending the INVITE is currently performing refreshes, else "uas" if its peer is performing the refreshes. In an initial INVITE, the UAC MAY include the refresher parameter with value "uac" if it wishes to perform the refreshes. If S.Donovan,J.Rosenberg [Page 8]
Internet Draft Session Timer October 1, 2001 the UAC wishes to leave this decision to the negotiation mechanisms described below, the refresher parameter is omitted. The UAC MAY include a Require in the request with the value "timer" to indicate that the UAS must support the session timer to participate in the session. This does not mean that the UAC is requiring the UAS to perform the refreshes, just that it is requiring the UAS to support the extension. In addition, the UAC MAY include a Proxy-Require header in the request with the value "timer" to indicate that proxies must support session timer in order to correctly process the request. However, usage of either Require or Proxy-Require by the UAC is NOT RECOMMENDED. They are not needed, since the extension works even when only the UAC supports the extension. The Supported header containing "timer" MUST still be included even if the Require or Proxy-Require headers are present containing "timer". The UAC MUST insert the Min-SE header into an re-INVITE request for a particular call leg if it has ever received a 422 response to a previous INVITE on the same leg, or if it has received an INVITE on that call leg which contained a Min-SE header. Similarly, if no call leg has been established yet, a UAC MUST insert the Min-SE header into an INVITE request for a particular call if it has ever received a 422 response to a previous INVITE with the same Call-ID. The value of the Min-SE header present in the INVITE MUST be the largest value amongst all Min-SE values returned in all 422 responses, or received in INVITE requests, on the same call leg, if a call leg has been established. If no leg is established, the Min-SE header is set to the largest value amongst all Min-SE values returned in all 422 responses for the same call. A result of this rule is that the maximum value of the Min-SE is effectively "cleared" once the call leg is established, and from that point on, only the values from proxies known to be on the proxy path are used. If the UAC inserts a Session-Expires into an INVITE, it MUST have a value greater than or equal to the value placed into the Min-SE header, if present. 7.1.1 Example As an example, a UAC sends an INVITE with Call-ID 1, and receives a 422 with a Min-SE header of 100. There is a tag in the To field, with a value of 8. The UAC retries the request. It contains a Min-SE header. Since no call leg has been established, the Min-SE header contains the largest value amongst all Min-SE values returned in 422 responses to INVITEs with the same Call-ID, in this case, with the Call-ID of 1. There has only been one such 422, and it had a Min-SE header with value 100. So, the retried INVITE contains a Min-SE header with value 100, and no tag in the To field, as there is no S.Donovan,J.Rosenberg [Page 9]
Internet Draft Session Timer October 1, 2001 call leg established yet. This INVITE generates another 422, this time with a Min-SE header with a value of 200 and a tag in the To field with value 9. Once again, the UAC retries the request. This time, the INVITE has a Min- SE with value 200. The call is accepted by the UAS, resulting in a 200 OK with a tag in the To field of 10. Later, the UAC sends a re- INVITE to refresh. Since a call leg is established, it looks to see whether there had been any Min-SE headers returned in any 422 responses on the same leg (that is, with a tag of 10). Since there were none, that refresh doesn't contain a Min-SE header. Later on, the UA receives a re-INVITE from its peer, containing a Min-SE header with the value of 100. This sets the maximum Min-SE value on this leg to 100. When the UA refreshes, it includes a Min-SE header with a value of 100. 7.2 Processing a 2xx Response When a 2xx response to the INVITE request arrives, it may or may not contain a Require header with the value "timer". If it does, the UAC MUST look for the Session-Expires header to process the response. If there was a Require header in the response with the value "timer", the Session-Expires header will always be present. UACs MUST be prepared to receive a Session-Expires header in a response even if none were present in the request. The "refresher" parameter will be present, indicating who will be performing the refreshes. If the parameter contains the value "uac", the UAC will perform them. It is possible that the UAC requested session timer (and thus included a Session-Expires in the request), but there was no Require or Session-Expires in the 200 class response. This will happen when the UAS doesn't support session timer, and only the UAC has asked for session timer (no proxies have requested it). In this case, if the UAC still wishes to use keepalives (they are purely for its benefit alone), it has to perform them. To do this, the UAC follows the procedures defined in this specification as if the Session-Expires header were in the 200 class response, and its value was the same as the one in the request (but with a refresher parameter of "uac"). If the 2xx response did not contain a Session-Expires header, there is no session expiration. In this case, no refreshes need to be sent. A 2xx without a Session-Expires can come for both initial and mid- call INVITE requests. The UAC remembers the session interval for a call leg as the value of the delta-time from the Session-Expires header in the most recent 2xx response to INVITE on that call leg. It is explicitly allowed for S.Donovan,J.Rosenberg [Page 10]
Internet Draft Session Timer October 1, 2001 there to be differing session intervals (or none at all) on differing call legs. This happens in the case where there are multiple 2xx OK responses to an initial INVITE with different tags in the To field. It also remembers whether it, or its peer, is the refresher on the leg. If the UAC must refresh a leg, it computes the session expiration for that leg. The session expiration is the time of reception of the last 2xx INVITE response on that leg plus the session interval for that leg. If UA wishes to continue with the session beyond the session expiration, it MUST generate a refresh before the session expiration. It is RECOMMENDED that this refresh be sent once half the session interval has elapsed. Additional procedures for this refresh are described in Section 10. 7.3 Processing a 422 Response If the response to an INVITE request is a 422 Session Timer Too Small response message, then the UAC MAY retry the INVITE. The procedures for retrying are described in Section 7.1. 8 Proxy Behavior Session timers are mostly of interest to call stateful proxy servers. However, a stateful proxy server MAY also follow the rules described here. Stateless proxies MUST NOT attempt to request session timers. Proxies which ask for session timers SHOULD record-route, since they won't receive refreshes if they don't. The proxy processing rules require the proxy to remember information between the request and response, ruling out stateless proxies. 8.1 Processing of requests Processing of requests is identical for INVITE and re-INVITE requests. To request a session timer for a call (either in progress or initial), a proxy makes sure that a Session-Expires header is present in an INVITE that it proxies for that call. A proxy MAY insert a Session-Expires header in the request before forwarding it, if none was present in the request. This Session-Expires header may contain any desired expiration time the proxy would like, but not with a duration lower than the value in the Min-SE header in the request, if present. The proxy MUST NOT insert a refresher parameter with value uac. It MAY insert one with value "uas", but this is redundant since S.Donovan,J.Rosenberg [Page 11]
Internet Draft Session Timer October 1, 2001 the UAS will conclude that it needs to refresh in any case. If the request already had a Session-Expires header, the proxy MAY reduce the value in the Session-Expires header, but MUST NOT set it to a duration lower than the value in the Min-SE header in the request, if present. If the value of the Session-Expires header is greater than or equal to the value in the Min-SE header (recall that the default is zero when Min-SE is not present), the proxy MUST NOT increase the value of the Session-Expires header. If the value of the Session-Expires header is lower than the value of the Min-SE header (possibly because the proxy increased the value of the Min-SE header, as described below), the proxy MUST increase the value of the Session-Expires to make it equal to Min-SE. The proxy MUST NOT insert or modify the value of the "refresher" parameter in the Session- Expires header if the header was present in the received request. If the request contains a Supported header with a value "timer", the proxy MAY reject the INVITE request if the session interval in the Session-Expires header is smaller than the minimum timer defined in the proxies local policy. The proxy does so by sending a 422 Session Timer Too Small response message. When sending the 422 response message, the proxy MUST include a Min-SE header with the value of its minimum timer. If the request doesn't indicate support for session timer, but the request contains a session interval that is too small, the proxy cannot usefully reject the request, as this would result in a call failure. Rather, the proxy SHOULD insert a Min-SE header containing its minimum timer. If a Min-SE header is already present, the proxy SHOULD increase (but MUST NOT decrease) the value to equal its minimum timer. The proxy MUST then increase the Session-Expires value to be equal to the value in the Min-SE header, as described above. A proxy MUST NOT insert a Min-SE header, or modify the value of an existing header, in a proxied request if that request contains a Supported header with the value "timer". This is needed to protect against certain denial of service attacks, described in Section 11. Assuming the proxy has requested session timer (and thus has possibly inserted the Session-Expires header or reduced it), the proxy MUST remember that it is using session timer, and also remember the value of the Session-Expires header from the proxied request. This MUST be remembered for the duration of the transaction. The proxy MUST remember, for the duration of the transaction, whether the request contained the Supported header with the value "timer". If the request did not contain a Supported header with the value "timer", the proxy MAY insert a Require header into the request, with the value "timer". However, this is NOT RECOMMENDED. This allows the S.Donovan,J.Rosenberg [Page 12]
Internet Draft Session Timer October 1, 2001 proxy to insist on session timer for the session. This header is not needed if a Supported header was in the request; in this case, the proxy can already be sure that the session timer can be used for the session. 8.2 Processing of Responses When the final response to the request arrives, it is examined by the proxy. If the response does not contain a Session-Expires header, but the proxy remembers that it requested a session timer in the request (by inserting, modifying, or examining and accepting the Session-Expires in the proxied INVITE), this means that the UAS did not support the session timer. If the proxy remembers that the UAC did not support session timer either, the proxy forwards the response upstream normally. There is no session expiration for this call leg. If, however, the proxy remembers that the UAC did support session timer, additional processing is needed. Because there is no Session-Expires or Require in the response, the proxy knows it is the first session-timer-aware proxy to receive the response. This proxy MUST insert a Session-Expires header into the response with the value it remembered from the forwarded request. It MUST set the value of the "refresher" parameter to "uac". The proxy MUST also insert the Require header into the response, with the value "timer", before forwarding it upstream. If the response received contains a Session-Expires header, no additional response processing is needed. The response is processed normally. In all cases, if the final response forwarded upstream by the proxy contains a Session-Expires header, its value represents the session interval for the call leg associated with that response. The proxy computes the session expiration as the time when the 2xx response is forwarded upstream, plus the session interval. This session expiration MUST update any existing session expiration for the call leg. The refresher param in the Session-Expires header in the 2xx response forwarded upstream will be present, and it indicates which UA is performing the refreshes. There can be multiple 200 class responses to a single INVITE, each representing a different call leg, resulting in multiple session expirations, one for each call leg. In all cases, the proxy MUST NOT modify the value of the Session- Expires header received in the response (assuming one was present) before forwarding it upstream. S.Donovan,J.Rosenberg [Page 13]
Internet Draft Session Timer October 1, 2001 8.3 Session Expiration When the current time equals or passes the session expiration for a call leg, the proxy MAY remove associated call state, and MAY free any resources associated with the call. Unlike the UA, it MUST NOT send a BYE. 9 UAS Behavior When a UAS receives an INVITE, the processing of that INVITE can logically be broken into two steps. In the first step, the UAS acts as a "virtual proxy", and follows the rules specified in Section 8.1 as if it were a proxy. This means that the same session timer manipulations that a proxy can do, can also be done by a UAS. Specifically, this means that it can insert or reduce the session timer (but not below Min-SE if present), reject the request with a 422, and insert/increase the Min-SE, just as a proxy can. Of course, rather than proxying the request, the "modified" request is passed into the second step of processing, which we call the "virtual UAS" processing. Viewing the UAS as the concatenation of a proxy and a UAS-specific processing component simplifies the specification of behavior and guarantees consistency. This separation is for the purposes of defining behavior. It does not mandate that the implementation work this way. Once the request is received by the virtual UAS (assuming it is received; it may have been rejected with a 422 based on the rules in Section 8.1), virtual UAS processing begins. If the virtual UAS wishes to accept the call, it copies the value of the Session-Timer from the request received from the first step into the 2xx response. The virtual UAS MUST then set the value of the refresher parameter in the Session-Expires header present in a 200 class response. This value specifies who will perform refreshes for the call leg. The value is set based on the value of this parameter in the request and on whether the UAC supports session timer. Table 3 defines how the value in the response MUST be set. A value of 'none' in the 2nd column means that there was no refresher parameter in the request. A value of 'NA' in the third column means that this particular combination shouldn't happen, as its disallowed by the protocol. In the fourth row of Table 3, since the UAC supports the session timer, and so does the UAS, the UAS can elect for itself or the UAC to perform the refreshes. Note that the results of the above table are that the UACs choice of refresher cannot be changed by the virtual UAS. S.Donovan,J.Rosenberg [Page 14]
Internet Draft Session Timer October 1, 2001 UAC supports? refresher parameter refresher parameter in request in response N none uas N uac NA N uas uas Y none uas or uac Y uac uac Y uas uas Table 3: UAS Behavior If the refresher parameter in the Session-Expires header in the 200 class response has a value of "uac", the UAS MUST place a Require header into the response with the value "timer". This is because the uac is performing refreshes and the response has to be processed for the UAC to know this. If the refresher parameter in the 200 class response has a value of "uas", and the Supported header in the request contained the value "timer", the UAS SHOULD place a Require header into the response with the value "timer". In this case, the UAC is not refreshing, but it is supposed to send a BYE if it never receives a refresh. Since the call will still succeed without the UAC doing this, insertion of the Require is a SHOULD here, rather than a MUST. The UAS remembers the session interval for a call leg as the value of the delta-time from the Session-Expires header in the most recent 2xx response to INVITE on that call leg. It also remembers whether it, or its peer, is the refresher on the leg. If the UAS must refresh a leg, it computes the session expiration for that leg. The session expiration is the time of transmission of the last 2xx INVITE response on that leg plus the session interval for that leg. If UA wishes to continue with the session beyond the session expiration, it MUST generate a refresh before the session expiration. It is RECOMMENDED that this refresh be sent once half the session interval has elapsed. Additional procedures for this refresh are described in Section 10. 10 Performing Refreshes The side generating a refresh does so according to the UAC procedures defined in Section 7. If no response to a refreshing re-INVITE is received before the session expiration, the UA SHOULD send a BYE request to terminate the call. It SHOULD send this BYE slightly before session expiration. The S.Donovan,J.Rosenberg [Page 15]
Internet Draft Session Timer October 1, 2001 minimum of ten seconds and one third the session interval is RECOMMENDED. For example, if the session interval is 120 seconds, one third of this is 40 seconds. Since the minimum of 10 seconds and 40 seconds is 10 seconds, the BYE would be sent 10 seconds before the session expires. Similarly, if the side not performing refreshes does not receive a re-INVITE refreshing the session before the session expiration, they SHOULD send a BYE to terminate the call, slightly before the session expiration. The minimum of ten seconds and one third the session interval is RECOMMENDED. Firewalls and NATs may be very unforgiving about allowing SIP traffic to pass after the expiration time of the session. It is for this reason that the BYE should be sent before the expiration. 11 Security Considerations The session timer introduces the capability of a proxy or UA element to force compliant clients to send refreshes at a rate of the element's choosing. This introduces the possibility of rogue proxies or UASes introducing denial-of-service attacks. However, the mechanisms in this specification prevent that from happening. First, consider the case of a rogue UAC that wishes to force a UAS to generate refreshes at a rapid rate. To do so, it inserts a Session- Expires header into an INVITE with a low duration and a refresher parameter equal to uas. Assume it places a Supported header into the request. Any proxy, or the UAS, which objects to this low timer will reject the request with a 422, therefore preventing the attack. If no Supported header was present, the proxies will insert a Min-SE header into the request before forwarding it. As a result, the UAS will not choose a session timer lower than the minimum acceptable one to all elements on the path. This too prevents the attack. Next, consider the case of a rogue UAS that wishes to force a UAC to generate refreshes at a rapid rate. In that case, the UAC has to support session timer. The initial INVITE arrives at the rogue UAS, which returns a 2xx with a very small session interval. The UAC uses this timer, and quickly sends a refresh. Section 7.1 requires the UAC to copy the current session interval into the Session-Expires header in the request. This enables the proxies to see the current value. The proxies will reject this request, and provide a Min-SE with a S.Donovan,J.Rosenberg [Page 16]
Internet Draft Session Timer October 1, 2001 higher minimum. The UAC will then use this higher minimum. Note, that if the proxies did not reject the request, but rather proxied the request with a Min-SE header, an attack would still be possible. The UAS could discard this header in a 2xx response, and force the UAC to continue to generate rapid requests. In a similar fashion, a rogue proxy cannot force either the UAC or UAS to generate refreshes unless the proxy remains on the signaling path, and sees every request and response. It is also RECOMMENDED that IP or transport level security is used when communicating between proxies, and that requests with Session- Expires headers only be accepted over these secure transports. 12 Examples The following examples are meant to illustrate the functionality associated with the session timer. In the interest of brevity, all headers except Supported, Session-Expires, Min-SE and Require are intentionally left out of the SIP messages. 12.1 Basic session timer In this case, two UAs communicate directly, with no proxies. Both support the session timer. The call is setup with a one hour expiration. Half an hour later, the UAC refreshes the session. Calling UA -> Called UA INVITE Supported: timer Session-Expires: 3600 Calling UA <- Called UA 200 OK Require: timer Session-Expires: 3600;refresher=uac Called UA starts timer on send Calling UA starts timer on receipt Calling UA -> Called UA ACK 1800 seconds later: Calling UA -> Called UA INVITE Supported: timer Session-Expires: 3600;refresher=uac S.Donovan,J.Rosenberg [Page 17]
Internet Draft Session Timer October 1, 2001 Calling UA <- Called UA 200 OK Require: timer Session-Expires: 3600;refresher=uac Called UA starts timer on send Calling UA starts timer on receipt Calling UA -> Called UA ACK 3550 seconds later the called UA did not receive a re-INVITE. It therefore considers the call terminated and sends a BYE: Calling UA <- Called UA BYE Calling UA -> Called UA 200 OK 12.2 Basic negotiation of Session Time In this configuration, two UAs talk through a single proxy server. Both the proxy and the UAS reduce the session timer. Calling UA -> proxy INVITE Supported: timer Session-Expires: 3600 proxy -> Called UA INVITE proxy wants a shorter timer Supported: timer Session-Expires: 180 proxy <- Called UA 200 OK Called UA wants a shorter timer Session-Expires: 120;refresher=uac Called UA starts timer Require: timer Calling UA <- proxy 200 OK Session-Expires: 120;refresher=uac Proxy starts timer on send Require: timer Calling UA starts timer on receipt Calling UA -> proxy S.Donovan,J.Rosenberg [Page 18]
Internet Draft Session Timer October 1, 2001 ACK proxy -> Called UA ACK For whatever reason, the calling UA decides not to refresh. So, after 110 seconds, it sends a BYE. Calling UA -> proxy BYE proxy -> Called UA BYE proxy <- Called UA 200 OK Calling UA <- proxy 200 OK 12.3 No Session-Expires Header in INVITE In this scenario, the UA sends an INVITE without a Session-Expires header and with a Supported header containing the option tag "timer". Since the proxy wants session timer for the call, it adds the Session-Expires header. Calling UA -> proxy INVITE No Session-Expires Supported: timer proxy -> Called UA INVITE Supported: timer Session-Expires: 3600 Proxy added Session-Expires proxy <- Called UA 200 OK Session-Expires: 3600;refresher=uac Called UA starts timer on send Require: timer Calling UA <- proxy 200 OK Session-Expires: 3600;refresher=uac Proxy starts timer on send S.Donovan,J.Rosenberg [Page 19]
Internet Draft Session Timer October 1, 2001 Require: timer Calling UA starts timer on receipt Calling UA -> proxy ACK proxy -> Called UA ACK 12.4 Session timer without Calling UA Support In this scenario, the calling UA sends and INVITE without a Session- Expires header and without a Supported header containing the option tag "timer". Since the proxy wants session timer for the call it adds Session-Expires header before proxying the INVITE to the called UA. Calling UA -> proxy INVITE proxy -> Called UA INVITE Proxy adds session expires Session-Expires: 3600 proxy <- Called UA 200 OK Called UA wants a shorter timer Session-Expires: 120;refresher=uas Called UA starts timer on send Calling UA <- proxy 200 OK Session-Expires: 120;refresher=uas Proxy starts timer on send Called UA starts timer on receipt Calling UA -> proxy ACK proxy -> Called UA ACK Sixty seconds later, the called UA sends a re-INVITE. Note that the called UA does support session timer, so it includes a header{Supported} header in the request. The proxy adds the Session-Expires and Require headers into the response from the calling UA. proxy <- Called UA S.Donovan,J.Rosenberg [Page 20]
Internet Draft Session Timer October 1, 2001 INVITE Supported: timer Session-Expires: 120;refresher=uac Calling UA <- proxy INVITE Supported: timer Session-Expires:120;refresher=uac Calling UA -> proxy 200 OK proxy -> Called UA 200 OK Session-Expires: 120;refresher=uac Proxy updates timer on send Require: timer Called UA updates timer on receipt proxy <- Called UA ACK Calling UA <- proxy ACK The Calling UA terminates the session for non timer related reasons: Calling UA -> proxy BYE proxy -> Called UA BYE proxy <- Called UA 200 OK Calling UA <- proxy 200 OK 12.5 Session Timer without Called UA Support In this scenario, the calling UA indicates that it supports the session timer, but does not add the Session-Expires header into the INVITE. The proxy adds it, but session timer is not supported by the UAS. The call is still set up with a session timer, as all that is S.Donovan,J.Rosenberg [Page 21]
Internet Draft Session Timer October 1, 2001 required is for one of the user agents involved in the call leg to understand the "timer" feature. Calling UA -> proxy INVITE k: timer proxy -> Called UA INVITE proxy adds S-E header k: timer Session-Expires: 3600 proxy <- Called UA 200 OK Called UA doesn't understand session timer Calling UA <- proxy 200 OK Session-Expires: 3600;refresher=uac Proxy adds S-E and Require Require: timer Proxy starts timer on send Calling UA starts timer on receipt Calling UA -> proxy ACK proxy -> Called UA ACK The UAC then re-invites, which is responded to with a 400 because the new media streams were rejected. Since this is a re-INVITE, the session is still active. Calling UA -> proxy INVITE k: timer Session-Expires: 3600;refresher=uac UA asks for timer this time This is not mandatory proxy -> Called UA INVITE proxy does not reduce Session-Expires header k: timer Session-Expires: 3600;refresher=uac S.Donovan,J.Rosenberg [Page 22]
Internet Draft Session Timer October 1, 2001 proxy <- Called UA 400 Rejected Media Called UA doesn't understand session timer Calling UA <- proxy 400 Rejected Media Calling UA -> proxy ACK proxy -> Called UA ACK 12.6 Neither UA Supports Session Timer In this case, neither UA supports the session timer. However, one of the proxies on the call setup path requests (but does not require) it. The call completes without session timers. Calling UA -> proxy INVITE proxy -> Called UA INVITE proxy adds S-E header compact form x: 3600 proxy <- Called UA 200 OK Called UA doesn't understand session timer Calling UA <- proxy proxy doesn't add S-E since it knows Calling UA 200 OK doesn't support it Calling UA -> proxy ACK proxy -> Called UA ACK 12.7 Both UAs Support, Change in Roles In this case, both user agents support session timer. The initial INVITE from caller to callee results in refreshes being generated by S.Donovan,J.Rosenberg [Page 23]
Internet Draft Session Timer October 1, 2001 the caller. A re-INVITE sent from the callee changes that role so that the callee refreshes. Calling UA -> proxy INVITE Supported: timer Session-Expires: 3600 proxy -> Called UA INVITE Proxy wants timer, no change in value Supported: timer Session-Expires: 3600 proxy <- Called UA 200 OK Called UA supports timer Session-Expires: 3600;refresher=uac Inserts Require, Session-Expires Require: timer Called UA starts timer on send Calling UA <- proxy Calling UA sees refresher=uac 200 OK It is refreshing Session-Expires: 3600;refresher=uac Proxy starts timer on send Require: timer Calling UA starts timer on receipt Calling UA -> proxy ACK proxy -> Called UA ACK The called UA (which is a UAC for this transaction) now sends a re- INVITE. For whatever reason, it decides to switch roles by explicitly designating the itself as the refresher. proxy <- Called UA INVITE Supported: timer Session-Expires: 3600;refresher=uac Calling UA <- proxy INVITE proxy wants timer, no change in value Supported: timer Session-Expires: 3600;refresher=uac S.Donovan,J.Rosenberg [Page 24]
Internet Draft Session Timer October 1, 2001 Calling UA -> proxy 200 OK Calling UA supports timer Session-Expires: 3600;refresher=uac Inserts Session-Expires Require: timer Calling UA updates timer on send proxy -> Called UA Called UA sees 200 w/refresher=uac 200 OK It is refreshing Session-Expires: 3600;refresher=uac Proxy updates timer on send Require: timer Called UA updates timer on receipt proxy <- Called UA ACK Calling UA <- proxy ACK 12.8 Proxy Rejects Timer In this call flow, the calling UA sends an INVITE with a Session- Expires header that is low. This arrives at a proxy, which rejects it with a 422 because it is too low. The proxy offers a larger minimum timer. The calling UA retries with a new Session-Expires and with a Min-SE header. Calling UA -> Proxy INVITE Supported: timer Session-Expires: 10 UAC uses low timer Calling UA <- Proxy 422 Timer Too Low Session-Expires: 200 Proxy says minimum is 200s Calling UA -> Proxy ACK Calling UA -> Proxy INVITE Supported: timer Session-Expires: 300 UAC chooses larger SE Min-SE: 200 Minimum is 200 Proxy -> Called UA INVITE S.Donovan,J.Rosenberg [Page 25]
Internet Draft Session Timer October 1, 2001 Supported: timer Session-Expires: 250 Proxy lowers to 250 Min-SE: 200 Proxy <- Called UA 200 Require: timer Session-Expires: 200;refresher=uac UAS lowers to 200 Calling UA <- Proxy 200 Require: timer Session-Expires: 200;refresher=uac Calling UA -> Proxy ACK Proxy -> Called UA ACK 13 Acknowledgements The authors wish to thank Brett Tate for his contributions to this work. 14 Author's Addresses Steven R. Donovan dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, Texas 75024 email: sdonovan@dynamicsoft.com Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936 email: jdrosen@dynamicsoft.com S.Donovan,J.Rosenberg [Page 26]
Internet Draft Session Timer October 1, 2001 15 Bibliography [1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: session initiation protocol," Request for Comments 2543, Internet Engineering Task Force, Mar. 1999. [2] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: a transport protocol for real-time applications," Request for Comments 1889, Internet Engineering Task Force, Jan. 1996. [3] S. Bradner, "Key words for use in RFCs to indicate requirement levels," Request for Comments 2119, Internet Engineering Task Force, Mar. 1997. [4] J. Rosenberg and H. Schulzrinne, "The SIP supported header," Internet Draft, Internet Engineering Task Force, Feb. 2001. Work in progress. Table of Contents 1 Introduction ........................................ 1 2 Terminology ......................................... 2 3 Protocol Overview ................................... 3 4 Session-Expires Header Field Definition ............. 5 5 Min-SE Header Field Definition ...................... 6 6 422 Response Code Definition ........................ 7 7 UAC Behavior ........................................ 7 7.1 Generating an INVITE Request ........................ 7 7.1.1 Example ............................................. 9 7.2 Processing a 2xx Response ........................... 10 7.3 Processing a 422 Response ........................... 11 8 Proxy Behavior ...................................... 11 8.1 Processing of requests .............................. 11 8.2 Processing of Responses ............................. 13 8.3 Session Expiration .................................. 14 9 UAS Behavior ........................................ 14 10 Performing Refreshes ................................ 15 11 Security Considerations ............................. 16 12 Examples ............................................ 17 12.1 Basic session timer ................................. 17 12.2 Basic negotiation of Session Time ................... 18 12.3 No Session-Expires Header in INVITE ................. 19 S.Donovan,J.Rosenberg [Page 27]
Internet Draft Session Timer October 1, 2001 12.4 Session timer without Calling UA Support ............ 20 12.5 Session Timer without Called UA Support ............. 21 12.6 Neither UA Supports Session Timer ................... 23 12.7 Both UAs Support, Change in Roles ................... 23 12.8 Proxy Rejects Timer ................................. 25 13 Acknowledgements .................................... 26 14 Author's Addresses .................................. 26 15 Bibliography ........................................ 27 S.Donovan,J.Rosenberg [Page 28]
