Internet Engineering Task Force Internet Draft A. Idnani Document: draft-idnani-sip-contact-timestamp-00.txt Motorola Expires: March 2003 October 2002 New Parameter for Contact Header Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 memo proposes a new parameter for the SIP Contact header This memo identifies the need for the new parameter, and then goes ahead and defines the new parameter, and the algorithm for using the new parameter. It also presents an example flow demonstrating the use of the new parameter. The new parameter being defined is an optional parameter, and is not required to be supported by the SIP servers and UAs to be interoperational. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. Idnani Expires - March 2003 [Page 1] Internet Draft New parameter for contact Header October 2002 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. SIP Registrar . . . . . . . . . . . . . . . . . . . . . . . 3 3. Proxy UA . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Backward Compatibility . . . . . . . . . . . . . . . . . . . 4 5. Call Flows . . . . . . . . . . . . . . . . . . . . . . . . . 4 6. Security Considerations . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction This draft tries to solve a problem that occurs in any situation in which a SIP User Agent acts as a gateway to a Non-SIP device. In particular, architectures in which SIP is used as the signaling protocol within the core network of a system but the wireless mobile devices that roam within the system are not SIP user agents themselves. This draft introduces the concept of a "Proxy UA" which acts as a gateway between the SIP core network and the SIP-unaware mobile. The Proxy UA is responsible for running the UA call engine for all the mobiles that it is serving, besides converting the call control messages from SIP to legacy protocols and vice-versa. SIP uses contact addresses to tie a user?s address-of-record to his/her location [1]. The contact addresses are centrally registered with a SIP Registrar using a SIP REGISTER message. The 200 OK response back from the SIP Registrar contains the list of all the current Contact addresses for the user. Many a times when a mobile user moves from one service area to another, his registration at the old service area is kept active by a proxy UA in that area. This is because the old proxy UA has no way of knowing (or atleast not fast enough way of knowing) that the user has moved, and that there is now a new proxy UA for the user, which is the correct proxy UA. This draft addresses the problem of stale registrations at the SIP Proxy UA. It does not change the behavior of a SIP UA in any way. The draft introduces a new parameter called "created", for the Contact header. The parameter "created" will be maintained by the SIP Registrar, and will contain a time stamp of when the Contact address was first created, i.e. when the SIP REGISTER message containing a Contact address and a new Call-ID was received. This parameter along Idnani Expires - March 2003 [Page 2] Internet Draft New parameter for contact Header October 2002 with the timestamp value will be passed back to the user / proxy UA in a SIP 200 OK message. 2. SIP Registrar SIP Registrar is required to maintain a list of contact addresses. When a SIP Registrar receives a SIP REGISTER message, it MUST get the contact address from the message, and add it to the list of contact addresses for the user if it?s a new contact address. This extension requires the SIP Registrar to also maintain a timestamp when the contact address is a new contact address. If the Call-ID of a SIP REGISTER is a new Call-ID, then the Contact address in the SIP REGISTER message MUST be considered a new contact address, and hence a new timestamp SHOULD be recorded for this contact address. To keep things simple a SIP Registrar SHOULD get a new timestamp when the CSeq of the SIP REGISTER message is "1 REGISTER". This would signify a new Registration and hence new contact address, and therefore a new timestamp. The SIP Registrar should return all the contact addresses in SIP 200 OK response for a SIP REGISTER request. The contact addresses SHOULD carry a parameter called "created". The value of the parameter SHOULD be set to the timestamp as stored at the SIP Registrar. e.g. Contact: userA@proxyUA1.visited.com;created=2002-03-18:12:24:31 3. Proxy UA The proxy UA sends SIP REGISTER messages on behalf of a UA to the SIP Registrar. When the proxy UA receives the SIP 200 OK response back from the SIP Registrar, - It SHOULD check the contact addresses, and see if there are any more contact addresses than it had sent in the SIP REGISTER message. - If there are, it SHOULD check the timestamp on all the contact addresses to see if there are any newer contact addresses as compared to the ones that it had sent. - If there are, and the proxy UA wants to remove itself as the contact for the UA, then the proxy UA SHOULD send another SIP REGISTER message to the SIP Registrar, with the Expires header set to 0. Removing a contact address may be relevant where performance of the system is critical. In such cases one might want to maintain Idnani Expires - March 2003 [Page 3] Internet Draft New parameter for contact Header October 2002 very few contact address (one in many cases), so that the UAC or a SIP server does not have to fork a SIP INVITE to too many contact addresses. This reduces the network traffic, and helps in trying only those contact addresses, where probability of finding the user is higher. - The remaining steps are same as for any other SIP Registration refer [1] 4. Backward Compatibility The "created" parameter is an optional parameter. Any UA that does not support the parameter can safely ignore the parameter. The parameter does not change the current functionality of the SIP Registrar and the UA, it only adds a new timestamping function on the SIP Registrar. A proxy UA / UA that does not want to remove its contact address from the Registrar, does not need to do so. The "created" parameter can be used in conjunction with other Contact header parameters, without affecting their semantics. 5. Call Flows The following diagram illustrates a typical use of this extension. In the following diagram Proxy UA 1 is the old proxy UA, and Proxy UA 2 is the new proxy UA. +-----------+ +-----------+ +---------------+ | Proxy UA1 | | Proxy UA1 | | SIP Registrar | +-----------+ +-----------+ +---------------+ | | | | | F1 SIP REGISTER | | |----------------------->| | | | | | F2 200 OK | | |<-----------------------| | | | | F3 SIP REGISTER | | |----------------------|----------------------->| | | | | F4 200 OK | | |<---------------------|------------------------| | | | | F5 SIP REGISTER | | |----------------------|----------------------->| | | | | F4 200 OK | | |<---------------------|------------------------| | | | Idnani Expires - March 2003 [Page 4] Internet Draft New parameter for contact Header October 2002 In the above call flow, when the user moves to a new service area, the proxy UA (Proxy UA 2) in that area registers the contact address with the SIP Registrar. After some time when the old proxy UA (Proxy UA 1) sends a SIP REGISTER to renew the registration, it gets a 200 OK response back from the SIP Registrar containing both the old and the new contact addresses. Proxy UA 1, looks at the contact addresses, and realizes by looking at the timestamps on the contact addresses that there is a new proxy UA for the user, so it deregisters its contact address, by sending a SIP REGISTER message, with the Expires value set to 0. Message Details F1 SIP REGISTER REGISTER sip:registrar.home.com Via: SIP/2.0/UDP proxyUA2.visited.com:5060 From:UserA To: UserA Call-ID: 123456@proxyUA2.visited.com Cseq: 1 REGISTER Contact: userA@proxyUA2.visited.com Expires: 7200 Content-Length: 0 F2 200 OK SIP/2.0 200 OK Via: SIP/2.0/UDP registrar.home.com:5060 From:UserA To: UserA Call-ID: 123456@proxyUA2.visited.com Cseq: 1 REGISTER Contact: userA@proxyUA1.visited.com;created=2002-03-18:12:24:31 Contact: userA@proxyUA2.visited.com;created=2002-03-18:18:19:35 Content-Length:0 F3 SIP REGISTER REGISTER sip:registrar.home.com Via: SIP/2.0/UDP proxyUA1.visited.com:5060 From:UserA To: UserA Call-ID: 63158@proxyUA1.visited.com Cseq: 16 REGISTER Contact: userA@proxyUA1.visited.com Expires: 7200 Content-Length: 0 Idnani Expires - March 2003 [Page 5] Internet Draft New parameter for contact Header October 2002 F4 200 OK SIP/2.0 200 OK Via: SIP/2.0/UDP registrar.home.com:5060 From:UserA To: UserA Call-ID: 63158@proxyUA1.visited.com Cseq: 16 REGISTER Contact: userA@proxyUA1.visited.com;created=2002-03-18:12:24:31 Contact: userA@proxyUA2.visited.com;created=2002-03-18:18:19:35 Content-Length:0 F5 SIP REGISTER REGISTER sip:registrar.home.com Via: SIP/2.0/UDP proxyUA1.visited.com:5060 From:UserA To: UserA Call-ID: 63158@proxyUA1.visited.com Cseq: 17 REGISTER Contact: userA@proxyUA1.visited.com Expires: 0 Content-Length: 0 F6 200 OK SIP/2.0 200 OK Via: SIP/2.0/UDP registrar.home.com:5060 From:UserA To: UserA Call-ID: 63158@proxyUA1.visited.com Cseq: 17 REGISTER Contact: userA@proxyUA2.visited.com;created=2002-03-18:18:19:35 Content-Length:0 6. Security Considerations This draft does not introduce any new security threats. 7. References [1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: Session Initiation Protocol", draft-ietf-sip-rfc2543bis-09 (work in progress),February 2002 [2] S. Bradner, "Key words for use in RFCs to indicate requirement levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. Idnani Expires - March 2003 [Page 6] Internet Draft New parameter for contact Header October 2002 Author's Addresses Ajaykumar Idnani Motorola 1301 E Algonquin Road Schaumburg, IL 60196 Email: Ajaykumar.idnani@motorola.com 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. 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 Idnani Expires - March 2003 [Page 7]