RFC 5411

A Hitchhiker's Guide to the Session Initiation Protocol (SIP)

📅 published February 2009, from ietf

RFC 5411: A Hitchhiker's Guide to the Session Initiation Protocol (SIP) 🚀

Bestie, this is the one that tells you where every SIP spec lives! 💖

Number: RFC 5411
Stream: Network Working Group
Author: J. Rosenberg (Cisco) 🎀
Category: Informational
Date: January 2009
Obsoletes / Updates: the header doesn't list either one, and the doc says it isn't an update to RFC 3261 (more on that in Section 1 🦋)

Status of This Memo 📜

This memo gives information to the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. 🌸

Abstract ✨

okay so SIP is the subject of SO many specs from the IETF 😭 and it can be lowkey impossible to find the right doc, or even figure out what the full set of Request for Comments (RFC) about SIP even is. This spec is your guide to the SIP RFC series 🧚. It lists a current snapshot of the specs under the SIP umbrella, gives a quick summary of each one, and sorts them into categories. slay 💅

Table of Contents 🗂️

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
2.  Scope of This Document . . . . . . . . . . . . . . . . . . . .  4
3.  Core SIP Specifications  . . . . . . . . . . . . . . . . . . .  5
4.  Public Switched Telephone Network (PSTN) Interworking  . . . .  8
5.  General Purpose Infrastructure Extensions  . . . . . . . . . . 10
6.  NAT Traversal  . . . . . . . . . . . . . . . . . . . . . . . . 12
7.  Call Control Primitives  . . . . . . . . . . . . . . . . . . . 13
8.  Event Framework  . . . . . . . . . . . . . . . . . . . . . . . 14
9.  Event Packages . . . . . . . . . . . . . . . . . . . . . . . . 15
10. Quality of Service . . . . . . . . . . . . . . . . . . . . . . 16
11. Operations and Management  . . . . . . . . . . . . . . . . . . 17
12. SIP Compression  . . . . . . . . . . . . . . . . . . . . . . . 17
13. SIP Service URIs . . . . . . . . . . . . . . . . . . . . . . . 17
14. Minor Extensions . . . . . . . . . . . . . . . . . . . . . . . 19
15. Security Mechanisms  . . . . . . . . . . . . . . . . . . . . . 20
16. Conferencing . . . . . . . . . . . . . . . . . . . . . . . . . 23
17. Instant Messaging, Presence, and Multimedia  . . . . . . . . . 24
18. Emergency Services . . . . . . . . . . . . . . . . . . . . . . 25
19. Security Considerations  . . . . . . . . . . . . . . . . . . . 25
20. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
21. Informative References . . . . . . . . . . . . . . . . . . . . 26

1. Introduction ✨

okay bestie, SIP [RFC3261] is the subject of a gazillion specs the IETF has cranked out 😭. It can be lowkey hard to find the right doc, or even to figure out what the full set of Request for Comments (RFC) about SIP is. "Don't Panic!" [HGTTG] 🧚 This spec is your guide to the SIP RFC series. It's a current snapshot of the specs under the SIP umbrella at the time of publication. The plan is for this doc itself to get regularly updated as SIP specs mature. Also, it references a bunch of specs that weren't finalized yet when this was published, and they might eventually get completed or abandoned. So the list here is a work-in-progress and subject to change, no cap 🫶

For each spec, there's a paragraph or so describing what it's for. Each spec also has a letter that marks its category in the Standards Track [RFC2026]. The letters are:

S: Standards Track (Proposed Standard, Draft Standard, or Standard) 💜
E: Experimental 🧪
B: Best Current Practice ✅
I: Informational 📖

The specs are grouped by topic. The topics are:

Core: the SIP specs that are expected to be used for each session or registration an endpoint takes part in. 💖
Public Switched Telephone Network (PSTN) Interop: specs about interworking with the telephone network. 📞
General Purpose Infrastructure: general purpose extensions to SIP, SDP (Session Description Protocol), and MIME, but ones that aren't expected to always be used. 🛠️
NAT Traversal: specs for dealing with firewall and NAT traversal. 🚪
Call Control Primitives: specs for manipulating SIP dialogs and calls. 🎛️
Event Framework: definitions of the core specs for the SIP event framework, which provides pub/sub capability. 📣
Event Packages: packages that use the SIP event framework. 📦
Quality of Service: specs related to multimedia quality of service (QoS). 🌈
Operations and Management: specs related to configuration and monitoring of SIP deployments. 📊
SIP Compression: specs that help you use SIP with the Signaling Compression (Sigcomp) framework. 🗜️
SIP Service URIs: specs on how to use SIP URIs to address multimedia services. 🔗
Minor Extensions: specs that solve a narrow problem space or provide an optimization. 🪄
Security Mechanisms: specs providing security functionality for SIP. 🔐
Conferencing: specs for multimedia conferencing. 🎤
Instant Messaging, Presence, and Multimedia: SIP extensions related to IM, presence, and multimedia. This only covers the SIP extensions for those topics. For a full treatment of SIP for IM and Presence (SIMPLE), see [SIMPLE]. 💬
Emergency Services: SIP extensions related to emergency services. For a more complete treatment of the extra functionality around emergency services, see [ECRIT-FRAME]. 🚨

Typically, SIP extensions fit naturally into topic areas, and implementors who care about a particular topic often implement many or all of the specs in that area. Some specs fall into more than one topic area, and in that case they're listed more than once. 🦋

Do not print all the specs cited here at once, as they might share the fate of the rules of Brockian Ultracricket when bound together: collapse under their own gravity and form a black hole [HGTTG]. 💀

This document itself is not an update to RFC 3261 or an extension to SIP. It's an informational doc, meant to guide newcomers, implementors, and deployers to the many specs associated with SIP. 🌸

3. Core SIP Specifications 💅

okay so the core SIP specs are the ones that are broadly applicable, meaning they fit one of these vibes:

specs that impact SIP session management, which means they'd be used for almost every session a user agent starts 📞
specs that impact SIP registrations, which means they'd be used for almost every registration a user agent starts 🎀
specs that impact SIP subscriptions, which means they'd be used for almost every subscription a user agent starts 🦋

basically these aren't specs you only use for some requests and skip for others. they apply to every single request where the extension is relevant. no cap, in the galaxy of SIP these specs are literally like towels [HGTTG] 🧚

RFC 3261, The Session Initiation Protocol (S): [RFC3261] is the core SIP protocol itself 👑. RFC 3261 obsoletes [RFC2543]. it's the president of the galaxy [HGTTG] as far as the SIP suite is concerned, so yeah, iconic.

RFC 3263, Locating SIP Servers (S): [RFC3263] gives you DNS procedures for taking a SIP URI and figuring out which SIP server goes with that URI 🗺️. it's essential for any implementation using SIP with DNS. RFC 3263 uses both DNS SRV records [RFC2782] and NAPTR records [RFC3401], so it's a whole team effort 🫶.

RFC 3264, An Offer/Answer Model with the Session Description Protocol (S): [RFC3264] defines how the Session Description Protocol (SDP) [RFC4566] gets used with SIP to negotiate the parameters of a media session 🎶. it's in widespread usage and it's an integral part of how RFC 3261 behaves, so it's a total staple.

RFC 3265, SIP-Specific Event Notification (S): [RFC3265] defines the SUBSCRIBE and NOTIFY methods 🔔. together they give you a general event notification framework for SIP. to actually use that framework, extensions need to be defined for specific event packages. an event package defines a schema for the event data and describes the other event processing stuff specific to that schema. an RFC 3265 implementation is required whenever any event package is used, so don't skip it 🙈.

RFC 3325, Private Extensions to SIP for Asserted Identity within Trusted Networks (I): ngl the P-header status makes it sound like it has limited applicability, but [RFC3325] is super popular and has been widely deployed 💖. it defines the P-Asserted-Identity header field and it's the basic mechanism for network-asserted caller ID services. its intended update, [UPDATE-PAI], clarifies usage for connected party identification too, so it's getting a glow-up ✨.

RFC 3327, SIP Extension Header Field for Registering Non-Adjacent Contacts (S): [RFC3327] defines the Path header field 🛤️. proxies insert it between a client and their registrar, and it lets inbound requests headed toward that client go through those proxies before they reach the user agent. it's essential in any SIP deployment with edge proxies, which are the proxies sitting between the client and the home proxy or SIP registrar. main character energy for sure.

RFC 3581, An Extension to SIP for Symmetric Response Routing (S): [RFC3581] defines the rport parameter of the Via header 🦋. it lets SIP responses traverse NAT. it's one of several specs used for NAT traversal (see Section 6), so it's part of a bigger squad.

