draft-ietf-sip-guidelines-05.txt   draft-ietf-sip-guidelines-06.txt 
Internet Engineering Task Force SIP WG Internet Engineering Task Force SIP WG
Internet Draft J. Rosenberg Internet Draft J. Rosenberg
dynamicsoft dynamicsoft
H. Schulzrinne H. Schulzrinne
Columbia U. Columbia U.
draft-ietf-sip-guidelines-05.txt draft-ietf-sip-guidelines-06.txt
June 6, 2002 November 4, 2002
Expires: December 2002 Expires: May 2003
Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP Guidelines for Authors of Extensions to
the Session Initiation Protocol (SIP)
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 groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 15 skipping to change at page 2, line 15
Table of Contents Table of Contents
1 Terminology ......................................... 3 1 Terminology ......................................... 3
2 Introduction ........................................ 3 2 Introduction ........................................ 3
3 Should I define a SIP Extension? ................... 3 3 Should I define a SIP Extension? ................... 3
3.1 SIP's Solution Space ................................ 4 3.1 SIP's Solution Space ................................ 4
3.2 SIP Architectural Model ............................. 6 3.2 SIP Architectural Model ............................. 6
4 Issues to be Addressed .............................. 8 4 Issues to be Addressed .............................. 8
4.1 Backwards Compatibility ............................. 8 4.1 Backwards Compatibility ............................. 8
4.2 Security ............................................ 10 4.2 Security ............................................ 10
4.3 Usage Guidelines .................................... 10 4.3 Terminology ......................................... 10
4.4 Syntactic Issues .................................... 10 4.4 Syntactic Issues .................................... 11
4.5 Semantics, Semantics, Semantics ..................... 12 4.5 Semantics, Semantics, Semantics ..................... 13
4.6 Examples Section .................................... 13 4.6 Examples Section .................................... 14
4.7 Overview Section .................................... 13 4.7 Overview Section .................................... 14
4.8 Document Naming Conventions ......................... 13 4.8 IANA Considerations Section ......................... 15
4.9 Additional Considerations for New Methods ........... 14 4.9 Document Naming Conventions ......................... 15
4.10 Additional Considerations for New Headers or 4.10 Additional Considerations for New Methods ........... 16
Header Parameters .............................................. 15 4.11 Additional Considerations for New Header Fields or
4.11 Additional Considerations for New Body Types ........ 15 Header Field Parameters ........................................ 17
5 Interactions with SIP Features ...................... 16 4.12 Additional Considerations for New Body Types ........ 17
6 Security Considerations ............................. 16 5 Interactions with SIP Features ...................... 18
7 IANA Considerations ................................. 16 6 Security Considerations ............................. 18
8 Authors Addresses ................................... 17 7 IANA Considerations ................................. 19
9 Normative References ................................ 17 8 Acknowledgements .................................... 19
10 Informative References .............................. 17 9 Authors Addresses ................................... 19
10 Normative References ................................ 19
11 Informative References .............................. 20
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 guidelines indicate requirement levels for compliant SIP implementations.
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 headers, new body types, and new parameters), (with new methods, new header fields, new body types, and new
and there have been countless proposals that have been made to do parameters), and there have been countless proposals that have been
just that. An IETF process has been put into place which defines how made to do just that. An IETF process has been put into place which
extensions are to be made to the SIP protocol [7]. That process is defines how extensions are to be made to the SIP protocol [9]. That
designed to ensure that extensions are made which are appropriate for process is designed to ensure that extensions are made which are
SIP (as opposed to being done in some other protocol), that these appropriate for SIP (as opposed to being done in some other
extensions fit within the model and framework provided by SIP and are protocol), that these extensions fit within the model and framework
consistent with its operation, and that these extensions solve provided by SIP and are consistent with its operation, and that these
problems generically rather than for a specific use case. However, extensions solve problems generically rather than for a specific use
[7] does not provide the technical guidelines needed to assist that case. However, [9] does not provide the technical guidelines needed
process. This draft helps to meet that need. to assist that process. This specification helps to meet that need.
This draft first provides a set of guidelines to help decide whether This specification first provides a set of guidelines to help decide
a certain piece of functionality is appropriately done in SIP. whether a certain piece of functionality is appropriately done in
Assuming the functionality is appropriate, it then points out issues SIP. Assuming the functionality is appropriate, it then points out
which extensions should deal with from within their specification. issues which extensions should deal with from within their
Finally, it discusses common interactions with existing SIP features specification. Finally, it discusses common interactions with
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.
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 SIPs 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 [8]. obtain their IP address. This is generally done through DHCP [10].
SIPs 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
object oriented software engineering. object oriented 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.
3.1 SIP's Solution Space 3.1 SIP's Solution Space
In order to evaluate the first criteria, it is necessary to define In order to evaluate the first criteria, it is necessary to define
exactly what SIPs solution space is, and what it is not. exactly what SIP's solution space is, and what it is not.
SIP is a protocol for initiating, modifying, and terminating SIP is a protocol for initiating, modifying, and terminating
interactive sessions. This process involves the discovery of users, interactive sessions. This process involves the discovery of users,
(or more generally, entities that can be communicated with, including (or more generally, entities that can be communicated with, including
services, such as voicemail or translation devices) wherever they may services, such as voicemail or translation devices) wherever they may
be located, so that a description of the session can be delivered to be located, so that a description of the session can be delivered to
the user. It is assumed that these users or communications entities the user. It is assumed that these users or communications entities
are mobile, and their point of attachment to the network changes over are mobile, and their point of attachment to the network changes over
time. The primary purpose of SIP is a rendezvous function, to allow a time. The primary purpose of SIP is a rendezvous function, to allow a
request initiator to deliver a message to a recipient wherever they request initiator to deliver a message to a recipient wherever they
be. Such rendezvous is needed to establish a session, but can be used may be. Such rendezvous is needed to establish a session, but can be
for other purposes related to communications, such as querying for used for other purposes related to communications, such as querying
capabilities or delivery of an instant message. for capabilities or delivery of an instant message.
Much of SIP focuses on this discovery and rendezvous component. Its Much of SIP focuses on this discovery and rendezvous component. Its
ability to fork, its registration capabilities, and its routing ability to fork, its registration capabilities, and its routing
capabilities are all present for the singular purpose of finding the capabilities are all present for the singular purpose of finding the
desired user wherever they may be. As such, features and capabilities desired user wherever they may be. As such, features and capabilities
such as personal mobility, automatic call distribution, and follow-me such as personal mobility, automatic call distribution, and follow-me
are well within the SIP solution space. are well within the SIP solution space.
Session initiation also depends on the ability of the called party to Session initiation also depends on the ability of the called party to
have enough information about the session itself in order to make a have enough information about the session itself in order to make a
skipping to change at page 5, line 34 skipping to change at page 5, line 34
SIP is not a resource reservation protocol for sessions. This is SIP is not a resource reservation protocol for sessions. This is
fundamentally because (1) SIP is independent of the underlying fundamentally because (1) SIP is independent of the underlying
session it establishes, and (2) the path of SIP messages is session it establishes, and (2) the path of SIP messages is
completely independent from the path that session packets may take. completely independent from the path that session packets may take.
The path independence refers to paths within a providers network, and The path independence refers to paths within a providers network, and
the set of providers itself. For example, it is perfectly reasonable the set of providers itself. For example, it is perfectly reasonable
for a SIP message to traverse a completely different set of for a SIP message to traverse a completely different set of
autonomous systems than the audio in a session SIP establishes. autonomous systems than the audio in a session SIP establishes.
SIP is not a general purpose transfer protocol. It is not meant to SIP is not a general purpose transfer protocol. It is not meant to
send large amounts of data unrelated to SIPs operation. It is not send large amounts of data unrelated to SIP's operation. It is not
meant as a replacement for HTTP. This is not to say that carrying meant as a replacement for HTTP. This is not to say that carrying
payloads in SIP messages is never a good thing; in many cases, the payloads in SIP messages is never a good thing; in many cases, the
data is very much related to SIPs operation. In those cases, data is very much related to SIP's operation. In those cases,
congestion controlled transports end-to-end are critical. congestion controlled transports end-to-end are critical.
SIP is not meant to be a general RPC mechanism. None of its user SIP is not meant to be a general Remote Procedure Call (RPC)
discovery and registration capabilities are needed for RPC, neither mechanism. None of its user discovery and registration capabilities
are most of its proxy functions. are needed for RPC, neither are most of its proxy functions.
SIP is not meant to be used as a strict PSTN signaling replacement. SIP is not meant to be used as a strict PSTN signaling replacement.
It is not a superset of ISUP. While it can support gatewaying of PSTN It is not a superset of ISUP. While it can support gatewaying of PSTN
signaling, and can provide many features present in the PSTN, the signaling, and can provide many features present in the PSTN, the
mere existence of a feature or capability in the PSTN is not a mere existence of a feature or capability in the PSTN is not a
justification for its inclusion in SIP. Extensions needed to support justification for its inclusion in SIP. Extensions needed to support
telephony MUST meet the other criteria described here. telephony MUST meet the other criteria described here.
SIP is a poor control protocol. It is not meant to be used for one SIP is a poor control protocol. It is not meant to be used for one
entity to tell another to pick up or answer a phone, send audio using entity to tell another to pick up or answer a phone, send audio using
a particular codec, or change a configuration parameter. Control a particular codec, or to provide a new value for a configuration
protocols have different trust relationships than is assumed in SIP, parameter. Control protocols have different trust relationships than
and are more centralized in architecture than SIP, which is a very is assumed in SIP, and are more centralized in architecture than SIP,
distributed protocol. which is a very distributed protocol.
There are many network layer services needed to make SIP function. There are many network layer services needed to make SIP function.
These include quality of service, mobility, and security, among These include quality of service, mobility, and security, among
others. Rather than building these capabilities into SIP itself, they others. Rather than building these capabilities into SIP itself, they
SHOULD be developed outside of SIP, and then used by it. SHOULD be developed outside of SIP, and then used by it.
Specifically, any protocol mechanisms that are needed by SIP, but are Specifically, any protocol mechanisms that are needed by SIP, but are
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
skipping to change at page 6, line 38 skipping to change at page 6, line 38
the session. SIP is not specific to VoIP only. Any the session. SIP is not specific to VoIP only. Any
extensions to SIP MUST consider the application of SIP to a extensions to SIP MUST consider 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 once, but it is worth noting again. The set of routers this once, but it is worth noting again. The set of routers
and/or networks and/or autonomous systems traversed by SIP and/or networks and/or autonomous systems traversed by SIP
messages are unrelated to the set of routers and/or messages are unrelated to the set of routers and/or
networks and/or autonomous systems traversed by session networks and/or autonomous systems traversed by session
packets. They may be the same in some cases, but it is packets. They may be the same in some cases, but it is
fundamental to SIPs architecture that they need not be the fundamental to SIP's architecture that they need not be the
same. Extensions which only work under some assumption of same. Extensions which only work under some assumption of
overlap are not generally applicable to SIPs 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 that SIP messages traverse many hops (where each assumed that SIP messages traverse many hops (where each
hop is a proxy). Extensions SHOULD NOT work only under the hop is a proxy). Extensions SHOULD NOT work only under the
assumption of a single hop or single provider. assumption of a single hop or single provider.
Transactional: SIP is a request/response protocol, possibly Transactional: SIP is a request/response protocol, possibly
skipping to change at page 7, line 41 skipping to change at page 7, line 41
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 capability can support a larger variety of services broader capability can support a larger variety of services
(at the cost of complexity or message sizes), the broader (at the cost of complexity or message sizes), the broader
capability SHOULD be preferred. capability SHOULD be preferred.
The Request URI is the primary key for forwarding: Forwarding The Request URI is the primary key for forwarding: Forwarding
logic at SIP servers depends primarily on the request URI logic at SIP servers depends primarily on the request URI
(this is different from request routing in SIP, which uses (this is different from request routing in SIP, which uses
the Route headers to pass a request through intermediate the Route header fields to pass a request through
proxies). It is fundamental to the operation of SIP that intermediate proxies). It is fundamental to the operation
the request URI indicate a resource that, under normal of SIP that the request URI indicate a resource that, under
operations, resolves to the desired recipient. Extensions normal operations, resolves to the desired recipient.
SHOULD NOT use other components of the SIP message as the Extensions SHOULD NOT use other components of the SIP
primary forwarding key, and SHOULD NOT modify the semantics message as the primary forwarding key, and SHOULD NOT
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 has built in mechanisms for determining the set of It has built in mechanisms for determining the set of
overlapping protocol functionalities. Extensions SHOULD NOT overlapping protocol functionalities. Extensions SHOULD NOT
be defined which only function if all devices support the be defined which 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 headers coupled with how the Require, Proxy-Require, and Supported header
are used. fields are used.
If an extension consists of new headers inserted by a user agent in a If an extension consists of new header fields or header field
request with an existing method, and the request cannot be processed parameters inserted by a user agent in a request with an existing
reasonably by a proxy and/or user agent without understanding the method, and the request cannot be processed reasonably by a proxy
headers, the extension MUST mandate the usage of the Require and/or and/or user agent without understanding the header fields or
Proxy-Require headers in the request. These extensions are not parameters, the extension MUST mandate the usage of the Require
backwards compatible with SIP. The result of mandating usage of these and/or Proxy-Require header fields in the request. These extensions
headers means that requests cannot be serviced unless the entities are not backwards compatible with SIP. The result of mandating usage
being communicated with also understand the extension. If some entity of these header fields means that requests cannot be serviced unless
does not understand the extension, the request will be rejected. The the entities being communicated with also understand the extension.
UAC can then handle this in one of two ways. In the first, the If some entity does not understand the extension, the request will be
request simply fails, and the service cannot be provided. This is rejected. The UAC can then handle this in one of two ways. In the
basically an interoperability failure. In the second case, the UAC first, the request simply fails, and the service cannot be provided.
retries the request without the extension. This will preserve This is basically an interoperability failure. In the second case,
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 headers in requests for basic SIP services o The usage of these header fields in requests for basic SIP
(in particular, session initiation and termination) is NOT services (in particular, session initiation and termination)
RECOMMENDED. The less frequently a particular extension is is NOT RECOMMENDED. The less frequently a particular extension
needed in a request, the more reasonable it is to use these is needed in a request, the more reasonable it is to use these
headers. header fields.
o The Proxy-Require header SHOULD be avoided at all costs. The
failure likelihood in an individual proxy stays constant, but
the path failure grows exponentially with the number of hops.
On the other hand, the Require header only mandates that a o The Proxy-Require header field SHOULD be avoided at all costs.
single entity, the UAS, support the extension. Usage of The failure likelihood in an individual proxy stays constant,
Proxy-Require is thus considered exponentially worse than but the path failure grows exponentially with the number of
usage of the Require header. hops. On the other hand, the Require header field only
mandates that a single entity, the UAS, support the extension.
Usage of Proxy-Require is thus considered exponentially worse
than usage of the Require 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 extension SHOULD discuss how to fall back to baseline SIP the 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. SIP defines mechanisms which allow a UAC to know whether a header field. SIP defines mechanisms which allow a UAC to know
new method is understood by a UAS. This includes both the OPTIONS whether a new method is understood by a UAS. This includes both the
request, and the 405 (Method Not Allowed) response with the Allow OPTIONS request, and the 405 (Method Not Allowed) response with the
header. It is fundamental to SIP that proxies do not need to Allow header field. It is fundamental to SIP that proxies do not need
understand the semantics of a new method in order to process it. If to understand the semantics of a new method in order to process it.
an extension defines a new method which must be understood by proxies If an extension defines a new method which must be understood by
in order to be processed, a Proxy-Require header is needed. As proxies in order to be processed, a Proxy-Require header field is
discussed above, these kinds of extensions are frowned upon. needed. As discussed above, these kinds of extensions are frowned
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 is used. There are two types of define new methods, the Allow header field is used. There are two
new methods - those that are used for established dialogs (initiated types of new methods - those that are used for established dialogs
by INVITE, for example), and those that are sent as the initial (initiated by INVITE, for example), and those that are sent as the
request to a UA. Since INVITE and its response both SHOULD contain an initial request to a UA. Since INVITE and its response both SHOULD
Allow header, a UA can readily determine whether the new method can contain an Allow header field, a UA can readily determine whether the
be supported within the dialog. For example, if a new method for a new method can be supported within the dialog. For example, once an
mid-dialog feature, such as hold, were to be defined, the hold button INVITE dialog is established, a user agent could determine if the
on the UI could be "greyed out" once the call is established, if the REFER method [11] is supported if it is present in an Allow header.
new method were not listed in the Allow header. If it was, the "transfer" button on the UI could be "greyed out" 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
headers into a request as it traverses the network, or for the UAS to header fields or header field parameters into a request as it
insert headers into a response. For some extensions, if the UAC or traverses the network, or for the UAS to insert header fields or
UAS does not understand these headers, the message can still be header field parameters into a response. For some extensions, if the
processed correctly. These extensions are completely backwards UAC or UAS does not understand these header fields, the message can
compatible. still be processed correctly. These extensions are completely
backwards compatible.
Most other extensions of this type require that the server only Most other extensions of this type require that the server only
insert the header if it is sure the client understands it. In this insert the header field or parameter if it is sure the client
case, these extensions will need to make use of the Supported request understands it. In this case, these extensions will need to make use
header mechanism. This mechanism allows a server to determine if the of the Supported request header field mechanism. This mechanism
client can understand some extension, so that it can apply the allows a server to determine if the client can understand some
extension to the response. By their nature, these extensions may not extension, so that it can apply the extension to the response. By
always be able to be applied to every response. their nature, these extensions may not always be able to be applied
to every response.
If an extension requires a proxy to insert a header into a request, If an extension requires a proxy to insert a header field or
and this header needs to be understood by both UAC and UAS to be parameter into a request, and this header field or parameter needs to
executed correctly, a combination of the Require and the Supported be understood by both UAC and UAS to be executed correctly, a
mechanism will need to be used. The proxy can insert a Require header combination of the Require and the Supported mechanism will need to
into the request, given the Supported header is present. An example be used. The proxy can insert a Require header field into the
of such an extension is the SIP Session Timer [9]. request, given the Supported header field is present. An example of
such an extension is the SIP Session Timer [12].
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 has been defined to allow a client or Content-Disposition header field has been defined to allow a client
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.
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.
4.2 Security 4.2 Security
Security is an important component of any protocol. SIP extensions Security is an important component of any protocol. Designers of SIP
SHOULD consider how (or if) they affect usage of the general SIP extensions need to carefully consider if additional security
security mechanisms. Most extensions should not require any new requirements are required over those described in RFC3261. Frequently
security capabilities beyond general purpose SIP. If they do, it is authorization requirements, and requirements for end-to-end integrity
likely that the security mechanism has more general purpose are the most overlooked.
SIP extensions MUST consider how (or if) they affect usage of the
general SIP security mechanisms. Most extensions should not require
any new security capabilities beyond general purpose SIP. If they 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.
4.3 Usage Guidelines 4.3 Terminology
All SIP extensions must contain guidelines defining when the RFC 3261 has an extensive terminology section that defines terms like
extension is to be used. caller, callee, user agent, header field, and so on. All SIP
extensions MUST conform to this terminology. They MUST NOT define new
terms that describe concepts already defined by a term in another SIP
specification. If new terminology is needed, it SHOULD appear in a
separate section towards the beginning of the document.
For extensions that define new headers, the extension MUST define the Careful attention must be paid to the actual usage of terminology.
request methods the header can appear in, and what responses it can Many documents misuse the terms header, header field, and header
be used in. It is recommended that this information be represented as field values, for example. Document authors SHOULD do a careful
a new row of Table 4 of RFC BBBB [2]. The extension SHOULD specify review of their documents for proper usage of these terms.
which entities (UAC, UAS, proxy, redirect, registrar) are allowed to
insert the header.
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.
Extensions that define new headers that are anticipated to be heavily Method names are case sensitive, and therefore there is no
used SHOULD define a compact form if those headers are more than four requirement that they be capitalized. However, using
characters. Compact headers MUST be a single character. When all 26 capitalized method names keeps with a long-standing
characters are exhausted, new compact forms will no longer be convention in SIP and many similar protocols, such as HTTP
defined. Header names SHOULD use ASCII characters. [13] and RTSP [14].
Extensions that define new header fields that are anticipated to be
heavily used SHOULD define a compact form if those header fields are
more than four characters. Compact header fields MUST be a single
character. When all 26 characters are exhausted, new compact forms
will no longer be defined. Header field names SHOULD be composed
primarily of ASCII characters and marks. 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 this be camel case.
As an example, the following are poor choices for header field names:
ThisIsMyNewHeaderThatDoesntDoVeryMuchButItHasANiceName
--.!A
Function
Case sensitivity of parameters and values is a constant source of Case sensitivity of parameters and values is a constant source of
confusion. SIP extensions MUST clearly indicate the case sensitivity confusion, a difficulty that plagued RFC 2543 [15]. This has been
or insensitivity of every parameter, value or field they define. made simple through the usage of the BNF constructs of RFC 2234 [3],
However, it is RECOMMENDED that these extensions be consistent with which have clear rules of case sensivitity and insensitivity.
baseline SIP, which uses case insensitive parameters, consistent with Therefore, the BNF for an extension completely defines the matching
the grammar constructs of RFC 2234 [3]. rules.
Extensions MUST be consistent with the SIP conventions for
sensitivity. Methods MUST be case sensitive. Header field names MUST
be case insensitive. Header field parameter names MUST be case
insensitive. Header field values and parameter values are sometimes
case sensitive, and sometimes case insensitive. However, generally
they SHOULD be case insensitive. Definiting a case sensitive
component requires explicitly listing each character through its
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 [4]. 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,
extremely complicated and are to 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 BBBB [2]. No other date formats are allowed. However, the in RFC 3261 [2]. No other date formats are allowed. However, the
usage of absolute dates in order to determine intervals (for example, usage of absolute dates in order to determine intervals (for example,
the time at which some timer fires) is NOT RECOMMENDED. This is the time at which some timer fires) is NOT RECOMMENDED. This is
because it requires synchronized time between peers, and this is because it requires synchronized time between peers, and this is
frequently not the case. Therefore, relative times, expressed in 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 [5],
and domain names. and domain names.
Extensions which have headers containing URIs SHOULD allow any URI, Extensions which have header fields containing URIs SHOULD allow any
not just SIP URIs. URI, not just SIP URIs.
Headers SHOULD follow the standard formatting for SIP, defined as: Header fields MUST follow the standard formatting for SIP, defined
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
value = token / host / quoted-string value = token / host / quoted-string
In some cases, this form is not sufficient. That is the case for In some cases, this form is not sufficient. That is the case for
headers that express descriptive text not meant for human header fields that express descriptive text meant for human
consumption. An example is the Subject header in SIP [2]. In this consumption. An example is the Subject header field in SIP [2]. In
case, an alternate form is: this case, an alternate form is:
header = header-name HCOLON [TEXT-UTF8-TRIM] header = header-name HCOLON [TEXT-UTF8-TRIM]
Developers of extensions SHOULD allow for extension parameters in Developers of extensions SHOULD allow for extension parameters in
their headers. their header fields.
Headers that contain a list of URIs SHOULD follow the same syntax as Header Fields that contain a list of URIs SHOULD follow the same
the Contact header in SIP. Implementors are also encouraged to always syntax as the Contact header field in SIP. Implementors are also
wrap these URI in angle brackets "<" and ">". We have found this to encouraged to always wrap these URI in angle brackets "<" and ">". We
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 values. Compression of SIP messages SHOULD be handled at of header field values. Compression of SIP messages SHOULD be handled
lower layers, for example, using IP payload compression [10] or at lower layers, for example, using IP payload compression [16] or
signalling compression [11]. signalling compression [17].
Syntax for headers is expressed in Augmented Backus-Naur Form and Syntax for header fields is expressed in Augmented Backus-Naur Form
MUST follow the format of RFC 2234 [3]. Extensions MUST make use of and MUST follow the format of RFC 2234 [3]. Extensions MUST make use
the primitive components defined in RFC BBBB [2]. If the construction of the primitive components defined in RFC 3261 [2]. If the
for a BNF element is defined in another specification, it is construction for a BNF element is defined in another specification,
RECOMMENDED that the construction be referenced rather than copied. it is RECOMMENDED that the construction be referenced rather than
The reference SHOULD include both the document and section number. copied. The reference SHOULD include both the document and section
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
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
space. Linear white space, for better or worse, allows for line space. Linear white space, for better or worse, allows for line
folding. Extensions SHOULD NOT define new headers that use alternate folding. Extensions MUST NOT define new header fields that use
linear white space rules. alternate linear white space rules.
All SIP extensions MUST verify that any BNF productions that they
define in their grammar do not conflict with any existing grammar
defined in other SIP standards track specifications.
4.5 Semantics, Semantics, Semantics 4.5 Semantics, Semantics, Semantics
Developers of protocols often get caught up in syntax issues, without Developers of protocols often get caught up in syntax issues, without
spending enough time on semantics. The semantics of a protocol are spending enough time on semantics. The semantics of a protocol are
far more important. SIP extensions MUST clearly define the semantics far more important. SIP extensions MUST clearly define the semantics
of the extensions. Specifically, the extension MUST specify the of the extensions. Specifically, the extension MUST specify the
behaviors expected of a UAC, UAS and proxy in processing the behaviors expected of a UAC, UAS and proxy in processing the
extension. This is often best described by having separate sections extension. This is often best described by having separate sections
for each of these three elements. Each section SHOULD step through for each of these three elements. Each section SHOULD step through
the processing rules in temporal order of the most common messaging the processing rules in temporal order of the most common messaging
scenario. scenario.
Processing rules generally specify actions to take (in terms of Processing rules generally specify actions to take (in terms of
messages to send, variables to store, rules to follow) on receipt of messages to send, variables to store, rules to follow) on receipt of
messages and expiration of timers. If an action requires transmission messages and expiration of timers. If an action requires transmission
of a message, the rule SHOULD outline requirements for insertion of of a message, the rule SHOULD outline requirements for insertion of
headers or other information in the message. header fields or other information in the message.
The extension SHOULD specify procedures to take in exceptional The extension SHOULD specify procedures to take in exceptional
conditions which are recoverable, or which require some kind of user conditions which are recoverable, or which require some kind of user
intervention. Recovering from unrecoverable problems generally does intervention. Recovering from unrecoverable problems generally does
not require specification. not require specification.
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 Call Flows message flows and message formatting defined in the Basic Call Flows
Example specification [12]. Note that complete messages SHOULD be specification [18]. Note that complete messages SHOULD be used. Be
used. Be careful to include tags, Via headers (with the branch ID careful to include tags, Via header fields (with the branch ID
cookie), Max-Forwards, Content-Lengths, Record-Route and Route cookie), Max-Forwards, Content-Lengths, Record-Route and Route header
headers. fields. Example INVITE messages MAY omit session descriptions, and
Content-Length values MAY be set to "..." to indicate that the value
is not provided. However, the specification MUST explicitly call out
the meanining of the "..." and explicitly indicate that session
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.
4.8 Document Naming Conventions 4.8 IANA Considerations Section
Documents which define new SIP extensions will invariably have IANA
Considerations sections.
If your extension is defining a new event package, you MUST register
that package. RFC 3265 [6] provides the registration template. See
[19] for an example of the registration of a new event package.
If your extension is defining a new header field, you MUST register
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
SIP header fields.
If your extension is defining a new response code, you MUST register
that response code. RFC 3261 [2] provides a registration template.
See [12] for an example of how to register a new response code.
If your extension is defining a new SIP method, you MUST register
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
SIP method.
Many SIP extensions make use of option tags, carried in the Require,
Proxy-Require and Supported header fields. Section 4.1 discusses 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. RFC 3261 [2] provides a registration template. See Section
8.1 of RFC 3262 [20] for an example of how to register an option tag.
Some SIP extensions will require establishment of their own IANA
registries. RFC 2434 [7] provides guidance on how and when IANA
registries are established. For an example of how to set one up, see
Section 6 of RFC 3265 [6] for an example.
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 "An Extension is RECOMMENDED that the title follow the basic form of "A [summary of
to the Session Initiation Protocol for X", where X is a 1-3 word function] for the Session Initiation Protocol (SIP)", where the
description of the extension. For example, if an extension defines a summary of function is a one to three word description of the
new header, called Make-Coffee, for making coffee, the title would extension. For example, if an extension defines a new header field,
read, "An Extenstion to the Session Initiation Protocol for Making called Make-Coffee, for making coffee, the title would read, "Making
Coffee". It is RECOMMENED that these additional words be descriptive Coffee with the Session Initiation Protocol (SIP)". It is RECOMMENED
rather than naming the header. For example, the extension for making that these additional words be descriptive rather than naming the
coffee should not be named "An Extension to the Session Initiation header field. For example, the extension for making coffee should not
Protocol for Make-Coffee". be named "The Make-Coffee Header for the Session 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 X Method" where X is the titles is "The Session Initiation Protocol (SIP) X Method" where X is
name of the method. the name of the method.
4.9 Additional Considerations for New Methods Note that the acronymn SIP MUST be expanded in the titles of RFCs, as
per [22].
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 of those bodies? What body types are allowed? presence 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 What headers are allowed in requests of this method? It is o The extension MUST define which header fields can be present
RECOMMENDED that this information be presented through a in requests of that method. It is RECOMMENDED that this
column of Table 2 in RFC BBBB [2]. information 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 track RFCs at the time of writing of the
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 dialog? a dialog?
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 responses. However, those extensions MUST adhere to the its responses. However, those extensions MUST adhere to the
protocol rules specified in [6], and MUST adhere to the protocol rules specified in [8], and MUST adhere to the
additional constraints for offers and answers as specified in additional 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 new methods, those requests need to be answered with new methods, those requests need to be answered
immediately by the UAS. Protocol extensions that require immediately by the UAS. Protocol extensions that require
longer durations for the generation of a response (such as a longer durations for the generation of a response (such as a
new method that does require human interaction) SHOULD instead new method that requires human interaction) SHOULD instead use
use two transactions - one to send the request, and another in two transactions - one to send the request, and another in the
the reverse direction to convey the result of the request. reverse direction to convey the result of the request. An
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 on a method-by-method basis. SIP [2] only allows method on a method-by-method basis. SIP [2] only allows
cancellation of INVITE. Extensions that define new methods cancellation of INVITE. Extensions that define new methods
MUST state whether or not transactions initiated by requests MUST state whether or not transactions initiated by requests
with that method can be cancelled. Furthermore, the rules a with that method can be cancelled. Furthermore, the rules a
UAS should follow upon cancellation of an unanswered request UAS should follow upon cancellation of an unanswered request
MUST be described. Note that, since non-INVITE requests are MUST be described. Note that, since non-INVITE requests are
generally answered immediately, cancellation ususally serves generally answered 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.10 Additional Considerations for New Headers or Header Parameters 4.11 Additional Considerations for New Header Fields or Header Field
Parameters
The most important issue for extensions that define new headers is The most important issue for extensions that define new header fields
backwards compatibility. See Section 4.1 for a discussion of the or header field parameters is backwards compatibility. See Section
issues. The extension MUST detail how backwards compatibility is 4.1 for a discussion of the issues. The extension MUST detail how
addressed. backwards compatibility is addressed.
It is often tempting to avoid creation of a new method by overloading It is often tempting to avoid creation of a new method by overloading
an existing method through a header. Headers are not meant to an existing method through a header field or parameter. Header fields
fundamentally alter the meaning of the method of the request. A new and parameters are not meant to fundamentally alter the meaning of
header cannot change the basic semantic and processing rules of a the method of the request. A new header field cannot change the basic
method. There is no shortage of method names, so when an extension semantic and processing rules of a method. There is no shortage of
changes the basic meaning of a request, a new method SHOULD be method names, so when an extension changes the basic meaning of a
defined. request, a new method SHOULD be defined.
Specifications that define new headers MUST include a table with For extensions that define new header fields, the extension MUST
identical columns to that of Table 2 of RFC BBBB [2] with a row for define the request methods the header field can appear in, and what
each new header. Furthermore, the table MUST include a column for any responses it can be used in. It is RECOMMENDED that this information
methods defined in any other standards track extensions that have be represented as a new row of Table 2/3 of RFC 3261 [2]. The table
reached RFC status. MUST contain columns for all methods defined in standards track RFCs
at time of writing of the extension.
4.11 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 through an URI even if content SHOULD be included indirectly [23] even if congestion
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 with extensions. This is generally because it interactions with extensions. This is generally because it
can cause (1) a single transmitted request to be received can cause (1) a single transmitted request to be received
by an unknown number of UASs, and (2) a single request to by an unknown number of UASs, and (2) a single INVITE
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 they are exceptions to many of the general request that they are exceptions to many of the general request
processing rules. The main reason for this special status processing rules. The main reason for this special status
is that CANCEL and ACK are always associated with another is that CANCEL and ACK are always associated with another
request. New methods SHOULD consider the meaning of request. New methods SHOULD consider the meaning of
cancellation, as described above. Extensions which defined cancellation, as described above. Extensions which defined
new headers in INVITE requests SHOULD consider whether they new header fields in INVITE requests SHOULD consider
also need to be included in ACK. whether they also need to be included in ACK and CANCEL.
Frequently they do, in order to allow a stateless proxy to
route the CANCEL or ACK identically to the INVITE.
Routing: The presence of Route headers in a request can cause it Routing: The presence of Route header fields in a request can
to be sent through intermediate proxies. Requests that cause it to be sent through intermediate proxies. Requests
establish dialogs can be record-routed, so that the initial that establish dialogs can be record-routed, so that the
request goes through one set of proxies, and subsequent initial request goes through one set of proxies, and
requests through a different set. These SIP features can subsequent requests through a different set. These SIP
interact in unusual ways with extensions. features can interact in 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 certain services. Extensions which depend on some execute certain services. Extensions which depend on some
kind of proxy processing SHOULD consider how stateless kind of proxy processing SHOULD consider how stateless
proxies affect that processing. proxies affect that 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 Authors Addresses 8 Acknowledgements
The authors would like to thank Rohan Mahy for his comments.
9 Authors Addresses
Jonathan Rosenberg Jonathan Rosenberg
dynamicsoft dynamicsoft
72 Eagle Rock Avenue 72 Eagle Rock Avenue
East Hanover, NJ 07936 East Hanover, NJ 07936
email: jdrosen@dynamicsoft.com email: jdrosen@dynamicsoft.com
Henning Schulzrinne Henning Schulzrinne
Columbia University Columbia University
M/S 0401 M/S 0401
1214 Amsterdam Ave. 1214 Amsterdam Ave.
New York, NY 10027-7003 New York, NY 10027-7003
email: schulzrinne@cs.columbia.edu email: schulzrinne@cs.columbia.edu
9 Normative References 10 Normative References
[1] S. Bradner, "Key words for use in RFCs to indicate requirement [1] S. Bradner, "Key words for use in RFCs to indicate requirement
levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. levels," RFC 2119, Internet Engineering Task Force, Mar. 1997.
[2] J. Rosenberg, H. Schulzrinne, et al. , "SIP: Session initiation [2] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.
protocol," Internet Draft, Internet Engineering Task Force, Feb. Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session
2002. Work in progress. initiation protocol," RFC 3261, Internet Engineering Task Force, June
2002.
[3] D. Crocker, Ed., and P. Overell, "Augmented BNF for syntax [3] "Augmented BNF for syntax specifications: ABNF," RFC 2234,
specifications: ABNF," RFC 2234, Internet Engineering Task Force, Internet Engineering Task Force, Nov. 1997.
Nov. 1997.
[4] H. Alvestrand, "IETF policy on character sets and languages," RFC [4] H. Alvestrand, "IETF policy on character sets and languages," RFC
2277, Internet Engineering Task Force, Jan. 1998. 2277, Internet Engineering Task Force, Jan. 1998.
[5] R. Hinden, B. Carpenter, and L. Masinter, "Format for literal [5] R. Hinden, B. Carpenter, and L. Masinter, "Format for literal
IPv6 addresses in URL's," RFC 2732, Internet Engineering Task Force, IPv6 addresses in URL's," RFC 2732, Internet Engineering Task Force,
Dec. 1999. Dec. 1999.
[6] J. Rosenberg and H. Schulzrinne, "An offer/answer model with [6] A. B. Roach, "Session initiation protocol (sip)-specific event
SDP," Internet Draft, Internet Engineering Task Force, Feb. 2002. notification," RFC 3265, Internet Engineering Task Force, June 2002.
Work in progress.
10 Informative References [7] T. Narten and H. Alvestrand, "Guidelines for writing an IANA
considerations section in RFCs," RFC 2434, Internet Engineering Task
Force, Oct. 1998.
[7] S. Bradner, R. Mahy, A. Mankin, et al. , "SIP change process," [8] J. Rosenberg and H. Schulzrinne, "An offer/answer model with
Internet Draft, Internet Engineering Task Force, Mar. 2002. Work in session description protocol (SDP)," RFC 3264, Internet Engineering
progress. Task Force, June 2002.
[8] R. Droms, "Dynamic host configuration protocol," RFC 2131, 11 Informative References
[9] A. Mankin, S. Bradner, and R. Mahy, "Change process for the
session initiation protocol (SIP)," Internet Draft, Internet
Engineering Task Force, Aug. 2002. Work in progress.
[10] R. Droms, "Dynamic host configuration protocol," RFC 2131,
Internet Engineering Task Force, Mar. 1997. Internet Engineering Task Force, Mar. 1997.
[9] S. Donovan and J. Rosenberg, "SIP session timer," Internet Draft, [11] R. Sparks, "The SIP refer method," Internet Draft, Internet
Internet Engineering Task Force, Oct. 2001. Work in progress. Engineering Task Force, July 2002. Work in progress.
[10] A. Shacham, R. Monsour, R. Pereira, and M. Thomas, "IP payload [12] S. Donovan and J. Rosenberg, "Session initiation protocol
extension for session timer," Internet Draft, Internet Engineering
Task Force, July 2002. Work in progress.
[13] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P.
Leach, and T. Berners-Lee, "Hypertext transfer protocol -- HTTP/1.1,"
RFC 2616, Internet Engineering Task Force, June 1999.
[14] H. Schulzrinne, A. Rao, and R. Lanphier, "Real time streaming
protocol (RTSP)," RFC 2326, Internet Engineering Task Force, Apr.
1998.
[15] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
session initiation protocol," RFC 2543, Internet Engineering Task
Force, Mar. 1999.
[16] A. Shacham, R. Monsour, R. Pereira, and M. Thomas, "IP payload
compression protocol (ipcomp)," RFC 2393, Internet Engineering Task compression protocol (ipcomp)," RFC 2393, Internet Engineering Task
Force, Dec. 1998. Force, Dec. 1998.
[11] R. Price, H. Hannu, et al. , "Signaling compression," Internet [17] R. Price et al. , "Signaling compression," Internet Draft,
Draft, Internet Engineering Task Force, May 2002. Work in progress. Internet Engineering Task Force, June 2002. Work in progress.
[12] A. Johnston, S. Donovan, R. Sparks, C. Cunningham, D. Willis, J. [18] A. Johnston et al. , "Session initiation protocol basic call
Rosenberg, K. Summers, and H. Schulzrinne, "SIP telephony call flow flow examples," Internet Draft, Internet Engineering Task Force, Aug.
examples," Internet Draft, Internet Engineering Task Force, Apr. 2002. Work in progress.
2001. Work in progress.
[19] J. Rosenberg, "A sip event package for registration state,"
Internet Draft, Internet Engineering Task Force, Oct. 2002. Work in
progress.
[20] J. Rosenberg and H. Schulzrinne, "Reliability of provisional
responses in session initiation protocol (SIP)," RFC 3262, Internet
Engineering Task Force, June 2002.
[21] J. Rosenberg, "The session initiation protocol (SIP) UPDATE
method," RFC 3311, Internet Engineering Task Force, Oct. 2002.
[22] J. Reynolds and B. Braden, "Instructions to request for comments
(RFC) authors," Internet Draft, Internet Engineering Task Force, Apr.
2002. Work in progress.
[23] S. Olson, "Requirements for content indirection in SIP
messages," Internet Draft, Internet Engineering Task Force, July
2002. Work in progress.
Full Copyright Statement Full Copyright Statement
Copyright (c) The Internet Society (2002). All Rights Reserved. Copyright (c) The Internet Society (2002). 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
 End of changes. 

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