Request for Comments: 4485 Cisco Systems
Category: Informational H. Schulzrinne
Columbia University
May 2006
Guidelines for Authors of Extensions to
the Session Initiation Protocol (SIP)
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The Session Initiation Protocol (SIP) is a flexible yet simple tool
for establishing interactive communications sessions across the
Internet. Part of this flexibility is the ease with which it can be
extended. In order to facilitate effective and interoperable
extensions to SIP, some guidelines need to be followed when
developing SIP extensions. This document outlines a set of such
guidelines for authors of SIP extensions.
Table of Contents
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Should I Define a SIP Extension? ................................3
3.1. SIP’s Solution Space .......................................4
3.2. SIP Architectural Model ....................................5
4. Issues to Be Addressed ..........................................7
4.1. Backwards Compatibility ....................................7
4.2. Security ..................................................10
4.3. Terminology ...............................................10
4.4. Syntactic Issues ..........................................10
4.5. Semantics, Semantics, Semantics ...........................13
4.6. Examples Section ..........................................14
4.7. Overview Section ..........................................14
4.8. IANA Considerations Section ...............................14
4.9. Document-Naming Conventions ...............................16
4.10. Additional Considerations for New Methods ................16
4.11. Additional Considerations for New Header Fields
or Header Field ..........................................17
4.12. Additional Considerations for New Body Types .............18
5. Interactions with SIP Features .................................18
6. Security Considerations ........................................19
7. Acknowledgements ...............................................19
8. References .....................................................19
8.1. Normative References ......................................19
8.2. Informative References ....................................20
1. Introduction
The Session Initiation Protocol (SIP) [2] is a flexible yet simple
tool for establishing interactive communications sessions across the
Internet. Part of this flexibility is the ease with which it can be
extended (with new methods, new header fields, new body types, and
new parameters), and there have been countless proposals that have
been made to do just that. An IETF process has been put into place
that defines how extensions are to be made to the SIP protocol [10].
That process is designed to ensure that extensions are made that are
appropriate for SIP (as opposed to being done in some other
protocol), that these extensions fit within the model and framework
provided by SIP and are consistent with its operation, and that these
extensions solve problems generically rather than for a specific use
case. However, [10] does not provide the technical guidelines needed
to assist that process. This specification helps to meet that need.
This specification first provides a set of guidelines to help decide
whether a certain piece of functionality is appropriately done in
SIP. Assuming the functionality is appropriate, it then points out
issues that extensions should deal with from within their
specification. Finally, it discusses common interactions with
existing SIP features that often cause difficulties in extensions.
2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and
indicate requirement levels for compliant implementations.
3. Should I Define a SIP Extension?
The first question to be addressed when defining a SIP extension is
whether a SIP extension is the best solution to the problem. SIP has
been proposed as a solution for numerous problems, including
mobility, configuration and management, QoS control, call control,
caller preferences, device control, third-party call control, and
MPLS path setup, to name a few. Clearly, not every problem can be
solved by a SIP extension. More importantly, some problems that
could be solved by a SIP extension probably shouldn’t.
To assist engineers in determining whether a SIP extension is an
appropriate solution to their problem, we present two broad criteria.
First, the problem SHOULD fit into the general purview of SIP’s
solution space. Secondly, the solution MUST conform to the general
SIP architectural model.
Although the first criteria might seem obvious, we have observed that
numerous extensions to SIP have been proposed because some function
is needed in a device that also speaks SIP. The argument is
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
obtain their IP address. This is generally done through DHCP [11].
SIP’s multicast registration mechanisms might supply an alternate way
to obtain an IP address. This would eliminate the need for DHCP in
clients. However, we do not believe such extensions are appropriate.
We believe that protocols should be defined to provide specific,
narrow functions, rather than be defined for all protocols needed
between a pair of devices. The former approach to protocol design
yields modular protocols with broad application. It also facilitates
extensibility and growth; single protocols can be removed and changed
without affecting the entire system. We observe that this approach
to protocol engineering mirrors object-oriented software engineering.
Our second criteria, that the extension must conform to the general
SIP architectural model, ensures that the protocol remains manageable
and broadly applicable.
3.1. SIP’s Solution Space
In order to evaluate the first criteria, it is necessary to define
exactly what SIP’s solution space is, and what it is not.
SIP is a protocol for initiating, modifying, and terminating
interactive sessions. This process involves the discovery of users,
(or, more generally, entities that can be communicated with,
including services, such as voicemail or translation devices)
wherever they may be located, so that a description of the session
can be delivered to the user. It is assumed that these users or
communications entities are mobile, and that their point of
attachment to the network changes over time. The primary purpose of
SIP is a rendezvous function, to allow a request initiator to deliver
a message to a recipient wherever they may be. Such a rendezvous is
needed to establish a session, but it can be used for other purposes
related to communications, such as querying for capabilities or
delivery of an instant message.
Much of SIP focuses on this discovery and rendezvous component. Its
ability to fork, its registration capabilities, and its routing
capabilities are all present for the singular purpose of finding the
desired user wherever they may be. As such, features and
capabilities such as personal mobility, automatic call distribution,
and follow-me are well within the SIP solution space.
Session initiation also depends on the ability of the called party to
have enough information about the session itself to make a decision
on whether to join. That information includes data about the caller,
the purpose for the invitation, and parameters of the session itself.
For this reason, SIP includes this kind of information.
Part of the process of session initiation is the communication of
progress and the final results of establishment of the session. SIP
provides this information as well.
SIP itself is independent of the session, and the session description
is delivered as an opaque body within SIP messages. Keeping SIP
independent of the sessions it initiates and terminates is
fundamental. As such, there are many functions that SIP explicitly
does not provide. It is not a session management protocol or a
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
fundamentally because (1) SIP is independent of the underlying
session it establishes, and (2) the path of SIP messages is
completely independent from the path that session packets may take.
The path independence refers to paths within a provider’s network and
the set of providers itself. For example, it is perfectly reasonable
for a SIP message to traverse a completely different set of
autonomous systems than the audio in a session SIP establishes.
SIP is not a general purpose transfer protocol. It is not meant to
send large amounts of data unrelated to SIP’s operation. It is not
meant as a replacement for HTTP. This is not to say that carrying
payloads in SIP messages is never a good thing; in many cases, the
data is very much related to SIP’s operation. In those cases,
congestion-controlled transports end-to-end are critical.
SIP is not meant to be a general Remote Procedure Call (RPC)
mechanism. None of its user discovery and registration capabilities
are needed for RPC, and neither are most of its proxy functions.
SIP is not meant to be used as a strict Public Switched Telephone
Network (PSTN) signaling replacement. It is not a superset of the
Integrated Services Digital Network (ISDN) User Part (ISUP).
Although 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
entity to tell another to pick up or answer a phone, to send audio
using a particular codec, or to provide a new value for a
configuration parameter. Control protocols have different trust
relationships from that assumed in SIP and are more centralized in
architecture than SIP is, as SIP is a very 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 build 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
that are also needed by many other application layer protocols SHOULD
NOT be addressed within SIP.
3.2. SIP Architectural Model
We describe here some of the primary architectural assumptions that
underlie SIP. Extensions that violate these assumptions should be
examined more carefully to determine their appropriateness for SIP.
Session independence: SIP is independent of the session it
establishes. This includes the type of session, be it audio,
video, game, chat session, or virtual reality. SIP operation
SHOULD NOT depend on some characteristic of the session. SIP is
not specific to voice only. Any extensions to SIP MUST consider
the application of SIP to a variety of different session types.
SIP and Session path independence: We have already touched on this
once, but it is worth noting again. The set of routers, networks,
and/or autonomous systems traversed by SIP messages are unrelated
to the set of routers, networks, and/or autonomous systems
traversed by session packets. They may be the same in some cases,
but it is fundamental to SIP’s architecture that they need not be
the same. Standards-track extensions MUST NOT be defined that
work only when the signaling and session paths are coupled. Non-
standard P-header extensions [10] are required for any extension
that only works in such a case.
Multi-provider and multi-hop: SIP assumes that its messages will
traverse the Internet. That is, SIP works through multiple
networks administered by different providers. It is also assumed
that SIP messages traverse many hops (where each hop is a proxy).
Extensions MUST NOT work only under the assumption of a single hop
or specialized network topology. They SHOULD avoid the assumption
of a single SIP provider (but see the use of P-Headers, per RFC
3427 [10]).
Transactional: SIP is a request/response protocol, possibly enhanced
with intermediate responses. Many of the rules of operation in
SIP are based on general processing of requests and responses.
This includes the reliability mechanisms, routing mechanisms, and
state maintenance rules. Extensions SHOULD NOT add messages that
are not within the request-response model.
Proxies can ignore bodies: In order for proxies to scale well, they
must be able to operate with minimal message processing. SIP has
been engineered so that proxies can always ignore bodies.
Extensions SHOULD NOT require proxies to examine bodies.
Proxies don’t need to understand the method: Processing of requests
in proxies does not depend on the method, except for the well-
known methods INVITE, ACK, and CANCEL. This allows for
extensibility. Extensions MUST NOT define new methods that must
be understood by proxies.
INVITE messages carry full state: An initial INVITE message for a
session is nearly identical (the exception is the tag) to a re-
INVITE message to modify some characteristic of the session. This
full state property is fundamental to SIP and is critical for
robustness of SIP systems. Extensions SHOULD NOT modify INVITE
processing such that data spanning multiple INVITEs must be
collected in order to perform some feature.
Generality over efficiency: Wherever possible, SIP has favored
general-purpose components rather than narrow ones. If some
capability is added to support one service but a slightly broader
capability can support a larger variety of services (at the cost
of complexity or message sizes), the broader capability SHOULD be
preferred.
The Request URI is the primary key for forwarding: Forwarding logic
at SIP servers depends primarily on the request URI (this is
different from request routing in SIP, which uses the Route header
fields to pass a request through intermediate proxies). 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 SHOULD NOT modify the semantics of the
request URI.
Heterogeneity is the norm: SIP supports heterogeneous devices. It
has built-in mechanisms for determining the set of overlapping
protocol functionalities. Extensions SHOULD NOT be defined that
only function if all devices support the extension.
4. Issues to Be Addressed
Given an extension has met the litmus tests in the previous section,
there are several issues that all extensions should take into
consideration.
4.1. Backward Compatibility
One of the most important issues to consider is whether the new
extension is backward compatible with baseline SIP. This is tightly
coupled with how the Require, Proxy-Require, and Supported header
fields are used.
If an extension consists of new header fields or header field
parameters inserted by a user agent in a request with an existing
method, and the request cannot be processed reasonably by a proxy
and/or user agent without understanding the header fields or
parameters, the extension MUST mandate the usage of the Require
and/or Proxy-Require header fields in the request. These extensions
are not backwards compatible with SIP. The result of mandating usage
of these header fields means that requests cannot be serviced unless
the entities being communicated with also understand the extension.
If some entity does not understand the extension, the request will be
rejected. The UAC can then handle this in one of two ways. In the
first, the request simply fails, and the service cannot be provided.
This is basically an interoperability failure. In the second case,
the UAC retries the request without the extension. This will
preserve interoperability, at the cost of a "dual stack"
implementation in a UAC (processing rules for operation with and
without the extension). As the number of extensions increases, this
leads to an exponential explosion in the sets of processing rules a
UAC may need to implement. The result is excessive complexity.
Because of the possibility of interoperability and complexity
problems that result from the usage of Require and Proxy-Require, we
believe the following guidelines are appropriate:
o The usage of these header fields in requests for basic SIP
services (in particular, session initiation and termination) is
NOT RECOMMENDED. The less frequently a particular extension is
needed in a request, the more reasonable it is to use these header
fields.
o The Proxy-Require header field SHOULD be avoided at all costs.
The failure likelihood in an individual proxy stays constant, but
the path failure grows exponentially with the number of hops. On
the other hand, the Require header field only mandates that a
single entity, the UAS, support the extension. Usage of
Proxy-Require is thus considered exponentially worse than usage of
the Require header field.
o If either Require or Proxy-Require are used by an extension, the
extension SHOULD discuss how to fall back to baseline SIP
operation if the request is rejected with a 420 response.
Extensions that define new methods do not need to use the Require
header field. SIP defines mechanisms that allow a UAC to know
whether a new method is understood by a UAS. This includes both the
OPTIONS request and the 405 (Method Not Allowed) response with the
Allow header field. It is fundamental to SIP that proxies need not
understand the semantics of a new method in order to process it. If
an extension defines a new method that must be understood by proxies
in order to be processed, a Proxy-Require header field is needed. As
discussed above, these kinds of extensions are frowned upon.
In order to achieve backwards compatibility for extensions that
define new methods, the Allow header field is used. There are two
types of new methods - those that are used for established dialogs
(initiated 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 Allow header field, a UA can readily determine whether the
new method can be supported within the dialog. For example, once an
INVITE dialog is established, a user agent could determine whether
the REFER method [12] is supported if it is present in an Allow
header field. If it wasn’t, the "transfer" button on the UI could be
"greyed out" once the call is established.
Another type of extension is that which requires a proxy to insert
header fields or header field parameters into a request as it
traverses the network, or for the UAS to insert header fields or
header field parameters into a response. For some extensions, if the
UAC or UAS does not understand these header fields, the message can
still be processed correctly. These extensions are completely
backwards compatible.
Most other extensions of this type require that the server only
insert the header field or parameter if it is sure the client
understands it. In this case, these extensions will need to make use
of the Supported request header field mechanism. This mechanism
allows a server to determine if the client can understand some
extension, so that it can apply the extension to the response. By
their nature, these extensions may not always be able to be applied
to every response.
If an extension requires a proxy to insert a header field or
parameter into a request and this header field or parameter needs to
be understood by both UAC and UAS to be executed correctly, a
combination of the Require and the Supported mechanism will need to
be used. The proxy can insert a Require header field into the
request if the Supported header field is present. An example of such
an extension is the SIP Session Timer [13].
Yet another type of extension is that which defines new body types to
be carried in SIP messages. According to the SIP specification,
bodies must be understood by user agents in order to process a
request. As such, the interoperability issues are similar to new
methods. However, the Content-Disposition header field has been
defined to allow a client or server to indicate that the message body
is optional [2]. Extensions that define or require new body types
SHOULD make them optional for the user agent to process.
When a body must be understood to properly process a request or
response, it is preferred that the sending entity know ahead of time
whether the new body is understood by the recipient. For requests
that establish a dialog, 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.
4.2. Security
Security is an important component of any protocol. Designers of SIP
extensions need to carefully consider if additional security
requirements are required over those described in RFC 3261.
Frequently, authorization requirements and requirements for end-to-
end integrity are the most overlooked.
SIP extensions MUST consider how (or if) they affect usage of the
general SIP security mechanisms. Most extensions should not require
any new security capabilities beyond general-purpose SIP. If they
do, it is likely that the security mechanism has more general-purpose
application and should be considered an extension in its own right.
Overall system security requires that both the SIP signaling and the
media sessions it established be secured. The media sessions
normally use their own security techniques, which are quite distinct
from those used by SIP itself. Extensions should take care not to
conflate the two. However, specifications that define extensions
that impact the media sessions in any way SHOULD consider the
interactions between SIP and session security mechanisms.
4.3. Terminology
RFC 3261 has an extensive terminology section that defines terms such
as caller, callee, user agent, and header field. All SIP extensions
MUST conform to this terminology. They MUST NOT define new terms
that describe concepts already defined by a term in another SIP
specification. If new terminology is needed, it SHOULD appear in a
separate section towards the beginning of the document.