Simpler
Algorithms for Processing 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. Based on the URNs in the
Alert-Info header field, the user agent must select an 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, constructing 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 and faster than
the previously described selection algorithm.A SIP user agent server determines 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 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 a signal. This usage has security problems
and is inconvenient to implement in practice. introduced an alternative practice: The
values could 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.However, a user agent is unlikely to provide alerting
signals that can render more than a small subset of the possible
combinations of "alert" URNs, so the user agent is frequently
required to select one alerting signal which renders only a
subset of the information in the Alert-Info header field(s).
The requirements for the process of selecting an alerting signal
based on "alert" URNs are given in section 11.1 of .Section 12 of gives one possible
algorithm for selecting a signal which satisfies section 11.1.
This algorithm can be used regardless of the set of alerting signals that
the user agent provides and their specified meanings. This
demonstrates that the rules can always be satisfied. However,
the algorithm is complex and slow.The purpose of this document is to describe an easier method
for user agent designers to construct an algorithm for selecting
alerting signals based on the Alert-Info header fields in a SIP
message. 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 maps into exactly one symbola finite state machine (FSM) whose input is the alphabet of
symbols and whose states describe information extracted from
the Alert-Info URNsa signal for each state of the FSM, which is the signal
that that the user agent will present if processing the
Alert-Info URNs leaves the FSM in that stateNote that the user agent has two FSMs. One FSM is used to
select the ring tone to present for an incoming INVITE request.
The other FSM is used to select the ringback tone to present
based on an incoming provisional response to an outgoing INVITE
request.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 present to
the user.If the FSM is correctly constructed by the designer, the
constraints of section 11.1 will be satisfied.Note that the values in an Alert-Info header field are
allowed to be URIs of any schema, and within the "urn" schema,
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 all Alert-Info URIs
that are not "alert" URNs have been removed.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 achieve is to skip over them during Alert-Info processing. A
more formal method is to map all of these URNs into one "Other"
symbol, and then for each state of the FSM, have the Other
symbol transition to that 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 existance 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:
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
alert-ind-parts that contradict all the "source" URNs that
the user agent can signal.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
URN.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 the tree is partitioned into
subtrees that map to each of these symbols. We also mark with
"*" the symbols that correspond to 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 describes 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 present 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)". 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.The initial state's label is the 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:
To summarize the steps of the method:
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 present 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, and the marking
is part of the state's name -- 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, the destination
state's label is 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
, 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:
Because there are no signals for combinations of "source" and
"priority" URNs, processing a "priority" URN from the state
Source:External/Priority leads to a state that records the
priority information, but does not signal it:
And similarly for Source:Internal/Priority:
On the other hand, state Source:(Other)/Priority can transition
to states that can signal priority:
From the state Source/Priority:High, "source" URNs transition to
states that record both source and priority but signal only
priority. Thus, we can get two states,
Source:(External)/Priority:High and
Source:External/Priority:(High) that record the same information
but have different signals -- 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.
Similarly for Source/Priority:Low:
However, the state Source/Priority:(Other) behaves as it does in
:
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 12 states.
Example 2 of is similar to the
example in , but it does not
include a signal for the combination "internal source, low
priority" to make resolution examples work inconsistently.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
still the 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:
whereas if the second transition
had been to the state Source/Priority:Low (on the basis that
there is no proper state Source:Internal/Priority:Low), then
the third transition would have been to the state
Source:External/Priority:Low, and the signal would have been
"external source/low priority".In the 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:source:internal:vip@example, which is a subset
of urn: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:
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:
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 may prefer to prioritize expressing one URN category over
another regardless of the order the URNs appear in Alert-Info.
This section describes how that can be accommodated
within the framework of , and presents the FSM
that this method generates.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 optimal 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 the states Source/Priority:High and
Source:(Other)/Priority:High, 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. We name this merged state
Source:*/Priority:High.The final FSM has 15 states. The changes from the FSM
of are marked with change bars.
This section discusses how to construct FSMs for user agent
that allows the user to configure the use of ringtones. Several
approaches can be used:
Whenever the set of ringtones is changed, re-execute the
processes listed in .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 in Alert-Info processing.If the set of possible URNs expressed by the ringtones is
sufficiently limited, the steps of can be
carried 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.