SIP Working Group RajKumar Internet Draft Ivan Expires: September 2006 Mahesh Category: Standards Track September 2006 Asynchronous Service State Notifications From SIP Entities draft-mahesh-sipping-svc-state-notify-00.txt 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 August 27, 2006. Please send comments to the author or the working group discussion list. Abstract This document describes the requirement for in-advance asynchronous service state notifications from a SIP[1] entity to its USER .The notifications MAY be about the state of the entity or the state of the session. It also explains certain mechanisms for implementing the same. This document is divided into three parts . 1)An Event Specification. 2)Use cases for event specification and mechanisms to extend this specification. 3)Limitations and Future work. Mahesh,Ivan,RajKumar Expires September 23,2006 [Page 1] Internet-Draft Asynchronous Service State Notifications February 2006 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[4]. Expires September 23,2006 [Page 1] RFC DRAFT Asynchronous Service State Notifications February 2006 Table of Contents 1 Introduction and Motivation ............................2 2 Definitions.............................................3 3 Requirements............................................3 4 Proposal................................................3 5 Service State Event Package.............................3 5.1 Event Package Name......................................3 5.2 Event package parameters ...............................3 5.3 SUBSCRIBE bodies .......................................3 5.4 Subscription............................................3 5.5 Subscription duration ..................................3 5.6 NOTIFY bodies ..........................................5 5.7 Notifier processing of SUBSCRIBE request ...............5 5.8 Notifier generation of NOTIFY requests..................5 5.9 Subscriber processing of NOTIFY requests ...............5 5.10 Handling of forked requests ............................6 5.11 Service State data format ..............................6 5.12 XML Schema..............................................7 5.13 Example.................................................8 5.14 Rate of notifications ..................................9 6 Working of the scheme ..................................9 6.1 Use cases and Scenarios................................10 6.1.1 Subscription...........................................10 6.1.2 Example for Session termination........................11 6.1.2.1 Calling card example...................................12 6.1.2.2 UA going down..........................................12 Mahesh,Ivan,RajKumar Expires September 23,2006 [Page 2] Internet-Draft Asynchronous Service State Notifications February 2006 6.1.2.3 Example for Out of service.............................13 6.1.3 Example for Service redirection........................14 7 Security Consideration ................................15 8 Limitations and Future work............................16 9 IANA Considerations....................................17 A.1 Discovering Proxy Agent................................18 A.2 Redundancy of Proxy Agent..............................19 A.3 Proxy Agent going down.................................19 A.4 Preventing flooding of SUBSCRIBE messages..............19 A.5 Preventing Overloading from notification...............19 1 Introduction and Motivation The advance knowledge of change of state of the entities in a sip network is helpful in many ways. One such case is graceful change of services.For example an advance notification from an entity that it is going out of service will help other SIP entities to use alternate mechanisms efficiently and continue to deliver services. The ability to notify changes in service state of an entity or a session in advance ,gives the service provider an ability to have better control of the User agents under its domain. This will help the service provider to have capabilities like , reconfiguring the User agents, announcements about service changes, better load control mechanism, managing peak traffic hours , advance redirection for giving different services etc. This is because the advance knowledge of service state changes will be helpful in certain cases where ,mechanisms like DNS some times may have limitations. One typical situation is knowing the exact load situation of the server. This is because only the server can know its exact load situation and processing capabilities . If the method described in the draft used along with existing mechanism of service discovery provides a better method for controlling the services. An advance indication of such changes will help a user agent for doing reconfiguration of the service parameters , using alternate ways for service etc. It also provides the user agent some information which can be conveyed to the user,if the user agent is an endpoint. An advance knowledge about the service state of a peer entity (may be a gateway) going out of service will help the network to change the services gracefully . Currently we don't have a standardized mechanism by which a SIP entity can inform other SIP entities under its domain , about its Mahesh,Ivan,RajKumar Expires September 23,2006 [Page 3] Internet-Draft Asynchronous Service State Notifications February 2006 service state in advance asynchronously .In this draft a proposal for such a frame work is made. The frame work is based on the SIP event notification[2] mechanisms, which uses subscription and notification. We describe a new event called service-state. The event package can be used both inside and out side a session to advertise future service-state changes. 2 Definitions Service state: Any state which affects the service given by an entity.For example , the state of going "out of service". Proxy-Agent : A Proxy-Agent is a notifier[2] , which is capable of publishing state information on behalf of a SIP entity. A proxy-agent notifies the subscriber, after subscriber subscribes for the service-state event. It is strongly recommended that a Proxy-Agent and SIP entity may be co located. A Proxy Agent MUST be able to know the states of the SIP entity. 3 Requirements REQ_1: User Agent Must be able to Subscribe for notifications for change in service state of other SIP entities. REQ_2: A SIP entity must be able to notify other entities about its future changes in its service state. 4 Proposal For achieving the requirements mentioned in section 3 we would like to propose a framework . The framework is based on SIP event notification[2] mechanism ,based on SUBSCIBE and NOTIFY methods. For this we are defining a new event "service-state" and the procedures associated with the event. 5 Proxy Agent The proxy agent can be a conceptual entity. It is a state agent. It can co-locate with a SIP entity. The SIP entity may be a Proxy, B2BUA or a user agent. If proxy agent is not co-located with a proxy , the same questions of discovery, redundancy, out of service, event notification load balancing etc exists .We strongly recommend , that a proxy agent must be co-located with the the SIP Entity whose state the proxy agent is advertizing.If a proxy agent Mahesh,Ivan,RajKumar Expires September 23,2006 [Page 4] Internet-Draft Asynchronous Service State Notifications February 2006 is not co-located ,it may lead to implementation complexity and practical difficulties .If Proxy agent is not co-located we can use the mechanism provided in Appendix A, to tackle the issues with that . 6 Service State Event Package The SIP event framework [2] defines a SIP extension for subscribing and receiving notifications of, events. It leaves the definition of many additional aspects of these events to concrete extensions, also known as event packages. This document qualifies as an event package. 6.1 Event Package Name The SIP Events specification requires package definitions to specify the name of their package or template-package. The name of this package is "service-state". As specified in [2], this header appears in SUBSCRIBE and NOTIFY requests. Example: Event: service-state 6.2 Event package parameters 6.3 SUBSCRIBE bodies This package does not define a SUBSCRIBE body. 6.4 Subscription The subscription can be either implicit or explicit. If the subscription is implicit Allow-Events header with a header value of service-state can be used. For explicit subscription can be done as per SIP events specification[2]. 6.5 Subscription duration The SIP Events specification requires package definitions to define a default value for subscription durations, and to discuss reasonable choices for durations when they are explicitly specified. The duration of subscription SHOULD be specified in the Expires header in the SUBSCRIBE request . It can be recommended that the subscription duration may be slightly longer than registration time. Mahesh,Ivan,RajKumar Expires September 23,2006 [Page 5] Internet-Draft Asynchronous Service State Notifications February 2006 6.6 NOTIFY bodies The SIP Events specification requires package definitions to describe the allowed set of body types in NOTIFY requests, and to specify the default value to be used when there is no Accept header in the SUBSCRIBE request. This specification describes an XML schema which may be present in the NOTIFY request for service-state event. 6.7 Notifier processing of SUBSCRIBE request The SIP Events framework specifies that packages should define any package-specific processing of SUBSCRIBE requests at a notifier, specifically with regards to authentication and authorization. Service state can be sensitive information. Therefore, all subscriptions to it SHOULD be authenticated and authorized before approval. Authentication MAY be performed using any of the techniques available through SIP. 6.8 Notifier generation of NOTIFY requests The SIP Event framework requests that packages specify the conditions under which notifications are sent for that package, and how such notifications are constructed. To determine when a notifier should send notifications of changes in service-state we propose the following mechanism.The Proxy-Agent when it detects some state changes must form a NOTIFY request with a body explaining service-state info .A notifier can wait for some random time before sending notification to the UAs. Also a notifier can send notifications to all the UAs subscribed in a distributed fashion . This scheme is to prevent the notifier from overloading . This reasonable time gap is permissible because a notifier will be able to know the service state in advance ,before the service state change will happen. Also the service state changes have to be informed in such a way that the subscribers under its domain must get enough time to accept the change . 6.9 Subscriber processing of NOTIFY requests The SIP Events framework expects packages to specify how a subscriber processes NOTIFY requests in any package specific ways, and in particular, how it uses the NOTIFY requests to construct a coherent view of the state of the subscribed resource. Typically,the NOTIFY will only contain information about the service-state event. Details regarding the event will be in the XML body associated with the NOTIFY. Section 6.11 describes the application/servicestateinfo+xml format ,which will be present in the service-state notification message .The subscriber must analyze the application/servicestateinfo+xml body present in the NOTIFY body Mahesh,Ivan,RajKumar Expires September 23,2006 [Page 6] Internet-Draft Asynchronous Service State Notifications February 2006 and act accordingly. 6.10 Handling of forked requests This topic is not applicable. 6.11 Service State data format Service state information is an XML document [4] that MUST be well-formed and SHOULD be valid. Service-state information documents MUST be based on XML 1.0 and MUST be encoded using UTF-8. This specification makes use of XML namespaces for identifying service state information documents and document fragments. The namespace URI for elements defined by this specification is a URN [5], using the namespace identifier 'ietf' defined by [6] and extended by [7]. This URN is: urn:ietf:params:xml:ns:servicestateinfo A service state information document begins with the root element tag "servicestateinfo".It consists of any number of "service state" sub-elements, each of which contains the service state for a particular entity (Proxy/Proxy-Agent/Session). The service state information for a particular address-of-record MUST be contained within a single "servicestate" element; it cannot be spread across multiple "servicestate" elements within a document. Other elements from different namespaces MAY be present for the purpose of extensibility; elements or attributes from unknown namespaces MUST be ignored. Note that the document format explicitly allows for conveying information on multiple addresses-of-record. This enables subscriptions to multiple entities(Proxy or Proxy-Agent) . The "servicestate" element has a list of any number of "Alternate" sub-elements, each of which contains information on a single alternate Entity. Other elements from different namespaces MAY be present for the purposes of extensibility; elements or attributes from unknown namespaces MUST be ignored. There are four attributes associated with the "servicestate" element, all of which MUST be present: identity : The identity of object whose service state is being told. state : The state identifies the state to which the serving entity will transisit.This document currently defines only one state "Out Of Service"(OOS). This may be extended later. reason : The reason tells the reason for the state Mahesh,Ivan,RajKumar Expires September 23,2006 [Page 7] Internet-Draft Asynchronous Service State Notifications February 2006 change. grace-period: The grace period is the time frame from which the state change will be in effect . The "Alternate" element contains a "uri" element. Other elements from different namespaces MAY be present for the purposes of extensibility; elements or attributes from unknown namespaces MUST be ignored. There are several attributes associated with the "Alternate" element which MUST be present: id : This is an identifier for the alternate element. q : This if several Alternate fields are there q tells the subscriber a scheme for giving priority for each of the alternate ones. effectiveFrom : This parameter tells from what time the alternate entity can give the service. So that the entity getting notification can start using the Alternate entity for services and it can change over to alternate entity gracefully. registration-required: This parameter tells whether the user of alternate entity requires registration with that entity. If an "Alternate" element is present in the xml body, the entity which receives the body MAY use the "Alternate" element to continue the service after the grace period. The uri element gives the address of the alternate element. uri : The uri of an alternate entity to which the subscriber can contact and get the service uninterrupted. 6.12 XML Schema. Mahesh,Ivan,RajKumar Expires September 23,2006 [Page 9] Internet-Draft Asynchronous Service State Notifications February 2006 6.13 Example. sip: proxy2.example.com 6.14 Rate of notifications The SIP Events framework mandates that packages define a maximum rate of notifications for their package. For reasons of congestion control, it is important that the rate of notifications not become excessive. As a result, it is RECOMMENDED that the server not generate notifications for a single subscriber at a rate faster than once every 5 seconds. Also the server must try to distribute the notifications send to subscribers within a reasonable time frame . 7 Working of the scheme The advance notification could either the change of state of a SIP entity or a dialog. 1)Receiving advance notifications of the change of state of a SIP entity. The user agent subscribes to the service-state event using the SUBSCRIBE method, with the value of service-state in the Events Header field .The duration of subscription will be in the Expires header .The Proxy Agent accepts the subscription and whenever it detects an event related to service-state it notifies the UAs which have subscribed for the event .Broadly a SIP entity can be in two state in terms of its service ,"Out-of Service" or "In-Service" .In this document we are interested in conveying the "Out-of Service" state, to User agents , so that service transitions can take place gracefully. One example of such a case is when two user agents are gateways which interacts Mahesh,Ivan,RajKumar Expires September 23,2006 [Page 10] Internet-Draft Asynchronous Service State Notifications February 2006 directly. Some advance knowledge of the state-change , such as one gate way going out of service will help the other gateway to continue the service without any call drop. 2)Receiving advance notifications of the change of state of a dialog This mechanism can be used to convey the state change of a session. If the user agents support service-state event, any future changes in the service state of the session is notified in advance as an inside dialog request. An example may a B2BUA sends NOTIFY to the user of a prepaid card where the session will be over after a time period. Given below are the use cases for the same. 7.1 Use cases and Scenarios We visualize that the event package can be used in several cases where one would like to get the advanced knowledge of the state of the session or the entity ,with whom they interact. Some examples are a user using prepaid card, two gateways interacting each other, a service provider wants to redirect a part of the out bound calls, a wireless ua whose battery is going down or in the case when a UA dont support DNS SRV ... etc. If the notification is received inside a session, the notification for that session and the acts resulting from the reception of the notification is applicable to that session .If the notifications are received out of any session, the notification carries the future state changes about the entity which send the NOTIFY and the acts resulting from the reception of the notification is applicable to all the future sessions. For achieving graceful change in service state the receiver of NOTIFY can use the values of the parameters "grace-period" and "effectiveFrom" .The parameter grace-period tells the time period after which the service state change happens. The "effectiveFrom" parameter is the property of the "Alternate" entity .This parameter tells, from when the receiver of the NOTIFY can use the services of the "Alternate" entity. 7.1.1 Subscription UA Proxy-Agent | | | F1 | |---------------->| | | | F2 | |<--------------- | | | | | Mahesh,Ivan,RajKumar Expires September 23,2006 [Page 11] Internet-Draft Asynchronous Service State Notifications February 2006 F1 SUBSCIBE SUBSCRIBE sip:proxy-agent@example.com SIP/2.0 Via: SIP/2.0/UDP ua.example.com;branch=z9hG4bKnashds7 From: sip: ua.example.com;tag=123aa9 To: sip:proxy-agent@example.com Call-ID: 9987@ua.example.com CSeq: 9887 SUBSCRIBE Contact: sip:ua@example.com:9999 Event: reg Max-Forwards: 70 Accept: application/servicestateinfo+xml F2 200 OK SUBSCRIBE SIP/2.0 200 OK Via: SIP/2.0/UDP ua.example.com;branch=z9hG4bKnashds7 ;received=192.0.2.1 From: sip:ua@example.com;tag=123aa9 To: sip:proxy-agent@example.com;tag=xyzygg Call-ID: 9987@ua.example.com CSeq: 9987 SUBSCRIBE Contact: sip:proxy-agent.example.com Expires: 3600 7.1.2 Example for Session termination 7.1.2.1 Calling card example In this example the caller is using a pre-paid calling card application.The call control is done by a B2BUA.The UA (Caller) has done implicit subscription of the service state for the session. Allow-events header was present in the initial INVITE, with value as service-state. The calling card of the caller is going to be over after a minute. The B2BUA sends the notification to the UA(Callee) , that the session is going to be out of service after a minute. The UA( Callee )prompt the user about the notification. Mahesh,Ivan,RajKumar Expires September 23,2006 [Page 12] Internet-Draft Asynchronous Service State Notifications February 2006 Caller B2BUA Callee | | | | | | | F1 (INVITE 200OK ACK) | |<-------------------------->|(Implicit | | |subscription) | | | |<-------- ---->| |(Card is going to be | | | over) | F2 | | | | | | F3 | | |<------------- |----------->|(Terminates the | | |session) | | | F1 INVITE 200,OK ACK (Only INVITE message is shown here) Allow events header is used with service-state as the value , will cause an implicit subscription . INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds Max-Forwards: 70 To: Bob < sip:bob@biloxi.com> From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710@pc33.atlanta.com CSeq: 314159 INVITE Contact: Content-Type: application/sdp Allow-Events:service-state Content-Length: ... F2 NOTIFY (Session going to be over) When balance is going to be over ,B2BUA sends an event notificaiton. F3 BYE When the balance is over B2BUA terminates the call. 7.1.2.2 UA going down In this case the caller(UA1) and callee(UA2) are two wireless clients , powered by battery. Both the UAs have subscribed each other for the service-state.UA1 gets an event from the UA1 system Mahesh,Ivan,RajKumar Expires September 23,2006 [Page 13] Internet-Draft Asynchronous Service State Notifications February 2006 that the battery is going to be over.UA1 notifies UA2 about the development.UA2 prompts the caller. Callee understands the prompt and now know that, caller may disappear , due to power failure. UA1 (Wireless) UA2 (Wireless) | | | F2 (SUBSCRIBE,200 OK) | |<---------------------------->|(UA2 subscribes for | | UA1) | | | | | F3 (INVITE 200OK ACK) | |<---------------------------->|(UA2 calls UA1) | | | F4 (NOTIFY 200 OK) | |----------------------------->|UA notifies the user | | about the power | |status of the peer | | (UA1 going down) F4 NOTIFY from UA1 to UA2. NOTIFY sip:UA2.example.com SIP/2.0 Via: SIP/2.0/UDP UA1.example.com;branch=z9hG4bKnasaii From: sip:UA1@example.com;tag=xyzygg To: sip:UA2@example.com;tag=123aa9 Call-ID: 9987@UA1.example.com CSeq: 1288 NOTIFY Event: service-state Max-Forwards: 70 Content-Type: application/servicestateinfo+xml Content-Length: ... Mahesh,Ivan,RajKumar Expires September 23,2006 [Page 14] Internet-Draft Asynchronous Service State Notifications February 2006 7.1.2.3 Example for Out of service In this example we are illustrating how two gateways can use this event for advertising the "out of service" state and how both of them can tear down the services gracefully and continue with the alternate one.GW1 and GW2 are two gateways. The GW1 and GW2 subscribes each other for the service-state changes.GW1 notifies GW2 about the planned shutdown. In notify it conveys GW2 that after 3600 secs it will be going out of service and GW2 can use alternate GW1 from "now" for the all the fresh sessions. So for all the fresh sessions are initiated with Alternate GW1.The change over is done gracefully. GateWay1 GateWay2 | | | F1 (SUBSCRIBE,200 OK) | |<---------------------------->|(GW1 subscribes for | |GW2) | | | | | F2 (SUBSCRIBE,200 OK) | |<---------------------------->|(GW2 subscribes for | |GW1) | | | | | | | F4 (NOTIFY 200 OK) | |----------------------------->|GW1 notifies GW2 | |about the planned | |shut down and | |gives the address of | |alternate gateway. Mahesh,Ivan,RajKumar Expires September 23,2006 [Page 15] Internet-Draft Asynchronous Service State Notifications February 2006 F4 NOTIFY from GateWay1 NOTIFY sip:GW2.example.com SIP/2.0 Via: SIP/2.0/UDP proxy-agent.example.com;branch=z9hG4bKnasaii From: sip:proxy-agent@example.com;tag=xyzygg To: sip:ua@example.com;tag=123aa9 Call-ID: 9987@ua.example.com CSeq: 1288 NOTIFY Contact: sip:proxy-agent.example.com Event: service-state Max-Forwards: 70 Content-Type: application/servicestateinfo+xml Content-Length: ... sip:proxy2.example.com F2 200 OK NOTIFY SIP/2.0 200 OK Via: SIP/2.0/UDP proxy-agent.example.com;branch=z9hG4bKnasaii From: sip:proxy@example.com;tag=xyzygg To: sip:ua@example.com;tag=123aa9 Call-ID: 9987@ua.example.com CSeq: 1288 NOTIFY Contact: sip: proxy-agent.example.com Event: service-state Max-Forwards: 70 Content-Type: application/servicestateinfo+xml Content-Length:0 Mahesh,Ivan,RajKumar Expires September 23,2006 [Page 16] Internet-Draft Asynchronous Service State Notifications February 2006 7.1.3 Example for Service redirection This example assumes that UA have already subscribed for service-state event. The service provider decides to redirect some of the out-bound calls through a different proxy ,for taking care of some peak situations. The proxy agent is notifying UA that the proxy is going out of service after the grace period, so contact the Alternate Proxy for service .It sends a NOTIFY with an XML body which lists the description of event and other related info . In this case the xml body is having a list of Alternate proxies which can be contacted by the UA.XML body also have the fields telling the UA where fresh registration is required with Alternate proxy .The UA contacts the Alternate proxy and continues its service .Please note that such mechanisms , if used in an on-going dialog may have impacts .This is because if the Out bound proxy have done record routing its in the dialog establishment request, the other end may have formed its route set .If proxy is changed to Alternate proxy , the route sets may not be in sync and , if the other end send a request , the request will get lost. (This is to be investigated further.) UA Proxy-Agent Alternate-Proxy | F1 | | |---------------->| | | | | | F2 | | |<--------------- | | | | | | | | | | | | F3 | | |-----------------|------------>| | | | | F4 | | |<--------------- |-------------| | | | | | | F1 UA gets NOTIFY from Proxy-Agent NOTIFY sip:ua.example.com SIP/2.0 Via: SIP/2.0/UDP proxy-agent.example.com;branch=z9hG4bKnasaii From: sip:proxy-agent@example.com;tag=xyzygg To: sip:ua@example.com;tag=123aa9 Call-ID: 9987@ua.example.com CSeq: 1288 NOTIFY Contact: sip:proxy-agent.example.com Mahesh,Ivan,RajKumar Expires September 23,2006 [Page 17] Internet-Draft Asynchronous Service State Notifications February 2006 Event: service-state Max-Forwards: 70 Content-Type: application/servicestateinfo+xml Content-Length: ... sip: proxy2.example.com F2 200 OK NOTIFY SIP/2.0 200 OK Via: SIP/2.0/UDP proxy-agent.example.com;branch=z9hG4bKnasaii From: sip:proxy@example.com;tag=xyzygg To: sip:ua@example.com;tag=123aa9 Call-ID: 9987@ua.example.com CSeq: 1288 NOTIFY Contact: sip: proxy-agent.example.com Event: service-state Max-Forwards: 70 Content-Type: application/servicestateinfo+xml Content-Length:0 F3 Next Request UA contacts alterante proxy and continues service 8 Security Consideration Security considerations for SIP event packages are discussed in RFC 3265 [2], and those considerations apply here. Mahesh,Ivan,RajKumar Expires September 23,2006 [Page 18] Internet-Draft Asynchronous Service State Notifications February 2006 Notifications SHOULD be sent in such a way to ensure confidentiality, message integrity and verification of source identity, such as sending subscriptions and notifications using a SIPS URL or protecting the notification bodies with S/MIME. 9 Limitations and Future work. The purpose of the event described in this document is to convey the state changes which affects the service, to the entities in "advance" ,so that the notifying entity can be out of service gracefully. Currently the mechanism specified for service redirection and load balancing shown in above examples can be used only for fresh dialogs .For the scheme to work with mid dialog redirection we need to have call state reconstitution mechanism provided by SIP.Such a mechanism will help the entities which control the session to recreate the necessary state information , even without the use of traditional state replication mechanism.Such a mechanism will need a query from the alternate entity to the redirected entity, asking the redirected entity to send the session state information to the alternate entity . We would like to explore a scheme which is similiar to the one proposed in [3]. Our scheme will be adding a new header and an XML body which will carry the states of all the sessions in the redirected entity.The new header is used to query/convey the co-operating entites the information required/conveyed about the session state in the message body.This is required because in the case of a gateway we need to retrieve the states of a large number of sessions/calls .It will be efficient to transfer the details of the calls at once to the Alternate Entity, than by doing it on a per call basis.Such a call state reconstruction mechanism will be limited by the following factors 1) A uniform method for call id generation. This is required in the case of entities like B2BUAs. 2) Use of FQDN in the Route and related headers. This is due to the static nature of route set. For this we would like to explore whether route sets can be changed , in case where entities are using IP address for Record-Routing.If how existing systems will be affected etc. A mechanism (if possible ) to change the route set can be some thing like the following.We are assuming the UA have done subscription for service-state. The Primary-Proxy (assuming it is stateful) is having a Proxy-agent which can send notifications , based on the state changes of the Primary-proxy.The UA1 after getting a notification for service-state registers with Alternate-Proxy (assuming it is stateful) and sends an UPDATEROUTESET message to UA2 through Alternate-Proxy(Alternate Proxy is Mahesh,Ivan,RajKumar Expires September 23,2006 [Page 19] Internet-Draft Asynchronous Service State Notifications February 2006 now the outbound proxy of UA1) .UPDATEROUTESET is send inside the dialog.Since Alternate proxy is not having the info about the ongoing call from UA1 to UA2, it will reject the request , by asking for the call context . UA1 resends the UPDATEROUTESET request with the call Context to UA2 . UA2 now updates its route set and can send request to UA1. UA1 Primary-Proxy Alternate-Proxy UA2 | F1 | | | | (NOTIFY) | | | |<--------------->| | | | | | | | | | | | | | | | (UPDATEROUTESET)| F2 | | |<----------------|--------------->| | | | | | | (Rejects ) | F3 | | |<----------------|--------------- |(Rejects ) | | | | | | | F4 | | |-----------------|----------------|--------------->|(Update | | | |RouteSet | | | |with | | | |context) | | F5 | | |<----------------|----------------|--------------- | | | | | | | | | | | | | 10 IANA Considerations The event package and the Options tag needs to be registered with IANA. Appendix A This section describes some procedures which are applicable in the case when a Proxy-Agent is not co located with a Sip Entity. Internet-Draft Asynchronous Service State Notifications February 2006 A.1 Discovering Proxy agent (If proxy agent is not co located) The Proxy Agent can be either "configured" or "discovered" .One scheme for discovery is given below .The Proxy Agent can be discovered during registration . Registrar is one entity which is capable of conveying the details of Proxy agent to the UAs. When the registrar gets a registration request it can check for the options tag service-state ,in the supported header field . If the tag is present the registrar can give the information about the proxy agents to the UA. The information is conveyed in the Proxy-Agent header field. If the options tag service-state is not present , the registrar MUST not send Proxy-Agent header . If Proxy-Agent header is not present in the response to REGISTER request the UA must consider as of the domain is not supporting procedures specified in this draft .If the registrar returns multiple Proxy-Agent headers, UA must consider the Proxy-Agent with highest q value .After selecting the corresponding Proxy-Agent the UA can send SUBSCRIBE message to the Proxy-Agent to get notifications about service-state. Another scheme for discovery is manual configuration. One place where manual configuration can be used may be between two User agents . An example may be the case of two gate ways. The call flow details for the above procedures are given in section 7. Grammar for proxy agent. Proxy-Agent = "Proxy-Agent" HCOLON proxy-agent *(COMMA proxy-agent) proxy-agent = name-addr *( SEMI param ) param = ("q" EQUAL qvalue) / generic-param where name-addr and generic-param is define in section NO: in RFC 3261 . Example Proxy-Agent: A.2 Redundancy of proxy agent The next question is about the redundancy of the proxy agent. A domain can have multiple proxy agents . This can be conveyed through the registration response and each of these proxy agents can have different "q" values .The UAs must subscribe to Proxy-Agents with highest "q" value .It MUST subscribe to a Proxy-Agent with lowest "q" value only if the subscription with a Proxy-Agent who have higher "q" value fails. Also registrar can have some algorithm by which it will assign one proxy-agent to a set of UAs and another one to another set of UAs , or can assign Proxy Agents dynamically to UAs . A.3 Proxy agent going down Another issue to be taken care of is that of a proxy agent going down. There could be two cases : proxy being brought down for maintenance or proxy going down due to a critical failure.If it is a scheduled activity the proxy agent can notify the subscriber.If an abnormal failure of the proxy agent happens ,the subscriber can try using other agents , if information about any such agents are provided by the registrar. A.4 Preventing flooding of SUBSCRIBE messages One way of avoiding flooding the Proxy-Agents with subscribe message is , The UAs must wait for a random time (say 0-1 secs) before sending the subscription. This will avoid flooding of subscription messages from UAs if all the UAs come up at same time. A.5 Preventing Overloading from notification For sending notification the Proxy-Agent can use the same scheme of waiting for a random period before sending the notifications. This waiting time is introduced since the purpose of event mechanism specified in this draft is to give the subscribers and service providers some grace period so that both of them will get some time to prepare for the service change 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] A. Roach Session Initiation Protocol (SIP)-Specific Event Notification, RFC 3265,June 2002 [3] Rosenberg, J."Reconsituting Call State in SIP User Agents" [4] W. W. W. C. (W3C), "Extensible markup language (xml) 1.0." The XML 1.0 spec can be found at http://www.w3.org/TR/1998/REC-xml-19980210. [5] Moats, R., "URN Syntax", RFC 2141, May 1997. [6] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999. [7] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, February 2004. [8] Murata, M., St. Laurent, S. and D. Kohn, "XML media types", RFC 3023, February 2001. Mahesh,Ivan,RajKumar Expires September 23,2006 [Page 20] Internet-Draft Asynchronous Service State Notifications February 2006 Author's Address Ivan Varghis Cisco Systems Pvt Ltd Bangalore India Email:ivarghis@cisco.com Rajkumar Nair #C-106, Wilson Manor Apartments, 13th Cross, Wilson Garden, Bangalore- 560027 Email:rajkknair@gmail.com Mahesh Govind Email:vu3mmg@gmail.com 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. Mahesh,Ivan,RajKumar Expires September 23,2006 [Page 21] Internet-Draft Asynchronous Service State Notifications February 2006 Copyright Statement Copyright (C) The Internet Society (2006). 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.