draft-ietf-sip-guidelines-06.txt   draft-ietf-sip-guidelines-07.txt 
Internet Engineering Task Force SIP WG SIP J. Rosenberg
Internet Draft J. Rosenberg Internet-Draft dynamicsoft
dynamicsoft Expires: April 26, 2004 H. Schulzrinne
H. Schulzrinne Columbia University
Columbia U. October 27, 2003
draft-ietf-sip-guidelines-06.txt
November 4, 2002
Expires: May 2003
Guidelines for Authors of Extensions to Guidelines for Authors of Extensions to the Session Initiation
the Session Initiation Protocol (SIP) Protocol (SIP)
draft-ietf-sip-guidelines-07
STATUS OF THIS MEMO Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that other
other groups may also distribute working documents as Internet- groups may also distribute working documents as Internet-Drafts.
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress". material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at http://
http://www.ietf.org/ietf/1id-abstracts.txt www.ietf.org/ietf/1id-abstracts.txt.
To view the list Internet-Draft Shadow Directories, see The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 26, 2004.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
The Session Initiation Protocol (SIP) is a flexible, yet simple tool The Session Initiation Protocol (SIP) is a flexible, yet simple tool
for establishing interactive connections across the Internet. Part of for establishing interactive connections across the Internet. Part of
this flexibility is the ease with which it can be extended. In order this flexibility is the ease with which it can be extended. In order
to facilitate effective and interoperable extensions to SIP, some to facilitate effective and interoperable extensions to SIP, some
guidelines need to be followed when developing SIP extensions. This guidelines need to be followed when developing SIP extensions. This
document outlines a set of such guidelines for authors of SIP document outlines a set of such guidelines for authors of SIP
extensions. extensions.
Table of Contents Table of Contents
1 Terminology ......................................... 3 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Introduction ........................................ 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
3 Should I define a SIP Extension? ................... 3 3. Should I define a SIP Extension? . . . . . . . . . . . . . . 5
3.1 SIP's Solution Space ................................ 4 3.1 SIP's Solution Space . . . . . . . . . . . . . . . . . . . . 5
3.2 SIP Architectural Model ............................. 6 3.2 SIP Architectural Model . . . . . . . . . . . . . . . . . . 7
4 Issues to be Addressed .............................. 8 4. Issues to be Addressed . . . . . . . . . . . . . . . . . . . 10
4.1 Backwards Compatibility ............................. 8 4.1 Backwards Compatibility . . . . . . . . . . . . . . . . . . 10
4.2 Security ............................................ 10 4.2 Security . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3 Terminology ......................................... 10 4.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 12
4.4 Syntactic Issues .................................... 11 4.4 Syntactic Issues . . . . . . . . . . . . . . . . . . . . . . 13
4.5 Semantics, Semantics, Semantics ..................... 13 4.5 Semantics, Semantics, Semantics . . . . . . . . . . . . . . 15
4.6 Examples Section .................................... 14 4.6 Examples Section . . . . . . . . . . . . . . . . . . . . . . 16
4.7 Overview Section .................................... 14 4.7 Overview Section . . . . . . . . . . . . . . . . . . . . . . 16
4.8 IANA Considerations Section ......................... 15 4.8 IANA Considerations Section . . . . . . . . . . . . . . . . 16
4.9 Document Naming Conventions ......................... 15 4.9 Document Naming Conventions . . . . . . . . . . . . . . . . 17
4.10 Additional Considerations for New Methods ........... 16 4.10 Additional Considerations for New Methods . . . . . . . . . 18
4.11 Additional Considerations for New Header Fields or 4.11 Additional Considerations for New Header Fields or Header
Header Field Parameters ........................................ 17 Field Parameters . . . . . . . . . . . . . . . . . . . . . . 19
4.12 Additional Considerations for New Body Types ........ 17 4.12 Additional Considerations for New Body Types . . . . . . . . 19
5 Interactions with SIP Features ...................... 18 5. Interactions with SIP Features . . . . . . . . . . . . . . . 20
6 Security Considerations ............................. 18 6. Security Considerations . . . . . . . . . . . . . . . . . . 21
7 IANA Considerations ................................. 19 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 22
8 Acknowledgements .................................... 19 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
9 Authors Addresses ................................... 19 Normative References . . . . . . . . . . . . . . . . . . . . 24
10 Normative References ................................ 19 Informative References . . . . . . . . . . . . . . . . . . . 25
11 Informative References .............................. 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 26
Intellectual Property and Copyright Statements . . . . . . . 27
1 Terminology 1. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and
indicate requirement levels for compliant SIP implementations. indicate requirement levels for compliant implementations.
2 Introduction 2. Introduction
The Session Initiation Protocol (SIP) [2] is a flexible, yet simple The Session Initiation Protocol (SIP) [2] is a flexible, yet simple
tool for establishing interactive connections across the Internet. tool for establishing interactive connections across the Internet.
Part of this flexibility is the ease with which it can be extended Part of this flexibility is the ease with which it can be extended
(with new methods, new header fields, new body types, and new (with new methods, new header fields, new body types, and new
parameters), and there have been countless proposals that have been parameters), and there have been countless proposals that have been
made to do just that. An IETF process has been put into place which made to do just that. An IETF process has been put into place which
defines how extensions are to be made to the SIP protocol [9]. That defines how extensions are to be made to the SIP protocol [8]. That
process is designed to ensure that extensions are made which are process is designed to ensure that extensions are made which are
appropriate for SIP (as opposed to being done in some other appropriate for SIP (as opposed to being done in some other
protocol), that these extensions fit within the model and framework protocol), that these extensions fit within the model and framework
provided by SIP and are consistent with its operation, and that these provided by SIP and are consistent with its operation, and that these
extensions solve problems generically rather than for a specific use extensions solve problems generically rather than for a specific use
case. However, [9] does not provide the technical guidelines needed case. However, [8] does not provide the technical guidelines needed
to assist that process. This specification helps to meet that need. to assist that process. This specification helps to meet that need.
This specification first provides a set of guidelines to help decide This specification first provides a set of guidelines to help decide
whether a certain piece of functionality is appropriately done in whether a certain piece of functionality is appropriately done in
SIP. Assuming the functionality is appropriate, it then points out SIP. Assuming the functionality is appropriate, it then points out
issues which extensions should deal with from within their issues which extensions should deal with from within their
specification. Finally, it discusses common interactions with specification. Finally, it discusses common interactions with
existing SIP features which often cause difficulties in extensions. existing SIP features which often cause difficulties in extensions.
3 Should I define a SIP Extension? 3. Should I define a SIP Extension?
The first question to be addressed when defining a SIP extension is: The first question to be addressed when defining a SIP extension is:
is a SIP extension the best solution to my problem? SIP has been is a SIP extension the best solution to my problem? SIP has been
proposed as a solution for numerous problems, including mobility, proposed as a solution for numerous problems, including mobility,
configuration and management, QoS control, call control, caller configuration and management, QoS control, call control, caller
preferences, device control, third party call control, and MPLS path preferences, device control, third party call control, and MPLS path
setup, to name a few. Clearly, not every problem can be solved by a setup, to name a few. Clearly, not every problem can be solved by a
SIP extension. More importantly, some problems that could be solved SIP extension. More importantly, some problems that could be solved
by a SIP extension, probably shouldn't. by a SIP extension, probably shouldn't.
skipping to change at page 4, line 10 skipping to change at page 5, line 27
appropriate solution to their problem, we present two broad criteria. appropriate solution to their problem, we present two broad criteria.
First, the problem SHOULD fit into the general purvey of SIP's First, the problem SHOULD fit into the general purvey of SIP's
solution space. Secondly, the solution MUST conform to the general solution space. Secondly, the solution MUST conform to the general
SIP architectural model. SIP architectural model.
While the first criteria might seem obvious, we have observed that While the first criteria might seem obvious, we have observed that
numerous extensions to SIP have been proposed because some function numerous extensions to SIP have been proposed because some function
is needed in a device which also speaks SIP. The argument is is needed in a device which also speaks SIP. The argument is
generally given that "I'd rather implement one protocol than many". generally given that "I'd rather implement one protocol than many".
As an example, user agents, like all other IP hosts, need some way to As an example, user agents, like all other IP hosts, need some way to
obtain their IP address. This is generally done through DHCP [10]. obtain their IP address. This is generally done through DHCP [9].
SIP's multicast registration mechanisms might supply an alternate way SIP's multicast registration mechanisms might supply an alternate way
to obtain an IP address. This would eliminate the need for DHCP in to obtain an IP address. This would eliminate the need for DHCP in
clients. However, we do not believe such extensions are appropriate. clients. However, we do not believe such extensions are appropriate.
We believe that protocols should be defined to provide specific, We believe that protocols should be defined to provide specific,
narrow functions, rather than being defined based on all narrow functions, rather than being defined based on all
communications requirements between a pair of devices. The latter communications requirements between a pair of devices. The latter
approach to protocol design yields modular protocols with broad approach to protocol design yields modular protocols with broad
application. It also facilitates extensibility and growth; single application. It also facilitates extensibility and growth; single
protocols can be removed and changed without affecting the entire protocols can be removed and changed without affecting the entire
system. We observe that this approach to protocol engineering mirrors system. We observe that this approach to protocol engineering mirrors
skipping to change at page 6, line 25 skipping to change at page 7, line 42
also needed by many other application layer protocols, SHOULD NOT be also needed by many other application layer protocols, SHOULD NOT be
addressed within SIP. addressed within SIP.
3.2 SIP Architectural Model 3.2 SIP Architectural Model
We describe here some of the primary architectual assumptions which We describe here some of the primary architectual assumptions which
underly SIP. Extensions which violate these assumptions should be underly SIP. Extensions which violate these assumptions should be
examined more carefully to determine their appropriateness for SIP. examined more carefully to determine their appropriateness for SIP.
Session independence: SIP is independent of the session it Session independence: SIP is independent of the session it
establishes. This includes the type of session, be it establishes. This includes the type of session, be it audio,
audio, video, game, chat session, or virtual reality. SIP video, game, chat session, or virtual reality. SIP operation
operation SHOULD NOT be dependent on some characteristic of SHOULD NOT be dependent on some characteristic of the session. SIP
the session. SIP is not specific to VoIP only. Any is not specific to VoIP only. Any extensions to SIP MUST consider
extensions to SIP MUST consider the application of SIP to a the application of SIP to a variety of different session types.
variety of different session types.
SIP and Session Path Independence: We have already touched on SIP and Session Path Independence: We have already touched on this
this once, but it is worth noting again. The set of routers once, but it is worth noting again. The set of routers and/or
and/or networks and/or autonomous systems traversed by SIP networks and/or autonomous systems traversed by SIP messages are
messages are unrelated to the set of routers and/or unrelated to the set of routers and/or networks and/or autonomous
networks and/or autonomous systems traversed by session systems traversed by session packets. They may be the same in some
packets. They may be the same in some cases, but it is cases, but it is fundamental to SIP's architecture that they need
fundamental to SIP's architecture that they need not be the not be the same. Extensions which only work under some assumption
same. Extensions which only work under some assumption of of overlap are not generally applicable to SIP's operation and
overlap are not generally applicable to SIP's operation and
should be scrutinized carefully. should be scrutinized carefully.
Multi-provider and Multi-hop: SIP assumes that its messages will Multi-provider and Multi-hop: SIP assumes that its messages will
traverse the Internet. That is, SIP works through multiple traverse the Internet. That is, SIP works through multiple
networks administered by different providers. It is also networks administered by different providers. It is also assumed
assumed that SIP messages traverse many hops (where each that SIP messages traverse many hops (where each hop is a proxy).
hop is a proxy). Extensions SHOULD NOT work only under the Extensions SHOULD NOT work only under the assumption of a single
assumption of a single hop or single provider. hop or single provider.
Transactional: SIP is a request/response protocol, possibly Transactional: SIP is a request/response protocol, possibly enhanced
enhanced with intermediate responses. Many of the rules of with intermediate responses. Many of the rules of operation in SIP
operation in SIP are based on general processing of are based on general processing of requests and responses. This
requests and responses. This includes the reliability includes the reliability mechanisms, routing mechanisms, and state
mechanisms, routing mechanisms, and state maintenance maintenance rules. Extensions SHOULD NOT add messages that are not
rules. Extensions SHOULD NOT add messages that are not
within the request-response model. within the request-response model.
Proxies can ignore bodies: In order for proxies to scale well, Proxies can ignore bodies: In order for proxies to scale well, they
they must be able to operate with minimal message must be able to operate with minimal message processing. SIP has
processing. SIP has been engineered so that proxies can been engineered so that proxies can always ignore bodies.
always ignore bodies. Extensions SHOULD NOT require proxies Extensions SHOULD NOT require proxies to examine bodies.
to examine bodies.
Proxies don't need to understand the method: Processing of Proxies don't need to understand the method: Processing of requests
requests in proxies does not depend on the method, except in proxies does not depend on the method, except for the well
for the well known methods INVITE, ACK, and CANCEL. This known methods INVITE, ACK, and CANCEL. This allows for
allows for extensibility. Extensions MUST NOT define new extensibility. Extensions MUST NOT define new methods which must
methods which must be understood by proxies. be understood by proxies.
INVITE messages carry full state: An initial INVITE message for INVITE messages carry full state: An initial INVITE message for a
a session is nearly identical (the exception is the tag) to session is nearly identical (the exception is the tag) to a
a re-INVITE message to modify some characteristic of the re-INVITE message to modify some characteristic of the session.
session. This full state property is fundamental to SIP, This full state property is fundamental to SIP, and is critical
and is critical for robustness of SIP systems. Extensions for robustness of SIP systems. Extensions SHOULD NOT modify
SHOULD NOT modify INVITE processing such that data spanning INVITE processing such that data spanning multiple INVITEs must be
multiple INVITEs must be collected in order to perform some collected in order to perform some feature.
feature.
Generality over efficiency: Wherever possible, SIP has favored Generality over efficiency: Wherever possible, SIP has favored
general purpose components rather than narrow ones. If some general purpose components rather than narrow ones. If some
capability is added to support one service, but a slightly capability is added to support one service, but a slightly broader
broader capability can support a larger variety of services capability can support a larger variety of services (at the cost
(at the cost of complexity or message sizes), the broader of complexity or message sizes), the broader capability SHOULD be
capability SHOULD be preferred. preferred.
The Request URI is the primary key for forwarding: Forwarding The Request URI is the primary key for forwarding: Forwarding logic
logic at SIP servers depends primarily on the request URI at SIP servers depends primarily on the request URI (this is
(this is different from request routing in SIP, which uses different from request routing in SIP, which uses the Route header
the Route header fields to pass a request through fields to pass a request through intermediate proxies). It is
intermediate proxies). It is fundamental to the operation fundamental to the operation of SIP that the request URI indicate
of SIP that the request URI indicate a resource that, under a resource that, under normal operations, resolves to the desired
normal operations, resolves to the desired recipient. recipient. Extensions SHOULD NOT use other components of the SIP
Extensions SHOULD NOT use other components of the SIP message as the primary forwarding key, and SHOULD NOT modify the
message as the primary forwarding key, and SHOULD NOT semantics of the request URI.
modify the semantics of the request URI.
Heterogeneity is the norm: SIP supports hetereogeneous devices. Heterogeneity is the norm: SIP supports hetereogeneous devices. It
It has built in mechanisms for determining the set of has built in mechanisms for determining the set of overlapping
overlapping protocol functionalities. Extensions SHOULD NOT protocol functionalities. Extensions SHOULD NOT be defined which
be defined which only function if all devices support the only function if all devices support the extension.
extension.
4 Issues to be Addressed 4. Issues to be Addressed
Given an extension has met the litmus tests in the previous section, Given an extension has met the litmus tests in the previous section,
there are several issues that all extensions should take into there are several issues that all extensions should take into
consideration. consideration.
4.1 Backwards Compatibility 4.1 Backwards Compatibility
One of the most important issues to consider is whether the new One of the most important issues to consider is whether the new
extension is backwards compatible with baseline SIP. This is tightly extension is backwards compatible with baseline SIP. This is tightly
coupled with how the Require, Proxy-Require, and Supported header coupled with how the Require, Proxy-Require, and Supported header
fields are used. fields are used.
If an extension consists of new header fields or header field If an extension consists of new header fields or header field
parameters inserted by a user agent in a request with an existing parameters inserted by a user agent in a request with an existing
method, and the request cannot be processed reasonably by a proxy method, and the request cannot be processed reasonably by a proxy
and/or user agent without understanding the header fields or and/or user agent without understanding the header fields or
parameters, the extension MUST mandate the usage of the Require parameters, the extension MUST mandate the usage of the Require and/
and/or Proxy-Require header fields in the request. These extensions or Proxy-Require header fields in the request. These extensions are
are not backwards compatible with SIP. The result of mandating usage not backwards compatible with SIP. The result of mandating usage of
of these header fields means that requests cannot be serviced unless these header fields means that requests cannot be serviced unless the
the entities being communicated with also understand the extension. entities being communicated with also understand the extension. If
If some entity does not understand the extension, the request will be some entity does not understand the extension, the request will be
rejected. The UAC can then handle this in one of two ways. In the rejected. The UAC can then handle this in one of two ways. In the
first, the request simply fails, and the service cannot be provided. first, the request simply fails, and the service cannot be provided.
This is basically an interoperability failure. In the second case, This is basically an interoperability failure. In the second case,
the UAC retries the request without the extension. This will preserve the UAC retries the request without the extension. This will preserve
interoperability, at the cost of a "dual stack" implementation in a interoperability, at the cost of a "dual stack" implementation in a
UAC (processing rules for operation with and without the extension). UAC (processing rules for operation with and without the extension).
As the number of extensions increases, this leads to an exponential As the number of extensions increases, this leads to an exponential
explosion in the sets of processing rules a UAC may need to explosion in the sets of processing rules a UAC may need to
implement. The result is excessive complexity. implement. The result is excessive complexity.
Because of the possibility of interoperability and complexity Because of the possibility of interoperability and complexity
problems that result from the usage of Require and Proxy-Require, we problems that result from the usage of Require and Proxy-Require, we
believe the following guidelines are appropriate: believe the following guidelines are appropriate:
o The usage of these header fields in requests for basic SIP o The usage of these header fields in requests for basic SIP
services (in particular, session initiation and termination) services (in particular, session initiation and termination) is
is NOT RECOMMENDED. The less frequently a particular extension NOT RECOMMENDED. The less frequently a particular extension is
is needed in a request, the more reasonable it is to use these needed in a request, the more reasonable it is to use these header
header fields. fields.
o The Proxy-Require header field SHOULD be avoided at all costs. o The Proxy-Require header field SHOULD be avoided at all costs. The
The failure likelihood in an individual proxy stays constant, failure likelihood in an individual proxy stays constant, but the
but the path failure grows exponentially with the number of path failure grows exponentially with the number of hops. On the
hops. On the other hand, the Require header field only other hand, the Require header field only mandates that a single
mandates that a single entity, the UAS, support the extension. entity, the UAS, support the extension. Usage of Proxy-Require is
Usage of Proxy-Require is thus considered exponentially worse thus considered exponentially worse than usage of the Require
than usage of the Require header field. header field.
o If either Require or Proxy-Require are used by an extension, o If either Require or Proxy-Require are used by an extension, the
the extension SHOULD discuss how to fall back to baseline SIP extension SHOULD discuss how to fall back to baseline SIP
operation if the request is rejected with a 420 response. operation if the request is rejected with a 420 response.
Extensions which define new methods do not need to use the Require Extensions which define new methods do not need to use the Require
header field. SIP defines mechanisms which allow a UAC to know header field. SIP defines mechanisms which allow a UAC to know
whether a new method is understood by a UAS. This includes both the whether a new method is understood by a UAS. This includes both the
OPTIONS request, and the 405 (Method Not Allowed) response with the OPTIONS request, and the 405 (Method Not Allowed) response with the
Allow header field. It is fundamental to SIP that proxies do not need Allow header field. It is fundamental to SIP that proxies do not need
to understand the semantics of a new method in order to process it. to understand the semantics of a new method in order to process it.
If an extension defines a new method which must be understood by If an extension defines a new method which must be understood by
proxies in order to be processed, a Proxy-Require header field is proxies in order to be processed, a Proxy-Require header field is
skipping to change at page 9, line 33 skipping to change at page 11, line 30
upon. upon.
In order to achieve backwards compatibility for extensions that In order to achieve backwards compatibility for extensions that
define new methods, the Allow header field is used. There are two define new methods, the Allow header field is used. There are two
types of new methods - those that are used for established dialogs types of new methods - those that are used for established dialogs
(initiated by INVITE, for example), and those that are sent as the (initiated by INVITE, for example), and those that are sent as the
initial request to a UA. Since INVITE and its response both SHOULD initial request to a UA. Since INVITE and its response both SHOULD
contain an Allow header field, a UA can readily determine whether the contain an Allow header field, a UA can readily determine whether the
new method can be supported within the dialog. For example, once an new method can be supported within the dialog. For example, once an
INVITE dialog is established, a user agent could determine if the INVITE dialog is established, a user agent could determine if the
REFER method [11] is supported if it is present in an Allow header. REFER method [10] is supported if it is present in an Allow header.
If it was, the "transfer" button on the UI could be "greyed out" once If it was, the "transfer" button on the UI could be ``greyed out''
the call is established. once the call is established.
Another type of extension are those which require a proxy to insert Another type of extension are those which require a proxy to insert
header fields or header field parameters into a request as it header fields or header field parameters into a request as it
traverses the network, or for the UAS to insert header fields or traverses the network, or for the UAS to insert header fields or
header field parameters into a response. For some extensions, if the header field parameters into a response. For some extensions, if the
UAC or UAS does not understand these header fields, the message can UAC or UAS does not understand these header fields, the message can
still be processed correctly. These extensions are completely still be processed correctly. These extensions are completely
backwards compatible. backwards compatible.
Most other extensions of this type require that the server only Most other extensions of this type require that the server only
skipping to change at page 10, line 12 skipping to change at page 12, line 9
extension, so that it can apply the extension to the response. By extension, so that it can apply the extension to the response. By
their nature, these extensions may not always be able to be applied their nature, these extensions may not always be able to be applied
to every response. to every response.
If an extension requires a proxy to insert a header field or If an extension requires a proxy to insert a header field or
parameter into a request, and this header field or parameter needs to parameter into a request, and this header field or parameter needs to
be understood by both UAC and UAS to be executed correctly, a be understood by both UAC and UAS to be executed correctly, a
combination of the Require and the Supported mechanism will need to combination of the Require and the Supported mechanism will need to
be used. The proxy can insert a Require header field into the be used. The proxy can insert a Require header field into the
request, given the Supported header field is present. An example of request, given the Supported header field is present. An example of
such an extension is the SIP Session Timer [12]. such an extension is the SIP Session Timer [11].
Yet another type of extension is that which defines new body types to Yet another type of extension is that which defines new body types to
be carried in SIP messages. According to the SIP specification, be carried in SIP messages. According to the SIP specification,
bodies must be understood in order to process a request. As such, the bodies must be understood in order to process a request. As such, the
interoperability issues are similar to new methods. However, the interoperability issues are similar to new methods. However, the
Content-Disposition header field has been defined to allow a client Content-Disposition header field has been defined to allow a client
or server to indicate that the message body is optional [2]. Usage of or server to indicate that the message body is optional [2]. Usage of
optional bodies, as opposed to mandatory ones, is RECOMMENDED optional bodies, as opposed to mandatory ones, is RECOMMENDED
wherever possible. wherever possible.
skipping to change at page 10, line 36 skipping to change at page 12, line 33
that establish a dialog, inclusion of Accept in the request and its that establish a dialog, inclusion of Accept in the request and its
success responses is RECOMMENDED. This will allow both parties to success responses is RECOMMENDED. This will allow both parties to
determine what body types are supported by their peers. Subsequent determine what body types are supported by their peers. Subsequent
messaging between the peers would then only include body types that messaging between the peers would then only include body types that
were indicated as being understood. were indicated as being understood.
4.2 Security 4.2 Security
Security is an important component of any protocol. Designers of SIP Security is an important component of any protocol. Designers of SIP
extensions need to carefully consider if additional security extensions need to carefully consider if additional security
requirements are required over those described in RFC3261. Frequently requirements are required over those described in RFC 3261.
authorization requirements, and requirements for end-to-end integrity Frequently authorization requirements, and requirements for
are the most overlooked. end-to-end integrity are the most overlooked.
SIP extensions MUST consider how (or if) they affect usage of the SIP extensions MUST consider how (or if) they affect usage of the
general SIP security mechanisms. Most extensions should not require general SIP security mechanisms. Most extensions should not require
any new security capabilities beyond general purpose SIP. If they do, any new security capabilities beyond general purpose SIP. If they do,
it is likely that the security mechanism has more general purpose it is likely that the security mechanism has more general purpose
application, and should be considered an extension in its own right. application, and should be considered an extension in its own right.
4.3 Terminology 4.3 Terminology
RFC 3261 has an extensive terminology section that defines terms like RFC 3261 has an extensive terminology section that defines terms like
skipping to change at page 11, line 19 skipping to change at page 13, line 17
field values, for example. Document authors SHOULD do a careful field values, for example. Document authors SHOULD do a careful
review of their documents for proper usage of these terms. review of their documents for proper usage of these terms.
4.4 Syntactic Issues 4.4 Syntactic Issues
Extensions that define new methods SHOULD use all capitals for the Extensions that define new methods SHOULD use all capitals for the
method name. Method names SHOULD be less than 10 characters, and method name. Method names SHOULD be less than 10 characters, and
SHOULD attempt to convey the general meaning of the request. SHOULD attempt to convey the general meaning of the request.
Method names are case sensitive, and therefore there is no Method names are case sensitive, and therefore there is no
requirement that they be capitalized. However, using requirement that they be capitalized. However, using capitalized
capitalized method names keeps with a long-standing method names keeps with a long-standing convention in SIP and many
convention in SIP and many similar protocols, such as HTTP similar protocols, such as HTTP [12] and RTSP [13]
[13] and RTSP [14].
Extensions that define new header fields that are anticipated to be Extensions that define new header fields that are anticipated to be
heavily used SHOULD define a compact form if those header fields are heavily used SHOULD define a compact form if those header fields are
more than four characters. Compact header fields MUST be a single more than four characters. Compact header fields MUST be a single
character. When all 26 characters are exhausted, new compact forms character. When all 26 characters are exhausted, new compact forms
will no longer be defined. Header field names SHOULD be composed will no longer be defined. Header field names SHOULD be composed
primarily of ASCII characters and marks. They SHOULD be descriptive primarily of ASCII characters and marks. They SHOULD be descriptive
but reasonably brief. Although header field names are case but reasonably brief. Although header field names are case
insensitive, a single common capitalization SHOULD be used throughout insensitive, a single common capitalization SHOULD be used throughout
the document. It is RECOMMENDED that this be camel case. the document. It is RECOMMENDED that each English word present in the
header field name have its first letter capitalized. For example,
"ThisIsANewHeader".
As an example, the following are poor choices for header field names: As an example, the following are poor choices for header field names:
ThisIsMyNewHeaderThatDoesntDoVeryMuchButItHasANiceName ThisIsMyNewHeaderThatDoesntDoVeryMuchButItHasANiceName
--.!A --.!A
Function Function
Case sensitivity of parameters and values is a constant source of Case sensitivity of parameters and values is a constant source of
confusion, a difficulty that plagued RFC 2543 [15]. This has been confusion, a difficulty that plagued RFC 2543 [14]. This has been
made simple through the usage of the BNF constructs of RFC 2234 [3], made simple through the usage of the BNF constructs of RFC 2234 [5],
which have clear rules of case sensivitity and insensitivity. which have clear rules of case sensivitity and insensitivity.
Therefore, the BNF for an extension completely defines the matching Therefore, the BNF for an extension completely defines the matching
rules. rules.
Extensions MUST be consistent with the SIP conventions for Extensions MUST be consistent with the SIP conventions for
sensitivity. Methods MUST be case sensitive. Header field names MUST sensitivity. Methods MUST be case sensitive. Header field names MUST
be case insensitive. Header field parameter names MUST be case be case insensitive. Header field parameter names MUST be case
insensitive. Header field values and parameter values are sometimes insensitive. Header field values and parameter values are sometimes
case sensitive, and sometimes case insensitive. However, generally case sensitive, and sometimes case insensitive. However, generally
they SHOULD be case insensitive. Definiting a case sensitive they SHOULD be case insensitive. Definiting a case sensitive
component requires explicitly listing each character through its component requires explicitly listing each character through its
ASCII code. ASCII code.
Extensions which contain freeform text MUST allow that text to be Extensions which contain freeform text MUST allow that text to be
UTF-8, as per the IETF policies on character set usage [4]. This UTF-8, as per the IETF policies on character set usage [3]. This
ensures that SIP remains an internationalized standard. As a general ensures that SIP remains an internationalized standard. As a general
guideline, freeform text is never needed by programs in order to guideline, freeform text is never needed by programs in order to
perform protocol processing. It is usually entered by and displayed perform protocol processing. It is usually entered by and displayed
to the user. If an extension uses a parameter which can contain UTF-8 to the user. If an extension uses a parameter which can contain UTF-8
encoded characters, and that extension requires a comparison to be encoded characters, and that extension requires a comparison to be
made of this parameter to other parameters, the comparison MUST be made of this parameter to other parameters, the comparison MUST be
case sensitive. Case insensitive comparison rules for UTF-8 text are, case sensitive. Case insensitive comparison rules for UTF-8 text are,
at this time, impossible and MUST be avoided. at this time, impossible and MUST be avoided.
Extensions which make use of dates MUST use the SIP-Date BNF defined Extensions which make use of dates MUST use the SIP-Date BNF defined
in RFC 3261 [2]. No other date formats are allowed. However, the in RFC 3261 \cite{RFC3261}. No other date formats are allowed.
usage of absolute dates in order to determine intervals (for example, However, the usage of absolute dates in order to determine intervals
the time at which some timer fires) is NOT RECOMMENDED. This is (for example, the time at which some timer fires) is NOT RECOMMENDED.
because it requires synchronized time between peers, and this is This is because it requires synchronized time between peers, and this
frequently not the case. Therefore, relative times, expressed in is frequently not the case. Therefore, relative times, expressed in
numbers of seconds, SHOULD be used. numbers of seconds, SHOULD be used.
Extensions which include network layer addresses SHOULD permit dotted Extensions which include network layer addresses SHOULD permit dotted
quad IPv4 addresses, IPv6 addresses in the format described in [5], quad IPv4 addresses, IPv6 addresses in the format described in [4],
and domain names. and domain names.
Extensions which have header fields containing URIs SHOULD allow any Extensions which have header fields containing URIs SHOULD allow any
URI, not just SIP URIs. URI, not just SIP URIs.
Header fields MUST follow the standard formatting for SIP, defined Header fields MUST follow the standard formatting for SIP, defined
as: as:
header = header-name HCOLON header-value header = header-name HCOLON header-value
*(COMMA header-value) *(COMMA header-value)
skipping to change at page 13, line 21 skipping to change at page 15, line 17
Developers of extensions SHOULD allow for extension parameters in Developers of extensions SHOULD allow for extension parameters in
their header fields. their header fields.
Header Fields that contain a list of URIs SHOULD follow the same Header Fields that contain a list of URIs SHOULD follow the same
syntax as the Contact header field in SIP. Implementors are also syntax as the Contact header field in SIP. Implementors are also
encouraged to always wrap these URI in angle brackets "<" and ">". We encouraged to always wrap these URI in angle brackets "<" and ">". We
have found this to be a frequently misimplemented feature. have found this to be a frequently misimplemented feature.
Beyond compact form, there is no need to define compressed versions Beyond compact form, there is no need to define compressed versions
of header field values. Compression of SIP messages SHOULD be handled of header field values. Compression of SIP messages SHOULD be handled
at lower layers, for example, using IP payload compression [16] or at lower layers, for example, using IP payload compression [15] or
signalling compression [17]. signalling compression [16].
Syntax for header fields is expressed in Augmented Backus-Naur Form Syntax for header fields is expressed in Augmented Backus-Naur Form
and MUST follow the format of RFC 2234 [3]. Extensions MUST make use and MUST follow the format of RFC 2234 [5]. Extensions MUST make use
of the primitive components defined in RFC 3261 [2]. If the of the primitive components defined in RFC 3261 [2]. If the
construction for a BNF element is defined in another specification, construction for a BNF element is defined in another specification,
it is RECOMMENDED that the construction be referenced rather than it is RECOMMENDED that the construction be referenced rather than
copied. The reference SHOULD include both the document and section copied. The reference SHOULD include both the document and section
number. All BNF elements must be either defined or referenced. number. All BNF elements must be either defined or referenced.
It is RECOMMENDED that BNF be collected into a single section near It is RECOMMENDED that BNF be collected into a single section near
the end of the document. the end of the document.
All tokens and quoted strings are separated by explicit linear white All tokens and quoted strings are separated by explicit linear white
skipping to change at page 14, line 33 skipping to change at page 16, line 24
4.6 Examples Section 4.6 Examples Section
The specification SHOULD contain a section that gives examples of The specification SHOULD contain a section that gives examples of
call flows and message formatting. Extensions which define call flows and message formatting. Extensions which define
substantial new syntax SHOULD include examples of messages containing substantial new syntax SHOULD include examples of messages containing
that syntax. Examples of message flows should be given to cover that syntax. Examples of message flows should be given to cover
common cases and at least one failure or unusual case. common cases and at least one failure or unusual case.
For an example of how to construct a good examples section, see the For an example of how to construct a good examples section, see the
message flows and message formatting defined in the Basic Call Flows message flows and message formatting defined in the Basic Call Flows
specification [18]. Note that complete messages SHOULD be used. Be specification [17]. Note that complete messages SHOULD be used. Be
careful to include tags, Via header fields (with the branch ID careful to include tags, Via header fields (with the branch ID
cookie), Max-Forwards, Content-Lengths, Record-Route and Route header cookie), Max-Forwards, Content-Lengths, Record-Route and Route header
fields. Example INVITE messages MAY omit session descriptions, and fields. Example INVITE messages MAY omit session descriptions, and
Content-Length values MAY be set to "..." to indicate that the value Content-Length values MAY be set to "..." to indicate that the value
is not provided. However, the specification MUST explicitly call out is not provided. However, the specification MUST explicitly call out
the meanining of the "..." and explicitly indicate that session the meaning of the "..." and explicitly indicate that session
descriptions were not included. descriptions were not included.
4.7 Overview Section 4.7 Overview Section
Too often, extension documents dive into detailed syntax and Too often, extension documents dive into detailed syntax and
semantics without giving a general overview of operation. This makes semantics without giving a general overview of operation. This makes
understanding of the extension harder. It is RECOMMENDED that understanding of the extension harder. It is RECOMMENDED that
extensions have a protocol overview section which discusses the basic extensions have a protocol overview section which discusses the basic
operation of the extension. Basic operation usually consists of the operation of the extension. Basic operation usually consists of the
message flow, in temporal order, for the most common case covered by message flow, in temporal order, for the most common case covered by
skipping to change at page 15, line 15 skipping to change at page 17, line 7
specification should explicitly state that the overview is tutorial specification should explicitly state that the overview is tutorial
in nature only. in nature only.
4.8 IANA Considerations Section 4.8 IANA Considerations Section
Documents which define new SIP extensions will invariably have IANA Documents which define new SIP extensions will invariably have IANA
Considerations sections. Considerations sections.
If your extension is defining a new event package, you MUST register If your extension is defining a new event package, you MUST register
that package. RFC 3265 [6] provides the registration template. See that package. RFC 3265 [6] provides the registration template. See
[19] for an example of the registration of a new event package. [18] for an example of the registration of a new event package.
If your extension is defining a new header field, you MUST register If your extension is defining a new header field, you MUST register
that header field. RFC 3261 [2] provides a registration template. See that header field. RFC 3261 [2] provides a registration template. See
Section 8.2 of RFC 3262 [20] for an example of how to register new Section 8.2 of RFC 3262 [19] for an example of how to register new
SIP header fields. SIP header fields.
If your extension is defining a new response code, you MUST register If your extension is defining a new response code, you MUST register
that response code. RFC 3261 [2] provides a registration template. that response code. RFC 3261 [2] provides a registration template.
See [12] for an example of how to register a new response code. See [11] for an example of how to register a new response code.
If your extension is defining a new SIP method, you MUST register If your extension is defining a new SIP method, you MUST register
that method. RFC 3261 [2] provides a registration template. See that method. RFC 3261 [2] provides a registration template. See
Section 10 of RFC 3311 [21] for an example of how to register a new Section 10 of RFC 3311 [20] for an example of how to register a new
SIP method. SIP method.
Many SIP extensions make use of option tags, carried in the Require, Many SIP extensions make use of option tags, carried in the Require,
Proxy-Require and Supported header fields. Section 4.1 discusses some Proxy-Require and Supported header fields. Section Section 4.1
of the issues involved in the usage of these header fields. If your discusses some of the issues involved in the usage of these header
extension does require them, you MUST register an option tag for your fields. If your extension does require them, you MUST register an
extension. RFC 3261 [2] provides a registration template. See Section option tag for your extension. RFC 3261 [2] provides a registration
8.1 of RFC 3262 [20] for an example of how to register an option tag. template. See Section 8.1 of RFC 3262 [19] for an example of how to
register an option tag.
Some SIP extensions will require establishment of their own IANA Some SIP extensions will require establishment of their own IANA
registries. RFC 2434 [7] provides guidance on how and when IANA registries. RFC 2434 [21] provides guidance on how and when IANA
registries are established. For an example of how to set one up, see registries are established. For an example of how to set one up, see
Section 6 of RFC 3265 [6] for an example. Section 6 of RFC 3265 [6] for an example.
4.9 Document Naming Conventions 4.9 Document Naming Conventions
An important decision to be made about the extension is its title. An important decision to be made about the extension is its title.
The title MUST indicate that the document is an extension to SIP. It The title MUST indicate that the document is an extension to SIP. It
is RECOMMENDED that the title follow the basic form of "A [summary of is RECOMMENDED that the title follow the basic form of "A [summary of
function] for the Session Initiation Protocol (SIP)", where the function] for the Session Initiation Protocol (SIP)", where the
summary of function is a one to three word description of the summary of function is a one to three word description of the
skipping to change at page 16, line 22 skipping to change at page 18, line 14
the name of the method. the name of the method.
Note that the acronymn SIP MUST be expanded in the titles of RFCs, as Note that the acronymn SIP MUST be expanded in the titles of RFCs, as
per [22]. per [22].
4.10 Additional Considerations for New Methods 4.10 Additional Considerations for New Methods
Extensions which define new methods SHOULD take into consideration, Extensions which define new methods SHOULD take into consideration,
and discuss, the following issues: and discuss, the following issues:
o Can it contain bodies? If so, what is the meaning of the o Can it contain bodies? If so, what is the meaning of the presence
presence of those bodies? What body types are allowed? of those bodies? What body types are allowed?
o Can a transaction with this request method occur while another o Can a transaction with this request method occur while another
transaction, in the same and/or reverse direction, is in transaction, in the same and/or reverse direction, is in progress?
progress?
o The extension MUST define which header fields can be present o The extension MUST define which header fields can be present in
in requests of that method. It is RECOMMENDED that this requests of that method. It is RECOMMENDED that this information
information be represented as a new column of Table 2/3 of RFC be represented as a new column of Table 2/3 of RFC 3261 [2]. The
3261 [2]. The table MUST contain rows for all header fields table MUST contain rows for all header fields defined in standards
defined in standards track RFCs at the time of writing of the track RFCs at the time of writing of the extension.
extension.
o Can the request be sent within a dialog, or does it establish o Can the request be sent within a dialog, or does it establish a
a dialog? dialog?
o Is it a target refresh request? o Is it a target refresh request?
o Extensions to SIP that define new methods MAY specify whether o Extensions to SIP that define new methods MAY specify whether
offers and answers can appear in requests of that method or offers and answers can appear in requests of that method or its
its responses. However, those extensions MUST adhere to the responses. However, those extensions MUST adhere to the protocol
protocol rules specified in [8], and MUST adhere to the rules specified in [23], and MUST adhere to the additional
additional constraints for offers and answers as specified in constraints for offers and answers as specified in SIP [2].
SIP [2].
o Because of the nature of reliability treatment of requests o Because of the nature of reliability treatment of requests with
with new methods, those requests need to be answered new methods, those requests need to be answered immediately by the
immediately by the UAS. Protocol extensions that require UAS. Protocol extensions that require longer durations for the
longer durations for the generation of a response (such as a generation of a response (such as a new method that requires human
new method that requires human interaction) SHOULD instead use interaction) SHOULD instead use two transactions - one to send the
two transactions - one to send the request, and another in the request, and another in the reverse direction to convey the result
reverse direction to convey the result of the request. An of the request. An example of that is SUBSCRIBE and NOTIFY [6].
example of that is SUBSCRIBE and NOTIFY [6].
o The CANCEL request can be used for a particular extension o The CANCEL request can be used for a particular extension method
method on a method-by-method basis. SIP [2] only allows on a method-by-method basis. SIP [2] only allows cancellation of
cancellation of INVITE. Extensions that define new methods INVITE. Extensions that define new methods MUST state whether or
MUST state whether or not transactions initiated by requests not transactions initiated by requests with that method can be
with that method can be cancelled. Furthermore, the rules a cancelled. Furthermore, the rules a UAS should follow upon
UAS should follow upon cancellation of an unanswered request cancellation of an unanswered request MUST be described. Note
MUST be described. Note that, since non-INVITE requests are that, since non-INVITE requests are generally answered
generally answered immediately, cancellation ususally serves immediately, cancellation ususally serves no purpose.
no purpose.
Note that the reliability mechanisms for all new methods must be the Note that the reliability mechanisms for all new methods must be the
same as for BYE. The delayed response feature of INVITE is only same as for BYE. The delayed response feature of INVITE is only
available in INVITE, never for new methods. This means requests with available in INVITE, never for new methods. This means requests with
new SIP methods need to be responded to within short time periods (on new SIP methods need to be responded to within short time periods (on
the order of seconds). the order of seconds).
4.11 Additional Considerations for New Header Fields or Header Field 4.11 Additional Considerations for New Header Fields or Header Field
Parameters Parameters
skipping to change at page 18, line 5 skipping to change at page 19, line 40
responses it can be used in. It is RECOMMENDED that this information responses it can be used in. It is RECOMMENDED that this information
be represented as a new row of Table 2/3 of RFC 3261 [2]. The table be represented as a new row of Table 2/3 of RFC 3261 [2]. The table
MUST contain columns for all methods defined in standards track RFCs MUST contain columns for all methods defined in standards track RFCs
at time of writing of the extension. at time of writing of the extension.
4.12 Additional Considerations for New Body Types 4.12 Additional Considerations for New Body Types
Because SIP can run over UDP, extensions that specify the inclusion Because SIP can run over UDP, extensions that specify the inclusion
of large bodies are frowned upon unless end-to-end congestion of large bodies are frowned upon unless end-to-end congestion
controlled transport can be guaranteed. If at all possible, the controlled transport can be guaranteed. If at all possible, the
content SHOULD be included indirectly [23] even if congestion content SHOULD be included indirectly [7] even if congestion
controlled transports are available. controlled transports are available.
Note that the presence of a body MUST NOT change the nature of the Note that the presence of a body MUST NOT change the nature of the
message. That is, bodies cannot alter the state machinery associated message. That is, bodies cannot alter the state machinery associated
with processing a request of a particular method or a response. with processing a request of a particular method or a response.
Bodies enhance this processing by providing additional data. Bodies enhance this processing by providing additional data.
5 Interactions with SIP Features 5. Interactions with SIP Features
We have observed that certain capabilities of SIP continually We have observed that certain capabilities of SIP continually
interact with extensions in unusual ways. Writers of extensions interact with extensions in unusual ways. Writers of extensions
SHOULD consider the interactions of their extensions with these SIP SHOULD consider the interactions of their extensions with these SIP
capabilities, document any unusual interactions if they exist. The capabilities, document any unusual interactions if they exist. The
most common causes of problems are: most common causes of problems are:
Forking: Forking by far presents the most troublesome Forking: Forking by far presents the most troublesome interactions
interactions with extensions. This is generally because it with extensions. This is generally because it can cause (1) a
can cause (1) a single transmitted request to be received single transmitted request to be received by an unknown number of
by an unknown number of UASs, and (2) a single INVITE UASs, and (2) a single INVITE request to have multiple responses.
request to have multiple responses.
CANCEL and ACK: CANCEL and ACK are "special" SIP requests, in CANCEL and ACK: CANCEL and ACK are "special" SIP requests, in that
that they are exceptions to many of the general request they are exceptions to many of the general request processing
processing rules. The main reason for this special status rules. The main reason for this special status is that CANCEL and
is that CANCEL and ACK are always associated with another ACK are always associated with another request. New methods SHOULD
request. New methods SHOULD consider the meaning of consider the meaning of cancellation, as described above.
cancellation, as described above. Extensions which defined Extensions which defined new header fields in INVITE requests
new header fields in INVITE requests SHOULD consider SHOULD consider whether they also need to be included in ACK and
whether they also need to be included in ACK and CANCEL. CANCEL. Frequently they do, in order to allow a stateless proxy to
Frequently they do, in order to allow a stateless proxy to
route the CANCEL or ACK identically to the INVITE. route the CANCEL or ACK identically to the INVITE.
Routing: The presence of Route header fields in a request can Routing: The presence of Route header fields in a request can cause
cause it to be sent through intermediate proxies. Requests it to be sent through intermediate proxies. Requests that
that establish dialogs can be record-routed, so that the establish dialogs can be record-routed, so that the initial
initial request goes through one set of proxies, and request goes through one set of proxies, and subsequent requests
subsequent requests through a different set. These SIP through a different set. These SIP features can interact in
features can interact in unusual ways with extensions. unusual ways with extensions.
Stateless Proxies: SIP allows a proxy to be stateless. Stateless Stateless Proxies: SIP allows a proxy to be stateless. Stateless
proxies are unable to retransmit messages and cannot proxies are unable to retransmit messages and cannot execute
execute certain services. Extensions which depend on some certain services. Extensions which depend on some kind of proxy
kind of proxy processing SHOULD consider how stateless processing SHOULD consider how stateless proxies affect that
proxies affect that processing. processing.
6. Security Considerations
6 Security Considerations
The nature of this document is such that it does not introduce any The nature of this document is such that it does not introduce any
new security considerations. new security considerations.
7 IANA Considerations 7. IANA Considerations
There are no IANA considerations associated with this specification. There are no IANA considerations associated with this specification.
8 Acknowledgements 8. Acknowledgements
The authors would like to thank Rohan Mahy for his comments. The authors would like to thank Rohan Mahy for his comments.
9 Authors Addresses Normative References
Jonathan Rosenberg [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
dynamicsoft Levels", BCP 14, RFC 2119, March 1997.
72 Eagle Rock Avenue
East Hanover, NJ 07936
email: jdrosen@dynamicsoft.com
Henning Schulzrinne [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Columbia University Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
M/S 0401 Session Initiation Protocol", RFC 3261, June 2002.
1214 Amsterdam Ave.
New York, NY 10027-7003
email: schulzrinne@cs.columbia.edu
10 Normative References [3] Alvestrand, H., "IETF Policy on Character Sets and Languages",
BCP 18, RFC 2277, January 1998.
[1] S. Bradner, "Key words for use in RFCs to indicate requirement [4] Hinden, R., Carpenter, B. and L. Masinter, "Format for Literal
levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. IPv6 Addresses in URL's", RFC 2732, December 1999.
[2] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. [5] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session Specifications: ABNF", RFC 2234, November 1997.
initiation protocol," RFC 3261, Internet Engineering Task Force, June
2002.
[3] "Augmented BNF for syntax specifications: ABNF," RFC 2234, [6] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Internet Engineering Task Force, Nov. 1997. Notification", RFC 3265, June 2002.
[4] H. Alvestrand, "IETF policy on character sets and languages," RFC [7] Olson, S., "A Mechanism for Content Indirection in Session
2277, Internet Engineering Task Force, Jan. 1998. Initiation Protocol (SIP) Messages",
draft-ietf-sip-content-indirect-mech-03 (work in progress), June
2003.
[5] R. Hinden, B. Carpenter, and L. Masinter, "Format for literal Informative References
IPv6 addresses in URL's," RFC 2732, Internet Engineering Task Force,
Dec. 1999.
[6] A. B. Roach, "Session initiation protocol (sip)-specific event [8] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J. and B.
notification," RFC 3265, Internet Engineering Task Force, June 2002. Rosen, "Change Process for the Session Initiation Protocol
(SIP)", BCP 67, RFC 3427, December 2002.
[7] T. Narten and H. Alvestrand, "Guidelines for writing an IANA [9] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
considerations section in RFCs," RFC 2434, Internet Engineering Task March 1997.
Force, Oct. 1998.
[8] J. Rosenberg and H. Schulzrinne, "An offer/answer model with [10] Sparks, R., "The Session Initiation Protocol (SIP) Refer
session description protocol (SDP)," RFC 3264, Internet Engineering Method", RFC 3515, April 2003.
Task Force, June 2002.
11 Informative References [11] Donovan, S. and J. Rosenberg, "Session Timers in the Session
Initiation Protocol (SIP)", draft-ietf-sip-session-timer-12
(work in progress), October 2003.
[9] A. Mankin, S. Bradner, and R. Mahy, "Change process for the [12] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L.,
session initiation protocol (SIP)," Internet Draft, Internet Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
Engineering Task Force, Aug. 2002. Work in progress. HTTP/1.1", RFC 2616, June 1999.
[10] R. Droms, "Dynamic host configuration protocol," RFC 2131, [13] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming
Internet Engineering Task Force, Mar. 1997. Protocol (RTSP)", RFC 2326, April 1998.
[11] R. Sparks, "The SIP refer method," Internet Draft, Internet [14] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,
Engineering Task Force, July 2002. Work in progress. "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[12] S. Donovan and J. Rosenberg, "Session initiation protocol [15] Shacham, A., Monsour, R., Pereira, R. and M. Thomas, "IP
extension for session timer," Internet Draft, Internet Engineering Payload Compression Protocol (IPComp)", RFC 2393, December
Task Force, July 2002. Work in progress. 1998.
[13] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. [16] Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu, Z.
Leach, and T. Berners-Lee, "Hypertext transfer protocol -- HTTP/1.1," and J. Rosenberg, "Signaling Compression (SigComp)", RFC 3320,
RFC 2616, Internet Engineering Task Force, June 1999. January 2003.
[14] H. Schulzrinne, A. Rao, and R. Lanphier, "Real time streaming [17] Johnston, A., "Session Initiation Protocol Basic Call Flow
protocol (RTSP)," RFC 2326, Internet Engineering Task Force, Apr. Examples", draft-ietf-sipping-basic-call-flows-02 (work in
progress), April 2003.
[18] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Package for Registrations", draft-ietf-sipping-reg-event-00
(work in progress), October 2002.
[19] jdrosen@dynamicsoft.com and schulzrinne@cs.columbia.edu,
"Reliability of Provisional Responses in Session Initiation
Protocol (SIP)", RFC 3262, June 2002.
[20] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
Method", RFC 3311, October 2002.
[21] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October
1998. 1998.
[15] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: [22] Reynolds, J. and R. Braden, "Instructions to Request for
session initiation protocol," RFC 2543, Internet Engineering Task Comments (RFC) Authors", draft-rfc-editor-rfc2223bis-07 (work
Force, Mar. 1999. in progress), August 2003.
[16] A. Shacham, R. Monsour, R. Pereira, and M. Thomas, "IP payload [23] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
compression protocol (ipcomp)," RFC 2393, Internet Engineering Task Session Description Protocol (SDP)", RFC 3264, June 2002.
Force, Dec. 1998.
[17] R. Price et al. , "Signaling compression," Internet Draft, Authors' Addresses
Internet Engineering Task Force, June 2002. Work in progress.
[18] A. Johnston et al. , "Session initiation protocol basic call Jonathan Rosenberg
flow examples," Internet Draft, Internet Engineering Task Force, Aug. dynamicsoft
2002. Work in progress. 600 Lanidex Plaza
Parsippany, NJ 07054
US
[19] J. Rosenberg, "A sip event package for registration state," Phone: +1 973 952-5000
Internet Draft, Internet Engineering Task Force, Oct. 2002. Work in EMail: jdrosen@dynamicsoft.com
progress. URI: http://www.jdrosen.net
[20] J. Rosenberg and H. Schulzrinne, "Reliability of provisional Henning Schulzrinne
responses in session initiation protocol (SIP)," RFC 3262, Internet Columbia University
Engineering Task Force, June 2002. M/S 0401
1214 Amsterdam Ave.
New York, NY 10027
US
[21] J. Rosenberg, "The session initiation protocol (SIP) UPDATE EMail: schulzrinne@cs.columbia.edu
method," RFC 3311, Internet Engineering Task Force, Oct. 2002. URI: http://www.cs.columbia.edu/~hgs
[22] J. Reynolds and B. Braden, "Instructions to request for comments Intellectual Property Statement
(RFC) authors," Internet Draft, Internet Engineering Task Force, Apr.
2002. Work in progress.
[23] S. Olson, "Requirements for content indirection in SIP The IETF takes no position regarding the validity or scope of any
messages," Internet Draft, Internet Engineering Task Force, July intellectual property or other rights that might be claimed to
2002. Work in progress. 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement Full Copyright Statement
Copyright (c) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/