SIPPING J. Rosenberg Internet-Draft Cisco Systems Expires: January 14, 2006 July 13, 2005 Registration Coupled Subscriptions in the Session Initiation Protocol (SIP) draft-rosenberg-sipping-reg-sub-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on January 14, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract When a Session Initiation Protocol (SIP) user agent starts up, it registers to the network and initiates numerous subscriptions in order to learn about various network events. This results in a chatty startup procedure which substantially impacts recovery times under avalanche restart. This specification proposes a mechanism whereby the subscriptions can be established as a side effect of the registration, alleviating this problem. Rosenberg Expires January 14, 2006 [Page 1] Internet-Draft Registration Coupled Subscriptions July 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 5 3.1 Overview of Operation . . . . . . . . . . . . . . . . . . 5 3.2 User Agent Behavior . . . . . . . . . . . . . . . . . . . 8 3.3 Registrar Behavior . . . . . . . . . . . . . . . . . . . . 9 3.3.1 REGISTER Processing . . . . . . . . . . . . . . . . . 9 3.3.2 PUBLISH Processing . . . . . . . . . . . . . . . . . . 10 3.4 Event Server Behavior . . . . . . . . . . . . . . . . . . 11 3.5 Subscription Header Field . . . . . . . . . . . . . . . . 13 3.6 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.6.1 Registrar has Dialog Ownership . . . . . . . . . . . . 14 3.6.2 Event Server Owned Dialog . . . . . . . . . . . . . . 16 3.6.3 Hybrid Model . . . . . . . . . . . . . . . . . . . . . 17 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.1 Normative References . . . . . . . . . . . . . . . . . . . 18 4.2 Informative References . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . 20 Rosenberg Expires January 14, 2006 [Page 2] Internet-Draft Registration Coupled Subscriptions July 2005 1. Introduction When a Session Initiation Protocol (SIP) [1] user agent starts up, it typically follows a series of message exchanges with servers in the network. At a minimum, this startup procedure involves a SIP registration that allows the user agent to receive incoming requests. However, over time, numerous event packages [2] have been defined that provide a user agent with useful information through the duration of its connection to the network. These packages include: Message Waiting: RFC 3842 [11] provides a message waiting indication event package. Typically, a user agent would subscribe to its own Address-of-Record (AOR) for this event package, in order to find out about messages that have been left for that user. This provides the familiar "message waiting lamp" on many business telephones. It is valuable for a user agent to subscribe to this package through the duration of its registration, in the event that messages are explicitly directed to a user's voicemail and do not ring their phone (this can happen, for example, if the caller utilizes the caller preferences specification [12] to direct a call to voicemail). Registration Event: RFC 3680 [13] allows a user agent to learn about the status of its registration. Typically, a user agent would subscribe to its own AOR for this event package, in order to find out if the network has removed its registration. Such removals happen in cases of graceful network shutdown, or when a user needs to re-register and re-authenticate due to concerns on validity of credentials. Presence List: A user may have a "buddy list", which contains a list of users whose presence is desired. A user will subscribe to their buddy list using an event list subscription [14] to the presence event package [15]. This is done by subscribing to a resource that is synonomous with the user's own buddy list. Watcher Info: In order to find out about attempts that have been made to subscribe to a users presence, that user makes use of the watcher info event template package [16]. They would do this by subscribing to their own AOR with the presence.winfo event package. Subscription attempts that are unauthorized will result in a notification, informing the user of this fact and allowing them to approve or deny the subscription. Dialog Events: Certain features, such as single line extension, require a user agent to find out about calls in progress on other user agents associated with the same AOR. This is done through subscriptions to the dialog event package [17]. The user agent Rosenberg Expires January 14, 2006 [Page 3] Internet-Draft Registration Coupled Subscriptions July 2005 would typically subscribe to their own AOR, and learn about calls in progress to other user agents. Configuration Events: The configuration event package [18] allows a UA to learn about changes in its configuration. This is done by having the UA subscribe to its own identity (which may be the AOR) for the config event package. As a consequence of this, each time a user agent starts up, they will generate a REGISTER transaction, plus a SUBSCRIBE and a NOTIFY transaction for each event package the user agent is interested in. Based on the above discussion, this could be upwards of six event packages, resulting in a total of fourteen transactions that take place on startup. Furthermore, each of these subscriptions needs to be periodically refreshed (as does the registration), resulting in ongoing messaging. This overhead is particularly problematic during an avalanche restart. This occurs when a failure event of some sort causes all user agents to simultaneously re-register. This is most common when recovering after a power outage. When the power returns, all the user agents will start booting simultaneously, and at the same time, each will execute their startup sequence. The more complex this sequence, the longer it takes for the system to return to service, and the more robust the network has to be. Another cause of avalanche restart is recovery after a catastrophic network failure, such as a network partition. If a network partition should last longer than the subscription lifetime, once the partition heals, each client will discover this and attempt to re-register and re-subscribe to each event package. The overhead is also problematic on wireless links and other interfaces where bandwidth is at a premium. 2. Requirements A solution to this problem should meet the following requirements: 1. The solution must substantially reduce the amount of SIP messaging traffic that takes place when a user agent starts up. 2. The solution must substantially reduce the amount of network processing that needs to take place when a user agent starts up. 3. The solution must not fundamentally alter the event model of RFC3265. Rosenberg Expires January 14, 2006 [Page 4] Internet-Draft Registration Coupled Subscriptions July 2005 3. Proposed Solution This document proposes a solution to this problem, based on the following observations: 1. In all of the above cases, the subscription is desired for the duration of the registration of the UA. 2. In all of the above cases, the user agent is subscribing to a resource which it owns; either its AOR or a related resource, like a buddy list. As a consequence, the authorization policies for the subscriptions always allow that user to subscribe. A policy in which a user can subscribe to their own events are called "self authorization". 3.1 Overview of Operation Based on these observations, the approach proposed here is to strongly couple subscriptions with registrations, and to actually use the registration to create the subscriptions. A subscription that is created as a result of a successful registration is called a registration-coupled subscription. The basic approach is shown in Rosenberg Expires January 14, 2006 [Page 5] Internet-Draft Registration Coupled Subscriptions July 2005 +-----------+ +-----------+ +-----------+ | | | | | | | Event | | Event | | Event | | Server | | Server | | Server | | | | | | | +-----------+ +-----------+ +-----------+ \ | / \ | / \ | / \ | / \ | / PUBLISH \ | / V V / +-----------+ V | | | Registrar | | | | | +-----------+ | | | | REGISTER+ | NOTIFY | +--------+ | | | UA | | | +--------+ Figure 1 To create a registration-coupled subscription, a UA includes a Subscription header field in its REGISTER message. This header field includes a list of the desired event packages, and for each, the resource to which a subscription is desired and any event header field parameters. There is no need for a Require header field. The registrar looks for the Subscription header field. For each value, it examines the event package and target resource. If the resource is in the domain of the registrar, and the resource has an authorization policy of "self", and the registrar allows registration coupled subscriptions for that event package, the registrar creates the dialog and a subscription. The 200 OK to the REGISTER contains an indication of whether the subscription was created, and if so, the remote tag needed to complete the dialog identifier. The UAC will create a dialog and a subscription for each value of the Rosenberg Expires January 14, 2006 [Page 6] Internet-Draft Registration Coupled Subscriptions July 2005 Subscription header field in the response. As there will be one of these per event package, the end result is a single dialog for each event package that the client wants to subscribe to. Dialogs are not shared across event packages. The dialog identifiers are obtained by copying the Call-ID and local tag from the REGISTER, with the remote tag from the Subscription header field value. Similarly, the registrar will create a subscription. The dialog identifiers and local sequence number are set in the same way. Its route set is taken from the Path header field from the registration [4]. At this point, a proper subscription is established at the UA and the registrar. The registrar can send a NOTIFY at any time. The initial NOTIFY normally sent upon receipt of a SUBSCRIBE is not required, as the REGISTER response serves that purpose. The subscriptions are all refreshed through registration refreshes. If the UAC omits an event and resource from a Subscription header field in its REGISTER, it means that the client wishes to unsubscribe. Similarly, if the 200 OK to the REGISTER omits that event package and resource, it means that the subscription was terminated. However, the client cannot ever send a SUBSCRIBE to refresh the subscription. Any such request is rejected with a 403. It is important to note that there is a dialog properly established as part of this mechanism. The dialog is established by providing the dialog parameters through the registration, and then to make the dialog state part of the registration state. The dialog is then refreshed and maintained just like registration state. If a user has multiple user agents registered to the same AOR, multiple dialogs would be created. This means that the dialogs terminate on the registrar as well. In order for events to be delivered to the clients in NOTIFY messages, an event server generates a PUBLISH message when it wants to send an event to a user agent. The PUBLISH is routed to the registrar, where it examines the URI in the request URI. If the user is registered, it goes through each registered contact. If the registration of that contact had created a coupled subscription, the registrar checks if the registration-coupled subscriptions include the event package in the PUBLISH. If they do, the registrar copies the event data in the body of the PUBLISH into a NOTIFY, and sends it to the user agent. As an additional mechanism, the event servers themselves can subscribe to the registration event package for all subscribers. WHenever a user registers, a notification would get delivered to the event server. It can then check which users are registered or not, and use this information to determine whether or not it wishes to send a PUBLISH. Alternatively, the reg-event notifications can contian all of the information on the registration-coupled subscriptions - their dialog identifiers, event packages, and so on. Rosenberg Expires January 14, 2006 [Page 7] Internet-Draft Registration Coupled Subscriptions July 2005 This would allow the event server itself to "take over" the subscription, and take ownership of the dialog. In that case, it can send the NOTIFY directly, instead of sending a PUBLISH to the registrar. Indeed, the event server can make a decision on a subscriber-by-subscriber basis as to whether it wishes to own the dialogs or not. 3.2 User Agent Behavior A user agent SHOULD be configured with a set of event packages that it wishes to couple with its registrations. For each such package, when the client performs its initial registration, it includes a Subscription header field value into its request. That value contains the address-of-record for the target of the subscription. This AOR MUST be one within the same domain as the domain of registration. Typically, it will be the same as the AOR for the user themselves. The UA includes any parameters it would otherwise include in the Event header field into the Subscription header field. The UA SHOULD include an Accept header field in the request, and include the content types the client supports for that event package. Otherwise, the registration is generated identically to a normal registration. If the response to the REGISTER is a 200 OK, the client looks for the Subscription header field. If the header field is not present, the user agent knows that either this mechanism is not supported in the registar, or is supported, but not in use for any of the event packages requested by the client. In that case, the user agent SHOULD proceed with a normal subscription according to the specifics of the event packages the client is interested in. If the 200 OK response to the REGISTER did contain a Subscription header field, the user agent goes through each value. It constructs a dialog by setting the Call-ID to the value in the REGISTER response, the local tag to the From tag the client placed in the REGISTER request, and the remote tag from the value of the Subscription header field. The local URI is set to the value in the From header field of the REGISTER request, and the remote URI to the value in the To header field of the REGISTER request. The local and remote CSeq are initially empty. Since the client never sends a request within the dialog, the local CSeq never needs to be populated. Similarly, the route set is empty. If the REGISTER request was sent over TLS, and the Request-URI was a sips URI, the "secure" flag for the dialog is set. The dialog state persists for the duration of the registration of that contact. When the UA determines that the contact expires, the dialog state is destroyed. A UA can determine that a contact has Rosenberg Expires January 14, 2006 [Page 8] Internet-Draft Registration Coupled Subscriptions July 2005 expired because it times out and is not refreshed, or because the client receives a registration event notification informing it that the contact has been terminated. If the client had included a Subscription header field in the request for a particular event package, and the REGISTER response contained a Subscrption header field, but that package was not listed, it means that the registrar is either refusing a subscription-coupled registration for that event package, or that subscription failed for some reason. To determine the exact problem, the client SHOULD perform a regular, separate subscription to that event package. At any point during the lifetime of the registration, the client may receive a NOTIFY on the dialog created by the registration. Processing of that NOTIFY happens as described in the relevant event package and according to the details of RFC 3265. A registration refresh occurs identically to an initial registration. A client MUST include a Subscription header field value for each dialog it wishes to retain. If a client omits a Subscription header field value for a particular event package, the dialog associated with that event package is terminated upon receipt of a 200 OK to the REGISTER request. If a client wishes to perform a subscription with event filters that need to be placed in the body of a request, the mechanism here cannot be used. Rather, the client should perform a normal subscription using SUBSCRIBE. An alternative would be to include the event filters as a body of the REGISTER request. Header field parameters could associated each MIME body with a particular event package. However, this introduces a lot of complexity for a corner case. As such, this document recommends just performing a regular subscription to handle these cases. 3.3 Registrar Behavior 3.3.1 REGISTER Processing When a registrar receives a REGISTER request, it processes the registration normally per RFC 3261. If the result would otherwise have been a successful registration resulting in a 200 OK, the procedures defined here are followed. The registrar checks for the presence of the Subscription header field in the REGISTER request. The processing that follows is performed for each value of this header field. Firstly, the registrar checks to see if it supports registration-coupled subscriptions for that particular event package. Performing them for Rosenberg Expires January 14, 2006 [Page 9] Internet-Draft Registration Coupled Subscriptions July 2005 any particular event package is a matter of local policy. Typically, it would be allowed when an event server is present in the network which supports the capabilities defined here. If the registrar doesn't support registration-coupled subscriptions for that event package, it goes on to the next value of the Subscription header field. Otherwise, processing continues. Next, the registrar validates that the resource in the header field value is a valid resource within the domain of the registrar. If it is, processing continues. Otherwise, the registrar goes on to the next value of the Subscription header field. Next, it checks whether or not the UAC is authorized to subscribe to the resource. The means by which authorization occurs is outside the scope of this specification. Typically, registration-coupled subscriptions are performed with subscriptions where the authorization policy is such that a user is allowed to subscribe to themselves, and no others. This authorization policy, called "self", is readily provisioned on the registrar, and would not require complex interactions with other event servers. If the registrar cannot determine authorization, or if the subscription is not authorized, the registrar goes on to the next value of the Subscription header field. Otherwise, processing continues. At this point, the subscription has been authorized. The registrar stores the event header field parameters in the Subscription header field value as part of the state associated with the registered contact. These parameters are carried as a quoted string in the Subscription header field, so that they are readily separable from the Subscription header field parameters. It also stores the event package. The registrar chooses a tag that will serve as the remote tag of the dialog, according to the procedures of RFC 3261. This tag is also stored as part of the state associated with the registered contact. The Call-ID and From tag from the REGISTER request would have already been stored as part of normal registration processing, as would the Path header field value. The registrar also stores the From header field of the REGISTER message. In the 200 OK to the REGISTER request, the registrar includes the Subscription header field. Each value contains the event package name for each registration-coupled subscription that was created, along with the tag that completes the dialog. The AOR SHOULD NOT be included. 3.3.2 PUBLISH Processing This specification allows a registrar to act as an event server for registration-coupled subscriptions. When the registrar receives a PUBLISH message for a particular address-of-record, it checks that Rosenberg Expires January 14, 2006 [Page 10] Internet-Draft Registration Coupled Subscriptions July 2005 the PUBLISH has arrived from an event server that is authorized to publish events for the subscriber. Typically, this is done based on the maintentance of a TLS connection between the registrar and the event server, used to identify the source of the messages to the registrar. The registrar would typically authorize PUBLISH messages for a specific event package only if they came from a specific event server. Once the sender of the PUBLISH is authorized, the registrar performs a registration query for the AOR in the Request-URI of the PUBLISH message. It checks to see if there are any contacts registered for that AOR that have registration-coupled subscriptions for that event package. For each contact it finds, the registrar constructs a NOTIFY message. The Call-ID of this NOTIFY is taken from the stored state associated with the registration. The From header field URI is set to the AOR of the user. The To header field URI is set to the value in the From header field of the most recent REGISTER message. The tag in the From header field is populated with the tag associated with the registration. The tag in the To header field is populated with the tag stored with the Contact. The Event header field of the NOTIFY is set to the event header field stored with the Contact. The body of the NOTIFY is taken from the body of the PUBLISH. The remainder of the NOTIFY is consructed as per RFC 3261, and then sent as a mid-dialog request. The registrar then generates a 200 OK to the PUBLISH request. If the registrar found no matching registration-coupled subscriptions for the PUBLISH, it generates a 403 response to the PUBLISH request. This informs the event server that its event was not delivered. 3.4 Event Server Behavior It is assumed that event servers learn about events for a particular package for a particular subscriber through any number of means. These can include non-SIP mechanisms, SIP subscriptions to a resource, and so on. However, they cannot include a SIP PUBLISH message sent to the AOR of the subscriber; those PUBLISH messages are routed to the registrar according to this specification. An event server MAY act as the dialog owner, or MAY leave that responsibility to the registrar. However, it MUST NOT do both for the same subscriber within the duration of a registration from that subscriber. To act as a dialog owner, the event server subscribes to the registration event package. It MAY subscribe to this event package for each subcscriber individually, or it MAY subscribe to a resource that represents all subscribers or a group of users at the registrar (for example, sip:all-users@example.com). The latter is preferable since it avoids the need for per-user subscription Rosenberg Expires January 14, 2006 [Page 11] Internet-Draft Registration Coupled Subscriptions July 2005 maintenance at the event server. The notifications of the dialog event package will contain information on each registration-coupled subscripton for a subscriber. If the event server is acting as a dialog owner, it MUST store this information. Effectively, the reg-event notification creates the dialog state and the event subscription at the event server. When the event server wishes to send an event, it creates a NOTIFY using the dialog state and sends it, per RFC 3265 and RFC 3261 procedures. These NOTIFY messages won't even traverse the registrar. If the event server is not acting as a dialog owner, when it wishes to send a notification, it sends a PUBLISH message. The request-URI of the PUBLISH is set to the AOR of the subscriber for whom a notification is to be delivered. The content of the PUBLISH contains the event state that is to be delivered to the watcher. The Event header field is populated with the value of the event package for which the notifications are intended. This PUBLISH message is sent, and will be routed to the registrar. The processing above will result in a NOTIFY being sent to each registered contact for that AOR. The choice of whether to act as dialog owner or not depends on several factors. When the event server leaves dialog ownership to the registrar, it alleviates the need for the event server to maintain any kind of per-subscriber state. However, it imposes additional work on the registrar to perform the registration queries and construction of NOTIFY messages. Thus, this mode is useful for very infrequent events, such as a request to update a configuration profile in the configuration event package. Dialog ownership makes more sense for more frequent events. Also, since the registrar doesnt know the actual event state, it cannot send an initial NOTIFY with the current state when the dialog is first created. It relies on the event server to do that. As a result, if an event package requires state to be delivered as part of a NOTIFY generated when the subscription is created, the event server needs to maintain ownership of the dialog, or the hybrid model below needs to be used. A hybrid model is also possible. An event server can receive reg- event notifications, but not store dialog state. When it sees that the user has registerd or unregistered, it can send a PUBLISH message. This is useful for infrequent notifications that need to be triggered on registration. The hybrid model also allows the event server to generate a PUBLISH when a client first registers, that contains the current value of the event state. This will cause the registrar to send a NOTIFY message with the current state. This is useful for event packages where it is desireable to send event state as part of the initial NOTIFY. Rosenberg Expires January 14, 2006 [Page 12] Internet-Draft Registration Coupled Subscriptions July 2005 The hybrid model is particularly attractive, since it alleviates the need for the event server to maintain any kind of dialog state or per-subscriber subscription state, and yet it allows for the full features of a traditional event subscription. 3.5 Subscription Header Field The grammar for the Subscription header field is: Subscription = "Subscription" HCOLON (sub-param *(COMMA sub-param)) sub-param = event-type *(SEMI sub-param) sub-event-param = sub-aor / sub-event-param / tag-param / generic-param sub-aor = "aor" EQUAL (SIP-URI / SIPS-URI) sub-event-param = "e-param" EQUAL quoted-string Figure 3 and Figure 4 are an extension of Tables 2 and 3 in RFC 3261 [1] for the Subscription header field. The column "INF" is for the INFO method [5], "PRA" is for the PRACK method [6], "UPD" is for the UPDATE method [7], "SUB" is for the SUBSCRIBE method [2], "NOT" is for the NOTIFY method [2], "MSG" is for the MESSAGE method [8], "PUB" is for the PUBLISH method [9], and "REF" is for the REFER method [10]. Header field where proxy ACK BYE CAN INV OPT REG REF Subscription R - - - - - - o - Subscription 2xx - - - - - - o - Figure 3: Subscription header field Header field where proxy PRA UPD SUB NOT INF MSG PUB Subscription R - - - - - - - - Subscription 2xx - - - - - - - - Figure 4: Subscription header field 3.6 Examples Rosenberg Expires January 14, 2006 [Page 13] Internet-Draft Registration Coupled Subscriptions July 2005 3.6.1 Registrar has Dialog Ownership In this example, the registrar holds ownership of the dialog. The event server is a message waiting indicator server that publishes MWI events. UA Registrar MWI Server |(1) REGISTER | | |------------->| | |(2) 200 OK | | |<-------------| | | |(3) PUBLISH | | |<-------------| | |(4) 200 OK | | |------------->| |(5) NOTIFY | | |<-------------| | |(6) 200 OK | | |------------->| | Figure 5: Registrar Owned Dialogs The REGISTER message (1) would look like: REGISTER sip:example.com SIP/2.0 To: sip:joe@example.com From: sip:joe@example.com;tag=asd9887g Subscription: message-summary;aor=sip:joe@example.com Expires: 3600 Via: SIP/2.0/UDP client.biloxi.example.com;branch=z9hG4bKnashds7 Max-Forwards: 70 Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com CSeq: 1 REGISTER Content-Length: 0 Contact: sip:client.biloxi.example.com The 200 OK to the REGISTER indicates successful creation of the dialog: Rosenberg Expires January 14, 2006 [Page 14] Internet-Draft Registration Coupled Subscriptions July 2005 SIP/2.0 200 OK To: sip:joe@example.com;tag=99j9jj From: sip:joe@example.com;tag=asd9887g Subscription: message-summary;tag=ghghghg Expires: 3600 Via: SIP/2.0/UDP client.biloxi.example.com;branch=z9hG4bKnashds7 Max-Forwards: 70 Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com CSeq: 1 REGISTER Content-Length: 0 The PUBLISH from the event server comes when a new message arrives: PUBLISH sip:joe@example.com SIP/2.0 To: sip:joe@example.com From: sip:mwi-server@example.com Event: message-summary Via: SIP/2.0/UDP mwi.example.com;branch=z9hG4bKnashas--d9 Call-ID: 3k9FpLxhg88asd7m8tn@mwi.example.com CSeq: 1 PUBLISH Content-Type: application/simple-message-summary Content-Length: --- Messages-Waiting: yes Message-Account: sip:joe@mwi.example.com Voice-Message: 2/8 (0/2) This results in a notification from the registrar: NOTIFY sip:client.biloxi.example.com SIP/2.0 To: sip:joe@example.com;tag=asd9887g From: sip:joe@example.com;tag=ghghghg Event: message-summary Via: SIP/2.0/UDP reg.example.com;branch=z9hG4bKnashas--d10 Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com CSeq: 1 NOTIFY Content-Type: application/simple-message-summary Content-Length: --- Messages-Waiting: yes Message-Account: sip:joe@mwi.example.com Voice-Message: 2/8 (0/2) Rosenberg Expires January 14, 2006 [Page 15] Internet-Draft Registration Coupled Subscriptions July 2005 3.6.2 Event Server Owned Dialog UA Registrar MWI Server | |(1) SUBSCRIBE | | |<-------------| | |(2) 200 OK | | |------------->| | |(3) NOTIFY | | |------------->| | |(4) 200 OK | | |<-------------| |(5) REGISTER | | |------------->| | |(6) 200 OK | | |<-------------| | | |(7) NOTIFY | | |------------->| | |(8) 200 OK | | |<-------------| |(9) NOTIFY | | |<----------------------------| |(10) 200 OK | | |---------------------------->| When the message waiting server starts up, it subscribes to the registration event package at the registrar (message 1). The request URI identifies all users in the domain. This generates a 200 OK (message 2), followed by a NOTIFY (message 3). This NOTIFY doesn't contain any event state (there is too much), but it confirms the subscription. At some point later, the UA in question registers. The registration sequence (messages 5/6) are as above. This causes a reg-event NOTIFY to be sent to the mwi server (message 7). This tells the server about the creation of a new contact, and also tells it that a MWI registration-coupled subscription was created. It provides the dialog identifiers to the MWI server. Next, the MWI server generates a NOTIFY to tell the client about the event state (9). Rosenberg Expires January 14, 2006 [Page 16] Internet-Draft Registration Coupled Subscriptions July 2005 3.6.3 Hybrid Model UA Registrar MWI Server | |(1) SUBSCRIBE | | |<-------------| | |(2) 200 OK | | |------------->| | |(3) NOTIFY | | |------------->| | |(4) 200 OK | | |<-------------| |(5) REGISTER | | |------------->| | |(6) 200 OK | | |<-------------| | | |(7) NOTIFY | | |------------->| | |(8) 200 OK | | |<-------------| | |(9) PUBLISH | | |<-------------| | |(10) 200 OK | | |------------->| |(11) NOTIFY | | |<-------------| | |(12) 200 OK | | |------------->| | When the message waiting server starts up, it subscribes to the registration event package at the registrar (message 1). The request URI identifies all users in the domain. This generates a 200 OK (message 2), followed by a NOTIFY (message 3). This NOTIFY doesn't contain any event state (there is too much), but it confirms the subscription. At some point later, the UA in question registers. The registration sequence (messages 5/6) are as above. This causes a reg-event NOTIFY to be sent to the mwi server (message 7). This tells the server about the creation of a new contact, and also tells it that a MWI registration-coupled subscription was created. It provides the dialog identifiers to the MWI server. However, instead of sending the NOTIFY, the MWI server discards the dialog information. It sends a PUBLISH request (message 9) identically to the case where the registrar owns the dialog. This causes the registrar to send the notification (message 11). 4. References Rosenberg Expires January 14, 2006 [Page 17] Internet-Draft Registration Coupled Subscriptions July 2005 4.1 Normative References [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [2] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [3] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration", RFC 3608, October 2003. [4] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts", RFC 3327, December 2002. [5] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000. [6] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002. [7] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002. [8] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002. [9] Niemi, A., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004. [10] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003. 4.2 Informative References [11] Mahy, R., "A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP)", RFC 3842, August 2004. [12] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004. [13] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Registrations", RFC 3680, March 2004. Rosenberg Expires January 14, 2006 [Page 18] Internet-Draft Registration Coupled Subscriptions July 2005 [14] Roach, A., Rosenberg, J., and B. Campbell, "A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists", draft-ietf-simple-event-list-07 (work in progress), January 2005. [15] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004. [16] Rosenberg, J., "A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP)", RFC 3857, August 2004. [17] Rosenberg, J., "An INVITE Inititiated Dialog Event Package for the Session Initiation Protocol (SIP)", draft-ietf-sipping-dialog-package-06 (work in progress), April 2005. [18] Petrie, D., "A Framework for Session Initiation Protocol User Agent Profile Delivery", draft-ietf-sipping-config-framework-06 (work in progress), February 2005. Author's Address Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07054 US Phone: +1 973 952-5000 Email: jdrosen@cisco.com URI: http://www.jdrosen.net Rosenberg Expires January 14, 2006 [Page 19] Internet-Draft Registration Coupled Subscriptions July 2005 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 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 procedures with respect to rights in RFC 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 (2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Rosenberg Expires January 14, 2006 [Page 20]