Internet Engineering Task Force                                   SIP WG
Internet Draft                                              J. Rosenberg
                                                          H. Schulzrinne
                                                             Columbia U.
March 1,
June 6, 2002
Expires: September December 2002

Guidelines for Authors of SIP Extensions to the Session Initiation Protocol (SIP


   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress".

   The list of current Internet-Drafts can be accessed at

   To view the list Internet-Draft Shadow Directories, see


   The Session Initiation Protocol (SIP) is a flexible, yet simple tool
   for establishing interactive connections 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

                           Table of Contents

   1          Terminology .........................................    3
   2          Introduction ........................................    3
   3          Should I define a SIP Extension?  ...................    3
   3.1        SIP's Solution Space ................................    4
   3.2        SIP Architectural Model .............................    6
   4          Issues to be Addressed ..............................    8
   4.1        Backwards Compatibility .............................    8
   4.2        Security ............................................   10
   4.3        Usage Guidelines ....................................   11   10
   4.4        Syntactic Issues ....................................   11   10
   4.5        Semantics, Semantics, Semantics .....................   12
   4.6        Examples Section ....................................   13
   4.7        Overview Section ....................................   13
   4.8        Document Naming Conventions .........................   13
   4.9        Additional Considerations for New Methods ...........   13
   4.9   14
   4.10       Additional Considerations for New Headers or
   Header Parameters ..............................................   14
   4.10   15
   4.11       Additional Considerations for New Body Types ........   15
   5          Interactions with SIP Features ......................   15   16
   6          Security Considerations .............................   16
   7          Changes since -03 ...................................          IANA Considerations .................................   16
   8          Changes since -02 ...................................   16
   9          Changes since -01 ...................................   16
   10          Authors Addresses ...................................   16
   11   17
   9          Normative References ................................   17
   10         Informative References ..............................   17

1 Terminology

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and
   indicate requirement levels for compliant SIP guidelines

2 Introduction

   The Session Initiation Protocol (SIP) [2] is a flexible, yet simple
   tool for establishing interactive connections across the Internet.
   Part of this flexibility is the ease with which it can be extended
   (with new methods, new headers, 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 which defines how
   extensions are to be made to the SIP protocol [6]. [7]. That process is
   designed to ensure that extensions are made which 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, SIP and are
   consistent with its operation, and that these extensions solve
   problems generically rather than for a specific use case. However,
   [7] does not provide the technical guidelines needed to assist that
   process. This draft helps to meet that need.

   This draft 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
   which extensions should deal with from within their specification.
   Finally, it discusses common interactions with existing SIP features
   which often cause difficulties in extensions.

3 Should I define a SIP Extension?

   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
   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 purvey of SIPs
   solution space. Secondly, the solution MUST conform to the general
   SIP architectural model.

   While 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 which 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 [7]. [8].
   SIPs 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 being defined based on all
   communications requirements between a pair of devices. The latter
   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 SIPs 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 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
   be. Such rendezvous is needed to establish a session, but 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 in order to make a
   decision on whether to join or not. 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

   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 packets for a session packets may take.
   The path independence refers to paths within a providers 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 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

   The only exception to this rule is REGISTER, which is, in many ways,
   its own protocol within SIP. REGISTER is ideally suited for
   configuration and exchange of application layer data between a user
   agent and its proxy. This may entail exchange of modest amounts of
   data. Because of the infrequency of such exchanges and their
   limitation in extent (i.e., usually not multi-hop), it is appropriate
   to transfer larger amounts of content in REGISTER. In such those cases, TCP
   is preferred.
   congestion controlled transports end-to-end are critical.

   SIP is not meant to be a general RPC mechanism. None of its user
   discovery and registration capabilities are needed for RPC, neither
   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

   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
   entity to tell another to pick up or answer a phone, send audio using
   a particular codec, or change a configuration parameter. Control
   protocols have different trust relationships than is assumed in SIP,
   and are more centralized in architecture than SIP, which 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 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.

3.2 SIP Architectural Model

   We describe here some of the primary architectual assumptions which
   underly SIP. Extensions which 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 be dependent on some characteristic of
             the session. SIP is not specific to VoIP 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
             and/or networks and/or autonomous systems traversed by SIP
             messages and the packets in are unrelated to the set of routers and/or
             networks and/or autonomous systems traversed by session are unrelated.
             packets. They may be the same in some cases, but it is
             fundamental to SIPs architecture that they need not be the
             same. Extensions which only work under some assumption of
             overlap are not generally applicable to SIPs operation and
             should be scrutinized carefully.

        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 SHOULD NOT work only under the
             assumption of a single hop or single provider.

        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 which 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 soft-state 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

        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 routing: forwarding: Forwarding
             logic at SIP servers depends primarily on the request URI. URI
             (this is different from request routing in SIP, which uses
             the Route headers 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 use other components of the SIP message as the
             primary routing forwarding key, and SHOULD NOT modify the semantics
             of the request URI.

        Proxies can operate statelessly:

        Heterogeneity is the norm: SIP allows for great
             flexibility supports hetereogeneous devices.
             It has built in mechanisms for determining the design set 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 SHOULD NOT be
             defined which operate only with stateful proxies.

        Heterogeneity is the norm: SIP supports hetereogeneous devices.
             It has built in mechanisms for determining the set of
             overlapping protocol functionalities. Extensions
             overlapping protocol functionalities. Extensions SHOULD NOT
             be defined which only function if all devices support the

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

4.1 Backwards Compatibility

   One of the most important issues to consider is whether the new
   extension is backwards compatible with baseline SIP. This is tightly
   coupled with how the Require, Proxy-Require, and Supported headers
   are used.

   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
   reasonably by a proxy and/or user agent without understanding the
   headers, the extension MUST mandate the usage of the Require and/or
   Proxy-Require headers in the request. These extensions are not
   backwards compatible with SIP. The result of mandating usage of these
   headers 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 headers 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

        o The Proxy-Require header SHOULD be avoided at all costs. The
          failure likelihood in an individual proxy stays constant, but
          the path failure grows exponentially with the number of hops.

          On the other hand, the Require header only mandates that a
          single entity, the UAS, support the extension. Usage of
          Proxy-Require is thus considered exponentially worse than
          usage of the Require header.

        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 which define new methods do not need to use the Require
   header. SIP defines mechanisms which allow a UAC to know whether a
   new method is understood by a UAS. This includes both the
   request, and the 405 (Method Not Allowed) response with the Allow
   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
   an extension defines a new method which must be understood by proxies
   in order to be processed, a Proxy-Require header 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 is used. There are two types of
   new methods - those that are used for established sessions dialogs (initiated
   by INVITE, for example), and those that are sent as the initial
   request to a UA. Since INVITEand INVITE and its response both SHOULD contain an
   Allow header, a UA can readily determine whether the new method can
   be supported within the call. dialog. For example, if a new method for a
   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
   new method were not listed in the Allow header.

   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
   insert headers into a response. For some extensions, if the UAC or
   UAS does not understand these headers, the message can still be
   processed correctly. These extensions are completely backwards

   Most other extensions of this type require that the server only
   insert the header if it is sure the client understands it. In this
   case, these extensions will need to make use of the Supported request
   header 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 into a request,
   and this header 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
   into the request, given the Supported header is present. An example
   of such an extension is the SIP Session Timer [8]. [9].

   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 in order to process a request. As such, the
   interoperability issues are similar to new methods. However, a new
   header, Content-Disposition, the
   Content-Disposition header has been defined that allows to allow a client or
   server to indicate that the message body is optional [2]. Usage of
   optional bodies, as opposed to mandatory ones, is RECOMMENDED
   wherever possible.

   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 are the first in establish a sequence of exchanges between user agents
   (such as INVITE), 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. SIP extensions
   SHOULD 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.

4.3 Usage Guidelines

   All SIP extensions must contain guidelines defining when the
   extension is to be used.

   For extensions that define new headers, the extension MUST define the
   request methods the 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 Table 4 of RFC BBBB [2]. The extension SHOULD specify
   which entities (UAC, UAS, proxy, redirect, registrar) are allowed to
   insert the header.

4.4 Syntactic Issues

   Extensions that define new methods SHOULD use all capitals for the
   method name. Method names SHOULD be less than 10 characters, and
   SHOULD attempt to convey the general meaning of the request.

   Extensions that define new headers that are anticipated to be heavily
   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 are exhausted, new compact forms will no longer be
   defined. Header names SHOULD use ASCII characters. Header names are
   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
   confusion. SIP extensions MUST clearly indicate the case sensitivity
   or insensitivity of every parameter, value or field they define. In
   general, case sensitivity
   However, it is preferred because of RECOMMENDED that these extensions be consistent with
   baseline SIP, which uses case insensitive parameters, consistent with
   the reduced
   processing requirements. grammar constructs of RFC 2234 [3].

   Extensions which contain freeform text MUST allow that text to be
   UTF-8, as per the IETF policies on character set usage [3]. [4]. This
   ensures that SIP remains an internationalized standard. As a general
   guideline, freeform text is never needed by programs in order to
   perform protocol processing. It is usually entered by and displayed
   to the user. If an extension uses a parameter which can contain UTF-8
   encoded characters, and that extension requires a comparison to be
   made of this parameter to other parameters, the comparison SHOULD MUST be
   case sensitive. Case insensitive comparison rules for UTF-8 text are
   extremely complicated and are to be avoided.

   Extensions which make use of dates and times MUST use the SIP-Date BNF defined
   in RFC BBBB. 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
   quad IPv4 addresses, IPv6 addresses in the format described in [4], [5],
   and domain names.

   Extensions which have headers containing URLs URIs SHOULD allow any URI,
   not just SIP URLs. URIs.

   Headers SHOULD follow the standard formatting for SIP, defined as:

   header          = header-name HCOLON header-value
                      *(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 ":" # (value *( ";" parameter-name ["=" token] ) |
      ";" parameter-name ["=" quoted-string] )) HCOLON [TEXT-UTF8-TRIM]

   Developers of extensions SHOULD allow for extension parameters in
   their headers.

   Headers that contain a list of URIs SHOULD follow the same syntax as
   the Contact header in SIP. Implementors are also encouraged to always
   wrap these URI in angle brackets "<" and ">". We have found this to
   be a frequently misimplemented feature.

   Beyond compact form, there is no need to define compressed versions
   of header values. Compression of SIP messages SHOULD be handled at
   lower layers, for example, using IP payload compression [9] [10] or link
   layer compression.
   signalling compression [11].

   Syntax for headers is expressed in Augmented Backus-Naur Form. Form and
   MUST follow the format of RFC 2234 [3]. Extensions MUST make use of
   the primitive components defined in RFC BBBB [2]. 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 explicit linear white
   space. Linear white space, for better or worse, allows for line
   folding. Extensions cannot SHOULD NOT define new headers that use alternate
   linear white space rules.

4.5 Semantics, Semantics, Semantics

   Developers of protocols often get caught up in syntax issues, without
   spending enough time on semantics. The semantics of a protocol are
   far more important. SIP extensions MUST clearly define the semantics
   of the extensions. Specifically, the extension MUST specify the
   behaviors expected of a UAC, UAS and proxy in processing the
   extension. This is often best described by having separate sections
   for each of these three elements. Each section SHOULD step through
   the processing rules in temporal order of the most common messaging

   Processing rules generally specify actions to take (in terms of
   messages to send, variables to store, rules to follow) on receipt of
   messages and expiration of timers. If an action requires transmission
   of a message, the rule SHOULD outline requirements for insertion of
   headers or other information in the message.

   The extension SHOULD specify procedures to take in exceptional
   conditions. This usually includes receipt of messages that
   conditions which are not
   expected, expiration of timers that handle timeouts, and presence recoverable, or which require some kind of
   headers in messages when they are user
   intervention. Recovering from unrecoverable problems generally does
   not expected. require specification.

4.6 Examples Section

   Presence of sections in the extension giving examples

   The specification SHOULD contain a section that gives examples of
   call flows and message formatting is RECOMMENDED. formatting. Extensions which define
   substantial new syntax SHOULD include examples of messages containing
   that syntax. Examples of message flows should be given to cover
   common cases and at least one failure or unusual case.

   For an example of how to construct a good examples section, see the
   message flows and message formatting defined in the Call Flows
   Example specification [10]. [12]. Note that complete messages SHOULD be
   used. Be careful to include tags, Via headers, headers (with the branch ID
   cookie), Max-Forwards, Content-Lengths, Record-Route and Route

4.7 Overview Section

   Too often, extension documents dive into detailed syntax and
   semantics without giving a general overview of operation. This makes
   understanding of the extension harder. It is RECOMMENDED that
   extensions have a protocol overview section which discusses the basic
   operation of the extension. Basic operation usually consists of the
   message flow, in temporal order, for the most common case covered by
   the extension. The most important processing rules for the elements
   in the call flow SHOULD be mentioned. Usage of the RFC 2119 [1]
   terminology in the overview section is RECOMMENDED. NOT RECOMMENDED, and the
   specification should explicitly state that the overview is tutorial
   in nature only.

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,
   and discuss, the following issues:

        o Can it contain bodies? If so, what is the meaning of the
          presence of those bodies? What body types are allowed?

        o Can a transaction with this request method occur while another
          transaction, in the same and/or reverse direction, is in

        o What headers are allowed in requests of this method? It is
          RECOMMENDED that this information be presented through a
          column of Table 4 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,
          within means that the request is sent with the same Call-ID,
          To and From field as an INVITEthat was sent dialog, or received
          previously. For, example, the REGISTERmethod is not associated
          with does it establish
          a call, whereas the BYE method is. dialog?

        o Extensions to SIP that define new methods MAY specify whether
          offers and answers can appear in requests of that method or
          its responses. However, those extensions MUST adhere to the
          protocol rules specified in [5], [6], and MUST adhere to the
          additional constraints for offers and answers as specified in
          SIP [2].

        o Because of the nature of reliability treatment of requests
          with new methods, those requests need to be answered
          immediately by the UAS. Protocol extensions that require
          longer durations for the generation of a response (such as a
          new method that does require human interaction) SHOULD instead
          use two transactions - one to send the request, and another in
          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
   same as for BYE. The delayed response feature of INVITEis INVITE is only
   available in INVITE, never for new methods. This means requests with
   new SIP methods need to be responded to within short time periods (on
   the order of seconds).


4.10 Additional Considerations for New Headers or Header Parameters

   The most important issue for extensions that define new headers is
   backwards compatibility. See Section 4.1 for a discussion of the
   issues. The extension MUST detail how backwards compatibility is

   It is often tempting to avoid creation of a new method by overloading
   an existing method through a header. Headers are not meant to
   fundamentally alter the meaning of the method of the request. A new
   header cannot change the basic semantic and processing rules of a
   method. There is no shortage of method names, so when an extension
   changes the basic meaning of a request, a new method SHOULD be


   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
   of large bodies are frowned upon. upon unless end-to-end congestion
   controlled transport can be guaranteed. If at all possible, the
   content SHOULD be included indirectly through an http URL. URI even if
   congestion controlled transports are available.

   Note that the presence of a body MUST NOT change the nature of the
   message. That is, bodies cannot alter the state machinery associated
   with processing a request of a particular method or a response.
   Bodies enhance this processing by providing additional data.

5 Interactions with SIP Features

   We have observed that certain capabilities of SIP continually
   interact with extensions in unusual ways. Writers of extensions
   SHOULD consider the interactions of their extensions with these SIP
   capabilities, document any unusual interactions if they exist. The
   most common causes of problems are:

        Forking: Forking by far presents the most troublesome
             interactions with extensions. This is generally because it
             can cause (1) a single transmitted request to be received
             by an unknown number of UASs, and (2) a single request to
             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
             that they are exceptions to many of the general request
             processing rules. The main reason for this special status
             is that CANCEL and ACK are always associated with another
             request. New methods SHOULD consider the meaning of
             cancellation, as described above. Extensions which defined
             new headers in
             INVITErequests INVITE requests SHOULD consider whether they
             also need to be included in ACK.

        Routing: The Route, Record-Route and Via presence of Route headers are used in a request can cause it
             support message routing. New be sent through intermediate proxies. Requests that
             establish dialogs can be record-routed, so that the initial
             request methods SHOULD
             carefully consider how these headers are used. 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
             proxies are unable to retransmit messages and cannot
             execute certain services. Extensions which depend on some
             kind of proxy processing SHOULD consider how stateless
             proxies affect that processing.

6 Security Considerations

   The nature of this document is such that it does not introduce any
   new security considerations.

7 Changes since -03

        o Recommend that short form headers are used only for headers
          that IANA Considerations

   There are expected to be heavily used.

        o Inclusion of text extracted from bis which specifies extension

        o Partial alignment no IANA considerations associated with bis. this specification.

8 Changes since -02

        o Rewrote introduction to discuss draft-tsvarea-sipchange

9 Changes since -01

        o Return to rfc2119 strength wording.

10 Authors Addresses

   Jonathan Rosenberg
   72 Eagle Rock Avenue
   East Hanover, NJ 07936

   Henning Schulzrinne
   Columbia University
   M/S 0401
   1214 Amsterdam Ave.
   New York, NY 10027-7003


9 Normative References

   [1] S. Bradner, "Key words for use in RFCs to indicate requirement
   levels," Request for Comments RFC 2119, Internet Engineering Task Force, Mar. 1997.

   [2] J. Rosenberg, H. Schulzrinne, et al.  , "SIP: Session initiation
   protocol," Internet Draft, Internet Engineering Task Force, Feb.
   2002.  Work in progress.

   [3] D. Crocker, Ed., and P. Overell, "Augmented BNF for syntax
   specifications:  ABNF," RFC 2234, Internet Engineering Task Force,
   Nov. 1997.

   [4] H. Alvestrand, "IETF policy on character sets and languages,"
   Request for Comments RFC
   2277, Internet Engineering Task Force, Jan. 1998.


   [5] R. Hinden, B. Carpenter, and L. Masinter, "Format for literal
   IPv6 addresses in URL's," Request for Comments 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.
   Work in progress.


10 Informative References


   [7] S. Bradner, R. Mahy, A. Mankin, et al.  , "SIP change process,"
   Internet Draft, Internet Engineering Task Force, Nov. 2001. Mar. 2002.  Work in


   [8] R. Droms, "Dynamic host configuration protocol," Request for
   Comments RFC 2131,
   Internet Engineering Task Force, Mar. 1997.


   [9] S. Donovan and J. Rosenberg, "SIP session timer," Internet Draft,
   Internet Engineering Task Force, Oct. 2001.  Work in progress.


   [10] A. Shacham, R. Monsour, R. Pereira, and M. Thomas, "IP payload
   compression protocol (ipcomp)," Request for Comments RFC 2393, Internet Engineering Task
   Force, Dec. 1998.


   [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
   examples," Internet Draft, Internet Engineering Task Force, Apr.
   2001.  Work in progress.

   Full Copyright Statement

   Copyright (c) The Internet Society (2002). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an