Internet Engineering Task Force MMUSIC WG Internet Draft J.Rosenberg,H.Schulzrinne draft-rosenberg-mmusic-sip-notify-00.txt Bell Laboratories,Columbia U.,MCI Worldcom June 24, 1999 Expires: December 1999 Notification Services in SIP 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 A number of services based on SIP require that users be able to subscribe to, and be notified of, SIP related events. Rather than developing separate protocols for each subscribe/notify mechanism, we propose a common framework for these services. We then discuss some specific services that make use of this framework, such as camp-on and message-waiting indicators. 1 Introduction As Internet telephony gains momentum, the issue of how to provide features grows in importance. Traditional telephony has hundreds of call features, many obscure, that are provided by switches and PBX's. There appear to be three different ways in which these features can be provided in IP telephony: J.Rosenberg,H.Schulzrinne [Page 1] Internet Draft SIP Notification June 24, 1999 o End systems are dumb, and invoke features through stimulus signaling. How these features are defined and implemented is handled in smart network servers. This is the model supported by megaco [1] o End systems are smart. They invoke features by sending specific messages defined for each feature. This is the approach used in protocols like H.450. o End systems are smart. They invoke features by sending specific messages that cause well-defined, general purpose behaviors to be executed at the recipient. Services are constructed by sending appropriate combinations of messages. It is our belief that the end to end architecture of the Internet dictates intelligent endpoints which signal their own services. However, we do not believe defining messages specifically for each service, one at a time, will result in a usable and deployable protocol. Our aim, therefore, is to take the middle road - to define general purpose signaling tools that can be used as building blocks to construct more complex services. We observe that this building block approach to protocol design is pervasive throughout the Internet suite, particularly recent work in reliable multicast and congestion management []. We observe that call features can be broken into a number of classes, with the features in each class being roughly similar. For example, a large number of features are related to call routing logic - the various screening services, forwarding services, follow-me services, and number translation services. These services are supported in large part by SIP [2] as is. Other services are related to participant management - transfer, add-party, ad-hoc conference, call and bridging. These services are supported by the call control primitives defined in [3]. Yet another class of services is related to subscription to, and notification of, call related events. These features include message waiting lamps, camp-on, conference join notifications, and so on. The purpose of this draft is to address this class of services, and to unify SIP related notifications across these services. 2 Types of Notifications We can break down subscription and notification services into several types: Session Notifications Certain events are session related events. These include termination of a fax transmission [4], joining of a member to a loosely coupled conference (learned by RTCP [5]), J.Rosenberg,H.Schulzrinne [Page 2] Internet Draft SIP Notification June 24, 1999 achievement of a certain loss rate for voice, and so on. These events do not relate to SIP itself, but to the sessions that SIP initiates. Location Service Notifications One of SIPs primary functions is call routing. This routing depends on name translations done at each intermediate SIP server. These translations can be dynamic. For example, the SIP REGISTER message establishes bindings that are used for translations. These registrations are dynamic, and can expire or be updated. Notifications can be delivered when these changes occur. Call State Notifications SIP endpoints participate in calls. The state associated with this includes current call state (proceeding, alerting, active, done), number of calls, list of participants for each call, and even SIP parameters used in the messages that established the call (such as priority). Changes in these calls states are another class of events which can be subscribed to. Service Logic Notifications Call servers can automatically reject calls, redirect calls, maintain call logs, or record messages when a call arrives but the called party is unavailable. This state can be subscribed to. To facilitate subscriptions to and notifications of these events, we make use of the SUBSCRIBE and NOTIFY methods presented in [4]. SUBSCRIBE allows a client to ask a server for notifications about a resource. The resource named in the request URI is always the user about whom the notifications are desired. We also believe that it is useful to add a SIP header which indentifies the type of information that is being subscribed to (session notifications, registration notifications, or call state notifications). We believe this information belongs in a SIP header rather than in the payload, since it can affect call routing. For example, subscriptions to call state can be handled in many places. A call state aware proxy server can provide it, or an end user can provide it. However, in most cases, only the proxy server can provide notifications of changes in registration state. This requires the information on what is being subscribed to to be present in the headers. 3 Subscribe-To The Subscribe-To header specifies the nature of the information that is being subscribed to. The syntax of the header is: J.Rosenberg,H.Schulzrinne [Page 3] Internet Draft SIP Notification June 24, 1999 Subscribe-To = ``Subscribe-To'' ``:'' sub-tokens sub-tokens = 1#sub-item sub-item = call-sub | session-sub | name-sub | message-sub call-sub = ``call'' [call-sub-params] session-sub = ``session'' name-sub = ``registrations'' message-sub = ``messages'' call-sub-params = ``;'' c-params c-params = callid-param | detail-param callid-param = ``call-id'' ``='' token detail-param = ``details'' The header contains a list of information that is being subscribed to. "call" indicates that a call is being subscribed to. If the call-id parameter is present, the call being subscribed to is the one indicated by the parameter. If not present, the subscription is for all calls. The detail parameter indicates whether the subscriber wishes to know detailed information about the call, or whether just the basic call state is conveyed. The "session" and "registration" values indicate subscriptions for session and registration information, respectively. Session subscriptions are always for the same Call-ID as the SUBSCRIBE request. The "messages" value indicates a subscription for messages at a messaging server. Subscriptions cause sensitive information to be conveyed in notifications. As a result, subscribe requests for a particular call-ID should only be accepted from participants in the call, or by specific trusted parties. In either case, subscribe requests should always be authenticated. 4 Subscribing to calls When a server receives and accepts a subscription for call state, it should send a 200 OK containing the current call state. Transitions in call state should generate notifications to the Contact address listed in the subscription. Notifications carry the same Call-ID as the subscription which triggered them. The body of the notification contains the call state. There are many types which can be used to convey call state. The type is especially dependent on whether detailed information was requested or not. 4.1 Basic call state notifications J.Rosenberg,H.Schulzrinne [Page 4] Internet Draft SIP Notification June 24, 1999 If the subscription was for basic call state information, the notification contains: 1. For each call, the name of the participant who initiated the call, or who was called by the subscribee. In the case of a multi-party call, only one participant will be listed, and the fact that the call is multiparty is not conveyed. 2. For each call, the call state. This is one of proceeding, alerting, connected, and terminated. To convey this information, we propose the use of the MIME type text/uri-list. Each URI represents a single call. If the call was initiated by the subscribee, the URI is that which was placed in the To field of the INVITE. If the call was not initiated by the subscribee, the URI is the one which appeared in the From field of the INVITE. We also propose the use of a new URI-parameter, call- state, to convey the call state. This URI parameter would only be valid within this MIME type. It is a hack, but presents a simple way to convey the call state without defining new types or formats beyond what is already used in a SIP client. An example notification when a call is accepted might look like: NOTIFY sip:subscriber@company.com SIP/2.0 Call-ID: 3 CSeq: 8 NOTIFY Subscribe-To: call To: sip:subscriber@company.com From: sip:subscribee@university.edu Content-Type: text/uri-list Content-Length: 33 #this is a comment sip:participant@startupcompany.com;call-state=connected When the call is hung up: NOTIFY sip:subscriber@company.com SIP/2.0 Call-ID: 3 CSeq: 9 NOTIFY Subscribe-To: call To: sip:subscriber@company.com From: sip:subscribee@university.edu J.Rosenberg,H.Schulzrinne [Page 5] Internet Draft SIP Notification June 24, 1999 Content-Type: text/uri-list Content-Length: 33 #this is a comment sip:participant@startupcompany.com;call-state=terminated 4.2 Detailed call information When the subscription is for detailed call information, the notifications contain: 1. The set of calls, and their call states 2. For each call, the list of participants (call-legs) 3. For each participant, the SIP message which caused the call leg to have its state transition. To support this, we propose the use of MIME multipart. Each multipart contains information for a different call. Within each multipart, there is either a SIP message (whenever the call is with one party), or another multipart (whenever the call is multi-party). The MIME type for a SIP message is XXX. The particular SIP message is the one which triggered the state transition. For a call which has just been initiated, its the INVITE. For a call that is proceeding, its the 100, for a call thats alerting, its the 180, for a call thats connected, its the 200, and for a call that is terminated, its the BYE, CANCEL, or error response. A notification is sent whenever a message arrives which changes a call state with a participant. Note that the entire state is sent in each notification, rather than the specific component which changed. For example, the following notification is sent for a subscribee who is in a one one-party call and one two-party call, where one of the participants in a two party call has disconnected (for brevity, we omit most of the SIP message): NOTIFY sip:subscribee@company.com SIP/2.0 Call-ID: 3 CSeq: 9 NOTIFY Subscribe-To: call To: sip:subscriber@company.com J.Rosenberg,H.Schulzrinne [Page 6] Internet Draft SIP Notification June 24, 1999 From: sip:subscribee@university.edu Content-Type: multipart/mixed;boundary=----3 Content-Length: 233 ----3 Content-Type: text/rfc2543 Content-Length: 48 SIP/2.0 200 OK From: sip:jack@call1.com To: sip:subscribee@lucent.com ----3 Content-Type: multipart-mixed;boundary=----4 Content-Length: 100 ----4 Content-Type: text/rfc2543 Content-Length: 48 SIP/2.0 200 OK From: sip:bob@call2.com To: sip:subscribee@lucent.com ----4 Content-Type: text/rfc2543 Content-Length: 48 BYE sip:subscribee@lucent.com From: sip:bill@call2.com To: sip:subscribee@lucent.com section{Subscribing to Registrations} Subscriptions to registration information are normally processed at a registrar. The 200 OK for an accepted subscription contains the current set of registrations for the subscribed party (identified in the request URI). When the registration status of the subscribed address changes, the entire registration for that address is sent in a notification. As with basic call state subscriptions, we use the MIME type text/uri-list to convey registration information. The URI's returned are the same ones that would be placed in the Contact header of a response to a registration for the same address, but without the display name. For example, the following notification might be generated when sip:joe@company.com adds an address through a registration: J.Rosenberg,H.Schulzrinne [Page 7] Internet Draft SIP Notification June 24, 1999 begin{verbatim} NOTIFY sip:subscriber@company.com SIP/2.0 To: sip:subscriber@company.com From: sip:joe@company.com Content-Type: text/uri-list Content-Length: 87 sip:joe@host.company.com mailto:joe@company.com 5 Subscribing to Messages Many call features and services are related to receiving notifications from network servers regarding call related information. These notifications include call logs, voicemail messages, and announcements. This information can be generically subscribed to by sending a SUBSCRIBE to the server, in much the same way a registration is sent to a server. The notifications contain MIME bodies of type text/uri-list. These URI's indicate means by which the subscriber can retrieve the message. Some of the possible URLs include: o A SIP URL for calling the server, and using IVR to retrieve the messages "through the phone". o An IMAP URL for retreiving the message through a mail reader. o An HTTP URL for retrieving the message on the web. A URL should be sent for each individual message that is to be retrieved. 6 Subsribing to Sessions The semantics of subscriptions to sessions depend on the particular session that is being subscribed to. This is for further study. 7 Example Services It is our aim that the generic subscription and notification mechanism here enables a host of services. In this section, we discuss some of these. 7.1 Message Waiting Lamp J.Rosenberg,H.Schulzrinne [Page 8] Internet Draft SIP Notification June 24, 1999 In this service, the phone subscribes to messages at a messaging server. The server sends notifications to the phone when messages arrive. The notifications contain SIP URL's where the phone can call back to retrieve the message. 7.2 Camp-On In this service, user A calls user B, but B is busy. Rather than trying back continuously, A sends a subscribe to B for basic call state. As B's state changes, notifications are sent to A. When the notification indicates that A is no longer in a call, A can retry the call. 8 Conclusion This draft has presented some preliminary thinking on a general purpose mechanism for notification related services in SIP. 9 Author's Addresses Jonathan Rosenberg Lucent Technologies, Bell Laboratories 101 Crawfords Corner Rd. Holmdel, NJ 07733 Rm. 4C-526 email: jdrosen@bell-labs.com Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027-7003 email: schulzrinne@cs.columbia.edu 10 Bibliography [1] F. Cuervo, C. Huitema, K. Kelly, B. Rosen, P. Sijben, and E. Zimmerer, "MEGACO protocol proposal," Internet Draft, Internet Engineering Task Force, Mar. 1999. Work in progress. [2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: session initiation protocol," Request for Comments (Proposed Standard) 2543, Internet Engineering Task Force, Mar. 1999. J.Rosenberg,H.Schulzrinne [Page 9] Internet Draft SIP Notification June 24, 1999 [3] H. Schulzrinne and J. Rosenberg, "SIP call control services," Internet Draft, Internet Engineering Task Force, Feb. 1998. Work in progress. [4] L. Conroy and S. Petrack, "The PINT profile of SIP and SDP: a protocol for IP access to telephone call services," Internet Draft, Internet Engineering Task Force, Mar. 1999. Work in progress. [5] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: a transport protocol for real-time applications," Request for Comments (Proposed Standard) 1889, Internet Engineering Task Force, Jan. 1996. J.Rosenberg,H.Schulzrinne [Page 10]