Internet Engineering Task Force J. Elwell Internet Draft Siemens V. Venkataramanan Sylantro Systems Corp draft-elwell-sip-state-update-00.txt Expires: August 2004 February 2004 State update during a SIP dialog Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC 2026. 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. 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 identifies matters that need to be fixed to make this possible. Elwell et alia Expires - August 2004 [Page 1] State update during a SIP dialog February 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 Author's Addresses..............................................6 6 Normative References............................................7 Elwell et alia Expires - August 2004 [Page 2] State update during a SIP dialog February 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 - August 2004 [Page 3] State update during a SIP dialog February 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 were 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, but there is no mention in [3] of the use of feature tags in an UPDATE request. 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 - August 2004 [Page 4] State update during a SIP dialog February 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, but there is no mention in [3] of the use of feature tags in a re-INVITE request. 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 - August 2004 [Page 5] State update during a SIP dialog February 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. There are several options for documenting this: 1. Revise all the relevant RFCs (including the imminent callee capabilities RFC). 2. Just revise the RFC 3311 (UPDATE) and RFC3261 to cover state information update, e.g., by means of published errata. 3. Write a new RFC to extend the use of UPDATE and re-INVITE to state information update. 5 Author's Addresses John Elwell Siemens Communications Technology Drive Beeston Nottingham, UK, NG9 1LA Elwell et alia Expires - August 2004 [Page 6] State update during a SIP dialog February 2004 email: john.elwell@siemens.com Venkatesh Venkataramanan Sylantro Systems Corp 910 E Hamilton Ave, Campbell, CA 95008 Sylantro inc. email: Venkatesh.Venkataramanan@sylantro.com 6 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-02.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). Elwell et alia Expires - August 2004 [Page 7]