Alert-Info header URNs for Session Initiation Protocol (SIP)

The Session Initiation Protocol (SIP) allows for user agent servers (UAS) and proxies to provide the specific ringback or ring tone to the user agent (UA). In RFC 3261 this is done by including a URI reference in the Alert-Info header field, that points to the tone. The URI reference is most commonly the HTTP URI to the audio file. On the receipt of the Alert-Info header the user agent may fetch the referenced ringback or ring tone and play it to the user. Current solution is sufficient for human users that share the same understanding of the tones. However if caller and callee are from the different countries the understanding of the tones may vary significantly. Hearing impaired users may not sense the specific tone if it is provided as an audio file. The tone per se is also not useful for automata. Another limitation of the current solution is that the referenced tones are tied to particular rendering. It is not possible to provide a semantic indication that signals the intent and allows the recipient to decide how to render the received information in an appropriate way. To solve the described issues and support new applications this specification defines the new URN namespace 'alert' for the Alert-Info header that can be understood by an automaton, would allow for programmatic handling, including user interface adaptation, or conversion to equivalent protocol parameters in the Public Switched Telephone Network (PSTN) when the client is a gateway. Using 'alert' namespace provides syntax for several different application spaces: Names for services like "call is a waiting call", not tied to any particular rendering. Names for standard tones, such as those used by the PSTN. For instance there could be names for all the various country-specific ring and ringback tones Names for things with specific renderings that aren't purely audio. They might be static icons, video sequences, text, etc. Some advantages of a URN rather than a net reference to a downloadable resource: no need to download it you don't have to worry if you support the format downloaded there is no "danger" that you might end up rendering something unexpected and undesirable you can render as high (or low) quality as your device can use The downside is that if the recipient does not understand the URN then it won't be able to render anything. To provide the general awareness about the Alert-Info URNs this document provides IANA template for registering the URNs and defines several typical identifiers.

A server MAY add a URN or multiple URNs to the Alert-Info header in an appropriate SIP message when it needs to provide additional information about the status of the user. A server SHOULD NOT add a mixture of the 'alert' URNs and URIs to the Alert-Info header that may cause disturbing rendering interference at the recepient's UA. Following example shows both the network audio resource referenced by the HTTP URI and the URN indication for the call-waiting service transported by the Alert-Info header in a 183 Session Progress provisional response.

, ]]>

Upon receiving a SIP message with an Alert-Info header that contains a single or multiple 'alert' URNs, the User Agent (UA) attempts to match the received URNs with the known indications. If no match is found, the UA ignores the received 'alert' URNs and proceed with normal operation. If the one or multiple URNs matches a known indication the UAC renders the indication(s) to the user according to the type of indication. The UA is responsible for the non disturbing rendering if multiple indications and network resources are to be rendered simultaneously.

This section describes the use cases that are supported by the 'alert' URNs.

The call waiting Service permits a callee to be notified of an incoming call whilst the media resources are not available for the incoming call and the callee is engaged in an active or held call. Subsequently, the callee can either accept, reject, or ignore the incoming call. There is an interest on the caller side to be informed about the call waiting situation on the callee side. Having this information the caller can decide whether to continue waiting for callee to pickup, or better to call some time later when it is estimated, that the callee could finished the ongoing conversation. To provide this information callee's UAS or proxy aware of the call waiting condition can add the call-waiting indication URN to the Alert-Info header. As call-waiting information may be subject to the callee's privacy concerns, the exposure of this information SHALL be done only if explicitly required by the user

Below is the registration template for the 'alert' URN scheme according to the RFC 3406 Namespace ID: alert Registration Information: Registration version: 1 Registration date: 2008-08-14 Declared registrant of the namespace: Registering organization: IETF Designated contact: Denis Alexeitsev Designated contact email: d.alexeitsev@telekom.de Declaration of syntactic structure: The URN consists of a hierarchical alert indication identifier, with a sequence of labels separated by periods. The left-most label is the most significant one and is called 'top-level alert indication', while names to the right are called 'alert indication'. The set of allowable characters is the same as that for domain names . Labels are case-insensitive, but MUST be specified in all lower-case. Some 'alert' URNs, indication- identifiers can be removed right-to-left; the resulting URN is still valid, referring to a more generic indication. In other words, if an indication 'x.y.z' exists, the URNs 'x' and 'x.y' are also valid 'alert' URNs. Each alert indication identifier SHALL explicitly define it's validity respective the sub-indications. The ABNF is shown below.

