Internet Engineering Task Force Internet Draft A.Idnani, Document: draft-idnani-sip-comb-reg-subscr-00.txt S.Upp, Expires: March 2003 T. Hallin Motorola October 2002 SIP Combined Registration and Subscription 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 that the headers of REGISTER and SUBSCRIBE be combined, so that a REGISTER message can also be treated as an implicit subscription for events. This memo identifies the need for doing this, and then explains how combining the Registration and Subscription solves the problem. It also presents an example flow demonstrating the use of this combined registration and subscription. The headers being combined will be made optional in the REGISTER and SUBSCRIBE messages - depending on where they do not appear as of today - so that backward compatibility is maintained. 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 [7]. Idnani, Upp, Hallin Expires - March 2003 [Page 1] SIP Combined Registration and Subscription October 2002 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Background on SIP Events . . . . . . . . . . . . . . . . . . 3 3. Proposed Solution . . . . . . . . . . . . . . . . . . . . . 4 4. SIP Registrar . . . . . . . . . . . . . . . . . . . . . . 5 5. Proxy UA . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . 6 7. Call Flows . . . . . . . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction This memo tries to solve a problem that occurs in any situation in which a SIP User Agent caches or in any way 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 memo also 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, which is his logical address, to his/her current location [1]. The contact addresses are centrally registered with a SIP Registrar using a SIP REGISTER message. UAs can also subscribe with presence servers, to get the presence information of other UAs, using the SIP SUBSCRIBE request message. The presence servers send a NOTIFY message to the subscribers, when the presence information changes 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 problem is more evident where you have a SIP gateway that talks proprietary protocols to the MS and maintains the MSĘ presence in the Idnani, Upp, Hallin Expires - March 2003 [Page 2] SIP Combined Registration and Subscription October 2002 SIP Registrar by sending SIP REGISTER messages to the SIP Registrar on the MSĘ behalf. In some terms the SIP gateway behaves like a proxy UA to a SIP Registrar. When the MS moves to another SIP gateway, the new gateway would also send a SIP REGISTER to the SIP Registrar, and record itself as being in the path to the MS. However the data at the old SIP gateway has not been updated, and the old SIP gateway is not aware of the fact that the MS has moved to a new SIP gateway. 2. Background on SIP Events Before we go ahead with the solution, it is important to understand how event notification works in SIP. So here is a brief description on SIP event notifications. In general entities in the SIP network can subscribe for resource or state changes with other SIP entities in the network, and these entities can send notifications back to the subscriber, when the state changes. A typical flow of messages would be as follows +------------+ +----------+ | Subscriber | | Notifier | +------------+ +----------+ | | | SUBSCRIBE | Request state subscription |----------------------->| | | | 200 OK | Acknowledge subscription |<-----------------------| | | | NOTIFY | Return current state information |<-----------------------| | | | 200 OK | |----------------------->| | | | NOTIFY | Return current state information |<-----------------------| when state changes | | | 200 OK | |----------------------->| | | Subscriptions are expired like registrations and should be renewed by subsequent SUBSCRIBE messages. It is also important to understand what presence is and how SIP entities use SUBSCRIBE and NOTIFY methods to communicate presence Idnani, Upp, Hallin Expires - March 2003 [Page 3] SIP Combined Registration and Subscription October 2002 data. Presence according to RFC 2778 [5] is subscription and notification of changes in the communication state of a user. This communications state consists of the set of communications means, communications address and status of that user. A normal SUBSCRIBE - NOTIFY flow for presence data communication is as follows +---------+ +----------+ +---------+ | Watcher | | Presence | | PUA | +---------+ | Server | +---------+ | +----------+ | | | | | SUBSCRIBE | | |---------------------->| | | | | | 200 OK | | |<----------------------| | | | | | NOTIFY | | |<----------------------| | | | | | 200 OK | | |---------------------->| | | | | | | Update Presence | | |<----------------------| | | | | NOTIFY | | |<----------------------| | | | | | 200 OK | | |---------------------->| | | | | In the above diagram a watcher (some UA) subscribes for the presence data of PUA with the presence server. The Presence server immediately replies back with the current presence data of the PUA in the NOTIFY message. At a later time, when the PUA updates its presence data by some means (could use SIP REGISTER message), the presence server again notifies the watcher, with the new presence data. 3. Proposed Solution In a legacy mobile world, the problem would be solved by the HLR sending a "Cancel Location" message to the old MSC-VLR. Idnani, Upp, Hallin Expires - March 2003 [Page 4] SIP Combined Registration and Subscription October 2002 This memo tries to solve the problem in a similar way but by using SIP messages. Here the SIP Registrar would somehow need to notify the old SIP proxy UA (or SIP gateway) that the MS has moved to a new SIP proxy UA. This memo proposes that - We combine the SIP Registrar and the Presence Server. However the Registrar and the Presence Server should process the expirations of registrations and subscriptions independently. This basically means that even if a registration may have expired due to a contact being overwritten, the subscription will still be active, until the expiration timer runs out. A user can however explicitly de-subscribe by sending a SUBSCRIBE with "Expires" header set to 0, or by sending a combined SIP REGISTER and SUBSCRIBE method (as described below), with the "Expires" header set to 0. - It further proposes that we combine the headers of SIP REGISTER method and SIP SUBSCRIBE method so that an explicit SUBSCRIBE is not required. This invention proposes that the SUBSCRIBE header "Event" be made optional in the SIP REGISTER message. Currently the header is not supported in the REGISTER message. When the SIP Registrar + SIP Presence Server sees a REGISTER message with an "Event" header, it SHOULD implicitly subscribe the UA for the event mentioned (presence in this case). So when the presence information changes - like the contact address being replaced with a new one, or a new contact address being added to the contact list - the old contact (proxy UA or SIP gateway in our case) SHOULD be notified of the change. - This memo also proposes that a NOTIFY SHOULD not be sent immediately on receiving the REGISTER, since the proxy UA would have all the required information on presence, or would get it in the 200 OK response. So a NOTIFY SHOULD only be sent when the presence information changes like when the old contact is removed, or a new contact address is added, the old contact SHOULD to be informed of this change. 4. SIP Registrar The SIP Registrar SHOULD also act as a Presence Server in this case. The SIP Registrar SHOULD subscribe the Proxy UA to presence information when it receives the combined SIP REGISTER and SUBSCRIBE message. If there is already a contact address for the subscriber being registered, and the contact is subscribed for presence information, a NOTIFY message SHOULD be sent to the old contact to inform it about the change in presence data. The Presence Server will remove subscriptions on expiry. Idnani, Upp, Hallin Expires - March 2003 [Page 5] SIP Combined Registration and Subscription October 2002 5. Proxy UA The Proxy UA SHOULD send the new combined SIP REGISTER + SIP SUBSCRIBE message to the SIP Registrar. It SHOULD also be capable of handling a NOTIFY message. It MAY use the message to update its local database 6. Backward Compatibility The modification being proposed in this memo is backward compatible since the header is being made optional in the SIP REGISTER message. If the header is not present, the message is same as before, so the SIP Registrar SHOULD behave as usual. 7. Call Flows +----+ +-----------+ +-----------+ +---------------+ | MS | | Proxy UA1 | | Proxy UA1 | | SIP Registrar | +----+ +-----------+ +-----------+ | + Presence Srv| | | | +---------------+ | F1 Update Presence | | |--------------->| | | | using standard | | | | cellular protocols | | | | F2 SIP REGISTER | (combined subscribe)| | |-------------------|-------------------->| | | | | | | F3 200 OK | | | |<------------------|---------------------| | | | | | F4 Update presence using standard | | |----------------|------------------>| | | cellular protocols | | | | | F5 SIP REGISTER | | | |-------------------->| | | | (combined subscribe)| | | | | | | | F6 200 OK | | | |<--------------------| | | | | | | F7 SIP NOTIFY | | | |<------------------|---------------------| | | | | | | F8 200 OK | | | |-------------------|-------------------->| | | | | Idnani, Upp, Hallin Expires - March 2003 [Page 6] SIP Combined Registration and Subscription October 2002 In the above flow, Proxy UA1 does a combined SIP Registration and Subscription. The expiration interval for both will be set by the Expires header in the SIP REGISTER message. We can also use the tag parameter with the Contact header, so that when the user moves from one proxy to another, the tag parameter can be used to replace the old contact addresses at the SIP Registrar. The SIP Registrar would NOTIFY the old proxies of this change. MESSAGE DETAILS F1 Update Presence using standard cellular protocols. This would be a standard message (depending on the mobile technology and provider) going from the MS to a SIP Gateway in the providerĘs network. F2 SIP REGISTER REGISTER sip:registrar.home.com Via: SIP/2.0/UDP proxyUA1.visited.com:5060 From:UserA To: UserA Accept: application/cpim-pidf+xml Call-ID: 123456@proxyUA1.visited.com Cseq: 14 REGISTER Contact: userA@proxyUA1.visited.com; tag=5551212 Event: presence Expires: 7200 Content-Length: 0 F3 200 OK SIP/2.0 200 OK Via: SIP/2.0/UDP registrar.home.com:5060 From:UserA To: UserA Call-ID: 123456@proxyUA1.visited.com Cseq: 14 REGISTER Contact: userA@proxyUA1.visited.com Content-Length:0 F4 Update Presence using standard cellular protocols. This would be a standard message (depending on the mobile technology and provider) going from the MS to a SIP Gateway in the providerĘs network. F5 SIP REGISTER REGISTER sip:registrar.home.com Via: SIP/2.0/UDP proxyUA2.visited.com:5060 From:UserA To: UserA Idnani, Upp, Hallin Expires - March 2003 [Page 7] SIP Combined Registration and Subscription October 2002 Accept: application/cpim-pidf+xml Call-ID: 63158@proxyUA2.visited.com Cseq: 1 REGISTER Contact: userA@proxyUA2.visited.com;tag=5551212 Event: presence Expires: 7200 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@proxyUA2.visited.com Cseq: 1 REGISTER Contact: userA@proxyUA2.visited.com Content-Length:0 F7 SIP NOTIFY NOTIFY sip:userA@proxyUA1.visited.com Via: SIP/2.0/UDP registrar.home.com:5060 From:UserA To: UserA Call-ID: 123456@proxyUA1.visited.com Cseq: 1 NOTIFY Contact: userA@proxyUA2.visited.com Content-Type: application/cpim-pidf+xml Content-Length: .. [PIDF Document] F8 200 OK SIP/2.0 200 OK Via: SIP/2.0/UDP proxyUA1.visited.com:5060 From:UserA To: UserA Call-ID: 123456@proxyUA1.visited.com Cseq: 1 NOTIFY Contact: userA@proxyUA2.visited.com Content-Length:0 8. Security Considerations This draft does not introduce any new security issues. Idnani, Upp, Hallin Expires - March 2003 [Page 8] SIP Combined Registration and Subscription October 2002 9. 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] H. Schulzrinne, "SIP Registration" Internet Draft, Internet Engineering Task Force, April 2001 [3] D. Crocker, A. Diacakis, F. Mazzoldi, C. Huitema, G. Klyne, J. Rosenburg, R. Sparks, and H. Sugano, "Common Presence and Instant Messaging (CPIM)", Internet Draft, Internet Engineering Task Force, November 2001 [4] Adam Roach, "SIP-Specific Event Notification", Internet Draft, Internet Engineering Task Force, February 2002 [5] M.Day, J. Rosenberg and H. Sugano, "A Model for Presence and Instant Messaging", Request for Comments 2778, Internet Engineering Task Force, February 2000 [6] J. Rosenberg, D. Willis, R. Sparks, B. Campbell, H. Schulzrinne, J. Lennox, C. Huitema, B. Aboba, D. Gurle, and D. Oran, "Session Initiation Protocol (SIP) Extensions for Presence", Internet Draft, Internet Engineering Task Force, April 2002 [7] S. Bradner, "Key words for use in RFCs to indicate requirement levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. Author's Addresses Ajaykumar Idnani Motorola 1301 E Algonquin Road Schaumburg, IL 60196 Email: Ajaykumar.Idnani@motorola.com Steve Upp Motorola 1301 E Algonquin Road Schaumburg, IL 60196 Email: Steve.Upp@motorola.com Thomas Hallin Motorola Idnani, Upp, Hallin Expires - March 2003 [Page 9] SIP Combined Registration and Subscription October 2002 1700 E. Golf Road 10Th. Floor Schaumburg, IL 60173 Email: thallin@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, Upp, Hallin Expires - March 2003 [Page 10]