INVITE. The UAC also remembers whether it or its peer is the
refresher on for the session.
If the UAC must perform the refreshes, it computes the session
expiration for that session. The session expiration is the time of
reception of the last 2xx response to a session refresh request on
that dialog plus the session interval for that session. If the UA
seeks 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.
Similarly, a re-INVITE or UPDATE request sent within a dialog for
purposes other than session refreshes will also have the effect of
refreshing the session, and its processing will follow the procedures
defined in this specification.
7.3. Processing a 422 Response
If the response to a session refresh request is a 422 (Session
Interval Too Small) response message, then the UAC MAY retry the
request. The procedures for retrying are described in Section 7.4.
This new request constitutes a new transaction and SHOULD have the
same value as the Call-ID, To, and From of the previous request, but
the CSeq should contain a new sequence number that is one higher than
the previous.
7.4. Generating Subsequent Session Refresh Requests
The values of Supported, Require, and Proxy-Require used in the
initial Session refresh request MUST be used.
The UAC MUST insert the Min-SE header field into a session refresh
request for a particular dialog if it has ever received a 422
response to a previous session refresh request on the same dialog, or
if it has received a session refresh request on that dialog that
contained a Min-SE header field. Similarly, if no dialog has been
established yet, a UAC MUST insert the Min-SE header field into an
INVITE request if it has ever received a 422 response to a previous
INVITE request with the same Call-ID.
The value of the Min-SE header field present in a session refresh
request MUST be the largest value among all 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, the Min-SE header field value is set
to the largest value among all Min-SE header field values returned in
all 422 responses for an INVITE request with the same Call-ID. A
result of this rule is that the maximum value of the Min-SE is
effectively ’cleared’ once the dialog is established, and from that
point on, only the values from proxies known to be on the proxy path
will end up being used.
The UAC may have its own opinions about the minimum session interval.
In that case, if 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 present, it SHOULD be equal to the maximum of the Min-SE header
field (recall that its default value when not present is 90 seconds)
and the current session interval. Inclusion of the Session-Expires
header field with this value avoids certain denial-of-service
attacks, as documented in Section 11. As such, a UA should only
ignore the SHOULD in unusual and singular cases where it is desirable
to change the session interval mid-dialog.
If the session refresh request is not the initial one, it is
RECOMMENDED that the refresher parameter be set to ’uac’ if the
element sending the request is currently performing refreshes, and to
’uas’ if its peer is performing the refreshes. This way, the role of
refresher does not change on each refresh. However, if it wishes to
explicitly change the roles, it MAY use a value of ’uas’ if it knows
that the other side supports the session timer. It could know this
by having received a request from its peer with a Supported header
field containing the value ’timer’. If it seeks to reselect the
roles, it MAY omit the parameter.
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 that its peer supports the UPDATE method, it is
RECOMMENDED that UPDATE be used instead of a re-INVITE. A UA can
make this determination 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], but a re-INVITE SHOULD contain one, even if the details of
the session have not changed. In that case, the offer MUST indicate
that it has not changed. In the case of SDP, this is accomplished by
including the same value for the origin field as did previous SDP
messages to its peer. The same is true for an answer exchanged as a
result of a session refresh request; if it has not changed, that MUST
be indicated.
8. Proxy Behavior
Session timers are mostly of interest to call stateful proxy servers
(that is, to servers that maintain the state of calls and dialogs
established through them). However, a stateful proxy server (that
is, a server which is aware of transaction state but does not retain
call or dialog state) MAY also follow the rules described here.
Stateless proxies MUST NOT attempt to request session timers.
Proxies that ask for session timers SHOULD record-route, as 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 all session refresh requests.
To request a session timer for a session, a proxy makes sure that a
Session-Expires header field is present in a session refresh request
for that session. A proxy MAY insert a Session-Expires header field
in the request before forwarding it if none was present in the
request. This Session-Expires header field may contain any desired
expiration time the proxy would like, but not with a duration lower
than the value in the Min-SE header field in the request, if it is
present. The proxy MUST NOT include a refresher parameter in the
header field value.
If the request already had a Session-Expires header field, the proxy
MAY reduce its value but MUST NOT set it to a duration lower than the
value in the Min-SE header field in the request, if it is present.
If the value of the Session-Expires header field is greater than or
equal to the value in the Min-SE header field (recall that the
default is 90 seconds when the Min-SE header field is not present),
the proxy MUST NOT increase the value of the Session-Expires header
field. If the value of the Session-Expires header field is lower
than the value of the Min-SE header field (possibly because the proxy
increased the value of the Min-SE header field, as described below),
the proxy MUST increase the value of the Session-Expires header field
to make it equal to Min-SE header field value. The proxy MUST NOT
insert or modify the value of the ’refresher’ parameter in the
Session-Expires header field.
If the request contains a Supported header field with a value
’timer’, the proxy MAY reject the INVITE request with a 422 (Session
Interval Too Small) response if the session interval in the
Session-Expires header field is smaller than the minimum interval
defined by the proxy’s local policy. When sending the 422 response,
the proxy MUST include a Min-SE header field with the value of its
minimum interval. That minimum MUST NOT be lower than 90 seconds.
If the request doesn’t indicate support for the session timer but
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 field containing its
minimum interval. If a Min-SE header field is already present, the
proxy SHOULD increase (but MUST NOT decrease) the value to its
minimum interval. The proxy MUST then increase the Session-Expires
header field value to be equal to the value in the Min-SE header
field, as described above. A proxy MUST NOT insert a Min-SE header
field or modify the value of an existing header field in a proxied
request if that request contains a Supported header field with the
value ’timer’. This is needed to protect against certain denial of
service attacks, described in Section 11.
Assuming that the proxy has requested a session timer (and thus has
possibly inserted the Session-Expires header field or reduced it),
the proxy MUST remember that it is using a session timer, and also
remember the value of the Session-Expires header field 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 field with the value
’timer’. If the request did not contain a Supported header field
with the value ’timer’, the proxy MAY insert a Require header field
with the value ’timer’ into the request. However, this is NOT
RECOMMENDED. This allows the proxy to insist on a session timer for
the session. This header field is not needed if a Supported header
field was in the request; in this case, the proxy would already be
sure 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 field but
the proxy remembers that it requested a session timer in the request
(by inserting, modifying, or examining and accepting the
Session-Expires header field in the proxied request), this means that
the UAS did not support the session timer. If the proxy remembers
that the UAC did not support the session timer either, the proxy
forwards the response upstream normally. There is no session
expiration for this session. If, however, the proxy remembers that
the UAC did support the session timer, additional processing is
needed.
Because there is no Session-Expires or Require header field in the
response, the proxy knows that it is the first session-timer-aware
proxy to receive the response. This proxy MUST insert a
Session-Expires header field 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 add the ’timer’
option tag to any Require header field in the response, and if none
was present, add the Require header field with that value before
forwarding it upstream.
If the received response contains a Session-Expires header field, no
modification of the response is needed.
In all cases, if the 2xx response forwarded upstream by the proxy
contains a Session-Expires header field, its value represents the
session interval for the session 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 session. The refresher parameter in the Session-Expires header
field in the 2xx response forwarded upstream will be present, and it
indicates which UA is performing the refreshes. There can be
multiple 2xx responses to a single INVITE, each representing a
different dialog, resulting in multiple session expirations, one for
each session associated with each dialog.
The proxy MUST NOT modify the value of the Session-Expires header
field received in the response (assuming one was present) before
forwarding it upstream.
8.3. Session Expiration
When the current time equals or passes the session expiration for a
session, 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
The UAS must respond to a request for a session timer by the UAC or a
proxy in the path of the request, or it may request that a session
timer be used itself.
If an incoming request contains a Supported header field with a value
’timer’ and a Session Expires header field, the UAS MAY reject the
INVITE request with a 422 (Session Interval Too Small) response if
the session interval in the Session-Expires header field is smaller
than the minimum interval defined by the UAS’ local policy. When
sending the 422 response, the UAS MUST include a Min-SE header field
with the value of its minimum interval. This minimum interval MUST
NOT be lower than 90 seconds.
If the UAS wishes to accept the request, it copies the value of the
Session-Expires header field from the request into the 2xx response.
The UAS response MAY reduce its value but MUST NOT set it to a
duration lower than the value in the Min-SE header field in the
request, if it is present; otherwise the UAS MAY reduce its value but
MUST NOT set it to a duration lower than 90 seconds. The UAS MUST
NOT increase the value of the Session-Expires header field.
If the incoming request contains a Supported header field with a
value ’timer’ but does not contain a Session-Expires header, it means
that the UAS is indicating support for timers but is not requesting
one. The UAS may request a session timer in the 2XX response by
including a Session-Expires header field. The value MUST NOT be set
to a duration lower than the value in the Min-SE header field in the
request, if it is present.
The UAS MUST set the value of the refresher parameter in the
Session-Expires header field in the 2xx response. This value
specifies who will perform refreshes for the dialog. The value is
based on the value of this parameter in the request, and on whether
the UAC supports the session timer extension. The UAC supports the
extension if the ’timer’ option tag was present in a Supported header
field in the request. Table 2 defines how the value in the response
is 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 it
is disallowed by the protocol.
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 Behavior
The fourth row of Table 2 describes a case where both the UAC and UAS
support the session timer extension, and where the UAC did not select
who will perform refreshes. This allows the UAS to decide whether it
or the UAC will perform the refreshes. However, as the table
indicates, the UAS cannot override the UAC’s choice of refresher, if
it made one.
If the refresher parameter in the Session-Expires header field in the
2xx response has a value of ’uac’, the UAS MUST place a Require
header field 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 2xx response has a value of ’uas’ and the Supported header field
in the request contained the value ’timer’, the UAS SHOULD place a
Require header field 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 sending a BYE, insertion of the Require is a
SHOULD here, and not a MUST.
Just like the UAC, the UAS stores state for the session timer. This
state includes the session interval, the session expiration, and the
identity of the refresher. This state is bound to the dialog used to
set up the session. The session interval is set to the value of the
delta-time from the Session-Expires header field in the most recent
2xx response to a session refresh request on that dialog. It also
remembers whether it or its peer is the refresher on the dialog,
based on the value of the refresher parameter from the most recent
2xx response to a session refresh request on that dialog. If the
most recent 2xx response had no Session-Expires header field, there
is no session expiration, and no refreshes have to be performed.
If the UAS must refresh the session, it computes the session
expiration. The session expiration is the time of transmission of
the last 2xx response to a session refresh request on that dialog
plus the session interval. 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. Note that only a 2xx response to a session
refresh request extends the session expiration. This means that a UA
could attempt a refresh and receive a 422 response with a Min-SE
header field that contains a value much larger than the current
session interval. The UA will still have to send a session refresh
request before the session expiration (which has not changed), even
though this request will contain a value of the Session-Expires that
is much larger than the current session interval.
If the session refresh request transaction times out or generates 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 session refresh request does not
generate a 2xx response (and, as a result, the session is not
refreshed), and a response other than 408 or 481 is received, the UAC
SHOULD follow the rules specific to that response code and retry if
possible. For example, if the response is a 401, the UAC would retry
the request with new credentials. However, the UAC SHOULD NOT
continuously retry the request if the server indicates the same error
response.
Similarly, if the side not performing refreshes does not receive a
session refresh request before the session expiration, it SHOULD send
a BYE to terminate the session, slightly before the session
expiration. The minimum of 32 seconds and one third of the session
interval is RECOMMENDED.
Firewalls and NAT ALGs may be very unforgiving about allowing SIP
traffic to pass after the expiration time of the session. This is
why 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 UAs to send refreshes at a rate of the element’s
choosing. This introduces the possibility of denial-of-service
attacks with significant amplification properties. These attacks can
be launched from ’outsiders’ (elements that attempt to modify
messages in transit) or by ’insiders’ (elements that are legitimately
in the request path but are intent on doing harm). Fortunately, both
cases are adequately handled by this specification.
11.1. Inside Attacks
This introduces the possibility of rogue proxies or UAs 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 field into an INVITE with a low duration and a
refresher parameter equal to uas. Assume it places a Supported
header field into the request. The UAS or any proxy that objects to
this low timer will reject the request with a 422, thereby preventing
the attack. If no Supported header field was present, the proxies
will insert a Min-SE header field into the request before forwarding
it. As a result, the UAS will not choose a session timer lower than
the minimum allowed by 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.4 requires that
the UAC copy the current session interval into the Session-Expires
header field 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 higher minimum, which the UAC will then use. Note,
that if the proxies did not reject the request, but rather proxied
the request with a Min-SE header field, an attack would still be
possible. The UAS could discard this header field 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.
11.2. Outside Attacks
An element that can observe and modify a request or response in
transit can force rapid session refreshes. To prevent this, requests
and responses have to be protected by message integrity. Since the
session timer header fields are not end-to-end and are manipulated by
proxies, the SIP S/MIME capabilities are not suitable for this task.
Rather, integrity has to be protected by using hop-by-hop mechanisms.
As a result, 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. As adequate protection is obtained only
if security is applied on each hop, it is RECOMMENDED that the SIPS
URI scheme be used in conjunction with this extension. This means
that proxies that record-route and request session timer SHOULD
record-route with a SIPS URI. A UA that inserts 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 IANA procedures for
registering these.
12.1. IANA Registration of Min-SE and Session-Expires 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: x
12.2. IANA Registration of the 422 (Session Interval Too Small)
Response Code
The following is the registration for the 422 (Session Interval Too
Small) response code:
Response Code: 422
Default Reason Phrase: Session Interval Too Small
RFC Number: RFC 4028