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.

There are requirements to allow network elements to request that a UA execute scripts. The requirements for this are described in [draft-culpepper-sipping-app-interact-reqs-02] and a framework for building applications using this mechanisms is explained in [draft-rosenberg-app-interaction-00]. There is also a specific markup [draft-burger-sipping-dml-00] that would use this mechanism to build applications. This document also defines a way for network elements to find out what mechanisms the UA supports for fetching scripts.

The main mechanism of this draft is a new header field, called App-Info, that tells the UA 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 reliable provisional responses. The draft also defines several option tags for use in the supported header field to allow an UA to indicate which URL schemes is supports for fetching scripts. The Accept header field is used to indicate the types of markup that the UA can process. An example App-Info header field is:

; id=app4323!sub3+svr56.provider.net; ]]> This indicates that the UA should load 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 consist of an application instance and an application class separated by a "!". In the example above, the instance is "app4323" and the class is "sub3+src56.provider.net". The combination of these two MUST make a globally unique identifier. There may be multiple applications classes simultaneous running on a UA with the same instance identifier. The instance identifier can be used to correlate the applications. The UA may use the display name for presentation purposes and helping manage 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. For example:

This indicates that the UA can accept VXML and HTML markup and it is capable fetching scripts from a local file or using HTTP.

When a UAC sends a message it MUST include the script fetching URLs it supports in the Supported header field and the markups or scripts that it can process in the Accept header field. When a UA receives a message that contains a 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 was previously started. In the case that 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. If the fetch fails for some reason, no error is reported by the UA. After fetching the script, execution starts in a context associated with the dialog. If the application identifier matches an existing script, the script is fetched and then used to replace the existing script. If the application identifier marches an existing script and the URL in the App-Info header field value is empty, then the existing script is terminated. The UA fetches the script by first checking if there is a cid parameter. If there is, then the script is fetched from the body of the SIP message that contained the App-Info header field. In this case, the body will contain a multipart MIME message. The MIME part with a Content-ID header that has an identifier that matches the value of the cid parameter is used as the script. If there is not cid parameter, then the UA fetches the script using the URI found in the uri portion of the App-Info header field value. An UA which supports the App-Info header field MUST support fetching scripts from multipart MIME bodies. When a dialog ends, all the applications associated with it SHOULD be immediately terminated. An 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 indicate it supports.

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 can be added to reliable provisional response. The proxy SHOULD not request services that the UA has not indicate it supports.

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

App-Info = "App-Info" HCOLON app-param *(COMMA app) app = [ display-name ] LAQUOT absolute-uri RAQUOT *(SEMI app-param) app-param = app-id-param / app-name-param / app-cid-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 app-cid-param = "cid" EQUAL app-msg-id app-msg-id = msg-id ; as defined in rfc2822 This document adds the following entry to Table 2 of REF

Header field where proxy ACK BYE CAN INV OPT REG ------------ ----- ----- --- --- --- --- --- --- App-Info adr - o - o o - SUB NOT REF INF UPD PRA --- --- --- --- --- --- o o o o o -

The document describes a mechanism that allows non trusted parties to request that a UA executes an arbitrary script. This mechanism should only be used to initiate scripts that are in scripting languages that are intended for the type of situation where a script is received from an party that is not trusted. 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 1-900 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. There is nothing stopping the scripting mechanism having a authorization mechanism such as signed scripts but this is not provided by the mechanisms in this document.

This document defines a new header field, "App-Info". As recommended by the policy of the Transport Area, 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 this document

This specification registers several option tags. The required information for this registration, as specified in RFC 3261, is:

Name: file Description: This option tag is for loading scripts into a UA. When present in a Supported header field, it indicates that the UA can load data using the file URL defined in RFC 1738. Name: http Description: This option tag is for loading scripts into a UA. When present in a Supported header field, it indicates that the UA can load data using a http URL. Name: https Description: This option tag is for loading scripts into a UA. When present in a Supported header field, it indicates that the UA can load data using a https URL. Registrant: Cullen Jennings fluffy@cisco.com

If there is an error loading a script, should any error be returned on the dialog? If a dialog A exists or is being created, it should be possible to create a sidebar dialog B that can create an application instant that is associated with the main dialog A. Need to think about security for this. When a dialog ends, should all the application associated with it be instantly terminated or should they be given a chance to notify some application server that they are ending. If this is done, it introduces the possibility of the telephone equivalent to those HTML windows that just keep coming back no matter how many times you kill them. Do we need a way to indicate that the UA can support: forking media, local mixing, media policy? The references in this draft are incomplete.

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 for previous work that has been reused here. That said, the errors, misinterpretation, and fouls in this document are my own.