draft-ietf-sip-session-timer-00.txt   draft-ietf-sip-session-timer-01.txt 
Internet Engineering Task Force Steve Donovan
Internet Draft MCI Worldcom
October, 1999 Expires April, 2000
draft-ietf-sip-session-timer-00.txt
SIP Session Timer Internet Engineering Task Force SIP WG
Internet Draft S.Donovan,J.Rosenberg
draft-ietf-sip-session-timer-01.txt MCI Worldcom,dynamicsoft
March 9, 2000
Expires: September, 2000
Status of this Memo The SIP Session Timer
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
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference mate- time. It is inappropriate to use Internet- Drafts as reference
rial or to cite them other than as "work in progress." material or to cite them other than as work in progress.
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document proposes an extension to the SIP specification [1]. This document proposes an extension to the Session Initiation
This extension adds a new message header, Session-Expires, which is Protocol (SIP). This extension allows for a periodic refresh of SIP
used to specify the duration of a requested session. sessions through a re-INVITE. The refresh allows both user agents and
call stateful proxies to determine in the SIP session is still
A session timer can be used to control the duration of a session if, active. The extension defines a new general header, Session-Expires,
for instance, one of the participants in the session wants to limit which conveys the lifetime of the session.
the cost of the session. Call Stateful SIP Proxy Servers can also use
a session timer to track the status of sessions for which session
state exists on the servers. Currently a call stateful SIP Proxy
Server that is not handling the media stream(s) for the session has
no mechanism to definitively determine the state of all sessions for
which it has state. While the SIP Specification does provide the BYE
method for terminating the session, there is no mechanism for a SIP
Proxy Server to detect the end of a session when the BYE message is
not sent or is lost due to network problems.
1.0 Introduction
The need for the addition of a session timer was initially motivated
by the realization that call stateful proxy servers currently have no
method of determining the end of a session in certain anomalous situ-
ations. 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
problems. In this situation, the call stateful proxy will retain
state for the session and has no deterministic method of determining
when the state no longer applies.
With the addition of a session timer to the SIP protocol, the call
stateful proxy server will have the option of tearing down the ses-
sion upon the expiration of the session timer.
A session timer can also be used for other purposes. For instance,
it could be used in the implementation of a prepaid service. In this
case all session related signaling would be routed through a SIP Pre-
paid Server that would control the session time based on a sub-
scriber's prepaid account. The SIP Prepaid Server could use the ses-
sion timer to force the tear down of the session within a specific
time. The session timer could also be used by the SIP Prepaid Server
as a trigger to indicate to the subscriber that the prepaid account
requires more funds to extend the call.
This document proposes the addition of the Session-Expires header to
various SIP messages. In addition, a new Request Failure message is
proposed. This message would be used to indicate session timer prob-
lems, including the need for a session-expires header in an INVITE
message and the need for a smaller session-expires time.
2.0 Session-Expires Header Field Definition
User agents or proxy servers needing to indicate the maximum duration
of a session shall use the Session-Expires header.
The format of the Session-Expires header shall be equivalent to the
format of the Expires header (see section 6.20 in [1]). As such, the
end of the session can be specified as either an absolute or delta
time.
The Session-Expires header shall be valid in INVITE and ACK requests.
In addition it shall be valid in certain response messages. This
includes the 200 OK response and the new Request Failure responses
defined in this document.
The called UA or any SPS in the path of the session signaling shall
have the option of rejecting an INVITE that does not contain the Ses-
sion-Expires header if the service context in which the session
request is made requires the use of the session timer.
The called UA has the option of adding the Session-Expires header to
the 200 OK response in the case where there was not a Session-Expires
header in the INVITE message.
An SPS shall also have the option of adding the Session-Expires
header to an INVITE message.
In addition, the called UA and SPS shall have the option of modifying
the value in the Session-Expires header. This modification shall
only be to decrease the requested duration of the session.
The start time of the session shall be based on the sending of the
ACK by the calling UA and receipt of the ACK message by the SPS and
called UA.
If the called UA or the SPS requires a session timer for a requested
session and the calling UA does not include the Session-Expires
header in the INVITE message, then the called UA or the SPS may
reject the request with a 487 request failure message.
If the use of a session timer is desirable but optional for the ses-
sion and the calling UA does not include the Session-Expires header
in the INVITE then the called UA or SPS may add a Session-Expires
header to the next session setup message. In this case the SPS shall
add the Session-Expires header to the INVITE message and the called
UA shall add the Session-Expires header to the 200 OK response mes-
sage.
The calling UA shall have the ability to request an extension to the
duration of the session by sending a re-INVITE message for the ses-
sion with a new Session-Expires header. See section 1.4.6, Changing
an Existing Session, in [1].
The called UA or any SPS in the path of the session signaling shall
have the ability to reject the change in the session duration.
Upon expiration of the session timer, the calling UA and called UA
shall have the option of terminating the session using the normal BYE
method.
3.0 Behavior of SIP User Agents
3.1 Behavior of User Agent Clients
A User Agent Client (UAC) shall have the ability to include the Ses-
sion-Expires header in an INVITE message.
The UAC shall have the ability to request an extension of the session
timer by sending an INVITE message for an existing session with a
Session-Expires header. This should be done enough in advance of the
session timeout to prevent the called UA or the SPS from timing out
the session prior to receipt of the new INVITE.
When requesting an extension of the session, the UAC shall use a
value in the Session-Expires header that is less-than or equal to the
value of the Session-Expires header received in the 200 OK from the
original setup of the session.
The UAC shall have the ability to receive a Session-Expires header in
a 200 OK message. This is independent of whether or not a Session-
Expires was included in the original INVITE message.
The UAC shall have the ability to accept the session time indicated
in the 200 OK Session-Expires header by including unchanged Session-
Expires header in the ACK generated as a result of the 200 OK.
The UAC shall have the ability to reject the session time indicated
in the 200 OK message by not including a Session-Expires header in
the ACK generated as a result of the 200 OK message.
In general, if the UAC is able to support session timers then it
should accept the session time included in the 200 OK, even if it
changed between the INVITE and the 200 OK.
3.2 Behavior of User Agent Servers
The User Agent Server shall have the ability to reject an INVITE mes- 1 Introduction
sage that does not contain a Session-Expires header if the INVITE is
received in a service context that requires a session timer. The UAS
shall reject the INVITE using the following response:
487 Session-Expires Header Problem The Session Initiation Protocol (SIP) [1], does not currently define
Session-Expires: n a keepalive mechanism. The result is that call stateful proxies will
not always be able to determine whether a call is still active or
not. For instance, when a user agent fails to send a BYE message at
the end of a session, or the BYE message gets lost due to network
problems, a call stateful proxy will not know when the session has
ended. In this situation, the call stateful proxy will retain state
for the call and has no deterministic method of determining when the
call state information no longer applies.
The UAS shall have the ability to provisionally reject an INVITE To resolve this problem, this extension defines a keepalive mechanism
request based on the contents of the Session-Expires header received for SIP sessions. UAs send periodic re-INVITEs to keep the session
in the INVITE message. For instance, the UAS may choose to reject alive. The interval for the re-INVITEs is determined through a
the INVITE if the requested session time is longer than the UAS negotiation mechanism defined here. If a re-INVITE is not received
desires to participate in the session. The UAS shall use the follow- before the interval passes, the session is considered terminated.
ing message to reject the request: Both UAs are supposed to send a BYE, and call stateful proxies can
remove any state for the call.
487 Session-Expires Header Problem This refresh mechanism has additional applications. For the same
Session-Expires: n reasons a call stateful proxy server would like to determine whether
the session is still active, a user agent would like to make this
determination. This determination can be made at a user agent without
the use of SIP level mechanisms; for audio sessions, periodic RTCP
packets serve as an indication of liveness [2]. However, it is
desirable to separate SIP call liveness from the details of the
particular session.
In both cases, the UAS shall include in the 487 response an accept- Another important application of the session timer is in NAT and
able delta time for the session. firewall control. In order for SIP to flow through a NAT or firewall,
holes and/or address bindings must be dynamically created to allow
the media for the session to flow. These holes and/or address
bindings represent state which must be eventually removed. Relying on
a BYE to trigger the removal of state, besides being unreliable,
introduces a potential denial of service attack.
If the Session-Expires header contains a delta time then the UAS This document proposes an extension to SIP that defines a session
shall calculate the end of the session based on receipt of the ACK expiration mechanism. Periodic refreshes, through re-INVITEs, are
message that completes a successful session initiation: used to keep the session active. A new general header, the Session-
Expires header, is defined. It conveys the expiration time of the
session.
End of session time = Receipt of ACK time + Session-Expires time 2 Protocol Overview
The UAS shall have the ability to reject a request to extend the
length of the session. The UAS shall do so by sending the following
response:
487 Session Time Request Problem UACs which support the session timer extension defined here include a
Session-Expires: n Supported header in all requests, excepting ACK, containing the
option tag "timer" [3]. When a UAC makes a call, it MAY include a
Session-Expires header in the INVITE request. The presence of the
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.
A value of zero (0) in the Session-Expires header shall indicate that Proxies on the signaling path may have their own requirements for the
the extension request is rejected. Any other value should be less refresh interval of the session. If the Supported header in the
than that received in the re-INVITE message and should indicate an request lists the option tag "timer", a proxy can be certain the UAC
acceptable extension to the session timer. understands the session timer. In this case, if no Session-Expires
was present, the proxy can insert one if it so desires. If one was
present, the proxy can lower, but not increase, the expiration time
of the session. If, however, the Supported header was absent, or was
present but didn't include the tag "timer", the proxy MAY reject the
request with a 421, and indicate in the Require header that the
feature "timer" is needed. As an alternative, the proxy MAY forward
the request, but MUST NOT add the Session-Expires header. This will
allow the call to proceed without a timer.
If the Session-Expires header in the re-INVITE contains a delta time Eventually, the initial INVITE reaches the UAS. Like proxies, the UAS
then the UAS shall calculate the new end of the session from the pre- MAY add a session timer, reduce the session timer, or reject the
vious end of session time: request if the session timer is needed but not supported. If the UAS
accepts the call, it places the final value of the session timer in
the Session-Expires in the 200 OK response, and includes a Require
header in the response indicating that the feature "timer" was
applied to the response.
New end of session time = Previous end of session time + delta time As the 200 OK traverses the path back towards the UAC, proxies make
note of the expiration time in the Session-Expires header in the
response. The proxy is safe in destroying call state if a refresh is
not received by this expiration time. The UAC then ACKs the INVITE.
The Session-Expires need not be included in the ACK.
If a request to extend the session time is rejected by the UAS then If the UAC wishes to keep the session alive, it MUST send a re-INVITE
the end of session time that existed prior to the extension request before the expiration time. This re-INVITE MAY contain a Session-
shall be remain in effect. Expires header. The processing of this re-INVITE by proxies and UAS
is identical to that of the initial INVITE.
The UAS shall have the ability to add a Session-Expires header to a If the UAS does not receive a re-INVITE refreshing the session, it
200 OK response for an INVITE request that did not contain a session- SHOULD send a BYE to terminate the call. If the UAC does not receive
Expires header. a response to the re-INVITE used to refresh the session, it SHOULD
send a BYE to terminate the call. Similarly, if a proxy doesn't
receive a re-INVITE before expiration of the session, it MAY remove
associated call state, and MAY free any resources associated with the
call. Unlike the UA, it MUST NOT send a BYE.
If the UAS adds a Session-Expires header to the 200 OK response and 3 Session-Expires Header Field Definition
the resulting ACK does not contain a Session-Expires header then the
UAS has the following options:
- The UAS can choose to participate in the session without a session The Session-Expires header conveys the expiration time for a SIP
timer. session. It is placed in only in INVITE requests, and is allowed in a
200 OK response to an INVITE. Like the SIP Expires header, it can
contain either an absolute time or a delta-time. If it contains an
absolute time, this time indicates the time at which a proxy or UA
may safely destroy any state associated with the call. If it contains
a delta time, the expiration time of the session is defined as that
delta plus the time at which the header is observed in a response.
- The UAS can choose to not participate in the session. In this For example, if a UAS generates a 200 OK response to a re-INVITE that
case, the UAS shall send a BYE message to tear down the session. 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 200 OK 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 200 OK.
The UAS shall have the ability to decrease the requested session time The syntax of the Session-Expires header is:
in the INVITE Session-Expires header.
If the UAS is sending a 200 OK to an INVITE that contained a Session- Session-Expires = "Session-Expires" ":" ( SIP-date |
Expires header then the UAS shall include a Session-Expires header in delta-seconds )
the 200 OK. The content of the Session-Expires header shall be
either the content of the Session-Expires header contained in the
INVITE request, if the UAS accepts the requested duration, or a
decreased value of the session timer desired by the UAS.
4.0 Behavior of SIP Proxy Servers Both SIP-Date and delta-seconds are defined in Section 6.20 of RFC
2543 [1].
A SIP Proxy Server has the option of tracking the duration of ses- Table 1 is an extension of tables 4 and 5 in [1] for the Session-
sions for which it is a proxy. Expires header:
If the SPS receives an INVITE without a Session-Expires header, it where enc. e-e ACK BYE CAN INV OPT REG
has the option of sending the following request failure response Session-Expires R n h - - - o - -
indicating that the Session-Expires header is required: Session-Expires 200 n h - - - o - -
487 Session-Expires Header Problem 4 UAC Behavior
Session-Expires: n
A SPS has the option of rejecting an INVITE with a Session-Expires A UAC which supports the session timer extension defined here MUST
header based on the time specified in the header. For instance, if include a Supported header in each request (excepting ACK), listing
the time specified is too long. The proxy server shall do so by send- the option tag "timer" [3]. It MUST do so even if the UAC is not
ing the following request failure response: requesting keepalives for the call.
487 Session-Expires Header Problem If the UAC wishes to request keepalives for this call, it MUST
Session-Expires: n include a Session-Expires in the INVITE request used to initiate the
call. The value of this header indicates the time when the UAC will
consider the call expired if no refresh is sent. If the request is
being authenticated, the Session-Expires header MUST appear before
the Authorization or Proxy-Authorization headers.
In both cases, the SPS shall include in the 487 response an accept- When the response to the initial INVITE request arrives, it may or
able delta time for the session. may not contain a Session-Expires header. UACs MUST be prepared to
receive a Session-Expires header in a 200 OK response even if none
were present in the request. The presence of this header in response
to an initial INVITE is only relevant in a 200 OK response. Assuming
this is the case, the UAC computes the expiration time of the
session. If the Session-Expires contains an absolute time, that is
the time of expiration. If it contains a delta-time, the expiration
time is the time of reception of the 200 OK plus that delta time. Let
the difference in time between the reception of the 200 OK and the
session expiration time be called the refresh interval. Note that
this expiration applies to the call leg created as a result of that
200 OK. It is explicitly allowed for there to be differing session
timers (or none at all) on differing call legs.
If the Session-Expires header contains a delta time then the SPS If the 200 OK response to the initial INVITE contained a Session-
shall use the method of calculating the session time specified in Expires, and the UAC wishes to continue with the session beyond the
section 3.2. expiration, it MUST generate a refresh before the expiration time. It
is RECOMMENDED that this be refresh be sent once half the refresh
interval has elapsed. This refresh is accomplished by sending a re-
INVITE request on the given call leg. The UAC MAY include a Session-
Expires in this re-INVITE, indicating the new desired expiration time
of the session. If the UAC does not place a Session-Expires header in
the request, this means the UAC wishes for the session to have no
expiration time going forward. The 200 OK response to the re-INVITE
contains the actual expiration time. If the 200 OK response to the
re-INVITE does not contain a Session-Expires header, the session no
longer has an expiration. If the response to the re-INVITE was not a
200 OK, the call is still active (as per RFC 2543), but the
expiration time remains unchanged. As with the original INVITE, the
UAC MUST be prepared to receive a Session-Expires header in a 200 OK
response even if it did not place one in the request.
A SPS has the option of rejecting a request for an extension of the It is important to note that the processing rules for re-INVITEs
session timer for an existing session by sending the following parallels that of the initial INVITE. This helps maintain the
request failure response: idempotency of INVITE.
487 Session-Expires Header Problem A UAC MAY use the refreshing re-INVITE as a normal SIP re-INVITE;
Session-Expires: n that 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 is
unchanged. In the case of SDP [4], this is accomplished by using the
same value for the origin field.
A value of zero (0) in the Session-Expires header shall indicate that If no 200 OK response to a refreshing re-INVITE is received before
the extension request is rejected. Any other value should be less the expiration of the session, the UAC SHOULD send a BYE request to
than that received in the re-INVITE message and should indicate an terminate the call. It SHOULD send this BYE slightly before
acceptable extension to the session timer. expiration of the session. Ten seconds is RECOMMENDED.
If the SPS accepts the request to extend the session timer then it Firewalls and NATs may be very unforgiving about allowing
shall use the method of calculating the new end of session time spec- SIP traffic to pass after the expiration time of the
ified in section 3.2. session. It is for this reason that the BYE should be sent
before the expiration.
The SPS shall have the ability to add a Session-Expires header to an 5 Proxy Behavior
INVITE request that does not contain a Session-Expires header.
The SPS shall have the ability to decrease the requested session time Session expirations are mostly of interest to call stateful proxy
in the INVITE Session-Expires header. servers. However, any proxy server may follow the rules described
here.
The content of the Session-Expires header included in the INVITE sent Due to local policy, a proxy may have guidelines about the desired
by the SPS shall be either the content of the Session-Expires header maximum lifetime for a call initiated through it. When an initial
contained in the INVITE request, if the UAS accepts the requested INVITE is received to establish a call, a proxy MAY insert a
duration, or a decreased value of the session timer desired by the Session-Expires header in the request before forwarding it, if (1)
SPS. none was present in the request, and (2) if the request contained a
Supported header with the option tag "timer". This Session-Expires
header may contain any desired expiration time the proxy would like.
If the SPS adds a Session-Expires header to the 200 OK response and If the initial INVITE had both a Session-Expires header and a
the resulting ACK does not contain a Session-Expires header then the Supported header containing the option tag "timer", the proxy MAY
SPS has the following options: reduce the value in the Session-Expires header before forwarding the
request, but MUST NOT increase it.
- The SPS can choose to allow the session without a session timer. If the initial INVITE did not contain a Supported header with the
option tag "timer", the proxy MUST NOT insert the Session-Expires
header into the forwarded request. It MAY, however, follow the
procedures defined in [3] and reject the request with a 421.
- The SPS can choose to not allow the session. When a 200 OK response arrives for the call, the actual expiration
time for the call leg is contained in the Session-Expires header. The
proxy MUST NOT modify the value of the Session-Expires header when
forwarding the response upstream. The expiration of the call will
occur at the time indicated in the Session-Expires header. If the
Session-Expires header contains a delta-time, the expiration time is
the time of receipt of the 200 OK response, plus that delta time.
5.0 Header Field Definitions Re-INVITE requests may arrive from the UAC, 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.
The following is an extension of tables 4 and 5 in [1] for the Ses- If the session expires without having seen a 200 OK response to a
sion-Expires header: re-INVITE, the proxy MAY consider the call leg terminated. This means
it MAY flush any state associated with that call leg.
where enc. e-e ACK BYE CAN INV OPT REG 6 UAS Behavior
Session-Expires R e o - - o - -
Session-Expires 200 e - - - o - -
Session-Expires 487 e - - - o - -
6.0 Request Failure Messages When a UAS receives an INVITE for a new call, and that INVITE
contains a Session-Expires header, the UAS MUST place a Session-
Expires header in a 200 OK response (assuming the UAS accepts the
call). The UAS MAY reduce the expiration time when it places this
header into the response, but it MUST NOT increase it. If the inital
INVITE did not contain a Session-Expires header, but it did contain a
Supported header containing the option tag "timer", the UAS MAY
insert a Session-Expires header into the response. This header MAY
have any desired expiration time.
6.1 487 Session-Expires Header Problem If the initial INVITE did not contain a Supported header with the
option tag "timer", the UAS MUST NOT insert the Session-Expires
header into the 200 OK response. It MAY, however, follow the
procedures defined in [3] and reject the request with a 421.
The server received an INVITE request with one of the following prob- If the UAS sends a 200 OK to the initial INVITE, and that 200 OK had
lems: a Sesion-Expires header, the UAS computes the expiration time of the
session. If the Session-Expires contains an absolute time, that is
the time of expiration. If it contains a delta-time, the expiration
time is the time of transmission of the 200 OK plus that delta time.
- The server requires a Session-Expires header. In this case the As described in Section 4, the UAC will send periodic re-INVITEs to
response should contain a Session-Expires header with an acceptable refresh the session. The UAS MUST be prepared to receive and process
session time. these re-INVITEs. Processing of the re-INVITE, as far as the session
timer is concerned, is identical to the rules for the initial INVITE,
described above. Note that if the 200 OK to the re-INVITE has no
Session-Expires, no expiration time exists for the session.
- The server received an INVITE with a Session-Expires header with an Since the re-INVITE is a standard re-INVITE, it is possible, for
expiration time longer than the server is willing to accept. In this whatever reason, that the UAS might reject the request. The
case the response should contain a Session-Expires header with an processing rules for session timer only apply to INVITEs with a 200
acceptable session time. OK response.
- The server received an INVITE with a Session-Expires header for an If no re-INVITE is received before expiration of the timer, the UAS
existing session and the server does not wish to extend the session. SHOULD send a BYE for the call leg.
In this case the response should contain a Session-Expires header
with a value of zero (0).
- The server received an INVITE with a Session-Expires header for an 7 Security Considerations
existing session with an expiration time longer than the server is
willing to accept. In this case the response should contain a Ses-
sion-Expires header with an acceptable session time.
7.0 Security Considerations The session timer introduces the capability of a proxy to effectively
force clients to send refreshes at a rate of the proxies choosing. It
can also force the clients to send a BYE by setting the expirations
to times that are too short. This introduces the possibility of rogue
proxies introducing denial-of-service attacks. Use of short refresh
intervals allows the proxies to create network load. The session
timer mechanism allows the proxy to be able to terminate established
calls - a capability a normal proxy doesn't have in [1].
There are no new security considerations introduced by the Session- As a result of these potential attacks, it is RECOMMENDED that IP or
Expires header. transport level security is used when communicating between proxies.
8.0 Examples 8 Examples
The following examples are meant to illustrate the functionality The following examples are meant to illustrate the functionality
associated with the Session-Expires header. In the interest of associated with the session timer. In the interest of brevity, all
brevity, other headers are intentionally left out of the SIP mes- headers excepting Supported, Session-Expires and Require are
sages. intentionally left out of the SIP messages.
8.1 Basic session-timer setup with UAS detected timeout 8.1 Basic session-timer setup with UAS detected timeout
Calling UA -> Called UA Calling UA -> Called UA
INVITE INVITE
Supported: timer
Session-Expires: 120 Session-Expires: 120
Calling UA <- Called UA Calling UA <- Called UA
200 OK 200 OK
Session-Expires: 120 Require: timer
Session-Expires: 120 Called UA starts session timer on send
Calling UA starts session timer on receipt
Calling UA -> Called UA Calling UA -> Called UA
ACK Calling UA starts session timer ACK
Session-Expires: 120
Called UA Receipt of ACK Called UA starts session timer
Calling UA determines need to extend session time 60 seconds later:
Calling UA -> Called UA Calling UA -> Called UA
INVITE INVITE
Supported: timer
Session-Expires: 120 Session-Expires: 120
Calling UA <- Called UA Calling UA <- Called UA
200 OK 200 OK
Session-Expires: 120 Require: timer
Session-Expires: 120 Called UA starts session timer on send
Calling UA starts session timer on receipt
Calling UA -> Called UA Calling UA -> Called UA
ACK Calling UA resets session end time ACK
Session-Expires: 120
Called UA Receipt of ACK Called UA resets session timer
Session timeout detected by Called UA 120 seconds later the called UA did not receive a re-INVITE. It
therefore considers the call terminated and sends a BYE:
Calling UA <- Called UA Calling UA <- Called UA
BYE BYE
Calling UA -> Called UA Calling UA -> Called UA
200 OK 200 OK
8.2 Basic negotiation 8.2 Basic negotiation of Session Time
In this configuration, two UAs talk through a single stateful proxy
server (SPS). Both the SPS and the UAS reduce the session timer.
Calling UA -> SPS Calling UA -> SPS
INVITE INVITE
Supported: timer
Session-Expires: 240 Session-Expires: 240
SPS -> Called UA SPS -> Called UA
INVITE SPS wants a shorter timer INVITE SPS wants a shorter timer
Supported: timer
Session-Expires: 180 Session-Expires: 180
SPS <- Called UA SPS <- Called UA
200 OK Called UA wants a shorter timer 200 OK Called UA wants a shorter timer
Session-Expires: 120 Session-Expires: 120 Called UA starts timer
Require: timer
Calling UA <- SPS Calling UA <- SPS
200 OK 200 OK
Session-Expires: 120 Session-Expires: 120 Proxy starts timer on send
Require: timer Calling UA starts timer on receipt
Calling UA -> SPS Calling UA -> SPS
ACK Calling UA starts session timer ACK
Session-Expires: 120
SPS Receipt of ACK SPS starts session timer
SPS -> Called UA SPS -> Called UA
ACK Called UA starts session timer ACK
Session-Expires: 120
For whatever reason, the calling UA decides not to refresh. So, after
120 seconds, it sends a BYE.
Calling UA -> SPS Calling UA -> SPS
BYE BYE
SPS -> Called UA SPS -> Called UA
BYE BYE
SPS <- Called UA SPS <- Called UA
200 OK 200 OK
Calling UA <- SPS Calling UA <- SPS
200 OK 200 OK
8.3 No Session-Expires Header Rejection by SPS 8.3 No Session-Expires Header Rejection by SPS
In this scenario, the UA sends an INVITE without a Session-Expires
header and without a Supported header containing the option tag
"timer". Since the proxy requires session timer for the call, it
rejects the INVITE.
Calling UA -> SPS Calling UA -> SPS
INVITE No Session-Expires header INVITE No Session-Expires or Supported header
Calling UA <- SPS Calling UA <- SPS
4xx Session-Expires Header Required 421 Extension Required
Session-Expires: 120 Suggested session time Require: timer
Calling UA -> SPS Calling UA -> SPS
INVITE ACK
Session-Expires: 120
Session setup continues 8.4 Addition of Session-Expires by UAS
8.4 Invalid Session-Expires Header Rejection by Called UA In this scenario, the calling UA indicates that it supports the
session timer, but does not add the Session-Expires into the INVITE.
The UAS, however, adds the header.
Calling UA -> Called UA Calling UA -> Called UA
INVITE No Session-Expires header INVITE
Session-Expires: 1000 Supported: timer
Calling UA <- Called UA Calling UA <- Called UA
4xx Session Time Request Rejected 200 OK
Session-Expires: 120 Suggested session time Require: timer
Session-Expires: 120 Called UA starts timer on send
Calling UA starts timer on receipt
Calling UA -> Called UA Calling UA -> Called UA
INVITE ACK
Session-Expires: 120
Session setup continues 8.5 Addition of Session-Expires by Proxy
8.5 Session-Expires Header Added by SPS, Rejected by UAC In this scenario, the calling UA indicates that it supports the
session timer, but does not add the Session-Expires header into the
INVITE. The proxy adds it, but session timer is not supported by the
UAS. The result is that the call is set up without a session timer.
Calling UA -> SPS Calling UA -> SPS
INVITE INVITE
k: timer
SPS -> Called UA SPS -> Called UA
INVITE SPS adds S-E header INVITE SPS adds S-E header
k: timer
Session-Expires: 180 Session-Expires: 180
SPS <- Called UA SPS <- Called UA
200 OK Called UA wants shorter timer 200 OK Called UA doesn't understand session timer
Session-Expires: 120
Calling UA <- SPS Calling UA <- SPS
200 OK 200 OK
Session-Expires: 120
Calling UA -> SPS Calling UA -> SPS
ACK Calling UA does not include S-E header ACK
The SPS has the choice of allowing or not allowing the call as a SPS -> Called UA
result of the Calling UA not supporting the Session-Expires function. ACK
9.0 Changes in this version 9 Changes since -00
The changes in this version of the document were primarily editorial o Changed to make use of the Supported header.
in nature.
10.0 References o Conveyance of Session Expires in ACK is no longer needed
(because of usage of the Supported header), and has been
removed.
[1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: o Session Expires only allowed in INVITE, not in BYE as
Session Initiation Protocol", RFC 2543, March 1999. previously specified. Usage in BYE doesn't accomplish
anything, as the call is terminated.
11.0 Author's Address o Specified that only UAC sends re-INVITEs for keepalives.
o Session Expires only present in 200 OK responses. Doesn't
appear to be needed in any other.
o Session-Expires no longer mandatory in re-INVITEs. This is
done to unify the processing of INVITE and re-INVITE for
session timer. Also means that a previously timed session can
become untimed.
o Changed semantics of delta-time to be relative to the time of
message arrival, rather than the time of previous expiration.
This is in line with normal Expires processing.
o The original mechanism allowed a proxy to reject the request
if the timer was too long, or to reduce the timer. There seems
to be no clear reason to have both. Rejecting will just cause
the client to resubmit with the shorter expiration, resulting
in the same net effect with additional complexity. Thus, the
notion of rejecting session timers is removed, and with it,
the 488 response code, which is then uneccesary. This seems to
simplify the protocol.
o A mechanism had existed to reject a session timer with a
Session-Expires of 0, meaning the expiration remains
unchanged. With the new definition of the relative offset for
Expires, this no longer requires special treatment. A proxy or
UAS can set the session timer with an absolute time equal to
the current expiration.
10 Open Issues
o Should we allow Session-Expires in non-INVITE requests,
perhaps INFO (I think no)
o Should we allow the UAC to insert a Require header in the
request, indicating that the UAS must support the session
timer? (I think no)
o With this draft (and the previous versions), there was no way
for the proxy to reject the call if the calling UA supported
the session timer, but the called UA didn't. Is this a
problem? If so, what can be done about it? (I think there is
nothing we can do, and we should not worry about it)
11 Author's Addresses
Steven R. Donovan Steven R. Donovan
MCI Worldcom MCI Worldcom
1493/678 1493/678
901 International Parkway 901 International Parkway
Richardson, Texas 75081 Richardson, Texas 75081
Email: steven.r.donovan@wcom.com email: steven.r.donovan@wcom.com
Jonathan Rosenberg
dynamicsoft
200 Executive Drive
Suite 120
West Orange, NJ 07052
email: jdrosen@dynamicsoft.com
12 Bibliography
[1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
session initiation protocol," Request for Comments (Proposed
Standard) 2543, Internet Engineering Task Force, Mar. 1999.
[2] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: a
transport protocol for real-time applications," Request for Comments
(Proposed Standard) 1889, Internet Engineering Task Force, Jan. 1996.
[3] J. Rosenberg and H. Schulzrinne, "Mandating SIP extension support
by servers," Internet Draft, Internet Engineering Task Force, Jan.
2000. Work in progress.
[4] M. Handley and V. Jacobson, "SDP: session description protocol,"
Request for Comments (Proposed Standard) 2327, Internet Engineering
Task Force, Apr. 1998.
Full Copyright Statement
Copyright (c) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Table of Contents
1 Introduction ........................................ 1
2 Protocol Overview ................................... 2
3 Session-Expires Header Field Definition ............. 3
4 UAC Behavior ........................................ 4
5 Proxy Behavior ...................................... 6
6 UAS Behavior ........................................ 6
7 Security Considerations ............................. 7
8 Examples ............................................ 8
8.1 Basic session-timer setup with UAS detected
timeout ........................................................ 8
8.2 Basic negotiation of Session Time ................... 9
8.3 No Session-Expires Header Rejection by SPS .......... 10
8.4 Addition of Session-Expires by UAS .................. 10
8.5 Addition of Session-Expires by Proxy ................ 10
9 Changes since -00 ................................... 11
10 Open Issues ......................................... 12
11 Author's Addresses .................................. 12
12 Bibliography ........................................ 13
 End of changes. 

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