draft-ietf-sip-session-timer-07.txt   draft-ietf-sip-session-timer-08.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-07.txt dynamicsoft draft-ietf-sip-session-timer-08.txt dynamicsoft
October 1, 2001 October 6, 2001
Expires: April 2002 Expires: April 2002
The SIP Session Timer The SIP Session Timer
STATUS OF THIS MEMO STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 7, line 39 skipping to change at page 7, line 39
phrase for this code is "Session Timer Too Small". It is generated by phrase for this code is "Session Timer Too Small". It is generated by
a UAS or proxy when a request contains a Session-Expires header with a UAS or proxy when a request contains a Session-Expires header with
a duration that is below the minimum timer for the server. The 422 a duration that is below the minimum timer for the server. The 422
response MUST contain a Min-SE header with the minimum timer for that response MUST contain a Min-SE header with the minimum timer for that
server. server.
7 UAC Behavior 7 UAC Behavior
7.1 Generating an INVITE Request 7.1 Generating an INVITE Request
The rules for an initial INVITE are identical to those for a re-
INVITE. An re-INVITE generated to refresh the session is a normal
re-INVITE. It SHOULD contain SDP that describes the session, even if
that SDP has not changed. In that case, the session description MUST
somehow indicate that it has not changed. In the case of SDP, this is
accomplished by including the same value for the origin field as
previous messages to its peer. The same is true for the 200 class
response to a re-INVITE used solely for refreshing. The response MUST
contain a session description with an indication that it has not
changed. This is accomplished in the same way as for the request.
It is possible for a UAS to believe that an INVITE is an initial
INVITE, and for the UAC to believe it is a re-INVITE. This happens
when a UA crashes and reboots between refreshes. When the refresh
arrives at the rebooted UA, it decides to reject the call (generally,
it will reject the call unless it explicitly is capable of recovering
lost calls). If From tags are used, the UAS can detect that the re-
INVITE is for an existing call by the existence of the tag in the To
field of the re-INVITE. Therefore, a UAC MUST insert a From tag in an
initial INVITE if it supports session timer. A UAS that wishes to
reject a re-INVITE for a call that it believes is already terminated
SHOULD respond with a 481. A UAC receiving a 481 to a session timer
refresh MUST generate a BYE to terminate that call leg.
If From tags were not mandatory, A could INVITE B without a
From tag. B inserts a tag in the 200 OK. Now, B sends a
re-INVITE to A. Meantime, A has crashed and rebooted. This
re-INVITE has a From tag, but no To tag. It therefore
cannot be distinguished for a new INVITE in which the UAC
inserts a From tag. This ambiguity is resolved by mandating
use of From tag with session timer.
The requirement for From tags and responding with a 481 to
stale re-INVITEs has been added to the updated version of
RFC2543. However, to eliminate a dependency between this
spec and the new version of SIP, these two features are
specified here as well.
A UAC which supports the session timer extension defined here MUST A UAC which supports the session timer extension defined here MUST
include a Supported header in each request (except ACK), listing the include a Supported header in each request (except ACK), listing the
option tag "timer" [4]. It MUST do so even if the UAC is not option tag "timer" [4]. It MUST do so even if the UAC is not
requesting keepalives for the call. requesting keepalives for the call.
A UAC MAY include a Session-Expires in an initial INVITE request if
it wishes for a session timer to be applied. The value of this header
indicates session interval desired by the UAC. In an INVITE that is
within a call leg with an active session timer, the header SHOULD be
present, and SHOULD contain the current value of the session
interval.
If the INVITE is a re-INVITE it is RECOMMENDED that the refresher be
set to "uac" if the element sending the INVITE is currently
performing refreshes, else "uas" if its peer is performing the
refreshes. In an initial INVITE, the UAC MAY include the refresher
parameter with value "uac" if it wishes to perform the refreshes. If
the UAC wishes to leave this decision to the negotiation mechanisms
described below, the refresher parameter is omitted.
The UAC MAY include a Require in the request with the value "timer" The UAC MAY include a Require in the request with the value "timer"
to indicate that the UAS must support the session timer to to indicate that the UAS must support the session timer to
participate in the session. This does not mean that the UAC is participate in the session. This does not mean that the UAC is
requiring the UAS to perform the refreshes, just that it is requiring requiring the UAS to perform the refreshes, just that it is requiring
the UAS to support the extension. In addition, the UAC MAY include a the UAS to support the extension. In addition, the UAC MAY include a
Proxy-Require header in the request with the value "timer" to Proxy-Require header in the request with the value "timer" to
indicate that proxies must support session timer in order to indicate that proxies must support session timer in order to
correctly process the request. However, usage of either Require or correctly process the request. However, usage of either Require or
Proxy-Require by the UAC is NOT RECOMMENDED. They are not needed, Proxy-Require by the UAC is NOT RECOMMENDED. They are not needed,
since the extension works even when only the UAC supports the since the extension works even when only the UAC supports the
extension. The Supported header containing "timer" MUST still be extension. The Supported header containing "timer" MUST still be
included even if the Require or Proxy-Require headers are present included even if the Require or Proxy-Require headers are present
containing "timer". containing "timer".
The UAC MUST insert the Min-SE header into an re-INVITE request for a The UAC MUST insert the Min-SE header into a re-INVITE request for a
particular call leg if it has ever received a 422 response to a particular call leg if it has ever received a 422 response to a
previous INVITE on the same leg, or if it has received an INVITE on previous INVITE on the same leg, or if it has received an INVITE on
that call leg which contained a Min-SE header. Similarly, if no call that call leg which contained a Min-SE header. Similarly, if no call
leg has been established yet, a UAC MUST insert the Min-SE header leg has been established yet, a UAC MUST insert the Min-SE header
into an INVITE request for a particular call if it has ever received into an INVITE request for a particular call if it has ever received
a 422 response to a previous INVITE with the same Call-ID. a 422 response to a previous INVITE with the same Call-ID.
The value of the Min-SE header present in the INVITE MUST be the The value of the Min-SE header present in the INVITE MUST be the
largest value amongst all Min-SE values returned in all 422 largest value amongst all Min-SE values returned in all 422
responses, or received in INVITE requests, on the same call leg, if a responses, or received in INVITE requests, on the same call leg, if a
call leg has been established. If no leg is established, the Min-SE call leg has been established. If no leg is established, the Min-SE
header is set to the largest value amongst all Min-SE values returned header is set to the largest value amongst all Min-SE values returned
in all 422 responses for the same call. A result of this rule is that in all 422 responses for the same call. A result of this rule is that
the maximum value of the Min-SE is effectively "cleared" once the the maximum value of the Min-SE is effectively "cleared" once the
call leg is established, and from that point on, only the values from call leg is established, and from that point on, only the values from
proxies known to be on the proxy path are used. If the UAC inserts a proxies known to be on the proxy path will end up being used.
Session-Expires into an INVITE, it MUST have a value greater than or
equal to the value placed into the Min-SE header, if present. The UAC may have its own opinions about the minimum session interval.
In that case, if the value above is too small, the UAC MAY increase
it.
A UAC MAY include a Session-Expires in an initial INVITE request if
it wishes for a session timer to be applied. The value of this header
indicates session interval desired by the UAC. In an INVITE that is
within a call leg with an active session timer, the header SHOULD be
present, and SHOULD contain the the larger of the current value of
the session interval and the value of the Min-SE, if present.
If the INVITE is a re-INVITE it is RECOMMENDED that the refresher be
set to "uac" if the element sending the INVITE is currently
performing refreshes, else "uas" if its peer is performing the
refreshes. In an initial INVITE, the UAC MAY include the refresher
parameter with value "uac" if it wishes to perform the refreshes. If
the UAC wishes to leave this decision to the negotiation mechanisms
described below, the refresher parameter is omitted.
A re-INVITE generated to refresh the session is a normal re-INVITE.
It SHOULD contain SDP that describes the session, even if that SDP
has not changed. In that case, the session description MUST somehow
indicate that it has not changed. In the case of SDP, this is
accomplished by including the same value for the origin field as
previous messages to its peer. The same is true for the 200 class
response to a re-INVITE used solely for refreshing. The response MUST
contain a session description with an indication that it has not
changed. This is accomplished in the same way as for the request.
It is possible for a UAS to believe that an INVITE is an initial
INVITE, and for the UAC to believe it is a re-INVITE. This happens
when a UA crashes and reboots between refreshes. When the refresh
arrives at the rebooted UA, it decides to reject the call (generally,
it will reject the call unless it explicitly is capable of recovering
lost calls). If From tags are used, the UAS can detect that the re-
INVITE is for an existing call by the existence of the tag in the To
field of the re-INVITE. Therefore, a UAC MUST insert a From tag in an
initial INVITE if it supports session timer. A UAS that wishes to
reject a re-INVITE for a call that it believes is already terminated
SHOULD respond with a 481. A UAC receiving a 481 to a session timer
refresh MUST generate a BYE to terminate that call leg.
If From tags were not mandatory, A could INVITE B without a
From tag. B inserts a tag in the 200 OK. Now, B sends a
re-INVITE to A. Meantime, A has crashed and rebooted. This
re-INVITE has a From tag, but no To tag. It therefore
cannot be distinguished for a new INVITE in which the UAC
inserts a From tag. This ambiguity is resolved by mandating
use of From tag with session timer.
The requirement for From tags and responding with a 481 to
stale re-INVITEs has been added to the updated version of
RFC2543. However, to eliminate a dependency between this
spec and the new version of SIP, these two features are
specified here as well.
7.1.1 Example 7.1.1 Example
As an example, a UAC sends an INVITE with Call-ID 1, and receives a As an example, a UAC sends an INVITE with Call-ID 1, and receives a
422 with a Min-SE header of 100. There is a tag in the To field, with 422 with a Min-SE header of 100. There is a tag in the To field, with
a value of 8. The UAC retries the request. It contains a Min-SE a value of 8. The UAC retries the request. It contains a Min-SE
header. Since no call leg has been established, the Min-SE header header. Since no call leg has been established, the Min-SE header
contains the largest value amongst all Min-SE values returned in 422 contains the largest value amongst all Min-SE values returned in 422
responses to INVITEs with the same Call-ID, in this case, with the responses to INVITEs with the same Call-ID, in this case, with the
Call-ID of 1. There has only been one such 422, and it had a Min-SE Call-ID of 1. There has only been one such 422, and it had a Min-SE
skipping to change at page 15, line 46 skipping to change at page 15, line 46
last 2xx INVITE response on that leg plus the session interval for last 2xx INVITE response on that leg plus the session interval for
that leg. If UA wishes to continue with the session beyond the that leg. If UA wishes to continue with the session beyond the
session expiration, it MUST generate a refresh before the session session expiration, it MUST generate a refresh before the session
expiration. It is RECOMMENDED that this refresh be sent once half the expiration. It is RECOMMENDED that this refresh be sent once half the
session interval has elapsed. Additional procedures for this refresh session interval has elapsed. Additional procedures for this refresh
are described in Section 10. are described in Section 10.
10 Performing Refreshes 10 Performing Refreshes
The side generating a refresh does so according to the UAC procedures The side generating a refresh does so according to the UAC procedures
defined in Section 7. defined in Section 7. Note that only a 2xx response to the INVITE
extends the session expiration. This means that a UA could attempt a
refresh, and receive a 422 with a Min-SE that contains a value much
larger than the current session interval. The UA will still need to
send an INVITE before the session expiration (which has not changed),
even though this INVITE will contain a value of the Session-Expires
that is much larger than the current session interval.
If no response to a refreshing re-INVITE is received before the If no response to a refreshing re-INVITE is received before the
session expiration, the UA SHOULD send a BYE request to terminate the session expiration, the UA SHOULD send a BYE request to terminate the
call. It SHOULD send this BYE slightly before session expiration. The call. It SHOULD send this BYE slightly before session expiration. The
minimum of ten seconds and one third the session interval is minimum of ten seconds and one third the session interval is
RECOMMENDED. RECOMMENDED.
For example, if the session interval is 120 seconds, one For example, if the session interval is 120 seconds, one
third of this is 40 seconds. Since the minimum of 10 third of this is 40 seconds. Since the minimum of 10
seconds and 40 seconds is 10 seconds, the BYE would be sent seconds and 40 seconds is 10 seconds, the BYE would be sent
skipping to change at page 28, line 5 skipping to change at page 28, line 11
8.2 Processing of Responses ............................. 13 8.2 Processing of Responses ............................. 13
8.3 Session Expiration .................................. 14 8.3 Session Expiration .................................. 14
9 UAS Behavior ........................................ 14 9 UAS Behavior ........................................ 14
10 Performing Refreshes ................................ 15 10 Performing Refreshes ................................ 15
11 Security Considerations ............................. 16 11 Security Considerations ............................. 16
12 Examples ............................................ 17 12 Examples ............................................ 17
12.1 Basic session timer ................................. 17 12.1 Basic session timer ................................. 17
12.2 Basic negotiation of Session Time ................... 18 12.2 Basic negotiation of Session Time ................... 18
12.3 No Session-Expires Header in INVITE ................. 19 12.3 No Session-Expires Header in INVITE ................. 19
12.4 Session timer without Calling UA Support ............ 20 12.4 Session timer without Calling UA Support ............ 20
12.5 Session Timer without Called UA Support ............. 21 12.5 Session Timer without Called UA Support ............. 22
12.6 Neither UA Supports Session Timer ................... 23 12.6 Neither UA Supports Session Timer ................... 23
12.7 Both UAs Support, Change in Roles ................... 23 12.7 Both UAs Support, Change in Roles ................... 24
12.8 Proxy Rejects Timer ................................. 25 12.8 Proxy Rejects Timer ................................. 25
13 Acknowledgements .................................... 26 13 Acknowledgements .................................... 26
14 Author's Addresses .................................. 26 14 Author's Addresses .................................. 26
15 Bibliography ........................................ 27 15 Bibliography ........................................ 27
 End of changes. 

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