draft-ietf-sip-session-timer-03.txt   draft-ietf-sip-session-timer-04.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-03.txt dynamicsoft draft-ietf-sip-session-timer-04.txt dynamicsoft
October 30, 2000 November 22, 2000
Expires: April 2001 Expires: May 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 4, line 32 skipping to change at page 4, line 32
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 UAS 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.
If the response contains no Session-Expires header or Require header,
but the UAC had inserted a Session-Expires header into the request
(since it wanted a session timer), the UAC will also be responsible
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, excepting that processing may also take place of the initial INVITE, excepting that processing may also take place
for non-200 final responses. for non-200 final responses.
skipping to change at page 5, line 42 skipping to change at page 5, line 46
devices that do not have access to absolute time. devices that do not have access to absolute time.
There is no absolute minimum session refresh interval. However, 30 There is no absolute minimum session refresh interval. However, 30
seconds is RECOMMENDED. In other words, SIP entites MUST be prepared seconds is RECOMMENDED. In other words, SIP entites MUST be prepared
to handle session refresh intervals of any duration, but entities to handle session refresh intervals of any duration, but entities
that insert the Session-Expires header SHOULD NOT choose times that that insert the Session-Expires header SHOULD NOT choose times that
result in intervals less than 30 seconds. 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" | "x") ":" ( SIP-date |
delta-seconds ) delta-seconds )
Note that a compact form, the letter 'x', has been reserved for
Both SIP-Date and delta-seconds are defined in Section 6.20 of RFC Session-Expires. Both SIP-Date and delta-seconds are defined in
2543 [1]. Section 6.20 of RFC 2543 [1].
Table 1 is an extension of tables 4 and 5 in [1] for the Session- Table 1 is an extension of tables 4 and 5 in [1] for the Session-
Expires header: Expires header:
where enc e-e ACK BYE CAN INV OPT REG where enc e-e ACK BYE CAN INV OPT REG
_____________________________________________________ _____________________________________________________
Session-Expires R n h - - - o - - Session-Expires R n h - - - o - -
Session-Expires r n h - - - o - - Session-Expires r n h - - - o - -
Table 1: Summary of header fields. "o": optional "-": not applicable, Table 1: Summary of header fields. "o": optional "-": not applicable,
skipping to change at page 7, line 6 skipping to change at page 7, line 11
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 2 describes the behavior of the UAC (in terms of handling Table 2 describes the behavior of the UAC (in terms of handling
refreshes) after receiving a 200 class response to an initial 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 or any final response to a re-INVITE, based on the headers present in
that response. that response.
Require Session-Expires Behavior Require Session-Expires Behavior
N N Do nothing. N N If request contained Session-Expires,
UAC is performing refreshes. Otherwise, do nothing.
N Y UAS is performing refreshes. 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 MUST perform refreshes. Y Y UAC MUST perform refreshes.
Table 2: UAC Behavior 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. This is based on the
contains an absolute time, that is the time of expiration. If it value of the Session-Expires in the response. If there is no
contains a delta-time, the expiration time is the time of reception Session-Expires in the response, but the UAC is refreshing, the value
of the response plus that delta time. Let the difference in time from the request is used (this only happens when the UAC wants
between the reception of the response and the session expiration time session timers, but none of the proxies, nor the UAS, want or support
be called the refresh interval. Note that this expiration applies it). If the Session-Expires contains an absolute time, that is the
only to the call leg associated with the response. It is explicitly time of expiration. If it contains a delta-time, the expiration time
allowed for there to be differing session timers (or none at all) on is the time of reception of the response plus that delta time. Let
differing call legs, in the case where there are multiple 2xx OK the difference in time between the reception of the response and the
responses to an initial INVITE with different tags in the To field. session expiration time be called the refresh interval. Note that
this expiration applies only to the call leg associated with the
response. It is explicitly allowed for there to be differing session
timers (or none at all) on differing call legs, in the case where
there are multiple 2xx OK responses to an initial INVITE with
different tags in the To field.
If UA wishes to continue with the session beyond the expiration, it 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 excepting that the processing applies to non-200 final responses, as
well as 200 class final responses. well as 200 class final responses.
skipping to change at page 8, line 23 skipping to change at page 8, line 34
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 refreshes. 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 during a call. responsibility for generating refreshes may change during a call.
This happens commonly in one specific case - both caller and callee
support session timer. The caller will be doing re-INVITEs initially.
If the callee re-INVITEs, it becomes the UAC for this transaction,
and the rules defined in this specification will result in a change
in refresh responsibility to the called party. In general, when both
parties support session timer, refreshes become the responsibility of
the party which performed the last INVITE transaction.
Note that it is possible for a UAS to believe that an INVITE is an Note that 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 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 happens when a UA crashes and reboots between refreshes. When the
refresh arrives at the rebooted UA, it decides to reject the call. refresh arrives at the rebooted UA, it decides to reject the call.
The UAS can detect that the re-INVITE is for an existing call by the 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. In order to existence of the tag in the To field of the re-INVITE. In order to
alert the UAC that it believes the call is now down (the UAC believes alert the UAC that it believes the call is now down (the UAC believes
this request to be a re-INVITE, and so a non-200 OK final response this request to be a re-INVITE, and so a non-200 OK final response
will not cause it to destroy the call), the UAS SHOULD include a will not cause it to destroy the call), the UAS SHOULD include a
Session-Expires and Require into the non-200 response (assuming Session-Expires and Require into the non-200 response (assuming
session timer is supported by the UAC), with an immediate expiration session timer is supported by the UAC), with an immediate expiration
time. 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. In general, proxies which ask for session timers will
record-route, since they won't receive refreshes if they don't.
The proxy processing rules require the proxy to remember The proxy processing rules require the proxy to remember
information between the request and response, ruling out information between the request and response, ruling out
stateless proxies. stateless proxies.
5.1 Processing of requests 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.
skipping to change at page 9, line 31 skipping to change at page 10, line 4
If the request did not contain a Supported header with the value If the request did not contain a Supported header with the value
"timer", the proxy MAY insert a Require header into the request, with "timer", the proxy MAY insert a Require header into the request, with
the value "timer". However, this is NOT RECOMMENDED. This allows the the value "timer". However, this is NOT RECOMMENDED. This allows the
proxy to insist on session timer for the session. This header is not proxy to insist on session timer for the session. This header is not
needed if a Supported header was in the request; in this case, the needed if a Supported header was in the request; in this case, the
proxy can already be sure that the session timer can be used for the proxy can already be sure that the session timer can be used for the
session. session.
5.2 Processing of Responses 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. There are four cases. proxy. There are four cases.
CASE I: UAC supports, UAS doesn't. In this case, the proxy CASE I: UAC supports, UAS doesn't. In this case, the request
remembers that it inserted a Session-Expires header into forwarded by the proxy contained a Session-Expires header
the request, and that the UAC supported session timer. (possibly inserted by the proxy). Recall that all proxies
However, the final response does not contain s Session- interested in session timer MUST remember the value of the
timer in the forwarded request, in addition to whether the
UAC supports it. Handling of the response for this scenario
depends on whether the session timer aware proxy is the one
closest to the UAS. For the proxy closest to the UAS, the
final response to the INVITE does not contain a Session-
Expires header, nor does it contain a Require header with Expires header, nor does it contain a Require header with
the option tag "timer". In this case, the proxy is the the option tag "timer". The proxy MUST insert a Session-
closest proxy to the UAS that requested session timer. The Expires header into the response with the value it
proxy MUST insert a Session-Expires header into the remembered from the forwarded request. The proxy MUST also
response with the value it remembered placing into the insert the Require header into the response, with the value
forwarded request. The proxy MUST also insert the Require "timer", before forwarding it upstream. The value of the
header into the response, with the value "timer", before Session-Expires in the forwarded response represents the
forwarding it upstream. The value of the Session-Expires in expiration time of the session. For other proxies, the
the forwarded response represents the expiration time of response will already contain the Session-Expires and
the session. Require header, so that this cae is indistinguishable from
CASE IV.
CASE II: UAC doesn't support, UAS doesn't support. In this case, CASE II: UAC doesn't support, UAS doesn't support. In this case,
the final response has no Session-Expires header, and the the final response has no Session-Expires header, and the
proxy remembers that the UAC did not support the session proxy remembers that the UAC did not support the session
timer. The proxy forwards the response upstream normally. timer. The proxy forwards the response upstream normally.
There are no session timers for this call leg. There are no session timers for this call leg.
CASE III: UAS supports, UAC doesn't. In this case, the final CASE III: UAS supports, UAC doesn't. In this case, the final
response contains a Session-Expires header, but no Require response contains a Session-Expires header, but no Require
header with the tag "timer". The proxy remembers that the header with the tag "timer". The proxy remembers that the
skipping to change at page 11, line 36 skipping to change at page 12, line 15
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 These cases are summarized in Table 3. The table indicates the
behavior of the UAS, assuming it supports session timers, as a behavior of the UAS, assuming it supports session timers, as a
function of the presence of the headers in the received request. function of the presence of the headers in the received request.
Supported Session-Expires Behavior Supported Session-Expires Behavior
N N No timers. Proceed normally. N N If response contains Session-Expires, UAS refreshing.
Otherwise, do nothing.
N Y Copy Session-Expires to response. N Y Copy Session-Expires to response.
May reduce. UAS refreshing. May reduce. UAS refreshing.
Y N MAY add Session-Expires to response. Y N MAY add Session-Expires to response.
If added, MUST add Require to response. If added, MUST add Require to response.
UAC refreshing. UAC refreshing.
Y Y Copy Session-Expires to response. Y Y Copy Session-Expires to response.
May reduce. Add Require to response. May reduce. Add Require to response.
UAC refreshing. UAC refreshing.
Table 3: UAS Behavior Table 3: UAS Behavior
skipping to change at page 12, line 17 skipping to change at page 12, line 42
is as described in section 4 once the UAC determined it was is as described in section 4 once the UAC determined it was
performing refreshes. 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, except that processing applies to any final INVITE, described above, except that processing applies to any final
response, not just 200 OK. Note that if the 200 OK to the re-INVITE 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. has no Session-Expires, no expiration time exists for the session.
This can happen if the proxies and/or UAS change their mind about
session timers, and decide they no longer wish to use them. Since
each INVITE is treated independently, the proxies or UAS do not need
to continue requesting session timer event though they did so the
first time.
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
skipping to change at page 18, line 13 skipping to change at page 18, line 40
session is still active, and thus the processing of the response to session is still active, and thus the processing of the response to
re-INVITE still occurs in the proxy. re-INVITE still occurs in the proxy.
Calling UA -> SPS Calling UA -> SPS
INVITE INVITE
k: timer k: timer
Session-Expires: 180 UA asks for specific timer this time Session-Expires: 180 UA asks for specific timer this time
This is not mandatory This is not mandatory
SPS -> Called UA SPS -> Called UA
INVITE SPS adds S-E header INVITE SPS does not reduce Session-Expires header
k: timer k: timer
Session-Expires: 180 Session-Expires: 180
SPS <- Called UA SPS <- Called UA
400 Rejected Media Called UA doesn't understand session timer 400 Rejected Media Called UA doesn't understand session timer
Calling UA <- SPS Calling UA <- SPS
400 Rejected Media 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
skipping to change at page 18, line 37 skipping to change at page 19, line 20
SPS -> Called UA SPS -> Called UA
ACK ACK
8.6 Proxy insists on session timer 8.6 Proxy insists on session timer
In this scenario, the calling UA does not support the 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 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 header. The UAS does not support the session timer either, so it
rejects the request with a 420 as per standard RFC2543 extension rejects the request with a 420 as per standard RFC2543 extension
handling. This response is forwarded upstream towards the UAC, which handling. This response is forwarded upstream towards the UAC. The
ACKs the request. In this case, the call cannot be established. UAC treats it as a normal 400 class response, and then ACKs it. In
this case, the call cannot be established.
It is slightly odd that a UAC will send a request without a
Require header, and yet get a 420 response back with an
Unsupported header. Normal UAs that don't support session
timer should handle this case correctly, treating it just
as a normal 400 class response.
Note that proxy insertion of Require is NOT RECOMMENDED. 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 19, line 33 skipping to change at page 20, line 23
8.7 Neither UA Supports Session Timer 8.7 Neither UA Supports Session Timer
In this case, neither UA supports the session timer. However, one of In this case, neither UA supports the session timer. However, one of
the proxies on the call setup path requests (but does not require) the proxies on the call setup path requests (but does not require)
it. The call completes without session timers. it. The call completes without session timers.
Calling UA -> SPS Calling UA -> SPS
INVITE INVITE
SPS -> Called UA SPS -> Called UA
INVITE SPS adds S-E header INVITE SPS adds S-E header compact form
Session-Expires: 180 x: 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 -02 8.8 Both UAs Support, Change in Roles
o Mentioned that having proxies insert Require when the UAC did In this case, both user agents support session timer. The initial
not insert Supported, is NOT RECOMMENDED. INVITE from caller to callee results in refreshes being generated by
the caller. A re-INVITE sent from the callee changes that role so
that the callee refreshes.
o Require insertion of Date header when absolute time is used. Calling UA -> SPS
INVITE
Supported: timer
Session-Expires: 240
o Changed UAS inserting Session-Expires: 0 after crash and SPS -> Called UA
reboot, from a MAY to a SHOULD. INVITE SPS wants timer, no change in value
Supported: timer
Session-Expires: 240
o Made 30s the minimum recommended interval. SPS <- Called UA
200 OK Called UA supports timer
Session-Expires: 240 Inserts Require, Session-Expires
Require: timer
o Clarified that BYE is sent either 10s before the end of the Calling UA <- SPS Calling UA gets response with Require:timer
sesison, or at 1/3 of the time of the interval, whichever is 200 OK It is refreshing
less. Session-Expires: 240
Require: timer
o Fixed example in Section 8.2 to have BYE sent in 110 seconds, Calling UA -> SPS
not 120. ACK
o Fixed example in Section 8.4, which was wrong. SPS -> Called UA
ACK
o Removed example that was previously Section 8.5, as it was The called UA (which is a UAC for this transaction) now sends a re-
redundant with Section 8.3. INVITE:
o Added example of non-200 response to re-invite. SPS <- Called UA
INVITE
Supported: timer
Session-Expires: 240
Calling UA <- SPS
INVITE SPS wants timer, no change in value
Supported: timer
Session-Expires: 240
Calling UA -> SPS
200 OK Calling UA supports timer
Session-Expires: 240 Inserts Require, Session-Expires
Require: timer
SPS -> Called UA Called UA gets response with Require:timer
200 OK It is refreshing
Session-Expires: 240
Require: timer
SPS <- Called UA
ACK
Calling UA <- SPS
ACK
9 Changes since -03
o Now handle the case where the UAC wants refreshes, but none of
the proxies, nor the UAS, support it. Same in the reverse -
case where UAS wants it, but the UAC nor any of the proxies
want it.
o Added note about proxy insertion of Require resulting in a 420
even though UAC didn't ask for any extensions.
o Added compact form
o Specified conditions under which refresh responsibilities
change. Also added an example showing this case.
10 Author's Addresses 10 Author's Addresses
Steven R. Donovan Steven R. Donovan
dynamicsoft dynamicsoft
5100 Tennyson Parkway, Suite 1200 5100 Tennyson Parkway, Suite 1200
Plano, Texas 75024 Plano, Texas 75024
email: sdonovan@dynamicsoft.com email: sdonovan@dynamicsoft.com
Jonathan Rosenberg Jonathan Rosenberg
skipping to change at page 21, line 30 skipping to change at page 23, line 33
[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 ............. 5 3 Session-Expires Header Field Definition ............. 5
4 UAC Behavior ........................................ 6 4 UAC Behavior ........................................ 6
5 Proxy Behavior ...................................... 8 5 Proxy Behavior ...................................... 9
5.1 Processing of requests .............................. 8 5.1 Processing of requests .............................. 9
5.2 Processing of Responses ............................. 9 5.2 Processing of Responses ............................. 9
6 UAS Behavior ........................................ 11 6 UAS Behavior ........................................ 11
7 Security Considerations ............................. 12 7 Security Considerations ............................. 12
8 Examples ............................................ 12 8 Examples ............................................ 13
8.1 Basic session timer ................................. 12 8.1 Basic session timer ................................. 13
8.2 Basic negotiation of Session Time ................... 13 8.2 Basic negotiation of Session Time ................... 14
8.3 No Session-Expires Header in INVITE ................. 14 8.3 No Session-Expires Header in INVITE ................. 15
8.4 Session timer without Calling UA Support ............ 15 8.4 Session timer without Calling UA Support ............ 16
8.5 Session Timer without Called UA Support ............. 17 8.5 Session Timer without Called UA Support ............. 17
8.6 Proxy insists on session timer ...................... 18 8.6 Proxy insists on session timer ...................... 19
8.7 Neither UA Supports Session Timer ................... 19 8.7 Neither UA Supports Session Timer ................... 20
9 Changes since -02 ................................... 20 8.8 Both UAs Support, Change in Roles ................... 20
10 Author's Addresses .................................. 20 9 Changes since -03 ................................... 22
11 Bibliography ........................................ 20 10 Author's Addresses .................................. 22
11 Bibliography ........................................ 23
 End of changes. 

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