summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3311.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3311.txt')
-rw-r--r--doc/rfc/rfc3311.txt731
1 files changed, 731 insertions, 0 deletions
diff --git a/doc/rfc/rfc3311.txt b/doc/rfc/rfc3311.txt
new file mode 100644
index 0000000..d478aca
--- /dev/null
+++ b/doc/rfc/rfc3311.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Network Working Group J. Rosenberg
+Request for Comments: 3311 dynamicsoft
+Category: Standards Track September 2002
+
+
+ The Session Initiation Protocol (SIP) UPDATE Method
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+Abstract
+
+ This specification defines the new UPDATE method for the Session
+ Initiation Protocol (SIP). UPDATE allows a client to update
+ 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 is like a re-INVITE, but unlike re-INVITE, it can be sent before
+ the initial INVITE has been completed. This makes it very useful for
+ updating session parameters within early dialogs.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg Standards Track [Page 1]
+
+RFC 3311 SIP UPDATE Method September 2002
+
+
+Table of Contents
+
+ 1 Introduction .............................................. 2
+ 2 Terminology ............................................... 3
+ 3 Overview of Operation ..................................... 3
+ 4 Determining Support for this Extension .................... 3
+ 5 UPDATE Handling ........................................... 4
+ 5.1 Sending an UPDATE ......................................... 4
+ 5.2 Receiving an UPDATE ....................................... 5
+ 5.3 Processing the UPDATE Response ............................ 6
+ 6 Proxy Behavior ............................................ 7
+ 7 Definition of the UPDATE method ........................... 7
+ 8 Example Call Flow ......................................... 7
+ 9 Security Considerations ................................... 11
+ 10 IANA Considerations ....................................... 11
+ 11 Notice Regarding Intellectual Property Rights ............. 11
+ 12 Normative References ...................................... 11
+ 13 Acknowledgements .......................................... 12
+ 14 Author's Address .......................................... 12
+ 15 Full Copyright Statement .................................. 13
+
+1 Introduction
+
+ The Session Initiation Protocol (SIP) [1] defines the INVITE method
+ for the initiation and modification of sessions. However, this
+ method actually affects two important pieces of state. It impacts
+ the session (the media streams SIP sets up) and also the dialog (the
+ state that SIP itself defines). While this is reasonable in many
+ cases, there are important scenarios in which this coupling causes
+ complications.
+
+ The primary difficulty is when aspects of the session need to be
+ modified before the initial INVITE has been answered. An example of
+ this situation is "early media", a condition where the session is
+ established, for the purpose of conveying progress of the call, but
+ before the INVITE itself is accepted. It is important that either
+ caller or callee be able to modify the characteristics of that
+ session (putting the early media on hold, for example), before the
+ 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
+ dialog, in addition to the session.
+
+ As a result, a solution is needed that allows the caller or callee to
+ provide updated session information before a final response to the
+ initial INVITE request is generated. The UPDATE method, defined
+ here, fulfills that need. It can be sent by a UA within a dialog
+ (early or confirmed) to update session parameters without impacting
+ the dialog state itself.
+
+
+
+Rosenberg Standards Track [Page 2]
+
+RFC 3311 SIP UPDATE Method September 2002
+
+
+2 Terminology
+
+ In this document, the key words "MUST", "MUST NOT", "REQUIRED",
+ "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
+ and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
+ [2] and indicate requirement levels for compliant SIP
+ implementations.
+
+3 Overview of Operation
+
+ Operation of this extension is straightforward. The caller begins
+ with an INVITE transaction, which proceeds normally. Once a dialog
+ is established, either early or confirmed, the caller can generate an
+ 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 field 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.
+
+4 Determining Support for this Extension
+
+ The initiation of a session operates as specified in RFC 3261 [1].
+ However, a UAC compliant to this specification SHOULD also include an
+ Allow header field in the INVITE request, listing the method UPDATE,
+ to indicate its ability to receive an UPDATE request.
+
+ When a UAS compliant to this specification receives an INVITE request
+ 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 field
+ listing the UPDATE method, and a 2xx response SHOULD contain an Allow
+ header field listing the UPDATE method.
+
+ Responses are processed normally as per RFC 3261 [1], and in the case
+ of reliable provisional responses, according to [4]. It is important
+ to note that a reliable provisional response will always create an
+ early dialog at the UAC. Creation of this dialog is necessary in
+ order to receive UPDATE requests from the callee.
+
+ If the response contains an Allow header field containing the value
+ "UPDATE", the UAC knows that the callee supports UPDATE, and the UAC
+ is allowed to follow the procedures of Section 5.1.
+
+
+
+
+Rosenberg Standards Track [Page 3]
+
+RFC 3311 SIP UPDATE Method September 2002
+
+
+5 UPDATE Handling
+
+5.1 Sending an UPDATE
+
+ The UPDATE request is constructed as would any other request within
+ an existing dialog, as described in Section 12.2.1 of RFC 3261. It
+ MAY be sent for both early and confirmed dialogs, and MAY be sent by
+ either caller or callee. 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 be
+ needed, and is possible with a re-INVITE.
+
+ The UAC MAY add optional headers for the UPDATE request, as defined
+ 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
+ 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, for the caller:
+
+ o If the UPDATE is being sent before completion of the initial
+ INVITE transaction, and the initial INVITE contained an offer,
+ the UPDATE can contain an offer if the callee generated an
+ answer in a reliable provisional response, and the caller 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
+ INVITE transaction, and the initial INVITE did not contain an
+ offer, the UPDATE can contain an offer if the callee generated
+ an offer in a reliable provisional response, and the UAC
+ generated an answer in the corresponding PRACK. Of course, it
+ 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
+ generated answers for any other offers it received in an UPDATE
+ from the callee.
+
+
+
+
+
+Rosenberg Standards Track [Page 4]
+
+RFC 3311 SIP UPDATE Method September 2002
+
+
+ o If the UPDATE is being sent after the completion of the initial
+ INVITE transaction, it cannot contain an offer if the caller
+ has generated or received offers in a re-INVITE or UPDATE which
+ have not been answered.
+
+ and for the callee:
+
+ o If the UPDATE is being sent before the completion of the INVITE
+ transaction, and the initial INVITE contained an offer, the
+ UPDATE cannot be sent with an offer unless the callee has
+ generated an answer in a reliable provisional response, has
+ received a PRACK for that reliable provisional response, has
+ not received 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
+ transaction, and the initial INVITE did not contain an offer,
+ the UPDATE cannot be sent with an offer unless the callee has
+ sent an offer in a reliable provisional response, received an
+ answer in a 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 initial
+ INVITE transaction, it cannot be sent with an offer if the
+ callee has generated or received offers in a re-INVITE or
+ UPDATE which have not been answered.
+
+5.2 Receiving an UPDATE
+
+ The UPDATE is processed as any other mid-dialog target refresh
+ request, as described in Section 12.2.2 of RFC 3261 [1]. If the
+ request is generally acceptable, processing continues as described
+ below. This processing is nearly identical to that of Section 14.2
+ of RFC 3261 [1], but generalized for the case of UPDATE.
+
+ A UAS that receives an UPDATE before it has generated a final
+ response to a previous UPDATE on the same dialog MUST return a 500
+ response to the new UPDATE, and MUST include a Retry-After header
+ field with a randomly chosen value between 0 and 10 seconds.
+
+ 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
+ not yet received an answer, the UAS MUST reject the UPDATE with a 491
+ 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
+
+
+
+Rosenberg Standards Track [Page 5]
+
+RFC 3311 SIP UPDATE Method September 2002
+
+
+ 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
+ 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.
+
+5.3 Processing the UPDATE Response
+
+ Processing of the UPDATE response at the UAC follows the rules in
+ Section 12.2.1.2 of RFC 3261 [1] for a target refresh request. Once
+ 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
+ parameters MUST remain unchanged, as if no UPDATE had been issued.
+ 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
+ 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.
+
+ If a UAC receives a 491 response to a UPDATE, it SHOULD start a timer
+ with a value T chosen as follows:
+
+ 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 value
+ 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 ID, T
+ has a randomly chosen value between 0 and 2 seconds in units of
+ 10 ms.
+
+ When the timer fires, the UAC SHOULD attempt the UPDATE once more, if
+ 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
+ not take place.
+
+
+
+Rosenberg Standards Track [Page 6]
+
+RFC 3311 SIP UPDATE Method September 2002
+
+
+6 Proxy Behavior
+
+ Proxy processing of the UPDATE request is identical to any other
+ non-INVITE request.
+
+7 Definition of the UPDATE method
+
+ The semantics of the UPDATE method are described in detail above.
+ This extension adds another value to the Method BNF described in RFC
+ 3261:
+
+ UPDATEm = %x55.50.44.41.54.45 ; UPDATE in caps
+ Method = INVITEm / ACKm / OPTIONSm / BYEm
+ / CANCELm / REGISTERm / UPDATEm
+ / extension-method
+
+ Table 1 extends Table 2 of RFC 3261 for the UPDATE method.
+
+ Table 2 updates Table 3 of RFC 3261 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
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg Standards Track [Page 7]
+
+RFC 3311 SIP UPDATE Method September 2002
+
+
+ Header field where proxy UPDATE
+ ____________________________________________
+ Accept R o
+ Accept 2xx o
+ Accept 415 c
+ Accept-Encoding R o
+ Accept-Encoding 2xx o
+ Accept-Encoding 415 c
+ Accept-Language R o
+ Accept-Language 2xx o
+ Accept-Language 415 c
+ Alert-Info -
+ Allow R o
+ Allow 2xx o
+ Allow r o
+ Allow 405 m
+ Allow-Events (1) -
+ Authentication-Info 2xx o
+ Authorization R o
+ Call-ID c r m
+ Call-Info ar o
+ Contact R m
+ Contact 1xx o
+ Contact 2xx m
+ Contact 3xx d o
+ Contact 485 o
+ Content-Disposition o
+ Content-Encoding o
+ Content-Language o
+ Content-Length ar t
+ Content-Type *
+ CSeq c r m
+ Date a o
+ Error-Info 300-699 a o
+ Event (1) -
+ Expires -
+ From c r m
+ In-Reply-To -
+ Max-Forwards R amr m
+ Min-Expires -
+ MIME-Version o
+ Organization ar o
+
+ Table 1: Summary of header fields, A--O ; (1) defined in [5].
+
+
+
+
+
+
+
+Rosenberg Standards Track [Page 8]
+
+RFC 3311 SIP UPDATE Method September 2002
+
+
+ Header field where proxy UPDATE
+ ____________________________________________________
+ Priority -
+ Proxy-Authenticate 407 ar m
+ Proxy-Authenticate 401 ar o
+ Proxy-Authorization R dr o
+ Proxy-Require R ar o
+ RAck R -
+ Record-Route R ar o
+ Record-Route 2xx,18x mr o
+ Reply-To -
+ Require ar c
+ Retry-After 404,413,480,486 o
+ 500,503 o
+ 600,603 o
+ Route R adr c
+ RSeq - -
+ Server r o
+ Subject - -
+ Subscription-State (1) -
+ Supported R o
+ Supported 2xx o
+ Timestamp o
+ To c r m
+ Unsupported 420 m
+ User-Agent o
+ Via R amr m
+ Via rc dr m
+ Warning r o
+ WWW-Authenticate 401 ar m
+ WWW-Authenticate 407 ar o
+
+
+ Table 2: Summary of header fields, P--Z.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg Standards Track [Page 9]
+
+RFC 3311 SIP UPDATE Method September 2002
+
+
+ Caller Callee
+ | |
+ | |
+ |(1) INVITE with offer 1 |
+ |---------------------------->|
+ | |
+ | |
+ |(2) 180 with answer 1 |
+ |<----------------------------|
+ | |
+ | |
+ |(3) PRACK |
+ |---------------------------->|
+ | |
+ | |
+ |(4) 200 PRACK |
+ |<----------------------------|
+ | |
+ | |
+ |(5) UPDATE with offer 2 |
+ |---------------------------->|
+ | |
+ | |
+ |(6) 200 UPDATE with answer 2 |
+ |<----------------------------|
+ | |
+ | |
+ |(7) UPDATE with offer 3 |
+ |<----------------------------|
+ | |
+ | |
+ |(8) 200 UPDATE with answer 3 |
+ |---------------------------->|
+ | |
+ | |
+ |(9) 200 INVITE |
+ |<----------------------------|
+ | |
+ | |
+ |(10) ACK |
+ |---------------------------->|
+ | |
+ | |
+ | |
+ | |
+
+ Figure 1: UPDATE Call Flow
+
+
+
+
+Rosenberg Standards Track [Page 10]
+
+RFC 3311 SIP UPDATE Method September 2002
+
+
+9 Security Considerations
+
+ 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 3261 [1] discusses security mechanisms
+ for achieving these functions.
+
+10 IANA Considerations
+
+ 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 added to the registry is:
+
+ RFC 3311: This specification serves as the RFC for registering
+ the UPDATE request method.
+
+ Method Name: UPDATE
+
+ Reason Phrase: Not applicable.
+
+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.
+
+
+
+
+
+Rosenberg Standards Track [Page 11]
+
+RFC 3311 SIP UPDATE Method September 2002
+
+
+13 Acknowledgements
+
+ The author would like to thank Jo Hornsby, Markus Isomaki, Rohan
+ Mahy, and Bob Penfield for their comments.
+
+14 Author's Address
+
+ Jonathan Rosenberg
+ dynamicsoft
+ 72 Eagle Rock Avenue
+ First Floor
+ East Hanover, NJ 07936
+
+ EMail: jdrosen@dynamicsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg Standards Track [Page 12]
+
+RFC 3311 SIP UPDATE Method September 2002
+
+
+15 Full Copyright Statement
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg Standards Track [Page 13]
+