A Simpler
Method for Resolving Alert-Info URNsAriadne Internet Services738 Main St.WalthamMA02451USworley@ariadne.com
Applications and Real Time (ART)
SALUDI-DInternet-DraftThe "alert" namespace of uniform resource names (URNs) can be
used in the Alert-Info header field of Session Initiation
Protocol (SIP) requests and responses to inform a VoIP telephone
(user agent) of the characteristics of the call that the user
agent has originated or terminated. The user agent must resolve
the URNs into a signal, that is, it must select the best
available signal to present to its user to indicate the
characteristics of the call. This document describes a method
by which a user agent's designer can, based on the user agent's
signals and their meanings, construct a finite state machine
(FSM) to process the URNs to select a signal in a way that obeys
the restrictions
given in the definition of the "alert" URN namespace. In many
situations, the resulting FSM is simpler to implement and faster than
the selection algorithm described in .When a SIP user agent server receives an incoming INVITE
request, it chooses an alerting signal (the
ring tone) to present to its user (the called user) by
processing the Alert-Info header field(s) in the incoming INVITE
request .
Similarly, a SIP user agent client determines an
alerting signal (the ringback tone) to present to its user (the
calling user) by processing the Alert-Info header field(s) in
the incoming provisional response(s) to its outgoing INVITE
request. envisioned that the Alert-Info
header field value would be a URL that the user agent could use
to retrieve the encoded
media of the signal. This usage has security problems
and is inconvenient to implement in practice. introduced an alternative practice: The
Alert-Info values can be URNs in the "alert" URN namespace which specify
features of the call or of the signal that should be signaled
to the user. defined a large set of
"alert" URNs and procedures for extending the set.A user agent is unlikely to provide more than a small set of alerting
signals and there are an infinite number of possible
combinations of "alert" URNs. Thus, a user agent is often
required to select an alerting signal which renders only a
subset of the information in the Alert-Info header field(s) --
which is the resolution process for "alert" URNs.
The requirements for resolving "alert" URNs are given in section
11.1 of .Section 12 of gives a resolution
algorithm for selecting a signal which satisfies the
requirements of section 11.1. That algorithm can be used
regardless of the set of alerting signals that the user agent
provides and their specified meanings. The existence of this
algorithm demonstrates that
the resolution requirements can always be satisfied. However,
the algorithm is complex and slow.The purpose of this document is to describe an improved implementation,
a more efficient resolution algorithm
for selecting signals that conforms to the requirements of
section 11.1: Once the
user agent designer has chosen the set of signals that the user
agent produces and the "alert" URNs
that they express, a finite state
machine is constructed that selects alerting signals based on
the URNs in the Alert-Info header field(s) in a SIP message.
The
incoming "alert" URNs are preprocessed in a straightforward manner
into a sequence of "symbols" drawn from a fixed finite set,
which are then used as input to the
finite state machine. After processing the input, the state of the
finite state machine selects the correct alerting signal to
present to the user.Both the preprocessor and the finite state machine are determined
only by the selected set of signals and the set of "alert" URNs
expressed by the signals, so the processing machinery can be
fixed at the time of designing the user agent.The requirements for the resolution of
"alert" URNs are given in section 11.1 of
and can be described as follows:
The "alert" URNs are processed from left to right. Each
"alert" URN has precedence over all URNs that follow it, and its
interpretation is subordinate to all URNs that precede it.As each URN is processed, one of the UA's signals is chosen
which expresses that URN as far as can be done without reducing
the degree to which any of the preceding URNs were expressed by
the signal chosen for the preceding URN. Thus, as processing
proceeds, the chosen signals become increasingly specific and
contain more information, but all of the information about a
particular URN that is expressed by the signal chosen for that
URN is also expressed by the signals chosen for all following
URNs.If the entirety of the current URN cannot be expressed by any
allowed signal, then in turn, each of the trailing alert-ind-parts
(the sections separated by colons) is removed until the reduced
URN can be expressed by some signal which also
expresses at least the same reduced versions of the preceding URNs that
were expressed by the signal chosen for the preceding URN. This
can be described as "a signal that expresses as much of the
current URN as possible while still expressing as much of the
previous URNs as the preceding signal did".So, for instance, consider processing
If the UA has no signal for
urn:alert:category-a:part-a1:part-a2, it removes part-a2 from
the URN and
checks whether it has a signal for the less-specific URN
urn:alert:category-a:part-a1. If it has no signal for that URN,
it gives up on the URN entirely (since urn:alert:category-a
doesn't exist, and can be considered to express nothing about
the call), and the chosen signal is the default signal of the
UA, the signal that is used when there is no Alert-Info.But let us suppose the UA has a signal for
urn:alert:category-a:part-a1, and chooses that signal when
processing the first URN. All processing after this point will
be restricted to signals that express
urn:alert:category-a:part-a1, or a more specific URN of the
category category-a.The UA then goes on to examine the next URN,
urn:alert:category-b:part-b1:part-b2. If there is a signal that
expresses both urn:alert:category-a:part-a1 and
urn:alert:category-b:part-b1:part-b2, then the UA chooses that
signal. If there is no such signal, the second URN is reduced
to urn:alert:category-b:part-b1, and the UA checks for a signal
that expresses that URN along with urn:alert:category-a:part-a1.
If there is no such signal that matches that relaxed
requirement, the second URN is reduced to urn:alert:category-b,
which is discarded, and the chosen signal for the first URN is
chosen for the second URN. In any case, all processing after
this point will be restricted to signals that express
urn:alert:category-a:part-a1 or a more specific URN of the
category category-a, and also express the chosen part of
urn:alert:category-b:part-b1:part-b2.This process is continued until the last "alert" URN is
processed; the signal chosen for the last URN is the signal that
the UA uses.The purpose of this document is to describe a
resolution algorithm that conforms to section 11.1 of
but is simpler than the algorithm
described in section 12 of : Once the
user agent designer has chosen a set of signals and the URNs
that they express, a finite state
machine is constructed that selects alerting signals based on
the URNs in the Alert-Info header field(s) in a SIP message.
The designer selects the set of signals that the user agent
produces, matching each signal to the "alert" URN or the
combination of "alert" URNs which are the meaning carried by
the signal.Based on the user agent's signals and their meanings, the
designer constructs an "alphabet" containing a finite number
of symbols; each possible "alert" URN is mapped into
one particular symbol.The designer constructs a finite state machine (FSM)
whose input is the alphabet of symbols and whose states
describe the information extracted from the Alert-Info URNs.Each state of the FSM has an associated signal. Processing the
Alert-Info URNs will leave the FSM in some particular state;
the UA renders the signal that is attached to that final
state.To select a ring tone or ringback tone based on a SIP
message, the user agent processes the "alert" URNs in the
Alert-Info header field from left to right. Initially the FSM
is in a designated initial state. The user agent maps each
successive URN into the corresponding symbol, and then executes
the state transition of the FSM specified by the symbol. The
state of the FSM after processing the URNs determines which
signal the user agent will render to the user.Note that the user agent generally has two FSMs, because a
user agent usually wants to signal different information in ring
tones than it signals in ringback tones. One FSM is used to
select the ring tone to render for an incoming INVITE request.
The other FSM is used to select the ringback tone to render
based on an incoming provisional response to an outgoing INVITE
request. Both FSMs are constructed in the same way, but the
constructions are based on different lists of signals and
corresponding URNs.All of the steps of the method after the designer has
selected the signals and their URNs are algorithmic, and the
algorithm of those steps assures that the operation of the FSM
will satisfy the
constraints of section 11.1 of . A Python
implementation of the algorithmic steps is provided in
.In simple situations, a suitable FSM or equivalent ad-hoc
code can be constructed by hand using ad-hoc analysis.
Generally, this is only practical in situations
where a small number of alert categories and alert indications
are signaled and the categories interact in a simple, uniform way.
E.g., the examples in and could be constructed by ad-hoc analysis.
But automatic processing is valuable if the situation is too
complicated to construct a correct FSM
by ad-hoc analysis, or if the set of signals will change too
frequently for human production to be economical.The designer must select signals that the UA will generate
and define the meanings that the signals will have to the user.
Based on this, the designer determines for each signal the
"alert" URN or combination of "alert" URNs that indicate that
meaning in SIP messages, and consequently should elicit that
signal from the UA.For example, suppose the UA has a particular ring tone
for calls from an external source. A call from an external
source is marked with the URN urn:alert:source:external
(specified in section 9 of ). Thus, the
table of signals includes:
Similarly, if the UA has a particular ring tone for
calls from an internal source, the table includes:
If the UA has ring tones for calls that are marked as
having higher or lower priority, then the table includes:
Note that the UA must be able to signal for a message that has
no "alert" URNs in the Alert-Info header field, which means that
there must always be a default signal which has zero corresponding URNs:
A signal can be defined to indicate a combination of
conditions. For instance, a signal that is used only for
high-priority, internal-source calls expresses two URNs,
and will only be used when both URNs are present in
Alert-Info:
A signal can be defined to cover a number of
related conditions by specifying a URN that is the common
prefix of the URNs for the various conditions. For instance,
the URNs for "recall due to callback", "recall due to call
hold", and "recall due to transfer" all start with
urn:alert:service:recall, and so one signal can be provided for
all of them by:
But if a specific signal is also provided for "recall due to
callback" by this entry:
then if the message contains urn:alert:service:recall:callback,
the "recall due to callback" signal will be chosen instead of
"recall generally" because the UA chooses the signal that most
completely expresses the information in the Alert-Info header
field.The designer may wish to define extension URNs that provide
more specific information about a call than the standard "alert"
URNs do. One method is to add additional components to standard
URNs. For instance, an extra-high priority could be indicated
by the URN urn:alert:priority:high:extra-high@example. The
final "extra-high@example" is an "alert-ind-part" that is a
private extension. (See sections 7 and 10.2 of for a discussion of private extensions.) In any
case, adding an alert-ind-part to a URN makes its meaning more
specific, in that any call to which the longer URN can be
applied can also have the shorter URN applied. In this case,
"extra-high-priority calls" are considered a subset of
"high-priority calls".
Of course, for this extension to be useful, the senders of SIP
messages (e.g., other UAs) must generate the extension URN in
suitable circumstances.
In some circumstances, the designer may want to create an
entirely new category of "alert" URNs to indicate a type of
information that
is not indicated by any standard category of URNs. In that case,
the designer uses a private extension as the alert-category (the
third component of the URN), combined with whatever
alert-ind-part (fourth component) values are desired. For
example, a simplified version of the U.S. military security designations
could be:
The designer should ensure that the new alert-category is
orthogonal to all defined standard alert-categories, in that any
combination of one of the new URNs with one of the standard URNs
is meaningful in that there could be a message carrying both URNs.In addition, the set of alert-ind-parts for the new
alert-category should be comprehensive and disjoint, in that
every message can be described by exactly one of them.In this section, we will discuss various considerations which
arise when processing Alert-Info. These have to be taken care
of properly in order to conform to the standards, as well as to
endure a good user experience. But since they are largely
independent of the generated finite state machine and its
processing, they are gathered here in a separate section.The UA may have a number of different finite state machines
(FSMs) for processing URNs. Generally, there will be different
FSMs for processing Alert-Info in incoming INVITE requests and
for incoming provisional responses to outgoing INVITE requests.
But any situation that changes the set of signals that the UA is
willing to generate specifies a different set of signals and
corresponding URNs, and thus generates a different FSM. 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.Similarly, if the set of signals is customized by user action
or local policy, the generated FSM must be updated. This can be
done by regenerating it according to the method described here,
or by generating a "generic" FSM and instantiating it based on
the available signals. (See for a
discussion of this.)Note that the values in an Alert-Info header field are
allowed to be URIs of any scheme, and within the "urn" scheme,
are allowed to have any namespace . The
processing of URIs that are not "alert" URNs is not considered
by this document, nor is that processing specified by . But the algorithm designer must consider
what to do with such URIs if they are encountered. The simplest
choice is to ignore them. Alternatively, the algorithm may
examine the URI to determine if it names an alerting signal or
describes how to retrieve an alerting signal, and if so, choose
to render that signal, rather than processing the "alert" URNs
to select a signal. In any case, the remainder of this document
assumes that the signal is to be chosen based on the "alert"
URNs in Alert-Info, and that all Alert-Info URIs that are not
"alert" URNs have been removed.The UA may also receive "alert" URNs that are semantically
invalid in various ways. E.g., the URN may have only three
components, despite that all valid "alert" URNs have at least
one alert-ind-part, and thus four components. The only useful
strategy is to ignore such URNs (and possibly log them for
analysis).The method described here is robust in its handling of
categories and alert-ind-parts which are unknown to the UA, and
as a consequence, it is also robust if they are not valid
standardized URNs.
Thus, these error conditions need not be handled specially.Constructing the FSM involves:
Listing the URNs which are expressed by the various signals
of the user agent.From the expressed URNs, constructing the finite alphabet
of symbols into which input URNs are mapped and which drive
the state transitions of the FSM.Constructing the states of the FSM and the transitions
between them.Selecting a signal to be associated with each FSM state.We will explain the process using a very simple example in
which there are two signals, one expressing "internal source"
and one expressing "external source", along with a default
signal (for when there is no source information to signal). The
"internal source" signal expresses urn:alert:source:internal,
and the "external source" signal expresses
urn:alert:source:external.The first step is to establish for
each of the user agent's signals what call characteristics it
represents, which is to say, the set of "alert" URNs which are
its information content.
From the totality of these expressed
URNs, the designer can then determine which sets of URNs must be
distinguished from each other.
In our simple example, the expressed URNs are:
In order to reduce the infinite set of possible "alert" URNs
to a finite alphabet of input symbols which cause the FSM's
transitions, the designer must partition the "alert" URNs into a
finite set of categories.Once we've listed all the expressed URNs, we can list all of the
alert-categories that
are relevant to the user agent's signaling; "alert" URNs in any other
alert-category cannot affect the signaling and can be ignored.
(The easiest method
to ignore the non-relevant URNs is to skip over them during
Alert-Info processing.
A more formal method is to map all of them into one "Other"
symbol, and then for each state of the FSM, have the Other
symbol transition to that same state.)Within each relevant alert-category, we now define a
distinct symbol
for every expressed URN and for all of their "ancestor" URNs
(those that can be created by removing one or more trailing
alert-ind-parts). In order to name the symbols in a way that
distinguishes them from the corresponding URNs, we remove the
initial "urn:alert:" and capitalize each alert-ind-part. Thus
in our example, we get these symbols:
Note that there is a "Source" symbol even though there is no
corresponding URN. (urn:alert:source is not a valid URN -- see
section 7 -- although the
processing algorithm must be prepared to screen out such a
purported URN if it appears in the Alert-Info header field.)
However, its existence as a symbol will be useful later when we
construct the FSM.For each of these symbols, we add a symbol that classifies
URNs that extend the symbol's corresponding URN
with alert-ind-parts that cannot be expressed by signals:
The latter two classify URNs like
urn:alert:source:external:foo@example, which extend URNs
that we already have symbols for. The first is for classifying
URNs, such as urn:alert:source:bar@example, which have
first alert-ind-parts that contradict all the "source" URNs that
the user agent can signal.These steps give us this set of symbols:
We can then simplify the set of symbols by removing the ones
like Source:External:Other and Source:Internal:Other that
consist of adding "Other" to a symbol which corresponds to an
expressed URN which is not ancestral to any other expressed
URNs. This works because adding further alert-ind-parts to a
URN which is a leaf in regard to the set of signals has no
additional effect. In this example,
urn:alert:source:external:foo@example has the same effect as
urn:alert:source:external, both for causing a signal to be
chosen as well as for suppressing the effect of later URNs.This leaves the following symbols for the "source" category:
These can be visually summarized by showing the infinite tree of
possible source "alert" URNs and how it is partitioned into
subtrees that map to each of these symbols. We also mark with
"*" the expressed URNs.
The user agent processes the Alert-Info URNs left-to-right
using a finite state machine (FSM), with each successive URN
causing the FSM to transition to a new state. Each state of
the FSM records the information which has so far been
extracted from the URNs. The state of the FSM after
processing all the URNs determines which signal the user agent
will render to the user.We label each state with a set of symbols, one from each
relevant category, which describe the information that's been
extracted from all of the URNs that have so far been
processed. The initial state is labeled with the "null"
symbols that are just the category names, because no
information has yet been recorded. In our simple example, the
initial state is labeled "Source", since that's the only
relevant category.Each state has a corresponding alerting signal, which is
the signal that the user agent will produce when URN
processing leaves the FSM in that state. The signal is the
one that best expresses the information that has been
extracted from the URNs. Usually the choice of signal is
obvious to the designer, but there are certain constraints
that the choice must satisfy. The main constraint is that the
signal's expressed URNs must be semantic supersets of (i.e., identical to
or a prefix of) the URNs corresponding to the symbols in the
state's label. In particular, if the expressed URN of the signal in
a certain category is shorter than the state's label, we show
that in the state's name by putting parentheses around the
trailing part of the symbol that is not expressed by the
signal. For instance, if the symbol in
the label is "Source:External" but the signal only expresses
"Source" (i.e., no "source" URN at all), then the symbol in the
label is modified to be "Source:(External)".The reason for this unintuitive construction is that in some
states, the FSM has recorded information that the chosen
signal cannot express.Note that the parentheses are part of the state name, so in
some circumstances there may be two or more distinct states
labeled with the same symbols, but with different placement of
parentheses within the symbols. These similar state names are
relevant when the FSM can record information from multiple
"alert" URNs but cannot express all of them -- depending on
the order in which the URNs appear, the UA may have to render
different signals, so it needs states that record the same
information but render different subsets of that information.The initial state's label is the string of null symbols for the
relevant categories, so the only allowed signal is the default
signal, which expresses no URNs:From each state, we must construct the transition for each
possible input symbol. For a particular state and symbol, we
construct the label of the destination state by combining the
input symbol with the symbol in the start state's label for
the same category. If one of the symbols is a prefix of the
other, we select the longer one; if not, we select the symbol in
the start state's label.Thus, in our simple example, the initial state has the
following transitions:
In all of these transitions, the input symbol is compatible
with the matching label of the state, "Source", so the
destination state's label is the full input symbol.However, there is a further constraint on the destination
state: Its signal must express URNs that at least contain the
expressed URNs of the signal of the start state. Within that
constraint, and being compatible with the destination state's
label, for the category of the input URN,
the destination state's signal must express the
longest URN that can be expressed by any signal.In our example, this means that the destination
Source:External state has the "external source" signal, which
expresses urn:alert:source:external. Since that signal
expresses all of the state's label, it is the chosen state.
Similarly, the destination Source:Internal state has the
"internal source" signal. But for the transition on input
Source:Other, the "Source:Other" state must have the default
signal, as there is no signal that expresses
urn:alert:source:[some-unknown-alert-ind-part].
So the destination state is
"Source:(Other)", where the parentheses record that the
"Other" part of the label is not expressed by the state's signal.Thus, the initial state and the states it can transition to
are:
Looking at the state Source:External, we see that it is
incompatible with all input symbols other than
Source:External, and thus all of its transitions are to itself:
and similarly:
The FSM can be constructed by processing the file
"very-simple.txt" with the program "alert-info-fsm.py" in
. The program's output shows the stages
of the construction, which are:
The signals have the meanings:
The expressed URNs are
The relevant categories of "alert" URNs are only:
Thus, the infinite universe of possible "alert" URNs can be
reduced to these symbols, which are the categories of URNs
that are different in ways that are significant to the
resolution process:
The FSM is:
Each state is labeled by a set of symbols which describe the
information which has been extracted from the URNs so far.Each state has a signal which is a semantic superset of the
state's label, i.e., the signal's expressed URNs match the
initial portion of the label symbols. If Alert-Info
processing finishes with the FSM
in a state, the user agent will render the state's signal to the
user.The state's label is marked to show what subset of the
symbols are expressed by the state's signal.
Two states can have the same label but different signals.If a transition's input symbol is compatible with (is a
semantic subset) of the start state's label for that category,
the destination
state's label is updated with the input symbol. If not, the destination
state is the start state. This is how the state's label
records what information has been accumulated while processing
the Alert-Info URNs.A transition's destination state has a signal which
semantically subsets the start state's signal as much as
possible in the category of the input symbol. (In most
cases, the choice of signal is unique. In rare cases there may be
more than one signal that meets this criterion, so the designer
may have some flexibility.)In the trivial case where the user agent receives no Alert-Info URNs,
then processing begins and ends with the FSM in the initial
state and selects the default signal.If the user agent receives
then processing progresses:
If the user agent receives
then processing progresses:
If the user agent receives
then processing progresses:
If the user agent receives
then processing progresses:
Now consider an example where the user agent can signal "external
source", "internal source", "low priority", and "high priority"
individually or in any combination of source and priority, along
with a default signal. This example is essentially the
cartesian product of two copies of the example in , one dealing with the call's source and one dealing with
the call's priority. So there is a total of 9 signals:
The expressed URNs are:
The relevant categories of "alert" URNs are only:
The alphabet of symbols is:
The 16 states are as follows, where 10 states have a simple
structure because from them, no further information can be recorded.
An example of processing that involves multiple "source" URNs and
one "priority" URN:
A more complicated example is in section 12.2.1 of
. It is like the example in
of this document, except
that the user agent can only signal "external
source", "internal source", "low priority", and "high priority"
individually but not in combination, as well as a default
signal:
The signals can express the following URNs:
The relevant categories of "alert" URNs are:
The alphabet of symbols is:
In this example, the FSM has 20 states because both "source"
and "priority" URNs are recorded, but the order in which the two
appear affects the signal:
State Priority:(Other)/Source can transition to states that can
signal source, because the recorded priority can't be signaled
and thus does not block the signaling of the source:
Because there are no signals for combinations of "source" and
"priority" URNs, processing a "source" URN from the state
Priority:High/Source leads to a state that records the
priority information, but does not signal it:
From the state Priority:High/Source, "source" URNs transition to
states that record both source and priority but signal only
priority, one of which is Priority:High/Source:(External).
But from Priority/Source:External, the symbol Priority:High
transitions to the state Priority:(High)/Source:External, which
records the same information but signals the source, not the
priority. -- One state is reached by processing
a "priority" URN and then a "source" URN, whereas the other is
reached by processing a "source" URN and then a "priority" URN.
And similarly for Priority:Low/Source:
As an example of processing, if the user agent receives
then processing progresses:
A more complicated example involves multiple "source" URNs
which do not select a non-default signal and one "priority" URN
which can be signaled:
Since the only characteristic of a state that affects the
output of the FSM is the state's signal, several groups of
states in this FSM can be merged using standard FSM optimization
algorithms:
This reduces the FSM to 7 states.
Examples 2, 3, and 4 of are similar to the
example in , but they do not
include a signal for the combination "internal source, low
priority" to make resolution examples work asymmetrically.The FSM for this example has the same alphabet as the FSM of
. Most of the states of this
FSM are the same as the states of the FSM of
, but the state
Source:Internal/Priority:Low is missing because there is no
signal for that combination. It is replaced by two states: One
state is Source:Internal/Priority:(Low); it records that
Source:Internal was specified first (and is to be signaled)
and that Priority:Low was specified later (and can not be
signaled -- but it still prevents any further "priority" URN
from having an effect). The other state is
Source:(Internal)/Priority:Low; it records the reverse
sequence of events.The changes in the FSM are:
An example of processing that involves multiple "source" URNs and
one "priority" URN:
If the user agent receives
If the user agent receives
Suppose the same user agent receives
Note that there is no signal that corresponds to this
combination. In that case, the processing is:
If the order of the URNs is reversed, what is signaled is
the meaning of now-different first URN:
Notice that the existence of the new states prevents later
URNs of a category from overriding earlier URNs of
that category, even if the earlier one was not itself
signalable and the later one would be signalable in the absence
of the earlier one:
This situation shows the necessity of states whose labels
contain parentheses. If the second transition
had been to the state Priority:Low/Source (on the basis that
there is no proper state Priority:Low/Source:Internal), then
the third transition would have been to the state
Priority:Low/Source:External, and the signal would have been
"external source/low priority".In the example of , there are signals for
"external source" and "internal source". Let us add to that
example a signal for "source
internal from a VIP". That last signal expresses the private
extension URN urn:alert:source:internal:vip@example, which is a subset
of urn:alert:source:internal, which is expressed by the "source
internal" signal. There is a total of 3 expressed URNs, one of
which is a subset of another:
This generates the following alphabet of symbols, which includes
two Other symbols for the category source:
In this example there are signals for "service forward" (the
call has been forwarded) and "source recall callback" (a recall
due to a callback). This gives 2 expressed URNs:
This generates the following alphabet of symbols. Note that
there are two "Other" symbols, because the "alert:service" URNs
have an additional level of qualification.
In this example, we consider how a UA generates ringback
signals when the UA wishes to reproduce the traditional behavior
that the caller hears the ringback signals defined by the
telephone service in the callee's country, rather than the
ringback signals defined by the service in the caller's
country. In the Alert-Info header field of the 180 Ringing provisional
response, we assume that the called UA provides an
"alert:country" URN containing the ISO 3166-1 alpha-2 country
code of the callee's country.The UA has a default signal and a "non-country" signal for
urn:alert:service:call-waiting. For the example country with
code "XA", the UA has a default signal and signals for
urn:alert:service:call-waiting and urn:alert:service:forward.
For the example country with code "XB", the UA has a default
signal and a signal for urn:alert:service:forward. These
inconsistencies between the non-country signals and the country
signals are chosen to demonstrate the flexibility of the
construction method, showing that three systems of signals can
be combined correctly even when the systems were established
without coordination between them.The signals are:
The expressed URNs are:
The relevant categories of "alert" URNs are only:
The alphabet of symbols is:
The 15 states are as follows:
Call-waiting can be signaled in conjunction with country XA,
but not in conjunction with country XB as the UA does not have
a signal to present
call waiting alerts for country XB. Thus the ordering of
urn:alert:service:call-waiting with urn:alert:country:xa does
not matter, but if urn:alert:country:xb appears before
urn:alert:service:call-waiting, call-waiting cannot be
signaled. On the other hand, if urn:alert:service:call-waiting
appears before urn:alert:country:xb, then call-waiting is
signaled, but using the non-country signal.
The specifications in are oriented
toward giving the sender of Alert-Info control over which of the
"alert" URNs are most important. But in some situations, the
user agent may prefer to prioritize expressing one URN category over
another regardless of the order their URNs appear in Alert-Info.
This section describes how that can be accommodated
within the framework of , and presents
an example FSM resulting from that approach.This example uses the signals of ,
viz., "external source", "internal source", "low priority" and
"high priority", but this time, we want to signal "high
priority" in preference to any other signal that might be
applicable.We accommodate this within the framework of by
assigning the signal "high priority" for each of these
combinations of URNs:
The result is that the "high priority" signal is the "best" signal for
any combination of urn:alert:priority:high with "source" URNs.The intermediate steps of the method produce the same results
as before. The signals can express the following URNs:
The relevant categories of "alert" URNs are:
The alphabet of symbols is:
When the FSM is constructed, it is the same as the FSM
for , except that
certain states are effectively renamed and merged, because any
"source" is defined to be expressed if high priority is expressed:
This reduces the FSM to 18 states. In addition, these two new states,
along with a number of other states, can be merged by
FSM optimization, since all of them have the signal "high
priority" and from them, there are no transitions to states
outside this set. The final FSM has 10 states.
This section discusses how to construct FSMs for a user agent
that allows variable sets of signals, for example, if the user can
configure the use of ringtones. Several approaches can be used:
Whenever the set of ringtones is changed, re-execute the
processes of .Whenever the set of ringtones is changed, rebuild the list
of expressed URNs () and reconstruct
the alphabet of symbols (). Then use
an algorithm for dynamically constructing states of the FSM as
they are needed during Alert-Info processing.If the sets of possible URNs expressed by the ringtones is
sufficiently limited, the steps of can be
carried out "generically", and the generic FSM can be specialized
for the current ringtone configuration.The remainder of this section gives an example of the third
approach.For the example, we will use a set of ringtones that express
the identify of the caller. To signal this information, a
private extension "alert" URN category is used, "caller@example":
which we can express by the generic pattern
where "IDENTITY" is replaced in succession by the set of caller
identities that have
their own ringtones to generate the set of expressed URNs.The alphabet is then:
where "IDENTITY" is replaced in succession by the set of caller
identities. The "Caller@example:Other" symbol includes all URNs
of the category "caller@example" that are not included in any of
the other symbols.The states and transitions of the FSM are:
where again, the second state is replicated once for each caller
identity that has a ringtone, with "IDENTITY" replaced with the
caller identity.[Note to RFC Editor: Please remove this entire section upon
publication as an RFC.]Correct the discussion in the example of .Revamp the introduction.Use the term "resolve" for processing "alert" URNs to
select a signal.Editorial improvements from independent submission reviewer.Editorial improvements from independent submission reviewer.Add note at end of introduction that you can do this by
hand in simple cases.Add the country-code example.Editorial improvements.Editorial improvements.Correct indenting of some lines.Recast exposition to feature the implementation of the
construction algorithm.Reorganized the text, including describing how the FSM
states are constructed.draft-worley-alert-info-fsm.auxAriadne Internet ServicesThanks to Paul Kyzivat, whose relentless identification of the
weaknesses of earlier versions made the final document much, much
better than it would have been, by changing it from the exposition
of a concept into a practical tool. Thanks to Rifaat
Shekh-Yusef, Eric Burger, and Gonzalo Camarillo for their
thorough reviews. Thanks to the Independent Submissions Editor,
Nevil Brownlee, for his work obtaining reviewers.