RFC 3311 (rfc3311) - Page 2 of 13
The Session Initiation Protocol (SIP) UPDATE Method
Alternative Format: Original Text Document
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



