A Framework for Application Interaction in the Session Initiation Protocol (SIP)
Extracted elements (28)
For presentation-capable UIs, HTTP POST is used as the interface between the UI and application because such UIs require an updated presentation every time user data is entered, which matches HTTP's request/response model. For presentation-free UIs, SIP NOTIFY is used instead because they merely transmit user input without needing a presentation update.
KPML is designed for the 'flip-flop' scenario where a client-local UI waits for a trigger (e.g., long pound key), then hands off to a client-remote UI for more complex interaction. Using KPML locally eliminates the need to send media streams into the network just to wait for a keypress.
The framework focuses on stimulus signaling rather than functional signaling because stimulus interfaces allow new applications to be built without requiring modifications to user devices or new standards, at the cost of being slower and less user-friendly than functional counterparts. The web is cited as the canonical example of a stimulus interface.
The separation between user interface and application is described as 'absolutely fundamental to the entire framework'. The user interface handles rendering and interpretation of raw user input, while the application only needs the semantic result, not the modality details (e.g., whether a prompt was male or female voice).
A hybrid UI approach combining a client-remote UI for prompts with a KPML client-local UI for digit collection is explicitly discouraged: it complicates the application by requiring deduplication of keypad input (sent to both media stream and KPML), and eliminates the primary bandwidth-saving benefit of KPML since a media stream is already present.
A third-party application not on the call path will not see capability header fields in dialog-initiating requests. It must obtain UA capability information via other means, such as the registration event package which can contain user agent capability information from REGISTER requests.
A UA that wishes to support client-local user interfaces should not encrypt the capability-advertising SIP header fields (Allow, Allow-Events, Supported, Contact schemes), because these headers are examined by proxies that may be executing applications.
A user agent compliant to this framework SHOULD use dialog identifiers that are cryptographically random, with at least 128 bits of randomness, split between the Call-ID and From header field tags in the case of a UAC.
A user agent compliant to this specification SHOULD use the SIPS URI scheme for all dialogs it initiates, to guarantee that only applications resident in or trusted by on-path elements can instantiate a user interface component.
An application MUST NOT attempt to push a user interface component to a user agent until it has determined that the user agent has the necessary capabilities and a dialog has been created. For INVITE-initiated dialogs on the UAC side, pushing must wait until an ACK or PRACK confirming a dialog-creating response has been seen.
For either presentation-free or presentation-capable user interfaces, the user agent MUST support the GRUU specification. The Contact header field in all dialog-initiating requests and responses MUST contain a GRUU, and the Supported header field MUST contain both the 'gruu' and 'tdialog' option tags.
If a user agent supports presentation-capable user interfaces, it MUST support the REFER method, MUST support the target dialog specification (tdialog), MUST support SIP user agent capabilities, MUST be capable of being REFERed to an HTTP URI, and MUST include a 'schemes' Contact header field parameter including the HTTP URI scheme.
If a user agent supports presentation-free user interfaces, it MUST support the SUBSCRIBE method and the KPML event package, MUST include SUBSCRIBE in the Allow header field, MUST include KPML in the Allow-Events header field, and MUST support the 'application/kpml-request+xml' MIME type.
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 the dialog was not established with SIPS or did not use cryptographically random dialog identifiers, the application MUST NOT be automatically authorized even with valid dialog identifiers.
It is RECOMMENDED that all user agents that support presentation-capable user interfaces support HTML as a markup language.
Once the UA has created a dialog, it MUST be prepared to receive a SUBSCRIBE or REFER request against its GRUU. If such a request arrives prior to the establishment of a dialog, the UA MUST reject it.
The application MUST be prepared to time out and never receive input from a user, since there is no mechanism for a presentation-capable UI to report to the application that the user dismissed the UI component. The duration of this timeout is application-dependent.
The Refer-To header field of the REFER request MUST contain an HTTP URI that references the markup document to be fetched. The SUBSCRIBE for presentation-free UI MUST be sent to the GRUU and MUST use the KPML event package.
This specification RECOMMENDS that the User Device Proxy monitor the first stream (defined by ordering of media sessions within a session description) for user input. As such, user agents SHOULD send their user input on the first stream, absent a policy directing otherwise.
To create a presentation-capable UI component, the REFER request MUST be sent to the GRUU advertised by the UA in the Contact header field, and MUST contain a Target-Dialog header field identifying the associated dialog along with a Require header field with the 'tdialog' option tag.
A Markup Language in this framework 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. Examples include HTML, WML, VoiceXML, and KPML.
A User Device Proxy is a software or hardware system through which a user indirectly interacts with an application. It terminates and re-originates both SIP signaling and media traffic, and monitors media streams to convert user input received in the media stream to events reported to the user interface.
A User Interface Component is a piece of user interface that operates independently of other pieces. It is always associated with a specific SIP dialog and its lifetime is bounded by that dialog's lifetime. Components can be presentation-capable (supports prompt-and-collect) or presentation-free (collects input only).
Capability advertisement for client-local UI is performed via SIP header fields in dialog-initiating requests and responses: Allow (listing REFER or SUBSCRIBE), Allow-Events (for KPML), Supported (for 'gruu' and 'tdialog'), Contact (containing a GRUU with 'schemes' parameter), and Accept (listing supported markup MIME types).
A user agent MAY apply additional authorization policies, including prompting the user with the application identity and associated dialog. If user authorization is required, the UA SHOULD respond with 202, and if authorization is denied for a SUBSCRIBE, generate a terminating NOTIFY; for REFER, MUST NOT act on the Refer-To URI until authorized.
Applications that push UI components to client devices must be authenticated and authorized. Authorization is automatically granted if the application can prove it is on the call path or trusted by a path element, demonstrated by knowledge of the dialog identifiers (via Target-Dialog or KPML Event header field parameters). This requires cryptographically random dialog identifiers (at least 128 bits) and SIPS for message confidentiality.
SIPS is RECOMMENDED for user agents compliant to this specification to ensure that only on-path or on-path-trusted applications can obtain dialog identifiers needed to instantiate user interface components. Without SIPS or cryptographically random dialog IDs, automatic authorization MUST NOT be granted even if valid dialog identifiers are presented.
A user interface component has two lifecycle states: active (created when pushed to client, after dialog creation and application authorization) and terminated (when the associated dialog ends, or earlier via SUBSCRIBE with Expires=0 for presentation-free UI, or when the UA dismisses it). Termination of presentation-free UI by the UA sends NOTIFY with Subscription-State: terminated.