RFC 3840, Indicating User Agent Capabilities in SIP (S): [RFC3840] defines a mechanism for carrying capability info about a user agent in REGISTER requests and in dialog-forming requests like INVITE 🧩. it's found use with conferencing, since the isfocus parameter declares that a user agent is a conference server, and with apps like push-to-talk 📢.

RFC 4320, Actions Addressing Issues Identified with the Non-INVITE Transaction in SIP (S): [RFC4320] formally updates RFC 3261 and changes some of the behaviors tied to non-INVITE transactions 🛠️. it fixes some problems found in timeout and failure cases, which is honestly such a relief.

RFC 4474, Enhancements for Authenticated Identity Management in SIP (S): [RFC4474] defines a mechanism for a cryptographically verifiable identity of the calling party in a SIP request 🔐. known as "SIP Identity," it's an alternative to RFC 3325. it hasn't seen much deployment yet, but its importance as a key construct for anti-spam techniques and new security mechanisms makes it a core part of the SIP specs. it's giving future-proof.

GRUU, Obtaining and Using Globally Routable User Agent Identifiers (GRUU) in SIP (S): [GRUU] defines a mechanism for directing requests toward a specific UA instance 🎯. GRUU is essential for features like transfer, and it's another piece of the SIP NAT traversal story 🧚.

OUTBOUND, Managing Client Initiated Connections through SIP (S): [OUTBOUND], also known as SIP outbound, defines important changes to the SIP registration mechanism 🚪. these changes enable delivery of SIP messages to a UA when it's behind a NAT. this spec is the cornerstone of the SIP NAT traversal strategy, so it's a total queen 👑.

RFC 4566, Session Description Protocol (S): [RFC4566] defines a format for representing multimedia sessions 🎬. SDP objects get carried in the body of SIP messages and, based on the offer/answer model, they're used to negotiate the media characteristics of a session between users.

SDP-CAP, SDP Capability Negotiation (S): [SDP-CAP] defines a set of extensions to SDP that allow capability negotiation within SDP 🎚️. you can use capability negotiation to pick between different RTP profiles (secure vs. unsecure) or to negotiate codecs, so an agent has to select one from a set of supported codecs.

ICE, Interactive Connectivity Establishment (ICE) (S): [ICE] defines a technique for NAT traversal of media sessions for protocols that use the offer/answer model 🌈. this is the IETF-recommended mechanism for NAT traversal for SIP media streams, and it's meant to be used even by endpoints that are never themselves behind a NAT. a SIP option tag and media feature tag [OPTION-TAG] (also a core specification) have been defined for use with ICE, so ICE is really in its era ✨.

RFC 3605, Real Time Control Protocol (RTCP) Attribute in the Session Description Protocol (SDP) (S): [RFC3605] defines a way to explicitly signal, within an SDP message, the IP address and port for RTCP 📡. the alternative is the port+1 rule in the Real Time Transport Protocol (RTP) [RFC3550]. this is needed for devices behind NAT, and ICE requires the specification.

RFC 4916, Connected Identity in the Session Initiation Protocol (SIP) (S): [RFC4916] formally updates RFC 3261 💫. it defines an extension to SIP that lets a calling user determine the identity of the final called user, aka the connected party. because of forwarding and retargeting services, that might not be the same user the caller was originally trying to reach 🙃. the mechanism works in tandem with the SIP identity spec [RFC4474] to provide signatures over the connected party identity. it can also be used if a party identity changes mid-call due to third-party call control actions or PSTN behavior.

RFC 3311, The SIP UPDATE Method (S): [RFC3311] defines the UPDATE method for SIP 🔄. it's meant for updating session info before the initial INVITE transaction completes. it can also update other info, like the identity of the participant [RFC4916], without needing an updated offer/answer exchange. it was developed initially to support [RFC3312], but it's found other uses too. in particular, paired with RFC 4916, it'll typically be part of every session to convey a secure, connected identity 🔐💖.

SIPS-URI, The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP) (S): [SIPS-URI] is intended to update RFC 3261 🛡️. it revises the processing of the SIPS URI, which was originally defined in RFC 3261, to fix lots of errors and problems people have run into with that mechanism. honestly a much-needed cleanup.

RFC 3665, Session Initiation Protocol (SIP) Basic Call Flow Examples (B): [RFC3665] contains best-practice call flow examples for basic SIP interactions: call establishment, termination, and registration 📖. it's a great study buddy.

Essential Corrections to SIP: this is a collection of fixes to SIP that address important bugs and vulnerabilities 🐛. it includes a fix requiring loop detection in any proxy that forks [LOOP-FIX], a clarification on how record-routing works [RECORD-ROUTE], and a correction to the IPv6 BNF [ABNF-FIX]. bestie, these are the glow-up patches we all need 🫶✨.

4. Public Switched Telephone Network (PSTN) Interworking ✨

okay bestie, this section is all about SIP talking to the PSTN (the old-school phone network 📞🎀) or going through it. Like, SO many SIP extensions are about interoperability with the PSTN, so buckle up 💅