Relevant ancillary documentation: None Community considerations: The alert URN is believed to be relevant to a large cross-section of Internet users, including both technical and non-technical users, on a variety of devices and with a variety of perception capabilities. The 'alert' URN will allow Internet users to better understand the status of the callee in the foreign country, or better understand if the callee is able to answer the call. For example, specific ringback tone from the foreign country can be rendered by the user interface in the familiar way to the user. Call is a waiting call indication meaning that the callee is occupied with the different session can be provided to the caller that would help to better assert the answer probability. User interfaces for the perception impaired users can better render the ringback indication based on the 'alert' URN. The assignment of identifiers is described in the IANA Considerations (). The 'alert' URN does not prescribe a particular resolution mechanism, but it is assumed that a number of different entities could operate and offer such mechanisms. Namespace considerations: There do not appear to be other URN namespaces that serve the same need of uniquely identifying 'alert' communication and information services. Identifier uniqueness considerations: An 'alert' URN identifies a logical service or tone, specified in the 'alert' indication registration (see IANA Considerations ()). Resolution of the registered URN, will return a particular instance of the alert indication. Alert indication URNs MUST be unique for each unique indication; this is guaranteed through the registration of each alert indication within this namespace, described in (). Identifier persistence considerations: The 'alert' URN for the same indication is expected to be persistent, as long as it is registered with IANA. Process of identifier assignment: The process of identifier assignment is described in the IANA Considerations (). Process for identifier resolution: 'alert' URNs are statically resolved according to the IANA registry. Rules for lexical equivalence: 'alert' URNs are compared according to case-insensitive string equality. Conformance with URN syntax: The BNF in the 'Declaration of syntactic structure' above constrains the syntax for this URN scheme. Validation mechanism: Validation determines whether a given string is currently a validly-assigned URN . Static validation is performed based on the currently registered 'alert' URNs at IANA. Scope: The scope for this URN is public and global.

This section registers a new URN scheme with the registration template provided in section Registration Template. Below, the section 7.1 details how to register new alert indication identifying labels. Descriptions of sub-indications for the first two indications to be registered, service and tone, are given in Section 7.2 and Section 7.3, respectively. Finally, Section 7.4 contains the initial registration table.

Indications and sub-indications are identified by labels managed by IANA, according to the processes outlined in in a new registry called "Alert URN Labels". Thus, creating a new indication requires IANA action. The policy for adding top-level indication labels is 'Standards Action'. (This document defines the top-level indication labels 'service' and 'tone'.) The policy for assigning labels to sub-indications may differ for each top-level indication designation and MUST be defined by the document describing the top-level indication. Entries in the registration table have the following format:

Each top-level or sub-indication label MUST NOT exceed 27 characters.

This section defines the indication registration within the IANA registry defined in Section 7.1, using the top-level indication labels 'service' and 'tone'. The 'service' indication label provides information about additional services performed on the callee side. Sub-indications of the 'service' indication are not tied to any particular rendering and signal the service invocation, that allows the recipient to decide on the best way to render this indication. Validity of the 'service' top-level indication: this indication is not valid without respective sub-indications. The 'tone' indication label describes tones that should be rendered to the caller. The normal rendering is audio, however there can be other renderings applicable if needed by the user interface specifics. Validity of the 'tone' top-level indication: this indication is not valid without respective sub-indications.

This section defines the indication registration within the IANA registry defined in Section 7.1, using the sub-indication label 'service:call-waiting'. urn:alert:service:call-waiting indication provides information to the caller about the call-waiting situation on the callee side. Call-waiting situation for the callee means that very limited resources are available for an incoming communication. The callee normally has the choice of accepting, rejecting or ignoring the waiting call. Validity of the 'service:call-waiting' sub-indication: this indication is valid without respective sub-indications

This section defines the indication registration within the IANA registry defined in Section 7.1, using the sub-indication label 'tone.xyz'. Input on the 'tone' sub-indication is requested. urn:alert:tone:xyz

The following table contains the initial IANA registration for service and tone indications.

The indication labels are protocol elements and are not normally seen by users. Thus, the character set for these elements is restricted, as described in Section 6.

As an identifier, the alert indication URN does not appear to raise any particular security issues. The indications described by the 'alert' URN are meant to be well-known, so privacy considerations do not apply to the URN. Provision of the specific indications from callee to caller may raise privacy issues. Such provision SHALL always be explicitly authorised by the callee.

The draft is based on the ideas expressed by Paul Kyzivat on the BLISS WG mailing list.