Sipping Parthasarathi. Ravindran
Internet-Draft Sheshadri. Shalya
Intended status: Standards Track Cisco Systems, Inc.
Expires: October 21, 2010 April 19, 2010
Session Initiation Protocol (SIP) Resource availability Event package
draft-partha-sip-overload-resource-availability-00
Abstract
Overload occurs in Session Initiation Protocol (SIP) networks when
B2BUA, proxies, and user agents have insufficient resources like CPU,
memory, DSP, or bandwidth to complete the processing of a request.
SIP provides limited support for overload handling through its 503
response code, which tells an upstream element that it is overloaded.
This document defines explicit SIP based resource monitoring and
overload avoidance mechanism based on the resource availability of
the entity.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on October 21, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Ravindran & Shalya Expires October 21, 2010 [Page 1]
Internet-Draft SIP Resource availability Event package April 2010
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Resource availability indication mechanism . . . . . . . . . . 4
4. Resource availability Event package definition . . . . . . . . 5
4.1. Event Package name . . . . . . . . . . . . . . . . . . . . 6
4.2. Event Package Parameters . . . . . . . . . . . . . . . . . 6
4.3. SUBSCRIBE bodies . . . . . . . . . . . . . . . . . . . . . 6
4.4. SUBSCRIBE duration . . . . . . . . . . . . . . . . . . . . 6
4.5. NOTIFY bodies . . . . . . . . . . . . . . . . . . . . . . 6
4.6. Notifier processing of SUBSCRIBE Requests . . . . . . . . 7
4.7. Notifier generation of NOTIFY Requests . . . . . . . . . . 7
4.8. Subscriber processing of NOTIFY requests . . . . . . . . . 7
4.9. Handling of forked requests . . . . . . . . . . . . . . . 8
4.10. Rate of Notifications . . . . . . . . . . . . . . . . . . 8
4.11. State Agents . . . . . . . . . . . . . . . . . . . . . . . 8
4.12. Behavior of SIP Proxy . . . . . . . . . . . . . . . . . . 8
4.13. Refresh SUBSCRIBE mechanism for failure handling . . . . . 8
5. Resource availability Indication (RAI) document format . . . . 9
5.1. Contents . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. XML data format . . . . . . . . . . . . . . . . . . . . . 9
5.2.1. Namespace . . . . . . . . . . . . . . . . . . . . . . 9
5.2.2. Resource-Availability . . . . . . . . . . . . . . . . 10
5.2.3. System . . . . . . . . . . . . . . . . . . . . . . . . 10
5.3. Resource . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.4. Resource-subtype . . . . . . . . . . . . . . . . . . . . . 10
5.5. Almost-out-of-resource . . . . . . . . . . . . . . . . . . 10
5.6. Total & Available . . . . . . . . . . . . . . . . . . . . 11
5.7. Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.8. Timestamp . . . . . . . . . . . . . . . . . . . . . . . . 11
5.9. Example . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Use Case for Resource Availability mechanism . . . . . . . . . 12
6.1. Subscriber acts as resource monitor only . . . . . . . . . 12
6.2. Subscriber acts as overload protection . . . . . . . . . . 13
6.3. Subscriber pools for resource status . . . . . . . . . . . 13
6.4. Subscriber in mixed mode . . . . . . . . . . . . . . . . . 13
7. XML Schema definition for Resource availability . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9.1. Resource availability package Registration . . . . . . . . 15
9.2. application/rai+xml MIME Registration . . . . . . . . . . 16
9.3. Resource availability indication Schema Registration . . . 17
Ravindran & Shalya Expires October 21, 2010 [Page 2]
Internet-Draft SIP Resource availability Event package April 2010
10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Ravindran & Shalya Expires October 21, 2010 [Page 3]
Internet-Draft SIP Resource availability Event package April 2010
1. Introduction
In Voice/Video over IP (VoIP) network, Session Initiation protocol
(SIP) [RFC3261] is widely deployed as a signaling protocol and
overload occurs in the SIP network has limited support using 503
response. Overload is said to occur if a SIP server does not have
sufficient resources to process all incoming SIP messages. These
resources include but not limited to CPU processing capacity, memory,
DSP, DS0, network bandwidth, input/output, or disk resources.
Overload requirements for SIP are explained in [RFC5390]. Overload
occurs at any time and the duration of overload depends upon the
resource overloaded. In case of CPU overload, when the number of
incoming dialogs are reduced then the system comes to normal
situation in a short span of time whereas DS0/DSP resource overload
will come back to normal after the set of dialogs are terminated. It
is necessary for the system to understand its current resource
capability and indicate to the neighboring entity in right time to
avoid congestion collapse.
In this overload protection mechanism document, SIP server indicates
its resource capability to the prior SIP server by which prior SIP
server will be able to perform intelligent routing. As SIP is used
for overload protection, it is easy to relate the overload protection
information to specific SIP entity within the SIP network without
having any separate naming or addressing scheme.
Apart from overload scenario, the administrator might be interested
in monitoring the resource utilization pattern at any given time for
deciding whether the VoIP network resources need to be expanded or it
is under utilized. SIP based resource utilization is preferred
within SIP network and removes the need for using any other
management protocol for resource monitoring purpose.
2. Terminology
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 [RFC2119]. This
document only uses these key words when referencing normative
statements in existing RFCs.
3. Resource availability indication mechanism
Resource availability indication mechanism by UA or Proxy helps load
balancer, resource statistics collector to collect the data and act
upon them accordingly. The solution is targeted for SIP trunks or
Ravindran & Shalya Expires October 21, 2010 [Page 4]
Internet-Draft SIP Resource availability Event package April 2010
between SIP servers. By the proposed mechanism, the individual
devices indicate their current resource availability information
through SIP event framework mechanism. Load Balancer or resource
statistics collector acts as a subscriber and subscribe to the
resource in the individual UA. Individual devices acts as Notifier
and inform the resource information in XML. In case of hop-by-hop
overload mechanism is required, SUBSCRIBE MAY include max-forward
header with value as 1.
In the load balancing scenario, the load balancer subscribes to all
the relevant SIP trunks and informed about the current resource
information. Based on the resource availability indication, the call
is routed to the individual SIP trunk. In case one of the devices is
reached almost out of the resource, the device notifies the load
balancer immediately. The load balancer SHOULD NOT forward any new
SIP dialog towards the notified device till further resource
availability indication from the device. The threshold for each of
the resource is decided based on the set of pre-configured values.
This helps load balancer to decide where to route the dialog when
multiple routes are available for the given dialog. In case the
entire route for the given dialog in load balancer is overloaded, 500
internal error or 4xx response (response code is TBD) is sent out to
incoming UAC. The algorithm of using resource availability to
achieve load balancing is kept out of scope of this document. The
threshold for the resource has to be decided by administrator by keep
in mind that NOTIFY message has to be formed and send out to the
external server and also resource priority dialog has to be processed
without any interruption.
In the resource monitor, the periodic resource information is
collected from all the devices and the reports are formed. These
statistics provide effective resource utilization indication for any
given resource at any point of time. This information helps
administrator to take informed decision and corrective measures to
tackle under or over resource utilization in the network.
The local policy has to be put in place in SIP Notifying entity to
provide fair resource allocation algorithm to ensure that Non-
SUBSCRIBE overloading entity may not have any unfair share of
resources.
4. Resource availability Event package definition
This document defines the details of the SIP event package for
Resource availability based routing according to [RFC3265]
Ravindran & Shalya Expires October 21, 2010 [Page 5]
Internet-Draft SIP Resource availability Event package April 2010
4.1. Event Package name
The name of the event package is resource-availability. This event
name has to be mentioned in the Event and allow-event header as
mentioned in [RFC3265]
4.2. Event Package Parameters
There is no specific event package parameter specified for this event
package.
4.3. SUBSCRIBE bodies
A SUBSCRIBE request for resource availability policy MAY contain a
body to request the specific resources availability notification.
For example, a subscriber is interested in some specific resources
only. The details of the subscription filter specification are not
yet defined.
A SUBSCRIBE request sent without a body implies the default
subscription behavior as specified in the sec 4.7.
4.4. SUBSCRIBE duration
Subscription duration depends upon the deployment. The default
duration for this package is 300 sec. It is not recommended to have
the refresh timer less than 180 sec. Refresh of subscription ensures
that the next hop is up before new dialog request is forwarded.
Refresh subscription should be triggered 32 sec before the expiry
time of the package. This keepalive mechanism is useful to decide
whether Notifier trunk is reachable or not. The user defined value
shall be used depending on the deployment scenario.
In case of SUBSCRIBE refresh failure, it is recommended that new
SUBSCRIBE is initiated after the expiry of user mentioned timer.
4.5. NOTIFY bodies
The body of a NOTIFY message in this event package contains resource
information of a device. The format of the NOTIFY body MUST be in
one of the formats defined in the Accept header field of the
SUBSCRIBE request or be the default format as specified in [RFC3265].
The default data format for the NOTIFY body of this event package is
"application/rai+xml" (defined in Section 7).
This means that if no Accept header field is specified to a SUBSCRIBE
request, the NOTIFY will contain a body in the "application/rai+xml"
format. If the Accept header field is present in SUBSCRIBE request,
Ravindran & Shalya Expires October 21, 2010 [Page 6]
Internet-Draft SIP Resource availability Event package April 2010
it MUST include "application/rai+xml" and MAY include any other
types.
4.6. Notifier processing of SUBSCRIBE Requests
Notifier has to provide the sensitive device resource information to
the subscriber in the notification mechanism. The entire subscriber
has to be authenticated before providing the package details. The
existing authentication SIP mechanism like DIGEST, TLS, and S/MIME
shall be used. In the trusted domain, the authentication may not be
required and the administrator has to decide the trusted domain and
non-trusted domain.
The requested SUBSCRIBER is not allowed to receive the requested
information, 403 response MUST be sent by Notifier.
4.7. Notifier generation of NOTIFY Requests
NOTIFY has to be formatted as per [RFC3265], it has to contain
resource availability information. NOTIFY has to be sent immediately
after SUBSCRIBE is received for initial dialog or refresh and
responded with 200 OK. Notifier MUST notify SUBSCRIBER whenever any
of the resource reaching almost out of the resource state or going
below the configured threshold. Almost out of the resource value for
the given resource or system will be decided by the administrator.
The threshold notification helps SUBSCRIBER to decide whether the
dialog shall be forwarded or not based on SUBSCRIBER policy.
Notifier shall notify the resource information in the periodic
manner. When any of the resource is reaching almost out of the
resource, NOTIFY will be send which contain only the resource which
reached almost out of the resource.
4.8. Subscriber processing of NOTIFY requests
Subscriber updates the dialog routing logic based on the incoming
NOTIFY message. In case NOTIFY message contains almost out of the
resource for the specific resource or the whole system, the dialog
routing logic in the subscriber has to be updated with appropriate
information by which any further dialog SHOULD NOT be routed to
Notifier till getting further notification with resource available
indication from Notifier.
In case NOTIFY is received in the periodic manner, the resource based
routing and statistics for the individual device usage at a given
time is updated with the received NOTIFY message body information.
Ravindran & Shalya Expires October 21, 2010 [Page 7]
Internet-Draft SIP Resource availability Event package April 2010
4.9. Handling of forked requests
Forking of SUBSCRIBE request is not supported for this package. In
case of forking happened, forked response has to be handled as
mentioned in Sec 4.4.9 of [RFC3265].
4.10. Rate of Notifications
Rate of Notification SHOULD NOT be less than once every 32 sec as the
notification itself will be observed as an overhead otherwise. It is
recommended that the rate of notification happens once every 120 sec.
The administrator is the best person to decide the notification time
based on the network topology. The rate of notification MAY be
reduced or stopped when almost out of the resource is attained for
the critical resources like CPU, Memory and the critical resource
list is based on device.
4.11. State Agents
The resource availability indications are generated by SIP entity
directly and there is no need of explicit state agent for this
package. As load balancing based on the resource availability
indication has to be done in the real time, the aggregation done by
any state agent will introduce delay and hence defeat overload
requirements.
4.12. Behavior of SIP Proxy
This subscription mechanism is recommended for neighboring SIP
entities as it provides more control on overload mechanism. In case
the network topology requires to pass this resource information
through proxy, Proxy has to forward SUBSCRIBE/NOTIFY messages and
this may be required when intermediate proxy is interworking and load
balancing is decided by entity sitting behind the proxy.
4.13. Refresh SUBSCRIBE mechanism for failure handling
Apart from refresh subscription as explained in sec 4.4, Refresh
subscription shall be triggered in the following network error
scenarios as well:
o ICMP message received during dialog creation from the Notifying
entity
o TCP connection failure from the Notifying entity
o Dialog creation timeout
Refresh Subscription shall be started whenever 503 is received for
any dialog creation request from Notifying entity.
Ravindran & Shalya Expires October 21, 2010 [Page 8]
Internet-Draft SIP Resource availability Event package April 2010
Till this refresh subscription succeeds, new dialog MUST NOT be
forwarded to the Notifying entity. In case of refresh SUBSCRIBE
failure, new SUBSCRIBE has to be started as mentioned in sec 4.4 and
no further dialog has to be forwarded till new SUBSCRIBE dialog is
created.
5. Resource availability Indication (RAI) document format
5.1. Contents
Resource availability indication (RAI) document is a XML document
which will be embedded as message body in NOTIFY message of resource-
availability package. The document contains
o Entity parameter in Resource-availability to specify the entity
whose resource information is available as part of this message
o System Tuple to indicate whether the whole system is overloaded or
not
o Resource Tuple indicates the individual resources total and
available capabilities, and also whether the resource is available
for further new dialog processing (Optional)
o Resource Subtype provides the granular information within the
particular resource. (Optional)
5.2. XML data format
RAI object is a XML document. It MUST have the XML declaration and
it SHOULD contain an encoding declaration in the XML declaration,
e.g., "". If the charset
parameter of the MIME content type declaration is present and it is
different from the encoding declaration, the charset parameter takes
precedence.
Every application conformant to this specification MUST accept the
UTF-8 character encoding to ensure the minimal interoperability.
5.2.1. Namespace
The namespace URI for elements defined by this specification is a
Uniform Resource Namespace (URN) [RFC2141], using the namespace
identifier 'ietf' defined by [RFC2648] and extended by [RFC3688].
The URN is as follows: urn:ietf:params:xml:ns:rai
Ravindran & Shalya Expires October 21, 2010 [Page 9]
Internet-Draft SIP Resource availability Event package April 2010
5.2.2. Resource-Availability
Resource-Availability element MUST contain an xmlns namespace
attribute with value as urn:ietf:params:xml:ns:rai.
Resource-availability MUST have entity attribute which contains SIP/
SIPS URI to identify the device which provides the resource
information. The entity attribute SIP/SIPS URI FQDN or IP address
represents the device and may not have user part.
5.2.3. System
All resource-availability element have one System element. The
system element represents the whole system as such. This element
indicates how much load accepted by the system as such. In case the
system is reached almost out of resource, it is expected that load
balancing entity SHOULD NOT forward the request until otherwise load
balancing entity knows the resource which shall be used by the new
dialog without causing any impact to the current state of the system.
Resource-availability MUST have entity attribute which contains SIP/
SIPS URI to identify the device which provides the resource
information. The entity attribute SIP/SIPS URI FQDN or IP address
represents the device and may not have user part.
5.3. Resource
This element indicates the individual resource status at the given
time. This is an optional element wherein the resources type like
CPU, Memory, DSP, and DSO are mentioned in type attribute. Each
resource element shall have almost out of resource status, total and
available resource usage. This resource information helps in routing
or load balancing based on the individual resource availability.
5.4. Resource-subtype
This element comes within a particular resource element to provide an
internal division within a given resource. For example, Memory shall
be divided into processor memory, IO memory and provides the
individual status. This division helps in load balancing in case
routing entity aware of the resource capability required for the
specified call. This is an optional element.
5.5. Almost-out-of-resource
Almost-out-of-resource is a Boolean element to indicate whether
system or resource is reached the threshold or not. This threshold
is decided by Notifier or subscriber shall send it through other
Ravindran & Shalya Expires October 21, 2010 [Page 10]
Internet-Draft SIP Resource availability Event package April 2010
mechanism.
Almost-out-of-resource value true indicates that the threshold is
reached. To avoid the back-forth movement in the threshold range, it
is preferred to provide the upper watermark value which decides the
above threshold limit and lower watermark value is used when the
above threshold is back to normal. True value is set for almost out
of resource when upper watermark is reached and when lower watermark
is reached, almost out of resource is set with false.
Above Threshold
<---------> Upper Watermark
| |
<---------> Lower Watermark
Below Threshold
Watermark mechanism for Threshold handling
5.6. Total & Available
Total and Available elements provide absolute value or the value
specified as per unit element. These are optional element.
5.7. Unit
Unit is a string which indicates unit for the given resource or
resource subtype. The default value of unit is absolute value.
5.8. Timestamp
Timestamp element contains a string indicating the date and time of
the status change of this tuple. The value of this element MUST
follow the IMPP datetime format [RFC3339]. Timestamps that contain
'T' or 'Z' MUST use the capitalized forms.
As a security measure, the timestamp element SHOULD be included in
all tuples unless the exact time of the status change cannot be
determined.
5.9. Example
The example provides all the tuples involved in rai xml body.
Ravindran & Shalya Expires October 21, 2010 [Page 11]
Internet-Draft SIP Resource availability Event package April 2010
false
false
100
50
percentage
false
256
153
mb
false
100
50
percentage
false
32
10
true
30
10
RAI Example XML body
6. Use Case for Resource Availability mechanism
6.1. Subscriber acts as resource monitor only
This is the simple scenario wherein subscriber simply collects the
Notifier statistics and store or display. This is useful when
Administrator is interested in the usage of the VoIP network
resource. Total and available element will be used by subscriber.
Ravindran & Shalya Expires October 21, 2010 [Page 12]
Internet-Draft SIP Resource availability Event package April 2010
In this scenario, subscriber will not honor the almost out of
resource information from the notifier.
6.2. Subscriber acts as overload protection
In this deployment, subscriber stop/start the load based on the
almost out of resource parameter of the body. System&aposs almost
out of resource is set to true whenever any one of the resource is
reached almost out of the resource. In case the subscriber is aware
that the new dialog does not require the set of resource which
reached almost out resource, the new dialog shall be forwarded. For
example, DS0 is almost out of the resource and the new dialog does
not require DS0 resource, the new dialog shall be forwarded to
Notifier. The resource requirement of Notifier for the specific
dialog shall be intimated to Subscriber through other protocol
mechanism or provisioning mechanism which is outside the scope of
this document.
6.3. Subscriber pools for resource status
In this mode, Subscriber is interested in the resource status at a
given time, and one shot subscription shall be used for this
mechanism.
6.4. Subscriber in mixed mode
Any of the above mentioned mechanism shall be combined together based
on the deployment requirement. For example, Subscriber performs
resource monitoring and threshold mechanism at the same time.
Based on the availability of the resource, the flow of the new
dialogs shall be decided. This requires tight understanding between
subscriber and notifier about the resource information and
utilization. Resource information of Notifier shall be provided to
Subscriber through provisioning mechanism or other protocol mechanism
which is outside the scope of this document.
7. XML Schema definition for Resource availability
This section defines XML schema for resource availability document.
Ravindran & Shalya Expires October 21, 2010 [Page 13]
Internet-Draft SIP Resource availability Event package April 2010
Ravindran & Shalya Expires October 21, 2010 [Page 14]
Internet-Draft SIP Resource availability Event package April 2010
8. Security Considerations
Security consideration for event based framework as specified in
[RFC3265] has to be considered for this draft as well. As the
resource information is sensitive information, Subscribe/Notify shall
use TLS transport in case subscriber and Notifier are in the public
domain. In case subscriber is a untrusted entity, subscriber will be
authenticated by responding with 401. The administrator provides
authorization mechanism by which different entity will be provided
with different level of information. For example, all SIP entity
within enterprise could be provided complete resource information and
only system level information could be provided towards service
provider network.
The resource information provided in this mechanism is more critical.
If the above specified mechanism is not secure enough, there is a
scope for coming up with addition security measures (TBD).
9. IANA Considerations
This specification registers a SIP event package, a new MIME type, a
new XML namespace, and a new XML schema.
9.1. Resource availability package Registration
This section registers an event package based on the registration
procedures defined in [RFC3265].
Package name: resource-availability
Ravindran & Shalya Expires October 21, 2010 [Page 15]
Internet-Draft SIP Resource availability Event package April 2010
Type: package
Published specification: This document
Person to contact: R.Parthasarathi, partr@cisco.com
9.2. application/rai+xml MIME Registration
This section registers a new MIME type based on the procedures
defined in [RFC4288] and guidelines in [RFC3023].
MIME media type name: application
MIME subtype name: rai+xml
Mandatory parameters: none
Optional parameters: Same as charset parameter application/xml in
[RFC3023]
Encoding considerations: Same as encoding considerations of
application/xml in [RFC3023]
Security considerations: See Section 10 of [RFC3023] and Section 8
of this specification
Interpretability considerations: None
Published Specification: This document
Applications which use this media type: Load balancing SIP
entities, Resource statistics collecting SIP entities
Additional information:
Magic number: None
File extension: .xml
Macintosh file type code: 'TEXT'
Personal and email address for further information:
Parthasarathi.R, partr@cisco.com
Intended usage: COMMON
Author/Change Controller: IETF SIPPING Working Group
, as designated by the IESG iesg@ietf.org
Ravindran & Shalya Expires October 21, 2010 [Page 16]
Internet-Draft SIP Resource availability Event package April 2010
9.3. Resource availability indication Schema Registration
URI: urn:ietf:params:xml:schema:rai
Registrant Contact: IETF SIPPING working group, Parthasarathi.R
(partr@cisco.com)
XML: the XML schema to be registered is contained in Section 7.
Its first line is and its last
line is
TBD: Adding registry for resourceType and resourceSubtype tuples
10. Acknowledgement
We wish to thank Muthu Arul Mozhi, Paul Kyzivat, Paul Jones, Sanjay
Sinha for the valuable comments
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
[RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
August 1999.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001.
[RFC3261] 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.
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
Ravindran & Shalya Expires October 21, 2010 [Page 17]
Internet-Draft SIP Resource availability Event package April 2010
Internet: Timestamps", RFC 3339, July 2002.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005.
11.2. Informative References
[RFC5390] Rosenberg, J., "Requirements for Management of Overload in
the Session Initiation Protocol", RFC 5390, December 2008.
Authors' Addresses
Parthasarathi R
Cisco Systems, Inc.
Cessna Business Park,
Kadabeesanahalli Village, Varthur Hobli,
Sarjapur-Marathahalli Outer Ring Road
Bangalore, Karnataka 560103
India
Email: partr@cisco.com
Sheshadri Shalya
Cisco Systems, Inc.
Cessna Business Park,
Kadabeesanahalli Village, Varthur Hobli,
Sarjapur-Marathahalli Outer Ring Road
Bangalore, Karnataka 560103
India
Email: svshesha@cisco.com
Ravindran & Shalya Expires October 21, 2010 [Page 18]