RFC 2848, The PINT Service Protocol (S): [RFC2848] is one of the earliest extensions to SIP 🌸 It defines procedures for using SIP to invoke services that actually execute on the PSTN. Its main application is third-party call control, which lets an IP host set up a call between two PSTN endpoints. PINT (PSTN/Internet Interworking) has a relatively narrow focus and hasn't seen widespread deployment, so it's kinda the quiet one in the group chat 🫶
RFC 3910, The SPIRITS Protocol (S): Continuing the trend of naming PSTN-related extensions after alcohol 🍸, SPIRITS (Services in PSTN Requesting Internet Services) [RFC3910] defines the inverse of PINT. It lets a switch in the PSTN ask an IP element how to proceed with call waiting. It was developed mainly to support Internet Call Waiting (ICW). Perhaps the next specification will be called the Pan Galactic Gargle Blaster [HGTTG] 🌌🍹 (I'm obsessed, not gonna lie 😭)
RFC 3372, SIP for Telephones (SIP-T): Context and Architectures (I): SIP-T [RFC3372] defines a mechanism for using SIP between pairs of PSTN gateways. The core idea is to tunnel ISDN User Part (ISUP) signaling between the gateways in the body of SIP messages 🚇 SIP-T motivated the development of INFO [RFC2976]. It has seen widespread implementation for the limited deployment model it addresses. As ISUP endpoints disappear from the network, the need for this mechanism will decrease 🥀
RFC 3398, ISUP to SIP Mapping (S): [RFC3398] defines how to do protocol mapping from the SS7 ISDN User Part (ISUP) signaling to SIP. It's widely used in SS7 to SIP gateways and is part of the SIP-T framework 🔁
RFC 4497, Interworking between the Session Initiation Protocol (SIP) and QSIG (B): [RFC4497] defines how to do protocol mapping from Q.SIG, which is used for Private Branch Exchange (PBX) signaling, to SIP 🏢
RFC 3578, Mapping of ISUP Overlap Signaling to SIP (S): [RFC3578] defines a mechanism to map overlap dialing into SIP. This one is widely regarded as the ugliest SIP specification 💀, because the introduction to the specification itself admits it has many problems 🙈 Overlap signaling (sending digits into the network as they're dialed instead of waiting for the complete called party number) is largely incompatible with SIP at some fairly fundamental levels. That said, RFC 3578 is mostly harmless and has seen some usage 🫠
RFC 3960, Early Media and Ringtone Generation in SIP (I): [RFC3960] defines some guidelines for handling early media 🎶, which is the practice of sending media from the called party or an application server towards the caller before the call is accepted. Early media is often generated from the PSTN. It's a complex topic, and this specification does not fully address the problems associated with it 😵‍💫
RFC 3959, Early Session Disposition Type for the Session Initiation Protocol (SIP) (S): [RFC3959] defines a new session disposition type for use with early media. It indicates that the SDP in the body is for a special early media session. This has seen little usage 🥱
RFC 3204, MIME Media Types for ISUP and QSIG Objects (S): [RFC3204] defines MIME objects for representing SS7 and QSIG signaling messages. SS7 signaling messages are carried in the body of SIP messages when SIP-T is used. QSIG signaling messages can be carried in a similar way 📦
RFC3666, Session Initiation Protocol (SIP) Public Switched Telephone Network (PSTN) Call Flows (B): [RFC3666] provides best practice call flows around interworking with the PSTN 📋✨

5. General Purpose Infrastructure Extensions 🧚

these extensions are general purpose enhancements to SIP, SDP, and MIME that can serve a wide variety of uses 🌈 They're not used for every session or registration, though, the way the core specifications are.

RFC 3262, Reliability of Provisional Responses in SIP (S): SIP defines two types of responses to a request: final and provisional. Provisional responses are numbered from 100 to 199. In SIP, these responses are not sent reliably. This choice was made in RFC 2543 because the messages were meant to be truly informational and rendered to the user 💬 However, later work on PSTN interworking showed a need to map provisional responses to PSTN messages that needed to be sent reliably. [RFC3262] was developed to allow reliability of provisional responses 🛟 The specification defines the PRACK method, which is used for indicating that a provisional response was received. Even though it's a generic capability for SIP, RFC 3262 implementations have been most common in PSTN interworking devices. PRACK brings a great deal of complication for relatively small benefit, so it has seen only moderate levels of deployment 😮‍💨
RFC 3323, A Privacy Mechanism for the Session Initiation Protocol (SIP) (S): [RFC3323] defines the Privacy header field, which clients use to request anonymity for their requests 🕶️ Though it defines several privacy services, the only one broadly used is the one that supports privacy of the P-Asserted-Identity header field [RFC3325] 🙊
UA-PRIVACY, UA-Driven Privacy Mechanism for SIP (S): [UA-PRIVACY] defines a mechanism for achieving anonymous calls in SIP. It's an alternative to [RFC3323], and it puts more intelligence in the endpoint so it can craft anonymous messages by directly accessing network services 🧠
RFC 2976, The INFO Method (S): [RFC2976] was defined as an extension to RFC 2543. It defines a method, INFO, used to transport mid-dialog information that has no impact on SIP itself 📨 Its driving application was transporting PSTN-related information when using SIP between a pair of gateways. Though it was originally conceived for broader use, it only found standardized usage with SIP-T [RFC3372]. It has been used to support numerous proprietary and non-interoperable extensions because its scope is poorly defined 🫣
RFC 3326, The Reason Header Field for SIP (S): [RFC3326] defines the Reason header field 🗯️ It's used in requests, such as BYE, to indicate the reason the request is being sent.
RFC 3388, Grouping of Media Lines in the Session Description Protocol (S): RFC 3388 [RFC3388] defines a framework for grouping together media streams in an SDP message 🎞️ Such a grouping lets you express relationships between streams, like which stream is the audio for a particular video feed 🎧
RFC 3420, Internet Media Type message/sipfrag (S): [RFC3420] defines a MIME object that contains a SIP message fragment 🧩 Only certain header fields and parts of the SIP message are present. For example, it's used to report back on the responses received to a request sent as a consequence of a REFER.
RFC 3608, SIP Extension Header Field for Service Route Discovery During Registration (S): [RFC3608] lets a client determine, from a REGISTER response, a path of proxies to use in requests it sends outside of a dialog 🗺️ It can also be used by proxies to verify the Route header in client-initiated requests. In many ways it's the inverse of the Path header field, but it has seen less usage since default outbound proxies have been sufficient in many deployments 🤷‍♀️
RFC 3841, Caller Preferences for SIP (S): [RFC3841] defines a set of headers that a client can include in a request to control how the request is routed downstream 🎯 It lets a client direct a request toward a UA with specific capabilities, which a UA indicates using [RFC3840] 💌
RFC 4028, Session Timers in SIP (S): [RFC4028] defines a keepalive mechanism for SIP signaling ⏰ It's primarily meant to clean up old state in proxies that are holding call state for calls from failed endpoints that were never terminated normally. Despite its name, the session timer is not a mechanism for detecting a network failure mid-call 🙅‍♀️ Session timers add a fair bit of complexity for relatively little gain, and they've seen moderate deployment 😤
RFC 4168, SCTP as a Transport for SIP (S): [RFC4168] defines how to carry SIP messages over the Stream Control Transmission Protocol (SCTP) [RFC4960] 🌊 SCTP has seen very limited usage for SIP transport.
RFC 4244, An Extension to SIP for Request History Information (S): [RFC4244] defines the History-Info header field, which indicates how and why a call came to be routed to a particular destination 📜
RFC 4145, TCP-Based Media Transport in the Session Description Protocol (SDP) (S): [RFC4145] defines an extension to SDP for setting up TCP-based sessions between user agents 🔌 It defines who sets up the connection and how its lifecycle is managed. It has seen relatively little usage because only a small number of media types use TCP so far 🥲
RFC 4091, The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework (S): [RFC4091] defines a mechanism for including both IPv4 and IPv6 addresses for a media session as alternates 🌐 This mechanism has been deprecated in favor of ICE [ICE] 👋
SDP-MEDIA, SDP Media Capabilities Negotiation (S): [SDP-MEDIA] defines an extension to the SDP capability negotiation framework [SDP-CAP] for negotiating codecs, codec parameters, and media streams 🎤
BODY-HANDLING, Message Body Handling in the Session Initiation Protocol (SIP): [BODY-HANDLING] clarifies handling of bodies in SIP, focusing mainly on multi-part behavior, which was under-specified in SIP 📬✨

6. NAT Traversal 🌸

Okay so these SIP extensions are mostly about getting past NAT, which is the thing that keeps breaking calls, bestie 😭

ICE, Interactive Connectivity Establishment (ICE) (S): [ICE] is the technique for NAT traversal of media sessions in protocols that use the offer/answer model 🦋. It's the IETF-recommended mechanism for NAT traversal of SIP media streams, and even endpoints that are never behind a NAT are meant to use it too ✨. There's a SIP option tag and a media feature tag [OPTION-TAG] defined for ICE 🏷️.

ICE-TCP, TCP Candidates with Interactive Connectivity Establishment (ICE) (S): [ICE-TCP] explains how to use ICE for TCP streams 💜. The payoff is that RTP-based voice can run on top of TCP, but only when NAT or firewalls would stop UDP-based voice from working 🫶.

RFC 3605, Real Time Control Protocol (RTCP) Attribute in the Session Description Protocol (SDP) (S): [RFC3605] gives you a way to signal the IP address and port for RTCP directly inside an SDP message 📡. That beats relying on the port+1 rule from the Real Time Transport Protocol (RTP) [RFC3550] 🙅‍♀️. It's needed for devices behind NAT, and ICE requires it 💅.

OUTBOUND, Managing Client Initiated Connections through SIP (S): [OUTBOUND], also known as SIP outbound, makes some big changes to the SIP registration mechanism 🍓. The result is that SIP messages can be delivered to a UA even when it's stuck behind a NAT 🔥.

RFC 3581, An Extension to SIP for Symmetric Response Routing (S): [RFC3581] defines the rport parameter of the Via header 🎀. It lets SIP responses get through NAT, which is honestly iconic 👑.

GRUU, Obtaining and Using Globally Routable User Agent Identifiers (GRUU) in SIP (S): [GRUU] defines a mechanism for sending requests to one specific UA instance 🎯. GRUU is essential for features like transfer, and it's another piece of the SIP NAT traversal story 🧚.

7. Call Control Primitives 📞

Okay, so there are loads of SIP extensions that give you a toolkit for managing dialogs and calls 🧰. People have mixed these together to build tons of SIP-based services, and it's giving main character energy 💖.

RFC 3515, The REFER Method (S): REFER [RFC3515] is a way to ask a user agent to send a SIP request 🎬. Think of it as SIP remote control ✨. It's the main tool for call transfer in SIP 📲. Now, be careful, because not every possible use of REFER is well defined, whether you look at the methods or the URI schemes 🙈. Implementors should only use the well-defined ones 🫣. They should not second guess or freely assume behavior for the others, or they'll get unexpected behavior from remote UAs, interoperability issues, and other bad surprises 💀.

RFC 3725, Best Current Practices for Third Party Call Control (3pcc) (B): [RFC3725] lays out a bunch of call flows that let one SIP entity, called the controller, create SIP sessions between other SIP user agents 🧚‍♀️.

RFC 3911, The SIP Join Header Field (S): [RFC3911] defines the Join header field 🔗. When you send it in an INVITE, the recipient joins the resulting dialog into a conference with another dialog that's already in progress 🥂.

RFC 3891, The SIP Replaces Header (S): [RFC3891] lets a new dialog replace an existing dialog 🔄. It's super useful for certain advanced transfer services 💅.

RFC 3892, The SIP Referred-By Mechanism (S): [RFC3892] defines the Referred-By header field 🫶. It shows up in requests triggered by REFER, and it tells the referred-to party who the referring party is 👀.

RFC 4117, Transcoding Services Invocation in SIP Using Third Party Call Control (I): [RFC4117] explains how to use 3pcc to invoke transcoding services for a call 🌈.

8. Event Framework 🔔

RFC 3265, SIP-Specific Event Notification (S): [RFC3265] defines the SUBSCRIBE and NOTIFY methods 💌. Together they give you a general event notification framework for SIP 🦋. To actually use it, you need extensions that define specific event packages 📦. An event package defines a schema for the event data and describes other event processing aspects that are specific to that schema 🧾. An RFC 3265 implementation is required whenever any event package is used 🙌.

RFC 3903, SIP Extension for Event State Publication (S): [RFC3903] defines the PUBLISH method 📤. It isn't an event package itself, but every event package uses it to push an event into the system 🚀.

RFC 4662, A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists (S): [RFC4662] extends RFC 3265 so a client can subscribe to a whole list of resources with one subscription 📋. The server, called a Resource List Server (RLS), "expands" the subscription and subscribes to each individual member of the list 🪄. It's mostly been used for presence, but it works with any event package 🌸.

SUBNOT-ETAGS, An Extension to Session Initiation Protocol (SIP) Events for Conditional Event Notification (S): [SUBNOT-ETAGS] extends RFC 3265 to make notifications more efficient ⚡. When a client subscribes, it can say which version of a document it already has, so the server can skip the notification if the client is already up-to-date 🧠. It applies to any event package 💖.

9. Event Packages 🎀

These are the event packages built to use the SIP events framework 🧁. A lot of them are also listed in their own areas, so you might see them twice 👯‍♀️.

RFC 3680, A SIP Event Package for Registrations (S): [RFC3680] defines an event package for finding out when registration state changes 🛎️.

GRUU-REG (S): [GRUU-REG] extends the registration event package [RFC3680] so user agents can learn about their GRUUs 🪪. It's especially helpful for keeping a client and its registrar in sync on their currently valid temporary GRUU ⏳.

RFC 3842, A Message Summary and Message Waiting Indication Event Package for SIP (S): [RFC3842] lets a user agent find out about voicemails and other messages waiting for it 📬. Its main job is turning on the voicemail waiting lamp on most business telephones 💡.

RFC 3856, A Presence Event Package for SIP (S): [RFC3856] defines an event package for showing user presence through SIP 🟢.

RFC 3857, A Watcher Information Event Template Package for SIP (S): [RFC3857], also known as winfo, lets a user agent find out what subscriptions are in place for a particular event package 👀. It's mostly used with presence, but it works with any event package 🫣.

RFC 4235, An INVITE-Initiated Dialog Event Package for SIP (S): [RFC4235] defines an event package for learning the state of the dialogs in progress at a user agent 🌌. It's also one of several RFCs whose number starts with the important number 42 [HGTTG] 🥹🌌.

RFC 4575, A SIP Event Package for Conference State (S): [RFC4575] defines a mechanism for learning about changes in conference state, including conference membership 🗣️.

RFC 4730, A SIP Event Package for Key Press Stimulus (KPML) (S): [RFC4730] defines a way for an application in the network to subscribe to the key presses made on a traditional telephone keypad ☎️. Along with RFC 4733 [RFC4733], it's one of the two mechanisms defined for handling DTMF 🔢. RFC 4730 is a signaling-path solution, and RFC 4733 is a media-path solution 🛤️.

RTCP-SUM, SIP Event Package for Voice Quality Reporting (S): [RTCP-SUM] defines a SIP event package that lets you collect and report metrics measuring the quality of Voice over Internet Protocol (VoIP) sessions 📊.

SESSION-POLICY, A Framework for Session Initiation Protocol (SIP) Session Policies (S): [SESSION-POLICY] defines a framework for session policies 📜. Policy servers tell user agents about the media characteristics a particular session requires 🎛️. Heads up, though: the session policy framework hasn't been widely implemented 🥲.

POLICY-PACK, A Session Initiation Protocol (SIP) Event Package for Session-Specific Session Policies (S): [POLICY-PACK] defines a SIP event package that's used together with the session policy framework [SESSION-POLICY] 🧩.

RFC 5362, The Session Initiation Protocol (SIP) Pending Additions Event Package (S): [RFC5362] defines a SIP event package that lets a UA find out whether consent has been given to add an address to a SIP "mailing list" 💌. It's used together with the SIP framework for consent [RFC5360] 🤝.

10. Quality of Service 🚦

Several specifications deal with how SIP interacts with network Quality of Service (QoS) mechanisms 💫.

RFC 3312, Integration of Resource Management and SIP (S): [RFC3312], updated by [RFC4032], makes sure the called party's phone doesn't ring until a QoS reservation has been installed in the network 🔔. It does this by defining a general preconditions framework, which sets out conditions that must be true before a SIP session can proceed 🛑.

QoS-ID, Quality of Service (QoS) Mechanism Selection in the Session Description Protocol (SDP) (S): [QoS-ID] lets user agents negotiate which type of end-to-end QoS mechanism to use for a session 🤳. Right now there are two options: the Resource Reservation Protocol (RSVP) and Next Steps in Signaling (NSIS) 🔀. The negotiation happens through an SDP extension 🪶. Because RSVP is barely deployed and NSIS is even less deployed, this extension hasn't been widely used 😔.

RFC 3313, Private SIP Extensions for Media Authorization (I): [RFC3313] defines a P-header that passes an authorization token between SIP and a network QoS reservation protocol like RSVP 🎟️. Its purpose is to make sure network QoS is only granted if the client made the SIP call through the same provider's network 🏰. This specification is sometimes called the SIP walled-garden specification by the truly paranoid androids in the SIP community 🤖. That's because it requires coupling signaling and the underlying IP network 🕸️.

RFC 3524, Mapping of Media Streams to Resource Reservation Flows (S): [RFC3524] uses the SDP grouping framework to indicate that a set of media streams should be handled by a single resource reservation 🧵.

11. Operations and Management 🛠️

Several specifications exist to support the operations and management of SIP systems 🧑‍💻. They cover configuration and network diagnostics 🩺.

CONFIG-FRAME, A Framework for SIP User Agent Profile Delivery (S): [CONFIG-FRAME] lets a SIP user agent bootstrap its configuration from the network and receive updates whenever that configuration changes 🌐. It's considered an essential piece of deploying a usable SIP network 🙏.

12. SIP Compression ✨

okay so Sigcomp [RFC3320] [RFC4896] was made to squish SIP messages down so they can travel over low bandwidth links 🗜️💖 BUT sigcomp is not formally part of SIP, so don't get it twisted 🙈 still, using sigcomp with SIP has needed some extensions to SIP, and these are the ones that handle it 💅

RFC 3486, Compressing SIP (S): [RFC3486] is the one that defines a SIP URI parameter that can be used to indicate that a SIP server supports Sigcomp. so a server can basically raise its hand and say "yes, I speak compressed 🙋‍♀️🗜️"

RFC 5049, Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP) (S): [RFC5049] explains how to actually apply Sigcomp to SIP. this is the how-to guide bestie needs 📖✨

13. SIP Service URIs

ngl this section is so iconic 👑 several extensions define well-known services that you can invoke just by building requests with specific structures in the Request URI, and the result is specific behaviour at the User Agent Server (UAS). it's basically a secret handshake but make it protocol 🤫🦋

RFC 3087, Control of Service Context using Request URI (I): [RFC3087] is the OG that introduced the idea of using Request URIs, encoded appropriately, to invoke services 🌸

RFC 4662, A SIP Event Notification Extension for Resource Lists (S): [RFC4662] defines a resource called a Resource List Server (RLS) 🧚 a client can send a subscribe to this server. the server then generates a series of subscriptions, compiles the resulting information, and sends it back to the subscriber. the set of resources the RLS will subscribe to is a property of the request URI in the SUBSCRIBE request. the URI does the heavy lifting here 💅

RFC 5363, Framework and Security Considerations for Session Initiation Protocol (SIP) Uniform Resource Identifier (URI)-List Services (S): [RFC5363] defines the framework for list services in SIP ✨ in this framework, a UA can include an XML list object in the body of various requests, and the server will provide list-oriented services as a result. for example, a SUBSCRIBE with a list subscribes to the URIs in the list 📝💜

RFC 5367, Subscriptions To Request-Contained Resource Lists in SIP (S): [RFC5367] uses the URI-list framework [RFC5363] and lets a client subscribe to a resource called a Resource List Server. this server generates subscriptions to the URIs in the list, compiles the resulting information, and sends it back to the subscriber 🎀

RFC 5365, Multiple-Recipient MESSAGE Requests in SIP (S): [RFC5365] also uses the URI-list framework [RFC5363] and lets a client send a MESSAGE to a number of recipients at once 💌🌈

RFC 5366, Conference Establishment Using Request-Contained Lists in SIP (S): [RFC5366] uses the URI-list framework [RFC5363] too 🎉 it lets a client ask the server to act as a conference focus and send an invitation to each recipient in the list. group hangout, served 🍓

RFC 4240, Basic Network Media Services with SIP (I): [RFC4240] defines a way for SIP application servers to invoke announcement and conferencing services from a media server 🎙️ this happens through a set of defined URI parameters that tell the media server what to do, such as what file to play and what language to render it in. very helpful, very organised 🫶

RFC 4458, Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and Interactive Voice Response (IVR) (I): [RFC4458] defines a way to invoke voicemail and IVR services by using a SIP URI constructed in a particular way 📞💖

14. Minor Extensions

these SIP extensions don't fit neatly into one specific use case 🧩 they have somewhat general applicability, but they solve a relatively small problem or provide an optimisation. small but mighty, bestie 🦋✨

RFC 4488, Suppression of the SIP REFER Implicit Subscription (S): [RFC4488] is an enhancement to REFER 💅 normally REFER creates an implicit subscription to the target of the REFER. that subscription is used to pass back updates on the progress of the referral. this extension lets you bypass that implicit subscription as an optimisation 🙌

RFC 4538, Request Authorization through Dialog Identification in SIP (S): [RFC4538] provides a mechanism that lets a UAS authorise a request because the requestor proves it knows a dialog that is already in progress with the UAS 🔑💜 this spec is useful alongside the SIP application interaction framework [INTERACT-FRAME] 🫶

RFC 4508, Conveying Feature Tags with the REFER Method in SIP (S): [RFC4508] defines a mechanism for carrying RFC 3840 feature tags in REFER 🏷️ it's useful for telling the target of the REFER about the characteristics of the intended target of the referred request. very "here's who you're talking to" energy 💅

RFC 5373, Requesting Answer Modes for SIP (S): [RFC5373] defines an extension for indicating to the called party whether or not the phone should ring and/or be answered immediately 📱⚡ this is useful for push-to-talk and diagnostic applications 🎙️

RFC 5079, Rejecting Anonymous Requests in SIP (S): [RFC5079] defines a mechanism for a called party to tell the calling party that a call was rejected because the caller was anonymous 🙅‍♀️ this is needed for implementing the Anonymous Call Rejection (ACR) feature in SIP. no mystery callers allowed 🕵️‍♀️💀

RFC 5368, Referring to Multiple Resources in SIP (S): [RFC5368] lets a UA sending a REFER ask the recipient of the REFER to generate multiple SIP requests, not just one 🎯 this is useful for conferencing, where a client wants a conference server to eject multiple users at once. main character move 👑

RFC 4483, A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages (S): [RFC4483] defines a mechanism for content indirection 🔗 instead of carrying an object within a SIP body, a URL reference is carried instead, and the recipient dereferences the URL to get the object. it has potential for sending large instant messages, but it hasn't found much actual use yet 🥲

RFC 3890, A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP) (S): [RFC3890] specifies an SDP extension that describes the bandwidth for a media session in a way that's independent of the underlying transport mechanism 📊🌸

