draft-ietf-sip-guidelines-08.txt   draft-ietf-sip-guidelines-09.txt 
SIP J. Rosenberg SIP J. Rosenberg
Internet-Draft dynamicsoft Internet-Draft Cisco Systems
Expires: January 16, 2005 H. Schulzrinne Expires: August 17, 2005 H. Schulzrinne
Columbia University Columbia University
July 18, 2004 February 16, 2005
Guidelines for Authors of Extensions to the Session Initiation Guidelines for Authors of Extensions to the Session Initiation
Protocol (SIP) Protocol (SIP)
draft-ietf-sip-guidelines-08 draft-ietf-sip-guidelines-09
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable This document is an Internet-Draft and is subject to all provisions
patent or other IPR claims of which I am aware have been disclosed, of section 3 of RFC 3667. By submitting this Internet-Draft, each
and any of which I become aware will be disclosed, in accordance with author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
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 groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-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://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at 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 January 16, 2005. This Internet-Draft will expire on August 17, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2005).
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 for establishing interactive connections across the Internet. Part
of this flexibility is the ease with which it can be extended. In of this flexibility is the ease with which it can be extended. In
order to facilitate effective and interoperable extensions to SIP, order to facilitate effective and interoperable extensions to SIP,
some guidelines need to be followed when developing SIP extensions. some guidelines need to be followed when developing SIP extensions.
This document outlines a set of such guidelines for authors of SIP This 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Should I define a SIP Extension? . . . . . . . . . . . . . . 5 3. Should I define a SIP Extension? . . . . . . . . . . . . . . 3
3.1 SIP's Solution Space . . . . . . . . . . . . . . . . . . . 5 3.1 SIP's Solution Space . . . . . . . . . . . . . . . . . . . 4
3.2 SIP Architectural Model . . . . . . . . . . . . . . . . . 7 3.2 SIP Architectural Model . . . . . . . . . . . . . . . . . 6
4. Issues to be Addressed . . . . . . . . . . . . . . . . . . . 10 4. Issues to be Addressed . . . . . . . . . . . . . . . . . . . 8
4.1 Backwards Compatibility . . . . . . . . . . . . . . . . . 10 4.1 Backwards Compatibility . . . . . . . . . . . . . . . . . 8
4.2 Security . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2 Security . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . 12 4.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . 11
4.4 Syntactic Issues . . . . . . . . . . . . . . . . . . . . . 13 4.4 Syntactic Issues . . . . . . . . . . . . . . . . . . . . . 11
4.5 Semantics, Semantics, Semantics . . . . . . . . . . . . . 15 4.5 Semantics, Semantics, Semantics . . . . . . . . . . . . . 14
4.6 Examples Section . . . . . . . . . . . . . . . . . . . . . 16 4.6 Examples Section . . . . . . . . . . . . . . . . . . . . . 14
4.7 Overview Section . . . . . . . . . . . . . . . . . . . . . 16 4.7 Overview Section . . . . . . . . . . . . . . . . . . . . . 14
4.8 IANA Considerations Section . . . . . . . . . . . . . . . 16 4.8 IANA Considerations Section . . . . . . . . . . . . . . . 15
4.9 Document Naming Conventions . . . . . . . . . . . . . . . 17 4.9 Document Naming Conventions . . . . . . . . . . . . . . . 16
4.10 Additional Considerations for New Methods . . . . . . . 18 4.10 Additional Considerations for New Methods . . . . . . . 16
4.11 Additional Considerations for New Header Fields or 4.11 Additional Considerations for New Header Fields or
Header Field Parameters . . . . . . . . . . . . . . . . 19 Header Field Parameters . . . . . . . . . . . . . . . . 18
4.12 Additional Considerations for New Body Types . . . . . . 19 4.12 Additional Considerations for New Body Types . . . . . . 18
5. Interactions with SIP Features . . . . . . . . . . . . . . . 20 5. Interactions with SIP Features . . . . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . 21 6. Security Considerations . . . . . . . . . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 22 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 19
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1 Normative References . . . . . . . . . . . . . . . . . . . . 24 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 20
9.2 Informative References . . . . . . . . . . . . . . . . . . . 24 9.2 Informative References . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . 27 Intellectual Property and Copyright Statements . . . . . . . 23
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 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 [8]. That defines how extensions are to be made to the SIP protocol [10]. 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, [8] does not provide the technical guidelines needed case. However, [10] 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?
skipping to change at page 5, line 18 skipping to change at page 3, line 49
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.
To assist engineers in determining whether a SIP extension is an To assist engineers in determining whether a SIP extension is an
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 purview 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 [9]. obtain their IP address. This is generally done through DHCP [11].
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 protocols narrow functions, rather than being defined based on all protocols
needed between a pair of devices. The latter approach to protocol needed between a pair of devices. The former approach to protocol
design yields modular protocols with broad application. It also design yields modular protocols with broad application. It also
facilitates extensibility and growth; single protocols can be removed facilitates extensibility and growth; single protocols can be removed
and changed without affecting the entire system. We observe that and changed without affecting the entire system. We observe that
this approach to protocol engineering mirrors object oriented this approach to protocol engineering mirrors object oriented
software engineering. software engineering.
Our second criteria, that the extension must conform to the general Our second criteria, that the extension must conform to the general
SIP architectural model, ensures that the protocol remains manageable SIP architectural model, ensures that the protocol remains manageable
and broadly applicable. and broadly applicable.
skipping to change at page 8, line 11 skipping to change at page 6, line 40
SIP is not specific to voice only. Any extensions to SIP MUST SIP is not specific to voice only. Any extensions to SIP MUST
consider the application of SIP to a variety of different session consider the application of SIP to a variety of different session
types. types.
SIP and Session Path Independence: We have already touched on this SIP and Session Path Independence: We have already touched on this
once, but it is worth noting again. The set of routers and/or once, but it is worth noting again. The set of routers and/or
networks and/or autonomous systems traversed by SIP messages are networks and/or autonomous systems traversed by SIP messages are
unrelated to the set of routers and/or networks and/or autonomous unrelated to the set of routers and/or networks and/or autonomous
systems traversed by session packets. They may be the same in systems traversed by session packets. They may be the same in
some cases, but it is fundamental to SIP's architecture that they some cases, but it is fundamental to SIP's architecture that they
need not be the same. Extensions which only work under some need not be the same. Standards track extensions MUST NOT be
assumption of overlap are not generally applicable to SIP's defined that work only when the signaling and session paths are
operation and should be scrutinized carefully. coupled. Non-standard P-header extensions [10] are required for
any extension which only works in such a case.
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 assumed networks administered by different providers. It is also assumed
that SIP messages traverse many hops (where each hop is a proxy). that SIP messages traverse many hops (where each hop is a proxy).
Extensions SHOULD NOT work only under the assumption of a single Extensions MUST NOT work only under the assumption of a single hop
hop or single provider. or specialized network topology. They SHOULD avoid the assumption
of a single SIP provider (but see the use of P-Headers, RFC 3427
[10]).
Transactional: SIP is a request/response protocol, possibly enhanced Transactional: SIP is a request/response protocol, possibly enhanced
with intermediate responses. Many of the rules of operation in with intermediate responses. Many of the rules of operation in
SIP are based on general processing of requests and responses. SIP are based on general processing of requests and responses.
This includes the reliability mechanisms, routing mechanisms, and This includes the reliability mechanisms, routing mechanisms, and
state maintenance rules. Extensions SHOULD NOT add messages that state maintenance rules. Extensions SHOULD NOT add messages that
are not within the request-response model. are not within the request-response model.
Proxies can ignore bodies: In order for proxies to scale well, they Proxies can ignore bodies: In order for proxies to scale well, they
must be able to operate with minimal message processing. SIP has must be able to operate with minimal message processing. SIP has
been engineered so that proxies can always ignore bodies. been engineered so that proxies can always ignore bodies.
Extensions SHOULD NOT require proxies to examine bodies. Extensions SHOULD NOT require proxies to examine bodies.
Proxies don't need to understand the method: Processing of requests Proxies don't need to understand the method: Processing of requests
in proxies does not depend on the method, except for the well in proxies does not depend on the method, except for the well
known methods INVITE, ACK, and CANCEL. This allows for known methods INVITE, ACK, and CANCEL. This allows for
extensibility. Extensions MUST NOT define new methods which must extensibility. Extensions MUST NOT define new methods which must
be understood by proxies. be understood by proxies.
INVITE messages carry full state: An initial INVITE message for a INVITE messages carry full state: An initial INVITE message for a
session is nearly identical (the exception is the tag) to a session is nearly identical (the exception is the tag) to a
re-INVITE message to modify some characteristic of the session. re-INVITE message to modify some characteristic of the session.
This full state property is fundamental to SIP, and is critical This full state property is fundamental to SIP, and is critical
for robustness of SIP systems. Extensions SHOULD NOT modify for robustness of SIP systems. Extensions SHOULD NOT modify
INVITE processing such that data spanning multiple INVITEs must be INVITE processing such that data spanning multiple INVITEs must be
collected in order to perform some feature. collected in order to perform some 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 broader capability is added to support one service, but a slightly broader
capability can support a larger variety of services (at the cost capability can support a larger variety of services (at the cost
of complexity or message sizes), the broader capability SHOULD be of complexity or message sizes), the broader capability SHOULD be
preferred. preferred.
The Request URI is the primary key for forwarding: Forwarding logic The Request URI is the primary key for forwarding: Forwarding logic
at SIP servers depends primarily on the request URI (this is at SIP servers depends primarily on the request URI (this is
different from request routing in SIP, which uses the Route header different from request routing in SIP, which uses the Route header
fields to pass a request through intermediate proxies). It is fields to pass a request through intermediate proxies). It is
fundamental to the operation of SIP that the request URI indicate fundamental to the operation of SIP that the request URI indicate
a resource that, under normal operations, resolves to the desired a resource that, under normal operations, resolves to the desired
recipient. Extensions SHOULD NOT modify the semantics of the recipient. Extensions SHOULD NOT modify the semantics of the
request URI. request URI.
Heterogeneity is the norm: SIP supports hetereogeneous devices. It Heterogeneity is the norm: SIP supports hetereogeneous devices. It
has built in mechanisms for determining the set of overlapping has built in mechanisms for determining the set of overlapping
protocol functionalities. Extensions SHOULD NOT be defined which protocol functionalities. Extensions SHOULD NOT be defined which
only function if all devices support the extension. only function if all devices support the 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.
skipping to change at page 10, line 22 skipping to change at page 8, line 22
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 and/ parameters, the extension MUST mandate the usage of the Require
or Proxy-Require header fields in the request. These extensions are and/or Proxy-Require header fields in the request. These extensions
not backwards compatible with SIP. The result of mandating usage of are not backwards compatible with SIP. The result of mandating usage
these header fields means that requests cannot be serviced unless the of these header fields means that requests cannot be serviced unless
entities being communicated with also understand the extension. If the entities being communicated with also understand the extension.
some entity does not understand the extension, the request will be If 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 the UAC retries the request without the extension. This will
preserve interoperability, at the cost of a "dual stack" preserve interoperability, at the cost of a "dual stack"
implementation in a UAC (processing rules for operation with and implementation in a UAC (processing rules for operation with and
without the extension). As the number of extensions increases, this without the extension). As the number of extensions increases, this
leads to an exponential explosion in the sets of processing rules a leads to an exponential explosion in the sets of processing rules a
UAC may need to implement. The result is excessive complexity. UAC may need to implement. The result is excessive complexity.
skipping to change at page 11, line 28 skipping to change at page 9, 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 [10] is supported if it is present in an Allow header. REFER method [12] 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 wasn't, 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 12, line 6 skipping to change at page 10, 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 [11]. such an extension is the SIP Session Timer [13].
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, bodies must be understood by user agents in order to process a
the interoperability issues are similar to new methods. However, the request. As such, the interoperability issues are similar to new
Content-Disposition header field has been defined to allow a client methods. However, the Content-Disposition header field has been
or server to indicate that the message body is optional [2]. Usage defined to allow a client or server to indicate that the message body
of optional bodies, as opposed to mandatory ones, is RECOMMENDED is optional [2]. Extensions that define or require new body types
wherever possible. SHOULD make them optional for the user agent to process.
When a body must be understood to properly process a request or When a body must be understood to properly process a request or
response, it is preferred that the sending entity know ahead of time response, it is preferred that the sending entity know ahead of time
whether the new body is understood by the recipient. For requests whether the new body is understood by the recipient. For requests
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.
skipping to change at page 12, line 40 skipping to change at page 10, line 43
requirements are required over those described in RFC 3261. requirements are required over those described in RFC 3261.
Frequently authorization requirements, and requirements for Frequently authorization requirements, and requirements for
end-to-end integrity 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 any new security capabilities beyond general purpose SIP. If they
do, it is likely that the security mechanism has more general purpose do, 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.
Overall system security requires that both the SIP signaling and the
media sessions it established be secured. The media sessions
normally use of their own security techniques that are quite distinct
by those used by SIP itself. Extensions should take care not to
conflate the two. However, specifications that define extensions
which impact the media sessions in any way SHOULD consider the
interactions between SIP and session security mechanisms.
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
caller, callee, user agent, header field, and so on. All SIP caller, callee, user agent, header field, and so on. All SIP
extensions MUST conform to this terminology. They MUST NOT define extensions MUST conform to this terminology. They MUST NOT define
new terms that describe concepts already defined by a term in another new terms that describe concepts already defined by a term in another
SIP specification. If new terminology is needed, it SHOULD appear in SIP specification. If new terminology is needed, it SHOULD appear in
a separate section towards the beginning of the document. a separate section towards the beginning of the document.
Careful attention must be paid to the actual usage of terminology. Careful attention must be paid to the actual usage of terminology.
Many documents misuse the terms header, header field, and header Many documents misuse the terms header, header field, and header
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
Method names are case sensitive, and therefore there is no names are case sensitive, and therefore, strictly speaking, they
requirement that they be capitalized. However, using capitalized don't have to be capitalized. However, using capitalized method
method names keeps with a long-standing convention in SIP and many names keeps with a long-standing convention in SIP and many similar
similar protocols, such as HTTP [13] and RTSP [14] protocols, such as HTTP [15] and RTSP [16]
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 MAY define a compact form if those header fields are
more than four characters. Compact header fields MUST be a single more than six characters. "Heavily used" means that the percentage
character. When all 26 characters are exhausted, new compact forms of all emitted messages which contain that header field is over
will no longer be defined. Header field names SHOULD be composed thirty percent. Usage of compact forms in these cases is only a MAY
primarily of ASCII characters and marks. They SHOULD be descriptive because there are better approaches for reducing message overhead
but reasonably brief. Although header field names are case [20]. Compact header fields MUST be a single character. When all 26
insensitive, a single common capitalization SHOULD be used throughout characters are exhausted, new compact forms will no longer be
the document. It is RECOMMENDED that each English word present in defined. Header field names are defined by the "token" production in
the header field name have its first letter capitalized. For RFC 3261 Section 25.1, and thus include the upper and lowercase
example, "ThisIsANewHeader". letters, the digits 0 through 9, the HYPHEN-MINUS (-), FULL STOP (.),
EXCLAMATION MARK (!), PERCENT SIGN (%), ASTERISK (*), LOW LINE (_),
PLUS SIGN (+), GRAVE ACCENT (`), APOSTROPHE ('), and TILDE (~). They
SHOULD be descriptive but reasonably brief. Although header field
names are case insensitive, a single common capitalization SHOULD be
used throughout 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 [17]. This has been
made simple through the usage of the BNF constructs of RFC 2234 [5], 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 case Extensions MUST be consistent with the SIP conventions for case
sensitivity. Methods MUST be case sensitive. Header field names sensitivity. Methods MUST be case sensitive. Header field names
MUST be case insensitive. Header field parameter names MUST be case MUST 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
skipping to change at page 14, line 26 skipping to change at page 12, line 45
of absolute dates in order to determine intervals (for example, the of absolute dates in order to determine intervals (for example, the
time at which some timer fires) is NOT RECOMMENDED. This is because time at which some timer fires) is NOT RECOMMENDED. This is because
it requires synchronized time between peers, and this is frequently it requires synchronized time between peers, and this is frequently
not the case. Therefore, relative times, expressed in numbers of not the case. Therefore, relative times, expressed in numbers of
seconds, SHOULD be used. 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 [4], 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 be
URI, not just SIP URIs. explicit about which URI schemes can be used in that header field.
Header fields SHOULD allow the broadest set of URI schemes possible
that are a match for the semantics of the header field.
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)
header-name = token header-name = token
header-value = value *(SEMI value-parameter) header-value = value *(SEMI value-parameter)
value-parameter = token [EQUAL gen-value] value-parameter = token [EQUAL gen-value]
gen-value = token / host / quoted-string gen-value = token / host / quoted-string
skipping to change at page 15, line 14 skipping to change at page 13, line 31
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 ">". encouraged to always wrap these URI in angle brackets "<" and ">".
We have found this to be a frequently misimplemented feature. We 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 of header field values. Compression of SIP messages SHOULD be
handled at lower layers, for example, using IP payload compression handled at lower layers, for example, using IP payload compression
[16] or signalling compression [18]. [18] or signalling compression [20].
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 [5]. 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
skipping to change at page 16, line 21 skipping to change at page 14, line 39
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 [19]. Note that complete messages SHOULD be used. Be specification [21]. 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 meaning 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
the extension. The most important processing rules for the elements the extension. The most important processing rules for the elements
in the call flow SHOULD be mentioned. Usage of the RFC 2119 [1] in the call flow SHOULD be mentioned. Usage of the RFC 2119 [1]
terminology in the overview section is NOT RECOMMENDED, and the terminology in the overview section is NOT RECOMMENDED, and the
specification should explicitly state that the overview is tutorial specification should explicitly state that the overview is tutorial
in nature only. in nature only. This section SHOULD expand all acronyms, even those
common in SIP systems, and SHOULD be understandable to readers that
are not SIP experts. [27] provides additional guidance on writing
good overview sections.
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
[20] for an example of the registration of a new event package. [22] for an example of the registration of a new event package. As
discussed in RFC 3427 [10], only standards track documents can
register new event-template packages. Both standards track and
informational specifications can register event packages.
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. that header field. RFC 3261 [2] provides a registration template.
See Section 8.2 of RFC 3262 [21] for an example of how to register See Section 8.2 of RFC 3262 [23] for an example of how to register
new SIP header fields. new SIP header fields. Both standards track and informational
P-header specifications can register new header fields [10].
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 Section 6.4 of RFC 3329 [17] for an example of how to register a See Section 6.4 of RFC 3329 [19] for an example of how to register a
new response code. new response code. As discussed in RFC 3427 [10], only standards
track documents can register new response codes.
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 [22] for an example of how to register a new Section 10 of RFC 3311 [24] for an example of how to register a new
SIP method. SIP method. As discussed in RFC 3427 [10], only standards track
documents can register new methods.
If your extension is defining a new SIP header field parameter, you
MUST register that header field parameter per the guidelines in RFC
3968 [7]. Section 4.1 of that specification provides a template.
Only IETF approved specifications can register new header field
parameters. However, there is no requirement that these be standards
track.
If your extension is defining a new SIP URI parameter, you MUST
register that URI parameter per the guidelines in RFC 3969 [8].
Section 4.1 of that specification provides a template. Only
standards track documents can register new URI parameters.
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 Proxy-Require and Supported header fields. Section 4.1 discusses
some of the issues involved in the usage of these header fields. If some of the issues involved in the usage of these header fields. If
your extension does require them, you MUST register an option tag for your extension does require them, you MUST register an option tag for
your extension. RFC 3261 [2] provides a registration template. See your extension. RFC 3261 [2] provides a registration template. See
Section 8.1 of RFC 3262 [21] for an example of how to register an Section 8.1 of RFC 3262 [23] for an example of how to register an
option tag. option tag. Only standards track RFCs can register new option tags.
Some SIP extensions will require establishment of their own IANA Some SIP extensions will require establishment of their own IANA
registries. RFC 2434 [23] provides guidance on how and when IANA registries. RFC 2434 [25] 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
extension. For example, if an extension defines a new header field, extension. For example, if an extension defines a new header field,
called Make-Coffee, for making coffee, the title would read, "Making called Make-Coffee, for making coffee, the title would read, "Making
Coffee with the Session Initiation Protocol (SIP)". It is RECOMMENED Coffee with the Session Initiation Protocol (SIP)". It is
that these additional words be descriptive rather than naming the RECOMMENDED that these additional words be descriptive rather than
header field. For example, the extension for making coffee should naming the header field. For example, the extension for making
not be named "The Make-Coffee Header for the Session Initiation coffee should not be named "The Make-Coffee Header for the Session
Protocol". Initiation Protocol".
For extensions that define new methods, an acceptable template for For extensions that define new methods, an acceptable template for
titles is "The Session Initiation Protocol (SIP) X Method" where X is titles is "The Session Initiation Protocol (SIP) X Method" where X is
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 [24]. per [26].
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 presence o Can it contain bodies? If so, what is the meaning of the 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 progress? transaction, in the same and/or reverse direction, is in progress?
o The extension MUST define which header fields can be present in o The extension MUST define which header fields can be present in
requests of that method. It is RECOMMENDED that this information requests of that method. It is RECOMMENDED that this information
be represented as a new column of Table 2/3 of RFC 3261 [2]. The be represented as a new column of Table 2/3 of RFC 3261 [2]. The
table MUST contain rows for all header fields defined in standards table MUST contain rows for all header fields defined in standards
track RFCs at the time of writing of the extension. track RFCs at the time of writing of the extension.
o Can the request be sent within a dialog, or does it establish a o Can the request be sent within a dialog, or does it establish 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 its offers and answers can appear in requests of that method or its
responses. However, those extensions MUST adhere to the protocol responses. However, those extensions MUST adhere to the protocol
rules specified in [25], and MUST adhere to the additional rules specified in [28], and MUST adhere to the additional
constraints for offers and answers as specified in SIP [2]. constraints for offers and answers as specified in SIP [2].
o Because of the nature of reliability treatment of requests with o Because of the nature of reliability treatment of requests with
new methods, those requests need to be answered immediately by the new methods, those requests need to be answered immediately by the
UAS. Protocol extensions that require longer durations for the UAS. Protocol extensions that require longer durations for the
generation of a response (such as a new method that requires human generation of a response (such as a new method that requires human
interaction) SHOULD instead use two transactions - one to send the interaction) SHOULD instead use two transactions - one to send the
request, and another in the reverse direction to convey the result request, and another in the reverse direction to convey the result
of the request. An example of that is SUBSCRIBE and NOTIFY [6]. of the request. An example of that is SUBSCRIBE and NOTIFY [6].
o The SIP specification [2] allows new methods to specify whether o The SIP specification [2] allows new methods to specify whether
transactions using that new method can be canceled using a CANCEL transactions using that new method can be canceled using a CANCEL
request. Further study of the non-INVITE transaction [12] has request. Further study of the non-INVITE transaction [14] has
determined that non-INVITE transactions must complete as soon as determined that non-INVITE transactions must complete as soon as
possible. New methods must not plan for the transaction to pend possible. New methods must not plan for the transaction to pend
long enough for CANCEL to be meaningful. Thus, new methods MUST long enough for CANCEL to be meaningful. Thus, new methods MUST
declare that transactions initiated by requests with that method declare that transactions initiated by requests with that method
cannot be canceled. Future work may relax this restriction, at cannot be canceled. Future work may relax this restriction, at
which point these guidelines will be revised. which point these guidelines will be revised.
o New methods that establish a new dialog must discuss the impacts o New methods that establish a new dialog must discuss the impacts
of forking. The design of such new methods should follow the of forking. The design of such new methods should follow the
pattern of requiring an immediate request in the reverse direction pattern of requiring an immediate request in the reverse direction
from the request establishing a dialog, similar to the immediate from the request establishing a dialog, similar to the immediate
NOTIFY sent when a subscription is created per RFC 3265 [6]. NOTIFY sent when a subscription is created per RFC 3265 [6].
The reliability mechanisms for all new methods must be the same as The reliability mechanisms for all new methods must be the same as
for BYE. The delayed response feature of INVITE is only available in for BYE. The delayed response feature of INVITE is only available in
INVITE, never for new methods. The design of new methods must INVITE, never for new methods. The design of new methods must
encourage an immediate response. If the application being enabled encourage an immediate response. If the application being enabled
skipping to change at page 19, line 36 skipping to change at page 18, line 37
For extensions that define new header fields, the extension MUST For extensions that define new header fields, the extension MUST
define the request methods the header field can appear in, and what define the request methods the header field can appear in, and what
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 (where large is several times the ethernet MTU) are
controlled transport can be guaranteed. If at all possible, the frowned upon unless end-to-end congestion controlled transport can be
content SHOULD be included indirectly [7] even if congestion guaranteed. If at all possible, the content SHOULD be included
controlled transports are available. indirectly [9] even if congestion 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
skipping to change at page 20, line 12 skipping to change at page 19, line 7
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 interactions Forking: Forking by far presents the most troublesome interactions
with extensions. This is generally because it can cause (1) a with extensions. This is generally because it can cause (1) a
single transmitted request to be received by an unknown number of single transmitted request to be received by an unknown number of
UASs, and (2) a single INVITE request to have multiple responses. UASs, and (2) a single INVITE request to have multiple responses.
CANCEL and ACK: CANCEL and ACK are "special" SIP requests, in that CANCEL and ACK: CANCEL and ACK are "special" SIP requests, in that
they are exceptions to many of the general request processing they are exceptions to many of the general request processing
rules. The main reason for this special status is that CANCEL and rules. The main reason for this special status is that CANCEL and
ACK are always associated with another request. New methods ACK are always associated with another request. New methods
SHOULD consider the meaning of cancellation, as described above. SHOULD consider the meaning of cancellation, as described above.
Extensions which defined new header fields in INVITE requests Extensions which defined new header fields in INVITE requests
SHOULD consider whether they also need to be included in ACK and SHOULD consider whether they also need to be included in ACK and
CANCEL. Frequently they do, in order to allow a stateless proxy CANCEL. Frequently they do, in order to allow a stateless proxy
to route the CANCEL or ACK identically to the INVITE. to route the CANCEL or ACK identically to the INVITE.
Routing: The presence of Route header fields in a request can cause Routing: The presence of Route header fields in a request can cause
it to be sent through intermediate proxies. Requests that it to be sent through intermediate proxies. Requests that
establish dialogs can be record-routed, so that the initial establish dialogs can be record-routed, so that the initial
request goes through one set of proxies, and subsequent requests request goes through one set of proxies, and subsequent requests
through a different set. These SIP features can interact in through a different set. These SIP 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 execute proxies are unable to retransmit messages and cannot execute
certain services. Extensions which depend on some kind of proxy certain services. Extensions which depend on some kind of proxy
processing SHOULD consider how stateless proxies affect that processing SHOULD consider how stateless 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. However, many of the principles
described in the document affect whether a potential SIP extension
design is likely to support the SIP security architecture.
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. Robert The authors would like to thank Rohan Mahy and Spencer Dawkins for
Sparks contributed important text on CANCEL issues. their comments. Robert Sparks contributed important text on CANCEL
issues. Thanks to Allison Mankin for her support.
9. References 9. References
9.1 Normative References 9.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
skipping to change at page 24, line 28 skipping to change at page 20, line 29
[4] Hinden, R., Carpenter, B. and L. Masinter, "Format for Literal [4] Hinden, R., Carpenter, B. and L. Masinter, "Format for Literal
IPv6 Addresses in URL's", RFC 2732, December 1999. IPv6 Addresses in URL's", RFC 2732, December 1999.
[5] Crocker, D. and P. Overell, "Augmented BNF for Syntax [5] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 1997.
[6] Roach, A., "Session Initiation Protocol (SIP)-Specific Event [6] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002. Notification", RFC 3265, June 2002.
[7] Olson, S., "A Mechanism for Content Indirection in Session [7] Camarillo, G., "The Internet Assigned Number Authority (IANA)
Header Field Parameter Registry for the Session Initiation
Protocol (SIP)", BCP 98, RFC 3968, December 2004.
[8] Camarillo, G., "The Internet Assigned Number Authority (IANA)
Uniform Resource Identifier (URI) Parameter Registry for the
Session Initiation Protocol (SIP)", BCP 99, RFC 3969, December
2004.
[9] Burger, E., "A Mechanism for Content Indirection in Session
Initiation Protocol (SIP) Messages", Initiation Protocol (SIP) Messages",
draft-ietf-sip-content-indirect-mech-03 (work in progress), June draft-ietf-sip-content-indirect-mech-05 (work in progress),
2003. October 2004.
9.2 Informative References 9.2 Informative References
[8] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J. and B. [10] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J. and B.
Rosen, "Change Process for the Session Initiation Protocol Rosen, "Change Process for the Session Initiation Protocol
(SIP)", BCP 67, RFC 3427, December 2002. (SIP)", BCP 67, RFC 3427, December 2002.
[9] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, [11] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997. March 1997.
[10] Sparks, R., "The Session Initiation Protocol (SIP) Refer [12] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003. Method", RFC 3515, April 2003.
[11] Donovan, S. and J. Rosenberg, "Session Timers in the Session [13] Donovan, S. and J. Rosenberg, "Session Timers in the Session
Initiation Protocol (SIP)", draft-ietf-sip-session-timer-14 Initiation Protocol (SIP)", draft-ietf-sip-session-timer-15
(work in progress), May 2004. (work in progress), August 2004.
[12] Sparks, R., "Problems identified associated with the Session [14] Sparks, R., "Problems identified associated with the Session
Initiation Protocol's non-INVITE Transaction", Initiation Protocol's non-INVITE Transaction",
draft-sparks-sip-nit-problems-00 (work in progress), February draft-sparks-sip-nit-problems-02 (work in progress), January
2004. 2005.
[13] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., [15] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999. HTTP/1.1", RFC 2616, June 1999.
[14] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming [16] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998. Protocol (RTSP)", RFC 2326, April 1998.
[15] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, [17] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,
"SIP: Session Initiation Protocol", RFC 2543, March 1999. "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[16] Shacham, A., Monsour, R., Pereira, R. and M. Thomas, "IP [18] Shacham, A., Monsour, B., Pereira, R. and M. Thomas, "IP
Payload Compression Protocol (IPComp)", RFC 2393, December Payload Compression Protocol (IPComp)", RFC 3173, September
1998. 2001.
[17] Arkko, J., Torvinen, V., Camarillo, G., Niemi, A. and T. [19] Arkko, J., Torvinen, V., Camarillo, G., Niemi, A. and T.
Haukka, "Security Mechanism Agreement for the Session Haukka, "Security Mechanism Agreement for the Session
Initiation Protocol (SIP)", RFC 3329, January 2003. Initiation Protocol (SIP)", RFC 3329, January 2003.
[18] Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu, Z. [20] Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu, Z.
and J. Rosenberg, "Signaling Compression (SigComp)", RFC 3320, and J. Rosenberg, "Signaling Compression (SigComp)", RFC 3320,
January 2003. January 2003.
[19] Johnston, A., Donovan, S., Sparks, R., Cunningham, C. and K. [21] Johnston, A., Donovan, S., Sparks, R., Cunningham, C. and K.
Summers, "Session Initiation Protocol (SIP) Basic Call Flow Summers, "Session Initiation Protocol (SIP) Basic Call Flow
Examples", BCP 75, RFC 3665, December 2003. Examples", BCP 75, RFC 3665, December 2003.
[20] Rosenberg, J., "A Session Initiation Protocol (SIP) Event [22] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Package for Registrations", RFC 3680, March 2004. Package for Registrations", RFC 3680, March 2004.
[21] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional [23] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
Responses in Session Initiation Protocol (SIP)", RFC 3262, June Responses in Session Initiation Protocol (SIP)", RFC 3262, June
2002. 2002.
[22] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE [24] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
Method", RFC 3311, October 2002. Method", RFC 3311, October 2002.
[23] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [25] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October Considerations Section in RFCs", BCP 26, RFC 2434, October
1998. 1998.
[24] Reynolds, J. and R. Braden, "Instructions to Request for [26] Reynolds, J. and R. Braden, "Instructions to Request for
Comments (RFC) Authors", draft-rfc-editor-rfc2223bis-07 (work Comments (RFC) Authors", draft-rfc-editor-rfc2223bis-08 (work
in progress), August 2003. in progress), July 2004.
[25] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with [27] Rescorla, E., "Writing Protocol Models", draft-iab-model-02
(work in progress), September 2004.
[28] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002. Session Description Protocol (SDP)", RFC 3264, June 2002.
Authors' Addresses Authors' Addresses
Jonathan Rosenberg Jonathan Rosenberg
dynamicsoft Cisco Systems
600 Lanidex Plaza 600 Lanidex Plaza
Parsippany, NJ 07054 Parsippany, NJ 07054
US US
Phone: +1 973 952-5000 Phone: +1 973 952-5000
EMail: jdrosen@dynamicsoft.com EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net URI: http://www.jdrosen.net
Henning Schulzrinne Henning Schulzrinne
Columbia University Columbia University
M/S 0401 M/S 0401
1214 Amsterdam Ave. 1214 Amsterdam Ave.
New York, NY 10027 New York, NY 10027
US US
EMail: schulzrinne@cs.columbia.edu EMail: schulzrinne@cs.columbia.edu
skipping to change at page 27, line 41 skipping to change at page 23, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

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