Internet Engineering Task Force J. Elwell Internet Draft Siemens draft-elwell-sip-session-retention-00.txt Expires: August 2005 February 2005 Session retention during SIP INVITE/Replaces 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, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 proposes a method or retaining a session when a SIP dialog between two UAs is replaced by another dialog between those same two UAs in order to update dialog-related information such as identity. Elwell Expires - August 2005 [Page 1] Session retention during SIP INVITE/ReplacesFebruary 2005 Table of Contents 1 Introduction....................................................3 2 Background......................................................3 3 Proposal........................................................5 4 Open issues.....................................................5 5 Security Considerations.........................................5 6 Author's Addresses..............................................6 7 References......................................................6 Elwell Expires - August 2005 [Page 2] Session retention during SIP INVITE/ReplacesFebruary 2005 1 Introduction The Session Initiation Protocol (SIP) [SIP] uses the Session Description Protocol (SDP) [SDP] for establishing a session comprising one or more media streams between User Agents (UAs). Session negotiation using SDP takes place in accordance with the offer/answer model [OA]. When establishing a SIP INVITE-initiated dialog, session negotiation normally takes place in parallel. The session remains associated with the dialog and terminates when the dialog terminates, normally as a result of a SIP BYE transaction. There are circumstances where a dialog between two SIP UAs may need to be replaced by a new dialog between those same two UAs in order to update certain dialog-related information. This may need to be done without disruption to media flows, and hence retention of the existing session would seem desirable. The background to this is given in section 2. Section 3 proposes a solution to the problem, involving small changes to [SIP] and [Replaces]. 2 Background During dialog establishment there are various means by which the SIP INVITE request can indicate to the UAS the identity of the UAC user. One example is the From header, although this suffers from lack of authentication. Other examples are Authenticated Identity Body [AIB] and the Identity header [ID]. The UAC generally assumes that the identity of the UAS user is the identity placed in the To header, although in some circumstances retargeting of the request can render this inaccurate. Study continues on how to provide authenticated identity information in a response. There has also been discussion on how to indicate change of identity during a dialog. One example of where identity can change during a dialog involves interworking with a legacy network via a UA that acts as a gateway. Establishment of an INVITE-initiated dialog (and associated session) to or from a gateway generally involves signalling the identity of the user of the legacy network (e.g., a telephone number in a sip: or tel: URI). Transfer or similar behaviour within the legacy network can cause this identity to change. It would be highly desirable to be able to signal the new identity to the peer UA, which could use it for display purposes, call logging purposes, etc.. Another example is where a SIP B2BUA has third party call control capabilities and can join two dialogs together. When an existing dialog is joined to a different dialog from that to which it was Elwell Expires - August 2005 [Page 3] Session retention during SIP INVITE/ReplacesFebruary 2005 previously joined, there may be a need to signal a new identity to the peer UA on the existing dialog. Recent discussions on how to achieve signalling of a new identity have led to consideration of several candidate solutions. Some of those solutions involved retaining the dialog and signalling the new identity using the (re)INVITE method or the UPDATE method [UPD], but these all have unresolved issues. The solution finding the most favour involved establishing a new dialog using the INVITE method with the Replaces header [REPL] and exploiting existing identity- related signalling in the INVITE transaction. With the latter solution, the UA wishing to report a new identity issues an INVITE request addressed to the peer UA (e.g., by means of a Globally Routable UA URI (GRUU) [GRUU] and includes in that request a Replaces header field identifying the existing dialog. The From header in conjunction with authenticated identity information in the INVITE request advises the UAS of the new identity. From the perspective of the UAS, this looks exactly like a call transfer situation, which in general is the event that has led to the need to carry out this action. The only difference in the cases considered here is that the UAC for the INVITE/Replaces request is already a participant in the replaced dialog. Because in this case the replaced dialog and the new dialog are both between the same two UAs, the question arises as to what should happen to the session associated with the replaced dialog. According to section 15 of [SIP], the BYE transaction, which occurs when the dialog is replaced, terminates the session. The INVITE/Replaces transaction will initiate a new session to replace the original session. However, the new session may be identical in all respects to the replaced session. This is particularly likely to be the case in the gateway example above. Both sessions will be between the gateway and the peer UA and in general will comprise the same media and parameters. When transfer in the legacy network occurs, any switching of media streams occurs within that legacy network and should not have impact on the media streams flowing between the gateway and the peer UA in the SIP network. In fact, any disruption to the existing session could have a detrimental effect, since the disruption might occur slightly later than the disruption in the legacy network, by which time meaningful media might have started to flow again between the new endpoint in the legacy network and the peer UA in the SIP network. For example, in the case of audio one of the users may have started to speak. Closing down a session and establishing a new session could cause disruption to the flow of media. To overcome this it would be useful to have a means of retaining the existing session when replacing the dialog in this manner. Elwell Expires - August 2005 [Page 4] Session retention during SIP INVITE/ReplacesFebruary 2005 3 Proposal An SDP offer or answer contains a session ID and version. Repeated offer/answer exchanges during an existing dialog for the purpose of modifying the session will use the same session ID but increment the version, in accordance with [OA]. In order to retain the existing session without change when establishing a new dialog to replace an existing dialog between the same two UAs, it is proposed that the SDP offer in the INVITE/Replaces request contain the same session ID and the same version as the existing session on the replaced dialog. In this situation, and assuming the UAS accepts the INVITE/Replaces request by sending a 2xx response, both UAs MUST retain the existing session without modification and without disrupting the media streams. All session parameters MUST remain the same, including any session keys for secured media. The UAS MUST NOT follow this behaviour if the remote targets of the two dialogs do not match or if any SDP parameters have changed. It is also proposed that in order to modify the existing session, the SDP offer in the INVITE/Replaces request contain the same session ID as the existing session and a version incremented by one. If the UAS accepts the INVITE/Replaces together with the modified session by sending a 2xx response, both UAs MUST retain the existing session modified in accordance with the offer/answer. If the UAS cannot accept the modified session it will issue a 488 response as normal. The UAS MUST NOT follow this behaviour if the remote targets of the two dialogs do not match. Any other values for session ID and version in the offer in the INVITE/Replaces request MUST be treated as a request to establish a new session and terminate the existing session. These proposed changes would need to be documented as follows: - A change to section 15 of [SIP] to permit session retention following a BYE transaction in these circumstances. - A change to [REPL] to specify this specific behaviour when the Replaces header is used in these circumstances. 4 Open issues The impact of key management protocols embedded in SDP in accordance with draft-ietf-mmusic-kmgmt-ext needs to be considered. 5 Security Considerations Elwell Expires - August 2005 [Page 5] Session retention during SIP INVITE/ReplacesFebruary 2005 The security considerations of [REPL] apply. In addition, in order to prevent an unauthorized party replacing an existing dialog and forcing continuation of an existing session, the proposal includes requirements to ensure that the UAC of the INVITE/Replaces request is the remote UA in the existing dialog. 6 Author's Addresses John Elwell Siemens Communications Technology Drive Beeston Nottingham, UK, NG9 1LA email: john.elwell@siemens.com 7 References [AIB] J. Peterson, "Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format", RFC 3893. [GRUU] J. Rosenberg, "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", draft-ietf-sip-gruu-02 (work in progress). [ID] J. Peterson, C. Jennings, "Enhancements for Authenticated Identity Management in Session Initiation Protocol (SIP)", draft- ietf-sip-identity-03 (work in progress). [OA] J. Rosenberg, H. Schulzrinne, "An Offer/Answer Model with the Session Description Protocol (SDP)", RFC 3264. [REPL] R. Mahy, B. Biggs, R. Dean, "The Session Initiation Protocol 'Replaces' Header ", RFC 3891. [SDP] M. Handley, V. Jacobson, "SDP: Session Initiation Protocol", RFC 2327. [SIP] J. Rosenberg, H. Schulzrinne, et al., "SIP: Session initiation protocol", RFC 3261. [UPD] J. Rosenberg, "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311. 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 Elwell Expires - August 2005 [Page 6] Session retention during SIP INVITE/ReplacesFebruary 2005 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 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 Expires - August 2005 [Page 7]