RFC 4583, Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams (S): [RFC4583] defines a mechanism in SDP to signal floor control streams that use BFCP 🎤 it's used for push-to-talk and conference floor control. who gets to talk next? this decides 🙋‍♀️

CONNECT-PRECON, Connectivity Preconditions for Session Description Protocol Media Streams (S): [CONNECT-PRECON] defines a usage of the precondition framework [RFC3312] ✅ the connectivity precondition makes sure the session doesn't get established until actual packet connectivity has been checked. no vibes-only connections here 🫠➡️💯

RFC 4796, The SDP (Session Description Protocol) Content Attribute (S): [RFC4796] defines an SDP attribute for describing the purpose of a media stream 🎬 examples include a slide view, the speaker, a sign language feed, and so on. so iconic for accessibility 🤟💜

IPv6-TRANS, IPv6 Transition in the Session Initiation Protocol (SIP) (S): [IPv6-TRANS] defines practices for interworking between IPv6 and IPv6 user agents 🌐 this is done through multi-homed proxies that interwork IPv4 and IPv6, along with ICE [ICE] for media traversal. the spec also includes some minor extensions and clarifications to SDP to cover some additional cases 🦋

CONNECT-REUSE, Connection Reuse in the Session Initiation Protocol (SIP) (S): [CONNECT-REUSE] defines an extension to SIP that lets a Transport Layer Security (TLS) connection between servers be reused for requests in both directions 🔁🔐 normally, two connections are set up between a pair of servers, one for requests in each direction. bestie really said "why have two when one can do" 💅✨

