Internet DRAFT - draft-idnani-sip-comb-reg-subscr
draft-idnani-sip-comb-reg-subscr
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 <userA@home.com>
To: UserA <userA@home.com>
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 <userA@home.com>
To: UserA <userA@home.com>
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 <userA@home.com>
To: UserA <userA@home.com>
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 <userA@home.com>
To: UserA <userA@home.com>
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 <userA@home.com>
To: UserA <userA@home.com>
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 <userA@home.com>
To: UserA <userA@home.com>
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]
