One document matched: draft-mahesh-sipping-svc-state-notify-00.txt
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.
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:servicestateinfo
"xmlns:tns="urn:ietf:params:xml:ns:servicestateinfo"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<!-- This import brings in the XML language attribute xml:lang-->
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/03/xml.xsd"/ >
<xs:element name="servicestateinfo">
<xs:complexType>
<xs:sequence>
<xs:element ref="tns:servicestate" minOccurs="0"
maxOccurs="unbounded>
<xs:any namespace="##other" processContents="lax"
Mahesh,Ivan,RajKumar Expires September 23,2006 [Page 8]
Internet-Draft Asynchronous Service State Notifications February 2006
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<!--Attributes of servicestate -->
<xs:attribute name="identity" type="xs:anyUri"
use="required"/>
<xs:attribute name="state" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="OOS"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="reason" type="xs:string"
use="required"/>
<xs:attribute name="grace-period" type="xs:dateTime"
use="required"/>
</xs:complexType >
</xs:element>
<!--reference of the service state element-->
<xs:element name="servicestate">
<xs:complexType>
<xs:sequence>
<xs:element ref="tns:Alternate" minOccurs="0"
maxOccurs="unbounded>
<xs:element name=uri type=xs:anyUri
use="required">
<xs:any namespace="##other" processContents="lax"
minOccurs="0"
<!-- Service state contains a sequence of Alternates
-->
</xs:sequence>
</xs:complexType>
<!-- Attributes of Alternate element-->
<xs:attribute name="id" type="xs:nonNegativeInteger"
use="required"/>
<xs:attribute name="q" type="xs:nonNegativeInteger"
use="required"/>
<xs:attribute name="registration-required"
use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="yes"/>
<xs:enumeration value="no"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="effectiveFrom" type="xs:dateTime"
use="required"/>
Mahesh,Ivan,RajKumar Expires September 23,2006 [Page 9]
Internet-Draft Asynchronous Service State Notifications February 2006
<!-- End of Alternate element-->
</xs:element>
</xs:schema >
6.13 Example.
<?xml version="1.0"?>
<servicestateinfo xmlns="urn:ietf:params:xml:ns:
servicestateinfo"
xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance"
version="0" state="full">
<servicestate Proxy="sip:example.com" state="OOS"
reason="Scheduled Upgradation" grace-period=
"10-10-2006">
<Alternate id="1" q=1 registration-required=yes>
<uri>sip: proxy2.example.com</uri>
</Alternate>
</servicestate>
</servicestateinfo>
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 <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
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: ...
<?xml version="1.0"?>
<servicestateinfo xmlns="urn:ietf:params:xml:ns:servicestate"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance "
>
<servicestate identity="sip:example.com" state="OOS"
reason="Low Battery"
grace-period="2006-10-10T00:00:00+05:00">
</servicestate>
</servicestateinfo>
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: ...
<?xml version="1.0"?>
<servicestateinfo xmlns="urn:ietf:params:xml:ns:servicestate"
xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance "
version="0" state="full">
<servicestate identity="sip:example.com" state="OOS"
reason="Scheduled Upgradation"
grace-period="2006-10-10T00:00:00+05:00">
<Alternate id=1 q=1 registration-required=yes
effectiveFrom=2006-9-10T00:00:00+05:00>
<uri>sip:proxy2.example.com</uri>
</Alternate>
</servicestate>
</servicestateinfo>
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: ...
<?xml version="1.0"?>
<servicestateinfo xmlns="urn:ietf:params:xml:ns:servicestate"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance "
version="0" state="full">
<servicestate identity="sip:example.com" state="OOS"
reason="Scheduled Upgradation"
grace-period="2006-10-10T00:00:00+05:00">
<Alternate id=1 q=1 registration-required=yes
effectiveFrom=2006-9-10T00:00:00+05:00>
<uri>sip: proxy2.example.com</uri>
</Alternate>
</servicestate>
</servicestateinfo>
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: <sip:p1.example.com;q=1>
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.
| PAFTECH AB 2003-2026 | 2026-04-24 02:00:13 |