SIP Support for Application Initiation

A "script" refers to some markup, program, or script that the UA can fetch and execute. 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 RFC-2119.

The Session Initiation Protocol (SIP) 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 pre-paid calling card calls, conferencing, and presence-based call routing. In order for most applications to properly function, they need input from the user to guide their operation. For example, a pre-paid 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 referred to as "application interaction". A set of high level requirements on a system for application interaction are described in . To meet these requirements, a framework has been developed. In this framework, applications can instantiate user interface classes on client devices, for the purposes of interacting with the user. Each class can represent different components of the the user interface in a single application. These user interface components are described using markup languages, such as VoiceXML and KPML. The framework also defines a set of requirements for SIP extensions that allow for an application to discover the capabilities of the user device for supporting markup languages, for placing user interface components on the device, and for terminating the component. This document proposes a specific SIP extension that fulfills those requirements. This extension is the App-Info header.

The main mechanism of this draft is a new header field, called App-Info, that provides the UA with the URL of a script to execute. A network element can add this header field. The App-Info header field can occur in most SIP messages, including INVITE and MESSSAGE messages, as well as in reliable provisional responses. This draft also defines an option tag for use in the supported header field to allow a UA to indicate support for this mechanism. Options tags are also used to indicate which types of markup are supported. The Caller Preferences mechanism is used to indicate the types of markup that the UA can process. An example App-Info header field is:

; id=app4323!sub4+svr56.provider.net ]]> This indicates that the UA should fetch and execute the script found at http://mediasvr.provider.net/calltimer.vxml. A key part of the header field value is an application id that consists of an application instance and an application class separated by a "!". In the example above, the instance is "app4323" and the class is "sub4+src56.provider.net". The combination of these two MUST make a globally unique identifier. There may be multiple user interface components running on a UA that are part of the same application instance, and therefore, share the same instance identifier. The instance identifier can be used to correlate the applications. An application might want to authorize the execution of the markup based only on the class name so that this authorization can be cached and used the next time a different instance of this same application is used. If authorization is cached or shared, note the warnings in the Security Consideration section. The UA may use the display name for presentation purposes and for help in managing focus, but it has no other meaning. The formal syntax for the App-info header field is presented in . This approach also uses the Supported and Accept header fields as well as the schemes mechanism from the caller prefs draft. For example:

This indicates that the UA can accept markup as defined in this draft. In particular the UA can accept VoiceXML and HTML markup and is capable fetching scripts from using a http, cid, or file scheme. The cid scheme fetches the content from an inline body in the same message.

When a UAC sends a message it MUST include in the Supported header the markup option tag. It MUST also put the markups or scripts that it can process in the Accept header field and indicate the schemes it can support in the Contact header. When a UA receives a message that contains an App-Info header field, it must process each header field value and decide what to do with it. There are three cases: creating a new application, updating an existing application, and stopping a script that has been previously started. In the case when the application identifier does not match any of the scripts that are currently running, a new application instance is created. The UA associates the application identifier with the dialog it was received on. The script is fetched. After fetching the script, execution starts in a context associated with the dialog. If the application identifier matches the identifier for a previously fetched script, and the App-Info header field URL value does not match the previous header field URL value for this script, then the script is fetched and then used to replace the existing script. If the application identifier matches an existing script and the URL in the App-Info header field value is empty, then the existing script is terminated. If the URL has not changed, this header field value is ignored. The UA fetches the script by using the URI found in the URI portion of the App-Info header field value. A UA which supports the App-Info header field MUST support fetching scripts from multipart MIME bodies using the cid scheme and SHOULD support the http scheme. When a dialog ends, all the applications associated with it SHOULD be immediately terminated. A UA may add the App-Info header field to initiate an application on the other UA in the dialog. The UA SHOULD NOT request services that the other UA has not indicated it supports. The App-Info header follows the general http scripting model for reporting errors - that is to say that the UA fetching the markup and executing it does not report errors to the application server. Part of the problem is that there is no easy way to report errors when fetching some markup fails, or when the markup can not be interpreted, or when the markup is terminated. There is no guarantee that the system will get any stimulus from the markup even if there are no errors. This means the application must be written in a way that detects when the application is not getting input and deals with this situation appropriately. For many web applications this has turned out to be fairly easy to do.

