draft-ietf-sip-session-timer-02.txt   draft-ietf-sip-session-timer-03.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-02.txt dynamicsoft draft-ietf-sip-session-timer-03.txt dynamicsoft
July 14, 2000 October 30, 2000
Expires: January 2001 Expires: April 2001
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
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
http://www.ietf.org/ietf/1id-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 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
call stateful proxies to determine if the SIP session is still proxies to determine if the SIP session is still active. The
active. The extension defines a new general header, Session-Expires, extension defines a new general header, Session-Expires, which
which conveys the lifetime of the session. conveys the lifetime of the session.
1 Introduction 1 Introduction
The Session Initiation Protocol (SIP) [1], does not currently define The Session Initiation Protocol (SIP) [1], does not currently define
a keepalive mechanism. The result is that call stateful proxies will 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 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
skipping to change at page 2, line 17 skipping to change at page 2, line 17
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
alive. The interval for the re-INVITEs is determined through a alive. The interval for the re-INVITEs is determined through a
negotiation mechanism defined here. If a re-INVITE is not received negotiation mechanism defined here. If a re-INVITE is not received
before the interval passes, the session is considered terminated. before the interval passes, the session is considered terminated.
Both UAs are supposed to send a BYE, and call stateful proxies can Both UAs are supposed to send a BYE, and call stateful proxies can
remove any state for the call. remove any state for the call.
INVITE is used as a refresh, as opposed to another method,
to allow sessions to be recovered after a crash and restart
of one of the UAs. It makes SIP sessions soft state.
This refresh mechanism has additional applications. For the same This refresh mechanism has additional applications. For the same
reasons a call stateful proxy server would like to determine whether reasons a call stateful proxy server would like to determine whether
the session is still active, a user agent would like to make this the session is still active, a user agent would like to make this
determination. This determination can be made at a user agent without determination. This determination can be made at a user agent without
the use of SIP level mechanisms; for audio sessions, periodic RTCP the use of SIP level mechanisms; for audio sessions, periodic RTCP
packets serve as an indication of liveness [2]. However, it is packets serve as an indication of liveness [2]. However, it is
desirable to separate SIP call liveness from the details of the desirable to separate SIP call liveness from the details of the
particular session. particular session.
Another important application of the session timer is in NAT and Another important application of the session timer is in NAT and
firewall control [3]. In order for SIP to flow through a NAT or firewall control [3]. In order for SIP to flow through a NAT or
firewall, holes and/or address bindings must be dynamically created firewall, holes and/or address bindings must be dynamically created
to allow the media for the session to flow. These holes and/or to allow the media for the session to flow. These holes and/or
address bindings represent state which must be eventually removed. address bindings represent state which must be eventually 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 one of the two backwards compatible with SIP that it works so long as either one of
participants in a call leg understand the extension. A new general the two participants in a call leg understand the extension. A new
header, the Session-Expires header, is defined. It conveys the general header, the Session-Expires header, is defined. It conveys
expiration time of the session. the expiration time of the session.
2 Protocol Overview 2 Protocol Overview
UACs which support the session timer extension defined here include a UACs which support the session timer extension defined here MUST
Supported header in all requests, excepting ACK, containing the include a Supported header in all requests, excepting ACK, containing
option tag "timer" [4]. When a UAC makes a call, it MAY include a the option tag "timer" [4]. When a UAC makes a call, it MAY include a
Session-Expires header in the INVITE request. The presence of the Session-Expires header in the INVITE request. The presence of the
Session-Expires header indicates that the UAC wishes to use the Session-Expires header indicates that the UAC wishes to use the
session timer for this call. Its value indicates the desired session timer for this call. Its value indicates the desired
expiration time of the session. expiration time of the session.
Proxies on the signaling path may have their own requirements for the Proxies on the signaling path may have their own requirements for the
refresh interval of the session. If the Supported header in the refresh interval of the session. If the Supported header in the
request lists the option tag "timer", a proxy can be certain the UAC request lists the option tag "timer", a proxy can be certain the UAC
understands the session timer. In this case, if no Session-Expires 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 was present, the proxy can insert one if it so desires. If one was
skipping to change at page 3, line 21 skipping to change at page 3, line 25
of the session. The proxy remembers the value of Session-Expires it of the session. The proxy remembers the value of Session-Expires it
placed into the request, and also remembers that the UAC supported placed into the request, and also remembers that the UAC supported
session timer. The UAC will ultimately be responsible for sending the session timer. The UAC will ultimately be responsible for sending the
refreshes for this call leg. refreshes for this call leg.
If the Supported header was absent from the request, or was present If the Supported header was absent from the request, or was present
but didn't include the tag "timer", the proxy knows the UAC cannot but didn't include the tag "timer", the proxy knows the UAC cannot
generate refreshes, but the called party may be able to. If no generate refreshes, but the called party may be able to. If no
Session-Expires was present, the proxy can insert one if it so Session-Expires was present, the proxy can insert one if it so
desires. If one was present, the proxy can lower, but not increase, desires. If one was present, the proxy can lower, but not increase,
the expiration time of the session. The proxy remembers the value of the expiration time of the session. The proxy MUST remember the value
Session-Expires it placed into the request, and also remembers that of Session-Expires it placed into the request, and also MUST remember
the UAC did not support the session timer. The UAS may be responsible that the UAC did not support the session timer. The UAS may be
for sending the refreshes for this call leg. If the proxy wishes to responsible for sending the refreshes for this call leg. If the proxy
insist that the call is only established if the UAS supports session wishes to insist that the call is only established if the UAS
timer, it MAY insert a Require header into the request, with the supports session timer, it MAY insert a Require header into the
value "timer". request, with the value "timer", although this is NOT RECOMMENDED,
since it eliminates the possibility of call establishment if the UAS
does not support session timers.
Eventually, the initial INVITE reaches the UAS. There are two cases - Eventually, the initial INVITE reaches the UAS. There are two cases -
the UAS supports session timer, or it does not. If it does, the UAS the UAS supports session timer, or it does not. If it does, and the
MAY add a session timer or reduce the session timer from the request. response is otherwise acceptable to the UAS, the UAS MUST copy the
If the UAS accepts the call, it places the final value of the session Session-Expires into the 200 class response, or MAY add one into the
timer in the Session-Expires in the 200 OK response. If the request response if none was present in the request. They UAS MAY reduce the
also contained the Supported header with the value "timer", the UAS session timer in the 200 class response. If the request also
knows the UAC can do refreshes. To make sure the UAC is aware it must contained the Supported header with the value "timer", the UAS knows
actually do them, the UAS MUST add a Require to the 200 OK response, that the UAC can do refreshes. To make sure the UAC is aware it must
with the tag "timer". The UAS does not perform the refreshes in this actually do them, the UAS MUST add a Require header to the 200 class
case. If the request did not contain the Supported header with the response, with the tag "timer", when the request contains a Require
value "timer", the UAS knows the UAC cannot perform refreshes. So, it header with tag "timer". The UAS does not perform the refreshes in
assumes the responsibility. It MUST add the value of the Session- this case. If the request did not contain the Supported header with
Timer to the response, but it MUST NOT add a Require header with the value "timer", the UAS knows the UAC cannot perform refreshes.
value "timer". This is because the UAC does not support the So, it assumes the responsibility. In this case, it MUST add the
extension; the UAS cannot insist on its usage at the UAC, which is value of the Session-Expires to the response, but it MUST NOT add a
what a Require header in the response would accomplish. Require header with value "timer". This is because the UAC does not
support the extension; the UAS cannot insist on its usage at the UAC,
which is what a Require header in the response would accomplish.
If the UAS does not support session timer, it behaves as a normal If the UAS does not support session timer, it behaves as a normal
UAS. It will, in this case, neither insert Session-Expires in the UAS. It will, in this case, neither insert Session-Expires in the
response nor a Require header with value "timer". response nor a Require header with value "timer".
This response travels backwards through the proxies. When it reaches This response travels backwards through the proxies. When it reaches
a proxy which remembers that it asked for session timer, the proxy a proxy which remembers that it asked for session timer, the proxy
examines the response. If the response did not contain a Session- examines the response. If the response did not contain a Session-
Expires header, but the proxy remembers that the UAC supported Expires header, but the proxy remembers that the UAC supported
session timer, the proxy knows that the UAC supports session timer, session timer, the proxy knows that the UAC supports session timer,
but the UAS did not. So, it inserts the Session-Expires header into but the UAS does not. So, it inserts the Session-Expires header into
the response and also adds a Require header with a value of "timer". the response and also adds a Require header with a value of "timer".
If the response the proxy received did have a Session-Expires header, If the response the proxy received did have a Session-Expires header,
but no Require header with value "timer", the proxy knows that the but no Require header with value "timer", the proxy knows that the
UAS understands session timer, but not the UAC. It simply forwards UAS understands session timer, but not the UAC. It simply forwards
this request upstream. If the proxy gets a response without Session- this request upstream. If the proxy gets a response without Session-
Expires, and the proxy remembers that the UAC did not support session Expires, and the proxy remembers that the UAC did not support session
timer, the proxy knows that session timer cannot be used, since timer, the proxy knows that session timer cannot be used, since
neither UAS nor UAC support it. Finally, if the response contains the neither UAS nor UAC support it. Finally, if the response contains the
Session-Expires and Require header with the value "timer", the proxy Session-Expires and Require header with the value "timer", the proxy
knows that both UAC and UAC support session timer, and that the UAC knows that both UAC and UAS support session timer, and that the UAC
will be performing refreshes. will be performing refreshes.
The response then arrives at the UAC. If it contains a Require header The response then arrives at the UAC. If it contains a Require header
with the value "timer", the UAC knows it is responsible for with the value "timer", the UAC knows it is responsible for
refreshes. The response will also contain a Session-Expires header, refreshes. The response will also contain a Session-Expires header,
and the value of that header is used as the interval for refreshes. and the value of that header is used as the interval for refreshes.
The UAC then ACKs the INVITE. The Session-Expires MUST NOT be The UAC then ACKs the INVITE. The Session-Expires MUST NOT be
included in the ACK. included in the ACK.
If the calling UA is supposed to perform refreshes and wishes to keep If the calling UA is supposed to perform refreshes and wishes to keep
the session alive, it MUST send a re-INVITE before the expiration the session alive, it MUST send a re-INVITE before the expiration
time. This re-INVITE MAY contain a Session-Expires header. The time. This re-INVITE MAY contain a Session-Expires header. The
processing of this re-INVITE by proxies and UAS is identical to that processing of this re-INVITE by proxies and UAS is identical to that
of the initial INVITE. of the initial INVITE, excepting that processing may also take place
for non-200 final responses.
If the called UA is supposed to perform refreshes and wishes to keep If the called UA is supposed to perform refreshes and wishes to keep
the session alive, it MUST send a re-INVITE before the expiration the session alive, it MUST send a re-INVITE before the expiration
time. This re-INVITE MAY contain a Session-Expires header. The time. This re-INVITE MAY contain a Session-Expires header. The
processing of this re-INVITE by proxies and UAS is identical to that processing of this re-INVITE by proxies and UAS is identical to that
of the initial INVITE. of the initial INVITE, excepting that processing may also take place
for non-200 final responses.
If the calling UA or the called UA is not performing refreshes, and If the calling UA or the called UA is not performing refreshes, and
does not receive a re-INVITE refreshing the session before the does not receive a re-INVITE refreshing the session before the
session expires, they SHOULD send a BYE to terminate the call. If a session expires, they SHOULD send a BYE to terminate the call. If a
refreshing UA does not receive a response to the re-INVITE used to refreshing UA does not receive a response to the re-INVITE used to
refresh the session, it SHOULD send a BYE to terminate the call. refresh the session, it SHOULD send a BYE to terminate the call.
Similarly, if a proxy doesn't receive a re-INVITE before expiration 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 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 resources associated with the call. Unlike the UA, it MUST NOT send a
BYE. BYE.
3 Session-Expires Header Field Definition 3 Session-Expires Header Field Definition
The Session-Expires header conveys the expiration time for a SIP The Session-Expires header conveys the expiration time for a SIP
session. It is placed in only in INVITE requests, and is allowed in session described in the body of the message. It is placed only in
any response to an INVITE. Like the SIP Expires header, it can INVITE requests, and is allowed in any final response to an INVITE.
contain either an absolute time or a delta-time. If it contains an Like the SIP Expires header, it can contain either an absolute time
absolute time, this time indicates the time at which a proxy or UA or a delta-time. If it contains an absolute time, this time indicates
may safely destroy any state associated with the call. If it contains the time at which a proxy or UA may safely destroy any state
a delta time, the expiration time of the session is defined as that associated with the call. If it contains a delta time, the expiration
delta plus the time at which the header is observed in a response. time of the session is defined as that delta plus the time at which
For example, if a UAS generates a 200 OK response to a re-INVITE that the header is observed in a final response. For example, if a UAS
contained a Session-Expires header with a value of 3600, the UAS generates a 200 OK response to a re-INVITE that contained a Session-
computes the expiration time of the session as one hour after the Expires header with a value of 3600, the UAS computes the expiration
time when the 200 OK was sent. For each proxy, the expiration time is time of the session as one hour after the time when the 200 OK was
one hour after the time when the 200 OK was received or sent sent. For each proxy, the expiration time is one hour after the time
(assuming these two are sufficiently close together). For the UAC, when the 200 OK was received or sent (assuming these two are
the expiration time is one hour after the receipt of the 200 OK. 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 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
seconds is RECOMMENDED. In other words, SIP entites MUST be prepared
to handle session refresh intervals of any duration, but entities
that insert the Session-Expires header SHOULD NOT choose times that
result in intervals less than 30 seconds.
The syntax of the Session-Expires header is: The syntax of the Session-Expires header is:
Session-Expires = "Session-Expires" ":" ( SIP-date | Session-Expires = "Session-Expires" ":" ( SIP-date |
delta-seconds ) delta-seconds )
Both SIP-Date and delta-seconds are defined in Section 6.20 of RFC Both SIP-Date and delta-seconds are defined in Section 6.20 of RFC
2543 [1]. 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 r n h - - - o - - Session-Expires r n h - - - o - -
Table 1: Summary of header fields. "o": optional "-": not applicable,
"R': request header, "r": response header, "g": general header, "*":
needed if message body is not empty. A numeric value in the "type"
column indicates the status code the header field is used with.
4 UAC Behavior 4 UAC Behavior
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 (excepting ACK), listing
the option tag "timer" [4]. It MUST do so even if the UAC is not the 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 If the UAC wishes to request keepalives for this call, it MUST
include a Session-Expires in the INVITE request used to initiate the 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 call. The value of this header indicates the time when the UAC will
skipping to change at page 6, line 23 skipping to change at page 6, line 46
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. extension.
When the response to the initial INVITE request arrives, it may or When the response to the initial INVITE request arrives, it may or
may not contain a Session-Expires header, and may or may not contain may not contain a Session-Expires header, and may or may not contain
a Require header with the value "timer". UACs MUST be prepared to a Require header with the value "timer". UACs MUST be prepared to
receive a Session-Expires header in a response even if none were receive a Session-Expires header in a response even if none were
present in the request. present in the request.
Table 4 describes the behavior of the UAC after receiving a 200 OK Table 2 describes the behavior of the UAC (in terms of handling
response to an initial INVITE, or any final response to a re-INVITE. refreshes) after receiving a 200 class response to an initial INVITE,
or any final response to a re-INVITE, based on the headers present in
that response.
Require Session-Timer Behavior Require Session-Expires Behavior
N N Do nothing. N N Do nothing.
N Y Do nothing. N Y UAS is performing refreshes. Do nothing.
Y N Should never happen. Do nothing. Y N Should never happen. Do nothing.
Y Y UAC SHOULD perform refreshes. Y Y UAC MUST perform refreshes.
Table 2: UAC Behavior
If the UAC must refresh, it follows the following procedure. The UAC If the UAC must refresh, it follows the following procedure. The UAC
computes the expiration time of the session. If the Session-Expires computes the expiration time of the session. If the Session-Expires
contains an absolute time, that is the time of expiration. If it contains an absolute time, that is the time of expiration. If it
contains a delta-time, the expiration time is the time of reception contains a delta-time, the expiration time is the time of reception
of the response plus that delta time. Let the difference in time of the response plus that delta time. Let the difference in time
between the reception of the response and the session expiration time between the reception of the response and the session expiration time
be called the refresh interval. Note that this expiration applies be called the refresh interval. Note that this expiration applies
only to the call leg associated with the response. It is explicitly 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 allowed for there to be differing session timers (or none at all) on
differing call legs. 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 If UA wishes to continue with the session beyond the expiration, it
MUST generate a refresh before the expiration time. It is RECOMMENDED MUST generate a refresh before the expiration time. It is RECOMMENDED
that this refresh be sent once half the refresh interval has elapsed. that this refresh be sent once half the refresh interval has elapsed.
This refresh is accomplished by sending a re-INVITE request on the This refresh is accomplished by sending a re-INVITE request on the
given call leg. Sending of the refresh (in terms of this extension), given call leg. Sending of the refresh (in terms of this extension),
and processing the response are exactly identical to the rules above. and processing the response are exactly identical to the rules above,
excepting that the processing applies to non-200 final responses, as
well as 200 class final responses.
A UA MAY use the refreshing re-INVITE as a normal SIP re-INVITE; that A UA MAY use the refreshing re-INVITE as a normal SIP re-INVITE; that
is, this re-INVITE MAY contain an updated session description. In the is, this re-INVITE MAY contain an updated session description. In the
case where the re-INVITE contains an updated session description, the case where the re-INVITE contains an updated session description, the
session description MUST somehow indicate that it has changed. In the session description MUST somehow indicate that it has changed. In the
case of SDP [5], this is accomplished by using a different value for case of SDP [5], this is accomplished by using a different value for
the origin field. the origin field.
If the refreshing re-INVITE is used solely for refreshing, it still If the refreshing re-INVITE is used solely for refreshing, it MUST
contains SDP. However, this is exactly the same SDP as sent still contain a session description, unchanged from the previous
previously by the UA. 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.
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 expiration of the session, the UA SHOULD send a BYE request to
terminate the call. It SHOULD send this BYE slightly before terminate the call. It SHOULD send this BYE slightly before
expiration of the session. Ten seconds is RECOMMENDED. expiration of the session. The minimum of ten seconds and one third
the session interval is RECOMMENDED.
For example, if the session interval is 120 seconds, one
third of this is 40 seconds. Since the minimum of 10
seconds and 40 seconds is 10 seconds, the BYE would be sent
10 seconds before the session expires.
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.
Note that it is possible that the calling UA is generating refreshes, Note that it is possible that the calling UA is generating refreshes,
and then it receives a re-INVITE. After following the rules for UAS and then it receives a re-INVITE. After following the rules for UAS
described below, the calling UA now determines it is not supposed to described below, the calling UA now determines it is not supposed to
generate refreshses. The UA SHOULD cease generating refreshes in this generate refreshes. The UA SHOULD cease generating refreshes in this
case, and let the other UA perform them. This also implies that the case, and let the other UA perform them. This also implies that the
responsibility for generating refreshes may change many times during responsibility for generating refreshes may change during a call.
a call.
Also note that a non-200 response to an initial INVITE MAY indicate a Note that it is possible for a UAS to believe that an INVITE is an
session expiration. This happens when a UA crashes and reboots initial INVITE, and for the UAC to believe it is a re-INVITE. This
between refreshes. When the refresh arrives at the rebooted UA, it happens when a UA crashes and reboots between refreshes. When the
decides to reject the call. In order to alert the UAC that it refresh arrives at the rebooted UA, it decides to reject the call.
believes the call is down (the UAC believes this request to be a re- The UAS can detect that the re-INVITE is for an existing call by the
INVITE, and so a non-200 OK final response will not cause it to existence of the tag in the To field of the re-INVITE. In order to
destroy the call), it MAY include a Session-Expires and Require into alert the UAC that it believes the call is now down (the UAC believes
the non-200 response (assuming session timer is supported by the this request to be a re-INVITE, and so a non-200 OK final response
UAC), with an immediate expiration time. will not cause it to destroy the call), the UAS SHOULD include a
Session-Expires and Require into the non-200 response (assuming
session timer is supported by the UAC), with an immediate expiration
time.
5 Proxy Behavior 5 Proxy Behavior
Session expirations are mostly of interest to call stateful proxy Session expirations are mostly of interest to call stateful proxy
servers. However, a stateful proxy server may also follow the rules servers. However, a stateful proxy server MAY also follow the rules
described here. Stateless proxies MUST NOT attempt to request session described here. Stateless proxies MUST NOT attempt to request session
timers. timers.
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.
5.1 Processing of requests
Due to local policy, a proxy may have guidelines about the desired Due to local policy, a proxy may have guidelines about the desired
maximum lifetime for a call initiated through it. When an initial maximum lifetime for a call initiated through it. When an initial
INVITE is received to establish a call, a proxy MAY insert a INVITE is received to establish a 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. If the request any desired expiration time the proxy would like. If the request
already had a Session-Expires header, the proxy MAY reduce the value already had a Session-Expires header, the proxy MAY reduce the value
in the Session-Expires header before forwarding the request, but MUST in the Session-Expires header before forwarding the request, but MUST
NOT increase it. NOT increase it.
Assuming the proxy wishes to use session timer (and thus has possibly Assuming the proxy wishes to use 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
in the request it forwarded, until the final response to the request in the request it forwarded, until the final response to the request
arrives, or the transaction times out. If the request also contained arrives, or the transaction times out. If the request also contained
the Supported header with the value "timer", the proxy MUST remember the Supported header with the value "timer", the proxy MUST remember
this as well. this as well.
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". This allows the proxy to insist on session timer the value "timer". However, this is NOT RECOMMENDED. This allows the
for the session. This header is not needed if a Supported header was proxy to insist on session timer for the session. This header is not
in the request; in this case, the proxy can already be sure that the needed if a Supported header was in the request; in this case, the
session timer can be used for the session. proxy can already be sure that the session timer can be used for the
session.
5.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. If it does not contain a Session-Expires header, and the proxy proxy. There are four cases.
remembers that the UAC supports session timer, the proxy MUST insert
a Session-Timer header into the response with the value it remembered
placing into the forwarded request. The proxy MUST also insert the
Require header into the response, with the value "timer", before
forwarding it upstream. The value of the Session-Timer in the
forwarded response represents the expiration time of the session.
If the final response to the request arrives without a Session- CASE I: UAC supports, UAS doesn't. In this case, the proxy
Expires header, and the proxy remembers that the proxy did not remembers that it inserted a Session-Expires header into
support session timer, then session timer is not available for this the request, and that the UAC supported session timer.
session. However, the final response does not contain s Session-
Expires header, nor does it contain a Require header with
the option tag "timer". In this case, the proxy is the
closest proxy to the UAS that requested session timer. The
proxy MUST insert a Session-Expires header into the
response with the value it remembered placing into the
forwarded request. 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.
If the final response does contain a Session-Expires header, its CASE II: UAC doesn't support, UAS doesn't support. In this case,
value represents the expiration time of the session. the final response has no Session-Expires header, and the
proxy remembers that the UAC did not support the session
timer. The proxy forwards the response upstream normally.
There are no session timers for this call leg.
In all cases, the proxy MUST NOT modify the value of the Session- CASE III: UAS supports, UAC doesn't. In this case, the final
Expires header received in the response before forwarding it response contains a Session-Expires header, but no Require
header with the tag "timer". The proxy remembers that the
UAC did not support session timers. The UAS will perform
refreshes in this case. The proxy forwards the response
upstream. upstream.
The expiration of the call will occur at the time indicated in the CASE IV: UAC supports, UAS supports. In this case, the final
Session-Expires header. If the Session-Expires header contains a response contains a Session-Expires header and a Require
header with the tag "timer". The UAC performs refreshes in
this case. This 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
contains a Session-Expires header, its value represents the
expiration time of the session for the call leg associated with that
response. Note that there can be multiple 200 class responses to a
single INVITE, each representing a different call leg, resulting in
multiple session timers, one for each call leg.
In all cases, the proxy MUST NOT modify the value of the Session-
Expires header received in the response (assuming one was present)
before forwarding it upstream.
The expiration of the call leg 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 final delta-time, the expiration time is the time of receipt of the final
response, plus that delta time. response, plus that delta time.
Re-INVITE requests may arrive from either UA, refreshing the session Re-INVITE requests may arrive from either UA, refreshing the session
and extending the expiration time. Processing of these re-INVITEs by and extending the expiration time. Processing of these re-INVITEs by
a proxy is identical to the procedure for processing the initial a proxy is identical to the procedure for processing the initial
INVITE. INVITE, except for the fact that processing includes any final
response, not just 200 class.
If the session expires without having seen a response to a re-INVITE, If the session expires without having seen a response to a re-INVITE,
the proxy MAY consider the call leg terminated. This means it MAY the proxy MAY consider the call leg terminated. This means it MAY
flush any state associated with that call leg. flush any state associated with that call leg.
Note that a proxy MUST NOT send a BYE request once the session
expires.
6 UAS Behavior 6 UAS Behavior
When a UAS receives an INVITE for a new call, and that INVITE When a UAS receives an INVITE for a new call, and that INVITE
contains a Session-Expires header, the UAS MUST place a Session- contains a Session-Expires header, the UAS MUST place a Session-
Expires header in a 200 OK response (assuming the UAS accepts the Expires header in a 200 OK response (assuming the UAS accepts the
call). The UAS MAY reduce the expiration time when it places this 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 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 INVITE did not contain a Session-Expires header, but it did contain a
Supported header containing the option tag "timer", the UAS MAY Supported header containing the option tag "timer", the UAS MAY
insert a Session-Expires header into the response. This header MAY insert a Session-Expires header into the response. This header MAY
skipping to change at page 9, line 42 skipping to change at page 11, line 31
If the UAS places a Session-Expires header into the response, and the If the UAS places a Session-Expires header into the response, and the
request contained a Supported header with the value "timer", the UAS request contained a Supported header with the value "timer", the UAS
MUST place a Require header into the response with the value "timer". MUST place a Require header into the response with the value "timer".
In this case, the UAC will generate the refreshes. In this case, the UAC will generate the refreshes.
If the UAS places a Session-Expires header into the response, and the If the UAS places a Session-Expires header into the response, and the
request did not contain a Supported header with the value "timer", request did not contain a Supported header with the value "timer",
the UAS MUST NOT place a Require header into the response with the the UAS MUST NOT place a Require header into the response with the
value "timer". In this case, the UAS will generate the refreshes. value "timer". In this case, the UAS will generate the refreshes.
These cases are summarized in Table 3. The table indicates the
behavior of the UAS, assuming it supports session timers, as a
function of the presence of the headers in the received request.
Supported Session-Expires Behavior
N N No timers. Proceed normally.
N Y Copy Session-Expires to response.
May reduce. UAS refreshing.
Y N MAY add Session-Expires to response.
If added, MUST add Require to response.
UAC refreshing.
Y Y Copy Session-Expires to response.
May reduce. Add Require to response.
UAC refreshing.
Table 3: UAS Behavior
If the UAS is generating refreshes, it computes the expiration time If the UAS is generating refreshes, it computes the expiration time
of the session based on the value of the Session-Expires header in of the session based on the value of the Session-Expires header in
the response it sent. The processing from this point is as described the response it sent. This expiration applies only to the call leg
in section 4 once the UAC determined it was performing refreshses. associated with that final response. The processing from this point
is as described in section 4 once the UAC determined it was
performing refreshes.
As described in Section 4, the refreshing UA will send periodic re- As described in Section 4, the refreshing UA will send periodic re-
INVITEs to refresh the session. A UAS MUST be prepared to receive and INVITEs to refresh the session. A UAS MUST be prepared to receive and
process these re-INVITEs. Processing of the re-INVITE, as far as the process these re-INVITEs. Processing of the re-INVITE, as far as the
session timer is concerned, is identical to the rules for the initial 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 INVITE, described above, except that processing applies to any final
no Session-Expires, no expiration time exists for the session. response, not just 200 OK. Note that if the 200 OK to the re-INVITE
has no Session-Expires, no expiration time exists for the session.
7 Security Considerations 7 Security Considerations
The session timer introduces the capability of a proxy to effectively The session timer introduces the capability of a proxy to effectively
force clients to send refreshes at a rate of the proxies choosing. It 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 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 to times that are too short. This introduces the possibility of rogue
proxies introducing denial-of-service attacks. Use of short refresh proxies introducing denial-of-service attacks. Use of short refresh
intervals allows the proxies to create network load. The session intervals allows the proxies to create network load. The session
timer mechanism allows the proxy to be able to terminate established timer mechanism allows the proxy to be able to terminate established
calls - a capability a normal proxy doesn't have in [1]. calls - a capability a normal proxy doesn't have in [1].
As a result of these potential attacks, it is RECOMMENDED that IP or As a result of these potential attacks, it is RECOMMENDED that IP or
transport level security is used when communicating between proxies. transport level security is used when communicating between proxies,
and that requests with Session-Expires headers only be accepted over
these secure transports.
8 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 timer. In the interest of brevity, all associated with the session timer. In the interest of brevity, all
headers excepting Supported, Session-Expires and Require are headers excepting Supported, Session-Expires and Require are
intentionally left out of the SIP messages. intentionally left out of the SIP messages.
8.1 Basic session-timer setup with UAS detected timeout 8.1 Basic session timer
In this case, two UAs communicate directly, with no proxies. Both
support the session timer. The call is setup with a two minute
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: 120
Calling UA <- Called UA Calling UA <- Called UA
200 OK 200 OK
Require: timer Require: timer
Session-Expires: 120 Called UA starts session timer on send Session-Expires: 120 Called UA starts session timer on send
Calling UA starts session timer on receipt Calling UA starts session timer on receipt
Calling UA -> Called UA Calling UA -> Called UA
ACK ACK
n60 seconds later: 60 seconds later:
Calling UA -> Called UA Calling UA -> Called UA
INVITE INVITE
Supported: timer Supported: timer
Session-Expires: 120 Session-Expires: 120
Calling UA <- Called UA Calling UA <- Called UA
200 OK 200 OK
Require: timer Require: timer
Session-Expires: 120 Called UA starts session timer on send Session-Expires: 120 Called UA starts session timer on send
skipping to change at page 12, line 4 skipping to change at page 14, line 21
Session-Expires: 120 Called UA starts timer Session-Expires: 120 Called UA starts timer
Require: timer Require: timer
Calling UA <- SPS Calling UA <- SPS
200 OK 200 OK
Session-Expires: 120 Proxy starts timer on send Session-Expires: 120 Proxy starts timer on send
Require: timer Calling UA starts timer on receipt Require: timer Calling UA starts timer on receipt
Calling UA -> SPS Calling UA -> SPS
ACK ACK
SPS -> Called UA SPS -> Called UA
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
120 seconds, it sends a BYE. 110 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 in INVITE 8.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 requires 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 -> SPS Calling UA -> SPS
INVITE No Session-Expires INVITE No Session-Expires
Supported: timer Supported: timer
SPS -> Called UA SPS -> Called UA
INVITE INVITE
Supported: timer Supported: timer
Session-Expires: 120 Session-Expires: 120 Proxy added Session-Expires
SPS <- Called UA SPS <- Called UA
200 OK 200 OK
Session-Expires: 120 Session-Expires: 120
Require: timer Require: timer
Calling UA <- SPS Calling UA <- SPS
200 OK 200 OK
Session-Expires: 120 Session-Expires: 120
Require: timer Require: timer
skipping to change at page 13, line 14 skipping to change at page 15, line 32
Calling UA -> SPS Calling UA -> SPS
ACK ACK
SPS -> Called UA SPS -> Called UA
ACK ACK
8.4 Session timer without Calling UA Support 8.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 requires session timer for the call it tag "timer". Since the proxy wants session timer for the call it adds
adds Session-Expires header before proxying the INVITE to the called Session-Expires header before proxying the INVITE to the called UA.
UA.
Calling UA -> SPS Calling UA -> SPS
INVITE INVITE
SPS -> Called UA SPS -> Called UA
INVITE SPS adds session expires INVITE SPS adds session expires
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
skipping to change at page 13, line 39 skipping to change at page 16, line 12
Calling UA <- SPS Calling UA <- SPS
200 OK 200 OK
Session-Expires: 120 Proxy starts timer on send Session-Expires: 120 Proxy starts timer on send
Calling UA -> SPS Calling UA -> SPS
ACK ACK
SPS -> Called UA SPS -> Called UA
ACK ACK
Sixty seconds later: Sixty seconds later, the called UA sends a re-INVITE. Note that the
called UA does support session timer, so it includes a
header{Supported} header in the request. The SPS adds the
Session-Expires and Require headers into the response from the calling
UA.
SPS <- Called UA SPS <- Called UA
INVITE INVITE
Supported: timer Supported: timer
Session-Expires: 120 Session-Expires: 120
Calling UA <- SPS Calling UA <- SPS
INVITE INVITE
Supported: timer Supported: timer
Session-Expires:120 Session-Expires:120
Calling UA -> SPS Calling UA -> SPS
200 OK 200 OK
SPS -> Called UA SPS -> Called UA
Session-Expires: 120
Require: timer
200 OK 200 OK
SPS <- Called UA SPS <- Called UA
ACK ACK
Calling UA <- SPS Calling UA <- SPS
ACK ACK
The Calling UA terminates the session for non timer The Calling UA terminates the session for non timer
related reasons: related reasons:
skipping to change at page 14, line 34 skipping to change at page 17, line 9
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.5 Addition of Session-Expires by UAS 8.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 into the INVITE. session timer, but does not add the Session-Expires header into the
The UAS, however, adds the header. 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
required is for one of the user agents involved in the call leg to
understand the "timer" feature.
Calling UA -> Called UA Calling UA -> SPS
INVITE INVITE
Supported: timer k: timer
Calling UA <- Called UA SPS -> Called UA
INVITE SPS adds S-E header
k: timer
Session-Expires: 180
SPS <- Called UA
200 OK Called UA doesn't understand session timer
Calling UA <- SPS
200 OK 200 OK
Session-Expires: 180 SPS adds Session-Expires and Require
Require: timer Require: timer
Session-Expires: 120 Called UA starts timer on send
Calling UA starts timer on receipt
Calling UA -> Called UA Calling UA -> SPS
ACK ACK
8.6 Session Timer without Called UA Support SPS -> Called UA
ACK
In this scenario, the calling UA indicates that it supports the The UAC then re-invites, which is responded to with a 400 because the
session timer, but does not add the Session-Expires header into the new media streams were rejected. Since this is a re-INVITE, the
INVITE. The proxy adds it, but session timer is not supported by the session is still active, and thus the processing of the response to
UAS. The call is still set up with a session timer, as all that is re-INVITE still occurs in the proxy.
required is for one of the user agents involved in the call leg to
understand the "timer" feature.
Calling UA -> SPS Calling UA -> SPS
INVITE INVITE
k: timer k: timer
Session-Expires: 180 UA asks for specific timer this time
This is not mandatory
SPS -> Called UA SPS -> Called UA
INVITE SPS adds S-E header INVITE SPS adds S-E header
k: timer k: timer
Session-Expires: 180 Session-Expires: 180
SPS <- Called UA SPS <- Called UA
200 OK Called UA doesn't understand session timer 400 Rejected Media Called UA doesn't understand session timer
Calling UA <- SPS Calling UA <- SPS
200 OK 400 Rejected Media
Session-Expires: 180 SPS adds Session-Expires and Require Session-Expires: 180 SPS adds Session-Expires and Require
Require: timer Require: timer
Calling UA -> SPS Calling UA -> SPS
ACK ACK
SPS -> Called UA SPS -> Called UA
ACK ACK
8.7 Proxy insists on session timer 8.6 Proxy insists on session timer
In this scenario, the calling UA does not support the session timer,
but the SPS 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, which
ACKs the request. In this case, the call cannot be established.
Note that proxy insertion of Require is NOT RECOMMENDED.
Calling UA -> SPS Calling UA -> SPS
INVITE INVITE
SPS -> Called UA SPS -> Called UA
INVITE SPS adds session expires INVITE SPS adds session expires
Require: timer SPS adds Require Require: timer SPS adds Require
Session-Expires: 180 Session-Expires: 180
SPS <- Called UA SPS <- Called UA
420 Bad Extension 420 Bad Extension
Unsupported: timer Unsupported: timer
Calling UA <- SPS Calling UA <- SPS
skipping to change at page 16, line 26 skipping to change at page 19, line 23
Calling UA <- SPS Calling UA <- SPS
420 Bad Extension 420 Bad Extension
Unsupported: timer Unsupported: timer
Calling UA -> SPS Calling UA -> SPS
ACK ACK
SPS -> Called UA SPS -> Called UA
ACK ACK
8.8 Neither UA Supports Session Timer 8.7 Neither UA Supports Session Timer
In this case, the proxy does not insist on session timer, so the call In this case, neither UA supports the session timer. However, one of
is set up without it. the proxies on the call setup path requests (but does not require)
it. The call completes without session timers.
Calling UA -> SPS Calling UA -> SPS
INVITE INVITE
SPS -> Called UA SPS -> Called UA
INVITE SPS adds S-E header INVITE SPS adds S-E header
Session-Expires: 180 Session-Expires: 180
SPS <- Called UA SPS <- Called UA
200 OK Called UA doesn't understand session timer 200 OK Called UA doesn't understand session timer
skipping to change at page 17, line 4 skipping to change at page 19, line 44
Session-Expires: 180 Session-Expires: 180
SPS <- Called UA SPS <- Called UA
200 OK Called UA doesn't understand session timer 200 OK Called UA doesn't understand session timer
Calling UA <- SPS SPS doesn't add S-E since it knows Calling UA Calling UA <- SPS SPS doesn't add S-E since it knows Calling UA
200 OK doesn't support it 200 OK doesn't support it
Calling UA -> SPS Calling UA -> SPS
ACK ACK
SPS -> Called UA SPS -> Called UA
ACK ACK
9 Changes since -01 9 Changes since -02
o Added wording indicating that the UAC can add the Require and o Mentioned that having proxies insert Require when the UAC did
Proxy-Require headers with the "timer" header. not insert Supported, is NOT RECOMMENDED.
o Added the ability for proxy to include Session-Timer header o Require insertion of Date header when absolute time is used.
when the UAC did not include the Supported with the "timer"
tag.
o Added the ability for a proxy to insert the Session-Timer o Changed UAS inserting Session-Expires: 0 after crash and
header into a response, in the case where the called UA didn't reboot, from a MAY to a SHOULD.
support session timer, but the calling UA did.
o Added the ability for the called UA to refresh the session o Made 30s the minimum recommended interval.
timer. This is only in the case that the calling UA does not
support the "timer" feature.
o Session-Expires can be present in non-200 OK responses to o Clarified that BYE is sent either 10s before the end of the
reINVITEs sesison, or at 1/3 of the time of the interval, whichever is
less.
o Added wording about getting Session-Expires of zero in non-200 o Fixed example in Section 8.2 to have BYE sent in 110 seconds,
OK response to initial INVITE, handling crash and reboot not 120.
cycles.
o Discuss re-INVITEs changing the role of who is doing o Fixed example in Section 8.4, which was wrong.
refreshes.
o Removed example that was previously Section 8.5, as it was
redundant with Section 8.3.
o Added example of non-200 response to re-invite.
10 Author's Addresses 10 Author's Addresses
Steven R. Donovan Steven R. Donovan
dynamicsoft dynamicsoft
72 Eagle Rock Avenue 5100 Tennyson Parkway, Suite 1200
First Floor Plano, Texas 75024
East Hanover, NJ 07936
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
11 Bibliography 11 Bibliography
skipping to change at page 18, line 33 skipping to change at page 21, line 28
progress. progress.
[5] M. Handley and V. Jacobson, "SDP: session description protocol," [5] M. Handley and V. Jacobson, "SDP: session description protocol,"
Request for Comments 2327, Internet Engineering Task Force, Apr. Request for Comments 2327, Internet Engineering Task Force, Apr.
1998. 1998.
Table of Contents Table of Contents
1 Introduction ........................................ 1 1 Introduction ........................................ 1
2 Protocol Overview ................................... 2 2 Protocol Overview ................................... 2
3 Session-Expires Header Field Definition ............. 4 3 Session-Expires Header Field Definition ............. 5
4 UAC Behavior ........................................ 5 4 UAC Behavior ........................................ 6
5 Proxy Behavior ...................................... 7 5 Proxy Behavior ...................................... 8
6 UAS Behavior ........................................ 9 5.1 Processing of requests .............................. 8
7 Security Considerations ............................. 10 5.2 Processing of Responses ............................. 9
8 Examples ............................................ 10 6 UAS Behavior ........................................ 11
8.1 Basic session-timer setup with UAS detected 7 Security Considerations ............................. 12
timeout ........................................................ 10 8 Examples ............................................ 12
8.2 Basic negotiation of Session Time ................... 11 8.1 Basic session timer ................................. 12
8.3 No Session-Expires Header in INVITE ................. 12 8.2 Basic negotiation of Session Time ................... 13
8.4 Session timer without Calling UA Support ............ 13 8.3 No Session-Expires Header in INVITE ................. 14
8.5 Addition of Session-Expires by UAS .................. 14 8.4 Session timer without Calling UA Support ............ 15
8.6 Session Timer without Called UA Support ............. 15 8.5 Session Timer without Called UA Support ............. 17
8.7 Proxy insists on session timer ...................... 15 8.6 Proxy insists on session timer ...................... 18
8.8 Neither UA Supports Session Timer ................... 16 8.7 Neither UA Supports Session Timer ................... 19
9 Changes since -01 ................................... 17 9 Changes since -02 ................................... 20
10 Author's Addresses .................................. 17 10 Author's Addresses .................................. 20
11 Bibliography ........................................ 18 11 Bibliography ........................................ 20
 End of changes. 

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