draft-ietf-sip-guidelines-04.txt   draft-ietf-sip-guidelines-05.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-04.txt draft-ietf-sip-guidelines-05.txt
March 1, 2002 June 6, 2002
Expires: September 2002 Expires: December 2002
Guidelines for Authors of SIP Extensions 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 .................................... 11 4.3 Usage Guidelines .................................... 10
4.4 Syntactic Issues .................................... 11 4.4 Syntactic Issues .................................... 10
4.5 Semantics, Semantics, Semantics ..................... 12 4.5 Semantics, Semantics, Semantics ..................... 12
4.6 Examples Section .................................... 13 4.6 Examples Section .................................... 13
4.7 Overview Section .................................... 13 4.7 Overview Section .................................... 13
4.8 Additional Considerations for New Methods ........... 13 4.8 Document Naming Conventions ......................... 13
4.9 Additional Considerations for New Headers or 4.9 Additional Considerations for New Methods ........... 14
Header Parameters .............................................. 14 4.10 Additional Considerations for New Headers or
4.10 Additional Considerations for New Body Types ........ 15 Header Parameters .............................................. 15
5 Interactions with SIP Features ...................... 15 4.11 Additional Considerations for New Body Types ........ 15
5 Interactions with SIP Features ...................... 16
6 Security Considerations ............................. 16 6 Security Considerations ............................. 16
7 Changes since -03 ................................... 16 7 IANA Considerations ................................. 16
8 Changes since -02 ................................... 16 8 Authors Addresses ................................... 17
9 Changes since -01 ................................... 16 9 Normative References ................................ 17
10 Authors Addresses ................................... 16 10 Informative References .............................. 17
11 Normative References ................................ 17
12 Informative References .............................. 17
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 guidelines
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 headers, new body types, and new parameters),
and there have been countless proposals that have been made to do and there have been countless proposals that have been made to do
just that. An IETF process has been put into place which defines how just that. An IETF process has been put into place which defines how
extensions are to be made to the SIP protocol [6]. That process is extensions are to be made to the SIP protocol [7]. That process is
designed to ensure that extensions are made which are appropriate for designed to ensure that extensions are made which are appropriate for
SIP (as opposed to being done in some other protocol), that these SIP (as opposed to being done in some other protocol), that these
extensions fit within the model and framework provided by SIP, and extensions fit within the model and framework provided by SIP and are
are consistent with its operation, and that these extensions solve consistent with its operation, and that these extensions solve
problems generically rather than for a specific use case. However, problems generically rather than for a specific use case. However,
[6] does not provide the technical guidelines needed to assist that [7] does not provide the technical guidelines needed to assist that
process. This draft helps to meet that need. process. This draft helps to meet that need.
This draft first provides a set of guidelines to help decide whether This draft first provides a set of guidelines to help decide whether
a certain piece of functionality is appropriately done in SIP. a certain piece of functionality is appropriately done in SIP.
Assuming the functionality is appropriate, it then points out issues Assuming the functionality is appropriate, it then points out issues
which extensions should deal with from within their specification. which extensions should deal with from within their specification.
Finally, it discusses common interactions with existing SIP features Finally, it discusses common interactions with existing SIP features
which often cause difficulties in extensions. which often cause difficulties in extensions.
3 Should I define a SIP Extension? 3 Should I define a SIP Extension?
skipping to change at page 4, line 10 skipping to change at page 4, line 10
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 SIPs
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 [7]. obtain their IP address. This is generally done through DHCP [8].
SIPs multicast registration mechanisms might supply an alternate way SIPs multicast registration mechanisms might supply an alternate way
to obtain an IP address. This would eliminate the need for DHCP in to obtain an IP address. This would eliminate the need for DHCP in
clients. However, we do not believe such extensions are appropriate. clients. However, we do not believe such extensions are appropriate.
We believe that protocols should be defined to provide specific, We believe that protocols should be defined to provide specific,
narrow functions, rather than being defined based on all narrow functions, rather than being defined based on all
communications requirements between a pair of devices. The latter communications requirements between a pair of devices. The latter
approach to protocol design yields modular protocols with broad approach to protocol design yields modular protocols with broad
application. It also facilitates extensibility and growth; single application. It also facilitates extensibility and growth; single
protocols can be removed and changed without affecting the entire protocols can be removed and changed without affecting the entire
system. We observe that this approach to protocol engineering mirrors system. We observe that this approach to protocol engineering mirrors
skipping to change at page 5, line 27 skipping to change at page 5, line 27
fundamental. As such, there are many functions that SIP explicitly fundamental. As such, there are many functions that SIP explicitly
does not provide. It is not a session management protocol or a does not provide. It is not a session management protocol or a
conference control protocol. The particulars of the communications conference control protocol. The particulars of the communications
within the session are outside of SIP. This includes features such as within the session are outside of SIP. This includes features such as
media transport, voting and polling, virtual microphone passing, media transport, voting and polling, virtual microphone passing,
chairman election, floor control, and feedback on session quality. 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 session packets may take.
take. The path independence refers to paths within a providers The path independence refers to paths within a providers network, and
network, and the set of providers itself. For example, it is the set of providers itself. For example, it is perfectly reasonable
perfectly reasonable for a SIP message to traverse a completely for a SIP message to traverse a completely different set of
different set of autonomous systems than the audio in a session SIP autonomous systems than the audio in a session SIP establishes.
establishes.
SIP is not a transfer protocol. It is not meant to send large amounts
of data unrelated to SIPs operation. It is not meant as a replacement
for HTTP. This is for numerous reasons, one of which is that SIP's
recommended mode of operation is over UDP. Sending large messages
over UDP can lead to fragmentation at the IP layer and thus poor
performance in even mildly lossy networks. This is not to say that
carrying payloads in SIP messages is never a good thing; in many
cases, the data is very much related to SIPs operation. However, SIP
is not meant to carry large amounts of data unrelated to SIPs general
function.
The only exception to this rule is REGISTER, which is, in many ways, SIP is not a general purpose transfer protocol. It is not meant to
its own protocol within SIP. REGISTER is ideally suited for send large amounts of data unrelated to SIPs operation. It is not
configuration and exchange of application layer data between a user meant as a replacement for HTTP. This is not to say that carrying
agent and its proxy. This may entail exchange of modest amounts of payloads in SIP messages is never a good thing; in many cases, the
data. Because of the infrequency of such exchanges and their data is very much related to SIPs operation. In those cases,
limitation in extent (i.e., usually not multi-hop), it is appropriate congestion controlled transports end-to-end are critical.
to transfer larger amounts of content in REGISTER. In such cases, TCP
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.
protocol, it is not good at carrying serialized objects of any large
size.
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
skipping to change at page 6, line 51 skipping to change at page 6, line 35
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 NOT be dependent on some characteristic of operation SHOULD NOT be dependent on some characteristic of
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 and the packets in the session are unrelated. They messages are unrelated to the set of routers and/or
may be the same in some cases, but it is fundamental to networks and/or autonomous systems traversed by session
SIPs architecture that they need not be the same. packets. They may be the same in some cases, but it is
Extensions which only work under some assumption of overlap fundamental to SIPs architecture that they need not be the
are not generally applicable to SIPs operation and should same. Extensions which only work under some assumption of
be scrutinized carefully. overlap are not generally applicable to SIPs operation and
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
enhanced with intermediate responses. Many of the rules of enhanced with intermediate responses. Many of the rules of
skipping to change at page 7, line 40 skipping to change at page 7, line 25
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 MUST NOT define new allows for extensibility. Extensions MUST NOT define new
methods which must be understood by proxies. methods which must be understood by proxies.
INVITE messages carry full state: An initial INVITE message for INVITE messages carry full state: An initial INVITE message for
a 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 soft-state property is fundamental to SIP, session. This full state property is fundamental to SIP,
and is critical for robustness of SIP systems. Extensions and is critical for robustness of SIP systems. Extensions
SHOULD NOT modify INVITE processing such that data spanning SHOULD NOT 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. feature.
Generality over efficiency: Wherever possible, SIP has favored Generality over efficiency: Wherever possible, SIP has favored
general purpose components rather than narrow ones. If some general purpose components rather than narrow ones. If some
capability is added to support one service, but a slightly capability is added to support one service, but a slightly
broader 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 routing: Forwarding logic The Request URI is the primary key for forwarding: Forwarding
at SIP servers depends primarily on the request URI. It is logic at SIP servers depends primarily on the request URI
fundamental to the operation of SIP that the request URI (this is different from request routing in SIP, which uses
indicate a resource that, under normal operations, resolves the Route headers to pass a request through intermediate
to the desired recipient. Extensions SHOULD NOT use other proxies). It is fundamental to the operation of SIP that
components of the SIP message as the primary routing key, the request URI indicate a resource that, under normal
and SHOULD NOT modify the semantics of the request URI. operations, resolves to the desired recipient. Extensions
SHOULD NOT use other components of the SIP message as the
Proxies can operate statelessly: SIP allows for great primary forwarding key, and SHOULD NOT modify the semantics
flexibility in the design of proxies. They can operate in of the request URI.
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 SHOULD NOT be
defined which operate only with stateful proxies.
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,
skipping to change at page 9, line 34 skipping to change at page 9, line 16
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.
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. SIP defines mechanisms which allow a UAC to know whether a
new method is understood by a UAS. This includes both the new method is understood by a UAS. This includes both the OPTIONS
OPTIONSrequest, and the 405 (Method Not Allowed) response with the request, and the 405 (Method Not Allowed) response with the Allow
Allow 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 dialogs (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 INVITEand its response both SHOULD contain an request to a UA. Since INVITEand 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 dialog. For example, if a new method for a
mid-call feature, such as hold, were to be defined, the hold button mid-dialog 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. For some extensions, if the UAC or insert headers into a response. For some extensions, if the UAC or
UAS does not understand these headers, the message can still be UAS does not understand these headers, the message can still be
processed correctly. These extensions are completely backwards processed correctly. These extensions are completely backwards
compatible. compatible.
skipping to change at page 10, line 25 skipping to change at page 10, line 6
header mechanism. This mechanism allows a server to determine if the header mechanism. This mechanism allows a server to determine if the
client can understand some extension, so that it can apply the client can understand some extension, so that it can apply the
extension to the response. By their nature, these extensions may not extension to the response. By their nature, these extensions may not
always be able to be applied to every response. 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 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 [8]. of such an extension is the SIP Session Timer [9].
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, a new interoperability issues are similar to new methods. However, the
header, Content-Disposition, has been defined that allows a client or Content-Disposition header has been defined to allow a client or
server to indicate that the message body is optional [2]. Usage of 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 are the first in a sequence of exchanges between user agents that establish a dialog, inclusion of Accept in the request and its
(such as INVITE), inclusion of Accept in the request and its success success responses is RECOMMENDED. This will allow both parties to
responses is RECOMMENDED. This will allow both parties to determine determine what body types are supported by their peers. Subsequent
what body types are supported by their peers. Subsequent messaging messaging between the peers would then only include body types that
between the peers would then only include body types that were were indicated as being understood.
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. 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.
skipping to change at page 11, line 28 skipping to change at page 11, line 9
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 Extensions that define new headers that are anticipated to be heavily
used SHOULD define a compact form if those headers are more than four used SHOULD define a compact form if those headers are more than four
characters. Compact headers MUST be a single character. When all 26 characters. Compact headers MUST be a single character. When all 26
characters are exhausted, new compact forms will no longer be characters are exhausted, new compact forms will no longer be
defined. Header names SHOULD use ASCII characters. Header names are defined. Header names SHOULD use ASCII characters.
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.
general, case sensitivity is preferred because of the reduced However, it is RECOMMENDED that these extensions be consistent with
processing requirements. baseline SIP, which uses case insensitive parameters, consistent with
the grammar constructs of RFC 2234 [3].
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 [3]. 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 SHOULD 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. 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 MUST use the SIP-Date BNF defined
BNF defined in RFC BBBB. No other date formats are allowed. in RFC BBBB [2]. No other date formats are allowed. However, the
usage of absolute dates in order to determine intervals (for example,
the time at which some timer fires) is NOT RECOMMENDED. This is
because it requires synchronized time between peers, and this is
frequently not the case. Therefore, relative times, expressed in
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 [4], quad IPv4 addresses, IPv6 addresses in the format described in [5],
and domain names. and domain names.
Extensions which have headers containing URLs SHOULD allow any URI, Extensions which have headers containing URIs SHOULD allow any URI,
not just SIP URLs. not just SIP URIs.
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 = header-name HCOLON header-value
";" parameter-name ["=" quoted-string] )) *(COMMA header-value)
header-name = token
header-value = value *(SEMI value-parameter)
value-parameter = token [EQUAL gen-value]
gen-value = token / host / quoted-string
value = token / host / quoted-string
In some cases, this form is not sufficient. That is the case for
headers that express descriptive text not meant for human
consumption. An example is the Subject header in SIP [2]. In this
case, an alternate form is:
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 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 be handled at of header values. Compression of SIP messages SHOULD be handled at
lower layers, for example, using IP payload compression [9] or link lower layers, for example, using IP payload compression [10] or
layer compression. signalling compression [11].
Syntax for headers is expressed in Augmented Backus-Naur Form. Syntax for headers is expressed in Augmented Backus-Naur Form and
Extensions MUST make use of the primitive components defined in RFC MUST follow the format of RFC 2234 [3]. Extensions MUST make use of
BBBB [2]. If the construction for a BNF element is defined in another the primitive components defined in RFC BBBB [2]. If the construction
specification, it is RECOMMENDED that the construction be referenced for a BNF element is defined in another specification, it is
rather than copied. The reference SHOULD include both the document RECOMMENDED that the construction be referenced rather than copied.
and section number. All BNF elements must be either defined or The reference SHOULD include both the document and section number.
referenced. All BNF elements must be either defined or referenced.
All tokens and quoted strings are separated by implicit 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 cannot define new headers that use alternate folding. Extensions SHOULD NOT define new headers that use alternate
linear white space rules. linear white space rules.
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
skipping to change at page 13, line 17 skipping to change at page 13, line 17
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 which are recoverable, or which require some kind of user
expected, expiration of timers that handle timeouts, and presence of intervention. Recovering from unrecoverable problems generally does
headers in messages when they are not expected. not require specification.
4.6 Examples Section 4.6 Examples Section
Presence of sections in the extension giving examples of call flows The specification SHOULD contain a section that gives examples of
and message formatting is RECOMMENDED. 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 Call Flows
Example specification [10]. Note that complete messages SHOULD be Example specification [12]. Note that complete messages SHOULD be
used. Be careful to include tags, Via headers, Content-Lengths, used. Be careful to include tags, Via headers (with the branch ID
Record-Route and Route headers. cookie), Max-Forwards, Content-Lengths, Record-Route and Route
headers.
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 RECOMMENDED. terminology in the overview section is NOT RECOMMENDED, and the
specification should explicitly state that the overview is tutorial
in nature only.
4.8 Additional Considerations for New Methods 4.8 Document Naming Conventions
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
is RECOMMENDED that the title follow the basic form of "An Extension
to the Session Initiation Protocol for X", where X is a 1-3 word
description of the extension. For example, if an extension defines a
new header, called Make-Coffee, for making coffee, the title would
read, "An Extenstion to the Session Initiation Protocol for Making
Coffee". It is RECOMMENED that these additional words be descriptive
rather than naming the header. For example, the extension for making
coffee should not be named "An Extension to the Session Initiation
Protocol for Make-Coffee".
For extensions that define new methods, an acceptable template for
titles is "The Session Initiation Protocol X Method" where X is the
name of the method.
4.9 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 BBBB [2]. column of Table 2 in RFC BBBB [2].
o The CANCEL request can be used for a particular transaction on
a method-by-method basis. SIP [2] only allows cancellation of
INVITE. Extensions that define new methods MUST state whether
or not transactions initiated by requests with that method can
be cancelled. Furthermore, the rules a UAS should follow upon
cancellation of an unanswered request MUST be described.
o Can the request be sent within a call or not? In this context, o Can the request be sent within a dialog, or does it establish
within means that the request is sent with the same Call-ID, a dialog?
To and From field as an INVITEthat was sent or received
previously. For, example, the REGISTERmethod is not associated
with a call, whereas the BYE method is.
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 [5], and MUST adhere to the protocol rules specified in [6], 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 does require human interaction) SHOULD instead
use two transactions - one to send the request, and another in use two transactions - one to send the request, and another in
the reverse direction to convey the result of the request. the reverse direction to convey the result of the request.
o The CANCEL request can be used for a particular extension
method on a method-by-method basis. SIP [2] only allows
cancellation of INVITE. Extensions that define new methods
MUST state whether or not transactions initiated by requests
with that method can be cancelled. Furthermore, the rules a
UAS should follow upon cancellation of an unanswered request
MUST be described. Note that, since non-INVITE requests are
generally answered immediately, cancellation ususally serves
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 INVITEis only same as for BYE. The delayed response feature of INVITEis 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.9 Additional Considerations for New Headers or Header Parameters 4.10 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 4.1 for a discussion of the backwards compatibility. See Section 4.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 cannot change the basic semantic and processing rules of a header cannot change the basic semantic and processing rules of a
method. There is no shortage of method names, so when an extension method. There is no shortage of method names, so when an extension
changes the basic meaning of a request, a new method SHOULD be changes the basic meaning of a request, a new method SHOULD be
defined. defined.
4.10 Additional Considerations for New Body Types Specifications that define new headers MUST include a table with
identical columns to that of Table 2 of RFC BBBB [2] with a row for
each new header. Furthermore, the table MUST include a column for any
methods defined in any other standards track extensions that have
reached RFC status.
4.11 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 unless end-to-end congestion
SHOULD be included indirectly through an http URL. controlled transport can be guaranteed. If at all possible, the
content SHOULD be included indirectly through an URI even if
congestion controlled transports are available.
Note that the presence of a body MUST NOT change the nature of the Note that the presence of a body MUST NOT change the nature of the
message. That is, bodies cannot alter the state machinery associated message. That is, bodies cannot alter the state machinery associated
with processing a request of a particular method or a response. with processing a request of a particular method or a response.
Bodies enhance this processing by providing additional data. Bodies enhance this processing by providing additional data.
5 Interactions with SIP Features 5 Interactions with SIP Features
We have observed that certain capabilities of SIP continually We have observed that certain capabilities of SIP continually
interact with extensions in unusual ways. Writers of extensions interact with extensions in unusual ways. Writers of extensions
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
presence is neccesitated as a result of forking. They are
an unfortunate exception to many SIP processing rules.
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. Extensions which defined new headers in cancellation, as described above. Extensions which defined
INVITErequests SHOULD consider whether they also need to be new headers in INVITE requests SHOULD consider whether they
included in ACK. also need to be included in ACK.
Routing: The Route, Record-Route and Via headers are used to Routing: The presence of Route headers in a request can cause it
support message routing. New request methods SHOULD to be sent through intermediate proxies. Requests that
carefully consider how these headers are used. establish dialogs can be record-routed, so that the initial
request goes through one set of proxies, and subsequent
requests through a different set. These SIP 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 Changes since -03 7 IANA Considerations
o Recommend that short form headers are used only for headers
that are expected to be heavily used.
o Inclusion of text extracted from bis which specifies extension
behavior.
o Partial alignment with bis.
8 Changes since -02
o Rewrote introduction to discuss draft-tsvarea-sipchange
9 Changes since -01
o Return to rfc2119 strength wording. There are no IANA considerations associated with this specification.
10 Authors Addresses 8 Authors Addresses
Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue East Hanover, NJ Jonathan Rosenberg
07936 email: jdrosen@dynamicsoft.com dynamicsoft
72 Eagle Rock Avenue
East Hanover, NJ 07936
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
11 Normative References 9 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," Request for Comments 2119, Internet Engineering Task Force, levels," RFC 2119, Internet Engineering Task Force, Mar. 1997.
Mar. 1997.
[2] J. Rosenberg, H. Schulzrinne, et al. , "SIP: Session initiation [2] J. Rosenberg, H. Schulzrinne, et al. , "SIP: Session initiation
protocol," Internet Draft, Internet Engineering Task Force, Feb. protocol," Internet Draft, Internet Engineering Task Force, Feb.
2002. Work in progress. 2002. Work in progress.
[3] H. Alvestrand, "IETF policy on character sets and languages," [3] D. Crocker, Ed., and P. Overell, "Augmented BNF for syntax
Request for Comments 2277, Internet Engineering Task Force, Jan. specifications: ABNF," RFC 2234, Internet Engineering Task Force,
1998. Nov. 1997.
[4] R. Hinden, B. Carpenter, and L. Masinter, "Format for literal [4] H. Alvestrand, "IETF policy on character sets and languages," RFC
IPv6 addresses in URL's," Request for Comments 2732, Internet 2277, Internet Engineering Task Force, Jan. 1998.
Engineering Task Force, Dec. 1999.
[5] J. Rosenberg and H. Schulzrinne, "An offer/answer model with [5] R. Hinden, B. Carpenter, and L. Masinter, "Format for literal
IPv6 addresses in URL's," RFC 2732, Internet Engineering Task Force,
Dec. 1999.
[6] J. Rosenberg and H. Schulzrinne, "An offer/answer model with
SDP," Internet Draft, Internet Engineering Task Force, Feb. 2002. SDP," Internet Draft, Internet Engineering Task Force, Feb. 2002.
Work in progress. Work in progress.
12 Informative References 10 Informative References
[6] S. Bradner, R. Mahy, A. Mankin, et al. , "SIP change process," [7] S. Bradner, R. Mahy, A. Mankin, et al. , "SIP change process,"
Internet Draft, Internet Engineering Task Force, Nov. 2001. Work in Internet Draft, Internet Engineering Task Force, Mar. 2002. Work in
progress. progress.
[7] R. Droms, "Dynamic host configuration protocol," Request for [8] R. Droms, "Dynamic host configuration protocol," RFC 2131,
Comments 2131, Internet Engineering Task Force, Mar. 1997. Internet Engineering Task Force, Mar. 1997.
[8] S. Donovan and J. Rosenberg, "SIP session timer," Internet Draft, [9] S. Donovan and J. Rosenberg, "SIP session timer," Internet Draft,
Internet Engineering Task Force, Oct. 2001. Work in progress. Internet Engineering Task Force, Oct. 2001. Work in progress.
[9] A. Shacham, R. Monsour, R. Pereira, and M. Thomas, "IP payload [10] A. Shacham, R. Monsour, R. Pereira, and M. Thomas, "IP payload
compression protocol (ipcomp)," Request for Comments 2393, Internet compression protocol (ipcomp)," RFC 2393, Internet Engineering Task
Engineering Task Force, Dec. 1998. Force, Dec. 1998.
[10] A. Johnston, S. Donovan, R. Sparks, C. Cunningham, D. Willis, J. [11] R. Price, H. Hannu, et al. , "Signaling compression," Internet
Draft, Internet Engineering Task Force, May 2002. Work in progress.
[12] A. Johnston, S. Donovan, R. Sparks, C. Cunningham, D. Willis, J.
Rosenberg, K. Summers, and H. Schulzrinne, "SIP telephony call flow Rosenberg, K. Summers, and H. Schulzrinne, "SIP telephony call flow
examples," Internet Draft, Internet Engineering Task Force, Apr. examples," Internet Draft, Internet Engineering Task Force, Apr.
2001. Work in progress. 2001. 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
 End of changes. 

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