diff options
Diffstat (limited to 'doc/rfc/rfc5629.txt')
| -rw-r--r-- | doc/rfc/rfc5629.txt | 2131 |
1 files changed, 2131 insertions, 0 deletions
diff --git a/doc/rfc/rfc5629.txt b/doc/rfc/rfc5629.txt new file mode 100644 index 0000000..eb0cfd0 --- /dev/null +++ b/doc/rfc/rfc5629.txt @@ -0,0 +1,2131 @@ + + + + + + +Network Working Group J. Rosenberg +Request for Comments: 5629 Cisco Systems +Category: Standards Track October 2009 + + + A Framework for Application Interaction + in the Session Initiation Protocol (SIP) + +Abstract + + This document describes a framework for the interaction between users + and Session Initiation Protocol (SIP) based applications. By + interacting with applications, users can guide the way in which they + operate. The focus of this framework is stimulus signaling, which + allows a user agent (UA) to interact with an application without + knowledge of the semantics of that application. Stimulus signaling + can occur to a user interface running locally with the client, or to + a remote user interface, through media streams. Stimulus signaling + encompasses a wide range of mechanisms, ranging from clicking on + hyperlinks, to pressing buttons, to traditional Dual-Tone Multi- + Frequency (DTMF) input. In all cases, stimulus signaling is + supported through the use of markup languages, which play a key role + in this framework. + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (c) 2009 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the BSD License. + + + + + +Rosenberg Standards Track [Page 1] + +RFC 5629 App Interaction Framework October 2009 + + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, 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, except to format + it for publication as an RFC or to translate it into languages other + than English. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Rosenberg Standards Track [Page 2] + +RFC 5629 App Interaction Framework October 2009 + + +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 . . . . . . . . . . . . . . . . . . 37 + + + + + +Rosenberg Standards Track [Page 3] + +RFC 5629 App Interaction Framework October 2009 + + +1. Introduction + + The Session Initiation Protocol (SIP) [2] provides the ability for + users to initiate, manage, and terminate communications sessions. + Frequently, these sessions will involve a SIP application. A SIP + application is defined as a program running on a SIP-based element + (such as a proxy or user agent) that provides some value-added + function to a user or system administrator. Examples of SIP + applications include prepaid calling card calls, conferencing, and + presence-based [12] call routing. + + In order for most applications to properly function, they need input + from the user to guide their operation. As an example, a prepaid + calling card application requires the user to input their calling + card number, their PIN code, and the destination number they wish to + reach. The process by which a user provides input to an application + is called "application interaction". + + Application interaction can be either functional or stimulus. + Functional interaction requires the user device to understand the + semantics of the application, whereas stimulus interaction does not. + Stimulus signaling allows for applications to be built without + requiring modifications to the user device. Stimulus interaction is + the subject of this framework. The framework provides a model for + how users interact with applications through user interfaces, and how + user interfaces and applications can be distributed throughout a + network. This model is then used to describe how applications can + instantiate and manage user interfaces. + +2. Conventions Used in This Document + + 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 + + SIP Application: A SIP application is defined as a program running + on a SIP-based element (such as a proxy or user agent) that + provides some value-added function to a user or system + administrator. Examples of SIP applications include prepaid + calling card calls, conferencing, and presence-based [12] call + routing. + + Application Interaction: The process by which a user provides input + to an application. + + + + + +Rosenberg Standards Track [Page 4] + +RFC 5629 App Interaction Framework October 2009 + + + Real-Time Application Interaction: Application interaction that + takes place while an application instance is executing. For + example, when a user enters their PIN number into a prepaid + calling card application, this is real-time application + interaction. + + Non-Real-Time Application Interaction: Application interaction that + takes place asynchronously with the execution of the application. + Generally, non-real-time application interaction is accomplished + through provisioning. + + Functional Application Interaction: Application interaction is + functional when the user device has an understanding of the + semantics of the interaction with the application. + + Stimulus Application Interaction: Application interaction is + stimulus when the user device has no understanding of the + semantics of the interaction with the application. + + User Interface (UI): The user interface provides the user with + context to make decisions about what they want. The user + interacts with the device, which conveys the user input to the + user interface. The user interface interprets the information and + passes it to the application. + + User Interface Component: A piece of user interface that operates + independently of other pieces of the user interface. For example, + a user might have two separate web interfaces to a prepaid calling + card application: one for hanging up and making another call, and + another for entering the username and PIN. + + User Device: The software or hardware system that the user directly + interacts with to communicate with the application. An example of + a user device is a telephone. Another example is a PC with a web + browser. + + User Device Proxy: A software or hardware system that a user + indirectly interacts through to communicate with the application. + This indirection can be through a network. An example is a + gateway from IP to the Public Switched Telephone Network (PSTN). + It acts as a user device proxy, acting on behalf of the user on + the circuit network. + + User Input: The "raw" information passed from a user to a user + interface. Examples of user input include a spoken word or a + click on a hyperlink. + + + + + +Rosenberg Standards Track [Page 5] + +RFC 5629 App Interaction Framework October 2009 + + + Client-Local User Interface: A user interface that is co-resident + with the user device. + + Client-Remote User Interface: A user interface that executes + remotely from the user device. In this case, a standardized + interface is needed between the user device and the user + interface. Typically, this is done through media sessions: audio, + video, or application sharing. + + Markup Language: A markup language describes a logical flow of + presentation of information to the user, collection of information + from the user, and transmission of that information to an + application. + + Media Interaction: A means of separating a user and a user interface + by connecting them with media streams. + + Interactive Voice Response (IVR): An IVR is a type of user interface + that allows users to speak commands to the application, and hear + responses to those commands prompting for more information. + + Prompt-and-Collect: The basic primitive of an IVR user interface. + The user is presented with a voice option, and the user speaks + their choice. + + Barge-In: The act of entering information into an IVR user interface + prior to the completion of a prompt requesting that information. + + Focus: A user interface component has focus when user input is + provided to it, as opposed to any other user interface components. + This is not to be confused with the term "focus" within the SIP + conferencing framework, which refers to the center user agent in a + conference [14]. + + Focus Determination: The process by which the user device determines + which user interface component will receive the user input. + + Focusless Device: A user device that has no ability to perform focus + determination. An example of a focusless device is a telephone + with a keypad. + + Presentation-Capable UI: A user interface that can prompt the user + with input, collect results, and then prompt the user with new + information based on those results. + + + + + + + +Rosenberg Standards Track [Page 6] + +RFC 5629 App Interaction Framework October 2009 + + + Presentation-Free UI: A user interface that cannot prompt the user + with information. + + Feature Interaction: A class of problems that result when multiple + applications or application components are trying to provide + services to a user at the same time. + + Inter-Application Feature Interaction: Feature interactions that + occur between applications. + + DTMF: Dual-Tone Multi-Frequency. DTMF refers to a class of tones + generated by circuit-switched telephony devices when the user + presses a key on the keypad. As a result, DTMF and keypad input + are often used synonymously, when in fact one of them (DTMF) is + merely a means of conveying the other (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), making a call on behalf of the user. + + Terminating Application: A SIP application that acts as a User Agent + Server (UAS), answering a call generated by a user. IVR + applications are terminating applications. + + Intermediary Application: A SIP application that is neither the + caller or callee, but rather a third party involved in a call. + +4. A Model for Application Interaction + + +---+ +---+ +---+ +---+ + | | | | | | | | + | | | 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 Interactions + + + +Rosenberg Standards Track [Page 7] + +RFC 5629 App Interaction Framework October 2009 + + + Figure 1 presents a general model for how users interact with + applications. Generally, users interact with a user interface + through a user device. A user device can be a telephone, or it can + be a PC with a web browser. Its role is to pass the user input from + the user to the user interface. The user interface provides the user + with context in order to make decisions about what they want. The + user interacts with the device, causing information to be passed from + the device to the user interface. The user interface interprets the + information, and passes it as a user interface event to the + application. The application may be able to modify the user + interface based on this event. Whether or not this is possible + depends on the type of user interface. + + User interfaces are fundamentally about rendering and interpretation. + Rendering refers to the way in which the user is provided context. + This can be through hyperlinks, images, sounds, videos, text, and so + on. Interpretation refers to the way in which the user interface + takes the "raw" data provided by the user, and returns the result to + the application as a meaningful event, abstracted from the + particulars of the user interface. As an example, consider a prepaid + calling card application. The user interface worries about details + such as what prompt the user is provided, whether the voice is male + or female, and so on. It is concerned with recognizing the speech + that the user provides, in order to obtain the desired information. + In this case, the desired information is the calling card number, the + PIN code, and the destination number. The application needs that + data, and it doesn't matter to the application whether it was + collected using a male prompt or a female one. + + User interfaces generally have real-time requirements towards the + user. That is, when a user interacts with the user interface, the + user interface needs to react quickly, and that change needs to be + propagated to the user right away. However, the interface between + the user interface and the application need not be that fast. Faster + is better, but the user interface itself can frequently compensate + for long latencies between the user interface and the application. + In the case of a prepaid calling card application, when the user is + prompted to enter their PIN, the prompt should generally stop + immediately once the first digit of the PIN is entered. This is + referred to as "barge-in". After the user interface collects the + rest of the PIN, it can tell the user to "please wait while + processing". The PIN can then be gradually transmitted to the + application. In this example, the user interface has compensated for + a slow UI to application interface by asking the user to wait. + + The separation between user interface and application is absolutely + fundamental to the entire framework provided in this document. Its + importance cannot be overstated. + + + +Rosenberg Standards Track [Page 8] + +RFC 5629 App Interaction Framework October 2009 + + + With this basic model, we can begin to taxonomize the types of + systems that can be built. + +4.1. Functional vs. Stimulus + + The first way to taxonomize the system is to consider the interface + between the UI and the application. There are two fundamentally + different models for this interface. In a functional interface, the + user interface has detailed knowledge about the application and is, + in fact, specific to the application. The interface between the two + components is through a functional protocol, capable of representing + the semantics that can be exposed through the user interface. + Because the user interface has knowledge of the application, it can + be optimally designed for that application. As a result, functional + user interfaces are almost always the most user friendly, the + fastest, and the most responsive. However, in order to allow + interoperability between user devices and applications, the details + of the functional protocols need to be specified in standards. This + slows down innovation and limits the scope of applications that can + be built. + + An alternative is a stimulus interface. In a stimulus interface, the + user interface is generic -- that is, totally ignorant of the details + of the application. Indeed, the application may pass instructions to + the user interface describing how it should operate. The user + interface translates user input into "stimulus", which are data + understood only by the application, and not by the user interface. + Because they are generic, and because they require communications + with the application in order to change the way in which they render + information to the user, stimulus user interfaces are usually slower, + less user friendly, and less responsive than a functional + counterpart. However, they allow for substantial innovation in + applications, since no standardization activity is needed to build a + new application, as long as it can interact with the user within the + confines of the user interface mechanism. The web is an example of a + stimulus user interface to applications. + + In SIP systems, functional interfaces are provided by extending the + SIP protocol to provide the needed functionality. For example, the + SIP caller preferences specification [15] provides a functional + interface that allows a user to request applications to route the + call to specific types of user agents. Functional interfaces are + important, but are not the subject of this framework. The primary + goal of this framework is to address the role of stimulus interfaces + to SIP applications. + + + + + + +Rosenberg Standards Track [Page 9] + +RFC 5629 App Interaction Framework October 2009 + + +4.2. Real-Time vs. Non-Real-Time + + Application interaction systems can also be real-time or non-real- + time. Non-real-time interaction allows the user to enter information + about application operation asynchronously with its invocation. + Frequently, this is done through provisioning systems. As an + example, a user can set up the forwarding number for a call-forward + on no-answer application using a web page. Real-time interaction + requires the user to interact with the application at the time of its + invocation. + +4.3. Client-Local vs. Client-Remote + + Another axis in the taxonomization is whether the user interface is + co-resident with the user device (which we refer to as a client-local + user interface), or the user interface runs in a host separated from + the client (which we refer to as a client-remote user interface). In + a client-remote user interface, there exists some kind of protocol + between the client device and the UI that allows the client to + interact with the user interface over a network. + + The most important way to separate the UI and the client device is + through media interaction. In media interaction, the interface + between the user and the user interface is through media: audio, + video, messaging, and so on. This is the classic mode of operation + for VoiceXML [5], where the user interface (also referred to as the + voice browser) runs on a platform in the network. Users communicate + with the voice browser through the telephone network (or using a SIP + session). The voice browser interacts with the application using + HTTP to convey the information collected from the user. + + In the case of a client-local user interface, the user interface runs + co-located with the user device. The interface between them is + through the software that interprets the user's input and passes it + to the user interface. The classic example of this is the Web. In + the Web, the user interface is a web browser, and the interface is + defined by the HTML document that it's rendering. The user interacts + directly with the user interface running in the browser. The results + of that user interface are sent to the application (running on the + web server) using HTTP. + + It is important to note that whether or not the user interface is + local or remote (in the case of media interaction) is not a property + of the modality of the interface, but rather a property of the + system. As an example, it is possible for a Web-based user interface + to be provided with a client-remote user interface. In such a + scenario, video- and application-sharing media sessions can be used + between the user and the user interface. The user interface, still + + + +Rosenberg Standards Track [Page 10] + +RFC 5629 App Interaction Framework October 2009 + + + 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. Indeed, the VoiceXML document + can be rendered using text, rather than media, with no impact on the + interface between the user interface and the application. + + It is also important to note that systems can be hybrid. In a hybrid + user interface, some aspects of it (usually those associated with a + particular modality) run locally, and others run remotely. + +4.4. Presentation-Capable vs. Presentation-Free + + A user interface can be capable of presenting information to the user + (a presentation-capable UI), or it can be capable only of collecting + user input (a presentation-free UI). These are very different types + of user interfaces. A presentation-capable UI can provide the user + with feedback after every input, providing the context for collecting + the next input. As a result, presentation-capable user interfaces + require an update to the information provided to the user after each + input. The Web is a classic example of this. After every input + (i.e., a click), the browser provides the input to the application + and fetches the next page to render. In a presentation-free user + interface, this is not the case. Since the user is not provided with + feedback, these user interfaces tend to merely collect information as + it's entered, and pass it to the application. + + Another difference is that a presentation-free user interface cannot + easily support the concept of a focus. Selection of a focus usually + requires a means for informing the user of the available + applications, allowing the user to choose, and then informing them + about which one they have chosen. Without the first and third steps + (which a presentation-free UI cannot provide), focus selection is + very difficult. Without a selected focus, the input provided to + applications through presentation-free user interfaces is more of a + broadcast or notification operation. + +5. Interaction Scenarios on Telephones + + In this section, we apply the model of Section 4 to telephones. + + In a traditional telephone, the user interface consists of a 12-key + keypad, a speaker, and a microphone. Indeed, from here forward, the + term "telephone" is used to represent any device that meets, at a + minimum, the characteristics described in the previous sentence. + Circuit-switched telephony applications are almost universally + client-remote user interfaces. In the Public Switched Telephone + Network (PSTN), there is usually a circuit interface between the user + and the user interface. The user input from the keypad is conveyed + + + +Rosenberg Standards Track [Page 11] + +RFC 5629 App Interaction Framework October 2009 + + + using Dual-Tone Multi-Frequency (DTMF), and the microphone input as + Pulse Code Modulated (PCM) encoded voice. + + In an IP-based system, there is more variability in how the system + can be instantiated. Both client-remote and client-local user + interfaces to a telephone can be provided. + + In this framework, a PSTN gateway can be considered a User Device + Proxy. It is a proxy for the user because it can provide, to a user + interface on an IP network, input taken from a user on a circuit- + switched telephone. The gateway may be able to run a client-local + user interface, just as an IP telephone might. + +5.1. Client Remote + + The most obvious instantiation is the "classic" circuit-switched + telephony model. In that model, the user interface runs remotely + from the client. The interface between the user and the user + interface 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, and then convey that DTMF using a + suitable encoding algorithm (such as PCMU). An alternative, and + generally the preferred approach, is to transmit the keypad input + using RFC 4733 [19], which provides an encoding mechanism for + carrying keypad input within RTP. + + In this classic model, the user interface would run on a server in + the IP network. It would perform speech recognition and DTMF + recognition to derive the user intent, feed them through the user + interface, and provide the result to an application. + +5.2. Client Local + + An alternative model is for the entire user interface to reside on + the telephone. The user interface 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 user interface can be + described by a Keypad Markup Language request document [8]. As the + user enters digits in the keypad, they are passed to the user + interface, which generates user interface events that can be + transported to the application. + + + + +Rosenberg Standards Track [Page 12] + +RFC 5629 App Interaction Framework October 2009 + + +5.3. Flip-Flop + + A middle-ground approach is to flip back and forth between a client- + local and client-remote user interface. Many voice applications are + of the type that listen to the media stream and wait for some + specific trigger that kicks off a more complex user interaction. The + long pound in a prepaid calling card application is one example. + Another example is a conference recording application, where the user + can press a key at some point in the call to begin recording. When + the key is pressed, the user hears a whisper to inform them that + recording has started. + + The ideal way to support such an application is to install a client- + local user interface component that waits for the trigger to kick off + the real interaction. Once the trigger is received, the application + connects the user to a client-remote user interface that can play + announcements, collect more information, and so on. + + The benefit of flip-flopping between a client-local and client-remote + user interface is cost. The client-local user interface will + eliminate the need to send media streams into the network just to + wait for the user to press the pound key on the keypad. + + The Keypad Markup Language (KPML) was designed to support exactly + this kind of need [8]. It models the keypad on a phone and allows an + application to be informed when any sequence of keys has been + pressed. However, KPML has no presentation component. Since user + interfaces generally require a response to user input, the + presentation will need to be done using a client-remote user + interface that gets instantiated as a result of the trigger. + + It is tempting to use a hybrid model, where a prompt-and-collect + application is implemented by using a client-remote user interface + that plays the prompts, and a client-local user interface, described + by KPML, that collects digits. However, this only complicates the + application. Firstly, the keypad input will be sent to both the + media stream and the KPML user interface. This requires the + application to sort out which user inputs are duplicates, a process + that is very complicated. Secondly, the primary benefit of KPML is + to avoid having a media stream towards a user interface. However, + there is already a media stream for the prompting, so there is no + real savings. + +6. Framework Overview + + 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 (such as a proxy or user agent) that provides + + + +Rosenberg Standards Track [Page 13] + +RFC 5629 App Interaction Framework October 2009 + + + some value-added function to a user or system administrator. SIP + applications can execute on behalf of a caller, a called party, or a + multitude of users at once. + + Each application has a number of instances that are executing at any + given time. An instance represents a single execution path for an + application. It is established as a result of some event. That + event can be a SIP event, such as the reception of a SIP INVITE + request, or it can be a non-SIP event, such as a web form post or + even a timer. Application instances also have an end time. Some + instances have a lifetime that is coupled with a SIP transaction or + dialog. For example, a proxy application might begin when an INVITE + arrives, and terminate when the call is answered. Other applications + have a lifetime that spans multiple dialogs or transactions. For + example, a conferencing application instance may exist so long as + there are dialogs connected to it. When the last dialog terminates, + the application instance terminates. Other applications have a + lifetime that is completely decoupled from SIP events. + + It is fundamental to the framework described here that multiple + application instances may interact with a user during a single SIP + transaction or dialog. Each instance may be for the same + application, or different applications. Each of the applications may + be completely independent, in that each may be owned by a different + provider, and may not be aware of each other's existence. Similarly, + there may be application instances interacting with the caller, and + instances interacting with the callee, both within the same + transaction or dialog. + + The first step in the interaction 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 that + is defined by a logical flow that is not 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 within a + network element (for a client-remote user interface). If a client- + local user interface is to be used, the application needs to + determine whether or not the user agent is capable of supporting a + client-local user interface, 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 of presentation + of information to the user, a collection of information from the + user, and a transmission of that information to an application. + Examples of markup languages include HTML, Wireless Markup Language + (WML), VoiceXML, and the Keypad Markup Language (KPML) [8]. + + + +Rosenberg Standards Track [Page 14] + +RFC 5629 App Interaction Framework October 2009 + + + Unlike an application instance, which has a very flexible lifetime, a + user interface component has a very fixed lifetime. A user interface + component is always associated with a dialog. The user interface + component can be created at any point after the dialog (or early + dialog) is created. However, the user interface component terminates + when the dialog terminates. The user interface component can be + terminated earlier by the user agent, and possibly by the + application, but its lifetime never exceeds that of 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 that points to the markup for the user + interface, and the REFER contains a Target-Dialog header field [10] + which identifies the dialog associated with the user interface + component. For user interface components that are presentation free + (such as those 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 is to be sent to the application in a NOTIFY. The + SUBSCRIBE does not contain the Target-Dialog header field, since + equivalent information is conveyed in the Event header field. + + If a user interface component is to be instantiated in the network, + there is no need to determine the capabilities of the device on which + the user interface is instantiated. Presumably, it is on a device on + which the application knows a UI can be created. However, the + application does need to connect the user device to the user + interface. This will require manipulation of media streams in order + to establish that connection. + + The interface between the user interface component and the + application depends on the type of user interface. For presentation- + capable user interfaces, such as those described by HTML and + VoiceXML, HTTP form POST operations are used. For presentation-free + user interfaces, a SIP NOTIFY is used. The differing needs and + capabilities of these two user interfaces, as described in + Section 4.4, are what drives the different choices for the + interactions. Since presentation-capable user interfaces require an + update to the presentation every time user data is entered, they are + a good match for HTTP. Since presentation-free user interfaces + merely transmit user input to the application, a NOTIFY is more + appropriate. + + Indeed, for presentation-free user interfaces, there are two + different modalities of operation. The first is called "one shot". + In the one-shot role, the markup waits for a user to enter some + + + +Rosenberg Standards Track [Page 15] + +RFC 5629 App Interaction Framework October 2009 + + + information and, when they do, reports this event to the application. + The application then does something, and the markup is no longer + used. In the other modality, called "monitor", the markup stays + permanently resident, and reports information back to an application + until termination of the associated dialog. + +7. Deployment Topologies + + This section presents some of the network topologies in which this + framework can be instantiated. + +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 Topology + + In this topology, the application that is interested in interacting + with the users exists outside of the SIP dialog between the user + agents. In that case, the application learns about the initiation + and termination of the dialog, along with the dialog identifiers, + through some out-of-band means. One such possibility 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 in order to obtain this information. + + At any point during the dialog, the application can instantiate user + interface components on the user device of the caller or callee. It + can do this using either SUBSCRIBE or REFER, depending on the type of + user interface (presentation capable or presentation free). + + + + + + + + + +Rosenberg Standards Track [Page 16] + +RFC 5629 App Interaction Framework October 2009 + + +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 Topology + + In this deployment topology, the application is co-resident with one + of the user agents (the one on the right in the picture above). This + 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 + situation typically arises when the application wishes to install UI + components on a presentation-capable user interface. If the only + user input is via keypad input, the framework is not needed per se, + because the UA/application will receive the input via RFC 4733 in the + RTP stream. + + If the application resides in the called party, it is called a + "terminating application". If it resides in the calling party, it is + called an "originating application". + + This kind of topology is common in protocol converter and gateway + applications. + + + + + + + + + + + + + + + + + + + + + +Rosenberg Standards Track [Page 17] + +RFC 5629 App Interaction Framework October 2009 + + +7.3. Third-Party Application and 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 + Proxy + + Figure 4: User Device Proxy Topology + + In this deployment topology, there is a third-party application as in + Section 7.1. However, instead of installing a user interface + component on the end user device, the component is installed in an + intermediate device, known as a User Device Proxy. From the + perspective of the actual user device (on the left), the User Device + Proxy is a client remote user interface. As such, media, typically + transported using RTP (including RFC 4733 for carrying user input), + is sent from the user device to the client remote user interface on + the User Device Proxy. As far as the application is concerned, it is + installing what it thinks is a client-local user interface on the + user device, but it happens to be on a user device proxy that looks + like the user device to the application. + + The user device proxy will need to terminate and re-originate both + signaling (SIP) and media traffic towards the actual peer in the + conversation. The User Device Proxy is a media relay in the + terminology of RFC 3550 [18]. The User Device Proxy will need to + monitor the media streams associated with each dialog, in order to + convert user input received in the media stream to events reported to + the user interface. This can pose a challenge in multi-media + systems, where it may be unclear on which media stream the user input + is being sent. As discussed in RFC 3264 [20], if a user agent has a + single media source and is supporting multiple streams, it is + supposed to send that source to all streams. In cases where there + are multiple sources, the mapping is a matter of local policy. In + + + + + +Rosenberg Standards Track [Page 18] + +RFC 5629 App Interaction Framework October 2009 + + + the absence of a way to explicitly identify or request which sources + map to which streams, the user device proxy will need 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). As such, user agents SHOULD + send their user input on the first stream, absent a policy to direct + it otherwise. + +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 Device + + Figure 5: Proxy Application Topology + + In this topology, the application is co-resident with a transaction + stateful, record-routing proxy server on the call path between two + user devices. The application uses SUBSCRIBE or REFER to install + user interface components on one or both user devices. + + This topology is common in routing applications, such as a web- + assisted call-routing application. + +8. Application Behavior + + The behavior of an application within this framework depends on + whether it seeks to use a client-local or client-remote user + interface. + + + + + + + + + +Rosenberg Standards Track [Page 19] + +RFC 5629 App Interaction Framework October 2009 + + +8.1. Client-Local Interfaces + + One key component of this framework is support for client-local user + interfaces. + +8.1.1. Discovering Capabilities + + A client-local user interface can only be instantiated on a user + agent if the user agent supports that type of user interface + component. Support for client-local user interface components is + declared by both the UAC and UAS in their Allow, Accept, Supported, + and Allow-Event header fields of dialog-initiating requests and + responses. If the Allow header field indicates support for the SIP + SUBSCRIBE method, and 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 that the Contact header field contains a + GRUU), it means that the UA can instantiate presentation-free user + interface components. In this 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, + and 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, it + means that the UA supports presentation-capable user interface + components. In this 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 is not present on the call path will + not be privy to these header fields in the dialog-initiating requests + that pass by. As such, it will need to obtain this capability + information in other ways. One way is through the registration event + package [21], which can contain user agent capability information + provided in REGISTER requests [6]. + +8.1.2. Pushing an Initial Interface Component + + Generally, we anticipate that interface components will need to be + created at various different points in a SIP session. Clearly, they + will need to be pushed during session setup, or after the session is + established. A user interface component is always associated with a + specific dialog, however. + + + + +Rosenberg Standards Track [Page 20] + +RFC 5629 App Interaction Framework October 2009 + + + 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. In the case of + a UAC, this means that an application MUST NOT push a user interface + component for an INVITE-initiated dialog until the application has + seen a request confirming the receipt of a dialog-creating response. + This 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 the application 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. + + Furthermore, it is essential for the REFER request to be correlated + with the dialog to which the user interface component will be + associated. This is necessary 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 wishes 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 include a + From header field that looks like: + + + + + +Rosenberg Standards Track [Page 21] + +RFC 5629 App Interaction Framework October 2009 + + + From: "Prepaid Calling Card" <sip:prepaid@example.com> + + Any of the SIP identity assertion mechanisms that have been defined, + such as [11] and [13], are applicable to these requests as well. + +8.1.3. Updating an Interface Component + + Once a user interface component has been created on a client, it can + be updated. The means for updating it depends on the type of UI + component. + + Presentation-capable UI components are updated using techniques + already in place for those markups. In particular, user input will + cause an HTTP POST operation to push the user input to the + application. The result of the POST operation is a new markup that + the UI is supposed to use. This allows the UI to be updated in + response to user action. Some markups, such as HTML, provide the + ability to force a refresh after a certain period of time, so that + the UI can be updated without user input. Those mechanisms can be + used here as well. However, there is 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 would create a new UI + component rather than update any components already in place. + + For presentation-free UI, the story is different. The application + MAY update the filter at any time by generating a SUBSCRIBE refresh + with the new filter. The UA will immediately begin using this new + filter. + +8.1.4. Terminating an Interface Component + + User interface components have a well-defined lifetime. They are + created when the component is first pushed to the client. User + interface components are always associated with the SIP dialog on + which they were pushed. As such, their lifetime is bound by the + lifetime of the dialog. When the dialog ends, so does the interface + component. + + However, there are some cases where the application would like to + terminate the user interface component before its natural termination + point. For presentation-capable user interfaces, this is not + possible. For presentation-free user interfaces, the application MAY + terminate the component by sending a SUBSCRIBE with Expires equal to + zero. This terminates the subscription, which removes the UI + component. + + A client can remove a UI component at any time. For presentation- + capable UI, this is analogous to the user dismissing the web form + + + +Rosenberg Standards Track [Page 22] + +RFC 5629 App Interaction Framework October 2009 + + + window. There is no mechanism provided for reporting this kind of + event to the application. The application MUST be prepared to time + out and never receive input from a user. The duration of this + timeout is application dependent. For presentation-free user + interfaces, the UA can explicitly terminate the subscription. This + will result in the generation of a NOTIFY with a Subscription-State + header field equal to "terminated". + +8.2. Client-Remote Interfaces + + As an alternative to, or in conjunction with client-local user + interfaces, an application can make use of client-remote user + interfaces. These user interfaces can execute 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 that the user interface runs on a + host that has a sufficient trust relationship with the application. + As such, the means for instantiating the user interface is not + considered here. + + The primary issue is to connect the user device to the remote user + interface. Doing so requires the manipulation of media streams + between the client and the user interface. Such manipulation can + only be done by user agents. There are two types of user agent + applications within this framework: originating/terminating + applications, and intermediary applications. + +8.2.1. Originating and Terminating Applications + + Originating and terminating applications are applications that are + themselves the originator or the final recipient of a SIP invitation. + They are "pure" user agent applications, not back-to-back user + agents. The classic example of such an application is an interactive + voice response (IVR) application, which is typically a terminating + application. It is a terminating application because the user + explicitly calls it; i.e., it is the actual called party. An example + of an originating application is a wakeup call application, which + calls a user at a specified time in order to wake them up. + + Because originating and terminating applications are a natural + termination point of the dialog, manipulation of the media session by + the application is trivial. Traditional SIP techniques for adding + and removing media streams, modifying codecs, and changing the + address of the recipient of the media streams can be applied. + + + + + + + +Rosenberg Standards Track [Page 23] + +RFC 5629 App Interaction Framework October 2009 + + +8.2.2. Intermediary Applications + + Intermediary applications are, at the same time, more common than + originating/terminating applications and more complex. Intermediary + applications are applications that are neither the actual caller nor + the called party. Rather, they represent a "third party" that wishes + to interact with the user. The classic example is the ubiquitous + prepaid calling card application. + + In order for the intermediary application to add a client-remote user + interface, it needs to manipulate the media streams of the user agent + to terminate on that user interface. This also introduces a + fundamental feature interaction issue. Since the intermediary + application is not 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 is + discussed in more detail in Section 10. + +9. User Agent Behavior + +9.1. Advertising Capabilities + + In order to participate in applications that make use of 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 + + + +Rosenberg Standards Track [Page 24] + +RFC 5629 App Interaction Framework October 2009 + + + 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 are examined by proxies that may be executing + applications, a UA that wishes to support client-local user + interfaces should not encrypt them. + +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 prior to the + establishment of a dialog, 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; therefore, the + user agent is unlikely to ever have a shared secret with it, making + digest authentication useless. However, authenticated identities can + be obtained through other means, such as 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 a set of + policies is present, it is checked first. If the application is + authorized, processing proceeds. + + If the application has authenticated itself but is not 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. That occurs 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. + + + +Rosenberg Standards Track [Page 25] + +RFC 5629 App Interaction Framework October 2009 + + + Furthermore, to ensure that 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 will guarantee secure links between all the elements + on the signaling path. + + If the dialog was not established with a SIPS URI, or the user agent + did not 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 is 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 is not 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 does not present a valid dialog identifier in its + REFER or SUBSCRIBE request, the user agent MUST reject the request + with a 403 response. + + 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. In the case of + presentation-capable user interfaces, this process is known as focus + selection. It is done by means that are specific to the user + interface on the device. In the case of a PC, for example, the + window manager would allow the user to select the appropriate user + interface component to which their input is directed. + + For presentation-free user interfaces, the situation is more + complicated. In some cases, the device may support a mechanism that + allows the user to select a "line", and thus the associated dialog. + Any user input on the keypad while this line is selected are fed to + the user interface components associated with that dialog. + + + + +Rosenberg Standards Track [Page 26] + +RFC 5629 App Interaction Framework October 2009 + + + 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 this to + the client-remote user interface. This 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 + + For presentation-capable user interfaces, updates to the user + interface occur in ways specific to that user interface component. + In the case of HTML, for example, the document can tell the client to + fetch a new document periodically. However, this framework does not + provide any additional machinery to asynchronously push a new user + interface component to the client. + + 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 + + Termination of a presentation-capable user interface component is a + trivial procedure. The user agent merely dismisses the window (or + its equivalent). The fact that the component is dismissed is not + communicated to the application. As such, it is purely a local + matter. + + In the case of a presentation-free user interface, the user might + wish to cease interacting with the application. However, most + presentation-free user interfaces will not 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. The system has to determine to which + user interface any particular input is destined. That question is + the essence of the inter-application feature interaction problem. + + + + +Rosenberg Standards Track [Page 27] + +RFC 5629 App Interaction Framework October 2009 + + + Inter-application feature interaction is not an easy problem to + resolve. For now, we consider separately the issues for client-local + and client-remote user interface components. + +10.1. Client-Local UI + + When the user interface itself resides locally on the client device, + the feature interaction problem is actually much simpler. The end + device knows explicitly about each application, and therefore can + present the user with each one separately. When the user provides + input, the client device can determine to which user interface the + input is destined. The user interface to which input is destined is + referred to as the "application in focus", and the means by which the + focused application is 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 does not know about focus; it merely + receives the user input that has been targeted to 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. Consider a user that makes a call from a PC. The + call passes through a prepaid calling card application and a call- + recording application. Both of these wish to interact with the user. + Both push an HTML-based user interface to the user. On the PC, each + user interface would appear as a separate 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. It is + clear to which application the user input is targeted. + + As another example, consider the same two applications, but on a + "smart phone" that has a set of buttons, and next to each button, + there is an LCD display that can provide the user with 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 determine which application to + interact with by pressing the appropriate button. Pressing a button + determines focus and provides user input, both at the same time. + + Unfortunately, not all devices will 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 + + + +Rosenberg Standards Track [Page 28] + +RFC 5629 App Interaction Framework October 2009 + + + Markup Language (KPML). Considering once again 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, to which + document does the input apply? The device does not allow the user to + select. 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 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, allowing the user to determine + which application they are interacting with. + + Indeed, when a user provides input on a focusless device, 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. In the case of KPML, key events are passed to remote user + interfaces by encoding them as described in RFC 4733 [19]. Of + course, since a client cannot determine whether or not a media stream + terminates in a remote user interface, these key events are 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, the determination of focus can + be much, much harder. There are many architectures that can be + deployed to handle the interaction. None are ideal. However, all + are beyond the scope of this specification. + +11. Intra Application Feature Interaction + + An application can instantiate a 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 less severe. If an application has multiple + client user interface components, their interaction is resolved + identically to the inter-application case -- through focus + + + +Rosenberg Standards Track [Page 29] + +RFC 5629 App Interaction Framework October 2009 + + + determination. However, the problems in focusless user devices (such + as a keypad on a telephone) generally won't exist, since the + application can generate user interfaces that do not overlap in their + usage of an input. + + The real issue is that the optimal user experience frequently + requires some kind of coupling between the differing user interface + components. This is a classic problem in multi-modal user + interfaces, such as those described by Speech Application Language + Tags (SALT). As an example, consider a user interface where a 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 cease immediately, since both + of them were targeted at collecting the same information in parallel. + Such interactions are best handled by markups that natively support + such interactions, such as SALT, and thus require no explicit support + from this framework. + +12. Example Call Flow + + This section shows the operation of a call-recording application. + This application allows a user to record the media in their call by + clicking on a button in a web form. The application uses a + presentation-capable user interface component that is pushed to the + caller. The conventions of [17] are used to describe representation + of long message lines. + + + + + + + + + + + + + + + + + + + + + + + + + +Rosenberg Standards Track [Page 30] + +RFC 5629 App Interaction Framework October 2009 + + + 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, the caller, A, sends an INVITE to set up a call (message 1). + Since the caller supports the framework and can handle presentation- + capable user interface components, it includes the Supported header + field indicating that the GRUU extension and the Target-Dialog header + field are understood, the Allow header field indicating that REFER is + understood, and the Contact header field that includes the "schemes" + header field parameter. + + + + + + + + +Rosenberg Standards Track [Page 31] + +RFC 5629 App Interaction Framework October 2009 + + + 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 acts as a recording server, and forwards the INVITE to the + called party (message 2). It strips the Record-Route it would + normally insert due to the presence of the GRUU in the INVITE: + + 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 accepts the call with a 200 OK (message 3). It does not support + the framework, so the various header fields are not present. + + + + + + +Rosenberg Standards Track [Page 32] + +RFC 5629 App Interaction Framework October 2009 + + + 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-- + + This 200 OK is 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 generates 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 ACK + + The ACK is 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 ACK + + + + +Rosenberg Standards Track [Page 33] + +RFC 5629 App Interaction Framework October 2009 + + + Now, the application decides to push a user interface component to + user A. So, it sends it a REFER request (message 7): + + <allOneLine> + REFER sip:A@example.com;gr=urn:uuid:f81d4fae + -7dec-11d0-a765-00a0c91e6bf6 SIP/2.0 + </allOneLine> + 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 + <allOneLine> + To: Caller <sip:A@example.com;gr=urn:uuid:f81d4fae + -7dec-11d0-a765-00a0c91e6bf6> + </allOneLine> + 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 is answered by 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 REFER + + + + + + + + + +Rosenberg Standards Track [Page 34] + +RFC 5629 App Interaction Framework October 2009 + + + User 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 Trying + + And the recording server responds 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 NOTIFY + + The REFER request contained a Target-Dialog header field parameter + with a valid dialog identifier. Furthermore, all of the signaling + was over TLS and the dialog identifiers contain sufficient + randomness. As such, the caller, A, automatically authorizes the + application. It then acts on the Refer-To URI, fetching the script + from app.example.com (message 11). The response, message 12, + contains a web application that the user can click on to enable + recording. Because the client executed the URL in the Refer-To, it + generates another NOTIFY to the application, informing it of the + successful response (message 13). This is answered with a 200 OK + (message 14). When the user clicks on the link (message 15), the + results are posted to the server, and an updated display is provided + (message 16). + + + + + + + + + +Rosenberg Standards Track [Page 35] + +RFC 5629 App Interaction Framework October 2009 + + +13. Security Considerations + + There are many security considerations associated with this + framework. It allows applications in the network to instantiate user + interface components on a client device. Such instantiations need to + be from authenticated applications, and also need to be authorized to + place a UI into the client. Indeed, the stronger requirement is + authorization. It is not as important to know the name of the + provider of the application, as it is 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 by the + use of cryptographically random dialog identifiers and the usage of + 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 was produced as a result of discussions amongst the + application interaction design team. All members of this team + contributed significantly to the ideas embodied in this document. + 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 to Allison Mankin for her support of this + work. + +16. References + +16.1. Normative References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., + Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: + Session Initiation Protocol", RFC 3261, June 2002. + + + + +Rosenberg Standards Track [Page 36] + +RFC 5629 App Interaction Framework October 2009 + + + [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 + + [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. + + + + + +Rosenberg Standards Track [Page 37] + +RFC 5629 App Interaction Framework October 2009 + + + [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 + + 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 + + + + + + + + + + + + + + +Rosenberg Standards Track [Page 38] + |