RFC 4485

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

📅 published May 2006, from ietf

🎀 RFC 4485: Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP) 💖

Group: Network Working Group 🌸 Authors: J. Rosenberg (Cisco Systems) and H. Schulzrinne (Columbia University) 👯‍♀️ Category: Informational 💜 (it's shared info for the community, not an Internet standard) Date: May 2006 📅 Obsoletes / Updates: nothing listed in the title block 🦋

Status of This Memo ✨

okay so first things first 🙈 this memo just gives info to the Internet community. it doesn't specify an Internet standard of any kind. distribution is unlimited, so share it with everyone 💅

Copyright (C) The Internet Society (2006). 📝

Abstract 🧚

SIP (the Session Initiation Protocol) is a flexible yet simple tool for setting up interactive communications sessions across the Internet 📞 and part of why it's so cute is how easy it is to extend. so to keep extensions effective and interoperable, there are some guidelines you need to follow when building them. this doc lays out a set of those 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 🦋

okay bestie, SIP [2] is a flexible yet simple tool for setting up interactive communications sessions across the Internet 📞 and the flexibility is giving: you can extend it with new methods, new header fields, new body types, and new parameters. so naturally people have come up with SO many proposals to do exactly that 😭 there's an IETF process for how extensions get made to SIP [10], and it's designed to make sure extensions are actually right for SIP (not something that belongs in some other protocol 🙅‍♀️), that they fit SIP's model and framework and keep working the way SIP works, and that they solve problems in a generic way instead of just for one specific use case 💜

BUT, and this is the tea ☕, [10] doesn't give the technical guidelines needed to help that process along. that's the gap this spec fills 🎀

so here's the plan ✨ first, it gives you guidelines to help decide whether a piece of functionality even belongs in SIP. if it does, it points out the issues your extension should deal with inside its own spec. and last, it talks about common interactions with existing SIP features that tend to cause trouble for 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 🔥 these ones are the official vibe-check words, so pay attention to them!!

3. Should I Define a SIP Extension? 🧚‍♀️

the very first question when you're defining a SIP extension is whether a SIP extension is even the best solution to your problem 🤔 SIP has been pitched as the answer to a bunch of problems: mobility, configuration and management, QoS control, call control, caller preferences, device control, third-party call control, and MPLS path setup, to name a few 🌈 and honestly? not every problem can be solved by a SIP extension. even worse, some problems that could be solved by one probably shouldn't be 💀

so to help engineers figure out if a SIP extension is the right move, there are two broad criteria 👑 first, the problem SHOULD fit into the general purview of SIP's solution space. second, the solution MUST conform to the general SIP architectural model. 🫶

now the first one sounds super obvious, but it's lowkey wild how many extensions get proposed just because some function is needed in a device that already speaks SIP 🙈 the logic is usually "I'd rather implement one protocol than many." like, user agents (just like every other IP host) need some way to get their IP address 🌐 that's normally done with DHCP [11]. and someone might say SIP's multicast registration mechanisms could supply an alternate way to get an IP address, which would mean clients don't need DHCP anymore. the authors don't think that kind of extension is appropriate, though 😤

the reasoning is that protocols should be defined to do specific, narrow functions, not to cover every protocol a pair of devices needs between them 💅 that approach gives you modular protocols with broad application, makes extensibility and growth way easier, and lets you remove or change a single protocol without wrecking the whole system ✨ honestly it's giving object-oriented software engineering, and that's the vibe the authors are going for 🦋

and the second criterion, that the extension must conform to the general SIP architectural model, is what keeps the protocol manageable and broadly applicable 👑

3.1. SIP's Solution Space 🎀

okay so before we can judge the first criteria, we need to figure out exactly what SIP's solution space is, and what it isn't 👀

SIP is a protocol for starting, changing, and ending interactive sessions 💖. That involves discovering users (or, more generally, entities you can talk to, like services such as voicemail or translation devices) wherever they are, so that a description of the session can be delivered to them. It's assumed 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: letting a request initiator deliver a message to a recipient wherever they might be. A rendezvous is needed to set up a session, but it can be used for other communications stuff too, like querying for capabilities or delivering an instant message 💌

Lots of SIP is all about discovery and rendezvous 🔍. Its forking, its registration, and its routing are all there for one reason: finding the desired user wherever they are. So features like personal mobility, automatic call distribution, and follow-me are totally inside the SIP solution space 🌸

Starting a session also depends on the called party having enough info about the session to decide whether to join 🤔. That includes data about the caller, the purpose of the invitation, and the parameters of the session itself. So SIP includes this kind of info 💅

Part of starting a session is communicating progress and the final results of establishing it. SIP provides that too ✅

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 starts and ends is fundamental 🫶. Because of that, there are loads of functions SIP explicitly does not provide 🙅‍♀️. It's not a session management protocol or a conference control protocol. The particulars of what happens inside the session are outside of SIP, and that includes 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 to 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, and it is not meant as a replacement for HTTP. Carrying payloads in SIP messages isn't always a bad thing, though! 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 the ones assumed in SIP, and they're more centralized in architecture than SIP is, since SIP is a very distributed protocol 🕸️

There are many network layer services needed to make SIP function, like 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 that are also needed by many other application layer protocols, SHOULD NOT be addressed within SIP 💜

3.2. SIP Architectural Model 🏗️

Here are some of the primary architectural assumptions that SIP is built on 🧱. Extensions that violate these assumptions should be examined more carefully to figure out whether they belong in 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 already touched on this once, but it's worth saying again 🔁. The set of routers, networks, and/or autonomous systems traversed by SIP messages is 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 its messages will traverse the Internet. That is, SIP works through multiple networks administered by different providers 🌐. It's 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 that modifies some characteristic of the session. This full state property is fundamental to SIP and is critical for the 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 indicates 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 ✨

okay so once an extension has passed the litmus tests from the previous section, there are several issues that all extensions should take into consideration 🧐💅

4.1. Backward Compatibility 🎀

okay bestie, this one is SO important 😭 the big question is whether the new extension is backward compatible with baseline SIP 🫶 and that's tightly tied to how the Require, Proxy-Require, and Supported header fields get used. it's giving whole web of drama.

so like, if an extension is new header fields or header field parameters that a user agent slaps into a request with an existing method, AND that request can't be processed reasonably by a proxy and/or user agent without understanding those 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 💀. mandating these header fields means requests can't be serviced unless the entities being communicated with also understand the extension. if some entity doesn't get it, the request gets rejected.

then the UAC has two options 🦋. option one: the request simply fails and the service can't be provided. that's basically an interoperability failure 😩. option two: the UAC retries the request without the extension. this keeps interoperability alive, but at the cost of a "dual stack" implementation in a UAC (processing rules for operation with and without the extension). and here's the spicy part 🌶️: as the number of extensions goes up, this leads to an exponential explosion in the sets of processing rules a UAC may need to implement. the result is excessive complexity. ngl that's a lot of rules to keep track of 💀

because of those interoperability and complexity problems from using Require and Proxy-Require, we think the following guidelines are appropriate:

  • using these header fields in requests for basic SIP services (in particular, session initiation and termination) is NOT RECOMMENDED. the less often a particular extension is needed in a request, the more reasonable it is to use these header fields 🌸
  • 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. meanwhile the Require header field only mandates that a single entity, the UAS, support the extension. so using Proxy-Require is considered exponentially worse than using Require 😭
  • 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 don't need to use the Require header field, bestie 🧚. SIP has mechanisms that let a UAC 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's fundamental to SIP that proxies don't need to understand the semantics of a new method in order to process it. if an extension defines a new method that proxies must understand to process it, a Proxy-Require header field is needed. as we said above, these kinds of extensions are frowned upon 🙃

to get backwards compatibility for extensions that define new methods, the Allow header field is used. there are two types of new methods: the ones used for established dialogs (initiated by INVITE, for example), and the ones sent as the initial request to a UA. since INVITE and its response both SHOULD contain an Allow header field, a UA can easily figure out whether the new method can be supported within the dialog 👑. for example, once an INVITE dialog is established, a user agent could check whether the REFER method [12] is supported if it's in an Allow header field. if it isn't, the "transfer" button on the UI could be "greyed out" once the call is established 💜

another type of extension has a proxy insert header fields or header field parameters into a request as it traverses the network, or has the UAS insert header fields or header field parameters into a response. for some of these, if the UAC or UAS doesn't understand those 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's sure the client understands it. these extensions will need the Supported request header field mechanism. this lets a server figure out if the client can understand some extension, so it can apply the extension to the response. by their nature, these extensions may not always be applicable to every response 🍓

if an extension needs a proxy to insert a header field or parameter into a request, and that header field or parameter has to be understood by both the UAC and the UAS to be executed correctly, then a combo of the Require and Supported mechanisms is needed. the proxy can insert a Require header field into the request if the Supported header field is present. an example of this is the SIP Session Timer [13] ⭐

one more type: extensions that define 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, so the interoperability issues look a lot like the new-methods case. BUT the Content-Disposition header field has been defined so a client or server can indicate that the message body is optional [2] 🙌. so 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's better if the sending entity knows ahead of time whether the recipient understands the new body. for requests that establish a dialog, including Accept in the request and its success responses is RECOMMENDED 💖. this lets both parties figure out which body types their peers support, and later messages between them would then only include body types that were indicated as understood 🦋

4.2. Security 🔐

security is an important part of any protocol, bestie 😤. designers of SIP extensions need to carefully consider whether they need security requirements beyond the ones described in RFC 3261. honestly? authorization requirements and requirements for end-to-end integrity are the ones people overlook the MOST 😭 (lowercase in the text, so no caps needed here)

SIP extensions MUST consider how (or if) they affect the use of the general SIP security mechanisms 🛡️. most extensions shouldn't need any new security capabilities beyond general-purpose SIP. if they do, the security mechanism probably has more general-purpose application and should be treated as an extension in its own right 💅

overall system security needs both the SIP signaling and the media sessions it sets up to be secured. the media sessions usually use their own security techniques, which are pretty distinct from the ones SIP uses. extensions should be careful not to mix the two up 🙈. however, specifications that define extensions which impact media sessions in any way SHOULD consider the interactions between SIP and session security mechanisms 🔥

4.3. Terminology 📖

RFC 3261 has a big terminology section that defines terms like 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 covered by a term in another SIP specification. if new terminology is needed, it SHOULD appear in a separate section near the beginning of the document ✨

and be careful with how you actually use the terminology, bestie 👀. lots of documents mix up the terms header, header field, and header field values, for example. document authors SHOULD do a careful review of their documents for proper usage of these terms 💅🎀

4.4. Syntactic Issues ✨

okay bestie, let's talk syntax 💅 Extensions that define new methods SHOULD use all capitals for the method name. Method names SHOULD be shorter than 10 characters and SHOULD try to capture the general meaning of the request 🎀 Method names are case sensitive, so strictly speaking they don't have to be capitalized. Still, capitalized method names keep up a long-standing convention in SIP and lots of similar protocols, like HTTP [15] and RTSP [16]. it's giving consistency 🦋

Extensions that define new header fields that are expected to be heavily used MAY define a compact form if those header fields are more than six characters 🌸 "Heavily used" means more than thirty percent of all emitted messages contain that header field. Using compact forms in these cases is only a MAY, because there are better approaches for reducing message overhead [20]. Compact header fields MUST be a single character. Once all 26 letters are used up, no new compact forms will be defined 💀 Header field names are defined by the "token" production in RFC 3261, Section 25.1, so they can include upper and lowercase letters, the digits 0 through 9, and these symbols: HYPHEN-MINUS (-), FULL STOP (.), EXCLAMATION MARK (!), PERCENT SIGN (%), ASTERISK (*), LOW LINE (_), PLUS SIGN (+), GRAVE ACCENT (`), APOSTROPHE ('), and TILDE (~). Header field names SHOULD be descriptive but reasonably brief. Even though header field names are case insensitive, a single common capitalization SHOULD be used throughout the document. It is RECOMMENDED that each English word in the header field name have its first letter capitalized, like this: "ThisIsANewHeader" ✨

Here are some examples of really poor choices for header field names 🙈

ThisIsMyNewHeaderThatDoesntDoVeryMuchButItHasANiceName
--.!A
Function

Case sensitivity of parameters and values has been a constant source of confusion, and it plagued RFC 2543 [17] 😭 This got simplified by using the BNF constructs of RFC 4234 [5], which have clear rules for what is case sensitive and what isn't. So the BNF for an extension completely defines the matching rules 🧚

Extensions MUST be consistent with the SIP conventions for case sensitivity. Methods MUST be case sensitive. Header field names MUST be case insensitive. Header field parameter names MUST be case insensitive. Header field values and parameter values are sometimes case sensitive and sometimes case insensitive, but generally they SHOULD be case insensitive. Defining a case-sensitive component requires explicitly listing each character through its ASCII code 🔥

Extensions that contain freeform text MUST allow that text to be UTF-8, as per the IETF policies on character set usage [3]. This keeps SIP an internationalized standard, which is so iconic 🌈 As a general rule, freeform text is never needed by programs to do protocol processing. It's usually entered by a person and displayed back to a person. If an extension uses a parameter that can contain UTF-8-encoded characters, and that extension needs to compare this parameter to other parameters, the comparison MUST be case sensitive. Case-insensitive comparison rules for UTF-8 text are, at this time, impossible, and they MUST be avoided 🫶

Extensions that make use of dates MUST use the SIP-Date BNF defined in RFC 3261, and no other date formats are allowed. However, using absolute dates to determine intervals (for example, the time at which some timer fires) is NOT RECOMMENDED. That's because it requires synchronized time between peers, and that is frequently not the case 🙃 So relative times, expressed in numbers of seconds, SHOULD be used 🍓

Extensions that include network-layer addresses SHOULD permit dotted quad IPv4 addresses, IPv6 addresses in the format described in [4], and domain names 🌐

Extensions that have header fields containing URIs SHOULD be explicit about which URI schemes can be used in that header field. Header fields SHOULD allow the broadest set of URI schemes possible that match the semantics of the header field 💜

Header fields MUST follow the standard formatting for SIP, which looks like this:

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

Sometimes that form isn't enough. That's the case for header fields that hold descriptive text meant for humans, like the Subject header field in SIP [2]. For those, the alternate form is:

header          = header-name HCOLON [TEXT-UTF8-TRIM]

Developers of extensions SHOULD allow for extension parameters in their header fields ✨

Header fields that contain a list of URIs SHOULD follow the same syntax as the Contact header field in SIP. Implementors are also encouraged to wrap these URIs in angle brackets, "<" and ">", at all times. We've found this is a feature that gets misimplemented a lot 😭

Beyond the compact form, there's no need to define compressed versions of header field values. Compression of SIP messages SHOULD be handled at lower layers, for example using IP payload compression [18] or signalling compression [20] 🧊

Syntax for header fields is expressed in Augmented Backus-Naur Form and MUST follow the format of RFC 4234 [5]. Extensions MUST make use of the primitive components defined in RFC 3261 [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 the section number. All BNF elements must be either defined or referenced 📚

It is RECOMMENDED that BNF be collected into a single section near the end of the document 🎀

All tokens and quoted strings are separated by explicit linear white space. Linear white space, for better or worse, allows for line folding. Extensions MUST NOT define new header fields that use alternate linear white space rules 🙅

All SIP extensions MUST verify that any BNF productions they define in their grammar do not conflict with any existing grammar defined in other SIP standards-track specifications. Main character energy: double-check your grammar before you ship 👑

4.5. Semantics, Semantics, Semantics 💖

Developers of protocols get SO caught up in syntax issues that they don't spend enough time on semantics 😤 But the semantics of a protocol are way more important! SIP extensions MUST clearly define the semantics of the extension. Specifically, the extension MUST specify the behaviors expected of a UAC, UAS, and proxy when 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 scenario 🦋

Processing rules generally specify actions to be taken (in terms of messages to be sent, variables to be stored, and rules to be followed) when messages are received and when timers expire. If an action requires sending a message, the rule SHOULD outline requirements for inserting header fields or other information into that message 💌

The extension SHOULD specify procedures for exceptional conditions that are recoverable, or that require some kind of user intervention. Handling of unrecoverable errors does not require specification 🫠

4.6. Examples Section 🍰

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

For an example of how to build a good examples section, check out the message flows and message formatting in the Basic Call Flows specification [21]. Note that complete messages SHOULD be used. Be careful to include tags, Via header fields (with the branch ID cookie), Max-Forwards, Content-Lengths, Record-Route, and Route header fields 🫶 Example INVITE messages MAY omit session descriptions, and Content-Length values MAY be set to "..." to indicate that the value is not provided. However, the specification MUST explicitly call out the meaning of the "..." and explicitly indicate that session descriptions were not included. No sneaky omissions allowed 🙈

4.7. Overview Section 🌸

Too often, extension documents dive straight into detailed syntax and semantics without giving a general overview of how things work. That makes the extension way harder to understand 😩 It is RECOMMENDED that extensions have a protocol overview section that discusses the basic operation of the extension. Basic operation usually means the message flow, in temporal order, for the most common case the extension covers. The most important processing rules for the elements in the call flow SHOULD be mentioned. Using the RFC 2119 [1] terminology in the overview section is NOT RECOMMENDED, and the specification should explicitly state that the overview is tutorial in nature only. This section SHOULD expand all acronyms, even the ones that are common in SIP systems, and SHOULD be understandable to readers who are not SIP experts 🧚 [27] has more tips on writing good overview sections, so go read it! 💅

4.8. IANA Considerations Section 🎀

Okay so every new SIP extension is going to have an IANA Considerations section, no exceptions 💅 It's giving paperwork, but it's the paperwork that keeps everything official.

  • Event packages: If your extension defines a new event package, you MUST register that package. RFC 3265 [6] gives you the registration template, and [22] has an example of registering a new event package. As RFC 3427 [10] explains, only standards-track documents can register new event-template packages. Both standards-track and informational specifications can register event packages 🫶
  • Header fields: If your extension defines a new header field, you MUST register that header field. RFC 3261 [2] provides a registration template. See Section 8.2 of RFC 3262 [23] for an example of how to register new SIP header fields. Both standards-track and informational P-header specifications can register new header fields [10].
  • Response codes: If your extension defines a new response code, you MUST register that response code. RFC 3261 [2] provides a registration template. See Section 6.4 of RFC 3329 [19] for an example of how to register a new response code. As RFC 3427 [10] discusses, only standards-track documents can register new response codes.
  • Methods: If your extension defines a new SIP method, you MUST register that method. RFC 3261 [2] provides a registration template. See Section 10 of RFC 3311 [24] for an example of how to register a new SIP method. As RFC 3427 [10] discusses, only standards-track documents can register new methods.
  • Header field parameters: If your extension defines a new SIP header field parameter, you MUST register that header field parameter per the guidelines in RFC 3968 [7]. Section 4.1 of that specification provides a template. Only IETF approved specifications can register new header field parameters. However, there is no requirement that these be standards track.
  • URI parameters: If your extension defines a new SIP URI parameter, you MUST register that URI parameter per the guidelines in RFC 3969 [8]. Section 4.1 of that specification provides a template. Only standards-track documents can register new URI parameters.
  • Option tags: Lots of SIP extensions use option tags, carried in the Require, Proxy-Require, and Supported header fields. Section 4.1 talks through some of the issues with using these header fields. If your extension does require them, you MUST register an option tag for your extension. RFC 3261 [2] provides a registration template. See Section 8.1 of RFC 3262 [23] for an example of how to register an option tag. Only standards-track RFCs can register new option tags.
  • Registries: Some SIP extensions will need their own IANA registries. RFC 2434 [25] gives guidance on how and when IANA registries are established. For an example of how to set one up, see Section 6 of RFC 3265 [6].

4.9. Document-Naming Conventions 💖

Picking your extension's title is a big deal, bestie 📝 The title MUST indicate that the document is an extension to SIP. It is RECOMMENDED that the title follow the basic form of A [summary of function] for the Session Initiation Protocol (SIP), where the summary of function is a one- to three-word description of the extension.

For example, say your extension defines a new header field called Make-Coffee for making coffee. The title would be "Making Coffee with the Session Initiation Protocol (SIP)" ☕ It is RECOMMENDED that those extra words be descriptive instead of naming the header field. So the coffee extension should not be called "The Make-Coffee Header for the Session Initiation Protocol" 🙈

If your extension defines new methods, an acceptable title template is The Session Initiation Protocol (SIP) X Method, where X is the name of the method ✨

Also, the acronym SIP MUST be expanded in the titles of RFCs, as per [26]. No shortcuts here, babe.

4.10. Additional Considerations for New Methods 🦋

Extensions that define new methods SHOULD take into consideration and discuss the following issues:

  • Bodies: Can it contain bodies? If so, what is the meaning of the presence of those bodies? What body types are allowed?
  • Overlapping transactions: Can a transaction with this request method occur while another transaction, in the same and/or reverse direction, is in progress?
  • Header fields per method: The extension MUST define which header fields can be present in requests of that method. It is RECOMMENDED that this information be represented as a new column of Table 2/3 of RFC 3261 [2]. The table MUST contain rows for all header fields defined in standards-track RFCs at the time of writing of the extension.
  • Dialogs: Can the request be sent within a dialog, or does it establish a dialog?
  • Target refresh: Is it a target refresh request?
  • Offers and answers: 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 [28] and MUST adhere to the additional constraints for offers and answers as specified in SIP [2].
  • Immediate responses: 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 requires 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. An example of that is SUBSCRIBE and NOTIFY [6].
  • Cancellation: The SIP specification [2] allows new methods to specify whether transactions using that new method can be canceled using a CANCEL request. Further study of the non-INVITE transaction [14] has determined that non-INVITE transactions must be completed as soon as possible. New methods must not plan for the transaction to pend long enough for CANCEL to be meaningful. Thus, new methods MUST declare that transactions initiated by requests with that method cannot be canceled. Future work may relax this restriction, at which point these guidelines will be revised.
  • Forking for new dialogs: New methods that establish a new dialog must discuss the impacts of forking. The design of such new methods should follow the pattern of requiring an immediate request in the reverse direction from the request establishing a dialog, similar to the immediate NOTIFY sent when a subscription is created per RFC 3265 [6].

The reliability mechanisms for all new methods must be the same as for BYE. The delayed response feature of INVITE is only available in INVITE, never for new methods. The design of new methods must encourage an immediate response. If the application being enabled requires a delay, the design SHOULD follow a pattern using multiple transactions, similar to RFC 3265's use of NOTIFYs with different Subscription-State header field values (pending and active in particular) in response to SUBSCRIBE [6] 💅

4.11. Additional Considerations for New Header Fields or Header Field Parameters 🌸

The biggest issue for extensions that define new header fields or header field parameters is backwards compatibility 🥺 See Section 4.1 for a discussion of the issues. The extension MUST detail how backwards compatibility is addressed.

It's honestly so tempting to skip making a new method and just overload an existing one with a header field or parameter. But header fields and parameters are not meant to fundamentally alter the meaning of the method of the request. A new header field 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 defined. Main character method names only 👑

For extensions that define new header fields, the extension MUST define the request methods the header field 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 2/3 of RFC 3261 [2]. The table MUST contain columns for all methods defined in standards-track RFCs at the time of writing of the extension.

4.12. Additional Considerations for New Body Types 🍓

Because SIP can run over UDP, extensions that specify the inclusion of large bodies (where large is several times the ethernet MTU) are frowned upon unless end-to-end congestion controlled transport can be guaranteed. If at all possible, the content SHOULD be included indirectly [9], 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. Their job is to add info, not rewrite the rules ✨

5. Interactions with SIP Features 🧚

We've noticed that certain SIP capabilities keep interacting with extensions in unusual ways 🙃 Writers of extensions SHOULD consider how their extensions interact with these SIP capabilities, and document any unusual interactions if they exist. Here are the most common causes of problems:

  • 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 UASes, and (2) a single INVITE request to have multiple responses.
  • CANCEL and ACK: CANCEL and ACK are "special" SIP requests, because 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 that define new header fields in INVITE requests SHOULD consider whether they also need to be included in ACK and CANCEL. Frequently they do, in order to allow a stateless proxy to route the CANCEL or ACK identically to the INVITE.
  • Routing: The presence of Route header fields in a request can cause it to be sent through intermediate proxies. Requests that establish dialogs can be record-routed, so that the initial request goes through one set of proxies, and subsequent requests go 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 that depend on some kind of proxy processing SHOULD consider how stateless proxies affect that processing.
  • Dialog Usages: SIP allows for requests that normally create their own dialog (such as SUBSCRIBE) to be used within a dialog created by another method (such as INVITE). In such a case, there are said to be multiple usages of that dialog. Extensions SHOULD consider their interaction with dialog usages. In particular, extensions that define new error response codes SHOULD describe whether that response code causes the dialog and all usages to terminate, or just a specific usage.

6. Security Considerations 🔐

The nature of this document is such that it does not introduce any new security considerations. However, many of the principles described in the document affect whether a potential SIP extension design is likely to support the SIP security architecture. Treat this one like a group-chat security warning, bestie: the stakes are real 🚨

7. Acknowledgements 🙌

okay bestie, big shoutout time 📣 Rohan Mahy and Spencer Dawkins gave the authors comments that made this doc better 💖 Robert Sparks wrote important text on CANCEL issues, which is a very real gift because CANCEL is where things get messy 🫶 And thanks to Allison Mankin for her support ✨ literally the squad 👑

8. References 📚

8.1. Normative References 🔥

[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.

[3] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.

[4] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.

[5] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.

[6] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.

[7] Camarillo, G., "The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)", BCP 98, RFC 3968, December 2004.

[8] Camarillo, G., "The Internet Assigned Number Authority (IANA) Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP)", BCP 99, RFC 3969, December 2004.

[9] Burger, E., Ed., "A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages", RFC 4483, May 2006.

8.2. Informative References 🧠

[10] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B. Rosen, "Change Process for the Session Initiation Protocol (SIP)", BCP 67, RFC 3427, December 2002.

[11] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.

[12] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.

[13] Donovan, S. and J. Rosenberg, "Session Timers in the Session Initiation Protocol (SIP)", RFC 4028, April 2005.

[14] Sparks, R., "Problems Identified Associated with the Session Initiation Protocol's (SIP) Non-INVITE Transaction", RFC 4321, January 2006.

[15] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

[16] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.

[17] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.

[18] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP Payload Compression Protocol (IPComp)", RFC 3173, September 2001.

[19] Arkko, J., Torvinen, V., Camarillo, G., Niemi, A., and T. Haukka, "Security Mechanism Agreement for the Session Initiation Protocol (SIP)", RFC 3329, January 2003.

[20] Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu, Z., and J. Rosenberg, "Signaling Compression (SigComp)", RFC 3320, January 2003.

[21] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and K. Summers, "Session Initiation Protocol (SIP) Basic Call Flow Examples", BCP 75, RFC 3665, December 2003.

[22] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Registrations", RFC 3680, March 2004.

[23] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.

[24] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.

[25] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

[26] Reynolds, J. and R. Braden, "Instructions to Request for Comments (RFC) Authors", Work in Progress, July 2004.

[27] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, June 2005.

[28] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.

Authors' Addresses 🏡

Jonathan Rosenberg
Cisco Systems
600 Lanidex Plaza
Parsippany, NJ  07054
US

Phone: +1 973 952-5000
EMail: jdrosen@cisco.com
URI:   http://www.jdrosen.net


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

EMail: schulzrinne@cs.columbia.edu
URI:   http://www.cs.columbia.edu/~hgs

Copyright (C) The Internet Society (2006).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🔐

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Acknowledgement 💜

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).

📦 where this page comes from