Proxies MAY add header field values to the App-Info header field but they SHOULD NOT delete or modify any existing header field values that they did not originally add. App-Info header fields MAY be added to reliable provisional response. The proxy SHOULD NOT request services that the UA has not indicated it supports.

The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC-2234.

App-Info = "App-Info" HCOLON app *(COMMA app) app = [ display-name ] LAQUOT [absolute-uri] RAQUOT *(SEMI app-param) app-param = app-id-param / app-name-param / generic-param app-id-param = "id" EQUAL app-id-value app-id-value = app-instance-id "!" app-class-id app-instance-id = app-token app-class-id = app-token app-token = 1*(alphanum / "-" / "." / "%" / "*" / "_" / "+" / "'" / "`" / "~" ) ; this is a token with no "!" app-name-param = "app-name" EQUAL gen-value This document adds the following entry to Table 2 of RFC-3261. Note that App-Info is only valid in something that is in a dialog or forms a dialog.

Header field where proxy ACK BYE CAN INV OPT REG ------------ ----- ----- --- --- --- --- --- --- App-Info adr - - - o o - SUB NOT REF INF UPD PRA --- --- --- --- --- --- o o o o o - In addition it would be listed as an optional header for the MESSAGE message so this document adds the following line to Table 1 in RFC-3428.

Header Field where proxy MESSAGE __________________________________________ App-Info o

This document describes a mechanism that allows non trusted parties to request that a UA execute an arbitrary script. This mechanism should only be used to initiate scripts that are in scripting languages intended for situations in which scripts from non trusted parties are expected. HTML is a good example of a markup language that is considered safe to render content that is not trusted. A scripting language that allowed scripts that automatically caused the UA to hang up and then dial a toll service phone number would certainly not be appropriate for this mechanism. The scripting language should not be able to access information on the UA that is not associated with the dialog, such as the user's address book. The mechanism in this document does not address the secure transport, authorization, and integrity of the markup, but there are multiple mechanisms to ensure that the markup came from the correct party and that the markup has not been tampered with. If the script is fetched using https, both the identity of the party providing the markup and the integrity of the markup can be secured. Alternatively, if the script is transferred using the cid scheme, S/MIME can be used to sign the markup. Proxies are allowed to insert App-Info headers so the App-Info headers can not be secured using an end to end mechanism. Using the sips URL in the SIP messages does provide some assurances that, as long as the user trusts all the proxies that the call traversed, the user can be sure that no rogue markup has been requested. When some markup has been requested, the UA should require authorization to run it. It is possible to authenticate the party that sent the markup using https or S/MIME signing of cid markup. Authorization SHOULD be obtained for each different class of markup but the UA MAY reuse the authorization for two different instances of the same application class. When authorization is cached or used for different instances of the same class, the system MUST ensure that all the markup sharing the authorization came from the same entity. For example, if the system authorizes a class named doSomething that was received from a source which could authenticate (using something line https or smime) as good.example.com, the system should not trust a class called doSomething received from evil.example.com.

{NOTE to IANA: Please replace XXXX with the rfc number of this specification}

This document defines a new header field, "App-Info". As recommended by RFC-3261 these headers fields should be registered by the IANA in the SIP header registry, using the RFC number of this document as its reference.

Name of Header: App-Info Short form: none Registrant: Cullen Jennings fluffy@cisco.com Normative description: Section 6.1 of RFC XXXX.

This specification registers a new option tag called markup. The required information for this registration, as specified in RFC-3261, is:

Name: markup Description: This option tag is for fetching scripts into a UA. When present in a Supported header field, it indicates that the UA can supports the mechanism in RFC XXXX. Registrant: Cullen Jennings fluffy@cisco.com

Eric Burger, Robert Fairlie-Cuninghame, Jonathan Rosenberg, and I were the members of the Application Stimulus Signaling Design Team. All members of the team contributed significantly to this work. In addition, thanks to Bert Culpepper.