RFC 7462
URNs for the Alert-Info Header Field of the Session Initiation Protocol (SIP)
9. IANA Considerations
9.1. URN Namespace Identifier "alert"
This section registers a new URN namespace identifier (NID), "alert", in accordance with [RFC3406] with the registration template provided in Section 7.9.2. 'Alert URN Identifiers' Registry
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.2.1.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 that contain <private-
name>s are not managed by IANA. The process of assigning these
values is described in Section 10.2.
9.2.1. Initial IANA Registration
This document defines the <alert-category>s 'service', 'source',
'priority', 'duration', 'delay' and 'locale'. The entries to be
added to the 'Alert URN Identifiers' registry table for each <alert-
category> are given in the respective sections below.
9.2.1.1. The "service" <alert-category> and <alert-identifier>s
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 RFC 7462 Specific telephony service used in this call service:normal RFC 7462 Normal ring/ringback rendering (default value) service:call-waiting RFC 7462 Call waiting was initiated at the other side of the call service:forward RFC 7462 Call has been forwarded service:recall:callback RFC 7462 Recall due to callback service:recall:hold RFC 7462 Recall due to call hold service:recall:transfer RFC 7462 Recall due to transfer
9.2.1.2. The "source" <alert-category> and <alert-identifier>s
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 RFC 7462 Classification of the other party to the call source:unclassified RFC 7462 Unclassified ring/ringback rendering (default value) source:internal RFC 7462 User at the other side of the call is internal to the enterprise or PBX system source:external RFC 7462 User at the other side of the call is external to the enterprise or PBX system source:friend RFC 7462 User at the other side of the call is a friend source:family RFC 7462 User at the other side of the call is a family member
9.2.1.3. The "priority" <alert-category> and <alert-identifier>s
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 RFC 7462 Priority of the call priority:normal RFC 7462 Normal ring/ringback rendering (default value) priority:low RFC 7462 Low priority call priority:high RFC 7462 High priority call9.2.1.4. The "duration" <alert-category> and <alert-identifier>s
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 RFC 7462 Duration of alerting signal duration:normal RFC 7462 Normal ring/ringback rendering (default value) duration:short RFC 7462 Shorter than normal duration:long RFC 7462 Longer than normal
9.2.1.5. The "delay" <alert-category> and <alert-identifier>s
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 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 RFC 7462 Delay of rendering of alerting signal delay:none RFC 7462 Immediate alerting (default value) delay:yes RFC 7462 Delayed alerting9.2.1.6. The "locale" <alert-category> and <alert-identifier>s
The following table contains the initial IANA registration for the "locale" <alert-category> and <alert-identifier>s. The value of this indicator provides information about whether the alerting signals characteristic of the specified location should be used. <alert-category>/ Reference Description <alert-identifier> ----------------------------------------------------------- locale RFC 7462 Location-specific alerting signals locale:default RFC 7462 Alerting not location specific (default value) locale:country:<ISO 3166-1 country code> RFC 7462 Alerting according to the conventions of the specified country
9.3. 'Alert URN Providers' Registry
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 rai-ads@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.10. Extension Rules
10.1. General Extension Rules
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>). That is, 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.2; 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.10.2. Private Extension Rules
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.3.10.3. Examples
10.3.1. Subsetting an Existing URN
The organization registering the <provider> "example" can define distinctive versions of <urn:alert:service:call-waiting>: urn:alert:service:call-waiting:abc@example urn:alert:service:call-waiting:def@example It can create a more specialized URN that applies to a subset of the situations to which the first URN above applies: urn:alert:service:call-waiting:abc@example:xyz Because "xyz" follows "abc@example" (and there is no intervening <private-name>), its meaning is defined by the owner of the <provider> "example".
10.3.2. A New Value within an <alert-category>
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: urn:alert:service:ghi@example 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.10.3.3. A New <alert-category>
The organization registering the <provider> "example" can define an extension <alert-category> named "jkl@example" with two <alert- indication>s "a1" and "a2": urn:alert:jkl@example:a1 urn:alert:jkl@example:a210.3.4. Subsetting a Private Extension URN
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: urn:alert:distinctive@foo:long-long urn:alert:distinctive@foo:short-long-short urn:alert:distinctive@foo:short-short-long 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>:
urn:alert:distinctive@foo:short-short@bar
11. Combinations of "alert" URNs
11.1. Priority Rules
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
that 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:
(a) Each "alert" URN has precedence over all URNs that follow it,
and its interpretation is subordinate to all URNs that precede
it.
(b) If the UA cannot implement the effect of a URN (because it does
not recognize the URN or the URN's effect is precluded by
preceding URNs), the UA repeatedly removes the final <alert-ind-
part> of the URN until either:
(1) the resulting URN is recognized and can be given effect by
some signal (without reducing the degree of expression of
any preceding URN), or
(2) the resulting URN is reduced to having no <alert-ind-part>
in which case, that URN in the series cannot be given
effect, and so is ignored.
(c) In case that after processing all the received URNs, the UA can
generate more than one signal that are equally effective at
expressing the URNs (under the preceding rules), one of those
signals is selected. When selecting from the set of equally
effective signals, the least specific signal in the set should
be chosen: a signal should not be chosen if a less-specific
signal is also in the set. (Specificity is to be judged based
on the defined meanings of the signals to the user.) (For
example, if each signal is considered to express certain <alert-
indication>s of certain <alert-category>s, one signal is less-
specific than a second signal if the first signal's <alert-
indication>s are a subset or are prefixes of the second signal's
<alert-indication>s.) However, a more-specific signal may be
chosen if the choice is based on information derived from the
containing SIP message. For example, a signal implying
<urn:alert:priority:high> may be chosen if the SIP message
contains the header field "Priority: urgent".
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. For example, 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.
11.2. Multi-mode Signals
There are cases when the device can render two signal modes (e.g.,
audio and visual, or video and text) at the same time.
Formally, the device must be considered to be 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 also 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.12. Non-normative Algorithm for Handling Combinations of URNs
The following text is a non-normative example of an algorithm for handling combinations of URNs that complies with the rules in Sections 10 and 11. Thus, it demonstrates that the rules are consistent and implementable. (Of course, a device may use any other algorithm that complies with Sections 10 and 11.)12.1. Algorithm Description
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 that 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): o The URN specifies a specific node in a specific feature tree.
o All signals in the set that are, within that feature tree,
positioned at the URN's node, or at an ancestor node of the URN's
node, are kept. All other signals are removed from the set
(because they have meanings that are incompatible with the URN's
meaning).
o Each group of signals that are tied under the previous sorts are
further sorted into groups based on how much of the URN's meaning
they represent: those which are positioned at the node of the URN
are tied for first position, those which are positioned at the
parent node of the URN are tied for second position, etc., and
those which are positioned at the root node of the feature tree
are tied for last position.
12.2. Examples of How the Algorithm Works
The following examples show how the algorithm described in the
previous section works:
12.2.1. Example 1
The device has a set of four alerting signals. We list their primary
meanings, and the locations that they are placed in the feature
trees:
Signal 1
Meaning: external
Locations:
- source:external
- priority (that is, the root node of the priority tree)
Signal 2
Meaning: internal
Locations:
- source:internal
- priority
Signal 3
Meaning: low
Locations:
- source
- priority:low
Signal 4
Meaning: high
Locations:
- source
- priority:high
To which we add:
Signal 5
Meaning: default
Locations:
- source
- priority
If the device receives <urn:alert:source:internal>, then the sort is:
Signals at source:internal: (this is, first place)
Signal 2: internal
Signals at source: (tied for second place)
Signal 3: low
Signal 4: high
Signal 5: default
And these signals are excluded from the set:
Signal 1: external
So, in this example, the sorting algorithm properly gives first place
to Signal 2 "internal".
12.2.2. Example 2
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
Meaning: default
Locations:
- source
- priority
Signal 2
Meaning: external
Locations:
- source:external
- priority
Signal 3
Meaning: internal
Locations:
- source:internal
- priority
Signal 4
Meaning: low
Locations:
- source
- priority:low
Signal 5
Meaning: high
Locations:
- source
- priority:high
Signal 6
Meaning: external high
Locations:
- source:external
- priority:high
Signal 7
Meaning: external low
Locations:
- source:external
- priority:low
Signal 8
Meaning: internal high
Locations:
- source:internal
- priority:high
If the device receives <urn:alert:source:internal>, then the sort is:
Signals at source:internal: (that is, tied for first place)
- Signal 3: internal
- Signal 8: internal high
Signals at source: (tied for second place)
- Signal 4: low
- Signal 5: high
- Signal 1: default
Signals excluded from the set:
- Signal 2: external
- Signal 7: external low
- Signal 6: external high
Two signals are tied for the first place, but the final sort orders
them:
- Signal 3: internal
- Signal 8: internal high
because it puts the least-specific signal first. So, the Signal 3
"internal" is chosen.
12.2.3. Example 3
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:
- Signal 2: external
- Signal 7: external low
- Signal 6: external high
Signals at source:
- Signal 4: low
- Signal 5: high
- Signal 1: default
Signals excluded:
- Signal 3: internal
- Signal 8: internal high
The second sort (due to <urn:alert:priority:low>) puts signals at
priority:low before signals at priority, and excludes signal at
priority:high:
- Signal 7: external low
- Signal 2: external
- Signal 4: low
- Signal 1: default
Excluded:
- Signal 6: external high
- Signal 5: high
- Signal 3: internal
- Signal 8: internal high
So, we choose Signal 7 "external low".
12.2.4. Example 4
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:
- Signal 3: internal
- Signal 8: internal high
- Signal 4: low
- Signal 5: high
- Signal 1: default
Excluded:
- Signal 2: external
- Signal 7: external low
- Signal 6: external high
The second sort is based on priority:low, and results in this order:
- Signal 3: internal
- Signal 4: low
- Signal 1: default
Excluded:
- Signal 8: internal high
- Signal 5: high
- Signal 7: external low
- Signal 2: external
- Signal 6: external high
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.
12.2.5. Example 5
Let us set up a simple set of signals, with three signals giving
priority:
Signal 1
Meaning: default
Locations:
- priority
Signal 2
Meaning: low
Locations:
- priority:low
Signal 3
Meaning: high
Locations:
- priority:high
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:
- Signal 2: low
- Signal 1: default
Excluded:
- Signal 3: high
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:
-Signal 1 :default
Excluded:
- Signal 2: low
- Signal 3: high
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.
13. User Agent Behaviour
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 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 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). Subsequent provisional responses, even within the same dialog, may contain different Alert-Info header field values. The Alert-Info header field values received within different provisional responses are treated independently. If subsequent provisional responses containing different Alert-Info header field values were received within the same dialog, the UA SHOULD render, at any time, the last received Alert-Info header field value. The handling of provisional responses containing different Alert-Info header field values that were not received within the same dialog is left as an implementation issue.14. Proxy Behaviour
A SIP proxy MAY add or remove an Alert-Info header field, and MAY add or remove Alert-Info header field values, in a SIP request or a non-100 provisional 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, 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
15. Internationalization Considerations
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 Sections 7 and 11.1.
The URNs <urn:alert:locale:country:<ISO 3166-1 country code>> select
renderings that are conventional in the specified country.
16. Security Considerations
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. For example, call-waiting (Section 6.2.1) and call-forwarding
(Section 6.2.2) services can reveal the dialog state of the UA. Such
a 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 it 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. UAs that implement alert indications SHOULD also implement SIP over TLS [RFC5246] and the sips: scheme [RFC5630].17. References
17.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997, <http://www.rfc-editor.org/info/rfc2141>. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>. [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, "Uniform Resource Names (URN) Namespace Definition Mechanisms", BCP 66, RFC 3406, October 2002, <http://www.rfc-editor.org/info/rfc3406>. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>. [RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)", RFC 5630, October 2009, <http://www.rfc-editor.org/info/rfc5630>.
17.2. Informative References
[E182] ITU-T, "Application of tones and recorded announcements in telephone services", ITU-T Recommendation E.182, 1998, <http://www.itu.int/rec/T-REC-E.182-199803-I/en>. [ISO3166-1] ISO, "English country names and code elements", ISO 3166-1, <http://www.iso.org/iso/ english_country_names_and_code_elements>. [RFC3043] Mealling, M., "The Network Solutions Personal Internet Name (PIN): A URN Namespace for People and Organizations", RFC 3043, January 2001, <http://www.rfc-editor.org/info/rfc3043>. [RFC3044] Rozenfeld, S., "Using The ISSN (International Serial Standard Number) as URN (Uniform Resource Names) within an ISSN-URN Namespace", RFC 3044, January 2001, <http://www.rfc-editor.org/info/rfc3044>. [RFC3120] Best, K. and N. Walsh, "A URN Namespace for XML.org", RFC 3120, June 2001, <http://www.rfc-editor.org/info/rfc3120>. [RFC3187] Hakala, J. and H. Walravens, "Using International Standard Book Numbers as Uniform Resource Names", RFC 3187, October 2001, <http://www.rfc-editor.org/info/rfc3187>. [RFC3188] Hakala, J., "Using National Bibliography Numbers as Uniform Resource Names", RFC 3188, October 2001, <http://www.rfc-editor.org/info/rfc3188>. [RFC4152] Tesink, K. and R. Fox, "A Uniform Resource Name (URN) Namespace for the Common Language Equipment Identifier (CLEI) Code", RFC 4152, August 2005, <http://www.rfc-editor.org/info/rfc4152>. [RFC4179] Kang, S., "Using Universal Content Identifier (UCI) as Uniform Resource Names (URN)", RFC 4179, October 2005, <http://www.rfc-editor.org/info/rfc4179>. [RFC4195] Kameyama, W., "A Uniform Resource Name (URN) Namespace for the TV-Anytime Forum", RFC 4195, October 2005, <http://www.rfc-editor.org/info/rfc4195>. [RFC4198] Tessman, D., "A Uniform Resource Name (URN) Namespace for Federated Content", RFC 4198, November 2005, <http://www.rfc-editor.org/info/rfc4198>.
[RFC5589] Sparks, R., Johnston, A., and D. Petrie, "Session Initiation Protocol (SIP) Call Control - Transfer", BCP 149, RFC 5589, June 2009, <http://www.rfc-editor.org/info/rfc5589>. [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010, <http://www.rfc-editor.org/info/rfc5890>. [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in Internationalization in the IETF", BCP 166, RFC 6365, September 2011, <http://www.rfc-editor.org/info/rfc6365>. [RFC6910] Worley, D., Huelsemann, M., Jesske, R., and D. Alexeitsev, "Completion of Calls for the Session Initiation Protocol (SIP)", RFC 6910, April 2013, <http://www.rfc-editor.org/info/rfc6910>. [RFC7463] Johnston, A., Ed., Soroushnejad, M., Ed., and V. Venkataramanan, "Shared Appearances of a Session Initiation Protocol (SIP) Address of Record (AOR)", RFC 7463, March 2015, <http://www.rfc-editor.org/info/rfc7463>. [TS24.615] 3GPP, "Communication Waiting (CW) using IP Multimedia (IM) Core Network (CN) subsystem; Protocol Specification", 3GPP TS 24.615, September 2015.Acknowledgements
The authors wish to thank Denis Alexeitsev, the editor of the initial version in BLISS, Anwar Siddiqui for his contributions to the document, Christer Holmberg for his careful review of the document, 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.
Authors' Addresses
Laura Liess (editor) Deutsche Telekom AG Heinrich-Hertz Str 3-7 Darmstadt, Hessen 64295 Germany Phone: +49 6151 5812761 EMail: laura.liess.dt@gmail.com Roland Jesske Deutsche Telekom AG Heinrich-Hertz Str. 3-7 Darmstadt, Hessen 64295 Germany Phone: +49 6151 5812766 EMail: r.jesske@telekom.de Alan Johnston Avaya, Inc. St. Louis, MO United States EMail: alan.b.johnston@gmail.com Dale R. Worley Ariadne Internet Services, Inc. 738 Main St. Waltham, MA 02451 United States Phone: +1 781 647 9199 EMail: worley@ariadne.com Paul Kyzivat Huawei United States EMail: pkyzivat@alum.mit.edu