15. Security Mechanisms ✨

okay bestie, this section is all about the security features bolted onto SIP 🔒💖 several extensions give SIP extra protection, so let's go through them 🫶

RFC 4474, Enhancements for Authenticated Identity Management in SIP (S) 🪪 [RFC4474] defines a way to give the calling party a cryptographically verifiable identity inside a SIP request. it's called "SIP Identity" and it's the alternative to RFC 3325. honestly it hasn't been deployed much yet, but it's a key building block for anti-spam stuff and new security mechanisms, so it's a core part of the SIP specs 💅

RFC 4916, Connected Identity in the Session Initiation Protocol (SIP) (S) 👑 [RFC4916] formally updates RFC 3261 🎀 it lets the calling user find out the identity of the final called user (the connected party). and this can be different from who the caller was originally trying to reach, because of forwarding and retargeting services 🙈 it works together with the SIP identity spec [RFC4474] so the connected party identity can be signed. it can also be used when a party's identity changes mid call, due to third party call control actions or PSTN behavior ✨

SIPS-URI, The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP) (S) 🔐 [SIPS-URI] is meant to update RFC 3261 💜 it reworks how the SIPS URI gets processed (that one was originally defined in RFC 3261) to fix a bunch of errors and problems people ran into with it 🛠️

DOMAIN-CERTS, Domain Certificates in the Session Initiation Protocol (SIP) (B) 📜 [DOMAIN-CERTS] clarifies how SIP over TLS handles certificates, and defines extra procedures needed for interoperability 🦋

RFC 3323, A Privacy Mechanism for the Session Initiation Protocol (SIP) (S) 🕶️ [RFC3323] defines the Privacy header field, which clients use to ask for anonymity in their requests 🌸 it defines several privacy services, but the only one that's broadly used is the one protecting the P-Asserted-Identity header field [RFC3325] 💅

RFC 4567, Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP) (S) 🗝️ [RFC4567] adds SDP extensions that let a key management protocol, namely MIKEY [RFC3830], get tunneled through offer/answer exchanges 🎀 this is one of three SRTP keying techniques specified for SIP. the final pick was DTLS-SRTP [SRTP-FRAME] 👑

RFC 4568, Session Description Protocol (SDP) Security Descriptions for Media Streams (S) 🎧 [RFC4568] adds SDP extensions that negotiate keying material directly through offer/answer, no separate key management protocol needed 🫠 the catch (and it's a big one 😭) is that the media keys are visible to any entity that can see the SDP. this one's sometimes called sdescriptions. it's also one of three SRTP keying techniques for SIP, and DTLS-SRTP [SRTP-FRAME] was the one chosen as the final solution 🌈

SRTP-FRAME, Framework for Establishing an SRTP Security Context using DTLS (S) 🧩 [SRTP-FRAME] lays out the overall framework, plus the SDP and SIP processing needed to do key management for RTP using Datagram TLS (DTLS) [RFC4347] directly between endpoints, over the media path 🦋 it's one of the three SRTP keying techniques for SIP, and yep, it's the final solution, DTLS-SRTP [SRTP-FRAME] 🏆

RFC 3853, S/MIME Advanced Encryption Standard (AES) Requirement for SIP (S) 🔏 [RFC3853] formally updates RFC 3261 💖 it's a short spec that updates the cryptography used in SIP S/MIME. however, SIP S/MIME has seen very little deployment 🥲

CERTS, Certificate Management Service for the Session Initiation Protocol (SIP) (S) 📇 [CERTS] defines a certificate service for SIP, meant to make S/MIME easier to deploy 🌟 clients can store and retrieve their own certificates, and also grab certificates for other users 🫶

RFC 3893, Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format (S) 🧾 [RFC3893] defines a SIP message fragment that can be signed to provide an authenticated identity over a request 🍓 it was an early predecessor to [RFC4474], so AIB has seen zero deployment 💀

SAML, SIP SAML Profile and Binding (S) 🎫 [SAML] defines how to use the Security Assertion Markup Language (SAML) within SIP. it also explains how to pair it with SIP identity [RFC4474] to provide authenticated assertions about a user's role or attributes 💜

RFC 5360, A Framework for Consent-Based Communications in the Session Initiation Protocol (SIP) (S) 🙋‍♀️ [RFC5360] defines several SIP extensions, including the Trigger-Consent and Permission-Missing header fields 💅 together with the other procedures in the document, these set up a way to manage membership on "SIP mailing lists" used for instant messaging or conferencing. the big win here is it helps stop these amplification services from being abused for attacks on the network, by making sure a user actually authorizes their address being added to one 🛡️ no unwanted sign-ups, periodt ✨

RFC 5361, A Document Format for Requesting Consent (S) 📄 [RFC5361] defines an XML object used by the consent framework. consent documents get sent from SIP "mailing list servers" to users, so they can manage their membership on those lists 🌸

RFC 5362, The Session Initiation Protocol (SIP) Pending Additions Event Package (S) 📬 [RFC5362] defines a SIP event package that lets a UA learn whether consent has been given for adding an address to a SIP "mailing list" 🦋 it's used together with the SIP framework for consent [RFC5360] 🎀

RFC 3329, Security Mechanism Agreement for SIP (S) 🤝 [RFC3329] defines a mechanism to prevent bid-down attacks in conjunction with SIP authentication 🚫 it hasn't been deployed much. it was defined as part of the 3GPP IP Multimedia Subsystem (IMS) specification suite [3GPP.24.229], and it's only needed when a particular server has multiple security mechanisms deployed. in practice, that hasn't really been the case 🙃

RFC 4572, Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP) (S) 🔗 [RFC4572] specifies how to signal TLS-based media streams between endpoints 💖 it expands the TCP-based media signaling parameters defined in [RFC4145] to include fingerprint information for TLS streams, so TLS can work between end hosts using self-signed certificates 🪪

