draft-ietf-sip-guidelines-00.txt   draft-ietf-sip-guidelines-01.txt 
Internet Engineering Task Force SIP WG Internet Engineering Task Force SIP WG
Internet Draft J.Rosenberg,H.Schulzrinne Internet Draft J.Rosenberg,H.Schulzrinne
draft-ietf-sip-guidelines-00.txt dynamicsoft,Columbia U. draft-ietf-sip-guidelines-01.txt dynamicsoft,Columbia U.
July 12, 2000 November 24, 2000
Expires: January, 2001 Expires: May, 2001
Guidelines for Authors of SIP Extensions Guidelines for Authors of SIP Extensions
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
skipping to change at page 1, line 47 skipping to change at page 1, line 47
to facilitate effective and interoperable extensions to SIP, some to facilitate effective and interoperable extensions to SIP, some
guidelines need to be followed when developing SIP extensions. This guidelines need to be followed when developing SIP extensions. This
document outlines a set of such guidelines for authors of SIP document outlines a set of such guidelines for authors of SIP
extensions. extensions.
1 Introduction 1 Introduction
The Session Initiation Protocol (SIP) [1] is a flexible, yet simple The Session Initiation Protocol (SIP) [1] 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.
SIP can be extended in numerous ways. New methods, headers and body SIP can be extended in numerous ways. New methods, headers, body
types and parameters for existing headers can be defined. This types and parameters for existing headers can be defined. This
flexibility also means that caution should be exercised when defining flexibility also means that caution should be exercised when defining
extensions, in order to ensure interoperability. extensions, in order to ensure interoperability.
In order to facilitate interoperability, this document serves as a In order to facilitate interoperability, this document serves as a
set of guidelines for authors of SIP extensions. It points out issues set of guidelines for authors of SIP extensions. It points out issues
to consider when deciding whether a SIP extension is the right answer to consider when deciding whether a SIP extension is the right answer
for a specific problem. It then points out issues which extensions for a specific problem. It then points out issues which extensions
should deal with from within the specification. Finally, it discusses should deal with from within their specification. Finally, it
common interactions with existing SIP features which often cause discusses common interactions with existing SIP features which often
difficulties in extensions. cause difficulties in extensions.
2 Should I define a SIP Extension? 2 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
skipping to change at page 3, line 13 skipping to change at page 3, line 13
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.
2.1 SIP's Solution Space 2.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 SIPs 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 a users, interactive sessions. This process involves the discovery of users,
(or more generally, entities that can be communicated with) wherever (or more generally, entities that can be communicated with, including
they may be located, so that a description of the session can be services, such as voicemail or translation devices) wherever they may
delivered to the user. It is assumed that these users or be located, so that a description of the session can be delivered to
communications entities are mobile, and their point of attachment to the user. It is assumed that these users or communications entities
the network changes over time. The primary purpose of SIP is a are mobile, and their point of attachment to the network changes over
rendezvous function, to allow a request initiator to deliver a time. The primary purpose of SIP is a rendezvous function, to allow a
message to a recipient wherever they be. Such rendezvous is needed to request initiator to deliver a message to a recipient wherever they
establish a session, but can be used for other purposes, such as be. Such rendezvous is needed to establish a session, but can be used
querying for capabilities or delivery of an instant message. for other purposes related to communications, such as querying for
capabilities or delivery of an instant message.
SIP itself is independent of the session, and the session description Much of SIP focuses on this discovery and rendezvous component. Its
is delivered as an opaque body. Much of SIP focuses on this discovery ability to fork, its registration capabilities, and its routing
component. Its ability to fork, its registration capabilities, and capabilities are all present for the singular purpose of finding the
its routing capabilities are all present for the singular purpose of desired user wherever they may be. As such, features and capabilities
finding the called user wherever they may be. As such, features and such as personal mobility, automatic call distribution, and follow-me
capabilities such as personal mobility, automatic call distribution, are well within the SIP solution space.
and follow-me 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
decision on whether to join or not. That information includes data decision on whether to join or not. That information includes data
about the caller, the purpose for the invitation, and parameters of about the caller, the purpose for the invitation, and parameters of
the session itself. For this reason, SIP includes this kind of the session itself. For this reason, SIP includes this kind of
information. information.
Part of the process of session initiation is the communication of Part of the process of session initiation is the communication of
progress and the final results of establishment of the session. SIP progress and the final results of establishment of the session. SIP
provides this information as well. provides this information as well.
There are many functions that SIP explicitly does not provide. It is SIP itself is independent of the session, and the session description
not a session management protocol or a conference control protocol. is delivered as an opaque body within SIP messages. Keeping SIP
The particulars of the communications within the session are outside independent of the sessions it initiates and terminates is
of SIP. This includes features such as media transport, voting and fundamental. As such, there are many functions that SIP explicitly
polling, virtual microphone passing, chairman election, floor does not provide. It is not a session management protocol or a
control, and feedback on session quality. conference control protocol. The particulars of the communications
within the session are outside of SIP. This includes features such as
media transport, voting and polling, virtual microphone passing,
chairman election, floor control, and feedback on session quality.
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 packets for a session may completely independent from the path that packets for a session may
take. The path independence refers to paths within a providers take. The path independence refers to paths within a providers
network, and the set of providers itself. For example, it is network, and the set of providers itself. For example, it is
perfectly reasonable for a SIP message to traverse a completely perfectly reasonable for a SIP message to traverse a completely
different set of autonomous systems than the audio in a session SIP different set of autonomous systems than the audio in a session SIP
establishes. establishes.
skipping to change at page 4, line 38 skipping to change at page 4, line 41
limitation in extent (i.e., usually not multi-hop), it is appropriate limitation in extent (i.e., usually not multi-hop), it is appropriate
to transfer larger amounts of content in REGISTER. In such cases, TCP to transfer larger amounts of content in REGISTER. In such cases, TCP
is preferred. is preferred.
SIP is not meant to be a general RPC mechanism. None of its user SIP is not meant to be a general RPC mechanism. None of its user
discovery and registration capabilities are needed for RPC, neither discovery and registration capabilities are needed for RPC, neither
are most of its proxy functions. As it is not an ideal transfer are most of its proxy functions. As it is not an ideal transfer
protocol, it is not good at carrying serialized objects of any large protocol, it is not good at carrying serialized objects of any large
size. size.
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
signaling, and can provide many features present in the PSTN, the
mere existence of a feature or capability in the PSTN is not a
justification for its inclusion in SIP. Extensions needed to support
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 change a configuration parameter. Control
protocols have different trust relationships than is assumed in SIP, protocols have different trust relationships than is assumed in SIP,
and are more centralized in architecture than SIP, which is a very and are more centralized in architecture than SIP, which is a very
distributed protocol. distributed protocol.
There are many network layer services needed to make SIP function.
These include quality of service, mobility, and security, among
others. Rather than building these capabilities into SIP itself, they
should be developed outside of SIP, and then used by it.
Specifically, any protocol mechanisms that are needed by SIP, but are
also needed by many other application layer protocols, should not be
addressed within SIP.
2.2 SIP Architectural Model 2.2 SIP Architectural Model
We describe here some of the primary architectual assumptions which We describe here some of the primary architectual assumptions which
underly SIP. Extensions which violate these assumptions should be underly SIP. Extensions which violate these assumptions should be
examined more carefully to determine their appropriateness for SIP. examined more carefully to determine their appropriateness for SIP.
Session independence: SIP is independent of the session it Session independence: SIP is independent of the session it
establishes. This includes the type of session, be it establishes. This includes the type of session, be it
audio, video, game, chat session, or virtual reality. SIP audio, video, game, chat session, or virtual reality. SIP
operation should never be dependent on some characteristic operation should never be dependent on some characteristic
of the session. SIP is not specific to VoIP only. Any of 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 and the packets in the session are unrelated. They messages and the packets in the session are unrelated. They
may be the same in some cases, but it is fundamental to may be the same in some cases, but it is fundamental to
SIPs architecture that they need not be the same. SIPs architecture that they need not be the same.
Extensions which only work under some assumption of overlap Extensions which only work under some assumption of overlap
are not generally applicable to SIPs operation and should are not generally applicable to SIPs operation and should
skipping to change at page 5, line 48 skipping to change at page 6, line 17
they must be able to operate with minimal message they must be able to operate with minimal message
processing. SIP has been engineered so that proxies can processing. SIP has been engineered so that proxies can
always ignore bodies. Extensions which require proxies to always ignore bodies. Extensions which require proxies to
examine bodies in order to work will likely lead to serious examine bodies in order to work will likely lead to serious
scaling problems. scaling problems.
Proxies don't need to understand the method: Processing of Proxies don't need to understand the method: Processing of
requests in proxies does not depend on the method, except requests in proxies does not depend on the method, except
for the well known methods INVITE, ACK, and CANCEL. This for the well known methods INVITE, ACK, and CANCEL. This
allows for extensibility. Extensions that define new allows for extensibility. Extensions that define new
methods which must be understood by proxies are NOT methods which must be understood by proxies are not
RECOMMENDED. recommended.
INVITE messages carry full state: An initial INVITE message for 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 a re-INVITE message to modify some characteristic of the
session. This is strongly coupled to the idempotency of SIP session. This is strongly coupled to the idempotency of SIP
requests, but is a different characteristic. Extensions requests, but is a different characteristic. Extensions
which modify INVITE processing such that data spanning which modify INVITE processing such that data spanning
multiple INVITEs must be collected in order to perform some multiple INVITEs must be collected in order to perform some
feature, are frowned upon. feature, are frowned upon.
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 is generally preferred. capability is generally preferred.
The Request URI is the primary key for routing: Forwarding logic
at SIP servers depends primarily on the request URI. It is
fundamental to the operation of SIP that the request URI
indicate a resource that, under normal operations, resolves
to the desired recipient. Extensions that use other
components of the SIP message as the primary routing key,
or modify the semantics of the request URI, are frowned
upon.
Proxies can operate statelessly: SIP allows for great
flexibility in the design of proxies. They can operate in
fast, stateless modes, or they can maintain complete call
and session state, providing advanced services. SIP
extensions should insure that such a range of servers can
always be built. Therefore, extensions which operate only
with stateful proxies, for example, are discouraged.
Heterogeneity is the norm: SIP supports hetereogeneous devices.
It has built in mechanisms for determining the set of
overlapping protocol functionalities. Extensions which only
function if all devices support the extension are strongly
discouraged.
3 Issues to be Addressed 3 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 extension should take into there are several issues that all extension should take into
consideration. consideration.
3.1 Backwards Compatibility 3.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 [3] coupled with how the Require, Proxy-Require, and Supported [3]
headers are used. headers are used.
If an extension consists of new headers inserted by a user agent in a If an extension consists of new headers inserted by a user agent in a
request with an existing method, and the request cannot be processed request with an existing method, and the request cannot be processed
reasonably by a proxy and/or user agent without understanding the reasonably by a proxy and/or user agent without understanding the
headers, the extension MUST mandate the usage of the Require and/or headers, the extension must mandate the usage of the Require and/or
Proxy-Require headers in the request. These extensions are not Proxy-Require headers in the request. These extensions are not
backwards compatible with SIP. The result of mandating usage of these backwards compatible with SIP. The result of mandating usage of these
headers means that requests cannot be serviced unless the entities headers means that requests cannot be serviced unless the entities
being communicated with also understand the extension. If some entity being communicated with also understand the extension. If some entity
does not understand the extension, the request will be rejected. The does not understand the extension, the request will be rejected. The
UAC can then handle this in one of two ways. In the first, the UAC can then handle this in one of two ways. In the first, the
request simply fails, and the service cannot be provided. This is request simply fails, and the service cannot be provided. This is
basically an interoperability failure. In the second case, the UAC basically an interoperability failure. In the second case, the UAC
retries the request without the extension. This will preserve 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,sczz this leads to an As the number of extensions increases, this leads to an exponential
exponential explosion in the sets of processing rules a UAC may need explosion in the sets of processing rules a UAC may need to
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 headers in requests for basic SIP services
(in particular, session initiation and termination) is NOT (in particular, session initiation and termination) is
RECOMMENDED. The less frequently a particular extension is strongly discouraged. The less frequently a particular
needed in a request, the more reasonable it is to use these extension is needed in a request, the more reasonable it is to
headers. use these headers.
o The Proxy-Require header SHOULD be avoided at all costs. The o The Proxy-Require header should be avoided at all costs. The
failure likelihood in an individual proxy stays constant, but failure likelihood in an individual proxy stays constant, but
the path failure grows exponentially with the number of hops. the path failure grows exponentially with the number of hops.
On the other hand, the Require header only mandates that a On the other hand, the Require header only mandates that a
single entity, the UAS, support the extension. Usage of single entity, the UAS, support the extension. Usage of
Proxy-Require is thus considered exponentially worse than Proxy-Require is thus considered exponentially worse than
usage of the Require header. usage of the Require header.
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. SIP defines mechanisms which allow a UAC to know whether a
new method is understood by a UAS. This includes both the OPTIONS new method is understood by a UAS. This includes both the OPTIONS
skipping to change at page 7, line 35 skipping to change at page 8, line 27
header. It is fundamental to SIP that proxies do not need to header. It is fundamental to SIP that proxies do not need to
understand the semantics of a new method in order to process it. If understand the semantics of a new method in order to process it. If
an extension defines a new method which must be understood by proxies an extension defines a new method which must be understood by proxies
in order to be processed, a Proxy-Require header is needed. As in order to be processed, a Proxy-Require header is needed. As
discussed above, these kinds of extensions are frowned upon. 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 is used. There are two types of
new methods - those that are used for established sessions (initiated new methods - those that are used for established sessions (initiated
by INVITE, for example), and those that are sent as the initial by INVITE, for example), and those that are sent as the initial
request to a UA. Since INVITE and its response both SHOULD contain an request to a UA. Since INVITE and its response both should contain an
Allow header, a UA can readily determine whether the new method can Allow header, a UA can readily determine whether the new method can
be supported within the call. For example, if a new method for a be supported within the call. For example, if a new method for a
mid-call feature, such as hold, were to be defined, the hold button mid-call feature, such as hold, were to be defined, the hold button
on the UI could be "greyed out" once the call is established, if the on the UI could be "greyed out" once the call is established, if the
new method were not listed in the Allow header. new method were not listed in the Allow header.
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 headers into a request as it traverses the network, or for the UAS to
insert headers into a response. Some extensions can simply insert insert headers into a response. For some extensions, if the UAC or
these headers. If the UAC or UAS does not understand them, the UAS does not understand these headers, the message can still be
message can still be processed correctly. These extensions are processed correctly. These extensions are completely backwards
completely backwards compatible. compatible.
Most other extensions of this type will need to make use of the Most other extensions of this type require that the server only
Supported request header mechanism. This mechanism allows a server to insert the header if it is sure the client understands it. In this
determine if the client can understand some extension applied to the case, these extensions will need to make use of the Supported request
response. If an extension is such that it requires a server to insert header mechanism. This mechanism allows a server to determine if the
information into a response which must be understood in order for the client can understand some extension, so that it can apply the
response to be correctly processed, that extension SHOULD make use of extension to the response [3]. By their nature, these extensions may
[3]. By their nature, these extensions may not always be able to be not always be able to be applied to every response.
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 into a request,
and this header needs to be understood by both UAC and UAS to be and this header needs to be understood by both UAC and UAS to be
executed correctly, a combination of the Require and the Supported executed correctly, a combination of the Require and the Supported
mechanism will need to be used. The proxy can insert a Require header mechanism will need to be used. The proxy can insert a Require header
into the request, given the Supported header is present. An example into the request, given the Supported header is present. An example
of such an extension is the SIP Session Timer [4]. of such an extension is the SIP Session Timer [4].
Yet another type of extension are those which define new body types Yet another type of extension is that which defines new body types to
to be carried in SIP messages. If the body type is to be conveyed in be carried in SIP messages. According to the SIP specification,
a request without usage of MIME multipart [5], the compatibility bodies must be understood in order to process a request. As such, the
issues mirror those of new methods. Usage of Accept in INVITE and interoperability issues are similar to new methods. However, a new
INVITE responses is is RECOMMENDED to determine if the body type is header, Content-Disposition, has been defined that allows a client or
understood for subsequent requests. If a body type is to be conveyed server to indicate that the message body is optional [5]. Usage of
in a response, that type MUST only be sent if support for it was optional bodies is recommended wherever possible.
indicated in an Accept header in the request. If the body type is to
be conveyed in a request with multipart, that body can either be
mandatory or optional. Mandatory implies that the request cannot be
processed unless the body is understood. Optional implies that the
request can be processed if the body is understood. It is RECOMMENDED
that extensions specify optional bodies if at all possible.
We note that there is no defined way right now through MIME When a body must be understood to properly process a request or
headers to indicate whether a body is mandatory or response, it is preferred that the sending entity know ahead of time
optional. This can be accomplished through a Require whether the new body is understood by the recipient. For requests
header, but a MIME parameter somehow seems more appropriate that are the first in a sequence of exchanges between user agents
(such as INVITE), inclusion of Accept in the request and its success
responses is recommended. This will allow both parties to determine
what body types are supported by their peers. Subsequent messaging
between the peers would then only include body types that were
indicated as being understood.
3.2 Security 3.2 Security
Security is an important component of any protocol. SIP extensions Security is an important component of any protocol. SIP extensions
SHOULD consider how (or if) they affect usage of the general SIP should consider how (or if) they affect usage of the general SIP
security mechanisms. Most extensions should not require any new security mechanisms. Most extensions should not require any new
security capabilities beyond general purpose SIP. If they do, it is security capabilities beyond general purpose SIP. If they do, it is
likely that the security mechanism has more general purpose 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.
3.3 Usage Guidelines 3.3 Usage Guidelines
All SIP extensions MUST contain guidelines defining when the All SIP extensions must contain guidelines defining when the
extension is to be used. extension is to be used.
For new headers, the extension MUST define the request methods the For new headers, the extension must define the request methods the
header can appear in, and what responses it can be used in. It is header can appear in, and what responses it can be used in. It is
RECOMMENDED that this information be represented as a new row of recommended that this information be represented as a new row of
Table 4 of RFC 2543 [1]. The extension SHOULD specify which entities Table 4 of RFC 2543 [1]. The extension should specify which entities
(UAC, UAS, proxy, redirect, registrar) are allowed to insert the (UAC, UAS, proxy, redirect, registrar) are allowed to insert the
header. header.
3.4 Syntactic Issues 3.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 SHOULD define a compact form Extensions that define new headers should define a compact form
representation if the non-compact header is more than four representation if the non-compact header is more than four
characters. Header names SHOULD use ASCII characters. Header names characters. Compact headers must be a single character. When all 26
are always case insensitive. Header values are generally case characters are exhausted, new compact forms will no longer be
sensitive, with the exception of domain names which MUST be case defined. Header names should use ASCII characters. Header names are
insensitive. always case insensitive. Header values are generally case sensitive,
with the exception of domain names which must be case insensitive.
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. SIP extensions must clearly indicate the case sensitivity
or insensitivity of every parameter, value or field they define. In or insensitivity of every parameter, value or field they define. In
general, case sensitivity is preferred because of the reduced general, case sensitivity is preferred because of the reduced
processing requirements. processing requirements.
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 [6]. This UTF-8, as per the IETF policies on character set usage [6]. 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 should 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. extremely complicated and are to be avoided.
Extensions which make use of dates and times MUST use the SIP-Date Extensions which make use of dates and times must use the SIP-Date
BNF defined in RFC 2543. No other date formats are allowed. BNF defined in RFC 2543. No other date formats are allowed.
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 [7], quad IPv4 addresses, IPv6 addresses in the format described in [7],
and domain names. and domain names.
Extensions which have headers containing URLs SHOULD allow any URI, Extensions which have headers containing URLs should allow any URI,
not just SIP URLs. not just SIP URLs.
Headers SHOULD follow the standard formatting for SIP, defined as: Headers should follow the standard formatting for SIP, defined as:
header-name ":" # (value *( ";" parameter-name ["=" token] ) | header-name ":" # (value *( ";" parameter-name ["=" token] ) |
";" parameter-name ["=" quoted-string] )) ";" parameter-name ["=" quoted-string] ))
Developers of extensions are strongly encouraged to allow for Developers of extensions are strongly encouraged to allow for
parameters in their headers, and to also define extension parameters parameters in their headers, and to also define extension parameters
for their headers. for their headers.
Headers that contain a list of URIs SHOULD follow the same syntax as Headers that contain a list of URIs should follow the same syntax as
the Contact header in SIP. Implementors are also encouraged to always the Contact header in SIP. Implementors are also encouraged to always
wrap these URI in angle brackets "<" and ">". We have found this to wrap these URI in angle brackets "<" and ">". We have found this to
be a frequently misimplemented feature. 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 handled at lower of header values. Compression of SIP messages should be handled at
layers, for example, using IP payload compression [8] or link layer lower layers, for example, using IP payload compression [8] or link
compression. layer compression.
Syntax for headers is expressed in Augmented Backus-Naur Form.
Extensions must make use of the primitive components defined in
RFC2543 [1]. If the construction for a BNF element is defined in
another specification, it is recommended that the construction be
referenced rather than copied. The reference should include both the
document and section number. All BNF elements must be either defined
or referenced.
All tokens and quoted strings are separated by implicit linear white
space. Linear white space, for better or worse, allows for line
folding. Extensions cannot define new headers that use alternate
linear white space rules.
3.5 Semantics, Semantics, Semantics 3.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. headers 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. This usually includes receipt of messages that are not conditions. This usually includes receipt of messages that are not
expected, expiration of timers that handle timeouts, and presence of expected, expiration of timers that handle timeouts, and presence of
headers in messages when they are not expected. headers in messages when they are not expected.
3.6 Examples Section 3.6 Examples Section
Presence of sections in the extension giving examples of call flows Presence of sections in the extension giving examples of call flows
and message formatting is RECOMMENDED. Extensions which define and message formatting is recommended. 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 Call Flows
Example specification [9]. Note that complete messages SHOULD be Example specification [9]. Note that complete messages should be
used. Be careful to include tags, Via headers, Content-Lengths, used. Be careful to include tags, Via headers, Content-Lengths,
Record-Route and Route headers. Record-Route and Route headers.
3.7 Overview Section 3.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 [10] in the call flow should be mentioned. Usage of the RFC 2119 [10]
terminology in the overview section is RECOMMENDED. terminology in the overview section is recommended.
3.8 Additional Considerations for New Methods 3.8 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 What headers are allowed in requests of this method? It is
recommended that this information be presented through a recommended that this information be presented through a
column of Table 4 in RFC 2543 [1]. column of Table 4 in RFC 2543 [1].
o All SIP requests can generally be cancelled. However, an o All SIP requests can generally be cancelled. However, an
extension MAY mandate that a new method not be cancelled. In extension may mandate that a new method cannot be cancelled.
either case, handling of CANCEL SHOULD be described. In In either case, handling of CANCEL should be described. In
particular, the rules a UAS should follow upon cancellation of particular, the rules a UAS should follow upon cancellation of
an unanswered request SHOULD be described. an unanswered request should be described.
o Can the request be sent within a call or not? In this context, o Can the request be sent within a call or not? In this context,
within means that the request is sent with the same Call-ID, within means that the request is sent with the same Call-ID,
To and From field as an INVITE that was sent or received To and From field as an INVITE that was sent or received
previously. For, example, the REGISTER method is not previously. For, example, the REGISTER method is not
associated with a call, whereas the BYE method is. associated with a call, whereas the BYE method is.
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).
3.9 Additional Considerations for New Headers or Header Parameters 3.9 Additional Considerations for New Headers or Header Parameters
The most important issue for extensions that define new headers is The most important issue for extensions that define new headers is
backwards compatibility. See Section 3.1 for a discussion of the backwards compatibility. See Section 3.1 for a discussion of the
issues. The extension MUST detail how backwards compatibility is issues. The extension must detail how backwards compatibility is
addressed. 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. Headers are not meant to
fundamentally alter the meaning of the method of the request. A new fundamentally alter the meaning of the method of the request. A new
header SHOULD NOT change the basic semantic and processing rules of a header cannot change the basic semantic and processing rules of a
method. method.
3.10 Additional Considerations for New Body Types 3.10 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. If at all possible, the content of large bodies are frowned upon. If at all possible, the content
should be included indirectly through an http URL. should be included indirectly through an http URL.
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.
4 Interactions with SIP Features 4 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 request to
have multiple responses. have multiple responses.
Tags: Tags are used to uniquely identify call legs. Their Tags: Tags are used to uniquely identify call legs. Their
presence is neccesitated as a result of forking. They are presence is neccesitated as a result of forking. They are
an unfortunate exception to many SIP processing rules. an unfortunate exception to many SIP processing rules.
Extensions should carefully consider their effect. Extensions should carefully consider their effect.
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. New headers in INVITE requests SHOULD cancellation. New headers in INVITE requests should
consider whether they also need to be included in ACK. consider whether they also need to be included in ACK.
Routing: The Route, Record-Route and Via headers are used to Routing: The Route, Record-Route and Via headers are used to
support message routing. New request methods SHOULD support message routing. New request methods should
carefully consider how these headers are used. carefully consider how these headers are used.
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.
5 Security Considerations 5 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.
6 Changes since -00 6 Changes since -00
o Added that SIP is appropriate for rendezvous applications not o Compact form is a single character.
related to initiation.
o Added the usage of registration for transfer is appropriate.
o Mandated usage of the common form for headers. o Added some notes on BNF usage.
o Headers containing a list of URIs should be formatted like o Clarified extensions section.
Contact.
o Reference call flows document as an example of example call o SIP is not a PSTN replacement.
flows.
o Bodies can't change the semantics of a request. o Do not incorporate general purpose, cross-application
functions (like new key exchange protocols) into SIP.
o Compression is done at lower layers, not within SIP. o Request URI is used for routing
o SIP is not an RPC protocol. o Heterogeneity is the norm.
o SIP is not a control protocol. o No longer using rfc2119 terminology, as it is not appropriate
for BCP.
7 Authors Addresses 7 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.
skipping to change at page 14, line 31 skipping to change at page 15, line 34
Engineering Task Force, Mar. 1999. Engineering Task Force, Mar. 1999.
[2] R. Droms, "Dynamic host configuration protocol," Request for [2] R. Droms, "Dynamic host configuration protocol," Request for
Comments 2131, Internet Engineering Task Force, Mar. 1997. Comments 2131, Internet Engineering Task Force, Mar. 1997.
[3] J. Rosenberg and H. Schulzrinne, "The SIP supported header," [3] J. Rosenberg and H. Schulzrinne, "The SIP supported header,"
Internet Draft, Internet Engineering Task Force, Mar. 2000. Work in Internet Draft, Internet Engineering Task Force, Mar. 2000. Work in
progress. progress.
[4] S. Donovan and J. Rosenberg, "SIP session timer," Internet Draft, [4] S. Donovan and J. Rosenberg, "SIP session timer," Internet Draft,
Internet Engineering Task Force, Mar. 2000. Work in progress. Internet Engineering Task Force, Oct. 2000. Work in progress.
[5] N. Freed and N. Borenstein, "Multipurpose internet mail [5] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
extensions (MIME) part two: Media types," Request for Comments 2046, Session initiation protocol," Internet Draft, Internet Engineering
Internet Engineering Task Force, Nov. 1996. Task Force, Aug. 2000. Work in progress.
[6] H. Alvestrand, "IETF policy on character sets and languages," [6] H. Alvestrand, "IETF policy on character sets and languages,"
Request for Comments 2277, Internet Engineering Task Force, Jan. Request for Comments 2277, Internet Engineering Task Force, Jan.
1998. 1998.
[7] R. Hinden, B. Carpenter, and L. Masinter, "Format for literal [7] R. Hinden, B. Carpenter, and L. Masinter, "Format for literal
IPv6 addresses in URL's," Request for Comments 2732, Internet IPv6 addresses in URL's," Request for Comments 2732, Internet
Engineering Task Force, Dec. 1999. Engineering Task Force, Dec. 1999.
[8] A. Shacham, R. Monsour, R. Pereira, and M. Thomas, "IP payload [8] A. Shacham, R. Monsour, R. Pereira, and M. Thomas, "IP payload
compression protocol (ipcomp)," Request for Comments 2393, Internet compression protocol (ipcomp)," Request for Comments 2393, Internet
Engineering Task Force, Dec. 1998. Engineering Task Force, Dec. 1998.
[9] A. Johnston, S. Donovan, R. Sparks, C. Cunningham, K. Summers, D. [9] A. Johnston, S. Donovan, R. Sparks, C. Cunningham, D. Willis, J.
Willis, J. Rosenberg, and H. a. Schulzrinne, "SIP telephony call flow Rosenberg, K. Summers, and H. Schulzrinne, "SIP telephony call flow
examples," Internet Draft, Internet Engineering Task Force, Mar. examples," Internet Draft, Internet Engineering Task Force, July
2000. Work in progress. 2000. Work in progress.
[10] S. Bradner, "Key words for use in RFCs to indicate requirement [10] S. Bradner, "Key words for use in RFCs to indicate requirement
levels," Request for Comments 2119, Internet Engineering Task Force, levels," Request for Comments 2119, Internet Engineering Task Force,
Mar. 1997. Mar. 1997.
 End of changes. 

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