draft-ietf-sip-update-02.txt   rfc3311.txt 
Internet Engineering Task Force SIP WG Network Working Group J. Rosenberg
Internet Draft J. Rosenberg Request for Comments: 3311 dynamicsoft
dynamicsoft Category: Standards Track September 2002
draft-ietf-sip-update-02.txt
April 30, 2002
Expires: October 2002
The Session Initiation Protocol UPDATE Method
STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with The Session Initiation Protocol (SIP) UPDATE Method
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Status of this Memo
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months This document specifies an Internet standards track protocol for the
and may be updated, replaced, or obsoleted by other documents at any Internet community, and requests discussion and suggestions for
time. It is inappropriate to use Internet-Drafts as reference improvements. Please refer to the current edition of the "Internet
material or to cite them other than as "work in progress". Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt
To view the list Internet-Draft Shadow Directories, see Copyright (C) The Internet Society (2002). All Rights Reserved.
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) but has no impact on the state of a dialog. In that sense, it codecs) but has no impact on the state of a dialog. In that sense,
is like a re-INVITE, but can be sent before the initial INVITE has it is like a re-INVITE, but unlike re-INVITE, it can be sent before
completed. This makes it very useful for updating session parameters the initial INVITE has been completed. This makes it very useful for
within early dialogs. updating session parameters within early dialogs.
Table of Contents Table of Contents
1 Introduction ........................................ 3 1 Introduction .............................................. 2
2 Terminology ......................................... 3 2 Terminology ............................................... 3
3 Overview of Operation ............................... 3 3 Overview of Operation ..................................... 3
4 Determining Support for this Extension .............. 4 4 Determining Support for this Extension .................... 3
5 UPDATE Handling ..................................... 4 5 UPDATE Handling ........................................... 4
5.1 Sending an UPDATE ................................... 4 5.1 Sending an UPDATE ......................................... 4
5.2 Receiving an UPDATE ................................. 6 5.2 Receiving an UPDATE ....................................... 5
5.3 Processing the UPDATE Response ...................... 6 5.3 Processing the UPDATE Response ............................ 6
6 Proxy Behavior ...................................... 7 6 Proxy Behavior ............................................ 7
7 Definition of the UPDATE method ..................... 7 7 Definition of the UPDATE method ........................... 7
8 Example Call Flow ................................... 7 8 Example Call Flow ......................................... 7
9 Security Considerations ............................. 11 9 Security Considerations ................................... 11
10 IANA Considerations ................................. 11 10 IANA Considerations ....................................... 11
11 Acknowledgements .................................... 11 11 Notice Regarding Intellectual Property Rights ............. 11
12 Author's Addresses .................................. 11 12 Normative References ...................................... 11
13 Normative References ................................ 11 13 Acknowledgements .......................................... 12
14 Informative References .............................. 12 14 Author's Address .......................................... 12
15 Full Copyright Statement .................................. 13
1 Introduction 1 Introduction
(Note to RFC Editor: replace all instances of BBBB in this
specification with the RFC number of draft-ietf-sip-rfc2543bis, all
all instances of OOOO with the RFC number of draft-ietf-mmusic-sdp-
offer-answer)
The Session Initiation Protocol (SIP) [1] 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
actually affects two important pieces of state. It impacts the method actually affects two important pieces of state. It impacts
session (the media streams SIP sets up) and also the dialog (the 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 this coupling causes cases, there are important scenarios in which 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, but established, for the purpose of conveying progress of the call, but
before the INVITE itself is accepted. It is important that either before the INVITE itself is accepted. It is important that either
caller or callee be able to modify the characteristics of that caller or callee be able to modify the characteristics of that
session (putting the early media on hold, for example), before the session (putting the early media on hold, for example), before the
call is answered. However, a re-INVITE cannot be used for this call is answered. However, a re-INVITE cannot be used for this
purpose, because the re-INVITE has an impact on the state of the purpose, because the re-INVITE has an impact on the state of the
dialog, in addition to the session. dialog, in addition to the session.
As a result, a solution is needed that allows the caller or callee to As a result, a solution is needed that allows the caller or callee to
provide updated session information before a final response to the provide updated session information before a final response to the
initial INVITE request is generated. The UPDATE method, defined here, initial INVITE request is generated. The UPDATE method, defined
fulfills that need. It can be sent by a UA within a dialog (early or here, fulfills that need. It can be sent by a UA within a dialog
confirmed), to update either session parameters without impacting the (early or confirmed) to update session parameters without impacting
dialog state itself. the dialog state itself.
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 [2] and and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
indicate requirement levels for compliant SIP implementations. [2] and indicate requirement levels for compliant SIP
implementations.
3 Overview of Operation 3 Overview of Operation
Operation of this extension is straigthforward. The caller begins Operation of this extension is straightforward. The caller begins
with an INVITE transaction, which proceeds normally. Once a dialog is with an INVITE transaction, which proceeds normally. Once a dialog
established, either early or confirmed, the caller can generate an is established, either early or confirmed, the caller can generate an
UPDATE method that contains an SDP offer [3] for the purposes of UPDATE method that contains an SDP offer [3] for the purposes of
updating the session. The response to the UPDATE method contains the updating the session. The response to the UPDATE method contains the
answer. Similarly, once a dialog is established, the callee can send 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 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 to the UPDATE. The Allow header field is used to indicate support
UPDATE method. There are additional constraints on when UPDATE can be for the UPDATE method. There are additional constraints on when
used, based on the restrictions of the offer/answer model. UPDATE can be used, based on the restrictions of the offer/answer
model.
4 Determining Support for this Extension 4 Determining Support for this Extension
The initiation of a session operates as specified in RFC BBBB [1]. The initiation of a session operates as specified in RFC 3261 [1].
However, a UAC compliant to this specification SHOULD also include an However, a UAC compliant to this specification SHOULD also include an
Allow header field in the request, listing the method UPDATE, to Allow header field in the INVITE request, listing the method UPDATE,
indicate its ability to receive an UPDATE request. to indicate its ability to receive an UPDATE request.
When a UAS compliant to this specification receives an INVITE request When a UAS compliant to this specification receives an INVITE request
for a new dialog, and generates a reliable provisional response for a new dialog, and generates a reliable provisional response
containing SDP, that response SHOULD contain an Allow header field containing SDP, that response SHOULD contain an Allow header field
that lists the UPDATE method. This informs the caller that the callee that lists the UPDATE method. This informs the caller that the
is capable of receiving an UPDATE request at any time. An unreliable callee is capable of receiving an UPDATE request at any time. An
provisional response MAY contain an Allow header listing the UPDATE unreliable provisional response MAY contain an Allow header field
method, and a 2xx response SHOULD contain an Allow header listing the listing the UPDATE method, and a 2xx response SHOULD contain an Allow
UPDATE method. header field listing the UPDATE method.
Responses are processed normally as per RFC BBBB [1], and in the case Responses are processed normally as per RFC 3261 [1], and in the case
of reliable provisional responses, according to [4]. It is important of reliable provisional responses, according to [4]. It is important
to note that a reliable provisional response will always create an to note that a reliable provisional response will always create an
early dialog at the UAC. Creation of this dialog is necessary in early dialog at the UAC. Creation of this dialog is necessary in
order to receive UPDATE creates from the callee. order to receive UPDATE requests from the callee.
If the response contains an Allow header containing the value If the response contains an Allow header field containing the value
"UPDATE", the UAC knows that the callee supports UPDATE, and the UAC "UPDATE", the UAC knows that the callee supports UPDATE, and the UAC
is allowed to follow the procedures of Section 5.1. is allowed to follow the procedures of Section 5.1.
5 UPDATE Handling 5 UPDATE Handling
5.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 3261. It
MAY be sent for both early and confirmed dialogs. Although UPDATE can MAY be sent for both early and confirmed dialogs, and MAY be sent by
be used on confirmed dialogs, it is RECOMMENDED that a re-INVITE be either caller or callee. Although UPDATE can be used on confirmed
used instead. This is because an UPDATE needs to be answered dialogs, it is RECOMMENDED that a re-INVITE be used instead. This is
immediately, ruling out the possibility of user approval. Such because an UPDATE needs to be answered immediately, ruling out the
approval will frequently needed, and is possible with a re-INVITE. possibility of user approval. Such approval will frequently be
needed, and is possible with a re-INVITE.
The UAC MAY add optional headers for the UPDATE request, as defined The UAC MAY add optional headers for the UPDATE request, as defined
in Tables 1 and 2. in Tables 1 and 2.
UPDATE is a target refresh request. As specified in RFC 3261 [1],
this means that it can update the remote target of a dialog. If a UA
uses an UPDATE request or response to modify the remote target while
an INVITE transaction is in progress, and it is a UAS for that INVITE
transaction, it MUST place the same value into the Contact header
field of the 2xx to the INVITE that it placed into the UPDATE request
or response.
The rules for inclusion of offers and answers in SIP messages as The rules for inclusion of offers and answers in SIP messages as
defined in Section 13.2.1 of RFC BBBB still apply. These rules exist defined in Section 13.2.1 of RFC 3261 still apply. These rules exist
to guarantee a consistent view of the session state. This means that, to guarantee a consistent view of the session state. 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 callee generated an the UPDATE can contain an offer if the callee generated an
answer in a reliable provisional response, and the caller has answer in a reliable provisional response, and the caller has
received answers to any other offers it sent in either PRACK received answers to any other offers it sent in either PRACK or
or UPDATE, and has generated answers for any offers it UPDATE, and has generated answers for any offers it received in
received in an UPDATE from the callee. 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
UPDATE from the callee. from the callee.
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
initial INVITE transaction, it cannot be sent if the caller INVITE transaction, it cannot contain an offer 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
which have not been answered. 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
INVITE transaction, and the initial INVITE contained an offer, transaction, and the initial INVITE contained an offer, the
the UPDATE cannot be sent unless the callee has generated an UPDATE cannot be sent with an offer unless the callee has
answer in a reliable provisional response, has received a generated an answer in a reliable provisional response, has
PRACK for that reliable provisional response, has not received received a PRACK for that reliable provisional response, has
any requests (PRACK or UPDATE) with offers that it has not not received any requests (PRACK or UPDATE) with offers that it
answered, and has not sent any UPDATE requests containing has not answered, and has not sent any UPDATE requests
offers that have not been answered. 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 cannot be sent unless the callee has sent an offer the UPDATE cannot be sent with an offer unless the callee has
in a reliable provisional response, received an answer in a sent an offer in a reliable provisional response, received an
PRACK, and has not received any UPDATE requests with offers answer in a PRACK, and has not received any UPDATE requests
that it has not answered, and has not sent any UPDATE requests with offers that it has not answered, and has not sent any
containing offers that have not been answered. 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
initial INVITE transaction, it cannot be sent if the callee INVITE transaction, it cannot be sent with an offer if the
has generated or received offers in a re-INVITE or UPDATE callee has generated or received offers in a re-INVITE or
which have not been answered. UPDATE which have not been answered.
5.2 Receiving an UPDATE 5.2 Receiving an UPDATE
The UPDATE is processed as any other mid-dialog request, as described The UPDATE is processed as any other mid-dialog target refresh
in Section 12.2.2 of RFC BBBB [1]. If the request is generally request, as described in Section 12.2.2 of RFC 3261 [1]. If the
acceptable, processing continues as described below. This processing request is generally acceptable, processing continues as described
is nearly identical to that of Section 14.2 of RFC BBBB [1], below. This processing is nearly identical to that of Section 14.2
generalized for the case of UPDATE. of RFC 3261 [1], but generalized for the case of UPDATE.
A UAS that receives an UPDATE before it has generated a final A UAS that receives an UPDATE before it has generated a final
response to a previous UPDATE or INVITE on the same dialog MUST response to a previous UPDATE on the same dialog MUST return a 500
return a 500 response to the new UPDATE, and MUST include a Retry- response to the new UPDATE, and MUST include a Retry-After header
After field with a Retry-After header field with a randomly chosen field with a randomly chosen value between 0 and 10 seconds.
value between 0 and 10 seconds.
If an UPDATE is received that contains an offer, and the UAS has If an UPDATE is received that contains an offer, and the UAS has
generated an offer (in an UPDATE, PRACK or INVITE) to which it has generated an offer (in an UPDATE, PRACK or INVITE) to which it has
not yet received an answer, the UAS MUST reject the UPDATE with a 491 not yet received an answer, the UAS MUST reject the UPDATE with a 491
response. response. Similarly, if an UPDATE is received that contains an
offer, and the UAS has received an offer (in an UPDATE, PRACK, or
INVITE) to which it has not yet generated an answer, the UAS MUST
reject the UPDATE with a 500 response, and MUST include a Retry-After
header field with a randomly chosen value between 0 and 10 seconds.
If a UA receives an UPDATE for an existing dialog, it MUST check any 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 in the session description or, if there are no
version identifiers, the content of the session description to see if version identifiers, the content of the session description to see if
it has changed. If the session description has changed, the UAS MUST it has changed. If the session description has changed, the UAS MUST
adjust the session parameters accordingly and generate an answer in adjust the session parameters accordingly and generate an answer in
the 2xx response. However, unlike a re-INVITE, the UPDATE MUST be the 2xx response. However, unlike a re-INVITE, the UPDATE MUST be
responded to promptly, and therefore the user cannot generally be responded to promptly, and therefore the user cannot generally be
prompted to approve the session changes. If the UAS cannot change the prompted to approve the session changes. If the UAS cannot change
session parameters without prompting the user, it SHOULD reject the the session parameters without prompting the user, it SHOULD reject
request with a 504 response. If the new session description is not the request with a 504 response. If the new session description is
acceptable, the UAS can reject it by returning a 488 (Not Acceptable not acceptable, the UAS can reject it by returning a 488 (Not
Here) response for the UPDATE. This response SHOULD include a Warning Acceptable Here) response for the UPDATE. This response SHOULD
header field. include a Warning header field.
5.3 Processing the UPDATE Response 5.3 Processing the UPDATE Response
Processing of the UPDATE response at the UAC is nearly identical to Processing of the UPDATE response at the UAC follows the rules in
the rules in Section 14.1 of RFC BBBB [1], but generalized for Section 12.2.1.2 of RFC 3261 [1] for a target refresh request. Once
UPDATE. that processing is complete, it continues as specified below. This
processing is nearly identical to the processing of Section 14.1 of
RFC 3261 [1], but generalized for UPDATE.
If a UA receives a non-2xx final response to a UPDATE, the session If a UA receives a non-2xx final response to a UPDATE, the session
parameters MUST remain unchanged, as if no UPDATE had been issued. parameters MUST remain unchanged, as if no UPDATE had been issued.
Note that, as stated in Section 12.2.1 of RFC BBBB [1], if the non- Note that, as stated in Section 12.2.1 of RFC 3261 [1], if the non-
2xx final response is a 481 (Call/Transaction Does Not Exist), or a 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 408 (Request Timeout), or no response at all is received for the
UPDATE (that is, a timeout is returned by the UPDATE client UPDATE (that is, a timeout is returned by the UPDATE client
transaction), the UAC will terminate the dialog. transaction), the UAC will terminate the dialog.
If a UAC receives a 491 response to a UPDATE, it SHOULD start a timer If a UAC receives a 491 response to a UPDATE, it SHOULD start a timer
with a value T chosen as follows: with a value T chosen as follows:
1. If the UAC is the owner of the Call-ID of the dialog ID 1. If the UAC is the owner of the Call-ID of the dialog ID
(meaning it generated the value), T has a randomly chosen (meaning it generated the value), T has a randomly chosen value
value between 2.1 and 4 seconds in units of 10 ms. between 2.1 and 4 seconds in units of 10 ms.
2. If the UAC is not the owner of the Call-ID of the dialog 2. If the UAC is not the owner of the Call-ID of the dialog ID, T
ID, T has a randomly chosen value of between 0 and 2 has a randomly chosen value between 0 and 2 seconds in units of
seconds in units of 10 ms. 10 ms.
When the timer fires, the UAC SHOULD attempt the UPDATE once more, if When the timer fires, the UAC SHOULD attempt the UPDATE once more, if
it still desires for that session modification to take place. For it still desires for that session modification to take place. For
example, if the call was already hung up with a BYE, the UPDATE would example, if the call was already hung up with a BYE, the UPDATE would
not take place. not take place.
6 Proxy Behavior 6 Proxy Behavior
Proxy processing of the UPDATE request is identical to any other Proxy processing of the UPDATE request is identical to any other
non-INVITE request. non-INVITE request.
7 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: 3261:
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
Table 1 extends Table 2 of RFC BBBB for the UPDATE method. Table 1 extends Table 2 of RFC 3261 for the UPDATE method.
Table 2 updates Table 3 of RFC BBBB for the UPDATE method. Table 2 updates Table 3 of RFC 3261 for the UPDATE method.
8 Example Call Flow 8 Example Call Flow
This section presents an example call flow using the UPDATE method. 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) The flow is shown in Figure 1. The caller sends an initial INVITE
which contains an offer. The callee generates a 180 response (2) with (1) which contains an offer. The callee generates a 180 response (2)
an answer to that offer. With the completion of an offer/answer with an answer to that offer. With the completion of an offer/answer
exchange, the session is established, although the dialog is still in
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
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.
This offer is answered in the 200 response to the UPDATE (6).
Shortly thereafter, the callee decides to update some aspect of the
session, 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 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 SDP.
Header field where proxy UPDATE Header field where proxy UPDATE
____________________________________________ ____________________________________________
Accept R o Accept R o
Accept 2xx o Accept 2xx o
Accept 415 c Accept 415 c
Accept-Encoding R o Accept-Encoding R o
Accept-Encoding 2xx o Accept-Encoding 2xx o
Accept-Encoding 415 c Accept-Encoding 415 c
Accept-Language R o Accept-Language R o
Accept-Language 2xx o Accept-Language 2xx o
skipping to change at page 8, line 47 skipping to change at page 8, line 48
Error-Info 300-699 a o Error-Info 300-699 a o
Event (1) - Event (1) -
Expires - Expires -
From c r m From c r m
In-Reply-To - In-Reply-To -
Max-Forwards R amr m Max-Forwards R amr m
Min-Expires - Min-Expires -
MIME-Version o MIME-Version o
Organization ar o Organization ar o
Table 1: Summary of header fields, A--O ; (1) defined in [5], Table 1: Summary of header fields, A--O ; (1) defined in [5].
Header field where proxy UPDATE Header field where proxy UPDATE
____________________________________________________ ____________________________________________________
Priority - Priority -
Proxy-Authenticate 407 ar m Proxy-Authenticate 407 ar m
Proxy-Authenticate 401 ar o Proxy-Authenticate 401 ar o
Proxy-Authorization R dr o Proxy-Authorization R dr o
Proxy-Require R ar o Proxy-Require R ar o
RAck R - RAck R -
Record-Route R ar o Record-Route R ar o
Record-Route 2xx,18x mr o Record-Route 2xx,18x mr o
skipping to change at page 9, line 36 skipping to change at page 9, line 37
Timestamp o Timestamp o
To c r m To c r m
Unsupported 420 m Unsupported 420 m
User-Agent o User-Agent o
Via R amr m Via R amr m
Via rc dr m Via rc dr m
Warning r o Warning r o
WWW-Authenticate 401 ar m WWW-Authenticate 401 ar m
WWW-Authenticate 407 ar o WWW-Authenticate 407 ar o
Table 2: Summary of header fields, P--Z Table 2: Summary of header fields, P--Z.
exchange, the session is established, although the dialog is still in
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
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.
This offer is answered in the 200 response to the UPDATE (6). Shortly
thereafter, the callee decides to update some aspect of the session,
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
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
SDP.
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 11, line 8 skipping to change at page 11, line 8
| | | |
| | | |
| | | |
| | | |
Figure 1: UPDATE Call Flow Figure 1: UPDATE Call Flow
9 Security Considerations 9 Security Considerations
The security considerations for UPDATE are identical to those for The security considerations for UPDATE are identical to those for
re-INVITE. It is important that the UPDATE be integrity protected and re-INVITE. It is important that the UPDATE be integrity protected
authenticated as coming from the same source as the entity on the and authenticated as coming from the same source as the entity on the
other end of the dialog. RFC BBBB [1] discusses security mechanisms other end of the dialog. RFC 3261 [1] discusses security mechanisms
for achieving these functions. for achieving these functions.
10 IANA Considerations 10 IANA Considerations
As per Section 27.4 of RFC BBBB [1], this specification serves as a As per Section 27.4 of RFC 3261 [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
added to the registry is: be added to the registry is:
RFC Number: This specification serves as the RFC for registering RFC 3311: This specification serves as the RFC for registering
the UPDATE request method. the UPDATE request method.
Method Name: UPDATE Method Name: UPDATE
Reason Phrase: Not applicable. Reason Phrase: Not applicable.
11 Acknowledgements 11 Notice Regarding Intellectual Property Rights
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.
12 Normative References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with the
Session Description Protocol (SDP)", RFC 3264, June 2002.
[4] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
Responses in the Session Initiation Protocol (SIP)", RFC 3262,
June 2002.
[5] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
13 Acknowledgements
The author would like to thank Jo Hornsby, Markus Isomaki, Rohan The author would like to thank Jo Hornsby, Markus Isomaki, Rohan
Mahy, and Bob Penfield for their comments. Mahy, and Bob Penfield for their comments.
12 Author's Addresses 14 Author's Address
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
13 Normative References
[1] J. Rosenberg, H. Schulzrinne, et al. , "SIP: Session initiation
protocol," Internet Draft, Internet Engineering Task Force, Feb.
2002. Work in progress.
[2] S. Bradner, "Key words for use in RFCs to indicate requirement
levels," RFC 2119, Internet Engineering Task Force, Mar. 1997.
[3] J. Rosenberg and H. Schulzrinne, "An offer/answer model with EMail: jdrosen@dynamicsoft.com
SDP," Internet Draft, Internet Engineering Task Force, Feb. 2002.
Work in progress.
[4] J. Rosenberg and H. Schulzrinne, "Reliability of provisional
responses in SIP," Internet Draft, Internet Engineering Task Force,
Feb. 2002. Work in progress.
[5] A. Roach, "SIP-specific event notification," Internet Draft,
Internet Engineering Task Force, Mar. 2002. Work in progress.
14 Informative References
Full Copyright Statement 15 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
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
skipping to change at page 12, line 44 skipping to change at page 13, line 33
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 Acknowledgement
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed Funding for the RFC Editor function is currently provided by the
rights. Internet Society.
 End of changes. 

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