RFC 5850
A Call Control and Multi-Party Usage Framework for the Session Initiation Protocol (SIP)
RFC 5850: A Call Control and Multi-Party Usage Framework for SIP 📞✨
Part 1 of 10 🎀
Okay bestie, so this is the paper that wrote the rulebook for how multi-party calls and call control work in SIP (the Session Initiation Protocol 💖). It came out in May 2010 🌸 and it's an Informational document, which means it's a helpful guide and not an Internet Standards Track spec 🧚. The authors are R. Mahy (Unaffiliated), R. Sparks (Tekelec), J. Rosenberg (jdrosen.net), D. Petrie (SIPez), and A. Johnston, Ed. (Avaya) 👑. It's published under ISSN 2070-1721, and the header doesn't list any RFCs it obsoletes or updates 🦋.
Abstract ✨
Here's the vibe in a nutshell 💅. This document sets up a framework and the requirements for call control and multi-party usage of SIP. To make it easier to talk about multi-party features and apps, it defines an abstract call model that describes the media relationships that a lot of these features need 🫶. The best part is that the model and its actions are deliberately independent of the SIP signaling and/or mixing approach you pick to actually set up those media relationships 🔥. On top of dialog manipulation, the framework also has requirements for sharing related info and events, like conference and session state and session history 📚. It also lays out other goals that match the spirit of SIP apps on the Internet 🌈: defining primitives (not services), invoker and participant oriented primitives, signaling and mixing model independence, and a few others 💜.
Status of This Memo 🎀
Not an Internet Standards Track spec, just published for info 🧸. It's a product of the IETF and reflects the consensus of the IETF community 💖. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 🌟. Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 for the details 🙈.
Want the latest status, errata, or a way to send feedback? Head to http://www.rfc-editor.org/info/rfc5850 🦋.
Copyright Notice 💅
Copyright (c) 2010 IETF Trust and the people listed as authors. All rights reserved 🔒.
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can read at http://trustee.ietf.org/license-info and which apply on the publication date 📜. Read those carefully, because they spell out your rights and restrictions 🫶. Any Code Components pulled out of this doc have to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come with no warranty, as described in the Simplified BSD License 🧚.
Okay, this next part is a little bit serious, so pay attention 👀. This document might have material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008 🕰️. The people who control the copyright in some of that material might not have given the IETF Trust permission to allow changes to it outside the IETF Standards Process 🙈. So unless you get an adequate license from those copyright holders, this doc can't be modified outside the IETF Standards Process, and you can't make derivative works of it outside that process 🚫. The one exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌍.
Table of Contents 🧚
Internet Engineering Task Force (IETF) R. MahyWait, that's the header. Here's the real table of contents, verbatim so the section numbers still line up 🍓:
1. Motivation and Background . . . . . . . . . . . . . . . . . . 4
2. Key Concepts . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Conversation Space Model . . . . . . . . . . . . . . . . . 7
2.2. Relationship between Conversation Space, SIP Dialogs,
and SIP Sessions . . . . . . . . . . . . . . . . . . . . . 8
2.3. Signaling Models . . . . . . . . . . . . . . . . . . . . . 9
2.4. Mixing Models . . . . . . . . . . . . . . . . . . . . . . 10
2.4.1. Tightly Coupled . . . . . . . . . . . . . . . . . . . 11
2.4.2. Loosely Coupled . . . . . . . . . . . . . . . . . . . 12
2.5. Conveying Information and Events . . . . . . . . . . . . . 13
2.6. Componentization and Decomposition . . . . . . . . . . . . 15
2.6.1. Media Intermediaries . . . . . . . . . . . . . . . . . 15
2.6.2. Text-to-Speech and Automatic Speech Recognition . . . 17
2.6.3. VoiceXML . . . . . . . . . . . . . . . . . . . . . . . 17
2.7. Use of URIs . . . . . . . . . . . . . . . . . . . . . . . 18
2.7.1. Naming Users in SIP . . . . . . . . . . . . . . . . . 19
2.7.2. Naming Services with SIP URIs . . . . . . . . . . . . 20
2.8. Invoker Independence . . . . . . . . . . . . . . . . . . . 22
2.9. Billing Issues . . . . . . . . . . . . . . . . . . . . . . 23
3. Catalog of Call Control Actions and Sample Features . . . . . 23
3.1. Remote Call Control Actions on Early Dialogs . . . . . . . 24
3.1.1. Remote Answer . . . . . . . . . . . . . . . . . . . . 24
3.1.2. Remote Forward or Put . . . . . . . . . . . . . . . . 24
3.1.3. Remote Busy or Error Out . . . . . . . . . . . . . . . 24
3.2. Remote Call Control Actions on Single Dialogs . . . . . . 24
3.2.1. Remote Dial . . . . . . . . . . . . . . . . . . . . . 24
3.2.2. Remote On and Off Hold . . . . . . . . . . . . . . . . 25
3.2.3. Remote Hangup . . . . . . . . . . . . . . . . . . . . 25
3.3. Call Control Actions on Multiple Dialogs . . . . . . . . . 25
3.3.1. Transfer . . . . . . . . . . . . . . . . . . . . . . . 25
3.3.2. Take . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3.3. Add . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.4. Local Join . . . . . . . . . . . . . . . . . . . . . . 28
3.3.5. Insert . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3.6. Split . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3.7. Near-Fork . . . . . . . . . . . . . . . . . . . . . . 29
3.3.8. Far-Fork . . . . . . . . . . . . . . . . . . . . . . . 29
4. Security Considerations . . . . . . . . . . . . . . . . . . . 30
Appendix A. Example Features . . . . . . . . . . . . . . . . . 32
Appendix A.1. Attended Transfer . . . . . . . . . . . . . . . . . 32
Appendix A.2. Auto Answer . . . . . . . . . . . . . . . . . . . . 32
Appendix A.3. Automatic Callback . . . . . . . . . . . . . . . . 32
Appendix A.4. Barge-In . . . . . . . . . . . . . . . . . . . . . 32
Appendix A.5. Blind Transfer . . . . . . . . . . . . . . . . . . 32
Appendix A.6. Call Forwarding . . . . . . . . . . . . . . . . . . 33
Appendix A.7. Call Monitoring . . . . . . . . . . . . . . . . . . 33
Appendix A.8. Call Park . . . . . . . . . . . . . . . . . . . . . 33
Appendix A.9. Call Pickup . . . . . . . . . . . . . . . . . . . . 33
Appendix A.10. Call Return . . . . . . . . . . . . . . . . . . . . 34
Appendix A.11. Call Waiting . . . . . . . . . . . . . . . . . . . 34
Appendix A.12. Click-to-Dial . . . . . . . . . . . . . . . . . . . 34
Appendix A.13. Conference Call . . . . . . . . . . . . . . . . . . 34
Appendix A.14. Consultative Transfer . . . . . . . . . . . . . . . 34
Appendix A.15. Distinctive Ring . . . . . . . . . . . . . . . . . 35
Appendix A.16. Do Not Disturb . . . . . . . . . . . . . . . . . . 35
Appendix A.17. Find-Me . . . . . . . . . . . . . . . . . . . . . . 35
Appendix A.18. Hotline . . . . . . . . . . . . . . . . . . . . . . 35
Appendix A.19. IM Conference Alerts . . . . . . . . . . . . . . . 35
Appendix A.20. Inbound Call Screening . . . . . . . . . . . . . . 35
Appendix A.21. Intercom . . . . . . . . . . . . . . . . . . . . . 36
Appendix A.22. Message Waiting . . . . . . . . . . . . . . . . . . 36
Appendix A.23. Music on Hold . . . . . . . . . . . . . . . . . . . 36
Appendix A.24. Outbound Call Screening . . . . . . . . . . . . . . 36
Appendix A.25. Pre-Paid Calling . . . . . . . . . . . . . . . . . 37
Appendix A.26. Presence-Enabled Conferencing . . . . . . . . . . . 37
Appendix A.27. Single Line Extension/Multiple Line Appearance . . 37
Appendix A.28. Speakerphone Paging . . . . . . . . . . . . . . . . 38
Appendix A.29. Speed Dial . . . . . . . . . . . . . . . . . . . . 38
Appendix A.30. Voice Message Screening . . . . . . . . . . . . . . 38
Appendix A.31. Voice Portal . . . . . . . . . . . . . . . . . . . 39
Appendix A.32. Voicemail . . . . . . . . . . . . . . . . . . . . . 40
Appendix A.33. Whispered Call Waiting . . . . . . . . . . . . . . 40
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 40
5. Informative References . . . . . . . . . . . . . . . . . . . . 401. Motivation and Background ✨
okay so the Session Initiation Protocol (SIP) [RFC3261] was built for starting, keeping up, and ending sessions or calls between one or more users 📞. but here's the tea 🫖: even though it started out as a big multi-party conferencing protocol, SIP is mostly used today for point-to-point calls. two-party calls are the main focus of the SIP spec and most of its extensions 💖
this document sets up a framework and the requirements for call control and multi-party usage of SIP 🦋. most multi-party operations mess with SIP dialogs (aka call legs) or SIP conference media policy so the participants perceive specific media relationships 👀. other protocols that deal with calls call this kind of manipulation call control. call control also covers passing along information and events about all that manipulating, including stuff about session state and history, conference state, user state, and even message state 🌸
so the authors went to the SIP community, asked what they wanted, and came back with this list of goals for SIP call control and multi-party apps 🎀:
- Define primitives, not services. 💅 the goal is a handful of robust yet simple mechanisms that can be mixed together to build features and services. we call these simple mechanisms "primitives" throughout this document. primitives should be robust enough that when you combine them, you can build lots of services 🧩. but the goal is not to define a provably complete set of primitives. also, while the IETF will NOT standardize behavior or services, it may define example services for informational purposes, like in service examples [RFC5359] ✨
- Be participant oriented. primitives should be designed to give services that are centered on the experience of the participants 🫶. the authors noticed that end users of features and services usually don't care how a media relationship gets set up 🙈
Their ultimate experience is based only on the resulting media and other externally visible characteristics 💜
- Be signaling model independent. support both a central-control and a peer-to-peer feature invocation model (and combos of the two) 🧚. baseline SIP already supports a centralized control model described in 3pcc (third party call control) [RFC3725], and the SIP community is super into peer-to-peer or distributed call control using primitives like the ones defined in REFER [RFC3515], Replaces [RFC3891], and Join [RFC3911] 🔥
- Be mixing model independent. most of the interesting multi-party apps involve mixing or combining media from multiple participants 🎶. that mixing can be done by one or more of the participants, or by a centralized mixing resource 🌈. the participants' experience should not depend on which mixing model is used. while most examples in this document are about audio mixing, the framework applies to any media type ⭐. in this context, a "mixer" means combining media of the same type in an appropriate, media-specific way 🍓. this matches the model described in the SIP conferencing framework
- Be invoker oriented. only the user who invokes a feature or service needs to know exactly which service is being invoked, or why 👑. this is great because new services can be created without needing new primitives from all of the participants 💅. it also allows much simpler feature authorization policies, for example when participation spans organizational boundaries 🦋. as discussed in Section 2.7, this also avoids exponential state explosion when combining features 💀. the invoker only has to manage a user interface or application programming interface (API) to prevent local feature interactions 🌸. everyone else just needs to manage the feature interactions of a much smaller number of primitives 🫶
- Primitives make full use of URIs (uniform resource identifiers). URIs are super powerful for describing users and services 🌈. they're a plentiful resource, extremely expressive, and easy to route, translate, and manipulate, even across organizational boundaries ✨. URIs can contain special parameters and informational header fields that only need to matter to the owner of the URI's namespace (domain) 🎀. just like a user who clicks an http: URL doesn't need to understand the significance and organization of the website it points to, a user might run into a SIP URI that translates into an email-style group alias, which plays a pre-recorded message or runs some complex call-handling logic 📼. yes, this might seem paradoxical to the previous goal, but both goals can be satisfied by the same model 🧠
- Make use of SIP header fields and SIP event packages to give SIP entities information about their environment 👀. this should include info about the status and handling of dialogs on other user agents (UAs), the history of other contacts attempted before the current contact, the status of participants, the status of conferences, user presence information, and the status of messages 💌
- Encourage service decomposition, and design to use standard components with well-defined, simple interfaces 🧩. sample components include a SIP mixer, recording service, announcement server, and voice-dialog server. (this is not an exhaustive list 🙃)
- Include authentication, authorization, policy, logging, and accounting mechanisms so these primitives can be used safely among mutually untrusted participants 🔐. some of these mechanisms may help with billing, but no specific billing system will be endorsed 💸
- Permit graceful fallback to baseline SIP. definitions for new SIP call control extensions/primitives must describe a graceful way to fall back to baseline SIP behavior 🛟. support for one primitive must not imply support for another primitive 🙅♀️
- Don't reinvent traditional models, like the model used for the H.450 family of protocols, JTAPI (Java Telephony Application Programming Interface), or the CSTA (Computer-supported telecommunications applications) call model 🚫. these other models don't share the design goals in this document, so no copy-pasting them 💅
Note that the flexibility in this model does come with some interoperability downsides 😬. it's possible to build a call control feature in SIP using different combos of primitives. for a discussion of the issues with this, see [BLISS-PROBLEM] 📚
2. Key Concepts 🔑
This section introduces a bunch of key concepts that the rest of the document uses to describe and explain call control operations and services 🧠. it covers the conversation space model, signaling and mixing models, common components, and how URIs get used 🌸
2.1. Conversation Space Model 🫧
okay, so this document introduces the idea of an abstract "conversation space" 💬. it's a set of participants who all believe they're communicating with one another 🫶. every conversation space has one or more participants 👑.
participants are SIP UAs that send original media to other members of the conversation space, or terminate and receive media from them 🦋. logically, every participant in the conversation space has access to all the media generated in that space (this is strictly true if all participants share a common media type) ✨. a SIP UA that doesn't contribute or consume any media is NOT a participant 🙅♀️. same goes for a UA that just forwards, transcodes, mixes, or selects media that came from somewhere else in the conversation space 💅
Note that a conversation space consists of zero or more SIP calls or SIP conferences. a conversation space is similar to the definition of a "call" in some other call models 🎀
participants can be human users or non-human users (the document calls these robots or automatons) 🤖. some participants might be hidden within a conversation space 🙈. some examples of hidden participants: robots that generate tones, images, or announcements during a conference to say when users arrive and leave 🔔, a human call center supervisor quietly monitoring a conversation between a trainee and a customer 🎧, and robots that record media for training or archival purposes 📼
participants can also be active or passive 💖. active participants are expected to be smart enough to leave a conversation space when they don't want to participate anymore 🚪. (an attentive human participant is obviously active 🙋♀️.) some robotic participants, like a voice-messaging system, an instant-messaging agent, or a voice-dialog system, can be active participants if they're able to leave the conversation space when there's no human interaction 🤖. other robots, like our tone-generating robot from the last example, are passive participants 🔇. a human participant "on hold" is passive too ⏸️
an example diagram of a conversation space can be drawn as a "bubble" or ovals, or as a "set" in curly or square bracket notation 🫧. each set, oval, or bubble represents one conversation space 💜. hidden participants are shown in lowercase letters 🙈. examples are in Figure 1 👇
Note that while the term "conversation" usually applies to oral exchange of information, we apply the conversation space model to any media exchange between participants 🌈
{ A , B } [ A , b, C, D ]
.-. .---.
/ \ / \
/ A \ / A b \
( ) ( )
\ B / \ C D /
\ / \ /
'-' '---'Figure 1. Conversation Spaces 🎀
2.2. Relationship between Conversation Space, SIP Dialogs, and SIP Sessions
Okay so in [RFC3261], a call is "an informal term that refers to some communication between peers, generally set up for the purposes of a multimedia conversation" 📞✨. We need a conversation space because the SIP definition of call isn't precise enough to describe what users actually experience with multi-party features 🫶
Do any other definitions get the vibe right? 🤔 SIP and SDP (Session Description Protocol) [RFC4566] both define a conference as "a multimedia session identified by a common session description". A session is defined as "a set of multimedia senders and receivers and the data streams flowing from senders to receivers". The definition of "call" in some call models is closer to our conversation space idea 🦋
Here are some examples of how conversation spaces, SIP dialogs, and SIP sessions relate to each other. In every single one, the human just sees ONE call 💅
- A simple two-party call is a single conversation space, a single session, and a single dialog. 💖
- A locally mixed three-way call is two sessions and two dialogs. It's also a single conversation space. 🌸
- A simple dial-in audio conference is a single conversation space, but it's represented by as many dialogs and sessions as there are human participants. 🎀
- A multicast conference is a single conversation space, a single session, and as many dialogs as participants. 🌈
2.3. Signaling Models
Obviously, if you want to change a conversation space, you need to be able to use SIP signaling to make those changes 🙈 Specifically, there must be a way to manipulate SIP dialogs (call legs) to move participants into and out of conversation spaces. It's less obvious, but there also must be a way to manipulate SIP dialogs to include non-participant UAs that are still involved in a conversation space (e.g., back-to-back user agents or B2BUAs, third party call control (3pcc) controllers, mixers, transcoders, translators, or relays). That's a lot of hats, bestie 👑
Implementations may set up the media relationships described in the conversation space model using a centralized control model. One common way to do this with SIP is third party call control (3pcc), which is described in 3pcc [RFC3725]. The 3pcc approach relies on only the following three primitive operations:
- Create a new dialog (
INVITE) - Modify a dialog (
reINVITE) - Destroy a dialog (
BYE)
The big win of the 3pcc approach is that it only requires very basic SIP support from end systems to get call control features working 🧚 That makes third party call control a natural fit for protocol conversion and mid-call features. It also has an advantage and a disadvantage at the same time: new features can/must be implemented in one place only (the controller), but it neither requires enhanced client functionality nor takes advantage of it. Iconic energy, but with tradeoffs 💀
Also, this document talks at length about a peer-to-peer approach. The main downside of the peer-to-peer model is extra complexity in the end system, plus more complicated authentication and management models 😭 The benefits of the peer-to-peer model include:
- state remains at the edges,
- call signaling need only go through participants involved (there are no additional points of failure), and
- peers may take advantage of end-to-end message integrity or encryption
The peer-to-peer approach relies on additional "primitive" operations, some of which are listed here:
- Replace an existing dialog
- Join a new dialog with an existing dialog
- Locally perform media forking (multi-unicast)
- Ask another user agent (UA) to send a request on your behalf
The peer-to-peer approach also results in only a single SIP dialog, directly between the two UAs. The 3pcc approach results in two SIP dialogs, one between each UA and the controller. Because of that, the SIP features and extensions usable during the dialog are limited to the ones the controller understands. So if both UAs support an advanced SIP feature but the controller doesn't, that feature won't be able to be used 😤
Many of the features, primitives, and actions described in this document also require some type of media mixing, combining, or selection, which is covered in the next section 🫧
2.4. Mixing Models
SIP permits a variety of mixing models, which we'll look at briefly here 👀 This topic is covered more thoroughly in the SIP conferencing framework [RFC4353] and [RFC4579]. SIP supports both tightly coupled and loosely coupled conferencing, although more sophisticated behavior is available in tightly coupled conferences. In a tightly coupled conference, a single SIP user agent (called the focus) has a direct dialog relationship with each participant (and may control non-participant user agents as well). The focus can authoritatively publish information about the character and participants in a conference 👑 In a loosely coupled conference, there are no coordinated signaling relationships among the participants.
For brevity, only the two most popular conferencing models get a deep dive in this document (local and centralized mixing). Applying the conversation spaces model to loosely coupled multicast and distributed full unicast mesh conferences is left as an exercise for the reader 📚 Note that a distributed full mesh conference can work for basic conferences, but it doesn't easily support more complex conferencing actions like splitting, merging, and sidebars.
Call control features should be designed so a mixer (local or centralized) can decide when to reduce a conference back to a two-party call, or drop all the participants (for example, if only two automatons are communicating) 🤖 The actual heuristics used to release calls are beyond the scope of this document, but they may depend on properties of the conversation space, such as the number of active, passive, or hidden participants and the send-only, receive-only, or send-and-receive orientation of various participants.
2.4.1. Tightly Coupled
Tightly coupled conferences use a central point for signaling and authentication, known as a focus [RFC4353]. The actual media can be centrally mixed or distributed 🌸
2.4.1.1. (Single) End System Mixing
The first model we call "end system mixing" 🎀 In this model, user A calls user B, and they have a conversation. At some point later, A decides to conference in user C. To do this, A calls C using a completely separate SIP call. This call uses a different Call-ID, different tags, etc. There's no call set up directly between B and C. No SIP extension or external signaling is needed. A simply decides to locally join two dialogs 💅
B C
\ /
\ /
AFigure 2. End System Mixing Example
In Figure 2, A receives media streams from both B and C, and mixes them. A sends a stream containing A's and C's streams to B, and a stream containing A's and B's streams to C. Basically, user A handles both the signaling and the media mixing 🧠
2.4.1.2. Centralized Mixing
In a centralized mixing model, all participants have a pairwise SIP and media relationship with the mixer. Common uses of centralized mixing include ad hoc conferences and scheduled dial-in or dial-out conferences 📞 In Figure 3 below, the mixer M sends and receives media to and from participants A, B, C, D, and E.
B C
\ /
\ /
M --- A
/ \
/ \
D EFigure 3. Centralized Mixing Example
2.4.1.3. Centralized Signaling, Distributed Media
In this conferencing model, there's a centralized controller, just like in the dial-in and dial-out cases. However, the centralized server handles signaling only ✨ The media is still sent directly between participants, using either multicast or multi-unicast. Participants do their own mixing. Multi-unicast is when a user sends multiple packets (one for each recipient, addressed to that recipient). This is referred to as a "Decentralized Multipoint Conference" in [H.323]. Full mesh media with centralized mixing is another approach 🦋
2.4.2. Loosely Coupled
In these models, there's no central point of control for SIP signaling. As in the "Centralized Signaling, Distributed Media" case above, all endpoints send media to all other endpoints. Consequently, every endpoint mixes its own media from all the other sources and sends its own media to every other participant 🌈
2.4.2.1. Large-Scale Multicast Conferences
Large-scale multicast conferences were the original motivation for both the Session Description Protocol (SDP) [RFC4566] and SIP 🧚 In a large-scale multicast conference, one or more multicast addresses are allocated to the conference. Each participant joins those multicast groups and sends their media to them. Signaling is not sent to the multicast groups. The sole purpose of the signaling is to tell participants which multicast groups to join. Large-scale multicast conferences are usually pre-arranged, with specific start and stop times. However, multicast conferences don't need to be pre-arranged, as long as a mechanism exists to dynamically obtain a multicast address 💖
2.4.2.2. Full Distributed Unicast Conferencing
In this conferencing model, each participant has both a pairwise media relationship and a pairwise signaling relationship with every other participant (a full mesh) 🕸️ This model requires a mechanism to maintain a consistent view of distributed state across the group. This is a classic, hard problem in computer science 😩 Also, this model doesn't scale well for large numbers of participants. For <n> participants, the number of media and signaling relationships is approximately n-squared. As a result, this model isn't generally available in commercial implementations; instead, it's mostly the topic of research or experimental implementations 🔬 Note that this model assumes peer-to-peer signaling.
2.5. Conveying Information and Events ✨
Okay so participants should have access to info about the other participants in a conversation space 💖, so it can be shown to a human user or processed by an automaton 🤖. Some of this might already be in the Request-URI or the To, From, Contact, or other SIP header fields, but we still need another way to report it 🫶.
Lots of apps are driven by knowing how calls and conferences are progressing 📞. These kinds of events are what let you build distributed apps, where the app needs dialog and conference state but doesn't have to be co-resident with an endpoint user agent or conference server 🧚. For example, a focus in a conversation space might want to hand out URIs for conference status and/or conference/floor control 🎀.
The SIP Events architecture [RFC3265] is the general machinery for subscribing to and getting notified about events in SIP networks 🔔. It brings in the idea of a package, which is a specific "instantiation" of the events mechanism for a well-defined set of events 📦.
Event packages are needed for the status of a user's dialogs, the status of conferences and their participants, user-presence info, the status of registrations, and the status of a user's messages 💌. That's not an exhaustive list, but it's enough to enable the sample features described in this document 💅.
The conference event package [RFC4575] lets users subscribe to info about an entire tightly coupled SIP conference 🎪. Notifications carry info about participants, like the SIP URI identifying each user, their status in the space (active, declined, departed), URIs to invoke other features (such as sidebar conversations), links to other relevant info (such as floor-control policies), and, if floor-control policies are in place, the user's floor-control status 🙌. For conversation spaces created from cascaded conferences, conversation state can be gathered from relevant foci and merged into one cohesive set of state 🧩.
The dialog package [RFC4235] provides info about all the dialogs the target user is maintaining, which conversations the user is participating in, and how these are correlated 🕸️. Likewise, the registration package [RFC3680] provides notifications when contacts have changed for a specific address-of-record (AOR) 📇. Put these together and a user agent can learn about all conversations occurring for the entire registered contact set for an address-of-record 🌈.
User presence in SIP [RFC3856] has a close relationship with those last two event packages 💜. The presence model is built on info constructed from any number of different input sources, and other examples include calendaring info and uploads of presence documents 📅. These two packages can be considered another mechanism that lets a presence agent determine the presence state of the user. Specifically, a user presence server can act as a subscriber for the dialog and registration packages to get additional info it can use to construct a presence document 🍓.
The multi-party architecture may also need a way to get info about the status/handling of a dialog (for example, info about the history of other contacts attempted prior to the current contact) 🕰️. Finally, the architecture should provide ample opportunities to present informational URIs related to calls, conversations, or dialogs in some way 🔗. For example, think about the SIP Call-Info header or Contact header fields returned in a 300-class response 📎. Frequently, extra info about a call or dialog can be fetched via non-SIP URIs, like a web page for package tracking when calling a delivery company, or a web page with related documentation when joining a dial-in conference 📦. The use of URIs in the multi-party framework is discussed in more detail in Section 3.7 ✨.
Last but not least, the interaction of SIP with stimulus-signaling-based applications is discussed in the SIP application interaction framework [RFC5629] 🎮. Those apps let a user agent interact with an application without knowing that application's semantics. Stimulus signaling can happen with a user interface running locally on the client, or with a remote user interface through media streams 📺. It covers a wide range of mechanisms, from clicking on hyperlinks, to pressing buttons, to traditional Dual-Tone Multi Frequency (DTMF) input 🔘. In all cases, stimulus signaling is supported through markup languages, which play a key role in that framework 🧾.
2.6. Componentization and Decomposition 🧩
This framework proposes a decomposed component architecture with a very loose coupling of services and components 💕. That means a service (such as a conferencing server or an auto-attendant) doesn't need to be implemented as an actual server 🙅. Instead, these services can be built by combining a few basic components in straightforward or arbitrarily complex ways 🏗️.
Since the components are easily deployed on separate boxes, by separate vendors, or even with separate providers, you get a separation of function that lets each piece be developed in complete isolation 🔒. You can also reuse existing components for new apps ♻️. This allows rapid service creation, and the ability for services to be distributed across organizational domains anywhere in the Internet 🌍.
For many of these components, it's also desirable to discover their capabilities, for example, querying the ability of a mixer to host a 10-dialog conference or to reserve resources for a specific time ⏰. These actions could be provided in the form of URIs, provided there is an a priori means of understanding their semantics 🗝️. For example, if there is a published dictionary of operations, plus a way to query the service for the available operations and the associated URIs, the URI can be the interface for providing these service operations 📖. This concept is described in more detail in the context of dialog operations in Section 3 🔍.
2.6.1. Media Intermediaries 🪞
Media intermediaries are not participants in any conversation space 🚫, although an entity that is also a media translator may also have a co-located participant component (for example, a mixer that also announces the arrival of a new participant; the announcement portion is a participant, but the mixer itself is not). Media intermediaries should be as transparent as possible to the end users -- offering a useful, fundamental service without getting in the way of new features implemented by participants 🫧. Some common media intermediaries are described below 👇.
2.6.1.1. Mixer 🎚️
A SIP mixer is a component that combines media from all dialogs in the same conversation in a media-specific way 🎶. For example, the default combining for an audio conference might be an N-1 configuration, while a text mixer might interleave text messages on a per-line basis 📝. More details about how to manipulate the media policy used by mixers are discussed in [XCON-CCMP] 🔗.
2.6.1.2. Transcoder 🔄
A transcoder translates media from one encoding or format to another (for example, GSM (Global System for Mobile communications) voice to G.711, MPEG2 to H.261, or text/html to text/plain), or from one media type to another (for example, text to speech) 🗣️. A more thorough discussion of transcoding is described in the SIP transcoding services invocation [RFC5369] 📚.
2.6.1.3. Media Relay 📡
A media relay terminates media and simply forwards it to a new destination without changing the content in any way 🎁. Sometimes, media relays are used to provide source IP address anonymity, to facilitate middlebox traversal, or to provide a trusted entity where media can be forcefully disconnected 🕵️.
2.6.1.4. Queue Server 🎫
A queue server is a location where calls can be entered into one of several FIFO (first-in, first-out) queues 🚶. A queue server would subscribe to the presence of groups or individuals who are interested in its queues 👀. When detecting that a user is available to service a queue, the server redirects or transfers the last call in the relevant queue to the available user 🙋. On a queue-by-queue basis, authorized users could also subscribe to the call state (dialog information) of calls within a queue 📊. Authorized users could use this information to effectively pluck (take) a call out of the queue (for example, by sending an INVITE with a Replaces header to one of the user agents in the queue) 🍒.
2.6.1.5. Parking Place 🅿️
A parking place is a location where calls can be terminated temporarily and then retrieved later 🚗. While a call is "parked", it can receive media "on hold" such as music, announcements, or advertisements 🎵. Such a service could be further decomposed such that announcements or music are handled by a separate component 🧩.
2.6.1.6. Announcements and Voice Dialogs 📢
An announcement server is a server that can play digitized media (frequently audio), such as music or recorded speech 🎙️. These servers are typically accessible via SIP, HTTP (Hyper Text Transport Protocol), or RTSP (Real-Time Streaming Protocol) 🌐. An analogous service is a recording service that stores digitized media 💾. A convention for specifying announcements in SIP URIs is described in [RFC4240] 📝. Likewise, the same server could easily provide a service that records digitized media 🎬.
A "voice dialog" is a model of spoken interactive behavior between a human and an automaton that can include synthesized speech, digitized audio, recognition of spoken and DTMF key input, a recording of spoken input, and interaction with call control 🗨️. Voice dialogs frequently consist of forms or menus 📋. Forms present information and gather input; menus offer choices of what to do next 🍽️.
Spoken dialogs are a basic building block of applications that use voice 🎤. Consider, for example, a voicemail system, the conference-id and passcode collection system for a conferencing system, and complicated voice-portal applications, which all require a voice-dialog component 💬.
2.6.2. Text-to-Speech and Automatic Speech Recognition 🗣️👂
Text-to-speech (TTS) is a service that converts text into digitized audio 🔊. TTS is frequently integrated into other applications, but when separated as a component, it provides greater opportunity for broad reuse ♻️. Automatic Speech Recognition (ASR) is a service that attempts to decipher digitized speech based on a proposed grammar 👂. Like TTS, ASR services can be embedded, or exposed so that many applications can take advantage of such services 💜. A standardized (decomposed) interface to access standalone TTS and ASR services is currently being developed as described in [RFC4313] 🛠️.
2.6.3. VoiceXML 🎀
Okay so VoiceXML is a W3C (World Wide Web Consortium) recommendation 💖 and it was built to give authors control over the spoken dialog between users and applications 🗣️ The application and the user take turns: the app prompts the user, then the user responds, and back and forth it goes ✨ Its big goal is to bring the good stuff from web-based development and content delivery over to interactive voice-response apps 🌸 The authors believe VoiceXML is the ideal partner for SIP when building distributed IVR (interactive voice response) servers, and honestly, same 💅
VoiceXML is an XML-based scripting language for describing IVR services at an abstract level 🧚 It can handle DTMF recognition, speech recognition, text-to-speech, and playing out recorded media files 🎶 Whatever data gets collected from the user is passed to a controlling entity through an HTTP POST operation 📬 Then the controller can send back another script, or end the interaction with the IVR server. Main character energy for the controller, no cap 👑
A VoiceXML server doesn't have to be one big monolithic blob either 🦋 Figure 4 shows a VoiceXML browser that's split into media and non-media handling parts. The VoiceXML interpreter takes care of SIP dialog state and the state inside a VoiceXML document, and it sends requests to the media component over a different protocol. Split-brain but make it iconic 🫶
+-------------+
| |
| VoiceXML |
| Interpreter |
| (signaling) |
+-------------+
^ ^
| |
SIP | | RTSP
| |
| |
v v
+-------------+ +-------------+
| | | |
| SIP UA | RTP | RTSP Server |
| |<------>| (media) |
| | | |
+-------------+ +-------------+Figure 4. Decomposed VoiceXML Server 🌈
2.7. Use of URIs ✨
Okay bestie, this part is huge because all naming in SIP runs on URIs 🔗 They show up everywhere: the Request-URI; Contact, To, From, and *-Info header fields; application/uri bodies; and they're embedded in email, web pages, instant messages, and ENUM records 💌 The Request-URI tells you the user or service the call is destined for 🎯
SIP URIs stuck inside informational SIP header fields, SIP bodies, and non-SIP content can also specify methods, special parameters, header fields, and even bodies. Wild, right? 🙈 For example:
sip:bob@b.example.com;method=REFER?Refer-To=http://example.com/~aliceThroughout this document we've been talking about call control primitive operations, and the biggest problem is figuring out how they get invoked 🤯 There are a bunch of ways to do it. One way is to define the primitives in the protocol itself, so SIP methods (like REFER) or SIP header fields (like Replaces) trigger a specific call control action 💜 Another way is to define a specific Request-URI naming convention. Those conventions either have to be shared between the client (the invoker) and the server, or published by or on behalf of the server. The first option means defining URI construction techniques (e.g., URI parameters and/or token conventions) like the ones proposed in [RFC4240]. The second option usually means discovering the URI through a SIP event package, a web page, a business card, or an instant message 📇 And yet another option is to define a dictionary of primitives with well-defined semantics, plus a way to query the named primitives and their corresponding URIs that can be invoked on the service or dialogs. Lowkey a whole library system 📚
2.7.1. Naming Users in SIP 💖
An address-of-record, or public SIP address, is a SIP (or Secure SIP (SIPS)) URI that points to a domain with a location service. That location service can map the URI to a set of Contact URIs where the user might be available 📍 Usually those Contact URIs get filled in through registration.
Address-of-Record Contacts
sip:bob@biloxi.example.com -> sip:bob@babylon.biloxi.example.com:5060
sip:bbrown@mailbox.provider.example.net
sip:+1.408.555.6789@mobile.example.net[RFC3840] Callee Capabilities defines a set of extra parameters for the Contact header field that describe the characteristics of the user agent at that URI 🧩 For example, there's a mobility parameter that says whether the UA is fixed or mobile. When a user agent registers, it puts these parameters in its Contact header fields to describe the URIs it's registering. That way, a proxy for the domain knows stuff about the user's contact addresses. Information is power, babe 💅
When a caller sends a request, it can optionally ask for Caller Preferences [RFC3841] by including the Accept-Contact, Request-Disposition, and Reject-Contact header fields. Those ask the proxy in the target domain to handle things a certain way 🎀 The header fields carry preferences describing the set of desired URIs the caller wants the request routed to. The proxy in the target domain matches those preferences against the Contact characteristics the target user originally registered 🔍 The target user can also choose to run arbitrarily complex "Find-me" feature logic on a proxy in the target domain. The ultimate control freak move 😭
There's a strong asymmetry in how caller and callee preferences get presented to the network 🦋 The caller is the active one because they start the request, while the callee is passive and just waits for requests. That's why callee-supplied scripts and caller preferences in the call request make sense. The asymmetry carries over into how the two sets of preferences relate. A server for a callee should respect the caller's wishes to avoid certain locations, but the preferences among locations have to be the callee's choice, since the callee is the one who decides where the phone rings and whether they get charged for mobile incoming calls 📱💸 Boundaries, bestie 🫶
SIP User Agent implementations are encouraged to make smart decisions based on the type of participants in a conversation space: active/passive, hidden, human/robot 🤖 This info gets conveyed via the dialog package or in a SIP header field parameter sent using an appropriate SIP header field. For example, a music on hold service might take the sensible approach that if there are two or more unhidden participants, it should not provide hold music; or that it will not send hold music to robots 🎶 Vibes matter.
Multiple participants in the same conversation space may represent the same human user. Say a user has one device for video, chat, and whiteboard on a PC, and another device for audio on a SIP phone 📞💻 In that case the address-of-record is the same for both user agents, but the Contacts are different. Even so, there's really only one human participant 🙈 Humans can also add robot participants that act on their behalf, like a call recording service or a calendar announcement reminder 🧚 Call control features in SIP should keep working as expected in an environment like that ✨
2.7.2. Naming Services with SIP URIs ✨
okay, this part is SO important, like it literally cannot be overstated 😭 defining the names of the resources inside a service is the foundation of the whole thing 💅
so here's the move. in SIP control of application components, we get to use the fact that the left-hand side of a standard SIP URI is a user part 🎀 most services basically act like user automatons that join SIP sessions, so it makes total sense to use the user part as a service indicator 🤖
for example, media servers usually offer multiple services at one host address. using the user part as a service indicator lets service consumers aim their requests with zero ambiguity 🎯 and it's a bonus that media services can register their availability with SIP Registrars just like any "real" SIP user would 💜 that keeps everything consistent and gives you extra flexibility when you deploy media services across the network 🦋
people have talked a LOT about what happens if media-service URIs aren't easy to tell apart from other SIP UAs 💀 the fix is a service namespace. it lets standard interfaces be identified unambiguously, and it still leaves room for private or experimental services 🌈
in SIP, the Request-URI says which user or service the call is destined for 📞 the big win of using URIs (specifically the SIP Request-URI) as service identifiers comes from two facts combined. first, the PSTN (Public Switched Telephone Network) has a limited namespace of dialable telephone numbers, but URIs come from an infinite space. they're plentiful, and they're free 🙌 second, the main job of SIP is call routing by manipulating the Request-URI. in the traditional SIP application that URI represents a person, but it can also represent a service, which is what we're proposing here 🧚 that means we can use the routing services SIP already provides to route calls to services. so service invocation and service location turn into a routing problem, and SIP gives you a scalable, flexible solution for that ✨ since the service namespace is so huge, every service can be named in a super finely granular way, which allows services to be distributed across the network 🍓 for more on services and SIP URIs, see RFC 3087 [RFC3087].
let's say you have a conferencing service and you've split ad hoc conference names from scheduled conference names. now your proxies can send ad hoc calls to one set of servers and scheduled calls to another, possibly even at a different provider 👑 and since every conference gets its own URI, you can spread conferences across servers AND guarantee that calls for the same conference always land on the same server 😭 this is giving total contrast to the telephone network, where the equivalent of the URI (the phone number) is scarce. a whole conferencing provider usually has one or two numbers 🙈 conference IDs have to come through IVR interactions with the caller or through a human attendant, which makes it hard to spread conferences across servers all over the network, because PSTN routing only knows about the dialed number 📵
for more examples, check out the URI conventions in RFC 4240 [RFC4240] for media servers and RFC 4458 [RFC4458] for voicemail and IVR systems 🎧
now, a practical note that really matters 🫶 an invoker shouldn't necessarily apply semantic rules to URIs it didn't create. instead, it should accept any arbitrary string that gets provisioned and map that string to the behavior you want. the service administrator may pick specific conventions or mnemonic strings, but the application shouldn't require them. in any big installation, the system owner probably already has rules for mnemonic URIs, and if an application tries to define its own rules, that can cause a conflict 💥 implementations should allow an arbitrary mix of URIs from these schemes, or from any other scheme that produces valid SIP URIs, instead of enforcing just one particular scheme 🌸
so yeah, SIP URIs are an ideal, flexible way to describe and name service resources, whether those resources are queues, conferences, voice dialogs, announcements, voicemail treatments, or phone features 💖
2.8. Invoker Independence 🦋
with functional signaling, only the invoker of a feature in SIP needs to know exactly which feature they're invoking 🙌 one of the main perks is that combinations of functional features work in SIP call control without needing complicated feature-interaction matrices. let's look at a transfer of a call that's been conferenced 👀
Alice calls Bob. Alice silently "conferences in" her robotic assistant Albert as a hidden party. Bob transfers Alice to Carol. If Bob asks Alice to Replace her leg with a new one to Carol, then both Alice and Albert should be communicating with Carol (transparently). 🤖💜
with the peer-to-peer model, this combo works fine if A does local mixing (Alice replaces Bob's dialog with Carol's), or if A uses a central mixer (the mixer replaces Bob's dialog with Carol's). a clever implementation using the 3pcc model can get similar results ✨
new extensions to the SIP Call Control Framework should try to preserve this property 🫶
2.9. Billing Issues 💸
billing in the PSTN is usually based on who initiated the call. right now, billing in a SIP network isn't consistent with itself OR with the PSTN 😭 (a billing model for SIP should allow both PSTN-style billing and non-PSTN billing.) here's an example of one inconsistency 👇
Alice places a call to Bob. Alice then blind transfers Bob to Carol through a PSTN gateway. with current usage of REFER, Bob may get billed for a call he didn't initiate (his UA originated the outgoing dialog, though). this isn't necessarily the end of the world, but it does show a security concern, since Bob needs appropriate local policy to prevent fraud 🚨 also, Alice might want to pay for Bob's session with Carol. there should be a way to signal that in SIP 💅
same vibe with a Replacement call. it may keep the same billing relationship as the Replaced call, so if Alice first calls Carol and then asks Bob to Replace that call, Alice may keep getting the bill 🙃
further work in SIP billing should define a way to set or discover the direction of billing 📊
3. Catalog of Call Control Actions and Sample Features 🎀
call control actions can be sorted by the dialogs they operate on. an action may involve one dialog or several, and those dialogs can be early or established. multiple dialogs may be related in a conversation space to form a conference or other interesting media topologies 🌈
it's worth noting that it's desirable to give a party a way to discover the actions that can be performed on a dialog. the interested party may be independent of the dialogs or related to them. one way to do this is by being able to define and obtain URIs for these actions, as described in Section 2.7.2 🔗
below are several call control "actions" that establish or modify dialogs and relate the participants in a conversation space. the names of the actions are for descriptive purposes only (they are not normative). this list isn't meant to be exhaustive 💫
in the examples, every action is initiated by the user "Alice" represented by UA "A" 👩
3.1. Remote Call Control Actions on Early Dialogs 📞
the following is a set of actions that may be performed on a single early dialog. you can think of these as a set of remote control operations. for example, an automaton might perform the operation on behalf of a user. or a user might use a remote control app to perform the action on the early dialog of a UA that's out of reach 📱 all of these actions boil down to telling the UA how to respond to a request that tries to establish an early dialog. they're useful for PDA-, PC-, and server-based applications that want to control a UA 🖥️ a proposed mechanism for this kind of functionality is described in remote call control [FEATURE-REF].
3.1.1. Remote Answer ✅
a dialog is in some early dialog state, like 180 Ringing. you might want to tell the UA to answer the dialog, meaning tell it to send a 200 OK response to establish the dialog 🥳
3.1.2. Remote Forward or Put ↪️
you might want to tell the UA to respond with a 3xx class response to forward an early dialog to another UA 💌
3.1.3. Remote Busy or Error Out 📵
you might want to tell the UA to send an error response, like 486 Busy Here 🙅
3.2. Remote Call Control Actions on Single Dialogs 🎧
there's another useful set of actions that operate on a single established dialog. these are great for productivity apps that help users control their phones 💼 for example, a Customer Relationship Management (CRM) application could set up calls for a user so they don't have to type in an address at all 🙌 these operations can also be thought of as remote control actions. a proposed mechanism for this kind of functionality is described in remote call control [FEATURE-REF].
3.2.1. Remote Dial 📲
this action tells the UA to initiate a dialog. it can be done using the REFER method 🪄
3.2.2. Remote On and Off Hold ⏸️
this action tells the UA to put an established dialog on hold. even though you could conceptually do this with the REFER method, there are no semantics defined for what the referred party should do with the SDP 🤷 there's also no way to tell apart a desire to go on hold versus off hold on a per-media-stream basis 😵💫
3.2.3. Remote Hangup 👋
this action tells the UA to terminate an early or established dialog. a REFER request with the Refer-To URI and Target-Dialog header field [RFC4538] below does exactly this. heads up: this example doesn't show the full set of header fields 👀
REFER sip:carol@client.chicago.net SIP/2.0
Refer-To: sip:bob@babylon.biloxi.example.com;method=BYE
Target-Dialog: 13413098;local-tag=879738;remote-tag=0232143.3. Call Control Actions on Multiple Dialogs 👯
these actions apply to a set of related dialogs 💖
3.3.1. Transfer ✨
Okay bestie, transfers are where things get spicy 📞🦋 This section shows how call transfer can be pulled off with the centralized (3pcc) approach or the peer-to-peer (REFER) approach.
The conversation space changes like this:
before after
{ A , B } --> { C , B }A replaces itself with C. Iconic. 💅
To make this happen with the peer-to-peer approach, "A" sends two SIP requests. Here's the shorthand:
REFER B Refer-To:C
BYE BTo make this happen with the 3pcc approach instead, the controller sends the requests in this shorthand:
INVITE C (w/SDP of B)
reINVITE B (w/SDP of C)
BYE AFeatures enabled by this action:
- blind transfer
- transfer to a central mixer (some type of conference or forking)
- transfer to park server (park)
- transfer to music on hold or announcement server
- transfer to a "queue"
- transfer to a service (such as voice-dialog service)
- transition from local mixer to central mixer
This action is often called "completing an attended transfer" 💖 It gets a deeper dive in [RFC5589].
Also, if a transfer needs URI hiding or privacy, the 3pcc approach makes that way easier to pull off. For example, if the URI of C needs to stay hidden from B, 3pcc helps make that happen 🫶
3.3.2. Take 🎀
The conversation space changes like this:
{ B , C } --> { B , A }A forcibly replaces C with itself. In most uses of this primitive, A is just "un-replacing" itself 🔁
With the peer-to-peer approach, "A" sends:
INVITE B Replaces: <dialog between B and C>With the 3pcc approach (all requests sent from the controller):
INVITE A (w/SDP of B)
reINVITE B (w/SDP of A)
BYE CFeatures enabled by this action:
- transferee completes an attended transfer
- retrieve from central mixer (not recommended)
- retrieve from music on hold or park
- retrieve from queue
- call center take
- voice portal resuming ownership of a call it originated
- answering-machine style screening (pickup)
- pickup of a ringing call (i.e., early dialog)
Picking up a ringing call has some extra-juicy requirements, ngl 🙈 First, it's an early dialog, not an established one. Second, the party picking up the call might only want to do it while it's still an early dialog. Picture this race condition: the ringing UA accepts just before it gets signaling from the party who wants the call, and now the taking party wants to yield or cancel the take. The whole goal is to avoid yanking an answered call away from the called party 😭
This action is described in Replaces [RFC3891] and in [RFC5589].
3.3.3. Add 🍓
The following four actions are described in [RFC4579].
This is just adding a participant to a SIP conference. The conversation space changes like this:
{ A , B } --> { A , B , C }A adds C to the conversation.
With the peer-to-peer approach, adding a party using local mixing needs no signaling at all. To move from a two-party call or a locally mixed conference over to central mixing, A could send these requests:
REFER B Refer-To: conference-URI
INVITE conference-URI
BYE BTo add a party to a conference:
REFER C Refer-To: conference-URI
or
REFER conference-URI Refer-To: CWith the 3pcc approach, moving to centrally mixed means the controller sends:
INVITE mixer leg 1 (w/SDP of A)
INVITE mixer leg 2 (w/SDP of B)
INVITE C (late SDP)
reINVITE A (w/SDP of mixer leg 1)
reINVITE B (w/SDP of mixer leg 2)
INVITE mixer leg3 (w/SDP of C)To add a party to a SIP conference:
INVITE C (late SDP)
INVITE conference-URI (w/SDP of C)Features enabled:
- standard conference feature
- call recording
- answering-machine style screening (screening)
3.3.4. Local Join 🧩
The conversation space changes like this:
{ A , B } , { A , C } --> { A , B , C }or like this:
{ A , B } , { C , D } --> { A , B , C , D }A takes two conversation spaces and joins them into one single space.
With the peer-to-peer approach, A can mix locally, or REFER the participants of both conversation spaces to the same central mixer (as in Section 3.3.5).
For the 3pcc approach, the call flows for inserting participants, and for joining and splitting conversation spaces, are tedious yet straightforward, so these are left as an exercise for the reader 📚🙃
Features enabled:
- standard conference feature
- leaving a sidebar to rejoin a larger conference
3.3.5. Insert 💜
The conversation space changes like this:
{ B , C } --> { A , B , C }A inserts itself into a conversation space.
A proposed mechanism for signaling this with the peer-to-peer approach is to send a new header field in an INVITE with "joining" [RFC3911] semantics. For example:
INVITE B Join: <dialog id of B and C>If B accepted the INVITE, B would take responsibility for setting up the dialogs and mixing that's needed (for example, to mix locally or to transfer the participants to a central mixer) ✨
Features enabled:
- barge-in
- call center monitoring
- call recording
3.3.6. Split 🌸
{ A , B , C , D } --> { A , B } , { C , D }If using a central conference with peer-to-peer:
REFER C Refer-To: conference-URI (new URI)
REFER D Refer-To: conference-URI (new URI)
BYE C
BYE DFeatures enabled:
- sidebar conversations during a larger conference
3.3.7. Near-Fork 🌈
A participates in two conversation spaces at the same time:
{ A, B } --> { B , A } & { A , C }A is a participant in two conversation spaces, and A sends the same media to both spaces while rendering media from both of them, presumably by mixing or rendering the media from both. We can define A as the "anchor" point for both forks, and each fork is its own separate conversation space 🧚
This action is purely a local implementation thing (it needs no special signaling). Local features like switching calls between the background and foreground are possible thanks to this media relationship 🔥
3.3.8. Far-Fork 👑
The conversation space diagram:
{ A, B } --> { A , B } & { B , C }A requests B to be the "anchor" of two conversation spaces.
This is easily set up by creating a conference with two sub-conferences and setting the media policy appropriately so that B is a participant in both. Media forking can also be set up using 3pcc, as described in Section 5.1 of RFC 3264 [RFC3264] (an offer/answer model for SDP). The session descriptions for forking are quite complex, so controllers should verify that endpoints can handle forked media, for example, using prior configuration 🤓
Features enabled:
- barge-in
- voice-portal services
- whisper
- key word detection
- sending DTMF somewhere else
4. Security Considerations 🔐
Okay, this part is serious, so let's be real 🥺 Call control primitives are a powerful set of features that can be dangerous in the hands of an attacker. To make things worse, call control primitives are likely to be automatically authorized without direct human oversight.
The class of attacks possible with these tools includes the ability to eavesdrop on calls, disconnect calls, redirect calls, render irritating content (including ringing) at a user agent, cause an action that has billing consequences, subvert billing (theft-of-service), and obtain private information. Call control extensions must take extra care to describe how these attacks will be prevented 🚨
We can also make some general observations about authorization and trust with respect to call control. The security model depends heavily on the signaling model you choose (see Section 2.3).
Let's look at the security model for the 3pcc approach first. All signaling goes through the controller, which is a trusted entity. Traditional SIP authentication and hop-by-hop encryption and message integrity work fine in this environment, but end-to-end encryption and message integrity may not be possible 🔒
With the peer-to-peer approach, call control actions and primitives can be legitimately started by a) an existing participant in the conversation space, b) a former participant in the conversation space, or c) an entity trusted by one of the participants. For example, a participant always starts a transfer, a retrieve from park (a take) is started on behalf of a former participant, and a barge-in (insert or far-fork) is started by a trusted entity (an operator, for example) 🎧
Authenticating requests from an existing participant or a trusted entity can be done with baseline SIP mechanisms. For features started by a former participant, these should be protected against replay attacks, e.g., by using a unique name or identifier per invocation. The Replaces header field does this as a by-product of how it works (once a Replaces operation is successful, the dialog being Replaced no longer exists). These credentials may, for example, need to be passed along transitively or fetched in an event body 🪄
To authorize call control primitives that trigger special behavior (such as an INVITE with Replaces or Join semantics), the receiving user agent may have trouble finding the right credentials to challenge or authorize the request, since the sender may be completely unknown to the receiver, except through the introduction of a third party. These credentials need to be passed transitively in some way or fetched in an event body, for example 💭
Standard SIP privacy and anonymity mechanisms such as [RFC3323] and [RFC3325], used during SIP session establishment, apply equally well to SIP call control operations. SIP call control mechanisms should address privacy and anonymity issues tied to that operation. For example, privacy during a transfer operation using REFER is discussed in Section 7.2 of [RFC5589] 🕵️♀️
Appendix A. Example Features 🎬
Primitives are defined by their ability to provide features. These example features should need an amply robust set of services to show off a useful set of primitives. They're described here briefly. The descriptions of these features are non-normative. This document also covers a mix of features from the world of telephones and features that are clearly Internet oriented 📱🌐
Appendix A.1. Attended Transfer 💁♀️
In Attended Transfer [RFC5589], the transferring party establishes a session with the transfer target before completing the transfer.
Appendix A.2. Auto Answer 🔊
In Auto Answer, calls to a certain address or URI answer immediately via a speakerphone. The Answer-Mode header field [RFC5373] can be used for this feature.
Appendix A.3. Automatic Callback 📲
In Automatic Callback [RFC5359], Alice calls Bob, but Bob is busy. Alice would like Bob to call her automatically when he's available. When Bob hangs up, Alice's phone rings. When Alice answers, Bob's phone rings. Bob answers and they talk 🥹💖
Appendix A.4. Barge-In 🎤
In Barge-in, Carol interrupts Alice, who has an in-progress call with Bob. In some variations, Alice forcibly joins a new conversation with Carol. In other variations, all three parties are placed in the same conversation (basically a three-way conference). Barge-in works the same as call monitoring, except that it must indicate that the send media stream be mixed so that all of the other parties can hear the stream from the UA that is barging in 🫣
Appendix A.5. Blind Transfer ✨
okay so in Blind Transfer [RFC5589], Alice is chatting with Bob 💬 and she asks Bob to contact Carol, but she doesn't even try to reach Carol herself 🙈 that's the "blind" part. ngl, in lots of implementations Alice never checks whether Bob actually managed to reach Carol 💀
Appendix A.6. Call Forwarding
in call forwarding [RFC5359], a dialog gets redirected to a different location before anyone accepts it 📞➡️ and the reasons are super relatable: the person it was meant for is busy, nobody picks up, they're disconnected from the network, or they've told everything to go somewhere else 🦋
Appendix A.7. Call Monitoring
call monitoring is a Join operation [RFC3911] 👀 like when a call center supervisor hops into a call that's already happening just to listen 🎧 the monitoring UA sends a Join to the dialog it wants to listen to. it can find that dialog through the dialog state on the monitored UA 🔍 and the monitoring UA puts SDP in the INVITE that says receive-only media. since it's only listening, it doesn't matter whether it says it wants the send stream mixed or point to point 🤷♀️ it's giving quiet observer energy 🧚
Appendix A.8. Call Park
in Call Park [RFC5359], someone parks a call (basically puts it on hold 💤) and then grabs it again later, usually from somewhere else 🚶♀️ to make this work, you need to be able to put a dialog somewhere, advertise it to a pickup group 📢 and give it a unique identifier that can actually be communicated, even by human voice 🗣️ the dialog can stay held locally on the parking UA, or it can get transferred to the park service for the pickup group. then the parked dialog needs a label (like orbit 12) that can be passed along to whoever is going to pick it up 🏷️ the UAs in the pickup group find the parked dialogs through the dialog package from the park service. if the dialog was parked locally, the park service just aggregates the parked call states from the UAs in the pickup group 🫶
Appendix A.9. Call Pickup
there are two different features that both get called Call Pickup [RFC5359] 🙌 first, picking up a parked dialog. the UA doing the pickup subscribes to the dialog state of either the park service or the UA that parked the dialog locally 📥 parked dialogs should be labeled with an identifier, and the UA uses those labels so the user can say which dialog they want. the UA picking up the call invoked the URI in the call state that is labeled as replace-remote 🎯
the other one is picking up an early dialog, which is usually something ringing at another location 🔔 one version lets the caller choose which location to pick up from, and another version just grabs any call ringing in that user's "pickup group" 🧑🤝🧑 this feature borrows some of the same primitives as picking up a parked call. the call state of the ringing UA gets advertised using the dialog package 📣 the pickup UA subscribes either straight to the ringing UA or to a service that aggregates states for the pickup group. the call state identifies early dialogs, so the UA can use those states to help the user pick which early dialog to grab 👀 then the UA invokes the URI in the call state labeled as replace-remote ✨
Appendix A.10. Call Return
in Call Return, Alice calls Bob 📱 but Bob misses it, or gets disconnected before he's done talking to Alice 😵 so Bob invokes Call return, which calls Alice back, even if Alice never gave Bob her real identity or location 🫣 main character comeback 💅
Appendix A.11. Call Waiting
in Call Waiting, Alice is already on a call when another one comes in 📞📞 so she can put the first call on hold and talk to the other caller. she can usually switch back and forth between them whenever she wants 🔄 multitasking queen 👑
Appendix A.12. Click-to-Dial
in Click-to-Dial [RFC5359], Alice looks up Bob in her company directory 📇 she finds him, clicks a URI, and her phone rings (or maybe it just answers itself 🤖). when she picks up, Bob's phone starts ringing 📲 the application or server hosting Click-to-Dial grabs the URI to dial, and it can set up the call using 3pcc, or it can send a REFER request to the UA that's supposed to dial the address 🧩 and because users sometimes change their minds or want to stop listing to a ringing or voicemail-answered phone 📵 this app shows why you also need a way to remotely hang up a call 🔚
Appendix A.13. Conference Call
in a Conference Call [RFC4579], there are three or more active, visible participants in the same conversation space 🎉 the more the merrier, bestie 🥳
Appendix A.14. Consultative Transfer
in Consultative Transfer [RFC5589] 🤝 the transferring party sets up a session with the target, then mixes both sessions together so all three people can take part. after that, they disconnect, and the transferee and the transfer target are left with an active session between them 💖 very polite, very no drama 🌸
Appendix A.15. Distinctive Ring
in Distinctive Ring, incoming calls sound different depending on the From party, the To party, or other factors 🎶 different ring cadences, different sample sounds, the whole vibe 🔔 the target UA can either make its own local call based on the info in an incoming INVITE (To, From, Contact, Request-URI) 🕵️♀️ or it can trust an Alert-Info header field [RFC3261] that came from the caller or was inserted by a trusted proxy. in that second case, the UA fetches the content described in the URI (usually over HTTP) and plays it for the user 🌈
Appendix A.16. Do Not Disturb
in Do Not Disturb, Alice turns on the Do Not Disturb option 🤫 calls to her either ring super briefly or not at all, and they get forwarded somewhere else 📴 some versions let specially authorized callers break through and ring her anyway 🚨 and in SIP, the best way to build Do Not Disturb is with presence [RFC3856] 🧠✨
Appendix A.17. Find-Me
in Find-Me, Alice sets up really complicated rules for how people can reach her 🗺️ it could use CPL (Call Processing Language) [RFC3880], presence [RFC3856], or other factors. when Bob calls Alice, his call eventually gets routed to a temporary Contact where Alice happens to be available 📍 the detective work is giving me chills 🕵️♀️
Appendix A.18. Hotline
in Hotline, Alice picks up a phone and is connected right away to something like the technical support hotline 📞⚡ no dialing needed 🙌 hotline is also sometimes called a Ringdown line 💜
Appendix A.19. IM Conference Alerts
in IM Conference Alerts, a user gets an instant message notification whenever someone joins a conference they're already in 💬🔔 the group chat is always watching 👀
Appendix A.20. Inbound Call Screening
in Inbound Call Screening, Alice does not want calls from Matt 🙅♀️ so Inbound Screening keeps Matt from bugging her 🛑 in some versions, this still works even if Matt hides his identity 🥷 absolutely not, Matt 😤
Appendix A.21. Intercom
in Intercom, Alice presses a button on her phone and it instantly connects to another user or phone, which then plays her voice over its speaker 📢 some versions set up two-way talk right away, and others need another button press before the conversation can go both ways 🔁 the UA starts a dialog with INVITE and the Answer-Mode: Auto header field, as described in [RFC5373] 🎙️ the called UA accepts the INVITE with a 200 OK and automatically turns on the speakerphone 🔊 iconic.
or, alternatively, the UA can decide locally to auto answer based on called-party identification 🧐
Appendix A.22. Message Waiting
in Message Waiting [RFC3842], Bob calls Alice while she's stepped away from her phone 📭 when she gets back, a visible or audible indicator tells her someone left a voicemail 💌 the message waiting indication can also show how many messages are waiting, who they're from, what time they came in, and other useful details 📊 this is basically the notification you always wanted 🔔
Appendix A.23. Music on Hold
in Music on Hold [RFC5359], when Alice puts her call with Bob on hold, her side swaps the audio for streaming content like music, announcements, or ads 🎵 there are a few ways to do this. one is to transfer the held call to a holding service. when the UA wants to take the call off hold, it basically performs a take on the call from the holding service 🔄 that means subscribing to call state on the holding service and then invoking the URI in the call state labeled as replace-remote 🎯
or music on hold can be a local mixing operation 🎚️ the UA holding the call can mix in music from the music service over RTP (so an additional dialog), RTSP, or some other streaming media source 📻 from a protocol perspective, this is simpler, since the held dialog doesn't move around and there's less chance of loosing them 😌 but it does eat up more LAN bandwidth and UA resources 💸
Appendix A.24. Outbound Call Screening
in Outbound Call Screening, Alice gets paged and unknowingly calls a PSTN pay-service telephone number in the Caribbean 🏝️😱 but local policy blocks the call, and it might tell her why 🚫 oof, the vacation she did not plan 🙃
Appendix A.25. Pre-Paid Calling
in Pre-paid Calling, Alice pays for a certain amount of calling value 💳 when she places a call, she gives her account number somehow 🔢 if her account runs out of calling value mid-call, the call gets disconnected or redirected to a service where she can buy more ⏳ this is giving "running on fumes" energy 🪫
for prepaid calling, the user's media always goes through a device the prepaid provider trusts 🔐 that could be the other endpoint (like a PSTN gateway) or something else. either way, an intermediary proxy or B2BUA can periodically check how much time is left on the prepaid account ⏱️ and use the session-timer extension to make the trusted endpoint (gateway) or intermediary (media relay) send a reINVITE before that time runs out. during the reINVITE, the SIP intermediary can re-verify the account and insert another session-timer header field 🔁
ngl, most prepaid systems on the PSTN use an IVR to collect the account number and destination 📟 but that's not strictly necessary for a SIP-originated prepaid call 🙅♀️ SIP requests and SIP URIs are expressive enough to carry the final destination, the provider of the prepaid service, the location the user is calling from, and the prepaid account they want to use 🧾 and if a prepaid IVR is used, the mechanism described below (Voice Portals) can be combined with it too 🎀
Appendix A.26. Presence-Enabled Conferencing
in Presence-Enabled Conferencing, Alice wants to set up a conference call with Bob and Cathy whenever they're all free, instead of picking a set time 🗓️✨ the server running the app monitors their status and calls all three once they're all "online," not idle, and not in another call 🟢 this could be built with conferencing [RFC4579] and presence [RFC3264] primitives 🧩 literally the most considerate scheduling ever 🫶
Appendix A.27. Single Line Extension/Multiple Line Appearance 📞✨
okay so Single Line Extension/Multiple Line Appearance is giving home phone with a squad of extensions 🏠💖 A bunch of phones all count as "extensions" of one line or AOR. A call for one rings them all, and the second someone picks up, the rest stop ringing. 🙅♀️
If any extension is already in a conversation, another one can "pick up" and immediately join in. It's literally the vibe of a house with multiple phones on one line, and I'm obsessed. 😭 Incoming calls ring every extension through basic parallel forking. Each extension subscribes to dialog events from each other extension. So while one user has an active call, any other UA extension can insert itself into that conversation (it already knows the dialog information) in the same way as barge-in. Main character energy 👑
When it's done with SIP, this feature is known as Shared Appearances of an AOR [BLISS-SHARED]. Extensions to the dialog package are used to convey appearance numbers (line numbers). 🦋
Appendix A.28. Speakerphone Paging 📢🌸
In Speakerphone Paging, Alice calls the paging address and speaks, and her voice plays on the speaker of every idle phone in a preconfigured group. 🎀 There are a few ways to do this. It can use either multicast or a simple multipoint mixer.
For the multicast version, the paging UA sends a multicast INVITE with send-only media in the SDP (see also [RFC3264]). Whether the paged UAs auto-answer and turn on the speakerphone is a locally configured decision on each one. The paging UA sends RTP via the multicast address indicated in the SDP. 📡
The multipoint version sends an INVITE to the multipoint mixer, which is configured to automatically answer the dialog. Then the paging UA sends REFER requests for each of the UAs that are going to become paging speakers. (The UA is likely to send out a single REFER that is parallel forked by the proxy server.) The UAs acting as paging speakers are configured to auto-answer based on caller identification, like the To field, URI, or Referred-To header fields. 🫶
Then there's a third option. The user agent can send a mass-invitation request to a conference server, and the server creates a conference and sends INVITEs containing the Answer-Mode: Auto header field to every user agent in the paging group. 💅
Appendix A.29. Speed Dial ⚡💕
In Speed Dial, Alice dials an abbreviated number, enters an alias, or presses a special speed-dial button for Bob. 🧚 Whatever she does gets interpreted as if she had typed in Bob's full address. Quick and easy, no cap.
Appendix A.30. Voice Message Screening 🙈📼
In Voice Message Screening, Bob calls Alice, and Alice is screening her calls. So Bob hears Alice's voicemail greeting, and Alice can hear him leave his message. 👂 If she decides she wants to talk to Bob, she can take the call back from the voicemail system. Otherwise, she just lets Bob leave a message. This is basically a home answering machine, but iconic. 💀
At first, this is the same as Call Monitoring (Appendix A.7). In this case, the voicemail service is one of the UAs. The UA doing the screening monitors the call on the voicemail service and also subscribes to dialog information. If the user screening their messages decides to answer, they perform a take from the voicemail system. For example, they might send an INVITE with Replaces to the UA that's leaving the message. 📲
Appendix A.31. Voice Portal 🎙️🌈
Voice Portal is service that lets users access a portal site using spoken dialog interaction. 💬 For example, Alice needs to schedule a working dinner with her co-worker Carol. Alice uses a voice portal to check Carol's flight schedule, find a restaurant near her hotel, make a reservation, get directions there, and page Carol with all of it. A voice portal is basically a complex collection of voice dialogs used to access interesting content. 🍓
One of the most desirable call control features of a Voice Portal is starting a new outgoing call from inside the Portal. Think making a restaurant reservation or returning a voicemail message. 📞 Once that new call is over, the user should be able to get back to the Portal by pressing a special key, using some DTMF sequence (e.g., a very long pound or hash tone), or by speaking a key word (e.g., "Main Menu"). Ngl, that's a lot of hoops, but okay 💅
To make this work, the Voice Portal starts with the following media relationship:
{ User , Voice Portal }The user then asks to make an outgoing call. The Voice Portal asks the user to perform a far-fork. In other words, the Voice Portal wants the following media relationship:
{ Target , User } & { User , Voice Portal }The Voice Portal is now just listening for a key word or the appropriate DTMF. ✨ As soon as the user says they're done, the Voice Portal takes the call from the old target, and we're back to the original media relationship. Full circle, bestie 🔁
This feature can also be used by the account number and phone number collection menu in a pre-paid calling service. A user can press a DTMF sequence that brings the appropriate menu back up. 🫶
Appendix A.32. Voicemail 📬💜
In Voicemail, Alice calls Bob, but Bob doesn't answer or isn't available. The call forwards to a voicemail server, which plays Bob's greeting and records Alice's message for him. 🎧 Then an indication is sent to Bob that a new message is waiting, and he retrieves it whenever he gets around to it. 🙃
This feature is implemented using features like Call Forwarding (Appendix A.6) and the History-Info header field [RFC4244] or the voicemail URI convention [RFC4458], along with Message Waiting [RFC3842]. It's giving teamwork. 🤝
Appendix A.33. Whispered Call Waiting 🤫🍋
In Whispered Call Waiting, Alice is in a conversation with Bob when Carol calls her. 📞 Carol can "whisper" to Alice directly ("Can you get lunch in 15 minutes?"), or an automaton can whisper to Alice to let her know Carol is trying to reach her. Sneaky, but iconic 😏
Appendix B. Acknowledgments 🙏🎀
The authors would like to acknowledge Ben Campbell for his contributions to the document. They also want to thank AC Mahendran, John Elwell, and Xavier Marjou for their detailed Working-Group review of the document. And they'd like to thank Magnus Nystrom for his review. Everyone who helped deserves a little flower crown 🌸💖
5. Informative References 📚✨
okay bestie, this is the reading list 🧚 these are the docs the spec points you to for background, not stuff you have to implement. I'm keeping every single one exactly as written so you can go find them 💖
- [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.
- [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.
- [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
- [RFC5359] Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and K. Summers, "Session Initiation Protocol Service Examples", BCP 144, RFC 5359, October 2008.
- [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.
- [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
- [RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, September 2004.
- [RFC3911] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP) "Join" Header", RFC 3911, October 2004.
- [BLISS-PROBLEM] Rosenberg, J., "Basic Level of Interoperability for Session Initiation Protocol (SIP) Services (BLISS) Problem Statement", Work in Progress, March 2009.
- [RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", RFC 4235, November 2005.
- [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, August 2006.
- [RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Registrations", RFC 3680, March 2004.
- [RFC3856] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
- [RFC4353] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, February 2006.
- [RFC5629] Rosenberg, J., "A Framework for Application Interaction in the Session Initiation Protocol (SIP)", RFC 5629, October 2009.
- [RFC5369] Camarillo, G., "Framework for Transcoding with the Session Initiation Protocol (SIP)", RFC 5369, October 2008.
- [XCON-CCMP] Barnes, M., Boulton, C., Romano, S., and H. Schulzrinne, "Centralized Conferencing Manipulation Protocol", Work in Progress, February 2010.
- [RFC5589] Sparks, R., Johnston, A., and D. Petrie, "Session Initiation Protocol (SIP) Call Control - Transfer", BCP 149, RFC 5589, June 2009.
- [RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents", BCP 119, RFC 4579, August 2006.
- [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.
- [RFC3087] Campbell, B. and R. Sparks, "Control of Service Context using SIP Request-URI", RFC 3087, April 2001.
- [FEATURE-REF] Audet, F., Johnston, A., Mahy, R., and C. Jennings, "Feature Referral in the Session Initiation Protocol (SIP)", Work in Progress, February 2008.
- [RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network Media Services with SIP", RFC 4240, December 2005.
- [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.
- [RFC4538] Rosenberg, J., "Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP)", RFC 4538, June 2006.
- [RFC3880] Lennox, J., Wu, X., and H. Schulzrinne, "Call Processing Language (CPL): A Language for User Control of Internet Telephony Services", RFC 3880, October 2004.
- [RFC5373] Willis, D. and A. Allen, "Requesting Answering Modes for the Session Initiation Protocol (SIP)", RFC 5373, November 2008.
- [RFC3842] Mahy, R., "A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP)", RFC 3842, August 2004.
- [BLISS-SHARED] Johnston, A., Soroushnejad, M., and V. Venkataramanan, "Shared Appearances of a Session Initiation Protocol (SIP) Address of Record (AOR)", Work in Progress, October 2009.
- [RFC4244] Barnes, M., "An Extension to the Session Initiation Protocol (SIP) for Request History Information", RFC 4244, November 2005.
- [RFC4313] Oran, D., "Requirements for Distributed Control of Automatic Speech Recognition (ASR), Speaker Identification/Speaker Verification (SI/SV), and Text-to-Speech (TTS) Resources", RFC 4313, December 2005.
- [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.
Authors' Addresses 🫶
Rohan Mahy Unaffiliated EMail: rohan@ekabal.com
Robert Sparks Tekelec EMail: rjsparks@nostrum.com
Jonathan Rosenberg jdrosen.net EMail: jdrosen@jdrosen.net
Dan Petrie SIPez EMail: dan.ietf@sipez.com
Alan Johnston (editor) Avaya EMail: alan.b.johnston@gmail.com
That's the whole RFC, bestie! 🌈💅👑
📦 where this page comes from
- ietf: rfc5850 2010-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms