RFC 5629
A Framework for Application Interaction in the Session Initiation Protocol (SIP)
A Framework for Application Interaction in the Session Initiation Protocol (SIP) 🎀
Part 1 of 9 🦋
Okay bestie, this is RFC 5629 💖, and it's all about how users talk to SIP apps. Here's the title-block tea ☕:
- Request for Comments: 5629
- Network Working Group
- Author: J. Rosenberg, Cisco Systems
- Category: Standards Track
- Date: October 2009
- Obsoletes / Updates: nothing listed in the title block 🙈
Abstract ✨
Okay so the abstract is giving "here's the whole vibe in one paragraph" 💅. This doc lays out a framework for how users interact with Session Initiation Protocol (SIP) based applications. When users interact with apps, they can steer how those apps work 🧚.
The main star is stimulus signaling 🌟. It lets a user agent (UA) interact with an application without knowing what that application actually does, which is so iconic. The stimulus can hit a user interface running locally on the client, or a remote user interface reached through media streams 🎧. It covers everything from clicking hyperlinks, to pressing buttons, to good old Dual-Tone Multi-Frequency (DTMF) input ☎️. And in every case, the whole thing runs on markup languages, which are a huge part of this framework 📄💜.
Status of This Memo 📋
Bestie, this section is the official paperwork, but the tea is simple. This document specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚. Distribution of this memo is unlimited 🌈.
Copyright Notice ©️
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved 💜.
Okay this part is a little legal, but it matters 🙈. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the date this document was published. Please read these carefully, because they spell out your rights and restrictions for this document 📜. Code Components pulled out of this document must 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 BSD License ⚠️.
This document may contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The people controlling the copyright in some of that material may not have granted the IETF Trust the right to allow modifications outside the IETF Standards Process 😭. Unless you get an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The one exceptions are formatting it for publication as an RFC, or translating it into languages other than English 🌸.
Table of Contents 🗂️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. A Model for Application Interaction . . . . . . . . . . . . . 7
4.1. Functional vs. Stimulus . . . . . . . . . . . . . . . . . 9
4.2. Real-Time vs. Non-Real-Time . . . . . . . . . . . . . . . 10
4.3. Client-Local vs. Client-Remote . . . . . . . . . . . . . . 10
4.4. Presentation-Capable vs. Presentation-Free . . . . . . . . 11
5. Interaction Scenarios on Telephones . . . . . . . . . . . . . 11
5.1. Client Remote . . . . . . . . . . . . . . . . . . . . . . 12
5.2. Client Local . . . . . . . . . . . . . . . . . . . . . . . 12
5.3. Flip-Flop . . . . . . . . . . . . . . . . . . . . . . . . 13
6. Framework Overview . . . . . . . . . . . . . . . . . . . . . . 13
7. Deployment Topologies . . . . . . . . . . . . . . . . . . . . 16
7.1. Third-Party Application . . . . . . . . . . . . . . . . . 16
7.2. Co-Resident Application . . . . . . . . . . . . . . . . . 17
7.3. Third-Party Application and User Device Proxy . . . . . . 18
7.4. Proxy Application . . . . . . . . . . . . . . . . . . . . 19
8. Application Behavior . . . . . . . . . . . . . . . . . . . . . 19
8.1. Client-Local Interfaces . . . . . . . . . . . . . . . . . 20
8.1.1. Discovering Capabilities . . . . . . . . . . . . . . . 20
8.1.2. Pushing an Initial Interface Component . . . . . . . . 20
8.1.3. Updating an Interface Component . . . . . . . . . . . 22
8.1.4. Terminating an Interface Component . . . . . . . . . . 22
8.2. Client-Remote Interfaces . . . . . . . . . . . . . . . . . 23
8.2.1. Originating and Terminating Applications . . . . . . . 23
8.2.2. Intermediary Applications . . . . . . . . . . . . . . 24
9. User Agent Behavior . . . . . . . . . . . . . . . . . . . . . 24
9.1. Advertising Capabilities . . . . . . . . . . . . . . . . . 24
9.2. Receiving User Interface Components . . . . . . . . . . . 25
9.3. Mapping User Input to User Interface Components . . . . . 26
9.4. Receiving Updates to User Interface Components . . . . . . 27
9.5. Terminating a User Interface Component . . . . . . . . . . 27
10. Inter-Application Feature Interaction . . . . . . . . . . . . 27
10.1. Client-Local UI . . . . . . . . . . . . . . . . . . . . . 28
10.2. Client-Remote UI . . . . . . . . . . . . . . . . . . . . . 29
11. Intra Application Feature Interaction . . . . . . . . . . . . 29
12. Example Call Flow . . . . . . . . . . . . . . . . . . . . . . 30
13. Security Considerations . . . . . . . . . . . . . . . . . . . 36
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 36
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
16.1. Normative References . . . . . . . . . . . . . . . . . . . 36
16.2. Informative References . . . . . . . . . . . . . . . . . . 371. Introduction ✨
Okay so SIP [2] is the protocol that lets users start, manage, and end communications sessions 📞. A lot of those sessions involve a SIP application 💫. A SIP application is a program running on a SIP-based element, like a proxy or a user agent, that gives a user or a system administrator some extra value-added function 🎁. Examples include prepaid calling card calls, conferencing, and presence-based [12] call routing 🦋.
Here's the thing: most apps can't work properly without input from the user to guide them 🫠. For example, a prepaid calling card app needs the user to type in their calling card number, their PIN code, and the destination number they want to reach 💳. The process of a user giving input to an application is called "application interaction" 💅.
Application interaction can be either functional or stimulus 🔥. Functional interaction means the user device has to understand the semantics of the application, whereas stimulus interaction doesn't need that 🧠. Stimulus signaling lets apps get built without changing the user device, which is seriously iconic 👑. Stimulus interaction is the subject of this framework 💜. The framework gives a model for how users interact with apps through user interfaces, and how those user interfaces and apps can be spread out across a network 🌐. That model is then used to describe how applications can instantiate and manage user interfaces 🧚.
2. Conventions Used in This Document 📝
Bestie, these are the magic words 🪄. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [1].
3. Definitions ✨
okay so this section is the glossary, and it's lowkey the foundation for everything else 🫶 we need every term to mean the same thing, bestie.
- SIP Application: a program running on a SIP-based element (like a proxy or user agent) that adds some value-added function for a user or system administrator 💅 examples are prepaid calling card calls, conferencing, and presence-based [12] call routing.
- Application Interaction: the process by which a user gives input to an application.
- Real-Time Application Interaction: application interaction that happens while an application instance is running ⏰ like when someone types their PIN into a prepaid calling card app. that's real-time, obsessed.
- Non-Real-Time Application Interaction: application interaction that happens asynchronously with the app running 🙈 this is usually done through provisioning.
- Functional Application Interaction: interaction is functional when the user device actually understands what the interaction means 🧠
- Stimulus Application Interaction: interaction is stimulus when the user device has no clue what the interaction means 🙃
- User Interface (UI): the thing that gives the user context so they can decide what they want 🎀 the user touches the device, the device passes the input along, and the UI interprets it and hands it to the app. iconic pipeline.
- User Interface Component: a piece of UI that works independently from the other pieces 🌸 for example, someone might have two separate web interfaces for a prepaid calling card app: one for hanging up and calling again, and one for entering the username and PIN.
- User Device: the software or hardware the user directly touches to talk to the application 📱 a telephone counts, and so does a PC with a web browser.
- User Device Proxy: a software or hardware system the user talks to indirectly 🦋 this can happen through a network. the example is a gateway from IP to the Public Switched Telephone Network (PSTN), which acts as a user device proxy and works on the user's behalf on the circuit network.
- User Input: the "raw" info that goes from a user to a user interface 💜 examples are a spoken word or a click on a hyperlink.
- Client-Local User Interface: a user interface that lives right alongside the user device 🏠
- Client-Remote User Interface: a user interface that runs somewhere else, not on the user device 🌍 here you need a standardized interface between the user device and the UI, and this is typically done through media sessions: audio, video, or application sharing.
- Markup Language: describes the logical flow of how info gets presented to the user, how info gets collected from the user, and how that info gets sent to an application 📝
- Media Interaction: a way of separating a user and a user interface by connecting them with media streams 🎶
- Interactive Voice Response (IVR): an IVR is a type of UI that lets users speak commands to the application and hear responses that ask for more info 📞 literally the phone tree era.
- Prompt-and-Collect: the basic building block of an IVR UI 🧱 the user hears a voice option and speaks their choice.
- Barge-In: entering info into an IVR UI before the prompt asking for that info has finished 🏃♀️ the "wait, I know this one" move.
- Focus: a UI component has focus when user input is directed to it instead of any other UI component 🎯 don't mix this up with the "focus" in the SIP conferencing framework, which means the center user agent in a conference [14]. different vibes, same word, iykyk.
- Focus Determination: the process where the user device figures out which UI component is going to receive the user input 🔍
- Focusless Device: a user device that can't do focus determination at all 🙈 a telephone with a keypad is the example.
- Presentation-Capable UI: a UI that can prompt the user, collect results, and then prompt the user again with new info based on those results 💖
- Presentation-Free UI: a UI that can't prompt the user with info at all 🤐
- Feature Interaction: a class of problems that happen when multiple applications (or application components) are trying to provide services to a user at the same time 😭 the drama is real.
- Inter-Application Feature Interaction: feature interactions that happen between applications 👯
- DTMF: Dual-Tone Multi-Frequency 🎹 DTMF is a class of tones that circuit-switched telephony devices generate when the user presses a key on the keypad. people use DTMF and keypad input like they're the same thing, but they aren't. DTMF is just a way of carrying the keypad input to a client-remote user interface (the switch, for example) ✨
- Application Instance: a single execution path of a SIP application 🧚
- Originating Application: a SIP application that acts as a User Agent Client (UAC) and makes a call on behalf of the user 📤
- Terminating Application: a SIP application that acts as a User Agent Server (UAS) and answers a call that a user generated 📥 IVR applications are terminating applications, obviously.
- Intermediary Application: a SIP application that is neither the caller or callee, but a third party involved in the call 👀
4. A Model for Application Interaction 🌈
okay the vibe here is a whole picture, so let's look at Figure 1 first 🦋
+---+ +---+ +---+ +---+
| | | | | | | |
| | | U | | U | | A |
| | Input | s | Input | s | Results | p |
| | ---------> | e | ---------> | e | ----------> | p |
| U | | r | | r | | l |
| s | | | | | | i |
| e | | D | | I | | c |
| r | Output | e | Output | f | Update | a |
| | <--------- | v | <--------- | a | <.......... | t |
| | | i | | c | | i |
| | | c | | e | | o |
| | | e | | | | n |
| | | | | | | |
+---+ +---+ +---+ +---+
Figure 1: Model for Real-Time InteractionsFigure 1 is a general model for how users interact with applications 💅 usually users talk to a user interface through a user device. a user device can be a telephone, or a PC with a web browser. its job is to pass the user input from the user over to the user interface. the UI gives the user context so they can decide what they want. the user touches the device, which sends info to the UI, and the UI interprets it and passes it up to the application as a user interface event. the app may be able to change the UI based on that event, but whether it can actually depends on what kind of UI it is 🎀
okay so UIs are really all about rendering and interpretation 🖼️ rendering is how the user gets context, and that can be hyperlinks, images, sounds, videos, text, and so on. interpretation is how the UI takes that messy "raw" data from the user and turns it into a meaningful event for the app, without the app needing to know any of the UI's particulars 🧠
for a prepaid calling card app as an example: the UI worries about stuff like which prompt the user hears, or whether the voice is male or female, and all that. it's the one recognizing the speech the user gives so it can get the info it needs 📞 in this case the info is the calling card number, the PIN code, and the destination number. the app needs that data, and it doesn't care whether it was collected with a male prompt or a female one 💁♀️
UIs generally have real-time requirements toward the user 🔥 when a user interacts with the UI, the UI needs to react quickly, and that change needs to get to the user right away. BUT the interface between the UI and the application doesn't need to be that fast. faster is better, sure, but the UI can usually cover up for long latencies between itself and the app 🫶 with the prepaid calling card app, when the user is prompted for their PIN, the prompt should generally stop immediately once the first digit is entered. this is called "barge-in" 🏃♀️ after the UI collects the rest of the PIN, it can tell the user to "please wait while processing," and then the PIN can gradually get sent to the app. so the UI covers for a slow UI-to-app connection by asking the user to wait ⏳
the separation between the user interface and the application is absolutely fundamental to the entire framework in this document 😭 its importance cannot be overstated, bestie.
with this basic model in hand, we can start sorting out the types of systems that can be built 🌸
4.1. Functional vs. Stimulus ✨
okay so the first way to sort this system out is to look at the interface between the UI and the application 👀. there are two totally different models here. in a functional interface, the user interface knows a LOT about the application, like it's literally built for that one app 💅. the two parts talk through a functional protocol that can represent whatever semantics the user interface can show. since the UI knows the app inside out, it can be designed super specifically for it, so functional UIs are almost always the most user friendly, the fastest, and the most responsive 🔥. BUT, to let user devices and applications work together, the details of those functional protocols have to be written down in standards 📜. which slows down innovation and limits what apps can be built 😭.
the other option is a stimulus interface 🦋. here the user interface is generic, totally clueless about the details of the app 🫠. the app can even send instructions to the UI describing how it should operate 📬. the UI turns what the user does into "stimulus", which is data that only the application understands, not the UI 🧚. because the UI is generic, and it needs to talk to the app to change how it shows info to the user, stimulus UIs are usually slower, less user friendly, and less responsive than a functional one 💀. however, they allow for a lot of innovation in apps, since no standardization work is needed to build a new app, as long as it can interact with the user within what the UI mechanism allows ✨. the web is an example of a stimulus user interface to applications 🌐.
in SIP systems, functional interfaces come from extending the SIP protocol to add the functionality needed 🎀. for example, the SIP caller preferences specification [15] gives a functional interface that lets a user ask applications to route the call to specific types of user agents 📞. functional interfaces matter, but they aren't the focus of this framework 🙅. the main goal here is to look at the role of stimulus interfaces to SIP applications 💜.
4.2. Real-Time vs. Non-Real-Time ⏰
application interaction systems can also be real-time or non-real-time ⏱️. non-real-time interaction lets the user put in info about how the app operates asynchronously with when it gets invoked 💌. often this happens through provisioning systems 🛠️. for example, a user can set the forwarding number for a call-forward on no-answer application using a web page 🌸. real-time interaction means the user has to interact with the app right at the moment it's invoked ⚡.
4.3. Client-Local vs. Client-Remote 🗺️
another axis is whether the user interface is co-resident with the user device (we call that a client-local user interface), or whether the UI runs on a host separate from the client (we call that a client-remote user interface) 🧭. in a client-remote UI, there's some kind of protocol between the client device and the UI so the client can talk to the UI over a network 🌐.
the most important way to split the UI and client device is through media interaction 🎧. in media interaction, the interface between the user and the UI is through media: audio, video, messaging, and so on 📹. this is the classic way VoiceXML [5] works, where the UI (also called the voice browser) runs on a platform in the network ☎️. users talk to the voice browser over the telephone network (or using a SIP session) 💬. the voice browser talks to the app using HTTP to pass along the info it collected from the user 📨.
in the client-local case, the UI runs right alongside the user device 🏠. the interface between them is the software that reads the user's input and passes it to the UI 🖥️. the classic example is the Web 🕸️. on the Web, the UI is a web browser, and the interface is defined by the HTML document it's rendering 📄. the user interacts directly with the UI running in the browser 🫶. the results of that UI get sent to the app (running on the web server) using HTTP 💨.
it's important to note that whether the UI is local or remote (for media interaction) isn't a property of the modality of the interface 🤔. it's a property of the system 💡. for example, a Web-based UI can be provided with a client-remote UI 🌩️. in that case, video and application-sharing media sessions can be used between the user and the UI 📺. the UI, still guided by HTML, now runs "in the network", remote from the client 🛰️. similarly, a VoiceXML document can be interpreted locally by a client device with no media streams at all 🙌. honestly, the VoiceXML document can be rendered using text instead of media, with no impact on the interface between the UI and the app 📝.
it's also worth noting that systems can be hybrid 🧩. in a hybrid UI, some aspects (usually the ones tied to a particular modality) run locally, and others run remotely 💫.
4.4. Presentation-Capable vs. Presentation-Free 🎨
a UI can be capable of presenting info to the user (a presentation-capable UI), or it can only collect user input (a presentation-free UI) 🫢. these are very different kinds of UIs 👀. a presentation-capable UI can give the user feedback after every input, which gives context for collecting the next input 🧠. so presentation-capable UIs need to update the info shown to the user after each input 🔄. the Web is a classic example. after every input (i.e., a click), the browser passes the input to the app and fetches the next page to render 🖱️. in a presentation-free UI, that doesn't happen 🙅♀️. since the user gets no feedback, these UIs tend to just collect info as it's entered and pass it to the app 📥.
another difference: a presentation-free UI can't easily support the concept of a focus 🎯. selecting a focus usually needs a way to tell the user which apps are available, letting them choose, and then telling them which one they picked 🙋. without the first and third steps (which a presentation-free UI can't provide), focus selection is really hard 😩. without a selected focus, input given to apps through presentation-free UIs is more of a broadcast or notification thing 📢.
5. Interaction Scenarios on Telephones 📞
in this section, we apply the model of Section 4 to telephones 💖.
in a traditional telephone, the UI is a 12-key keypad, a speaker, and a microphone 🎙️. from here on, "telephone" is used to mean any device that meets, at a minimum, the characteristics in the sentence before 📱. circuit-switched telephony apps are almost always client-remote UIs 📡. in the Public Switched Telephone Network (PSTN), there's usually a circuit interface between the user and the UI 🔌. the keypad input is carried using Dual-Tone Multi-Frequency (DTMF), and the microphone input as Pulse Code Modulated (PCM) encoded voice 🎶.
in an IP-based system, there's more variability in how it can be set up 🌈. both client-remote and client-local UIs to a telephone can be provided 💜.
in this framework, a PSTN gateway can be considered a User Device Proxy 🧚♀️. it's a proxy for the user because it can give a UI on an IP network the input taken from a user on a circuit-switched telephone 🫶. the gateway may be able to run a client-local UI, just like an IP telephone might 🤷♀️.
5.1. Client Remote 🖥️
the most obvious setup is the "classic" circuit-switched telephony model 📞✨. in that model, the UI runs remotely from the client 🖥️. the interface between the user and the UI is through media, which is set up by SIP and carried over the Real Time Transport Protocol (RTP) [18] 🎧. the microphone input can be carried using any suitable voice-encoding algorithm 🎤. the keypad input can be conveyed in one of two ways 🔢. the first is to convert the keypad input to DTMF, then convey that DTMF using a suitable encoding algorithm (such as PCMU) 🙃. the alternative, and generally the preferred approach, is to send the keypad input using RFC 4733 [19], which provides an encoding mechanism for carrying keypad input within RTP 🏆.
in this classic model, the UI would run on a server in the IP network 🖲️. it would do speech recognition and DTMF recognition to derive the user intent, feed them through the UI, and provide the result to an application 🧠💅.
5.2. Client Local 📱
an alternative model is for the entire UI to live on the telephone 📱. the UI can be a VoiceXML browser, running speech recognition on the microphone input, and feeding the keypad input directly into the script 🎙️. as discussed above, the VoiceXML script could be rendered using text instead of voice if the telephone has a textual display 📝.
for simpler phones without a display, the UI can be described by a Keypad Markup Language request document [8] 📄. as the user enters digits on the keypad, they're passed to the UI, which generates user interface events that can be transported to the application 🔢💖.
5.3. Flip-Flop 🦋
okay so there's this middle-ground move where you flip back and forth between a client-local and a client-remote user interface 🔄 bestie, it's giving balance. A lot of voice apps just sit there listening to the media stream and waiting for one specific trigger to kick off something more complex. The long pound in a prepaid calling card app is the classic example 📞 Another one is a conference recording app, where someone presses a key partway through the call to start recording. When they press it, they hear a whisper telling them recording has started 🤫
The ideal way to handle this is to install a client-local user interface component that just waits for the trigger 👀 Once the trigger lands, the application connects the user to a client-remote user interface that can play announcements, collect more info, and so on ✨
The benefit of flip-flopping between client-local and client-remote is cost 💸 The client-local UI means you don't have to send media streams into the network just to wait for someone to press the pound key on their keypad. Major savings, no cap 💅
The Keypad Markup Language (KPML) was built for exactly this kind of need [8] 🎹 It models the phone keypad and lets an application know when any sequence of keys has been pressed. BUT (and this is a big but 🙈) KPML has no presentation component. Since user interfaces usually need to respond to what the user does, the presentation has to happen on a client-remote user interface that gets created because of the trigger.
It's tempting to go hybrid, where a prompt-and-collect app uses a client-remote UI to play the prompts and a client-local UI, described by KPML, to collect the digits. Honestly though, this just makes things messier 😩 Firstly, the keypad input gets sent to both the media stream and the KPML user interface. Now the application has to figure out which inputs are duplicates, and that process is super complicated. Secondly, the main reason to use KPML is to avoid having a media stream going toward a user interface. But there's already a media stream for the prompting, so there are no real savings 💀
6. Framework Overview 🧚
okay so in this framework, we use the term "SIP application" to refer to a broad set of functionality 💜 A SIP application is a program running on a SIP-based element (like a proxy or a user agent) that gives some value-added function to a user or a system administrator. SIP applications can run on behalf of a caller, a called party, or a whole bunch of users at once 👑
Each application has a number of instances running at any given time 🌸 An instance is a single execution path for an application, and it gets established because of some event. That event can be a SIP event, like receiving a SIP INVITE request, or it can be a non-SIP event, like a web form post or even a timer ⏰ Application instances also have an end time. Some instances have a lifetime tied to a SIP transaction or dialog. For example, a proxy application might start when an INVITE arrives and end when the call is answered 📲 Other applications have a lifetime that spans multiple dialogs or transactions. Say a conferencing application instance exists as long as there are dialogs connected to it. Once the last dialog ends, the application instance ends too 🫶 And some applications have a lifetime that's totally decoupled from SIP events, so they just do their own thing 🦋
Here's the fundamental part of this framework: multiple application instances may interact with a user during a single SIP transaction or dialog ✨ Each instance can be for the same application or for different applications. These applications can be completely independent, each owned by a different provider, and they might not even know each other exists 🙈 Also, there can be application instances talking to the caller and instances talking to the callee, all within the same transaction or dialog 🍓
The first step in interacting with the user is to instantiate one or more user interface components for the application instance 🎀 A user interface component is a single piece of the user interface, defined by a logical flow that isn't synchronously coupled with any other component. In other words, each component runs independently 🏃♀️
A user interface component can be instantiated in one of the user agents in a dialog (for a client-local user interface), or inside a network element (for a client-remote user interface) 🖥️ If you want a client-local user interface, the application has to figure out whether the user agent can support one, and in what format. In this framework, all client-local user interface components are described by a markup language 📝 A markup language describes a logical flow for presenting information to the user, collecting information from the user, and sending that information to an application. Examples include HTML, Wireless Markup Language (WML), VoiceXML, and the Keypad Markup Language (KPML) [8] 💅
Unlike an application instance, which has a very flexible lifetime, a user interface component has a very fixed one 🔒 A user interface component is always associated with a dialog. It can be created at any point after the dialog (or early dialog) is created, but it terminates when the dialog terminates. The user agent can terminate it earlier, and possibly the application can too, but its lifetime never goes past its associated dialog ⏳
There are two ways to create a client-local interface component 🛠️ For interface components that are presentation capable, the application sends a REFER [7] request to the user agent. The Refer-To header field contains an HTTP URI pointing to the markup for the user interface, and the REFER contains a Target-Dialog header field [10] that identifies the dialog associated with the user interface component 🎯 For presentation-free user interface components (like the ones defined by KPML), the application sends a SUBSCRIBE request to the user agent. The body of the SUBSCRIBE request contains a filter, which in this case is the markup that defines when information gets sent to the application in a NOTIFY 📨 The SUBSCRIBE does not contain the Target-Dialog header field, since the same info is conveyed in the Event header field 🧠
If a user interface component is going to be instantiated in the network, there's no need to figure out the capabilities of the device it runs on 🌐 Presumably it's on a device where the application already knows a UI can be created. But the application still needs to connect the user device to the user interface, and that means manipulating media streams to set up the connection 🎶
The interface between the user interface component and the application depends on the type of user interface 🔌 For presentation-capable user interfaces, like the ones described by HTML and VoiceXML, HTTP form POST operations are used. For presentation-free user interfaces, a SIP NOTIFY is used. The different needs and capabilities of these two kinds of user interface, as described in Section 4.4, are what drive the different choices for these interactions 💖 Since presentation-capable user interfaces need an update to the presentation every time user data is entered, they're a great match for HTTP. Since presentation-free user interfaces just pass user input along to the application, a NOTIFY is more appropriate 📬
And for presentation-free user interfaces, there are two different modalities 🌈 The first is called "one shot". In the one-shot role, the markup waits for a user to enter some information and, once they do, reports that event to the application. The application then does something, and the markup isn't used anymore 💫 The other modality is called "monitor". The markup stays permanently resident and keeps reporting information back to an application until the associated dialog terminates 👀
7. Deployment Topologies 🌷
Okay this section shows some of the network topologies where this framework can be set up 🗺️
7.1. Third-Party Application 💌
+-------------+
/---| Application |
/ +-------------+
/
SUB/ / REFER/
NOT / HTTP
/
+--------+ SIP (INVITE) +-----+
| UI A--------------------X |
|........| | SIP |
| User | RTP | UA |
| Device B--------------------Y |
+--------+ +-----+
Figure 2: Third-Party TopologyIn this topology, the application that wants to interact with the users lives outside the SIP dialog between the user agents 🙅♀️ So the application finds out about the dialog starting and ending, plus the dialog identifiers, through some out-of-band means. One option is the dialog event package [16] 📡 Dialog information is only revealed to trusted parties, so the application would need to be trusted by one of the users to get this info 🔐
At any point during the dialog, the application can instantiate user interface components on the user device of the caller or the callee 💁♀️ It does this using either SUBSCRIBE or REFER, depending on the type of user interface (presentation capable or presentation free) 🎀
7.2. Co-Resident Application 🏠
+--------+ SIP (INVITE) +-----+
| User A--------------------X SIP |
| Device | RTP | UA |
|........B--------------------Y |
| | SUB/NOT | App)|
| UI A'-------------------X' |
+--------+ REFER/HTTP +-----+
Figure 3: Co-Resident TopologyIn this deployment topology, the application is co-resident with one of the user agents (the one on the right in the picture above) 🧑💻 That application can install client-local user interface components on the other user agent, which is acting as the user device. These components can be installed using either SUBSCRIBE, for presentation-free user interfaces, or REFER, for presentation-capable ones 💕 This usually happens when the application wants to install UI components on a presentation-capable user interface. If the only user input is keypad input, the framework isn't really needed, because the UA/application will receive that input via RFC 4733 in the RTP stream 🎹✨
If the application resides in the called party, it's called a "terminating application" 📥 If it resides in the calling party, it's called an "originating application" 📤
This kind of topology is super common in protocol converter and gateway applications 🌉 💜
7.3. Third-Party Application and User Device Proxy ✨
Okay bestie, this one is a third-party application again (see Section 7.1. 💅), but nobody installs the UI on the phone itself this time 🫶. It lives on a middleman box called a User Device Proxy 🎀.
+-------------+
/---| Application |
/ +-------------+
/
SUB/ / REFER/
NOT / HTTP
/
+-----+ SIP +---M----+ SIP +-----+
| V--------------------C A--------------------X |
| SIP | | UI | | SIP |
| UAa | RTP | | RTP | UAb |
| W--------------------D B--------------------Y |
+-----+ +--------+ +-----+
User User
Device Device
ProxyFigure 4: User Device Proxy Topology
So from the real user device's point of view (the one on the left 👈), the User Device Proxy is a client remote user interface. That means the media, usually RTP (plus RFC 4733 for carrying user input 🦋), gets sent from the device over to that client remote UI on the proxy. The app thinks it's installing a client-local UI on the device, but it's really sitting on a user device proxy that just looks like the device to the app. Iconic illusion 😭
The user device proxy has to terminate and re-originate both the signaling (SIP) and the media traffic toward the actual peer in the conversation. It's a media relay in the terminology of RFC 3550 [18]. It also has to keep an eye on the media streams tied to each dialog, so it can turn the user input it spots in the media stream into events reported to the user interface.
This can get messy in multi-media systems, because it might not be clear which media stream the user input is being sent on 🙈. As discussed in RFC 3264 [20], if a user agent has a single media source and supports multiple streams, it's supposed to send that source to all of the streams. When there are multiple sources, the mapping is a matter of local policy. If there's no way to explicitly identify or request which sources map to which streams, the user device proxy just has to do the best job it can 💀.
This specification RECOMMENDS that the User Device Proxy monitor the first stream (defined in terms of ordering of media sessions within a session description). So user agents SHOULD send their user input on the first stream, unless a policy says to direct it somewhere else. 🌸
7.4. Proxy Application
+----------+
SUB/NOT | App | SUB/NOT
+--------------->| |<-----------------+
| REFER/HTTP |..........| REFER/HTTP |
| | SIP | |
| | Proxy | |
| +----------+ |
V ^ | V
+----------+ | | +----------+
| UI | INVITE | | INVITE | UI |
| |------------+ +------------>| |
|......... | |..........|
| SIP |...................................| SIP |
| UA | | UA |
+----------+ RTP +----------+
User Device User DeviceFigure 5: Proxy Application Topology
In this topology, the app is co-resident with a transaction stateful, record-routing proxy server sitting on the call path between two user devices 🧚. The application uses SUBSCRIBE or REFER to install user interface components on one or both of the user devices. Main character energy 👑
This topology is super common in routing applications, like a web-assisted call-routing application 🌈.
8. Application Behavior 💜
The behavior of an application in this framework depends on whether it wants to use a client-local or a client-remote user interface 🦋.
8.1. Client-Local Interfaces
Client-local user interfaces are a huge piece of this framework, so they get their own section ✨.
8.1.1. Discovering Capabilities
A client-local user interface can only be instantiated on a user agent if that user agent supports that type of user interface component 💅. Both the UAC and the UAS declare support for client-local UI components in their Allow, Accept, Supported, and Allow-Event header fields, in dialog-initiating requests and responses.
If the Allow header field indicates support for the SIP SUBSCRIBE method, the Allow-Event header field indicates support for the KPML package [8], and the Supported header field indicates support for the Globally Routable UA URI (GRUU) [9] specification (which, in turn, means the Contact header field contains a GRUU), then the UA can instantiate presentation-free user interface components 🎀. In that case, the application can push presentation-free user interface components according to the rules of Section 8.1.2. The specific markup languages that can be supported are indicated in the Accept header field.
If the Allow header field indicates support for the SIP REFER method, the Supported header field indicates support for the Target-Dialog header field [10], and the Contact header field contains UA capabilities [6] that indicate support for the HTTP URI scheme, then the UA supports presentation-capable user interface components 🌸. In that case, the application can push presentation-capable user interface components to the client according to the rules of Section 8.1.2. The specific markups that are supported are indicated in the Accept header field.
A third-party application that isn't on the call path won't see these header fields in the dialog-initiating requests that pass by 🙈. So it needs to get this capability information some other way. One option is the registration event package [21], which can carry user agent capability information provided in REGISTER requests [6].
8.1.2. Pushing an Initial Interface Component
Generally, we expect interface components to be created at various points in a SIP session 🍓. Obviously they need to be pushed during session setup, or after the session is established. A user interface component is always tied to a specific dialog, though.
An application MUST NOT attempt to push a user interface component to a user agent until it has determined that the user agent has the necessary capabilities and a dialog has been created. For a UAC, this means an application MUST NOT push a user interface component for an INVITE-initiated dialog until it has seen a request confirming receipt of a dialog-creating response. That could be an ACK for a 200 OK, or a PRACK for a provisional response [3]. For SUBSCRIBE-initiated dialogs, the application MUST NOT push a user interface component until it has seen a 200 OK to the NOTIFY request. For a user interface component on a UAS, the application MUST NOT push a user interface component for an INVITE-initiated dialog until it has seen a dialog-creating response from the UAS. For a SUBSCRIBE-initiated dialog, it MUST NOT push a user interface component until it has seen a NOTIFY request from the notifier 🔥.
To create a presentation-capable UI component on the UA, the application sends a REFER request to the UA. This REFER MUST be sent to the GRUU [9] advertised by that UA in the Contact header field of the dialog-initiating request or response sent by that UA. Note that this REFER request creates a separate dialog between the application and the UA 🦋. The Refer-To header field of the REFER request MUST contain an HTTP URI that references the markup document to be fetched.
It's also essential for the REFER request to be correlated with the dialog the user interface component will be associated with 👑. This is needed for authorization, and for terminating the user interface components when the dialog terminates. To provide this context, the REFER request MUST contain a Target-Dialog header field identifying the dialog with which the user interface component is associated. As discussed in [10], this request will also contain a Require header field with the tdialog option tag.
To create a presentation-free user interface component, the application sends a SUBSCRIBE request to the UA. The SUBSCRIBE MUST be sent to the GRUU advertised by the UA. This SUBSCRIBE request creates a separate dialog. The SUBSCRIBE request MUST use the KPML [8] event package. The body of the SUBSCRIBE request contains the markup document that defines the conditions under which the application wants to be notified of user input 🧚.
In both cases, the REFER or SUBSCRIBE request SHOULD include a display name in the From header field that identifies the name of the application 💖. For example, a prepaid calling card might have a From header field that looks like:
From: "Prepaid Calling Card" <sip:prepaid@example.com>Any of the SIP identity assertion mechanisms that have been defined, such as [11] and [13], apply to these requests too 🔐.
8.1.3. Updating an Interface Component
Once a user interface component has been created on a client, it can be updated 🌷. How you update it depends on the type of UI component.
Presentation-capable UI components are updated using techniques already in place for those markups 💅. Specifically, user input causes an HTTP POST operation to push that input to the application. The result of the POST operation is a new markup that the UI is supposed to use, so the UI can change in response to what the user does ✨. Some markups, like HTML, can force a refresh after a set period of time, so the UI updates without any user input, and those mechanisms can be used here as well. However, there's no support for an asynchronous push of an updated UI component from the application to the user agent 😭. A new REFER request to the same GRUU creates a new UI component rather than updating any components already in place.
Presentation-free UI is a different story 🎀. The application MAY update the filter at any time by generating a SUBSCRIBE refresh with the new filter, and the UA will immediately start using that new filter 🫶.
8.1.4. Terminating an Interface Component 💅
Okay so UI components have a well-defined lifetime 🫶 They get created the moment they're first pushed to the client, and they're always tied to the SIP dialog they were pushed on. That means their lifetime is bound by the dialog's lifetime. Dialog ends, component ends. Bye bye 👋
BUT there are times when the application wants to kill the UI component before its natural end point 😭 For presentation-capable user interfaces, that's not possible 🙅♀️ For presentation-free user interfaces, the application MAY terminate the component by sending a SUBSCRIBE with Expires equal to zero. That ends the subscription, and the UI component gets removed. Iconic. 🦋
A client can remove a UI component at any time 🙈 For presentation-capable UI, this is basically the user closing the web form window. There's no mechanism for reporting that kind of event back to the application, so the application MUST be prepared to time out and never receive input from a user 💀 How long that timeout lasts is up to the application. For presentation-free user interfaces, the UA can explicitly terminate the subscription. That results in a NOTIFY with a Subscription-State header field equal to "terminated" ✨
8.2. Client-Remote Interfaces 🌈
So instead of client-local user interfaces, or alongside them, an application can use client-remote user interfaces 💖 These can run co-resident with the application itself (in which case no standardized interfaces between the UI and the application need to be used), or they can run separately. This framework assumes the user interface runs on a host with a sufficient trust relationship with the application, so how the user interface gets instantiated isn't considered here 🧚
The main issue is connecting the user device to the remote user interface. That takes manipulating media streams between the client and the user interface, and only user agents can do that kind of manipulation 🎀 There are two types of user agent applications in this framework: originating/terminating applications, and intermediary applications.
8.2.1. Originating and Terminating Applications 📞
Originating and terminating applications are apps that are themselves the originator or the final recipient of a SIP invitation. They're "pure" user agent applications, not back-to-back user agents, so no sneaky middle person energy here 😌 The classic example is an interactive voice response (IVR) application, which is typically a terminating application. It's terminating because the user explicitly calls it, i.e., it's the actual called party. An example of an originating application is a wakeup call application, which calls a user at a specified time to wake them up ⏰
Since originating and terminating applications are a natural termination point of the dialog, manipulating the media session is trivial for them 💅 Traditional SIP techniques for adding and removing media streams, modifying codecs, and changing the address of the recipient of the media streams can all be applied.
8.2.2. Intermediary Applications 🕵️♀️
Intermediary applications are, at the same time, more common than originating/terminating applications AND more complex 😩 They're applications that are neither the actual caller nor the called party. Instead, they represent a "third party" that wants to interact with the user. The ubiquitous prepaid calling card application is the classic example 💳
For an intermediary application to add a client-remote user interface, it needs to manipulate the user agent's media streams so they terminate on that user interface. This also introduces a fundamental feature interaction issue 🙃 Since the intermediary application isn't an actual participant in the call, the user will need to interact with both the intermediary application and its peer in the dialog. Doing both at the same time is complicated, and it's discussed in more detail in Section 10 📖
9. User Agent Behavior ✨
9.1. Advertising Capabilities 📣
In order to take part in applications that use stimulus interfaces, a user agent needs to advertise its interaction capabilities 🔥
If a user agent supports presentation-capable user interfaces, it MUST support the REFER method. It MUST include, in all dialog-initiating requests and responses, an Allow header field that includes the REFER method. The user agent MUST support the target dialog specification [10], and MUST include the "tdialog" option tag in the Supported header field of dialog-forming requests and responses. Furthermore, the UA MUST support the SIP user agent capabilities specification [6]. The UA MUST be capable of being REFERed to an HTTP URI. It MUST include, in the Contact header field of its dialog-initiating requests and responses, a "schemes" Contact header field parameter that includes the HTTP URI scheme. The UA MUST include, in all dialog-initiating requests and responses, an Accept header field listing all of those markups supported by the UA. It is RECOMMENDED that all user agents that support presentation-capable user interfaces support HTML 🌸
If a user agent supports presentation-free user interfaces, it MUST support the SUBSCRIBE [4] method. It MUST support the KPML [8] event package. It MUST include, in all dialog-initiating requests and responses, an Allow header field that includes the SUBSCRIBE method. It MUST include, in all dialog-initiating requests and responses, an Allow-Events header field that lists the KPML event package. The UA MUST include, in all dialog-initiating requests and responses, an Accept header field listing those event filters it supports. At a minimum, a UA MUST support the "application/kpml-request+xml" MIME type 🧃
For either presentation-free or presentation-capable user interfaces, the user agent MUST support the GRUU [9] specification. The Contact header field in all dialog-initiating requests and responses MUST contain a GRUU. The UA MUST include a Supported header field that contains the "gruu" option tag and the "tdialog" option tag 💜
Because these headers get examined by proxies that may be executing applications, a UA that wishes to support client-local user interfaces should not encrypt them. Not encrypting them is the move 🙈
9.2. Receiving User Interface Components 🎀
Once the UA has created a dialog (in either the early or confirmed states), it MUST be prepared to receive a SUBSCRIBE or REFER request against its GRUU. If the UA receives such a request before a dialog is established, the UA MUST reject the request 🚫
A user agent SHOULD attempt to authenticate the sender of the request. The sender will generally be an application, so the user agent is unlikely to ever share a secret with it, which makes digest authentication useless here 🥲 Authenticated identities can still be obtained through other means, though, like the Identity mechanism [11] ✨
A user agent MAY have pre-defined authorization policies that permit applications which have authenticated themselves with a particular identity to push user interface components. If such policies are present, they get checked first. If the application is authorized, processing carries on 🦋
If the application has authenticated itself but isn't explicitly authorized or blocked, this specification RECOMMENDS that the application be automatically authorized if it can prove that it was either on the call path, or is trusted by one of the elements on the call path. An application proves this to the user agent by demonstrating that it knows the dialog identifiers. It does that by including them in a Target-Dialog header field for REFER requests, or in the Event header field parameters of the KPML SUBSCRIBE request 🔑
Because the dialog identifiers serve as a tool for authorization, a user agent compliant to this framework SHOULD use dialog identifiers that are cryptographically random, with at least 128 bits of randomness. It is recommended that this randomness be split between the Call-ID and From header field tags in the case of a UAC 🎲
Furthermore, to make sure only applications resident in or trusted by on-path elements can instantiate a user interface component, a user agent compliant to this specification SHOULD use the Session Initiation Protocol Secure (SIPS) URI scheme for all dialogs it initiates. This guarantees secure links between all the elements on the signaling path 🔐
If the dialog was not established with a SIPS URI, or the user agent didn't choose cryptographically random dialog identifiers, then the application MUST NOT automatically be authorized, even if it presented valid dialog identifiers. A user agent MAY apply any other policies in addition to (but not instead of) the ones specified here in order to authorize the creation of the user interface component. One such mechanism would be to prompt the user, informing them of the identity of the application and the dialog it's associated with. If an authorization policy requires user interaction, the user agent SHOULD respond to the SUBSCRIBE or REFER request with a 202. In the case of SUBSCRIBE, if authorization isn't granted, the user agent SHOULD generate a NOTIFY to terminate the subscription. In the case of REFER, the user agent MUST NOT act upon the URI in the Refer-To header field until user authorization is obtained 🙅♀️
If an application doesn't present a valid dialog identifier in its REFER or SUBSCRIBE request, the user agent MUST reject the request with a 403 response. No valid ID, no entry 💀
If a REFER request to an HTTP URI is authorized, the UA executes the URI and fetches the content to be rendered to the user. This instantiates a presentation-capable user interface component. If a SUBSCRIBE was authorized, a presentation-free user interface component is instantiated 🌈
9.3. Mapping User Input to User Interface Components 🎯
Once the user interface components are instantiated, the user agent must direct user input to the appropriate component. For presentation-capable user interfaces, this process is known as focus selection, and it's done by means that are specific to the user interface on the device. On a PC, for example, the window manager lets the user select the appropriate user interface component their input is directed to 🖥️
For presentation-free user interfaces, things get more complicated 😵💫 In some cases, the device may support a mechanism that lets the user select a "line", and thus the associated dialog. Any keypad input while this line is selected gets fed to the user interface components associated with that dialog ☎️
Otherwise, for client-local user interfaces, the user input is assumed to be associated with all user interface components. For client-remote user interfaces, the user device converts the user input to media, typically conveyed using RFC 4733, and sends it to the client-remote user interface. That user interface then needs to map user input from potentially many media streams into user interface events. The process for doing this is described in Section 7.3 🫶
9.4. Receiving Updates to User Interface Components ✨
okay so for presentation-capable user interfaces, updates happen in ways that are specific to that UI component 💅. In HTML, for example, the document can literally tell the client to fetch a new document every so often 🌸. But this framework does NOT give you any extra machinery to asynchronously push a brand new user interface component to the client. not me... no extra push stuff here 🙈
For presentation-free user interfaces, an application can push an update to a component by sending a SUBSCRIBE refresh with a new filter 🦋. The user agent will process these according to the rules of the event package ✨.
9.5. Terminating a User Interface Component 🎀
Terminating a presentation-capable user interface component is a trivial procedure 💖. The user agent just dismisses the window (or its equivalent). The fact that the component was dismissed is NOT communicated to the application, so it's purely a local matter 🫶.
For a presentation-free user interface, the user might want to stop interacting with the application 🥺. However, most presentation-free user interfaces won't have a way for the user to signal this through the device 💀. If such a mechanism did exist, the UA SHOULD generate a NOTIFY request with a Subscription-State header field equal to "terminated" and a reason of "rejected". This tells the application that the component has been removed and that it should not attempt to re-subscribe 🙅♀️.
10. Inter-Application Feature Interaction 👑
the inter-application feature interaction problem is inherent to stimulus signaling 🧠. Whenever there are multiple applications, there are multiple user interfaces, and the system has to figure out which user interface any particular input is destined for. That question IS the essence of the inter-application feature interaction problem 💯.
Inter-application feature interaction is not an easy problem to resolve 😭. For now, we look at the issues for client-local and client-remote user interface components separately.
10.1. Client-Local UI 🌈
When the user interface itself lives locally on the client device, the feature interaction problem is actually much simpler ✨. The end device knows explicitly about each application, so it can present the user with each one separately. When the user provides input, the client device can determine which user interface the input is destined for. The user interface that the input is destined for is called the "application in focus", and the way the focused application gets selected is called "focus determination" 🎯.
Generally speaking, focus determination is purely a local operation 🏠. In the PC universe, focus determination is provided by window managers. Each application doesn't know about focus; it just receives the user input that was targeted at it when it's in focus. This basic concept applies to SIP-based applications as well 🦋.
Focus determination will frequently be trivial, depending on the user interface type 💅. Picture a user making a call from a PC. The call passes through a prepaid calling card application and a call-recording application. Both of these want to interact with the user, so both push an HTML-based user interface to them. On the PC, each user interface shows up as its own window. The user interacts with the call-recording application by selecting its window, and with the prepaid calling card application by selecting its window. Focus determination is literally provided by the PC window manager, so it's super clear which application the user input is targeted at 🖥️✨.
Now here's another example with the same two applications, but on a "smart phone" that has a set of buttons, with an LCD display next to each button that can show the user an option 📱. This user interface can be represented using the Wireless Markup Language (WML), for example 🧚.
The phone would allocate some number of buttons to each application. The prepaid calling card would get one button for its "hangup" command, and the recording application would get one for its "start/ stop" command. The user can easily figure out which application to interact with by pressing the right button 🙌. Pressing a button determines focus and provides user input, both at the same time 🤯.
Unfortunately, not all devices have these advanced displays 😩. A PSTN gateway, or a basic IP telephone, may only have a 12-key keypad. The user interfaces for these devices are provided through the Keypad Markup Language (KPML). Going back to the feature interaction case above, the prepaid calling card application and the call-recording application would both pass a KPML document to the device. When the user presses a button on the keypad, which document does the input apply to? The device doesn't let the user select one 🤷♀️. A device where the user cannot provide focus is called a "focusless device". This is quite a hard problem to solve 😵💫. This framework does not make any explicit normative recommendation, but it concludes that the best option is to send the input to both user interfaces, unless the markup in one interface has indicated that it should be suppressed from the others 🫠. This is a sensible choice by analogy -- it's exactly what the existing circuit-switched telephone network will do 📞. It is an explicit non-goal to provide a better mechanism for feature interaction resolution than the PSTN on devices that have the same user interface as they do on the PSTN 🚫. Devices with better displays, such as PCs or screen phones, can benefit from the capabilities of this framework, letting the user decide which application they're interacting with 💖.
Indeed, when a user provides input on a focusless device, the input MUST... okay wait, lowercase here: the input must be passed to all client-local user interfaces AND all client-remote user interfaces, unless the markup tells the UI to suppress the media 🫨. For KPML, key events are passed to remote user interfaces by encoding them as described in RFC 4733 [19]. Of course, since a client can't tell whether or not a media stream terminates in a remote user interface, these key events get passed in all audio media streams unless the KPML request document is used to suppress them 🎧💜.
10.2. Client-Remote UI 🧚
When the user interfaces run remotely, figuring out focus can be much, much harder 😤. There are lots of architectures that can be deployed to handle the interaction. None of them are ideal 💀. However, all of them are beyond the scope of this specification 📜.
11. Intra Application Feature Interaction 💜
An application can instantiate a whole multiplicity of user interface components 🍓. For example, a single application can instantiate two separate HTML components and one WML component. Furthermore, an application can instantiate both client-local and client-remote user interfaces 🌸.
The feature interaction issues between these components within the same application are way less severe 🙌. If an application has multiple client user interface components, their interaction is resolved exactly like the inter-application case, through focus determination. The problems on focusless user devices (like a keypad on a telephone) generally won't exist, though, since the application can generate user interfaces that don't overlap in how they use an input ✨.
The real issue is that the optimal user experience frequently requires some kind of coupling between the different user interface components 😮💨. This is a classic problem in multi-modal user interfaces, like the ones described by Speech Application Language Tags (SALT). As an example, picture a user interface where the user can either press a labeled button to make a selection, or listen to a prompt and speak the desired selection 🎤. Ideally, when the user presses the button, the prompt should stop immediately, since both were targeted at collecting the same information in parallel 🛑. Interactions like this are best handled by markups that natively support them, like SALT, so they require no explicit support from this framework 🫶🔥.
12. Example Call Flow 🎀
Okay bestie, this section is a walkthrough of a call-recording app 🎙️ 💖 A user can hit record right from a web form during their call. The app pushes a presentation-capable UI component down to the caller, and the conventions of [17] are used to show long message lines. Let's gooo 🧚
A Recording App B
|(1) INVITE | |
|----------------------->| |
| |(2) INVITE |
| |----------------------->|
| |(3) 200 OK |
| |<-----------------------|
|(4) 200 OK | |
|<-----------------------| |
|(5) ACK | |
|----------------------->| |
| |(6) ACK |
| |----------------------->|
|(7) REFER | |
|<-----------------------| |
|(8) 200 OK | |
|----------------------->| |
|(9) NOTIFY | |
|----------------------->| |
|(10) 200 OK | |
|<-----------------------| |
|(11) HTTP GET | |
|----------------------->| |
|(12) 200 OK | |
|<-----------------------| |
|(13) NOTIFY | |
|----------------------->| |
|(14) 200 OK | |
|<-----------------------| |
|(15) HTTP POST | |
|----------------------->| |
|(16) 200 OK | |
|<-----------------------| |Figure 6
First up, the caller, A, sends an INVITE to start the call (message 1) 📞 Since A supports the framework and can handle presentation-capable UI components, the INVITE includes a Supported header field saying the GRUU extension and the Target-Dialog header field are understood ✨ It also has an Allow header field saying REFER is understood, plus a Contact header field carrying the "schemes" header field parameter 💅
INVITE sip:B@example.com SIP/2.0
Via: SIP/2.0/TLS host.example.com;branch=z9hG4bK9zz8
From: Caller <sip:A@example.com>;tag=kkaz-
To: Callee <sip:B@example.org>
Call-ID: fa77as7dad8-sd98ajzz@host.example.com
CSeq: 1 INVITE
Max-Forwards: 70
Supported: gruu, tdialog
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, REFER
Accept: application/sdp, text/html
<allOneLine>
Contact: <sip:A@example.com;gr=urn:uuid:f81d4fae
-7dec-11d0-a765-00a0c91e6bf6>;schemes="http,sip"
</allOneLine>
Content-Length: ...
Content-Type: application/sdp
--SDP not shown--The proxy is acting as a recording server here 🦋 It forwards the INVITE on to the called party (message 2). Because the INVITE has a GRUU in it, the proxy skips the Record-Route it would normally add 🙈
INVITE sip:B@pc.example.com SIP/2.0
Via: SIP/2.0/TLS app.example.com;branch=z9hG4bK97sh
Via: SIP/2.0/TLS host.example.com;branch=z9hG4bK9zz8
From: Caller <sip:A@example.com>;tag=kkaz-
To: Callee <sip:B@example.org>
Call-ID: fa77as7dad8-sd98ajzz@host.example.com
CSeq: 1 INVITE
Max-Forwards: 70
Supported: gruu, tdialog
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, REFER
Accept: application/sdp, text/html
<allOneLine>
Contact: <sip:A@example.com;gr=urn:uuid:f81d4fae
-7dec-11d0-a765-00a0c91e6bf6>;schemes="http,sip"
</allOneLine>
Content-Length: ...
Content-Type: application/sdp
--SDP not shown--B picks up with a 200 OK (message 3) 🌸 B doesn't support the framework, so none of those extra header fields show up. Lowkey a plain old call, and that's totally fine 🫶
SIP/2.0 200 OK
Via: SIP/2.0/TLS app.example.com;branch=z9hG4bK97sh
Via: SIP/2.0/TLS host.example.com;branch=z9hG4bK9zz8
From: Caller <sip:A@example.com>;tag=kkaz-
To: Callee <sip:B@example.com>;tag=7777
Call-ID: fa77as7dad8-sd98ajzz@host.example.com
CSeq: 1 INVITE
Contact: <sip:B@pc.example.com>
Content-Length: ...
Content-Type: application/sdp
--SDP not shown--That 200 OK gets passed back to the caller (message 4) 🍓
SIP/2.0 200 OK
Record-Route: <sip:app.example.com;lr>
Via: SIP/2.0/TLS host.example.com;branch=z9hG4bK9zz8
From: Caller <sip:A@example.com>;tag=kkaz-
To: Callee <sip:B@example.com>;tag=7777
Call-ID: fa77as7dad8-sd98ajzz@host.example.com
CSeq: 1 INVITE
Contact: <sip:B@pc.example.com>
Content-Length: ...
Content-Type: application/sdp
--SDP not shown--The caller sends an ACK (message 5) ✅
ACK sip:B@pc.example.com
Route: <sip:app.example.com;lr>
Via: SIP/2.0/TLS host.example.com;branch=z9hG4bK9zz9
From: Caller <sip:A@example.com>;tag=kkaz-
To: Callee <sip:B@example.com>;tag=7777
Call-ID: fa77as7dad8-sd98ajzz@host.example.com
CSeq: 1 ACKThat ACK gets forwarded to the called party (message 6) 💜
ACK sip:B@pc.example.com
Via: SIP/2.0/TLS app.example.com;branch=z9hG4bKh7s
Via: SIP/2.0/TLS host.example.com;branch=z9hG4bK9zz9
From: Caller <sip:A@example.com>;tag=kkaz-
To: Callee <sip:B@example.com>;tag=7777
Call-ID: fa77as7dad8-sd98ajzz@host.example.com
CSeq: 1 ACKNow the app decides it wants to push a UI component to user A, so it sends A a REFER request (message 7) 👑
REFER sip:A@example.com;gr=urn:uuid:f81d4fae
-7dec-11d0-a765-00a0c91e6bf6 SIP/2.0
Refer-To: https://app.example.com/script.pl
Target-Dialog: fa77as7dad8-sd98ajzz@host.example.com
;remote-tag=7777;local-tag=kkaz-
Require: tdialog
Via: SIP/2.0/TLS app.example.com;branch=z9hG4bK9zh6
Max-Forwards: 70
From: Recorder Application <sip:app.example.com>;tag=jhgf
To: Caller <sip:A@example.com;gr=urn:uuid:f81d4fae
-7dec-11d0-a765-00a0c91e6bf6>
Require: tdialog
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, REFER
Call-ID: 66676776767@app.example.com
CSeq: 1 REFER
Event: refer
Contact: <sip:app.example.com>Since the recording application is the same as the authoritative proxy for the domain, it resolves the Request URI to the registered contact of A, and then sent there. The REFER gets a 200 OK (message 8) 🥰
SIP/2.0 200 OK
Via: SIP/2.0/TLS app.example.com;branch=z9hG4bK9zh6
From: Recorder Application <sip:app.example.com>;tag=jhgf
To: Caller <sip:A@example.com>;tag=pqoew
Call-ID: 66676776767@app.example.com
Supported: gruu, tdialog
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, REFER
<allOneLine>
Contact: <sip:A@example.com;gr=urn:uuid:f81d4fae
-7dec-11d0-a765-00a0c91e6bf6>;schemes="http,sip"
</allOneLine>
CSeq: 1 REFERUser A sends a NOTIFY (message 9) 📣
NOTIFY sip:app.example.com SIP/2.0
Via: SIP/2.0/TLS host.example.com;branch=z9hG4bK9320394238995
To: Recorder Application <sip:app.example.com>;tag=jhgf
From: Caller <sip:A@example.com>;tag=pqoew
Call-ID: 66676776767@app.example.com
CSeq: 1 NOTIFY
Max-Forwards: 70
<allOneLine>
Contact: <sip:A@example.com;gr=urn:uuid:f81d4fae
-7dec-11d0-a765-00a0c91e6bf6>;schemes="http,sip"
</allOneLine>
Event: refer;id=93809824
Subscription-State: active;expires=3600
Content-Type: message/sipfrag;version=2.0
Content-Length: 20
SIP/2.0 100 TryingAnd the recording server replies with a 200 OK (message 10) 🫧
SIP/2.0 200 OK
Via: SIP/2.0/TLS host.example.com;branch=z9hG4bK9320394238995
To: Recorder Application <sip:app.example.com>;tag=jhgf
From: Caller <sip:A@example.com>;tag=pqoew
Call-ID: 66676776767@app.example.com
CSeq: 1 NOTIFYHere's the tea 🔥 The REFER had a Target-Dialog header field parameter with a valid dialog identifier. On top of that, all of the signaling ran over TLS, and the dialog identifiers have enough randomness to be unguessable. So caller A automatically authorizes the application, no cap 🔐 A then acts on the Refer-To URI and fetches the script from app.example.com (message 11). The response (message 12) is a web app the user can click to turn recording on 💅 Since the client executed the URL in the Refer-To, it sends another NOTIFY to the application to say the response worked (message 13), and that gets a 200 OK (message 14) ✨ When the user clicks the link (message 15), the results get posted to the server, and an updated display comes back (message 16) 🎉
13. Security Considerations 🔐
Okay, security is a whole vibe here and we are taking it seriously 😭 This framework lets applications in the network put UI components onto a client device. That means those instantiations need to come from authenticated applications, and they also need to be authorized to place a UI into the client. Honestly, the stronger requirement is authorization. It matters less to know the name of the application's provider than to know that the provider is authorized to instantiate components 🛡️
This specification defines specific authorization techniques and requirements 💜 Automatic authorization is granted if the application can prove that it is on the call path, or is trusted by an element on the call path. As documented above, this can be accomplished with cryptographically random dialog identifiers and by using SIPS for message confidentiality. It is RECOMMENDED that SIPS be implemented by user agents compliant to this specification. This does not represent a change from the requirements in RFC 3261 🙌
14. Contributors 🧚
This document came out of discussions amongst the application interaction design team. Everyone on that team contributed a ton to the ideas in here 🫶 The members of this team were:
Eric Burger Cullen Jennings Robert Fairlie-Cuninghame
15. Acknowledgements 🌈
The authors would like to thank Martin Dolly and Rohan Mahy for their input and comments 💖 Thanks also to Allison Mankin for her support of this work ✨
16. References 📚
16.1. Normative References 💅
Okay bestie, these are the must-reads 📚 Everything below is cited exactly as the original has it.
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[3] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
Responses in Session Initiation Protocol (SIP)", RFC 3262,
June 2002.
[4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[5] McGlashan, S., Lucas, B., Porter, B., Rehor, K., Burnett, D.,
Carter, J., Ferrans, J., and A. Hunt, "Voice Extensible Markup
Language (VoiceXML) Version 2.0", W3C CR CR-voicexml20-
20030220, February 2003.
[6] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating
User Agent Capabilities in the Session Initiation Protocol
(SIP)", RFC 3840, August 2004.
[7] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
[8] Burger, E. and M. Dolly, "A Session Initiation Protocol (SIP)
Event Package for Key Press Stimulus (KPML)", RFC 4730,
November 2006.
[9] Rosenberg, J., "Obtaining and Using Globally Routable User
Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)",
RFC 5627, October 2009.
[10] Rosenberg, J., "Request Authorization through Dialog
Identification in the Session Initiation Protocol (SIP)",
RFC 4538, June 2006.16.2. Informative References 🦋
These ones are extra reading for when you're curious. Not required, but so good to know 🧚
[11] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)",
RFC 4474, August 2006.
[12] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence
and Instant Messaging", RFC 2778, February 2000.
[13] 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.
[14] Rosenberg, J., "A Framework for Conferencing with the Session
Initiation Protocol (SIP)", RFC 4353, February 2006.
[15] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
Preferences for the Session Initiation Protocol (SIP)",
RFC 3841, August 2004.
[16] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-
Initiated Dialog Event Package for the Session Initiation
Protocol (SIP)", RFC 4235, November 2005.
[17] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., and
H. Schulzrinne, "Session Initiation Protocol (SIP) Torture Test
Messages", RFC 4475, May 2006.
[18] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003.
[19] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF Digits,
Telephony Tones, and Telephony Signals", RFC 4733, December
2006.
[20] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[21] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Package for Registrations", RFC 3680, March 2004.Author's Address 🎀
Meet the author, Jonathan Rosenberg, who's at Cisco Systems 💜
Jonathan Rosenberg
Cisco Systems
600 Lanidex Plaza
Parsippany, NJ 07054
US
Phone: +1 973 952-5000
EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net📦 where this page comes from
- ietf: rfc5629 2009-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms