| SALUD | L. Liess, Ed. |
| Internet-Draft | R. Jesske |
| Updates: 3261 (if approved) | Deutsche Telekom AG |
| Intended status: Standards Track | A. Johnston |
| Expires: January 21, 2015 | Avaya |
| D. Worley | |
| Ariadne | |
| P. Kyzivat | |
| Huawei | |
| July 20, 2014 |
URNs for the Alert-Info Header Field of the Session Initiation Protocol (SIP)
draft-ietf-salud-alert-info-urns-13
The Session Initiation Protocol (SIP) supports the capability to provide a reference to a specific rendering to be used by the UA as an alerting signal (e.g., a ring tone or ringback tone) when the user is alerted. This is done using the Alert-Info header field. However, the reference (typically a URL) addresses only a specific network resource with specific rendering properties. There is currently no support for standard identifiers for describing the semantics of the alerting situation or the characteristics of the alerting signal, without being tied to a particular rendering. To overcome these limitations and support new applications, a new family of URNs for use in Alert-Info header fields (and situations with similar requirements) is defined in this specification.
This document normatively updates RFC 3261, which defines the Session Initiation Protocol (SIP): It changes the usage of the Alert-Info header field defined in RFC 3261 by additionally allowing its use in all provisional responses to INVITE (except the 100 response). This document also permits proxies to add and remove header field values from the Alert-Info header field.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 21, 2015.
Copyright (c) 2014 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 Simplified BSD License.
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.
The Session Initiation Protocol (SIP) [RFC3261] includes a means to suggest to a user agent (UA) a particular ringback tone or ring tone to be used during session establishment. In [RFC3261] this is done by including a URI in the Alert-Info header field, that specifies a reference to the tone. The URI is most commonly the HTTP URL to an audio file. On the receipt of the Alert-Info header field the user agent may fetch the referenced ringback tone or ring tone and play it to the user.
This mechanism hinders interoperability when there is no common understanding of the meaning of the referenced tone, which might be country- or vendor-specific. It can lead to problems for the user trying to interpret the tone and for the UA wanting to substitute its own tone (e.g., in accordance with user preferences) or provide an alternative alerting mode (e.g., for hearing-impaired users). If caller and callee are from 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 using URLs of audio files is that the referenced tones are tied to particular renderings. There is no method to signal the semantic intention of the alert while enabling the recipient UA to choose the specific alert indication (such as a particular tone, vibration, or visual display) to use to signal the intention. Similarly, there is no method to signal particular rendering features (such as short duration, delay, or country-specific conventions).
The issues with URLs that reference audio files can be avoided by using fixed URLs with specific meanings. However this approach has its own interoperability issues. For example, consider the PBX special ring tone for an external (to the PBX) caller. Different vendors use different approaches such as:
where ring.pcm is a dummy file name, or:
As a result, the Alert-Info header field currently only works when the same vendor provides PBX and UA, and only then if the same artificial proprietary URI convention used.
To solve the described issues, this specification defines the new URN namespace "alert" for the Alert-Info header field that allows for programmatic user interface adaptation and for conversion of equivalent alerting tones in the Public Switched Telephone Network (PSTN) when the client is a gateway. The work to standardize an "alert" URN will increase SIP interoperability for this header field by replacing proprietary conventions used today.
The "alert" namespace provides syntax for several different application spaces, e. g.:
Some advantages of a URN rather than a URL of a downloadable resource:
The downside is that if the recipient does not understand the URN then it will only be able to render a default ringback tone or ring tone.
This document creates a new URN namespace and registry for alert indications and registers some initial values.
In practice, this specification extends the usage of the Alert-Info header field in that it will cause the use of a new class of URIs and the use of multiple URIs. Backward compatibility issues are not expected, as devices that do not understand an "alert" URN should ignore it, and devices should not malfunction upon receiving multiple Alert-Info header field values (<alert-param>s in [RFC3261]) (which was syntactically permitted before, but rarely used).
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 [RFC2119].
This specification uses a number of terms to refer to the roles involved in the use of alerting indications in SIP. A "specifier" sends an "alerting indication" (one or more URNs in an Alert-Info header field) to a "renderer" which then "renders" a "signal" or "rendering" based on the indication to a human user. A "category" is a characteristic whose "values" can be used to classify indications.
This specification uses the terms "ring tone" and "ringback tone". A "ring tone" or "calling signal" (terminology used in [E182]) is a signal generated by the callee's end device, advising the callee about an incoming call. A "ringback tone" or "ringing tone" (terminology used in [E182]) is a signal advising the caller that a connection has been made and that a ring tone is being rendered to the callee.
This specification changes the usage of the Alert-Info header field defined in [RFC3261] by additionally allowing its use in all provisional responses to INVITE (except the 100 response).
Previously, the Alert-Info header field was only permitted in 180 (Ringing) responses. But in telephony, other situations indicated by SIP provisional responses, such as 181 (Call Is Being Forwarded) and 182 (Call Is Being Queued), are often indicated by tones. Extending the applicability of the Alert-Info header field allows the telephony practice to be implemented in SIP.
To support this change, the following paragraph replaces the the first paragraph of section 20.4 of [RFC3261]:
A SIP proxy MAY add or remove header field values in an Alert-Info header field in a SIP request or a provisional 1xx response (excepting a 100 response).
This section discusses the requirements for an alerting indication to transport the semantics of the alerting situation or the characteristics of the rendering.
REQ-1: The mechanism will allow user agents (UAs) and proxies to provide in the Alert-Info header field an alerting indication which describes the semantics of the signaling situation or the characteristics of the rendering and allows the recipient to decide how to render the received information to the user.
REQ-2: The mechanism will allow the alerting indication to be specified "by name" rather than "by value", to enable local policy decisions whether to use it or not.
REQ-3: The mechanism will enable alerting indications to represent a wide variety of signals, which have many largely-orthogonal characteristics.
REQ-4: The mechanism will enable the set of alerting indications to be able to support extensibility by a wide variety of organizations that are not coordinated with each other. Extensions will be able to:
REQ-5: The mechanism will be flexible, so new alerting indications can be defined in the future, when SIP-applications evolve. E. g. "alert" URNs could identify specific media by name, such as "Beethoven's Fifth", and the end device could render some small part of it as a ring tone.
REQ-6: The mechanism will provide only an indication capability, not a negotiation capability.
REQ-7: The mechanism will not require an alerting indication to depend on context provided by a previous alerting indication in either direction.
REQ-8: The mechanism will allow transmission in the Alert-Info header field of SIP INVITE requests and provisional 1xx responses excepting the 100 responses.
REQ-9: The mechanism will be able to accommodate renderers that are customized with a limited or uncommon set of signals they can render and renderers that are provided with a set of signals that have uncommon semantics. (The canonical example is a UA for the hearing-impaired, customized with an uncommon set of signals, video or text instead of audio. By REQ-6, the renderer has no way of transmitting this fact to the specifier.)
REQ-10: The mechanism will allow an alerting indication to reliably carry all extensions if the specifier and the renderer have designs that are properly coordinated.
REQ-11: The mechanism will allow a renderer to select a tone that approximates to that intended by the specifier if the renderer is unable to provide the precise tone indicated.
REQ-12: The mechanism will support alerting indications relating to services such as call waiting, forward, transfer-recall, auto-callback and hold-recall.
REQ-13: The mechanism will allow rendering common PBX ring tone types.
REQ-14: The mechanism will allow rendering specific country ringback tones.
REQ-15: The mechanism will allow rendering tones for emergency alerts. (Use cases and values definition are not a subject of this specification.)
REQ-16: The mechanism will allow rendering using other means than tones, e.g. text or images.
REQ-17: The mechanism will allow TDM gateways to map ring/ringback tones from legacy protocols to SIP at the edge of a network, e.g. national ring tones as defined in TIA/EIA-41-D and 3GPP2 A.S0014. (Use cases and values definition are not a subject of this specification.)
REQ-18: The mechanism will ensure that if an UA receives "alert" URNs or portions of an "alert" URN it does not understand, it can ignore them.
REQ-19 The mechanism will allow storage of the actual encoding of the rendering locally rather than fetching it.
REQ-20: The mechanism must provide a simple way to combine two or more alerting indications to produce an alerting indication that requests a combination of the intentions of the two alerting indications, where any contradictions or conflicts between the two alerting indications are resolved in favor of the intention of the first alerting indication.
This section describes some use cases for which the "alert" URN mechanism is needed today.
This section defines some commonly encountered ring tones on PBX or business phones. They are as follows:
This tone indicates that the default or normal ring tone should be rendered. This is essentially a no-operation "alert" URN and should be treated by the UA as if no "alert" URN is present. This is most useful when Alert-Info header field parameters are being used. For example, in [I-D.ietf-bliss-shared-appearances], an Alert-Info header field needs to be present containing the "appearance" parameter, but no special ring tone needs to be specified.
[Note to RFC Editor: Please update the information for the above reference and change its tag from "I-D.ietf-bliss-shared-appearances" to the appropriate RFC number.]
This tone is used to indicate that the caller is external to the enterprise or PBX system. This could be a call from the PSTN or from a SIP trunk.
This tone is used to indicate that the caller is internal to the enterprise or PBX system. The call could have been originated from another user on this PBX or on another PBX within the enterprise.
A PBX tone needs to indicate that a priority level alert should be applied for the type of alerting specified (e.g. internal alerting).
In this case the alerting type specified (e.g. internal alerting) should be rendered shorter than normal. In contact centers, this is sometimes referred to as "abbreviated ringing" or a "zip tone".
In this case the alerting type specified should be rendered after a short delay. In some bridged line/shared line appearance implementations, this is used so that the bridged line does not ring at exactly the same time as the main line, but is delayed a few seconds.
These tones are used to indicate specific PBX and public network telephony services.
The Call Waiting Service [TS24.615] permits a callee to be notified of an incoming call while 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 have finished the ongoing conversation. To provide this information, the callee's UAS (or proxy) aware of the call waiting condition can add the call-waiting indication to the Alert-Info header field in the 180 (Ringing) response.
This feature is used in a 180 (Ringing) response when a call forwarding feature has been initiated on an INVITE. Many PBX system implement a forwarding "beep" followed by normal ringing to indicate this. Note that a 181 response can be used in place of this URN.
This feature is used when a blind transfer [RFC5589] has been performed by a server on behalf of the transferor and fails. Instead of failing the call, the server calls back the transferor, giving them another chance to transfer or otherwise deal with the call. This service tone is used to distinguish this INVITE from a normal incoming call.
This feature is used when a user has utilized a server to implement an automatic callback service [RFC6910]. When the user is available, the server calls back the user and utilizes this service tone to distinguish this INVITE from a normal incoming call.
This feature is used when a server implements a call hold timer on behalf of an endpoint. After a certain period of time of being on hold, the user who placed the call on hold is alerted to either retrieve the call or otherwise dispose of the call. This service tone is used to distinguish this case from a normal incoming call.
In the PSTN, different tones are used in different countries. End users are accustomed to hear the callee's country ringback tone and would like to have this feature for SIP.
This section provides the registration template for the "alert" URN namespace identifier (NID) according to [RFC2141] and [RFC3406].
alert-URN = "urn:alert:" alert-identifier
alert-identifier = alert-category ":" alert-indication
alert-category = alert-name
alert-indication = alert-ind-part *(":" alert-ind-part)
alert-ind-part = alert-name
alert-name = alert-label / private-name
private-name = alert-label "@" provider
provider = alert-label
alert-label = let-dig [ *let-dig-hyp let-dig ]
let-dig-hyp = let-dig / "-"
let-dig = ALPHA / DIGIT
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
DIGIT = %x30-39 ; 0-9
The following <alert-category> values are defined in this document:
This section describes the "alert" URN indication values for the alert-categories defined in this document.
For each <alert-category> , a default <alert-indication> is defined, which is essentially a no-operation "alert" URN and should be treated by the UA as if no "alert" URN for the respective category is present. "alert" URN default indications are most useful when Alert-Info header field parameters are being used. For example, in [I-D.ietf-bliss-shared-appearances], an Alert-Info header field needs to be present containing the "appearance" parameter, but no special ringtone need be specified.
The "<private-name>" syntax is used for extensions defined by independent organizations, as described in Section 10.2.
Examples: <urn:alert:service:call-waiting> or <urn:alert:service:recall:transfer>.
(These <alert-indication>s will rarely be provided by the sending UA; rather they will usually be inserted by a proxy acting on behalf of the recipient UA to inform the recipient UA about the origins of a call.)
Examples: <urn:alert:source:external>.
Examples: <urn:alert:priority:high>.
Examples: <urn:alert:duration:short>.
Examples: <urn:alert:delay:yes>.
The ISO 3166-1 country code [ISO3166-1] is used to inform the renderer on the other side of the call that a country-specific rendering should be used. For example, to indicate ringback tones from South Africa, the following URN would be used: <urn:alert:locale:country:za>.
This section registers a new URN namespace identifier (NID), "alert", in accordance with [RFC3406] with the registration template provided in Section 7.
Standard "alert" URNs are recorded as <alert-identifier>s in a new registry called "Alert URN Identifiers". Thus, creating a new standard "alert" URN requires IANA action. IANA manages the "Alert URN Identifiers" registry under the policy 'Specification Required' [RFC5226] following the guidelines in Section 10.1.
The registry contains entries in the following formats:
<alert-category>/ Reference Description
<alert-identifier>
---------------------------------------------------------------
foo [RFCxyz] Description of the 'foo'
<alert-category>;
foo:bar [RFCabc] Description of the 'foo:bar'
<alert-identifier>
foo:<range> [RFCdef] Description of the
'foo:<category>'
<alert-identifer>s (which will
reference the <range> value)
The first value in each row is the value that is registered, which is either: (1) an <alert-category> value, (2) an <alert-identifier> value, composed of an <alert-category> followed by an <alert-indication>, in turn composed of one or more <alert-label>s, or (3) a pattern for <alert-identifier> values (e.g., for the "locale" <alert-category> in Section 9.1.2.6).
The second value in each row is the reference to the required specification for the value.
The third value in each row is a short description of the semantics of the value.
A new URN MUST NOT be registered if it is equal by the comparison rules (that is, case-insensitive string comparison) to an already registered URN.
<alert-category> and <alert-identifier> values which contain <private-name>s are not managed by IANA. The process of assigning these values is described in Section 10.2.
This document defines the <alert-category>s 'service', 'source', 'priority', 'duration', 'delay' and 'locale'. The entries to be added to the registry table for each <alert-category> are given in the respective sections below.
[Note to RFC Editor: In all the entries below, please replace XXXX in [RFCXXXX] by the new RFC number, when assigned.]
The following table contains the initial IANA registration for the "service" <alert-category> and <alert-identifier>s. The value of this indicator is set to a value different from "normal" if the caller or callee is informed that a specific telephony service has been initiated.
<alert-category>/ Reference Description
<alert-identifier>
-----------------------------------------------------------
service [RFCXXXX] Specific telephony
service used in this
call
service:normal [RFCXXXX] Normal ring/ringback
rendering (default value)
service:call-waiting [RFCXXXX] Call waiting was
initiated at the other side
of the call
service:forward [RFCXXXX] Call has been forwarded
service:recall:callback [RFCXXXX] Recall due to callback
service:recall:hold [RFCXXXX] Recall due to call hold
service:recall:transfer [RFCXXXX] Recall due to transfer
The following table contains the initial IANA registration for the "source" <alert-category> and <alert-identifier>. The value of this indicator provides information about the user at the other side of the call.
<alert-category>/ Reference Description
<alert-identifier>
-----------------------------------------------------------
source [RFCXXXX] Classification
of the other party
to the call
source:unclassified [RFCXXXX] Unclassified ring/ringback
rendering (default value)
source:internal [RFCXXXX] User at the other side of
the call is internal to the
enterprise or PBX system
source:external [RFCXXXX] User at the other side of
the call is external to the
enterprise or PBX system
source:friend [RFCXXXX] User at the other side of
the call is a friend
source:family [RFCXXXX] User at the other side of
the call is a family member
The following table contains the initial IANA registration for the "priority" <alert-category> and <alert-identifier>s. The value of this indicator provides information about the priority the alerted user should give to the call.
<alert-category>/ Reference Description
<alert-identifier>
-----------------------------------------------------------
priority [RFCXXXX] Priority of the
call
priority:normal [RFCXXXX] Normal ring/ringback
rendering (default value)
priority:low [RFCXXXX] Low priority call.
priority:high [RFCXXXX] High priority call
The following table contains the initial IANA registration for the "duration" <alert-category> and <alert-identifier>s. The value of this indicator provides information about the duration of the alerting signals compared to the default alerting signals.
<alert-category>/ Reference Description
<alert-identifier>
-----------------------------------------------------------
duration [RFCXXXX] Duration of alerting signal
alerting signal
duration:normal [RFCXXXX] Normal ring/ringback
rendering (default value)
duration:short [RFCXXXX] Shorter than normal
duration:long [RFCXXXX] Longer than normal
The following table contains the initial IANA registration for the "delay" <alert-category> and <alert-identifier>s. The value of this indicator provides information about about whether the presentation of the alerting signal should be delayed compared to the default presentation process. For more details see Section 6.1.6.
<alert-category>/ Reference Description
<alert-identifier>
-----------------------------------------------------------
delay [RFCXXXX] Delay of rendering of alerting
of alerting signal
delay:none [RFCXXXX] Immediate alerting
(default value)
delay:yes [RFCXXXX] Delayed alerting
The following table contains the initial IANA registration for the "locale" <alert-category> and <alert-identifier>s. The value of this indicator provides information suggests that alerting signals characteristic of the specified location should be used.
<alert-category>/ Reference Description
<alert-identifier>
-----------------------------------------------------------
locale [RFCXXXX] Location-specific
alerting signals
locale:default [RFCXXXX] Alerting not location
specific
(default value)
locale:country:<ISO 3166-1 country code>
[RFCXXXX] Alerting according to the
conventions of the specified
country
Values of <provider>, which are used to create <private-name>s, are recorded in a new registry called "Alert URN Providers". (Private extension "alert" URNs that are defined are not recorded by IANA.) The registry is managed by IANA under the policy 'First Come First Served'.[RFC5226]
The registry contains entries in the following format:
<provider> Registrant Contact URI --------------------------------------------------------------------- example IETF mailto:rai-ads&tools.ietf.org
The first value in each row is the <provider> value that is registered. This value is case-insensitive and MUST comply with the syntax for Non Reserved LDH-labels [RFC5890].
The second value in each row is the name of the registrant of the value.
The third value is a contact URI for the registrant.
The registry initially contains the one entry shown above, which can be used for constructing examples of private extension URNs.
The set of "alert" URNs is extensible. An extension "at the top level" creates a new <alert-category> (which represents a new alerting characteristic), an extension "at the second level" creates a new <alert-indication> value for an existing <alert-category> , an extension "at the third level" creates a subdivision of an existing <alert-indication> (that has one <alert-ind-part>), etc. URNs allow (in principle) indefinite subdivision of existing <alert-indication> values, although most of the standard "alert" URNs have only one level of subdivision and a few have two levels of subdivision.
Extensions, either standard or private, MUST conform to the following principles:
A new <alert-category> is independent of all previously-existing <alert-category>s: For any combination of one <alert-identifier> in the new <alert-category> with any one <alert-identifier> in any of the previously-existing <alert-category>s, there are potential calls to which the combination can be meaningfully applied.
A new <alert-identifier> that has more than one <alert-ind-part> is a semantic refinement of a parent <alert-identifier>, the parent being obtained by deleting the final <alert-ind-part>. The new <alert-identifier> has as parent the most specific previously-existing <alert-identifier> whose meaning includes all potential calls to which the new <alert-identifier> could be meaningfully applied.
A new <alert-identifier> has no semantic overlap with any sibling <alert-identifier> (<alert-identifier>s that differ only in the final <alert-ind-part>). I.e., there could be no call to which both <alert-identifier>s could be meaningfully applied.
The process for defining new standard "alert" URNs is described in Section 9.1.1; all such definitions require registering a publicly-available specification. The process for defining new "alert" URNs via the private extension mechanism is described in Section 10.2.
The "<private-name>" syntax is used to create private extensions, extensions that are not registered with IANA. The "<private-name>" has the form of an "<alert-label>" followed by "@" and then a "<provider>" that designates the organization defining the extension. Both <alert-label> and <provider> have the same syntax as an ordinary ASCII DNS label. A private extension URN is created by using a <private-name> as either an <alert-category> or an <alert-ind-part>.
If the <private-name> is used as an <alert-category>, the characteristic of the alerting signal that the <alert-category> describes is defined by the organization. If the <private-name> is used as the first <alert-ind-part>, the organization defines an alternative value for the standardized <alert-category> of the URN. If the <private-name> is used as the second or later <alert-ind-part>, the organization defines the meaning of the URN as a subset of the meaning of the shorter URN resulting when the <private-name> (and any subsequent <alert-ind-part>s) are removed.
Within a URN, all <alert-label> components that follow a <private-name> but are before any following <private-name>s are additional private extensions whose meaning is defined by the organization defining the nearest preceding <private-name>.
A URN that contains a private extension can be further subdivided by the private extension of a different organization: the second organization appends an <alert-ind-part> that is a <private-name> containing a the <provider> value for the second organization.
The meaning of a <private-name> or an <alert-label> that is defined privately (because of a preceding <private-name>) is only fixed within the context provided by the sequence of preceding <alert-name>s; these components have no meaning in isolation and there is no necessary relationship between the meaning of textually identical <alert-name>s that are preceded by different sequences of <alert-name>s.
Creating private extension "alert" URNs is not a Standards Action and they are not registered with IANA.
The organization defining a private extension is responsible for ensuring persistence of the meaning of the private extension.
Private extensions MUST conform to the principles of Section 10.1, both in regard to previously-existing standard <alert-URN>s and in regard to any previously-existing private extensions using the same <provider> value, and any other private extensions that the organization is aware of. In particular, a private extension MUST NOT duplicate any standard URN or any private extension that the organization is aware of. (In either of those cases, the organization MUST use the existing URN for its purposes.)
An organization obtains a <provider> value for constructing <private-name>s by registering the value with IANA as provided in Section 9.2.
The organization registering the <provider> "example" can define distinctive versions of <urn:alert:service:call-waiting>:
It can create a more specialized URN that applies to a subset of the situations to which the first URN above applies:
Because "xyz" follows "abc@example" (and there is no intervening <private-name>), its meaning is defined by the owner of the <provider> "example".
The organization registering the <provider> "example" can define URNs in the "service" category to express a new service that is not covered by any of the standardized URNs:
However, before defining such a URN, the organization should verify that the set of calls to which the URN applies is not a subset of the set of calls for some existing URN. If it is a subset, the extension URN should be a subdivision of the existing URN.
The organization registering the <provider> "example" can define an extension <alert-category> named "jkl@example" with two <alert-indication>s "a1" and "a2":
The organization registering the <provider> "foo" wants to define a set of URNs that specify the different ring patterns used by a "distinctive ring" service to alert for incoming calls that are directed to different directory numbers. These ring patterns are composed of groups of ring sounds that have particular patterns of lengths.
The company can create a private <alert-category> "distinctive@foo", and within it assign three 'alert' URNs that indicate the three different ring patterns used by the company's service:
Later, the company registering the <provider> "bar" wants to define an additional 'alert' URN for the ring pattern "short short", which it uses to support a fourth directory number for a phone instrument. The company can create a <private-name> to be used with the "distinctive@foo" <alert-category>:
This section describes combination rules for the case when all the Alert-Info header fields only contain "alert" URNs. Other combinations of URIs in the Alert-Info header fields of the same SIP message are not defined in this specification.
In many cases, more than one URN will be needed to fully define a particular tone. This is done by including multiple "alert" URNs, in one or more Alert-Info header fields in a request or a response. For example, an internal, priority call could be indicated by Alert-Info: <urn:alert:source:internal>, <urn:alert:priority:high> A priority call waiting tone could be indicated by Alert-Info: <urn:alert:service:call-waiting>, <urn:alert:priority:high>
The sender of the Alert-Info header field may include an arbitrary list of "alert" URNs, even if they are redundant or contradictory. An earlier URN has priority over any later contradictory URN. This allows any element to modify a list of URNs to require a feature value (by adding a URN at the beginning of the list) or to suggest a feature value (by adding a URN at the end of the list).
The receiving UA matches the received "alert" URN combination with the signal(s) it is able to render.
The implementation is free to ignore an "alert" URN if it does not recognize the URN, or if it is incapable of rendering its effect in the context. Similarly, it can remove a final series of one or more <alert-ind-part>s of an "alert" URN to create a "more generic" URN which it recognizes and whose meaning it can render in the context.
The exact way in which a UA renders a received combination of "alert" URNs is left as an implementation issue. However, the implementation MUST comply to following rules:
In all situations, the set of signals that can be rendered and their significances may change based on user preferences and local policy.
In addition, the chosen signal may change based on the status of the UA. E.g., if a call is active on the UA, all audible signals may become unavailable, or audible signals may be available only if <urn:alert:priority:high> is specified.
There are cases when the device can render two signal modes (e.g., audio and visual, or video or text) at the same time.
Formally, the device must be considered as making its choice from the set of all combined signals that it can render (pairs of one signal from the first mode and one signal from the second mode), and that choice must conform to the above rules. However, it can be proven that if the device makes its rendering choice for each of the two modes independently, with each choice separately conforming to the above rules, its combined choice conforms to the above rules, when it is regarded as a choice from among all possible combinations.
In such a situation, it may simplify implementation to make each choice separately. It is an implementation decision whether to chose from among combined signals, or to combine choices made from each signal mode.
The following text is a non-normative example of an algorithm for handling combinations of URNs that complies with the rules in Section 10 and Section 11. Thus, it demonstrates that the rules are consistent and implementable. (Of course, a device may use any other algorithm which complies with Section 10 and Section 11.)
For each <alert-category> (feature) known by the implementation, there is a "feature tree" of the known <alert-indication>s for that <alert-category>, with the sequence of <alert-ind-part>s in an <alert-indication> specifying the path in the tree from the root to the node representing the <alert-indication>. For this description, we will name each tree and its root node by the <alert-category> name, and name each non-root node by the <alert-identifier>. Each URN thus corresponds to one non-root node in one feature tree. For example, there is a tree named "source", whose root node is also named "source", and which has the children source:internal, source:external, source:friend, and source:family. The URN <urn:alert:source:external> is placed at the node "source:external" in the "source" tree. If the implementation understands <urn:alert:source:foo@example>, there is a node source:foo@example that is a child of node "source". If the implementation understands <urn:alert:source:external:bar@example>, there is a node source:external:bar@example that is a child of node source:external. (Of course, there are an infinite number of potential additional nodes in the tree for private values, but we don't have to represent those nodes explicitly unless the device has a signal representing the private value.)
We assign similar locations to signals, but each signal has a position in *every* tree, describing the specific combination of meanings that it carries. If a signal has a simple meaning, such as "external source", its place in the "source" tree is source:external, showing that it carries the "external source" meaning, but its place in every other feature tree is at the root node, meaning that it has no particular meaning for those features.
A signal that has a complex meaning may have non-root positions in more than one feature tree. For example, an "external, high priority" signal would be placed at source:external and priority:high in those trees, but be at the root in all other feature trees.
In order to assure that the algorithm always selects at least one signal, we require that there is a "default" signal, whose position in every feature tree is at the root. This default signal will never be excluded from the set of acceptable signals for any set of URNs, but will be the lowest-priority signal for any set of URNs.
The algorithm proceeds by considering each URN in the received Alert- Info header fields from left to right, while revising a set of signals. The set of signals starts as the entire set of signals available to the device. Each URN excludes some signals from the set, and "sorts" the signals that remain in the set according to how well they represent the URN. (The details of these operations are described below.) The first URN is the "major sort", and has the most influence on the position of a signal in the set. The second URN is a "minor sort", in that it arranges the orders of the signals that are tied within the first sort, the third URN arranges the orders of the signals that are tied within the first two sorts, etc.
At the end of the algorithm, a final, "most minor" sort is done, which orders the signals which remain tied under all the sorts driven by the URNs. This final sort places the least specific signals (within their tied groups) "first". (If one signal's position in each feature tree is ancestral or the same as a second signal's position in that tree, the first signal is "less specific" than the second signal. Other cases are left to the implementation to decide.)
Once all the URNs are processed and the sorting of the signals that have not been excluded is done, the device selects the first signal in the set.
Here is how a single sort step proceeds, examining a single URN to modify the set of signals (by excluding some signals and further sorting the signals that remain):
The following examples show how the algorithm described in the previous section works:
The device has a set of 4 alerting signals. We list their primary meanings, and the locations that they are placed in the feature trees:
Signal 1
Signal 2
Signal 3
Signal 4
To which we add:
Signal 5
If the device receives <urn:alert:source:internal>, then the sort is:
Signals at source:internal: (this is, first place)
Signals at source: (tied for second place)
And these signals are excluded from the set:
So in this example, the sorting algorithm properly gives first place to Signal 2 "internal".
Let us add to the set of signals in Example 1 ones that express combinations like "internal, high priority", but let us specifically exclude the combination "internal, low priority" so as to set up some tricky examples. This enlarges our set of signals:
Signal 1
Signal 2
Signal 3
Signal 4
Signal 5
Signal 6
Signal 7
Signal 8
If the device receives <urn:alert:source:internal>, then the sort is:
Signals at source:internal: (that is, tied for first place)
Signals at source: (tied for second place)
Signals excluded from the set:
Two signals are tied for the first place, but the final sort orders them:
because it puts the least-specific signal first. So the Signal 3 "internal" is chosen.
The same device receives <urn:alert:source:external>, <urn:alert:priority:low>. The first sort (due to <urn:alert:source:external>) is:
Signals at source:external:
Signals at source:
Signals excluded:
The second sort (due to <urn:alert:priority:low>) puts signals at priority:low before signals at priority, and excludes signal at priority:high:
Excluded:
So, we choose Signal 7 "external low".
Suppose the same device receives <urn:alert:source:internal>, <urn:alert:priority:low>. Note that there is no signal that corresponds to this combination.
The first sort is based on source:internal, and results in this order:
Excluded:
The second sort is based on priority:low, and results in this order:
Excluded:
So we choose the Signal 3 "internal".
Note that <urn:alert:priority:low> could not be given effect because it followed <urn:alert:source:internal>. If the two URNs had appeared in the reverse order, the Signal 2 "external" would have been chosen, because <urn:alert:priority:low> would have been given precedence.
Let us set up a simple set of signals, with three signals giving priority:
Signal 1
Signal 2
Signal 3
Notice that we've used the "default" signal to cover "normal priority". That is so the signal will cover situations where no priority URN is present, as well as the ones with <urn:alert:priority:normal>. So we're deliberately failing to distinguish "priority:normal" from the default priority.
If the device receives <urn:alert:priority:low>, the sort is:
Excluded:
and Signal 2 "low" is chosen.
Similarly, if the device receives <urn:alert:priority:high>, Signal 3 is chosen.
If the device receives <urn:alert:priority:normal>, the sort is:
Excluded:
and Signal 1 "default" is chosen.
If no "priority" URN is received, Signal 1 "default"will be put before Signal 2 "low" and Signal 3 " high" by the final sort, and so it will be chosen.
A SIP UA MAY add a URN or multiple URNs to the Alert-Info header field in a SIP request or a provisional 1xx response (excepting a 100 response) when it needs to provide additional information about the call or about the provided service.
Upon receiving a SIP INVITE request or a SIP provisional response with an Alert-Info header field that contains a combination of Alert- Info URNs, the User Agent (UA) attempts to match the received Alert- Info URNs combination with a signal it can render. The process the UA uses MUST conform to the rules described in Section 11. (A non-normative algorithm example for the process is described in Section 12.)
The User Agent (UA) must produce a reasonable rendering regardless of the combination of URIs (of any schemes) in the Alert-Info header field: It MUST produce a rendering based on the URIs that it can understand and act on (if any), interpreted as prescribed by local policy, and ignore the other URIs. In particular, unless the containing message is a request and is immediately rejected, the UA SHOULD provide some alert unless it is instructed not to (for example, by Alert-Info URIs that it understands, the presence of a Replaces or Joins header field, local policy, or direction of the user).
A SIP proxy MAY add an Alert-Info header field if none is present, and MAY add or remove header field values of an Alert-Info header field in a SIP request or a provisional 1xx response (excepting a 100 response) when it needs to modify the information about the call or about the provided services.
There are many reasons a proxy may choose do this. For example: (1) to add indications based on information that the proxy can determine about the call, such as that it is coming from an external source, or that the INVITE contains a "Priority: urgent" header field; (2) to add indication that a particular service is being invoked at this end of the call; (3) to remove undesirable indications, such as possibly deceptive indications from untrusted sources; and (4) to remove indications that contain information that should be suppressed for privacy reasons.
The following example shows a typical example of a 180 (Ringing) provisional response that has been modified by a proxy. The response sent by the UAS to the proxy was very similar, but had no Alert-Info header field. The proxy has added Alert-Info header field values specifying both a network audio resource referenced by the HTTP URI and the URN indication for the call-waiting service. This allows the UAC to render the network audio resource, or to choose a rendering based on the URN, or to perform some combination of these actions. Due to Section 10, the UAC must produce some reasonable rendering in this situation.
SIP/2.0 180 (Ringing)
Alert-Info: <http://www.example.com/sound/moo.wav>,
<urn:alert:service:call-waiting>
To: Bob <sip:bob@biloxi.example.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710
Contact: <sip:bob@192.0.2.4>
CSeq: 314159 INVITE
Via: SIP/2.0/UDP server10.biloxi.example.com;
branch=z9hG4bK4b43c2ff8.1
Content-Length: 0
The <alert-identifier> labels are protocol elements [RFC6365] and are not normally seen by users. Thus, the character set for these elements is restricted, as described in Section 7.
Allowance has been made for the possibility of internationalizing <alert-identifier>s by allowing them to be A-labels: A processor that does not understand such <alert-identifier>s is required to ignore them as specified in Section 7 and Section 11.1.
The URNs <urn:alert:locale:country:<ISO 3166-1 country code>> select renderings that are conventional in the specified country.
As an identifier, the alert URN does not appear to raise any particular security issues. The indications described by the "alert" URN are meant to be well-known.
However, the provision of specific indications may raise privacy issues by revealing information about the source UA, e.g. its nature, its dialog state, or services initiated at its end of the call. E.g., call-waiting (Section 6.2.1) and call-forwarding (Section 6.2.2) services can reveal the dialog state of the UA. Such provision SHALL always require authorization on behalf of the user of the source UA (usually through accessing configured policy). Authorization SHALL NOT assume that there is any limitation of the potential recipients of the indications without obtaining specific information about the SIP transaction.
Based on local policy, a UA MAY choose to ignore undesirable indications (e.g. possibly deceptive indications from untrusted sources), and MAY choose not to send indications that are otherwise valid in the context (e.g., for privacy reasons). A proxy acting on behalf of a UA MAY add or delete indications going to or from the UA for the same reasons.
Since the alert indications can be sensitive, end-to-end SIP encryption mechanisms using S/MIME MAY be used to protect it. User agents that implement alert indications SHOULD also implement SIP over TLS [RFC5246] and the sips: scheme [RFC5630].
The authors wish to thank Denis Alexeitsev, the editor of the initial draft in BLISS, Anwar Siddiqui for his contributions to the draft, Christer Holmberg for his careful review of the draft, Adam Roach, Dean Willis, Martin Huelsemann, Shida Schubert, John Elwell and Tom Taylor for their comments and suggestions and Alfred Hoenes for his extensive comments and proposals related to new namespace identifiers for URNs.