RFC 5027, Security Preconditions for Session Description Protocol Media Streams (S) 🚧 [RFC5027] defines a precondition for use with the preconditions framework [RFC3312] 🛑 the security precondition stops a session from being established until a security media stream is set up 🔐

RFC 3310, Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (S) 📱 [RFC3310] defines an extension to digest authentication so it can work with the credentials stored in cell phones 🎀 even though it technically extends HTTP digest, its main use is SIP 💜 it's mostly useful to IMS implementors 🧚

RFC 4169, Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA) Version-2 (S) 🆙 [RFC4169] is an enhancement to [RFC3310] that improves the security of the authentication even further 🌈

16. Conferencing 🎉

okay, conferencing! 🎤 lots of SIP and SDP extensions were built with conferencing as their main job, so let's meet them 💅

RFC 4574, The SDP (Session Description Protocol) Label Attribute (S) 🏷️ [RFC4574] defines an SDP attribute that gives media streams an opaque label 🌸 other documents can refer to these labels, especially conference policy documents 💖 this lets a UA tie together the documents it gets through conferencing mechanisms with the media streams they point to ✨

RFC 3911, The SIP Join Header Field (S) 🤝 [RFC3911] defines the Join header field 🎀 when it's sent in an INVITE, the recipient joins the resulting dialog into a conference with another dialog that's already in progress 🫶

RFC 4575, A SIP Event Package for Conference State (S) 📡 [RFC4575] defines a mechanism for finding out about changes in conference state, including conference membership 👑

RFC 5368, Referring to Multiple Resources in SIP (S) 🎯 [RFC5368] lets a UA sending a REFER ask the REFER's recipient to generate multiple SIP requests, not just one 🦋 this is super useful for conferencing, like when a client wants a conference server to eject multiple users at once 🙅‍♀️

RFC 5366, Conference Establishment Using Request-Contained Lists in SIP (S) 📋 [RFC5366] is similar to [RFC5367] 🧁 but instead of subscribing to the resource, an INVITE gets sent to the resource. it acts as a conference focus and generates an invitation for each recipient in the list 🎉

RFC4579, Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents (B) 📘 [RFC4579] defines best practice procedures and call flows for conferencing 💜 that includes conference creation, joining, and dial out, among other capabilities ✨

RFC 4583, Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams (S) 🎙️ [RFC4583] defines a mechanism in SDP for signaling floor control streams that use BFCP 🫧 it's used for push-to-talk and conference floor control 🗣️

17. Instant Messaging, Presence, and Multimedia 💬

SIP has extensions for instant messaging, presence, and multimedia too, so let's finish up this part 🦋

RFC 3428, SIP Extension for Instant Messaging (S) 💌 [RFC3428] defines the MESSAGE method, used for sending an instant message without setting up a session (sometimes called "page mode") 🍓

RFC 3856, A Presence Event Package for SIP (S) 🟢 [RFC3856] defines an event package for indicating user presence through SIP 🌈

RFC 3857, A Watcher Information Event Template Package for SIP (S) 👀 [RFC3857], also known as winfo, gives a user agent a way to find out what subscriptions are in place for a particular event package 🧚 its main use is with presence, but it works with any event package 💖

TRANSFER-MECH, A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer (S) 📁 [TRANSFER-MECH] defines a mechanism for signaling a file transfer session with SIP 🚀✨

18. Emergency Services 🚨✨

okay so emergency services are literally the most important part 🫶 they include preemption features, which let authorized people get into network resources when there's an emergency, plus the classic emergency calling we all know 📞

RFC 4411, Extending the SIP Reason Header for Preemption Events (S): [RFC4411] defines an extension to the Reason header. it lets a UA know that its dialog got torn down because a higher priority session came through 😭
RFC 4412, Communications Resource Priority for SIP (S): [RFC4412] defines a new header field, Resource-Priority, that lets a session get priority treatment from the network 💅
LOCATION, Location Conveyance for the Session Initiation Protocol (S): [LOCATION] defines a mechanism for carrying location objects in SIP messages. this is how location gets conveyed from a UA to an emergency call taker 📍🧚

19. Security Considerations 🔐

okay bestie, this spec is basically an overview of specs that already exist, so it doesn't bring any security considerations of its own 💜 but ngl the world would be SO much more secure if everyone followed one simple rule: "Don't Panic!" [HGTTG] 🌌🙈

20. Acknowledgements 🎀

huge thanks to Spencer Dawkins, Brian Stucker, Keith Drage, John Elwell, and Avshalom Houri for their comments on this document 🫶💖 the author is so grateful!!

21. Informative References 📚🦋

[3GPP.24.229]     3GPP, "Internet Protocol (IP) multimedia call
                  control protocol based on Session Initiation
                  Protocol (SIP) and Session Description Protocol
                  (SDP); Stage 3", 3GPP TS 24.229 5.22.0,
                  September 2008.

[ABNF-FIX]        Gurbani, V. and B. Carpenter, "Essential correction
                  for IPv6 ABNF in RFC3261", Work in Progress,
                  November 2007.

[BODY-HANDLING]   Camarillo, G., "Message Body Handling in the
                  Session Initiation Protocol (SIP)", Work
                  in Progress, November 2008.

[CERTS]           Jennings, C. and J. Fischl, "Certificate Management
                  Service for The Session Initiation Protocol (SIP)",
                  Work in Progress, November 2008.

[CONFIG-FRAME]    Channabasappa, S., "A Framework for Session
                  Initiation Protocol User Agent Profile Delivery",
                  Work in Progress, February 2008.

[CONNECT-PRECON]  Andreasen, F., Camarillo, G., Oran, D., and D.
                  Wing, "Connectivity Preconditions for Session
                  Description Protocol Media Streams", Work
                  in Progress, October 2008.

[CONNECT-REUSE]   Gurbani, V., Mahy, R., and B. Tate, "Connection
                  Reuse in the Session Initiation Protocol (SIP)",
                  Work in Progress, October 2008.

[DOMAIN-CERTS]    Gurbani, V., Lawrence, S., and B. Laboratories,
                  "Domain Certificates in the Session Initiation
                  Protocol (SIP)", Work in Progress, October 2008.

[ECRIT-FRAME]     Rosen, B., Schulzrinne, H., Polk, J., and A.
                  Newton, "Framework for Emergency Calling using
                  Internet Multimedia", Work in Progress, July 2008.

[GRUU]            Rosenberg, J., "Obtaining and Using Globally
                  Routable User Agent (UA) URIs (GRUU) in the Session
                  Initiation Protocol (SIP)", Work in Progress,
                  October 2007.

[GRUU-REG]        Kyzivat, P., "Registration Event Package Extension
                  for Session Initiation Protocol (SIP)  Globally
                  Routable User Agent URIs (GRUUs)", Work
                  in Progress, July 2007.

[HGTTG]           Adams, D., "The Hitchhiker's Guide to the Galaxy",
                  September 1979.

