Internet Engineering Task Force J. Elwell Internet Draft Siemens V. Venkataramanan Sylantro Systems Corp draft-elwell-sip-state-update-01.txt Expires: October 2004 April 2004 State update during a SIP dialog Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3667. Internet-Drafts are working documents of the Internet Engineering 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress. " The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document examines the need for updating state information, such as remote party identity, during a SIP dialog. It explores existing mechanisms that might be appropriate and proposes minor clarifications to existing RFCs and drafts to achieve this. Elwell et alia Expires - October 2004 [Page 1] State update during a SIP dialog April 2004 Table of Contents 1 Introduction....................................................3 2 State information subject to change during a dialog.............3 3 Applicability of existing mechanisms............................4 3.1 UPDATE........................................................4 3.2 re-INVITE.....................................................5 3.3 INVITE with Replaces header...................................6 4 Proposal........................................................6 5 Clarifications to RFC 3261[1]...................................7 6 Clarifications to RFC 3311 [2]..................................8 7 Clarification to RFC 3325 [4]..................................10 8 Clarification to draft-ietf-sip-authid-body-02 [6].............10 9 Author's Addresses.............................................10 10 Normative References..........................................11 Elwell et alia Expires - October 2004 [Page 2] State update during a SIP dialog April 2004 1 Introduction Certain information exchanged between SIP [1] UAs during an INVITE transaction can be stored at a receiving UA for the lifetime of the resulting dialog and/or made available to the user (e.g., via a display in the case of a human user). One example is the identity of the peer user (as supplied in the To or From header, the Authenticated Identity Body (AIB) or the P-Asserted-Identity header). Another example is the Subject header. This information forms part of the state of a dialog at a UA. Under certain circumstances some of this state information may need to be changed. For example, when interworking with a PSTN, there may be a change of party in the PSTN (e.g., because of call transfer). The PSTN party identity sent to the peer SIP UA in the To or From header, the AIB or the P-Asserted-Identity header during dialog establishment normally reflects the identity of the PSTN user. If the identity of the PSTN user changes during the lifetime of the dialog, this information needs to be updated at the UA. A second example involves 3rd party call control. A B2BUA performing 3rd party call control can perform actions such as call transfer that cause a change of membership of the call. An existing UA that remains involved in the call and retains its dialog with the B2BUA needs to be updated with the identity of the new remote party. A third example also involves 3rd party call control. In this case a B2BUA forms a conference and acts as a conference focus. It therefore needs to indicate this to any existing UA whose dialog is "transferred" into that conference. A fourth example is where a user changes the subject during a dialog. The revised subject needs to be communicated to the remote UA. Existing mechanisms for changing a session during a dialog (re-INVITE and UPDATE transactions) may be a suitable basis for making other state changes, but it is not at present clear if and how these mechanisms are applicable. 2 State information subject to change during a dialog The following information exchanged during the INVITE transaction can change during the lifetime of the resulting dialog. - Call-Info header. - Alert-Info header (early dialogs only). Elwell et alia Expires - October 2004 [Page 3] State update during a SIP dialog April 2004 - Contact header (change of feature tags [3]). - Reply-To header. - Subject header. - P-Asserted-Identity header [4]. - Privacy header [5] (for use in conjunction with updated identity information). - Authenticated Identity Body (AIB) [6]. In addition consideration should be given to the following headers: Allowed, Supported, Required. These would not normally be expected to change at a UA reporting a state change. However, there might be some B2BUA arrangements where Allowed, Supported and Required are sent by the B2BUA on behalf of another UA, and if that other UA changes, these headers might change. 3 Applicability of existing mechanisms 3.1 UPDATE The UPDATE mechanism [2] provides a means for updating the session using a 2-message sequence (request/response) during an INVITE- initiated dialog. Although one of the prime motivations for UPDATE is use during an early dialog (in conjunction with the PRACK method), where re-INVITE cannot be used, UPDATE can also be used during a confirmed dialog. The RFCs concerned are unclear on the use of UPDATE for updating the following state information: Call-Info header. According to [2], this is optional in an UPDATE request, but no semantics are given. It is unclear whether this is allowed to differ from what was in the INVITE request or response, and if so the meaning of this. Alert-Info header. According to [2], this is not applicable in an UPDATE request. However, a possible use during an early dialog would be to change the alerting indication or ringback tone. Contact header. According to [2], this is mandatory in an UPDATE request. In [3] there is mention of updating feature parameters during a dialog. Reply-To header. This is not allowed in an UPDATE request. Subject header. According to [2], this is not allowed in an UPDATE request. Elwell et alia Expires - October 2004 [Page 4] State update during a SIP dialog April 2004 P-Asserted-Identity header. According to [4], this header is not allowed in an UPDATE request. Privacy header. There is no mention in [5] of using this header in an UPDATE request. AIB. [6] does provide for the use of AIB in a request within the context of an existing dialog. However, it does not mention UPDATE specifically. Also, it does not mention semantics, e.g., whether an AIB in a request in an existing dialog overrides any AIB in the original request or response. 3.2 re-INVITE The re-INVITE mechanism [1] provides a means for updating the session during an INVITE-initiated dialog. It differs from UPDATE in that it uses a three message sequence (request, response, ACK), and this takes account of possible delays while a user is consulted on the proposed update. Therefore for updating the session on a confirmed dialog, re-INVITE will often be preferred to UPDATE. If state information needs to be updated at the same time as the session, re- INVITE might be the preferred choice. At other times UPDATE might be the preferred choice for updating state information. Another consideration is that some SIP implementations do not currently support UPDATE. The RFCs concerned are unclear on the use of re-INVITE for updating the following state information: Call-Info header. According to [1], this is optional in an INVITE request, but there is no specific mention of re-INVITE. It is unclear whether this is allowed to differ from what was in the original INVITE request or response, and if so the meaning of this. Contact header. According to [1], this is mandatory in a re-INVITE request. In [3] there is mention of updating feature parameters during a dialog. Reply-To header. According to [1], this is optional in an INVITE request, but there is no specific mention of re-INVITE. It is unclear whether this is allowed to differ from what was in the original INVITE request or response, and if so the meaning of this. Subject header. According to [2], this is optional in an INVITE request, but there is no specific mention of re-INVITE. It is unclear whether this is allowed to differ from what was in the original INVITE request or response, and if so the meaning of this. Elwell et alia Expires - October 2004 [Page 5] State update during a SIP dialog April 2004 P-Asserted-Identity header. There is no mention in [4] of using this header in a re-INVITE request. Privacy header. There is no mention in [5] of using this header in a re-INVITE request. AIB. [6] does provide for the use of AIB in a request within the context of an existing dialog. However, it does not mention re-INVITE specifically. Also, it does not mention semantics, e.g., whether an AIB in a request in an existing dialog overrides any AIB in the original request or response. 3.3 INVITE with Replaces header Rather than updating state information for the existing dialog, a new dialog could be created using an INVITE addressed to the remote contact (assuming this is a GRUU) and the Replaces header, thereby causing the new dialog to replace the existing dialog. This is a heavyweight method of achieving the desired results. In particular it requires support of the Replaces header, support of GRUUs, and re- negotiation of the session. 4 Proposal It is proposed that the use of the UPDATE method for updating state information during a confirmed or early dialog be endorsed. It is also proposed that the use of the re-INVITE method be endorsed for updating state information during a confirmed dialog for cases where the peer UA does not support UPDATE or when the session is to be updated at the same time. In order to achieve this, clarifications are required to some existing RFCs: - RFC 3261: Clarify that a re-INVITE can be used to update dialog- related information during a dialog, i.e., not just a target refresh or a session description change. - RFC 3311: Clarify that an UPDATE can be used without a session description in order to update dialog-related information. This is already implicit in some places, but a few places seem to require an UPDATE request to contain an SDP offer. - RFC 3323: This does not specify specific procedures for particular methods and does not make any distinction between a request outside of an existing dialog or a request within a dialog. Therefore as it stands it is in theory equally applicable to UPDATE and re-INVITE as it is to INVITE. However, certain privacy services may not be possible to provide during a dialog if not already provided from the Elwell et alia Expires - October 2004 [Page 6] State update during a SIP dialog April 2004 start of the dialog. Its main usefulness seems to be to indicate privacy for an updated P-Asserted-Identity header or an updated Authenticated Identity Body. No changes are proposed. - RFC 3325: Allow the use of the P-Asserted-Identity header with the UPDATE method. The RFC does not specify specific procedures for particular methods and does not make any distinction between a request outside of an existing dialog or a request within a dialog. Therefore as it stands it is equally applicable to UPDATE (with the proposed change) and re-INVITE as it is to INVITE. Therefore no procedural changes need to be made. - draft-ietf-sip-authid-body-02: Add mention of use of AIB in re- INVITE or UPDATE. The remainder of this draft proposes detailed clarifications. 5 Clarifications to RFC 3261[1] Add two new paragraphs to the end of 12.2 (prior to 12.2.1): "A request, whether or not it is a target refresh request, MAY update certain other information transmitted at the time of dialog establishment. Examples include the following headers from this RFC: Alert-Info, Call-Info, Reply-To and Subject. Other extensions may define other headers that are appropriate for updating during a dialog. "In this RFC, the only request defined that is suitable for updating information during a dialog is re-INVITE (see section 14). Other extensions may define different requests suitable for updating information during a dialog." Add to the end of the first paragraph of 14.1: "A UAC MAY send a session description that is unchanged, if the purpose of the re-INVITE is solely for updating dialog-related information." OPEN ISSUE. Section 14.1 of RFC 3261 states that a UAC MUST NOT initiate a new INVITE transaction within a dialog while another INVITE transaction is in progress in either direction. What is the reason for this? If it is just because of constraints of the offer/answer model, then presumably it should not apply to a re- INVITE that does not contain an offer. Other methods within dialogs (e.g., UPDATE with no SDP, INFO and NOTIFY) do not seem to have similar constraints. Elwell et alia Expires - October 2004 [Page 7] State update during a SIP dialog April 2004 6 Clarifications to RFC 3311 [2] General Call-Info Alert-Info Reply-To Subject Add to the end of the last paragraph of section 1: "It can also be sent by a UA within a dialog (early or confirmed) to update dialog-related information in addition to or instead of updating session parameters." Replace the last sentence of section 3: Old text: "There are additional constraints on when UPDATE can be used, based on the restrictions of the offer/answer model." New text: "The UPDATE method can also be used without SDP offer/answer in order to update only dialog-related information and not the session. There are additional constraints on when UPDATE can be used with SDP offer/answer, based on restrictions of the offer/answer model." Change "MAY" to "SHOULD" in the 2nd paragraph of section 4: Old text: "An unreliable provisional response MAY contain an Allow header field listing the UPDATE method ... New text: "An unreliable provisional response SHOULD contain an Allow header field listing the UPDATE method ... Extend the last sentence of the 3rd paragraph of section 4: Old text: "Creation of this dialog is necessary in order to receive UPDATE requests from the callee." New text: "Creation of this dialog is necessary in order to receive UPDATE requests from the callee and in order to receive an SDP offer in an UPDATE request from the caller." Add the following paragraph at the end of section 4: "Although a UAS for an INVITE request must use a reliable provisional response in order to ensure that an early dialog is created before issuing an UPDATE request towards the caller, a UAC for an INVITE request will know that an early dialog is established even if it receives an unreliable provisional response. The UAC for Elwell et alia Expires - October 2004 [Page 8] State update during a SIP dialog April 2004 the INVITE request MAY then issue an UPDATE request without an SDP offer towards the callee, subject to having received an appropriate Allow header field." Replace the 3rd sentence of section 5.1: Old text: "Although UPDATE can be used on confirmed dialogs, it is RECOMMENDED that a re-INVITE be used instead." New text: "Although UPDATE can be used on confirmed dialogs, it is RECOMMENDED that a re-INVITE be used instead if there is a need to seek user approval." Replace the last sentence of the 2nd bullet of section 5.1: Old text: "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." New text: "Of course, it can't send an UPDATE containing an offer 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." Add a new paragraph at the end of section 5.2: "If a UA receives an UPDATE request with no session description for an existing dialog, the UA MUST NOT include a session description in the response. In this case the UPDATE request is for the purpose of target refresh or updating other dialog-related information". Change the following row in table 1: Old: Alert-Info - New: Alert-Info o Change the following rows in table 2: Old: Reply-To - New: Reply-To o Old: Subject - - New: Subject o Elwell et alia Expires - October 2004 [Page 9] State update during a SIP dialog April 2004 7 Clarification to RFC 3325 [4] In section 9.1, change the additional entry to table 1 of RFC 3261 as follows (to make UPDATE optional): Old: Header field where proxy ACK BYE CAN INV OPT REG ------------ ----- ----- --- --- --- --- --- --- P-Asserted-Identity adr - o - o o - SUB NOT REF INF UPD PRA --- --- --- --- --- --- o o o - - - New: Header field where proxy ACK BYE CAN INV OPT REG ------------ ----- ----- --- --- --- --- --- --- P-Asserted-Identity adr - o - o o - SUB NOT REF INF UPD PRA --- --- --- --- --- --- o o o - o - 8 Clarification to draft-ietf-sip-authid-body-02 [6] Add the following to the first paragraph of section 5: "An AIB in a request within the context of an existing dialog (e.g., re-INVITE, UPDATE) can be used to replace the corresponding identity transmitted at the start of the dialog." 9 Author's Addresses John Elwell Siemens Communications Technology Drive Beeston Nottingham, UK, NG9 1LA email: john.elwell@siemens.com Venkatesh Venkataramanan Sylantro Systems Corp 910 E Hamilton Ave, Campbell, CA 95008 Sylantro inc. Elwell et alia Expires - October 2004 [Page 10] State update during a SIP dialog April 2004 email: Venkatesh.Venkataramanan@sylantro.com 10 Normative References [1] J. Rosenberg, H. Schulzrinne, et al., "SIP: Session initiation protocol", RFC 3261. [2] J. Rosenberg, "The Session Initiation Protocol (SIP) UPDATE method", RFC 3311. [3]J. Rosenberg, H. Schulzrinne, P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", draft-ietf- sip-callee-caps-03.txt (work in progress). [4] C. Jennings, J. Peterson, M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325. [5] J. Peterson. "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323. [6] J. Peterson. "SIP Authenticated Identity Body (AIB) Format", draft-ietf-sip-authid-body-02.txt (work in progress). Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Disclaimer of Validity Elwell et alia Expires - October 2004 [Page 11] State update during a SIP dialog April 2004 This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Elwell et alia Expires - October 2004 [Page 12]