draft-ietf-sip-update-01.txt   draft-ietf-sip-update-02.txt 
Internet Engineering Task Force SIP WG Internet Engineering Task Force SIP WG
Internet Draft J. Rosenberg Internet Draft J. Rosenberg
dynamicsoft dynamicsoft
draft-ietf-sip-update-01.txt draft-ietf-sip-update-02.txt
March 1, 2002 April 30, 2002
Expires: September 2002 Expires: October 2002
The SIP UPDATE Method The Session Initiation Protocol UPDATE Method
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
To view the list Internet-Draft Shadow Directories, see To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This specification defines the new UPDATE method for the Session This specification defines the new UPDATE method for the Session
Initiation Protocol (SIP). UPDATE allows a client to update Initiation Protocol (SIP). UPDATE allows a client to update
parameters of a session (such as the set of media streams and their parameters of a session (such as the set of media streams and their
codecs), or update SIP level information (such as credentials), but codecs) but has no impact on the state of a dialog. In that sense, it
has no impact on the state of a dialog. This is very useful for is like a re-INVITE, but can be sent before the initial INVITE has
updating information about a call before the call has been accepted. completed. This makes it very useful for updating session parameters
within early dialogs.
Table of Contents Table of Contents
1 Introduction ........................................ 3 1 Introduction ........................................ 3
2 Terminology ......................................... 4 2 Terminology ......................................... 3
3 Definitions ......................................... 4 3 Overview of Operation ............................... 3
4 Overview of Operation ............................... 4 4 Determining Support for this Extension .............. 4
5 UA Behavior ......................................... 5 5 UPDATE Handling ..................................... 4
5.1 Initiating a Dialog ................................. 5 5.1 Sending an UPDATE ................................... 4
5.2 Generating a Provisional Response ................... 5 5.2 Receiving an UPDATE ................................. 6
5.2.1 Requesting an Update ................................ 6 5.3 Processing the UPDATE Response ...................... 6
5.2.2 Continuing With the Dialog .......................... 6 6 Proxy Behavior ...................................... 7
5.3 Processing Provisional Responses .................... 6 7 Definition of the UPDATE method ..................... 7
5.3.1 Processing the 155 .................................. 7 8 Example Call Flow ................................... 7
6 UPDATE Handling ..................................... 8 9 Security Considerations ............................. 11
6.1 Sending an UPDATE ................................... 8 10 IANA Considerations ................................. 11
6.1.1 Specifics for INVITE ................................ 8 11 Acknowledgements .................................... 11
6.1.2 Specifics for SUBSCRIBE ............................. 9 12 Author's Addresses .................................. 11
6.2 Receiving an UPDATE ................................. 9 13 Normative References ................................ 11
6.2.1 Specifics for INVITE ................................ 10 14 Informative References .............................. 12
6.2.2 Specifics for SUBSCRIBE ............................. 11
7 Proxy Behavior ...................................... 11
8 Definition of the UPDATE method ..................... 11
9 Definition of the 155 (Update Requested) Response
................................................................ 13
10 Example Call Flow ................................... 13
11 Security Considerations ............................. 14
12 IANA Considerations ................................. 14
12.1 update Option Tag ................................... 14
12.2 UPDATE Request Method ............................... 14
12.3 155 Response Code ................................... 16
13 Acknowledgements .................................... 16
14 Author's Addresses .................................. 16
15 Normative References ................................ 16
16 Informative References .............................. 17
1 Introduction 1 Introduction
(Note to RFC Editor: replace all instances of BBBB in this (Note to RFC Editor: replace all instances of BBBB in this
specification with the RFC number of draft-ietf-sip-rfc2543bis, all specification with the RFC number of draft-ietf-sip-rfc2543bis, all
all instances of OOOO with the RFC number of draft-ietf-mmusic-sdp- all instances of OOOO with the RFC number of draft-ietf-mmusic-sdp-
offer-answer) offer-answer)
The Session Initiation Protocol (SIP) [2] defines the INVITE method The Session Initiation Protocol (SIP) [1] defines the INVITE method
for the initiation and modification of sessions. However, this method for the initiation and modification of sessions. However, this method
actually affects two important pieces of state. It impacts the actually affects two important pieces of state. It impacts the
session (the media streams SIP sets up) and also the dialog (the session (the media streams SIP sets up) and also the dialog (the
state that SIP itself defines). While this is reasonable in many state that SIP itself defines). While this is reasonable in many
cases, there are important scenarios where it this coupling causes cases, there are important scenarios where this coupling causes
complications. complications.
The primary difficulty is when aspects of the session need to be The primary difficulty is when aspects of the session need to be
modified before the initial INVITE has been answered. An example of modified before the initial INVITE has been answered. An example of
this situation is "early media", a condition where the session is this situation is "early media", a condition where the session is
established, for the purpose of conveying progress of the call, established, for the purpose of conveying progress of the call, but
before the INVITE itself is accepted. It is important to be able to before the INVITE itself is accepted. It is important that either
modify the characteristics of that session (putting the early media caller or callee be able to modify the characteristics of that
on hold, for example), before the call is answered. However, a re- session (putting the early media on hold, for example), before the
INVITE cannot be used for this purpose, because the re-INVITE has an call is answered. However, a re-INVITE cannot be used for this
impact on the state of the dialog, in addition to the session. purpose, because the re-INVITE has an impact on the state of the
dialog, in addition to the session.
Another difficulty is when an INVITE is rejected, not because the
call is declined, but because some aspect of the request was not
acceptable, and a proxy on the call path was attempting to provide a
service that requires forking. That rejection won't be forwarded
upstream by the proxy unless all other branches reject the request.
That may never happen. The result is that the caller never has an
opportunity to update its request to make it acceptable to the
rejecting party. Even if the rejection is passed upstream
immediately, there can be problems. The rejection of the INVITE will
trigger the caller to try again, resulting in a re-invocation of the
forking service at the proxy. That re-invocation will frequently
result in undesirable side-effects. These two problems have been
referred to by the SIP community as the "Heterogeneous Error Response
Forking Problem", or HERFP.
In both cases, a solution is needed that allows the caller to provide As a result, a solution is needed that allows the caller or callee to
updated information to the recipients of the request, before a final provide updated session information before a final response to the
response to the initial request is generated. The UPDATE method, initial INVITE request is generated. The UPDATE method, defined here,
defined here, fulfills that need. It can be sent by a UA within a fulfills that need. It can be sent by a UA within a dialog (early or
dialog (early or confirmed), to update either session parameters or confirmed), to update either session parameters without impacting the
SIP information, without impacting the dialog state itself. This dialog state itself.
specification also defines the 155 (Update Requested) response, which
can be used by the UAS to inform the UAC of a condition that prevents
it from processing the request, but which can be corrected with an
UPDATE.
2 Terminology 2 Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and and "OPTIONAL" are to be interpreted as described in RFC 2119 [2] and
indicate requirement levels for compliant SIP implementations. indicate requirement levels for compliant SIP implementations.
3 Definitions 3 Overview of Operation
Repairable Error Response: An error response in the 4xx class
which indicates that the request was unacceptable for some
reason which can be repaired by automated processing at the
UAC. For the 4xx response codes defined in RFC BBBB [2],
this includes the 401, 415, 416, 420, 423 and 488
responses. However, SIP extensions can define additional
error codes with this property, and those are covered by
this specification.
4 Overview of Operation
When a UAC sends an INVITE, it includes a Supported tag in the
request that contains the option tag "update". This option tag
indicates that the UAC understands the mechanisms defined in this
specification. When the UAS gets that request, it performs the
processing defined in Section 8.2 of RFC BBBB [2]. This processing
may determine that the request is acceptable, and therefore the user
is alerted (or some other appropriate action is taken), or the
processing may determine that the request cannot be processed further
without some kind of change.
In the former case, the UAS generates a reliable provisional response
[3]. The provisional response establishes an early dialog. It
contains an Allow header listing the methods supported by the server.
Among them will be the UPDATE method. At any time thereafter, the UAC
can generate an UPDATE method that contains an SDP offer [4] for the
purposes of updating the session. The response to the UPDATE method
contains the answer. Similarly, the callee can send an UPDATE with an
offer, and the caller places its answer in the 2xx. The UPDATE method
can also update other information provided in previous requests, such
as a new Call-Info or Alert-Info header.
In the latter case, the request might be unacceptable because it does
not contain proper credentials, contains content not understood by
the UAS, requests service on a URI with a scheme not supported by the
server, mandates an extension not supported by the UAS, requests a
creation of soft state with a refresh interval that is too brief, or
contains a session description that is not acceptable. Rather than
rejecting the request with a 401, 415, 416, 420, 423 or 488 response,
respectively (these response codes are referred to as repairable
error responses), the UAS can choose to generate a 155 (Update
Requested) reliable provisional response. This response is formatted
identically to the way the 401, 415, 416, 420, 423 or 488 would be
formatted, with the exception of the status line. When this is
received by the UAC, the UAC generates an UPDATE request to "correct"
whatever problem was reported by the 155 response. Such a request
might include credentials, omit bodies not acceptable to the UAS, or
not mandate an extension not supported by the UAS. When the UAS
receives this request, it processes it much like it would a re-
INVITE, except that the UPDATE request is answered immediately if
acceptable, and the response to the original INVITE is not sent until
the call is explicitly answered or rejected.
The usage of the 155, instead of rejecting the request, is not needed
unless there is a proxy upstream performing a forking application.
Therefore, in order to know whether to send a 155 or a final
response, the proxy can insert a Require header field into the
request with a value of update, before proxying it. This informs the
UAS that it should send a 155 instead of a repairable error response.
5 UA Behavior
5.1 Initiating a Dialog
A UAC compliant to this specification SHOULD include a Supported
header field in all requests it sends that can initiate a dialog
(including INVITE and SUBSCRIBE [5]), with the option tag "update".
This indicates the ability to process the 155 response properly. The
UA SHOULD also include an Allow header field in the request,
including the method UPDATE, to indicate its ability to receive an
UPDATE request.
The UAC MAY include a Require header in the request, with the option
tag "update", if it insists that the UAS generate a 155 response code
instead of an error response for all repairable error responses.
5.2 Generating a Provisional Response
When a UAS compliant to this specification receives a request that
can initiate a dialog, the procedures in this section are followed.
The request is processed according to the rules in Section 8.2 of RFC
BBBB. If the request contains a Supported header field with the
option tag of "update", and the guidelines in Section 8.2 of RFC BBBB
would result in the generation of a repairable error response, the
processing in Section 5.2.1 is performed instead of sending the error
response.
If, on the other hand, the processing of Section 8.2 of RFC BBBB
indicates that the request is generally acceptable, the procedures of
Section 5.2.2 are followed.
5.2.1 Requesting an Update
Instead of generating the repairable error response, a UAS MAY
generate a 155 (Update Requested) response. If the request contains a
Require header with the value of "update", the UAS MUST generate the
155 (Update Requested) instead of the repairable error response.
The 155 is generated exactly as the corresponding repairable error
response would be generated. The only difference is that the status
line has the response code of 155. The UAC will be able to infer the
particular reason for rejection from the headers in the response.
The 155 response MUST contain the Require header, with the value of
"update".
The 155 response MUST be sent reliably, using the reliability of
provisional responses extension to SIP [3].
Once the response is sent, the UAS starts a timer. The timer SHOULD
be equal to at least T1*64 seconds (T1 is defined in Section 17.1.1.1
of RFC BBBB [2]. This timer indicates how long the UAS is willing to
wait for the update before terminating the transaction. During this
time, the UAS MUST NOT perform application layer processing of the
request (alert the user, send media, etc.). Processing of the request
is effectively suspended. However, the UAS MUST still process a
CANCEL request for that transaction, should one arrive. If the timer
fires before receipt of an UPDATE request on the dialog, the UAS MUST
generate the repairable error response. If an UPDATE is received
before the timer fires, processing continues in Section 6.2.
5.2.2 Continuing With the Dialog
If the request was acceptable, the UAS MAY generate a provisional
response. That response SHOULD contain an Allow header field that
includes the UPDATE method. This informs the caller that the callee
is capable of receiving an UPDATE request at any time.
5.3 Processing Provisional Responses
If the UAC receives a provisional response with a tag in the To
field, and that response contains a Supported header with the value
of "update", or the response is a 155, the UAC MUST create an early
dialog.
Creation of early dialogs is a MAY in RFC BBBB. This
extension increases the strength to MUST. This is necessary
to receive incoming UPDATE requests from the callee.
If the response is a 155, the UAC follows the processing of Section
5.3.1. Otherwise, the response is processed normally. The requestor
can generate an UPDATE request within the dialog, as described in
Section 6.1.
5.3.1 Processing the 155
The 155 provisional response indicates to the UAC that the request it
generated was not acceptable, and that a modification of the request
in some way may make the request acceptable. That modification is
performed with an UPDATE request, sent as a mid-dialog request.
Additional processing beyond that specified in Section 12.2.1 of RFC
BBBB [2] is applied as described below.
If the 155 response contains a WWW-Authenticate header, the UAC
SHOULD include an Authorization header in the UPDATE with a response
to the challenge. The Authorization header is constructed as
described in Section 22 of RFC BBBB.
If the 155 response contains an Accept header field, the UAC MAY
include a body in the UPDATE. That body MUST be with one of the types
listed in the Accept header field of the 155. Similarly, if the 155
contains an Accept-Encoding header field, the UAC MAY apply an
encoding to any bodies in the request, but MUST only apply encodings
listed in the Accept-Encoding header field of the 155. Finally, if
the 155 contains an Accept-Language header field, the UAC MAY place a
body into the request, but it MUST be in a language listed in the
Accept-Language header field of the 155.
If the 155 response contains a Unsupported header, the UAC MUST NOT
include a Require header in the UPDATE listing any option tags
present in the Unsupported header from the 155.
If the 155 response contains a description of media capabilities in Operation of this extension is straigthforward. The caller begins
the body (for example, an SDP formatted according to Section 9 of RFC with an INVITE transaction, which proceeds normally. Once a dialog is
OOOO [4]), the UAC MUST include a new offer in the UPDATE. This will established, either early or confirmed, the caller can generate an
be the case when the repairable error response was 488. UPDATE method that contains an SDP offer [3] for the purposes of
updating the session. The response to the UPDATE method contains the
answer. Similarly, once a dialog is established, the callee can send
an UPDATE with an offer, and the caller places its answer in the 2xx
to the UPDATE. The Allow header is used to indicate support for the
UPDATE method. There are additional constraints on when UPDATE can be
used, based on the restrictions of the offer/answer model.
If the 155 response contains a Min-Expires header, the UAC MUST NOT 4 Determining Support for this Extension
include a Expires header or parameter in the UPDATE with a value less
than the value in the Min-Expires header.
It is possible that the request was not acceptable, but repairable, The initiation of a session operates as specified in RFC BBBB [1].
for some reason which cannot be ascertained from headers in the 155. However, a UAC compliant to this specification SHOULD also include an
A proxy MAY use other means to make such a determination. For Allow header field in the request, listing the method UPDATE, to
example, if a future extension defined a header which conveyed a indicate its ability to receive an UPDATE request.
reason code in the 155, that could be used.
The UAC MAY add any other optional headers for the UPDATE request, as When a UAS compliant to this specification receives an INVITE request
defined in Tables 1 and 2. for a new dialog, and generates a reliable provisional response
containing SDP, that response SHOULD contain an Allow header field
that lists the UPDATE method. This informs the caller that the callee
is capable of receiving an UPDATE request at any time. An unreliable
provisional response MAY contain an Allow header listing the UPDATE
method, and a 2xx response SHOULD contain an Allow header listing the
UPDATE method.
The offer/answer rules in RFC BBBB apply to the UPDATE request. Responses are processed normally as per RFC BBBB [1], and in the case
Specifically, the UPDATE can only contain an offer if there are no of reliable provisional responses, according to [4]. It is important
outstanding offers. Since the 155 effectively rejects the offer, the to note that a reliable provisional response will always create an
UPDATE can contain a new offer. early dialog at the UAC. Creation of this dialog is necessary in
order to receive UPDATE creates from the callee.
The UPDATE request is then sent according to the procedures of If the response contains an Allow header containing the value
Section 12.2.1 of RFC BBBB. "UPDATE", the UAC knows that the callee supports UPDATE, and the UAC
is allowed to follow the procedures of Section 5.1.
6 UPDATE Handling 5 UPDATE Handling
6.1 Sending an UPDATE 5.1 Sending an UPDATE
The UPDATE request is constructed as would any other request within The UPDATE request is constructed as would any other request within
an existing dialog, as described in Section 12.2.1 of RFC BBBB. It an existing dialog, as described in Section 12.2.1 of RFC BBBB. It
MAY be sent for both early and confirmed dialogs. MAY be sent for both early and confirmed dialogs. Although UPDATE can
be used on confirmed dialogs, it is RECOMMENDED that a re-INVITE be
used instead. This is because an UPDATE needs to be answered
immediately, ruling out the possibility of user approval. Such
approval will frequently needed, and is possible with a re-INVITE.
6.1.1 Specifics for INVITE The UAC MAY add optional headers for the UPDATE request, as defined
in Tables 1 and 2.
In the case of INVITE, the UPDATE request can contain an offer, and The rules for inclusion of offers and answers in SIP messages as
the response to the UPDATE would contain the answer. Of course, the defined in Section 13.2.1 of RFC BBBB still apply. These rules exist
rules for inclusion of offers and answers in SIP messages as defined to guarantee a consistent view of the session state. This means that,
in Section 13.2.1 of RFC BBBB still apply. Typically, this means for the caller:
that, for the caller:
o If the UPDATE is being sent before completion of the initial o If the UPDATE is being sent before completion of the initial
INVITE transaction, and the initial INVITE contained an offer, INVITE transaction, and the initial INVITE contained an offer,
the UPDATE can contain an offer if: the UPDATE can contain an offer if the callee generated an
answer in a reliable provisional response, and the caller has
- The callee rejected the offer by sending a 155 with a received answers to any other offers it sent in either PRACK
description of capabilities in the body, OR or UPDATE, and has generated answers for any offers it
received in an UPDATE from the callee.
- The callee generated an answer in a reliable provisional
response, and the UAC has received answers to any other
offers it sent in either PRACK or UPDATE, and has generated
answers for any offers it received in an UPDATE from the
callee.
o If the UPDATE is being sent before completion of the initial o If the UPDATE is being sent before completion of the initial
INVITE transaction, and the initial INVITE did not contain an INVITE transaction, and the initial INVITE did not contain an
offer, the UPDATE can contain an offer if the callee generated offer, the UPDATE can contain an offer if the callee generated
an offer in a reliable provisional response, and the UAC an offer in a reliable provisional response, and the UAC
generated an answer in the corresponding PRACK. Of course, it generated an answer in the corresponding PRACK. Of course, it
can't send an UPDATE if it has not received answers to any can't send an UPDATE if it has not received answers to any
other offers it sent in either PRACK or UPDATE, or has not other offers it sent in either PRACK or UPDATE, or has not
generated answers for any other offers it received in an generated answers for any other offers it received in an
UPDATE from the callee. UPDATE from the callee.
skipping to change at page 9, line 25 skipping to change at page 5, line 35
o If the UPDATE is being sent after the completion of the o If the UPDATE is being sent after the completion of the
initial INVITE transaction, it cannot be sent if the caller initial INVITE transaction, it cannot be sent if the caller
has generated or received offers in a re-INVITE or UPDATE has generated or received offers in a re-INVITE or UPDATE
which have not been answered. which have not been answered.
and for the callee: and for the callee:
o If the UPDATE is being sent before the completion of the o If the UPDATE is being sent before the completion of the
INVITE transaction, and the initial INVITE contained an offer, INVITE transaction, and the initial INVITE contained an offer,
the UPDATE cannot be sent unless the callee has generated an the UPDATE cannot be sent unless the callee has generated an
answer in a reliable provisional response, and has not sent or answer in a reliable provisional response, has received a
received other UPDATE requests containing offers that have not PRACK for that reliable provisional response, has not received
been answered. any requests (PRACK or UPDATE) with offers that it has not
answered, and has not sent any UPDATE requests containing
offers that have not been answered.
o If the UPDATE is being sent before completion of the INVITE o If the UPDATE is being sent before completion of the INVITE
transaction, and the initial INVITE did not contain an offer, transaction, and the initial INVITE did not contain an offer,
the UPDATE can contain an offer unless the callee has sent or the UPDATE cannot be sent unless the callee has sent an offer
received other UPDATE requests containing offers that have not in a reliable provisional response, received an answer in a
been answered. PRACK, and has not received any UPDATE requests with offers
that it has not answered, and has not sent any UPDATE requests
containing offers that have not been answered.
o If the UPDATE is being sent after the completion of the o If the UPDATE is being sent after the completion of the
initial INVITE transaction, it cannot be sent if the callee initial INVITE transaction, it cannot be sent if the callee
has generated or received offers in a re-INVITE or UPDATE has generated or received offers in a re-INVITE or UPDATE
which have not been answered. which have not been answered.
If the response to the UPDATE is a 491, the UAC SHOULD follow the 5.2 Receiving an UPDATE
processing in Section 4.1 of RFC BBBB for 491 processing, except that
the UPDATE is retried on expiration of the timer, rather than a re-
INVITE.
6.1.2 Specifics for SUBSCRIBE
An UPDATE request MUST NOT be sent for SUBSCRIBE unless a SUBSCRIBE
request has generated a 155 response.
6.2 Receiving an UPDATE
If an UPDATE is received which does not match an existing dialog, it
MUST be rejected with a 481 response.
When a UAS receives an UPDATE request, it is being asked to update The UPDATE is processed as any other mid-dialog request, as described
aspects of the session or other application state, but not the dialog in Section 12.2.2 of RFC BBBB [1]. If the request is generally
state itself (which will either be early or confirmed). The UPDATE acceptable, processing continues as described below. This processing
request is a target refresh request. is nearly identical to that of Section 14.2 of RFC BBBB [1],
generalized for the case of UPDATE.
If the UPDATE matches an existing dialog, it is processed as would A UAS that receives an UPDATE before it has generated a final
any mid-dialog request, as per Section 12.2.2 of RFC BBBB. response to a previous UPDATE or INVITE on the same dialog MUST
Furthermore, its processing then follows the method-specific behavior return a 500 response to the new UPDATE, and MUST include a Retry-
as if the UPDATE had the same method as the request which created the After field with a Retry-After header field with a randomly chosen
dialog. However, the response to UPDATE does not result in a change value between 0 and 10 seconds.
to the dialog state (i.e., it does not change it from early to
confirmed). Furthermore, in many cases, the session or other
application state is also confirmed when the dialog is established.
The response to UPDATE does not cause such confirmation either. In
the case of INVITE, for example, a 2xx response to an initial INVITE
confirms the setup of the call, but a 2xx response to UPDATE does
not. As such, an UPDATE MUST generate an immediate final response.
If the UPDATE is received after processing of the original request If an UPDATE is received that contains an offer, and the UAS has
was suspended because a 155 was generated, processing continues as if generated an offer (in an UPDATE, PRACK or INVITE) to which it has
the repairable error response had actually been sent, and, as above, not yet received an answer, the UAS MUST reject the UPDATE with a 491
the UPDATE was the same method as that request. However, as described response.
above, the final response to UPDATE does not change the state of the
dialog, nor does it confirm any application state, and therefore,
SHOULD generate a 2xx response immediately once it passes the
processing steps in Section 12.2.2 of RFC BBBB. Once the application
determines what the response to request would have been, for example,
an acceptance of the call, the original request is responded to with
that response code.
6.2.1 Specifics for INVITE If a UA receives an UPDATE for an existing dialog, it MUST check any
version identifiers in the session description or, if there are no
version identifiers, the content of the session description to see if
it has changed. If the session description has changed, the UAS MUST
adjust the session parameters accordingly and generate an answer in
the 2xx response. However, unlike a re-INVITE, the UPDATE MUST be
responded to promptly, and therefore the user cannot generally be
prompted to approve the session changes. If the UAS cannot change the
session parameters without prompting the user, it SHOULD reject the
request with a 504 response. If the new session description is not
acceptable, the UAS can reject it by returning a 488 (Not Acceptable
Here) response for the UPDATE. This response SHOULD include a Warning
header field.
If the UPDATE is received by the UAS, and it had previously sent a 5.3 Processing the UPDATE Response
155, the UPDATE is processed like a re-INVITE. Assuming the steps of
Section 14.2 of RFC BBBB pass, the UPDATE SHOULD be responded to with
a 2xx response, and then the processing of the original request
continues, as if the original request were the same as the UPDATE
(excepting the method, of course). This means that the callee is
alerted, for example, or media can begin to be sent. The original
request can be rejected, of course, if a call screening application
decides that the caller is on the block list.
Of course, if the UPDATE itself is not acceptable (for example, Processing of the UPDATE response at the UAC is nearly identical to
invalid credentials), it MAY be rejeced with the appropriate error the rules in Section 14.1 of RFC BBBB [1], but generalized for
response. A 155 response to the UPDATE MUST NOT be sent. UPDATE.
If an UPDATE is received that contains an offer, and the UAS has If a UA receives a non-2xx final response to a UPDATE, the session
generated an offer (presumably in an UPDATE of its own) to which it parameters MUST remain unchanged, as if no UPDATE had been issued.
has not yet received an answer, the UAS MUST reject the UPDATE with a Note that, as stated in Section 12.2.1 of RFC BBBB [1], if the non-
491 response. 2xx final response is a 481 (Call/Transaction Does Not Exist), or a
408 (Request Timeout), or no response at all is received for the
UPDATE (that is, a timeout is returned by the UPDATE client
transaction), the UAC will terminate the dialog.
6.2.2 Specifics for SUBSCRIBE If a UAC receives a 491 response to a UPDATE, it SHOULD start a timer
with a value T chosen as follows:
If an UPDATE is received before the original SUBSCRIBE is responded 1. If the UAC is the owner of the Call-ID of the dialog ID
to (which should only occur if a 155 is sent), the UPDATE is (meaning it generated the value), T has a randomly chosen
processed as if it were a new SUBSCRIBE refresh. Specifically, the value between 2.1 and 4 seconds in units of 10 ms.
expiration, acceptable notification formats (from the Accept,
Accept-Encoding and Accept-Language headers), and body information
are used for the subscription. The UPDATE generates an immediate 2xx
response as long as those parameters are acceptable. Once the status
of the subscription itself is determined, the original SUBSCRIBE is
responded to. For example, if the status is pending, a 202 would be
sent to the SUBSCRIBE.
7 Proxy Behavior 2. If the UAC is not the owner of the Call-ID of the dialog
ID, T has a randomly chosen value of between 0 and 2
seconds in units of 10 ms.
If a proxy receives a request with a Supported header containing the When the timer fires, the UAC SHOULD attempt the UPDATE once more, if
option tag "update", and the proxy knows it is going to fork the it still desires for that session modification to take place. For
request, either in parallel or in serial, it SHOULD add a Require example, if the call was already hung up with a BYE, the UPDATE would
header to all proxied requests with the option tag "update" if such a not take place.
header is not already present.
For each request which generates a 420 response containing the 6 Proxy Behavior
Unsupported header with the value of "update", the proxy MUST
generate another branch to the same destination, this time, without
the Require header added in.
This behavior helps ensure that forking applications work properly, Proxy processing of the UPDATE request is identical to any other
but also provides for backwards compatibility with endpoints which do non-INVITE request.
not support this extension.
8 Definition of the UPDATE method 7 Definition of the UPDATE method
The semantics of the UPDATE method are described in detail above. The semantics of the UPDATE method are described in detail above.
This extension adds another value to the Method BNF described in RFC This extension adds another value to the Method BNF described in RFC
BBBB: BBBB:
UPDATEm = %x55.50.44.41.54.45 ; UPDATE in caps UPDATEm = %x55.50.44.41.54.45 ; UPDATE in caps
Method = INVITEm / ACKm / OPTIONSm / BYEm Method = INVITEm / ACKm / OPTIONSm / BYEm
/ CANCELm / REGISTERm / UPDATEm / CANCELm / REGISTERm / UPDATEm
/ extension-method / extension-method
The following extends Table 2 of RFC BBBB for the UPDATE method:
Table 1 extends Table 2 of RFC BBBB for the UPDATE method.
Table 2 updates Table 3 of RFC BBBB for the UPDATE method.
8 Example Call Flow
This section presents an example call flow using the UPDATE method.
The flow is shown in Figure 1. The caller sends an initial INVITE (1)
which contains an offer. The callee generates a 180 response (2) with
an answer to that offer. With the completion of an offer/answer
Header field where proxy UPDATE Header field where proxy UPDATE
____________________________________________ ____________________________________________
Accept R o Accept R o
Accept 2xx o Accept 2xx o
Accept 415 o Accept 415 c
Accept-Encoding R o Accept-Encoding R o
Accept-Encoding 2xx o Accept-Encoding 2xx o
Accept-Encoding 415 o Accept-Encoding 415 c
Accept-Language R o Accept-Language R o
Accept-Language 2xx o Accept-Language 2xx o
Accept-Language 415 o Accept-Language 415 c
Alert-Info R am o Alert-Info -
Alert-Info 180 am o
Allow R o Allow R o
Allow 2xx o Allow 2xx o
Allow r o Allow r o
Allow 405 o Allow 405 m
Allow-Events (1) -
Authentication-Info 2xx o Authentication-Info 2xx o
Authorization R o Authorization R o
Call-ID c r m Call-ID c r m
Call-Info am o Call-Info ar o
Contact R o Contact R m
Contact 1xx o Contact 1xx o
Contact 2xx o Contact 2xx m
Contact 3xx o Contact 3xx d o
Contact 485 o Contact 485 o
Content-Disposition o Content-Disposition o
Content-Encoding o Content-Encoding o
Content-Language o Content-Language o
Content-Length r t Content-Length ar t
Content-Type * Content-Type *
CSeq c r m CSeq c r m
Date a o Date a o
Error-Info 300-699 o Error-Info 300-699 a o
Expires o Event (1) -
Expires -
From c r m From c r m
In-Reply-To R o In-Reply-To -
Max-Forwards R amr m Max-Forwards R amr m
Min-Expires 423 o Min-Expires -
MIME-Version o MIME-Version o
Organization am o Organization ar o
Table 1: Summary of header fields, A--O
The following extends Table 3 of RFC BBBB for UPDATE:
Table 1: Summary of header fields, A--O ; (1) defined in [5],
Header field where proxy UPDATE Header field where proxy UPDATE
____________________________________________________ ____________________________________________________
Priority R a o Priority -
Proxy-Authenticate 407 m Proxy-Authenticate 407 ar m
Proxy-Authorization R r o Proxy-Authenticate 401 ar o
Proxy-Require R acr o Proxy-Authorization R dr o
Proxy-Require R ar o
RAck R - RAck R -
Record-Route R amr o Record-Route R ar o
Record-Route 2xx,401,484 o Record-Route 2xx,18x mr o
Reply-To o Reply-To -
Require acr o Require ar c
Retry-After 404,413,480,486 o Retry-After 404,413,480,486 o
500,503 o 500,503 o
600,603 o 600,603 o
Route R r c Route R adr c
RSeq 1xx o RSeq - -
Server r o Server r o
Subject R o Subject - -
Subscription-State (1) -
Supported R o Supported R o
Supported 2xx o Supported 2xx o
Timestamp o Timestamp o
To c(1) r m To c r m
Unsupported 420 o Unsupported 420 m
User-Agent o User-Agent o
Via c acmr m Via R amr m
Via rc dr m
Warning r o Warning r o
WWW-Authenticate 401 m WWW-Authenticate 401 ar m
WWW-Authenticate 407 ar o
Table 2: Summary of header fields, P--Z; (1): copied with possible
addition of tag
9 Definition of the 155 (Update Requested) Response
The semantics of the 155 (Update Requested) response code are defined
above. The default reason phrase is "Update Requested".
10 Example Call Flow Table 2: Summary of header fields, P--Z
This section presents an example call flow using the UPDATE method.
The flow is shown in Figure 1. The caller sends an initial INVITE (1)
which contains an offer. The callee generates a 180 response (2) with
an answer to that offer. With the completion of an offer/answer
exchange, the session is established, although the dialog is still in exchange, the session is established, although the dialog is still in
the early state. The caller generates a PRACK (3) to acknowledge the the early state. The caller generates a PRACK (3) to acknowledge the
180, and the PRACK is answered with a 200 OK (4). The caller decides 180, and the PRACK is answered with a 200 OK (4). The caller decides
to update some aspect of the session - to put it on hold, for to update some aspect of the session - to put it on hold, for
example. So, they generate an UPDATE request (5) with a new offer. example. So, they generate an UPDATE request (5) with a new offer.
This offer is answered in the 200 response to the UPDATE (6). Shortly This offer is answered in the 200 response to the UPDATE (6). Shortly
thereafter, the callee decides to update some aspect of the session, thereafter, the callee decides to update some aspect of the session,
so it generates an UPDATE request (7) with an offer, and the answer so it generates an UPDATE request (7) with an offer, and the answer
is sent in the 200 response (8). Finally, the callee answers the is sent in the 200 response (8). Finally, the callee answers the
call, resulting in a 200 OK response to the INVITE (9), and then an call, resulting in a 200 OK response to the INVITE (9), and then an
ACK (10). Neither the 200 OK to the INVITE, nor the ACK, will contain ACK (10). Neither the 200 OK to the INVITE, nor the ACK, will contain
SDP. SDP.
11 Security Considerations
This specification describes a condition under which a UAS would
receive a request that is unauthenticated, and maintain state for
processing that request, for a duration of 32 seconds. This
introduces a potential denial-of-service attack. Implementations
SHOULD restrict the number of transactions which are pending with a
155 to a small number. Subsequent unauthenticated requests SHOULD
then be rejected with a 401, even if a Require header is present with
the option tag "update".
These guidelines imply that the usage of 155 for unauthenticated
requests is useful primarily for single user devices, which typically
have only a few transactions outstanding a time in general.
12 IANA Considerations
This document serves as a registration of the update option tag, the
UPDATE request method, and the 155 response code.
12.1 update Option Tag
As per Section 27.1 of RFC BBBB [2], this specification serves as a
registration for the SIP option tag "update". The information to be
added to the registry is:
Name of the Option Tag: The name of the option tag is "update".
Descriptive Text: Support for the update extension implies the
ability to generate and receive a 155 (Update Requested)
provisional response as an alternative to sending an
equivalent repairable error response.
12.2 UPDATE Request Method
As per Section 27.4 of RFC BBBB [2], this specification serves as a
Caller Callee Caller Callee
| | | |
| | | |
|(1) INVITE with offer 1 | |(1) INVITE with offer 1 |
|---------------------------->| |---------------------------->|
| | | |
| | | |
|(2) 180 with answer 1 | |(2) 180 with answer 1 |
|<----------------------------| |<----------------------------|
| | | |
skipping to change at page 16, line 4 skipping to change at page 11, line 4
| | | |
| | | |
|(10) ACK | |(10) ACK |
|---------------------------->| |---------------------------->|
| | | |
| | | |
| | | |
| | | |
Figure 1: UPDATE Call Flow Figure 1: UPDATE Call Flow
registration for the SIP UPDATE request method. The information to be
added to the registry is:
RFC Number: This specification serves as the RFC for registering 9 Security Considerations
the UPDATE request method.
Method Name: UPDATE
Reason Phrase: Not applicable. The security considerations for UPDATE are identical to those for
re-INVITE. It is important that the UPDATE be integrity protected and
authenticated as coming from the same source as the entity on the
other end of the dialog. RFC BBBB [1] discusses security mechanisms
for achieving these functions.
12.3 155 Response Code 10 IANA Considerations
As per Section 27.4 of RFC BBBB [2], this specification serves as a As per Section 27.4 of RFC BBBB [1], this specification serves as a
registration for the SIP UPDATE request method. The information to be registration for the SIP UPDATE request method. The information to be
added to the registry is: added to the registry is:
RFC Number: This specification serves as the RFC for registering RFC Number: This specification serves as the RFC for registering
the 155 response code. the UPDATE request method.
Response Code: 155 Method Name: UPDATE
Default Reason Phrase: Update Requested Reason Phrase: Not applicable.
13 Acknowledgements 11 Acknowledgements
The author would like to thank Rohan Mahy and Markus Isomaki for The author would like to thank Jo Hornsby, Markus Isomaki, Rohan
their comments. Mahy, and Bob Penfield for their comments.
14 Author's Addresses 12 Author's Addresses
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
15 Normative References 13 Normative References
[1] S. Bradner, "Key words for use in RFCs to indicate requirement
levels," Request for Comments 2119, Internet Engineering Task Force,
Mar. 1997.
[2] J. Rosenberg, H. Schulzrinne, et al. , "SIP: Session initiation [1] J. Rosenberg, H. Schulzrinne, et al. , "SIP: Session initiation
protocol," Internet Draft, Internet Engineering Task Force, Feb. protocol," Internet Draft, Internet Engineering Task Force, Feb.
2002. Work in progress. 2002. Work in progress.
[3] J. Rosenberg and H. Schulzrinne, "Reliability of provisional [2] S. Bradner, "Key words for use in RFCs to indicate requirement
responses in SIP," Internet Draft, Internet Engineering Task Force, levels," RFC 2119, Internet Engineering Task Force, Mar. 1997.
Feb. 2002. Work in progress.
[4] J. Rosenberg and H. Schulzrinne, "An offer/answer model with [3] J. Rosenberg and H. Schulzrinne, "An offer/answer model with
SDP," Internet Draft, Internet Engineering Task Force, Feb. 2002. SDP," Internet Draft, Internet Engineering Task Force, Feb. 2002.
Work in progress. Work in progress.
[5] A. Roach et al. , "SIP-specific event notification," Internet [4] J. Rosenberg and H. Schulzrinne, "Reliability of provisional
Draft, Internet Engineering Task Force, Feb. 2002. Work in progress. responses in SIP," Internet Draft, Internet Engineering Task Force,
Feb. 2002. Work in progress.
16 Informative References [5] A. Roach, "SIP-specific event notification," Internet Draft,
Internet Engineering Task Force, Mar. 2002. Work in progress.
14 Informative References
Full Copyright Statement Full Copyright Statement
Copyright (c) The Internet Society (2002). All Rights Reserved. Copyright (c) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
skipping to change at line 778 skipping to change at page 12, line 43
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
 End of changes. 

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