[ICE]             Rosenberg, J., "Interactive Connectivity
                  Establishment (ICE): A Protocol for Network Address
                  Translator (NAT) Traversal for Offer/Answer
                  Protocols", Work in Progress, October 2007.

[ICE-TCP]         Rosenberg, J., "TCP Candidates with Interactive
                  Connectivity Establishment (ICE)", Work
                  in Progress, July 2008.

[INTERACT-FRAME]  Rosenberg, J., "A Framework for Application
                  Interaction in the Session Initiation Protocol
                  (SIP)", Work in Progress, July 2005.

[IPv6-TRANS]      Camarillo, G., "IPv6 Transition in the Session
                  Initiation Protocol (SIP)", Work in Progress,
                  August 2007.

[LOCATION]        Polk, J. and B. Rosen, "Location Conveyance for the
                  Session Initiation Protocol", Work in Progress,
                  November 2008.

[LOOP-FIX]        Sparks, R., Lawrence, S., Hawrylyshen, A., and B.
                  Campen, "Addressing an Amplification Vulnerability
                  in Session Initiation Protocol  (SIP) Forking
                  Proxies", Work in Progress, October 2008.

[OPTION-TAG]      Rosenberg, J., "Indicating Support for Interactive
                  Connectivity Establishment (ICE) in the Session
                  Initiation Protocol (SIP)", Work in Progress,
                  June 2007.

[OUTBOUND]        Jennings, C. and R. Mahy, "Managing Client
                  Initiated Connections in the Session Initiation
                  Protocol  (SIP)", Work in Progress, October 2008.

[POLICY-PACK]     Hilt, V. and G. Camarillo, "A Session Initiation
                  Protocol (SIP) Event Package for Session-Specific
                  Session Policies.", Work in Progress, July 2008.

[QoS-ID]          Polk, J., Dhesikan, S., and G. Camarillo, "Quality

                  of Service (QoS) Mechanism Selection in the Session
                  Description Protocol (SDP)", Work in Progress,
                  November 2008.

[RECORD-ROUTE]    Froment, T., Lebel, C., and B. Bonnaerens,
                  "Addressing Record-Route issues in the Session
                  Initiation Protocol (SIP)", Work in Progress,
                  October 2008.

[RFC2026]         Bradner, S., "The Internet Standards Process --
                  Revision 3", BCP 9, RFC 2026, October 1996.

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

[RFC2782]         Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS
                  RR for specifying the location of services (DNS
                  SRV)", RFC 2782, February 2000.

[RFC2848]         Petrack, S. and L. Conroy, "The PINT Service
                  Protocol: Extensions to SIP and SDP for IP Access
                  to Telephone Call Services", RFC 2848, June 2000.

[RFC2976]         Donovan, S., "The SIP INFO Method", RFC 2976,
                  October 2000.

[RFC3087]         Campbell, B. and R. Sparks, "Control of Service
                  Context using SIP Request-URI", RFC 3087,
                  April 2001.

[RFC3204]         Zimmerer, E., Peterson, J., Vemuri, A., Ong, L.,
                  Audet, F., Watson, M., and M. Zonoun, "MIME media
                  types for ISUP and QSIG Objects", RFC 3204,
                  December 2001.

[RFC3261]         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.

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

[RFC3263]         Rosenberg, J. and H. Schulzrinne, "Session
                  Initiation Protocol (SIP): Locating SIP Servers",
                  RFC 3263, June 2002.

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

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

[RFC3310]         Niemi, A., Arkko, J., and V. Torvinen, "Hypertext
                  Transfer Protocol (HTTP) Digest Authentication
                  Using Authentication and Key Agreement (AKA)",
                  RFC 3310, September 2002.

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

[RFC3312]         Camarillo, G., Marshall, W., and J. Rosenberg,
                  "Integration of Resource Management and Session
                  Initiation Protocol (SIP)", RFC 3312, October 2002.

[RFC3313]         Marshall, W., "Private Session Initiation Protocol
                  (SIP) Extensions for Media Authorization",
                  RFC 3313, January 2003.

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

[RFC3323]         Peterson, J., "A Privacy Mechanism for the Session
                  Initiation Protocol (SIP)", RFC 3323,
                  November 2002.

[RFC3325]         Jennings, C., Peterson, J., and M. Watson, "Private
                  Extensions to the Session Initiation Protocol (SIP)
                  for Asserted Identity within Trusted Networks",
                  RFC 3325, November 2002.

[RFC3326]         Schulzrinne, H., Oran, D., and G. Camarillo, "The
                  Reason Header Field for the Session Initiation
                  Protocol (SIP)", RFC 3326, December 2002.

[RFC3327]         Willis, D. and B. Hoeneisen, "Session Initiation
                  Protocol (SIP) Extension Header Field for
                  Registering Non-Adjacent Contacts", RFC 3327,
                  December 2002.

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

[RFC3372]         Vemuri, A. and J. Peterson, "Session Initiation
                  Protocol for Telephones (SIP-T): Context and
                  Architectures", BCP 63, RFC 3372, September 2002.

[RFC3388]         Camarillo, G., Eriksson, G., Holler, J., and H.
                  Schulzrinne, "Grouping of Media Lines in the
                  Session Description Protocol (SDP)", RFC 3388,
                  December 2002.

[RFC3398]         Camarillo, G., Roach, A., Peterson, J., and L. Ong,
                  "Integrated Services Digital Network (ISDN) User
                  Part (ISUP) to Session Initiation Protocol (SIP)
                  Mapping", RFC 3398, December 2002.

[RFC3401]         Mealling, M., "Dynamic Delegation Discovery System
                  (DDDS) Part One: The Comprehensive DDDS", RFC 3401,
                  October 2002.

[RFC3420]         Sparks, R., "Internet Media Type message/sipfrag",
                  RFC 3420, November 2002.

[RFC3427]         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.

okay bestie, the reference list keeps going and it's still giving main character energy 📚✨

