draft-ietf-sip-session-timer-05.txt   draft-ietf-sip-session-timer-06.txt 
Internet Engineering Task Force SIP WG Internet Engineering Task Force SIP WG
Internet Draft S.Donovan,J.Rosenberg Internet Draft S.Donovan,J.Rosenberg
draft-ietf-sip-session-timer-05.txt dynamicsoft draft-ietf-sip-session-timer-06.txt dynamicsoft
July 20, 2001 August 24, 2001
Expires: February 2002 Expires: February 2002
The SIP Session Timer The SIP Session Timer
STATUS OF THIS MEMO STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 1, line 44 skipping to change at page 1, line 44
This document proposes an extension to the Session Initiation This document proposes an extension to the Session Initiation
Protocol (SIP). This extension allows for a periodic refresh of SIP Protocol (SIP). This extension allows for a periodic refresh of SIP
sessions through a re-INVITE. The refresh allows both user agents and sessions through a re-INVITE. The refresh allows both user agents and
proxies to determine if the SIP session is still active. The proxies to determine if the SIP session is still active. The
extension defines two new general headers, Session-Expires, which extension defines two new general headers, Session-Expires, which
conveys the lifetime of the session, and Min-SE, which conveys the conveys the lifetime of the session, and Min-SE, which conveys the
minimum allowed value for the session timer. minimum allowed value for the session timer.
1 Introduction 1 Introduction
The Session Initiation Protocol (SIP) [1], does not currently define The Session Initiation Protocol (SIP) [1], does not define a
a keepalive mechanism. The result is that call stateful proxies will keepalive mechanism. The result is that call stateful proxies will
not always be able to determine whether a call is still active or 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 not. For instance, when a user agent fails to send a BYE message at
the end of a session, or the BYE message gets lost due to network 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 problems, a call stateful proxy will not know when the session has
ended. In this situation, the call stateful proxy will retain state ended. In this situation, the call stateful proxy will retain state
for the call and has no deterministic method of determining when the for the call and has no deterministic method of determining when the
call state information no longer applies. call state information no longer applies.
To resolve this problem, this extension defines a keepalive mechanism To resolve this problem, this extension defines a keepalive mechanism
for SIP sessions. UAs send periodic re-INVITEs to keep the session for SIP sessions. UAs send periodic re-INVITEs to keep the session
skipping to change at page 2, line 42 skipping to change at page 2, line 42
SIP NAT ALG. The ALG embedded in a NAT will need to maintain state 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. for the duration of a call. This state must eventually be removed.
Relying on a BYE to trigger the removal of state, besides being Relying on a BYE to trigger the removal of state, besides being
unreliable, introduces a potential denial of service attack. unreliable, introduces a potential denial of service attack.
This document proposes an extension to SIP that defines a session This document proposes an extension to SIP that defines a session
expiration mechanism. Periodic refreshes, through re-INVITEs, are expiration mechanism. Periodic refreshes, through re-INVITEs, are
used to keep the session active. The extension is sufficiently used to keep the session active. The extension is sufficiently
backwards compatible with SIP that it works so long as either one of 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 the two participants in a call leg understand the extension. Two new
general headers, Session-Expires and Min-SE, are defined. Session- general headers, Session-Expires and Min-SE, and a new response code,
Expires conveys the duration of the session, and Min-SE conveys the 422, are defined. Session-Expires conveys the duration of the
minimum allowed value for the session expiration. 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 Protocol Overview 2 Terminology
UACs which support the session timer extension defined here MUST In this document, the key words "MUST", "MUST NOT", "REQUIRED",
include a Supported header in all requests, excepting ACK, containing "SHALL", "SHALLNOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
the option tag "timer" [3]. When a UAC makes a call, it MAY include a and "OPTIONAL" are to be interpreted as described in RFC 2119 [3] and
Session-Expires header in the INVITE request. The presence of the indicate requirement levels for compliant SIP implementations.
Session-Expires header indicates that the UAC wishes to use the
session timer for this call. Its value indicates the desired
expiration time of the session. The UAC MAY include the "refresher"
parameter in the Session-Expires header with the value "uac". This
indicates that the caller will perform refreshes for the session.
Proxies on the signaling path may have their own requirements for the Additionally, we define the following terms:
refresh interval of the session. If no Session-Expires was present,
the proxy MAY insert one if it so desires. If one was present, the
proxy can lower its value, but not to a value lower than the value in
the Min-SE header in the request, if present. The proxy MUST NOT
increase the value of the Session-Expires header. The proxy remembers
the value of Session-Expires that was finally used in the request.
The proxy also notes whether the UAC supports session timer, based on
whether the Supported header was present with the tag "timer". In all
cases, the proxy MUST NOT insert or modify the value of the
"refresher" parameter in the Session-Expires header.
If the proxy wishes to insist that the call is only established if Session Interval: The largest amount of time that can occur
the UAS supports session timer, it MAY insert a Require header into between INVITE requests in a call before it will be
the request, with the value "timer", although this is NOT considered timed out. The session interval is conveyed in
RECOMMENDED, since it eliminates the possibility of call the Session-Expires header defined here. The UAS obtains
establishment if the UAS does not support session timers. 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.
Eventually, the initial INVITE reaches the UAS. There are two cases - Minimum Timer: Because of the processing load of INVITE
the UAS supports session timer, or it does not. If it does, and the requests, all elements (proxy, UAC, UAS) can have a
response is otherwise acceptable to the UAS, the UAS MUST copy the configured minimum value for the session interval that they
Session-Expires into the 200 class response, or MAY add one into the are willing to accept. This value is called the minimum
response if none was present in the request. They UAS MAY reduce the timer.
session timer in the 200 class response, but not lower than the value
in the Min-SE header, if present. The UAS also sets the value of the
refresher parameter, based on rules in Section 7, which determines
who will be generating the re-INVITEs for the refreshing. If the UAC
is doing refreshes, the UAS additionally inserts a Require header
into the 200 class response, with the tag "timer". This informs the
UAC that special processing is needed for this response.
If the UAS does not support session timer, it behaves as a normal Session Expiration: The time at which an element will consider
UAS. Because of this, any 200 class response it generates will not the call timed out, if no successful INVITE transaction
contain the Session-Expires or Require header with the tag "timer". occurs beforehand.
The 200 class response travels backwards through the proxies. When it Refresh: An INVITE request sent during an active call leg. If
reaches a proxy which remembers that it asked for session timer, the the request generates a 2xx response, the session
proxy examines the response. If the response did not contain a expiration is increased to the current time plus the
Session-Expires header (meaning the UAS does not support session session interval from the response.
timer), additional proxy processing is needed. If the proxy remembers
that the UAC supported session timer, the proxy must return the value
of the session timer to the UAC. So, it inserts the Session-Expires
header into the response (using the value it remembered inserting),
sets the "refresher" parameter to "uac", and adds a Require header
with a value of "timer". If the proxy remembers that the UAC did not
support session timer, the proxy knows that session timer cannot be
used, since neither UAS nor UAC support it.
If the response received by the proxy does contain the Session- 3 Protocol Overview
Expires header, the "refresher" parameter will indicate which side is
performing refreshes.
The response then arrives at the UAC. If it contains a Require header This section provides a brief overview of operation of the protocol.
with the value "timer", the UAC knows that special processing of the It is tutorial in nature and should not be considered as normative.
response is needed. The response will also contain a Session-Expires
header, and the value of that header is used as the interval for
refreshes. The refresher parameter indicates who will be performing
the refreshes. If it contains the value "uac", the UAC knows it is
performing them. If it contains the value "uas", it knows that the
UAS is performing them.
The UAC then ACKs the INVITE. The Session-Expires MUST NOT be Session refreshes are accomplished using SIP INVITEs. The initial
included in the ACK. 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.
Whichever side is supposed to perform the refreshes MUST send a re- It is an explicit goal of the protocol to operate so long as one of
INVITE before the expiration time. This re-INVITE SHOULD contain a the two UAs in a call leg support the extension. That side, of
Session-Expires header. The processing of this re-INVITE by proxies course, ends up performing the refreshes. The other side will merely
and UAS is identical to that of the initial INVITE. see them as repetitive re-INVITEs. This facilitates interoperability.
If the side not performing refreshes does not receive a re-INVITE The details of the protocol relate to negotiation of a reasonable
refreshing the session before the session expires, they SHOULD send a value for the session interval, and negotiation of which side of the
BYE to terminate the call. If a refreshing UA does not receive a call leg is performing the refreshes. Negotiation of the session
response to the re-INVITE used to refresh the session, it SHOULD send interval is critical. The value must be small enough to provide a
a BYE to terminate the call. Similarly, if a proxy doesn't receive a useful expiration, but not so small to overload the proxies with re-
re-INVITE before expiration of the session, it MAY remove associated INVITEs. The goal of the protocol is to choose a session interval
call state, and MAY free any resources associated with the call. that is the smallest of all the values requested by all elements, but
Unlike the UA, it MUST NOT send a BYE. 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.
3 Session-Expires Header Field Definition 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.
The Session-Expires header conveys the expiration time for a SIP This basic behavior is built upon to handle the case where only one
session described in the body of the message. It is placed only in side supports the extension. When only the UAC supports it, one of
INVITE requests, and is allowed in any 200 class response to an the proxies "fills the shoes" of the UAS. Specifically, when the UAS
INVITE. Like the SIP Expires header, it can contain either an does support session timer, it places the value of the session timer
absolute time or a delta-time. If it contains an absolute time, this into the Session-Expires header in the 2xx response. When the UAS
time indicates the time at which a proxy or UA may safely destroy any doesn't support it, the proxy closest to the UAS performs that job,
state associated with the call. If it contains a delta time, the and inserts the value of the timer into the 2xx response as it passes
expiration time of the session is defined as that delta plus the time by.
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
expiration time of the session as one hour after the time when the
200 OK was sent. For each proxy, the expiration time 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.
Any entity that inserts a Session-Expires header with an absolute 4 Session-Expires Header Field Definition
time MUST also insert a Date header into the message. This ensures
proper operation for devices that do not have access to absolute
time.
There is no absolute minimum session refresh interval. However, 30 The Session-Expires general header conveys the session interval for a
minutes is RECOMMENDED. In other words, SIP entites MUST be prepared SIP call. It is placed only in INVITE requests, and is allowed in any
to handle session refresh intervals of any duration, but entities 200 class response to an INVITE. Unlike the SIP Expires header, it
that insert the Session-Expires header SHOULD NOT choose times that can only contain a delta-time. The session expiration is defined as
result in intervals less than 30 minutes. 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.
Small session timer values can be destructive to the network. They There is no absolute minimum value for the Session-Expires header.
cause excessive messaging traffic that affects both user agents and However, 1800 seconds (30 minutes) is RECOMMENDED. In other words,
proxy servers. They increase the possibility of re-INVITE collisions SIP entites MUST be prepared to handle Session-Expires values of any
(when both parties re-INVITE each other at the same time). Since the 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 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. 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 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 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 not a MUST, since the exact value for this number is dependent on
many network factors, including network bandwidths and latencies, many network factors, including network bandwidths and latencies,
computing power, memory availability, network topology, and of computing power, memory availability, network topology, and of
course, the application scenario. After all, SIP can set up any kind course, the application scenario. After all, SIP can set up any kind
of session, nut just a phone call. At the time of publication of this of session, not just a phone call. At the time of publication of this
document, 30 minutes seems appropriate. Advances in technologies may document, 30 minutes seems appropriate. Advances in technologies may
result in the number being excessively large five years in the result in the number being excessively large five years in the
future. future.
The syntax of the Session-Expires header is: The syntax of the Session-Expires header is:
Session-Expires = ("Session-Expires" | "x") ":" ( SIP-date | Session-Expires = ("Session-Expires" | "x") ":" delta-seconds
delta-seconds ) [refresher] [refresher]
refresher = ";" "refresher" "=" "uas"|"uac" refresher = ";" "refresher" "=" "uas"|"uac"
OPEN ISSUE: Is there really any reason for absolute times?
It just complicates things, since all operations really
need to be done using the delta-seconds. Plus, it will
require a Date header, so that a proxy will have to
subtract the two to arrive at a delta-time anyway.
RECOMMENDATION: Remove absolute time.
The optional refresher parameter indicates who will be doing the The optional refresher parameter indicates who will be doing the
refreshing. It is RECOMMENDED that this parameter not be present in refreshing. It is RECOMMENDED that this parameter not be present in
an initial INVITE, so that the negotiation mechanisms can an initial INVITE, so that the negotiation mechanisms can
successfully determine who will perform them. A response with the successfully determine who will perform them. A 2xx response with the
Session-Expires header MUST contain this parameter, indicating who Session-Expires header MUST contain this parameter, indicating who
will perform the refreshes. If the UAC wishes to insist on performing 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 refreshes, it MAY insert the parameter with a value of "uac" in
the initial INVITE. It MUST NOT use a value of "uas" in the initial the INVITE. It MAY use a value of "uas" if it knows that the other
INVITE, since it doesn't know whether the UAS is capable of side supports session timer. It could know this by having received a
refreshes. However, in a re-INVITE, it MAY use a value of "uas" if it request with a Supported header containing the value "timer" from its
knows that the other side supports session timer. 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 Note that a compact form, the letter 'x', has been reserved for
Session-Expires. Both SIP-Date and delta-seconds are defined in Session-Expires. The BNF for delta-seconds is defined in Section 6.20
Section 6.20 of RFC 2543 [1]. of RFC 2543 [1].
Table 1 is an extension of tables 4 and 5 in [1] for the Session- Table 1 is an extension of tables 4 and 5 in [1] for the Session-
Expires header: Expires header:
where enc e-e ACK BYE CAN INV OPT REG where enc e-e ACK BYE CAN INV OPT REG
_____________________________________________________ _____________________________________________________
Session-Expires R n h - - - o - - Session-Expires R n h - - - o - -
Session-Expires 2xx n h - - - o - - Session-Expires 2xx n h - - - o - -
Table 1: Summary of header fields. "o": optional "-": not applicable, Table 1: Summary of header fields. "o": optional "-": not applicable,
"R': request header, "r": response header, "g": general header, "*": "R': request header, "r": response header, "g": general header, "*":
needed if message body is not empty. A numeric value in the "type" needed if message body is not empty. A numeric value in the "type"
column indicates the status code the header field is used with. column indicates the status code the header field is used with.
4 Min-SE Header Field Definition 5 Min-SE Header Field Definition
The Min-SE request header indicates the minimum value for the The Min-SE general header indicates the minimum value for the session
duration of the session timer. It is in units of delta-seconds. An interval, in units of delta-seconds. When used in an INVITE request,
INVITE for a particular call leg which has generated a 422 response it indicates the smallest value of the session interval which can be
MUST contain the Min-SE header, and the value MUST be the largest used for that session. A proxy or UAS MUST NOT reduce the value of
value amongst all Session-Expires values returned in 422 responses on the session interval below the value in this header, when present in
that leg. A proxy or UAS MUST NOT reduce the value of the session an INVITE request.
timer below the value in this header, when present.
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.
The syntax of the Min-SE header is: The syntax of the Min-SE header is:
Min-SE = "Min-SE" ":" delta-seconds Min-SE = "Min-SE" ":" delta-seconds
A UAC MAY include the Min-SE in an INVITE request, even if it never A UAC MAY include the Min-SE in an INVITE request, even if it never
received a 422 previously. received a 422 previously.
Table 2 is an extension of tables 4 and 5 in [1] for the Session- Table 2 is an extension of tables 4 and 5 in [1] for the Min-SE
Expires header: header:
where enc e-e ACK BYE CAN INV OPT REG where enc e-e ACK BYE CAN INV OPT REG
____________________________________________ ____________________________________________
Min-SE R n h - - - o - - Min-SE R n h - - - o - -
Min-SE 422 n h - - - m - -
Table 2: Summary of header fields. "o": optional "-": not applicable, Table 2: Summary of header fields. "o": optional, "m": mandatory, "-
"R': request header, "r": response header, "g": general header, "*": ": not applicable, "R': request header, "r": response header, "g":
needed if message body is not empty. A numeric value in the "type" general header, "*": needed if message body is not empty. A numeric
column indicates the status code the header field is used with. value in the "type" column indicates the status code the header field
is used with.
5 UAC Behavior 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
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.
Without From tags, 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 A UAC which supports the session timer extension defined here MUST
include a Supported header in each request (excepting ACK), listing include a Supported header in each request (except ACK), listing the
the option tag "timer" [3]. It MUST do so even if the UAC is not option tag "timer" [4]. It MUST do so even if the UAC is not
requesting keepalives for the call. requesting keepalives for the call.
If the UAC wishes to request keepalives for this call, it MUST A UAC MAY include a Session-Expires in an initial INVITE request if
include a Session-Expires in the INVITE request used to initiate the it wishes for a session timer to be applied. The value of this header
call. The value of this header indicates the time when the UAC will indicates session interval desired by the UAC. In an INVITE that is
consider the call expired if no refresh is sent. If the request is within a call leg with an active session timer, the header SHOULD be
being authenticated, the Session-Expires header MUST appear before present, and SHOULD contain the current value of the session
the Authorization or Proxy-Authorization headers. The UAC MAY include interval.
the refresher parameter with value "uac" if it wishes to perform the
refreshes. 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
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" The UAC MAY include a Require in the request with the value "timer"
to indicate that the UAS must support the session timer to to indicate that the UAS must support the session timer to
participate in the session. In addition, the UAC MAY include a 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 Proxy-Require header in the request with the value "timer" to
indicate that proxies must support session timer in order to indicate that proxies must support session timer in order to
correctly process the request. However, usage of either Require or correctly process the request. However, usage of either Require or
Proxy-Require by the UAC is NOT RECOMMENDED. They are not needed, Proxy-Require by the UAC is NOT RECOMMENDED. They are not needed,
since the extension works even when only the UAC supports the since the extension works even when only the UAC supports the
extension. The Supported header containing "timer" MUST still be extension. The Supported header containing "timer" MUST still be
included even if the Require or Proxy-Require headers are present included even if the Require or Proxy-Require headers are present
containing "timer". containing "timer".
When a 2xx response to the initial INVITE request arrives, it may or The UAC MUST insert the Min-SE header into an re-INVITE request for a
may not contain a Require header with the value "timer". If it does, particular call leg if it has ever received a 422 response to a
the UAC MUST look for the Session-Expires header to process the previous INVITE on the same leg, or if it has received an INVITE on
response. 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
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", If there was a Require header in the response with the value "timer",
the Session-Expires header will always be present. UACs MUST be the Session-Expires header will always be present. UACs MUST be
prepared to receive a Session-Expires header in a response even if prepared to receive a Session-Expires header in a response even if
none were present in the request. The "refresher" parameter will be none were present in the request. The "refresher" parameter will be
present, indicating who will be performing the refreshes. If the present, indicating who will be performing the refreshes. If the
parameter contains the value "uac", the UAC will perform them. It is parameter contains the value "uac", the UAC will perform them. It is
possible that the UAC requested session timer (and thus included a possible that the UAC requested session timer (and thus included a
Session-Expires in the request, but there was no Require or Session- Session-Expires in the request), but there was no Require or
Expires in the 200 class response. This will happen when only the UAC Session-Expires in the 200 class response. This will happen when the
supports session timer. In this case, the UAC needs to perform UAS doesn't support session timer, and only the UAC has asked for
keepalives. To do this, the UAC follows the procedures defined in session timer (no proxies have requested it). In this case, if the
this specification as if the Session-Expires header were in the 200 UAC still wishes to use keepalives (they are purely for its benefit
class response, and its value was the same as the one in the request alone), it has to perform them. To do this, the UAC follows the
(but with a refresher parameter of "uac"). 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 UAC must refresh, it computes the expiration time of the If the 2xx response did not contain a Session-Expires header, there
session. This is based on the value of the Session-Expires in the is no session expiration. In this case, no refreshes need to be sent.
response. If the Session-Expires contains an absolute time, that is A 2xx without a Session-Expires can come for both initial and mid-
the time of expiration. If it contains a delta-time, the expiration call INVITE requests.
time is the time of reception of the response plus that delta time.
Let the difference in time between the reception of the response and
the session expiration time be called the refresh interval. Note that
this expiration applies only to the call leg associated with the
response. It is explicitly allowed for there to be differing session
timers (or none at all) on differing call legs, in the case where
there are multiple 2xx OK responses to an initial INVITE with
different tags in the To field.
If UA wishes to continue with the session beyond the expiration, it The UAC remembers the session interval for a call leg as the value of
MUST generate a refresh before the expiration time. It is RECOMMENDED the delta-time from the Session-Expires header in the most recent 2xx
that this refresh be sent once half the refresh interval has elapsed. response to INVITE on that call leg. It is explicitly allowed for
The procedures for performing this refresh are described in Section there to be differing session intervals (or none at all) on differing
8. 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 response to the initial INVITE request is a 422 Session Timer If the UAC must refresh a leg, it computes the session expiration for
Too Small response message then the UAC MAY retry the INVITE with a that leg. The session expiration is the time of reception of the last
longer session timer value in the Session-Expires header. The UAC 2xx INVITE response on that leg plus the session interval for that
MUST use a value that is bigger than any value returned in a leg. If UA wishes to continue with the session beyond the session
Session-Expires header in any 422 response within the call leg. This expiration, it MUST generate a refresh before the session expiration.
requires the UA to store the largest session timer duration returned It is RECOMMENDED that this refresh be sent once half the session
in any 422 for the duration of the call leg. This behavior is needed interval has elapsed. Additional procedures for this refresh are
to prevent certain denial of service attacks, described in Section 9. described in Section 10.
6 Proxy Behavior 7.3 Processing a 422 Response
Session expirations are mostly of interest to call stateful proxy If the response to an INVITE request is a 422 Session Timer Too Small
servers. However, a stateful proxy server MAY also follow the rules response message, then the UAC MAY retry the INVITE. The procedures
described here. Stateless proxies MUST NOT attempt to request session for retrying are described in Section 7.1.
timers. Proxies which ask for session timers SHOULD record-route,
since they won't receive refreshes if they don't. 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 The proxy processing rules require the proxy to remember
information between the request and response, ruling out information between the request and response, ruling out
stateless proxies. stateless proxies.
6.1 Processing of requests 8.1 Processing of requests
Due to local policy, a proxy may have guidelines about the desired Processing of requests is identical for INVITE and re-INVITE
maximum lifetime for a call initiated through it. When an initial requests.
INVITE is received to establish a call, a proxy MAY insert a
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 Session-Expires header in the request before forwarding it, if none
was present in the request. This Session-Expires header may contain was present in the request. This Session-Expires header may contain
any desired expiration time the proxy would like, but not with a 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 duration lower than the value in the Min-SE header in the request, if
present. present. The proxy MUST NOT insert a refresher parameter with value
uac. It MAY insert one with value "uas", but this is redundant since
the UAS will conclude that it needs to refresh in any case.
If the request already had a Session-Expires header, the proxy MAY 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 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 to a duration lower than the value in the Min-SE header in the
request, if present. The proxy MUST NOT increase the value of the request, if present. If the value of the Session-Expires header is
duration. 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.
The proxy MAY reject the INVITE request if the requested session If the request contains a Supported header with a value "timer", the
timer value in the Session-Expires header is smaller than the minimum proxy MAY reject the INVITE request if the session interval in the
value defined in the proxies local policy. The proxy does so by Session-Expires header is smaller than the minimum timer defined in
sending a 422 Session Timer Too Small response message. When sending the proxies local policy. The proxy does so by sending a 422 Session
the 422 response message, the proxy MUST include a Session-Expires Timer Too Small response message. When sending the 422 response
header with a value for the session timer that is acceptable to the message, the proxy MUST include a Min-SE header with the value of its
proxy. minimum timer.
Assuming the proxy wishes to use session timer (and thus has possibly 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 has requested session timer (and thus has possibly
inserted the Session-Expires header or reduced it), the proxy MUST inserted the Session-Expires header or reduced it), the proxy MUST
remember that it is using session timer, and also remember the value remember that it is using session timer, and also remember the value
of the Session-Expires header it placed in the proxied request. This of the Session-Expires header from the proxied request. This MUST be
MUST be remembered for the duration of the transaction. The proxy remembered for the duration of the transaction. The proxy MUST
MUST remember, for the duration of the transaction, whether the remember, for the duration of the transaction, whether the request
request contained the Supported header with the value "timer". contained the Supported header with the value "timer".
If the request did not contain a Supported header with the value If the request did not contain a Supported header with the value
"timer", the proxy MAY insert a Require header into the request, with "timer", the proxy MAY insert a Require header into the request, with
the value "timer". However, this is NOT RECOMMENDED. This allows the the value "timer". However, this is NOT RECOMMENDED. This allows the
proxy to insist on session timer for the session. This header is not 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 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 proxy can already be sure that the session timer can be used for the
session. session.
6.2 Processing of Responses 8.2 Processing of Responses
When the final response to the request arrives, it is examined by the When the final response to the request arrives, it is examined by the
proxy. There are four cases. proxy.
CASE I: UAC supports, UAS doesn't. In this case, the request
forwarded by the proxy contained a Session-Expires header
(possibly inserted by the proxy). Recall that all proxies
interested in session timer MUST remember the value of the
timer in the forwarded request, in addition to whether the
UAC supports it. Handling of the response for this scenario
depends on whether the session timer aware proxy is the one
closest to the UAS, amongst all proxies which requested
session timer.
When the UAS sends the response, it will not contain a
Session-Expires or Require header. This response is
forwarded upstream, and it will eventually arrive at a
proxy which was interested in session timers. 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. The value of the
Session-Expires in the forwarded response represents the
expiration time of the session. For other proxies, the
response will already contain the Session-Expires and
Require header, so that this case is indistinguishable from
CASE IV.
CASE II: UAC doesn't support, UAS doesn't support. In this case, If the response does not contain a Session-Expires header, but the
the final response has no Session-Expires header, and the proxy remembers that it requested a session timer in the request (by
proxy remembers that the UAC did not support the session inserting, modifying, or examining and accepting the Session-Expires
timer. The proxy forwards the response upstream normally. in the proxied INVITE), this means that the UAS did not support the
There are no session timers for this call leg. 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.
CASE III: UAS supports, UAC doesn't. In this case, the final Because there is no Session-Expires or Require in the response, the
response contains a Session-Expires header with the proxy knows it is the first session-timer-aware proxy to receive the
refresher parameter set to "uas". The proxy forwards the response. This proxy MUST insert a Session-Expires header into the
response upstream. 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.
CASE IV: UAC supports, UAS supports. In this case, the final If the response received contains a Session-Expires header, no
response contains a Session-Expires header. The refresher additional response processing is needed. The response is processed
parameter indicates who is performing the refreshes. This normally.
case will also occur when the UAC supports session timer,
and the UAS doesn't, but a downstream proxy had recognized
this as CASE I and inserted the Session-Expires and Require
headers into the response. The proxy forwards the response
upstream.
In all cases, if the final response forwarded upstream by the proxy In all cases, if the final response forwarded upstream by the proxy
contains a Session-Expires header, its value represents the contains a Session-Expires header, its value represents the session
expiration time of the session for the call leg associated with that interval for the call leg associated with that response. The proxy
response. There can be multiple 200 class responses to a single computes the session expiration as the time when the 2xx response is
INVITE, each representing a different call leg, resulting in multiple forwarded upstream, plus the session interval. This session
session timers, one for each call leg. 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- In all cases, the proxy MUST NOT modify the value of the Session-
Expires header received in the response (assuming one was present) Expires header received in the response (assuming one was present)
before forwarding it upstream. before forwarding it upstream.
The expiration of the call leg will occur at the time indicated in 8.3 Session Expiration
the Session-Expires header. If the Session-Expires header contains a
delta-time, the expiration time is the time of receipt of the final
response, plus that delta time.
Re-INVITE requests may arrive from either UA, refreshing the session
and extending the expiration time. Processing of these re-INVITEs by
a proxy is identical to the procedure for processing the initial
INVITE.
If the session expires without having seen a response to a re-INVITE, When the current time equals or passes the session expiration for a
the proxy MAY consider the call leg terminated. This means it MAY call leg, the proxy MAY remove associated call state, and MAY free
flush any state associated with that call leg. any resources associated with the call. Unlike the UA, it MUST NOT
send a BYE.
Note that a proxy MUST NOT send a BYE request once the session 9 UAS Behavior
expires.
7 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.
When a UAS receives an INVITE for a new call, and that INVITE Once the request is received by the virtual UAS (assuming it is
contains a Session-Expires header, the UAS MUST place a Session- received; it may have been rejected with a 422 based on the rules in
Expires header in a 200 class response (assuming the UAS accepts the Section 8.1), virtual UAS processing begins. If the virtual UAS
call). The UAS MAY reduce the expiration time when it places this wishes to accept the call, it copies the value of the Session-Timer
header into the response, but MUST NOT set it to a duration lower from the request received from the first step into the 2xx response.
than the value in the Min-SE header in the request, if present. The
UAS MUST NOT increase the value of the duration.
The UAS MAY reject the INVITE request if the requested session timer The virtual UAS MUST then set the value of the refresher parameter in
value in the Session-Expires header is smaller than the minimum value the Session-Expires header present in a 200 class response. This
defined in UAS local policy. The UAS does so by sending a 422 Session value specifies who will perform refreshes for the call leg. The
Timer Too Small response message. When sending the 422 response value is set based on the value of this parameter in the request and
message, the UAS MUST include a Session-Expires header with a value on whether the UAC supports session timer. Table 3 defines how the
that is acceptable to it. 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.
If the inital INVITE did not contain a Session-Expires header, and In the fourth row of Table 3, since the UAC supports the session
the UAS wishes to use refreshes for the session, it MUST insert a timer, and so does the UAS, the UAS can elect for itself or the UAC
Session-Expires header into the response. This header MAY have any to perform the refreshes.
desired expiration time greater than the value in the Min-SE header
from the request, if present.
The UAS MUST set the value of the refresher parameter in the Note that the results of the above table are that the UACs choice of
Session-Expires header present in a 200 class response. This value refresher cannot be changed by the virtual UAS.
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 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 its disallowed by the protocol.
UAC supports? refresher parameter refresher parameter UAC supports? refresher parameter refresher parameter
in request in response in request in response
N none uas N none uas
N uac NA N uac NA
N uas NA N uas uas
Y none uas or uac Y none uas or uac
Y uac uac Y uac uac
Y uas uas Y uas uas
Table 3: UAS Behavior Table 3: UAS Behavior
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.
If the refresher parameter in the Session-Expires header in the 200 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 class response has a value of "uac", the UAS MUST place a Require
header into the response with the value "timer". header into the response with the value "timer". This is because the
uac is performing refreshes and the response has to be processed for
If the UAS is generating refreshes, it computes the expiration time the UAC to know this. If the refresher parameter in the 200 class
of the session based on the value of the Session-Expires header in response has a value of "uas", and the Supported header in the
the response it sent. If the Session-Expires contains an absolute request contained the value "timer", the UAS SHOULD place a Require
time, that is the time of expiration. If it contains a delta-time, header into the response with the value "timer". In this case, the
the expiration time is the time of transmission of the response plus UAC is not refreshing, but it is supposed to send a BYE if it never
that delta time. Let the difference in time between the transmission receives a refresh. Since the call will still succeed without the UAC
of the response and the session expiration time be called the refresh doing this, insertion of the Require is a SHOULD here, rather than a
interval. Note that this expiration applies only to the call leg MUST.
associated with the response.
If the UA wishes to continue with the session beyond the expiration,
it MUST generate a refresh before the expiration time. It is
RECOMMENDED that this refresh be sent once half the refresh interval
has elapsed. The procedures for performing this refresh are described
in Section 8.
8 Performing Refreshes
The refresh is accomplished by sending a re-INVITE request on the
given call leg. Sending of the refresh (in terms of this extension),
and processing the response are exactly identical to the rules in
Sections 5 and 7. However, as discussed in Section 4, if the UAC
received any 422 responses for this call leg, the re-INVITE MUST
contain a Min-SE header with the largest of all durations returned in
all 422 responses on that call leg. The re-INVITE SHOULD contain a
Session-Expires header, with an duration equal to the last duration.
For example, if the initial INVITE sequence results in a session
timer of 200 seconds, the re-INVITE SHOULD contain a session timer
with a value of 200 seconds. The re-INVITE MAY contain a different
expiration, but this should only be done if the UA wishes to change
the session expiration.
If the Session-Timer is placed in the re-INVITE, the refresher The UAS remembers the session interval for a call leg as the value of
parameter SHOULD be present, and SHOULD identify the element the delta-time from the Session-Expires header in the most recent 2xx
currently responsible for refreshes. This means that a re-INVITE may response to INVITE on that call leg. It also remembers whether it, or
have a refresher parameter with value "uas", if the element not its peer, is the refresher on the leg.
performing refreshes sends a re-INVITE for some other, non-session-
timer reason. The refresher parameter MAY be set to identify the
element not performing refreshes at this time. This will result in a
change of roles.
If the 200 OK to the re-INVITE has no Session-Expires, no expiration If the UAS must refresh a leg, it computes the session expiration for
time exists for the session. This can happen if the proxies and/or that leg. The session expiration is the time of transmission of the
UAS change their mind about session timers, and decide they no longer last 2xx INVITE response on that leg plus the session interval for
wish to use them. Since each INVITE is treated independently, the that leg. If UA wishes to continue with the session beyond the
proxies or UAS do not need to continue requesting session timer even session expiration, it MUST generate a refresh before the session
though they did so the first time. 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.
A UA MAY use the refreshing re-INVITE as a normal SIP re-INVITE; that 10 Performing Refreshes
is, this re-INVITE MAY contain an updated session description. In the
case where the re-INVITE contains an updated session description, the
session description MUST somehow indicate that it has changed. In the
case of SDP [4], this is accomplished by using a different value for
the origin field.
If the refreshing re-INVITE is used solely for refreshing, it SHOULD The side generating a refresh does so according to the UAC procedures
still contain a session description, unchanged from the previous defined in Section 7.
INVITE. 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 changed. This is accomplished in the
same way as for the request.
If no response to a refreshing re-INVITE is received before the If no response to a refreshing re-INVITE is received before the
expiration of the session, the UA SHOULD send a BYE request to session expiration, the UA SHOULD send a BYE request to terminate the
terminate the call. It SHOULD send this BYE slightly before call. It SHOULD send this BYE slightly before session expiration. The
expiration of the session. The minimum of ten seconds and one third minimum of ten seconds and one third the session interval is
the session interval is RECOMMENDED. RECOMMENDED.
For example, if the session interval is 120 seconds, one For example, if the session interval is 120 seconds, one
third of this is 40 seconds. Since the minimum of 10 third of this is 40 seconds. Since the minimum of 10
seconds and 40 seconds is 10 seconds, the BYE would be sent seconds and 40 seconds is 10 seconds, the BYE would be sent
10 seconds before the session expires. 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 Firewalls and NATs may be very unforgiving about allowing
SIP traffic to pass after the expiration time of the SIP traffic to pass after the expiration time of the
session. It is for this reason that the BYE should be sent session. It is for this reason that the BYE should be sent
before the expiration. before the expiration.
It is possible that the calling UA is generating refreshes, and then 11 Security Considerations
it receives a re-INVITE. After following the rules for UAS described
above, the calling UA now determines it is not supposed to generate
refreshes. The UA SHOULD cease generating refreshes in this case, and
let the other UA perform them. This also implies that the
responsibility for generating refreshes may change during a call.
This happens commonly in one specific case - both caller and callee
support session timer. The caller will be doing re-INVITEs initially.
If the callee re-INVITEs, it becomes the UAC for this transaction,
and the rules defined in this specification may result in a change in
refresh responsibility to the called party. In general, when both
parties support session timer, refreshes become the responsibility of
the party which performed the last INVITE transaction.
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.
Without From tags, A could INVITE B without a From tag. B The session timer introduces the capability of a proxy or UA element
inserts a tag in the 200 OK. Now, B sends a re-INVITE to A. to force compliant clients to send refreshes at a rate of the
Meantime, A has crashed and rebooted. This re-INVITE has a element's choosing. This introduces the possibility of rogue proxies
From tag, but no To tag. It therefore cannot be or UASes introducing denial-of-service attacks. However, the
distinguished for a new INVITE in which the UAC inserts a mechanisms in this specification prevent that from happening.
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 First, consider the case of a rogue UAC that wishes to force a UAS to
stale re-INVITEs has been added to the updated version of generate refreshes at a rapid rate. To do so, it inserts a Session-
RFC2543. However, to eliminate a dependency between this Expires header into an INVITE with a low duration and a refresher
spec and the new version of SIP, these two features are parameter equal to uas. Assume it places a Supported header into the
specified here as well. 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.
9 Security Considerations 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
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.
The session timer introduces the capability of a proxy to effectively In a similar fashion, a rogue proxy cannot force either the UAC or
force clients to send refreshes at a rate of the proxies choosing. It UAS to generate refreshes unless the proxy remains on the signaling
can also force the clients to send a BYE by setting the expirations path, and sees every request and response.
to times that are too short. This introduces the possibility of rogue
proxies or UASes introducing denial-of-service attacks. Use of short
refresh intervals allows the proxies or UAS to create network load.
This is preventable using the 422 response and Min-SE header
mechanism. Any proxy or the UAS can reject an INVITE with a low
session timer, and the UAC will then include this minimum in the
Min-SE header in subsequent requests. No compliant proxy will then
use a session timer with a lower value. Rogue proxies could strip the
Min-SE, but in this case, UA configuration should ideall prevent the
attacks by refusing to use a session timer lower than a specific
value (30 minutes is recommended here).
It is also RECOMMENDED that IP or transport level security is used It is also RECOMMENDED that IP or transport level security is used
when communicating between proxies, and that requests with Session- when communicating between proxies, and that requests with Session-
Expires headers only be accepted over these secure transports. Expires headers only be accepted over these secure transports.
10 Examples 12 Examples
The following examples are meant to illustrate the functionality The following examples are meant to illustrate the functionality
associated with the session timer. In the interest of brevity, all associated with the session timer. In the interest of brevity, all
headers excepting Supported, Session-Expires, Min-SE and Require are headers except Supported, Session-Expires, Min-SE and Require are
intentionally left out of the SIP messages. intentionally left out of the SIP messages.
10.1 Basic session timer 12.1 Basic session timer
In this case, two UAs communicate directly, with no proxies. Both In this case, two UAs communicate directly, with no proxies. Both
support the session timer. The call is setup with a two minute support the session timer. The call is setup with a two minute
session expiration. One minute later, the UAC refreshes the session. session expiration. One minute later, the UAC refreshes the session.
Calling UA -> Called UA Calling UA -> Called UA
INVITE INVITE
Supported: timer Supported: timer
Session-Expires: 120 Session-Expires: 3600
Calling UA <- Called UA Calling UA <- Called UA
200 OK 200 OK
Require: timer Require: timer
Session-Expires: 120;refresher=uac Called UA starts timer on send Session-Expires: 3600;refresher=uac Called UA starts timer on send
Calling UA starts timer on receipt Calling UA starts timer on receipt
Calling UA -> Called UA Calling UA -> Called UA
ACK ACK
60 seconds later: 60 seconds later:
Calling UA -> Called UA Calling UA -> Called UA
INVITE INVITE
Supported: timer Supported: timer
Session-Expires: 120;refresher=uac Session-Expires: 3600;refresher=uac
Calling UA <- Called UA Calling UA <- Called UA
200 OK 200 OK
Require: timer Require: timer
Session-Expires: 120;refresher=uac Called UA starts timer on send Session-Expires: 3600;refresher=uac Called UA starts timer on send
Calling UA starts timer on receipt Calling UA starts timer on receipt
Calling UA -> Called UA Calling UA -> Called UA
ACK ACK
110 seconds later the called UA did not receive a re-INVITE. It 3550 seconds later the called UA did not receive a re-INVITE. It
therefore considers the call terminated and sends a BYE: therefore considers the call terminated and sends a BYE:
Calling UA <- Called UA Calling UA <- Called UA
BYE BYE
Calling UA -> Called UA Calling UA -> Called UA
200 OK 200 OK
10.2 Basic negotiation of Session Time 12.2 Basic negotiation of Session Time
In this configuration, two UAs talk through a single proxy server. In this configuration, two UAs talk through a single proxy server.
Both the proxy and the UAS reduce the session timer. Both the proxy and the UAS reduce the session timer.
Calling UA -> proxy Calling UA -> proxy
INVITE INVITE
Supported: timer Supported: timer
Session-Expires: 240 Session-Expires: 3600
proxy -> Called UA proxy -> Called UA
INVITE proxy wants a shorter timer INVITE proxy wants a shorter timer
Supported: timer Supported: timer
Session-Expires: 180 Session-Expires: 180
proxy <- Called UA proxy <- Called UA
200 OK Called UA wants a shorter timer 200 OK Called UA wants a shorter timer
Session-Expires: 120;refresher=uac Called UA starts timer Session-Expires: 120;refresher=uac Called UA starts timer
Require: timer Require: timer
skipping to change at page 18, line 4 skipping to change at page 19, line 17
ACK ACK
For whatever reason, the calling UA decides not to refresh. So, after For whatever reason, the calling UA decides not to refresh. So, after
110 seconds, it sends a BYE. 110 seconds, it sends a BYE.
Calling UA -> proxy Calling UA -> proxy
BYE BYE
proxy -> Called UA proxy -> Called UA
BYE BYE
proxy <- Called UA proxy <- Called UA
200 OK 200 OK
Calling UA <- proxy Calling UA <- proxy
200 OK 200 OK
10.3 No Session-Expires Header in INVITE 12.3 No Session-Expires Header in INVITE
In this scenario, the UA sends an INVITE without a Session-Expires In this scenario, the UA sends an INVITE without a Session-Expires
header and with a Supported header containing the option tag "timer". header and with a Supported header containing the option tag "timer".
Since the proxy wants session timer for the call, it adds the Since the proxy wants session timer for the call, it adds the
Session-Expires header. Session-Expires header.
Calling UA -> proxy Calling UA -> proxy
INVITE No Session-Expires INVITE No Session-Expires
Supported: timer Supported: timer
proxy -> Called UA proxy -> Called UA
INVITE INVITE
Supported: timer Supported: timer
Session-Expires: 120 Proxy added Session-Expires Session-Expires: 3600 Proxy added Session-Expires
proxy <- Called UA proxy <- Called UA
200 OK 200 OK
Session-Expires: 120;refresher=uac Called UA starts timer on send Session-Expires: 3600;refresher=uac Called UA starts timer on send
Require: timer Require: timer
Calling UA <- proxy Calling UA <- proxy
200 OK 200 OK
Session-Expires: 120;refresher=uac Proxy starts timer on send Session-Expires: 3600;refresher=uac Proxy starts timer on send
Require: timer Calling UA starts timer on receipt Require: timer Calling UA starts timer on receipt
Calling UA -> proxy Calling UA -> proxy
ACK ACK
proxy -> Called UA proxy -> Called UA
ACK ACK
10.4 Session timer without Calling UA Support 12.4 Session timer without Calling UA Support
In this scenario, the calling UA sends and INVITE without a Session- In this scenario, the calling UA sends and INVITE without a Session-
Expires header and without a Supported header containing the option Expires header and without a Supported header containing the option
tag "timer". Since the proxy wants session timer for the call it adds tag "timer". Since the proxy wants session timer for the call it adds
Session-Expires header before proxying the INVITE to the called UA. Session-Expires header before proxying the INVITE to the called UA.
Calling UA -> proxy Calling UA -> proxy
INVITE INVITE
proxy -> Called UA proxy -> Called UA
INVITE Proxy adds session expires INVITE Proxy adds session expires
Session-Expires: 180 Session-Expires: 3600
proxy <- Called UA proxy <- Called UA
200 OK Called UA wants a shorter timer 200 OK Called UA wants a shorter timer
Session-Expires: 120;refresher=uas Called UA starts timer on send Session-Expires: 120;refresher=uas Called UA starts timer on send
Calling UA <- proxy Calling UA <- proxy
200 OK 200 OK
Session-Expires: 120;refresher=uas Proxy starts timer on send Session-Expires: 120;refresher=uas Proxy starts timer on send
Called UA starts timer on receipt Called UA starts timer on receipt
skipping to change at page 20, line 28 skipping to change at page 21, line 42
proxy -> Called UA proxy -> Called UA
BYE BYE
proxy <- Called UA proxy <- Called UA
200 OK 200 OK
Calling UA <- proxy Calling UA <- proxy
200 OK 200 OK
10.5 Session Timer without Called UA Support 12.5 Session Timer without Called UA Support
In this scenario, the calling UA indicates that it supports the In this scenario, the calling UA indicates that it supports the
session timer, but does not add the Session-Expires header into 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 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 UAS. The call is still set up with a session timer, as all that is
required is for one of the user agents involved in the call leg to required is for one of the user agents involved in the call leg to
understand the "timer" feature. understand the "timer" feature.
Calling UA -> proxy Calling UA -> proxy
INVITE INVITE
k: timer k: timer
proxy -> Called UA proxy -> Called UA
INVITE proxy adds S-E header INVITE proxy adds S-E header
k: timer k: timer
Session-Expires: 180 Session-Expires: 3600
proxy <- Called UA proxy <- Called UA
200 OK Called UA doesn't understand session timer 200 OK Called UA doesn't understand session timer
Calling UA <- proxy Calling UA <- proxy
200 OK 200 OK
Session-Expires: 180;refresher=uac Proxy adds S-E and Require Session-Expires: 3600;refresher=uac Proxy adds S-E and Require
Require: timer Proxy starts timer on send Require: timer Proxy starts timer on send
Calling UA starts timer on receipt Calling UA starts timer on receipt
Calling UA -> proxy Calling UA -> proxy
ACK ACK
proxy -> Called UA proxy -> Called UA
ACK ACK
The UAC then re-invites, which is responded to with a 400 because the 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 new media streams were rejected. Since this is a re-INVITE, the
session is still active. session is still active.
Calling UA -> proxy Calling UA -> proxy
INVITE INVITE
k: timer k: timer
Session-Expires: 180;refresher=uac UA asks for timer this time Session-Expires: 3600;refresher=uac UA asks for timer this time
This is not mandatory This is not mandatory
proxy -> Called UA proxy -> Called UA
INVITE proxy does not reduce Session-Expires header INVITE proxy does not reduce Session-Expires header
k: timer k: timer
Session-Expires: 180;refresher=uac Session-Expires: 3600;refresher=uac
proxy <- Called UA proxy <- Called UA
400 Rejected Media Called UA doesn't understand session timer 400 Rejected Media Called UA doesn't understand session timer
Calling UA <- proxy Calling UA <- proxy
400 Rejected Media 400 Rejected Media
Calling UA -> proxy Calling UA -> proxy
ACK ACK
proxy -> Called UA proxy -> Called UA
ACK ACK
10.6 Proxy insists on session timer 12.6 Neither UA Supports Session Timer
In this scenario, the calling UA does not support the session timer,
but the proxy on the setup path insists on it by inserting a Require
header. The UAS does not support the session timer either, so it
rejects the request with a 420 as per standard RFC2543 extension
handling. This response is forwarded upstream towards the UAC. The
UAC treats it as a normal 400 class response, and then ACKs it. In
this case, the call cannot be established.
It is slightly odd that a UAC will send a request without a
Require header, and yet get a 420 response back with an
Unsupported header. Normal UAs that don't support session
timer should handle this case correctly, treating it just
as a normal 400 class response.
Note that proxy insertion of Require is NOT RECOMMENDED.
Calling UA -> proxy
INVITE
proxy -> Called UA
INVITE proxy adds session expires
Require: timer proxy adds Require
Session-Expires: 180
proxy <- Called UA
420 Bad Extension
Unsupported: timer
Calling UA <- proxy
420 Bad Extension
Unsupported: timer
Calling UA -> proxy
ACK
proxy -> Called UA
ACK
10.7 Neither UA Supports Session Timer
In this case, neither UA supports the session timer. However, one of In this case, neither UA supports the session timer. However, one of
the proxies on the call setup path requests (but does not require) the proxies on the call setup path requests (but does not require)
it. The call completes without session timers. it. The call completes without session timers.
Calling UA -> proxy Calling UA -> proxy
INVITE INVITE
proxy -> Called UA proxy -> Called UA
INVITE proxy adds S-E header compact form INVITE proxy adds S-E header compact form
x: 180 x: 3600
proxy <- Called UA proxy <- Called UA
200 OK Called UA doesn't understand session timer 200 OK Called UA doesn't understand session timer
Calling UA <- proxy proxy doesn't add S-E since it knows Calling UA Calling UA <- proxy proxy doesn't add S-E since it knows Calling UA
200 OK doesn't support it 200 OK doesn't support it
Calling UA -> proxy Calling UA -> proxy
ACK ACK
proxy -> Called UA proxy -> Called UA
ACK ACK
10.8 Both UAs Support, Change in Roles 12.7 Both UAs Support, Change in Roles
In this case, both user agents support session timer. The initial In this case, both user agents support session timer. The initial
INVITE from caller to callee results in refreshes being generated by INVITE from caller to callee results in refreshes being generated by
the caller. A re-INVITE sent from the callee changes that role so the caller. A re-INVITE sent from the callee changes that role so
that the callee refreshes. that the callee refreshes.
Calling UA -> proxy Calling UA -> proxy
INVITE INVITE
Supported: timer Supported: timer
Session-Expires: 240 Session-Expires: 3600
proxy -> Called UA proxy -> Called UA
INVITE Proxy wants timer, no change in value INVITE Proxy wants timer, no change in value
Supported: timer Supported: timer
Session-Expires: 240 Session-Expires: 3600
proxy <- Called UA proxy <- Called UA
200 OK Called UA supports timer 200 OK Called UA supports timer
Session-Expires: 240;refresher=uac Inserts Require, Session-Expires Session-Expires: 3600;refresher=uac Inserts Require, Session-Expires
Require: timer Called UA starts timer on send Require: timer Called UA starts timer on send
Calling UA <- proxy Calling UA sees refresher=uac Calling UA <- proxy Calling UA sees refresher=uac
200 OK It is refreshing 200 OK It is refreshing
Session-Expires: 240;refresher=uac Proxy starts timer on send Session-Expires: 3600;refresher=uac Proxy starts timer on send
Require: timer Calling UA starts timer on receipt Require: timer Calling UA starts timer on receipt
Calling UA -> proxy Calling UA -> proxy
ACK ACK
proxy -> Called UA proxy -> Called UA
ACK ACK
The called UA (which is a UAC for this transaction) now sends a re- 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 INVITE. For whatever reason, it decides to switch roles by explicitly
designating the itself as the refresher. designating the itself as the refresher.
proxy <- Called UA proxy <- Called UA
INVITE INVITE
Supported: timer Supported: timer
Session-Expires: 240;refresher=uac Session-Expires: 3600;refresher=uac
Calling UA <- proxy Calling UA <- proxy
INVITE proxy wants timer, no change in value INVITE proxy wants timer, no change in value
Supported: timer Supported: timer
Session-Expires: 240;refresher=uac Session-Expires: 3600;refresher=uac
Calling UA -> proxy Calling UA -> proxy
200 OK Calling UA supports timer 200 OK Calling UA supports timer
Session-Expires: 240;refresher=uac Inserts Session-Expires Session-Expires: 3600;refresher=uac Inserts Session-Expires
Require: timer Calling UA updates timer on send Require: timer Calling UA updates timer on send
proxy -> Called UA Called UA sees 200 w/refresher=uac proxy -> Called UA Called UA sees 200 w/refresher=uac
200 OK It is refreshing 200 OK It is refreshing
Session-Expires: 240;refresher=uac Proxy updates timer on send Session-Expires: 3600;refresher=uac Proxy updates timer on send
Require: timer Called UA updates timer on receipt Require: timer Called UA updates timer on receipt
proxy <- Called UA proxy <- Called UA
ACK ACK
Calling UA <- proxy Calling UA <- proxy
ACK ACK
10.9 Proxy Rejects Timer 12.8 Proxy Rejects Timer
In this call flow, the calling UA sends an INVITE with a Session- 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 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 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 timer. The calling UA retries with a new Session-Expires and with a
Min-SE header. Min-SE header.
Calling UA -> Proxy Calling UA -> Proxy
INVITE INVITE
Supported: timer Supported: timer
skipping to change at page 25, line 40 skipping to change at page 26, line 11
Proxy -> Called UA Proxy -> Called UA
INVITE INVITE
Supported: timer Supported: timer
Session-Expires: 250 Proxy lowers to 250 Session-Expires: 250 Proxy lowers to 250
Min-SE: 200 Min-SE: 200
Proxy <- Called UA Proxy <- Called UA
200 200
Require: timer Require: timer
Session-Expires: 250;refresher=uac UAS lowers to 200 Session-Expires: 200;refresher=uac UAS lowers to 200
Calling UA <- Proxy Calling UA <- Proxy
200 200
Require: timer Require: timer
Session-Expires: 250;refresher=uac Session-Expires: 200;refresher=uac
Calling UA -> Proxy Calling UA -> Proxy
ACK ACK
Proxy -> Called UA Proxy -> Called UA
ACK ACK
11 Acknowledgements 13 Acknowledgements
The authors wish to thank Brett Tate for his contributions to this The authors wish to thank Brett Tate for his contributions to this
work. work.
12 Changes since -04 14 Changes since -05
o Added a section explicitly defining the 422 response code.
o Clarified UAC behavior for 422, distinguishing between calls
and call legs.
o Merged normative text in Section 2 with the rest of the
document. Section 2 is now purely tutorial, at a higher level.
o Clarified that the recommended minimum value for Session-
Expires is 30 minutes. The previous text just talked about the
"interval", without a formal definition of what interval might
mean.
o Min-SE now used in 422 response, instead of Session-Expires,
based on agreement at IETF 51.
o Clarified that Require in a request does not mean that the UAS
is being required to perform refreshes, just that its required
to support the extension.
o Updated row three of Table 3 to indicate a value of "uas"
since this case is actually possible. Updated the related text
in the section on proxy behavior to describe the scenario.
o Based on IETF 51 discussions, removed absolute time. Everyting
is now in delta-seconds.
o Removed example flow that uses Require header. No reason to
list flows that are not recommended.
o Updated examples to use recommended values for parameters.
o Added terminology section, reworked text to use consistent
terms based on that section.
o Modeled the behavior of a UAS as the concatenation of a proxy
and virtual UAS, so that a UAS could perform the same session
timer manipulations as a proxy without respecification of the
rules for such processing.
o Generalization of the request processing behaviors to work for
both INVITE and re-INVITE, which allowed for the removal of
the secion on performing refreshes.
o Allow proxies to insert or increase Min-SE (and possibly
increase Session-Timer as a result) in order to handle the
case when the UAC doesn't support session timer, and a proxy
receives a request with a value that is too small.
o Min-SE header in initial INVITE is the maximum of the values
returned in 422, AND also received in any INVITE. Previously,
it was just 422. This change is needed because of the previous
item.
o Improvied Security Considerations section to explicitly
consider several DoS cases.
15 Changes since -04
o Added requirement for From tags with session timer, to handle o Added requirement for From tags with session timer, to handle
this crash and reboot case. Discussed when a UA would want to this crash and reboot case. Discussed when a UA would want to
recover calls this way. recover calls this way.
o Removed text about inserting Session-Expires:0 when you want o Removed text about inserting Session-Expires:0 when you want
to indicate that the call is down. Rather, send a 481. to indicate that the call is down. Rather, send a 481.
o Made handling of a 481 a MUST for UAC. o Made handling of a 481 a MUST for UAC.
skipping to change at page 27, line 5 skipping to change at page 28, line 34
glare. glare.
o Added discussion of why minimum of 30 minutes is a SHOULD and o Added discussion of why minimum of 30 minutes is a SHOULD and
not a MUST. not a MUST.
o Added Min-SE header and related processing. o Added Min-SE header and related processing.
o Added refresher parameter to Session-Expires, which has o Added refresher parameter to Session-Expires, which has
simplified processing. simplified processing.
13 Author's Addresses 16 Author's Addresses
Steven R. Donovan Steven R. Donovan
dynamicsoft dynamicsoft
5100 Tennyson Parkway 5100 Tennyson Parkway
Suite 1200 Suite 1200
Plano, Texas 75024 Plano, Texas 75024
email: sdonovan@dynamicsoft.com email: sdonovan@dynamicsoft.com
Jonathan Rosenberg Jonathan Rosenberg
dynamicsoft dynamicsoft
72 Eagle Rock Avenue 72 Eagle Rock Avenue
First Floor First Floor
East Hanover, NJ 07936 East Hanover, NJ 07936
email: jdrosen@dynamicsoft.com email: jdrosen@dynamicsoft.com
14 Bibliography 17 Bibliography
[1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: [1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
session initiation protocol," Request for Comments 2543, Internet session initiation protocol," Request for Comments 2543, Internet
Engineering Task Force, Mar. 1999. Engineering Task Force, Mar. 1999.
[2] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: a [2] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: a
transport protocol for real-time applications," Request for Comments transport protocol for real-time applications," Request for Comments
1889, Internet Engineering Task Force, Jan. 1996. 1889, Internet Engineering Task Force, Jan. 1996.
[3] J. Rosenberg and H. Schulzrinne, "The SIP supported header," [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 Internet Draft, Internet Engineering Task Force, Feb. 2001. Work in
progress. progress.
[4] M. Handley and V. Jacobson, "SDP: session description protocol,"
Request for Comments 2327, Internet Engineering Task Force, Apr.
1998.
Table of Contents Table of Contents
1 Introduction ........................................ 1 1 Introduction ........................................ 1
2 Protocol Overview ................................... 2 2 Terminology ......................................... 2
3 Session-Expires Header Field Definition ............. 4 3 Protocol Overview ................................... 3
4 Min-SE Header Field Definition ...................... 6 4 Session-Expires Header Field Definition ............. 5
5 UAC Behavior ........................................ 7 5 Min-SE Header Field Definition ...................... 6
6 Proxy Behavior ...................................... 9 6 422 Response Code Definition ........................ 7
6.1 Processing of requests .............................. 9 7 UAC Behavior ........................................ 7
6.2 Processing of Responses ............................. 10 7.1 Generating an INVITE Request ........................ 7
7 UAS Behavior ........................................ 11 7.1.1 Example ............................................. 9
8 Performing Refreshes ................................ 13 7.2 Processing a 2xx Response ........................... 10
9 Security Considerations ............................. 15 7.3 Processing a 422 Response ........................... 11
10 Examples ............................................ 16 8 Proxy Behavior ...................................... 11
10.1 Basic session timer ................................. 16 8.1 Processing of requests .............................. 11
10.2 Basic negotiation of Session Time ................... 17 8.2 Processing of Responses ............................. 13
10.3 No Session-Expires Header in INVITE ................. 18 8.3 Session Expiration .................................. 14
10.4 Session timer without Calling UA Support ............ 18 9 UAS Behavior ........................................ 14
10.5 Session Timer without Called UA Support ............. 20 10 Performing Refreshes ................................ 15
10.6 Proxy insists on session timer ...................... 22 11 Security Considerations ............................. 16
10.7 Neither UA Supports Session Timer ................... 22 12 Examples ............................................ 17
10.8 Both UAs Support, Change in Roles ................... 23 12.1 Basic session timer ................................. 17
10.9 Proxy Rejects Timer ................................. 25 12.2 Basic negotiation of Session Time ................... 18
11 Acknowledgements .................................... 26 12.3 No Session-Expires Header in INVITE ................. 19
12 Changes since -04 ................................... 26 12.4 Session timer without Calling UA Support ............ 20
13 Author's Addresses .................................. 27 12.5 Session Timer without Called UA Support ............. 21
14 Bibliography ........................................ 27 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 Changes since -05 ................................... 26
15 Changes since -04 ................................... 27
16 Author's Addresses .................................. 28
17 Bibliography ........................................ 29
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/