[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[RFC3482] Foster, M., McGarry, T., and J. Yu, "Number Portability in the Global Switched Telephone Network (GSTN): An Overview", RFC 3482, February 2003.
[RFC3486] Camarillo, G., "Compressing the Session Initiation Protocol (SIP)", RFC 3486, February 2003.
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[RFC3524] Camarillo, G. and A. Monrad, "Mapping of Media Streams to Resource Reservation Flows", RFC 3524, April 2003.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3578] Camarillo, G., Roach, A., Peterson, J., and L. Ong, "Mapping of Integrated Services Digital Network (ISDN) User Part (ISUP) Overlap Signalling to the Session Initiation Protocol (SIP)", RFC 3578, August 2003.
[RFC3581] Rosenberg, J. and H. Schulzrinne, "An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing", RFC 3581, August 2003.
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, October 2003.
[RFC3608] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration", RFC 3608, October 2003.
[RFC3665] 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.
[RFC3666] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and K. Summers, "Session Initiation Protocol (SIP) Public Switched Telephone Network (PSTN) Call Flows", BCP 76, RFC 3666, December 2003.
[RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Registrations", RFC 3680, March 2004.
[RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004.
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004.
[RFC3842] Mahy, R., "A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP)", RFC 3842, August 2004.
[RFC3853] Peterson, J., "S/MIME Advanced Encryption Standard (AES) Requirement for the Session Initiation Protocol (SIP)", RFC 3853, July 2004.
[RFC3856] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[RFC3857] Rosenberg, J., "A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP)", RFC 3857, August 2004.
[RFC3890] Westerlund, M., "A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP)", RFC 3890, September 2004.
[RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, September 2004.
[RFC3892] Sparks, R., "The Session Initiation Protocol (SIP) Referred-By Mechanism", RFC 3892, September 2004.
[RFC3893] Peterson, J., "Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format", RFC 3893, September 2004.
[RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004.
[RFC3910] Gurbani, V., Brusilovsky, A., Faynberg, I., Gato, J., Lu, H., and M. Unmehopa, "The SPIRITS (Services in PSTN requesting Internet Services) Protocol", RFC 3910, October 2004.
[RFC3911] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP) "Join" Header", RFC 3911, October 2004.
[RFC3959] Camarillo, G., "The Early Session Disposition Type for the Session Initiation Protocol (SIP)", RFC 3959, December 2004.
[RFC3960] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)", RFC 3960, December 2004.
[RFC4028] Donovan, S. and J. Rosenberg, "Session Timers in the Session Initiation Protocol (SIP)", RFC 4028, April 2005.
[RFC4032] Camarillo, G. and P. Kyzivat, "Update to the Session Initiation Protocol (SIP) Preconditions Framework", RFC 4032, March 2005.
[RFC4091] Camarillo, G. and J. Rosenberg, "The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework", RFC 4091, June 2005.
[RFC4117] Camarillo, G., Burger, E., Schulzrinne, H., and A. van Wijk, "Transcoding Services Invocation in the Session Initiation Protocol (SIP) Using Third Party Call Control (3pcc)", RFC 4117, June 2005.
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005.
[RFC4168] Rosenberg, J., Schulzrinne, H., and G. Camarillo, "The Stream Control Transmission Protocol (SCTP) as a Transport for the Session Initiation Protocol (SIP)", RFC 4168, October 2005.
[RFC4169] Torvinen, V., Arkko, J., and M. Naslund, "Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA) Version-2", RFC 4169, November 2005.
[RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", RFC 4235, November 2005.
[RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network Media Services with SIP", RFC 4240, December 2005.
[RFC4244] Barnes, M., "An Extension to the Session Initiation Protocol (SIP) for Request History Information", RFC 4244, November 2005.
[RFC4320] Sparks, R., "Actions Addressing Identified Issues with the Session Initiation Protocol's (SIP) Non-INVITE Transaction", RFC 4320, January 2006.
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[RFC4411] Polk, J., "Extending the Session Initiation Protocol (SIP) Reason Header for Preemption Events", RFC 4411, February 2006.
[RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource Priority for the Session Initiation Protocol (SIP)", RFC 4412, February 2006.
[RFC4458] Jennings, C., Audet, F., and J. Elwell, "Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and Interactive Voice Response (IVR)", RFC 4458, April 2006.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4483] Burger, E., "A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages", RFC 4483, May 2006.
[RFC4488] Levin, O., "Suppression of Session Initiation Protocol (SIP) REFER Method Implicit Subscription", RFC 4488, May 2006.
[RFC4497] Elwell, J., Derks, F., Mourot, P., and O. Rousseau, "Interworking between the Session Initiation Protocol (SIP) and QSIG", BCP 117, RFC 4497, May 2006.
[RFC4508] Levin, O. and A. Johnston, "Conveying Feature Tags with the Session Initiation Protocol (SIP) REFER Method", RFC 4508, May 2006.
[RFC4538] Rosenberg, J., "Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP)", RFC 4538, June 2006.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. Carrara, "Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)", RFC 4567, July 2006.
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, July 2006.
[RFC4572] Lennox, J., "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 4572, July 2006.
[RFC4574] Levin, O. and G. Camarillo, "The Session Description Protocol (SDP) Label Attribute", RFC 4574, August 2006.
[RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, August 2006.

[RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents", BCP 119, RFC 4579, August 2006. 📞

[RFC4583] Camarillo, G., "Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams", RFC 4583, November 2006. 🎀

[RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists", RFC 4662, August 2006. 📋

[RFC4730] Burger, E. and M. Dolly, "A Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML)", RFC 4730, November 2006. ⌨️

[RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals", RFC 4733, December 2006. 🔢

[RFC4796] Hautakorpi, J. and G. Camarillo, "The Session Description Protocol (SDP) Content Attribute", RFC 4796, February 2007. 🧩

[RFC4896] Surtees, A., West, M., and A. Roach, "Signaling Compression (SigComp) Corrections and Clarifications", RFC 4896, June 2007. 🗜️

[RFC4916] Elwell, J., "Connected Identity in the Session Initiation Protocol (SIP)", RFC 4916, June 2007. 🪪

[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007. 🚚

[RFC5027] Andreasen, F. and D. Wing, "Security Preconditions for Session Description Protocol (SDP) Media Streams", RFC 5027, October 2007. 🔐

[RFC5049] Bormann, C., Liu, Z., Price, R., and G. Camarillo, "Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP)", RFC 5049, December 2007. 🗜️

[RFC5079] Rosenberg, J., "Rejecting Anonymous Requests in the Session Initiation Protocol (SIP)", RFC 5079, December 2007. 🚫

[RFC5360] Rosenberg, J., Camarillo, G., and D. Willis, "A Framework for Consent-Based Communications in the Session Initiation Protocol (SIP)", RFC 5360, October 2008. 🤝

[RFC5361] Camarillo, G., "A Document Format for Requesting Consent", RFC 5361, October 2008. ✅

[RFC5362] Camarillo, G., "The Session Initiation Protocol (SIP) Pending Additions Event Package", RFC 5362, October 2008. ⏳

[RFC5363] Camarillo, G. and A. Roach, "Framework and Security Considerations for Session Initiation Protocol (SIP) URI-List Services", RFC 5363, October 2008. 🔒

[RFC5365] Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol (SIP)", RFC 5365, October 2008. 💌

[RFC5366] Camarillo, G. and A. Johnston, "Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP)", RFC 5366, October 2008. 🎉

[RFC5367] Camarillo, G., Roach, A., and O. Levin, "Subscriptions to Request-Contained Resource Lists in the Session Initiation Protocol (SIP)", RFC 5367, October 2008. 📚

[RFC5368] Camarillo, G., Niemi, A., Isomaki, M., Garcia-Martin, M., and H. Khartabil, "Referring to Multiple Resources in the Session Initiation Protocol (SIP)", RFC 5368, October 2008. 👯

[RFC5373] Willis, D. and A. Allen, "Requesting Answering Modes for the Session Initiation Protocol (SIP)", RFC 5373, November 2008. 📲

[RTCP-SUM] Clark, A., Pendleton, A., Johnston, A., and H. Sinnreich, "Session Initiation Protocol Package for Voice Quality Reporting Event", Work in Progress, October 2008. 📊

[SAML] Tschofenig, H., Hodges, J., Peterson, J., Polk, J., and D. Sicker, "SIP SAML Profile and Binding", Work in Progress, November 2008. 🪪

[SDP-CAP] Andreasen, F., "SDP Capability Negotiation", Work in Progress, July 2008. 🤳

[SDP-MEDIA] Gilman, R., Even, R., and F. Andreasen, "SDP media capabilities Negotiation", Work in Progress, July 2008. 🎬

[SESSION-POLICY] Hilt, V., Camarillo, G., and J. Rosenberg, "A Framework for Session Initiation Protocol (SIP) Session Policies", Work in Progress, November 2008. 📜

[SIMPLE] Rosenberg, J., "SIMPLE made Simple: An Overview of the IETF Specifications for Instant Messaging and Presence using the Session Initiation Protocol (SIP)", Work in Progress, October 2008. 💬

[SIPS-URI] Audet, F., "The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)", Work in Progress, November 2008. 🔐

[SRTP-FRAME] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for Establishing an SRTP Security Context using DTLS", Work in Progress, October 2008. 🔑

[SUBNOT-ETAGS] Niemi, A., "An Extension to Session Initiation Protocol (SIP) Events for Conditional Event Notification", Work in Progress, July 2008. 🏷️

[TRANSFER-MECH] Garcia, M., Isomaki, M., Camarillo, G., Loreto, S., and P. Kyzivat, "A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer", Work in Progress, November 2008. 📁

[UA-PRIVACY] Munakata, M., Schubert, S., and T. Ohba, "UA-Driven Privacy Mechanism for SIP", Work in Progress, October 2008. 🙈

[UPDATE-PAI] Elwell, J., "Updates to Asserted Identity in the Session Initiation Protocol (SIP)", Work in Progress, October 2008. 🆔

Author's Address ✨

Jonathan Rosenberg, the author, is at Cisco in Iselin, NJ, US. 🏢

EMail: jdrosen@cisco.com 💌
URI: http://www.jdrosen.net 🌐

Full Copyright Statement 🎀

This document is subject to the rights, licenses and restrictions in BCP 78. Apart from what BCP 78 sets out, the authors keep all of their rights. 🦋

This document and the info in it are handed over "AS IS". THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE say no to ALL warranties, express or implied. That includes no promise that using the info won't infringe anyone's rights, and no implied warranties of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. 🙅‍♀️

Intellectual Property 💜

The IETF doesn't take a side on whether any Intellectual Property Rights, or other rights that someone might claim, are valid or how far they reach. The same goes for whether anyone's implementing or using this technology needs a license, and whether one is available. It also doesn't say it has done any independent work to find such rights. 🧐 BCP 78 and BCP 79 explain how rights work for RFC documents. 📖

Copies of IPR disclosures sent to the IETF Secretariat, plus any promises to license, or the result of an attempt to get a general license or permission for implementers or users to use proprietary rights in this spec, can be found in the IETF's online IPR repository at http://www.ietf.org/ipr. 🗂️

The IETF invites anyone who's interested to flag any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org. 📬🫶

📦 where this page comes from

ietf: rfc5411 2009-02
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms