5.  Further Examples

5.1.  Example with "source" and "priority" URNs

   Now consider an example where the UA 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 Section 4: one dealing with the call's
   source and one dealing with the call's priority.  So there are a
   total of 9 signals:

       Signal                          URN(s)
       ----------------------------    -------------------------------
       default                         (none)
       external source                 urn:alert:source:external
       internal source                 urn:alert:source:internal
       low priority                    urn:alert:priority:low
       low priority/external source    urn:alert:priority:low,
                                           urn:alert:source:external
       low priority/internal source    urn:alert:priority:low,
                                           urn:alert:source:internal
       high priority                   urn:alert:priority:high
       high priority/external source   urn:alert:priority:high,
                                           urn:alert:source:external
       high priority/internal source   urn:alert:priority:high,
                                           urn:alert:source:internal

   The expressed URNs are:

       urn:alert:source:external
       urn:alert:source:internal
       urn:alert:priority:low
       urn:alert:priority:high

   The relevant categories of "alert" URNs are only:

       source
       priority

   The alphabet of symbols is:

       Source
       Source:External
       Source:Internal
       Source:Other
       Priority
       Priority:Low
       Priority:High
       Priority:Other

   The 16 states are as follows, where 9 states are "sink" states from
   which no further information can be recorded, as all transitions from
   the state lead to itself.

       State: Priority/Source
       Signal: default
       Transitions:
           Priority:Other -> Priority:(Other)/Source
           Priority:High -> Priority:High/Source
           Priority:Low -> Priority:Low/Source
           Source:Other -> Priority/Source:(Other)
           Source:External -> Priority/Source:External
           Source:Internal -> Priority/Source:Internal

       State: Priority:(Other)/Source
       Signal: default
       Transitions:
           Priority:Other -> Priority:(Other)/Source
           Priority:High -> Priority:(Other)/Source
           Priority:Low -> Priority:(Other)/Source
           Source:Other -> Priority:(Other)/Source:(Other)
           Source:External -> Priority:(Other)/Source:External
           Source:Internal -> Priority:(Other)/Source:Internal

       State: Priority:(Other)/Source:(Other)
       Signal: default
       Transitions:
           any -> Priority:(Other)/Source:(Other)

       State: Priority:(Other)/Source:External
       Signal: external source
       Transitions:
           any -> Priority:(Other)/Source:External

       State: Priority:(Other)/Source:Internal
       Signal: internal source
       Transitions:
           any -> Priority:(Other)/Source:Internal

       State: Priority:High/Source
       Signal: high priority
       Transitions:
           Priority:Other -> Priority:High/Source
           Priority:High -> Priority:High/Source
           Priority:Low -> Priority:High/Source
           Source:Other -> Priority:High/Source:(Other)
           Source:External -> Priority:High/Source:External
           Source:Internal -> Priority:High/Source:Internal

       State: Priority:High/Source:(Other)
       Signal: high priority
       Transitions:
           any -> Priority:High/Source:(Other)

       State: Priority:High/Source:External
       Signal: high priority/external source
       Transitions:
           any -> Priority:High/Source:External

       State: Priority:High/Source:Internal
       Signal: high priority/internal source
       Transitions:
           any -> Priority:High/Source:Internal

       State: Priority:Low/Source
       Signal: low priority
       Transitions:
           Priority:Other -> Priority:Low/Source
           Priority:High -> Priority:Low/Source
           Priority:Low -> Priority:Low/Source
           Source:Other -> Priority:Low/Source:(Other)
           Source:External -> Priority:Low/Source:External
           Source:Internal -> Priority:Low/Source:Internal

       State: Priority:Low/Source:(Other)
       Signal: low priority
       Transitions:
           any -> Priority:Low/Source:(Other)

       State: Priority:Low/Source:External
       Signal: low priority/external source
       Transitions:
           any -> Priority:Low/Source:External

       State: Priority:Low/Source:Internal
       Signal: low priority/internal source
       Transitions:
           any -> Priority:Low/Source:Internal

       State: Priority/Source:(Other)
       Signal: default
       Transitions:
           Priority:Other -> Priority:(Other)/Source:(Other)
           Priority:High -> Priority:High/Source:(Other)
           Priority:Low -> Priority:Low/Source:(Other)
           Source:Other -> Priority/Source:(Other)
           Source:External -> Priority/Source:(Other)
           Source:Internal -> Priority/Source:(Other)

       State: Priority/Source:External
       Signal: external source
       Transitions:
           Priority:Other -> Priority:(Other)/Source:External
           Priority:High -> Priority:High/Source:External
           Priority:Low -> Priority:Low/Source:External
           Source:Other -> Priority/Source:External
           Source:External -> Priority/Source:External
           Source:Internal -> Priority/Source:External

       State: Priority/Source:Internal
       Signal: internal source
       Transitions:
           Priority:Other -> Priority:(Other)/Source:Internal
           Priority:High -> Priority:High/Source:Internal
           Priority:Low -> Priority:Low/Source:Internal
           Source:Other -> Priority/Source:Internal
           Source:External -> Priority/Source:Internal
           Source:Internal -> Priority/Source:Internal

   An example of processing that involves multiple "source" URNs and one
   "priority" URN:

       Alert-Info: <urn:alert:source:internal>,
           <urn:alert:source:unclassified>,
           <urn:alert:priority:high>

   in which case processing progresses:

       State: Source/Priority
           Process: Source:Internal (urn:alert:source:internal)
       State: Source:Internal/Priority
           Process: Source:(Other) (urn:alert:source:unclassified)
       State: Source:Internal/Priority
           Process: Priority:High (urn:alert:priority:high)
       State: Source:Internal/Priority:High
       Signal: internal source/high priority

5.2.  Example 1 of RFC 7462

   A more complicated example is provided in Section 12.2.1 of
   [RFC7462].  It is like the example in Section 5.1 of this document,
   except that the UA can only signal "external source", "internal
   source", "low priority", and "high priority" individually but not in
   combination, as well as a default signal:

       Signal                          URN(s)
       ----------------------------    -------------------------------
       default                         (none)
       internal source                 urn:alert:source:external
       external source                 urn:alert:source:internal
       low priority                    urn:alert:priority:low
       high priority                   urn:alert:priority:high

   The signals can express the following URNs:

       urn:alert:source:external
       urn:alert:source:internal
       urn:alert:priority:low
       urn:alert:priority:high

   The relevant categories of "alert" URNs are:

       source
       priority

   The alphabet of symbols is:

       Source
       Source:External
       Source:Internal
       Source:Other
       Priority
       Priority:Low
       Priority:High
       Priority:Other

   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/Source
       Signal: default
       Transitions:
           Priority:Other -> Priority:(Other)/Source
           Priority:High -> Priority:High/Source
           Priority:Low -> Priority:Low/Source
           Source:Other -> Priority/Source:(Other)
           Source:External -> Priority/Source:External
           Source:Internal -> Priority/Source:Internal

   State Priority:(Other)/Source can transition to states that can
   signal the source, because the recorded priority can't be signaled
   and thus does not block the signaling of the source:

       State: Priority:(Other)/Source
       Signal: default
       Transitions:
           Priority:Other -> Priority:(Other)/Source
           Priority:High -> Priority:(Other)/Source
           Priority:Low -> Priority:(Other)/Source
           Source:Other -> Priority:(Other)/Source:(Other)
           Source:External -> Priority:(Other)/Source:External
           Source:Internal -> Priority:(Other)/Source:Internal

       State: Priority:(Other)/Source:(Other)
       Signal: default
       Transitions:
           any -> Priority:(Other)/Source:(Other)

       State: Priority:(Other)/Source:External
       Signal: external source
       Transitions:
           any -> Priority:(Other)/Source:External

       State: Priority:(Other)/Source:Internal
       Signal: internal source
       Transitions:
           any -> Priority:(Other)/Source:Internal

   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:

       State: Priority:High/Source
       Signal: high priority
       Transitions:
           Priority:Other -> Priority:High/Source
           Priority:High -> Priority:High/Source
           Priority:Low -> Priority:High/Source
           Source:Other -> Priority:High/Source:(Other)
           Source:External -> Priority:High/Source:(External)
           Source:Internal -> Priority:High/Source:(Internal)

       State: Priority:High/Source:(Other)
       Signal: high priority
       Transitions:
           any -> Priority:High/Source:(Other)

   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.

       State: Priority:High/Source:(External)
       Signal: high priority
       Transitions:
           any -> Priority:High/Source:(External)

       State: Priority:High/Source:(Internal)
       Signal: high priority
       Transitions:
           any -> Priority:High/Source:(Internal)

   and similarly for Priority:Low/Source:

       State: Priority:Low/Source
       Signal: low priority
       Transitions:
           Priority:Other -> Priority:Low/Source
           Priority:High -> Priority:Low/Source
           Priority:Low -> Priority:Low/Source
           Source:Other -> Priority:Low/Source:(Other)
           Source:External -> Priority:Low/Source:(External)
           Source:Internal -> Priority:Low/Source:(Internal)

       State: Priority:Low/Source:(Other)
       Signal: low priority
       Transitions:
           any -> Priority:Low/Source:(Other)

       State: Priority:Low/Source:(External)
       Signal: low priority
       Transitions:
           any -> Priority:Low/Source:(External)

       State: Priority:Low/Source:(Internal)
       Signal: low priority
       Transitions:
           any -> Priority:Low/Source:(Internal)

       State: Priority/Source:(Other)
       Signal: default
       Transitions:
           Priority:Other -> Priority:(Other)/Source:(Other)
           Priority:High -> Priority:High/Source:(Other)
           Priority:Low -> Priority:Low/Source:(Other)
           Source:Other -> Priority/Source:(Other)
           Source:External -> Priority/Source:(Other)
           Source:Internal -> Priority/Source:(Other)

       State: Priority/Source:External
       Signal: external source
       Transitions:
           Priority:Other -> Priority:(Other)/Source:External
           Priority:High -> Priority:(High)/Source:External
           Priority:Low -> Priority:(Low)/Source:External
           Source:Other -> Priority/Source:External
           Source:External -> Priority/Source:External
           Source:Internal -> Priority/Source:External

       State: Priority:(High)/Source:External
       Signal: external source
       Transitions:
           any -> Priority:(High)/Source:External

       State: Priority:(Low)/Source:External
       Signal: external source
       Transitions:
           any -> Priority:(Low)/Source:External

       State: Priority/Source:Internal
       Signal: internal source
       Transitions:
           Priority:Other -> Priority:(Other)/Source:Internal
           Priority:High -> Priority:(High)/Source:Internal
           Priority:Low -> Priority:(Low)/Source:Internal
           Source:Other -> Priority/Source:Internal
           Source:External -> Priority/Source:Internal
           Source:Internal -> Priority/Source:Internal

       State: Priority:(High)/Source:Internal
       Signal: internal source
       Transitions:
           any -> Priority:(High)/Source:Internal

       State: Priority:(Low)/Source:Internal
       Signal: internal source
       Transitions:
           any -> Priority:(Low)/Source:Internal

   As an example of processing, if the UA receives

       Alert-Info: <urn:alert:source:internal>

   then processing progresses:

       State: Priority/Source
           Process: Source:Internal (urn:alert:source:internal)
       State: Priority/Source:Internal
       Signal: internal source

   A more complicated example involves multiple "source" URNs that do
   not select a non-default signal and one "priority" URN that can be
   signaled:

       Alert-Info: <urn:alert:source:unclassified>,
           <urn:alert:source:internal>,
           <urn:alert:priority:high>

   in which case processing progresses:

       State: Priority/Source
           Process: Source:Other (urn:alert:source:unclassified)
       State: Priority/Source:(Other)
           Process: Source:Internal (urn:alert:source:internal)
       State: Priority/Source:(Other)
           Process: Priority:High (urn:alert:priority:high)
       State: Priority:High/Source:(Other)
       Signal: high priority

   The only output of the FSM is the state's signal.  Based on this,
   several groups of states in this FSM can be merged using standard FSM
   optimization algorithms:

       states with signal "high priority":
           Priority:High/Source
           Priority:High/Source:(Other)
           Priority:High/Source:(External)
           Priority:High/Source:(Internal)

       states with signal "low priority":
           Priority:Low/Source
           Priority:Low/Source:(Other)
           Priority:Low/Source:(External)
           Priority:Low/Source:(Internal)

       states with signal "external source":
           Priority/Source:External
           Priority:(High)/Source:External
           Priority:(Low)/Source:External
           Priority:(Other)/Source:External

       states with signal "internal source":
           Priority/Source:Internal
           Priority:(High)/Source:Internal
           Priority:(Low)/Source:Internal
           Priority:(Other)/Source:Internal

   This reduces the FSM to eight states:

       Priority/Source
       Priority:(Other)/Source
       Priority:(Other)/Source:(Other)
       Priority:High/Source  [aggregated]
       Priority:Low/Source  [aggregated]
       Priority/Source:(Other)
       Priority/Source:External  [aggregated]
       Priority/Source:Internal  [aggregated]

5.3.  Examples 2, 3, and 4 of RFC 7462

   Examples 2, 3, and 4 of [RFC7462] are similar to the example in
   Section 5.1 of this document, 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
   Section 5.1.  Most of the states of this FSM are the same as the
   states of the FSM of Section 5.1, but the state
   Source:Internal/Priority:Low is missing because there is no signal
   for that combination.  It is replaced by two states:

   1.  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 cannot be signaled --
       but it still prevents any further "priority" URNs from having an
       effect).

   2.  The other state is Source:(Internal)/Priority:Low; it records the
       reverse sequence of events.

   The changes in the FSM are:

       State: Priority:Low/Source
       Signal: low priority
       Transitions:
           Source:Internal -> Priority:Low/Source:(Internal)
           (other transitions unchanged)

       State: Priority:Low/Source:(Internal)
       Signal: low priority
       Transitions:
           any -> Priority:Low/Source:(Internal)

       State: Priority/Source:Internal
       Signal: internal source
       Transitions:
           Priority:Low -> Priority:(Low)/Source:Internal
           (other transitions unchanged)

       State: Priority:(Low)/Source:Internal
       Signal: internal source
       Transitions:
           any -> Priority:(Low)/Source:Internal

   An example of processing that involves multiple "source" URNs and one
   "priority" URN:

       Alert-Info: <urn:alert:source:internal>,
           <urn:alert:source:unclassified>,
           <urn:alert:priority:high>

   then processing progresses:

       State: Priority/Source
           Process: Source:Internal (urn:alert:source:internal)
       State: Priority/Source:Internal
           Process: Source:Other (urn:alert:source:unclassified)
       State: Priority/Source:Internal
           Process: Priority:High (urn:alert:priority:high)
       State: Priority:High/Source:Internal
       Signal: internal source/high priority

   If the UA receives

       Alert-Info: <urn:alert:source:internal>

   then processing progresses:

       State: Priority/Source
           Process: Source:Internal (urn:alert:source:internal)
       State: Priority/Source:Internal
       Signal: internal source

   If the UA receives

       Alert-Info: <urn:alert:source:external>,
           <urn:alert:priority:low>

   then processing progresses:

       State: Priority/Source
           Process: Source:External (urn:alert:source:external)
       State: Priority/Source:External
           Process: Priority:Low (urn:alert:priority:low)
       State: Priority:Low/Source:External
       Signal: external source/low priority

   Suppose the same UA receives

       Alert-Info: <urn:alert:source:internal>,
           <urn:alert:priority:low>

   Note that there is no signal that corresponds to this combination.
   In that case, the processing is:

       State: Priority/Source
           Process: Source:Internal (urn:alert:source:internal)
       State: Priority/Source:Internal
           Process: Priority:Low (urn:alert:priority:low)
       State: Priority:(Low)/Source:Internal
       Signal: internal source

   If the order of the URNs is reversed, what is signaled is the meaning
   of the now-different first URN:

       Alert-Info: <urn:alert:priority:low>,
           <urn:alert:source:internal>

       State: Priority/Source
           Process: Priority:Low (urn:alert:priority:low)
       State: Priority:Low/Source
           Process: Source:Internal (urn:alert:source:internal)
       State: Priority:Low/Source:(Internal)
       Signal: low priority

   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:

       Alert-Info: <urn:alert:priority:low>,
           <urn:alert:source:internal>,
           <urn:alert:source:external>

       State: Priority/Source
           Process: Priority:Low (urn:alert:priority:low)
       State: Priority:Low/Source
           Process: Source:Internal (urn:alert:source:internal)
       State: Priority:Low/Source:(Internal)
           Process: Source:External (urn:alert:source:external)
       State: Priority:Low/Source:(Internal)
       Signal: low priority

   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".

5.4.  An Example That Subsets Internal Sources

   In the example of Section 4, there are signals for "external source"
   and "internal source".  Let us add to that example a signal for
   "source internal from a VIP (Very Important Person)".  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 are a total of three expressed URNs, one of
   which is a subset of another:

       urn:alert:source:internal
       urn:alert:source:internal:vip@example
       urn:alert:source:external

   This generates the following alphabet of symbols, which includes two
   "Other" symbols for the "source" category:

       Source
       Source:Internal
       Source:Internal:Vip@example
       Source:Internal:Other
       Source:Other

5.5.  An Example of "alert:service" URNs

   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 two expressed URNs:

       urn:alert:service:forward
       urn:alert:service:recall:callback

   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.

       Service
       Service:Forward
       Service:Recall
       Service:Recall:Callback
       Service:Recall:Other
       Service:Other

5.6.  An Example Using Country Codes

   In this example, we consider how a UA generates ringback signals when
   the UA wishes to reproduce the traditional behavior where 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 [RFC7462] containing the ISO 3166-1
   [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:

       Signal                        URN(s)
       --------------------------    ----------------------------------
       default                       (none)
       call-waiting                  urn:alert:service:call-waiting

       XA default                    urn:alert:country:xa
       XA call-waiting               urn:alert:country:xa,
                                         urn:alert:service:call-waiting
       XA forward                    urn:alert:country:xa,
                                         urn:alert:service:forward

       XB default                    urn:alert:country:xb
       XB forward                    urn:alert:country:xb,
                                        urn:alert:service:forward

   The expressed URNs are:

       urn:alert:country:xa
       urn:alert:country:xb
       urn:alert:service:call-waiting
       urn:alert:service:forward

   The relevant categories of "alert" URNs are only:

       country
       service

   The alphabet of symbols is:

       Country
       Country:[other]
       Country:Xa
       Country:Xb
       Service
       Service:[other]
       Service:Call-waiting
       Service:Forward

   The 17 states are as follows:

       State: 0 Country/Service
       Signal: default
       Transitions:
           Country:[other] -> 1 Country:([other])/Service
           Country:Xa -> 5 Country:Xa/Service
           Country:Xb -> 9 Country:Xb/Service
           Service:[other] -> 13 Country/Service:([other])
           Service:Call-waiting -> 14 Country/Service:Call-waiting
           Service:Forward -> 16 Country/Service:(Forward)

    State: 1 Country:([other])/Service
    Signal: default
    Transitions:
        Country:[other] -> 1 Country:([other])/Service
        Country:Xa -> 1 Country:([other])/Service
        Country:Xb -> 1 Country:([other])/Service
        Service:[other] -> 2 Country:([other])/Service:([other])
        Service:Call-waiting -> 3 Country:([other])/Service:Call-waiting
        Service:Forward -> 4 Country:([other])/Service:(Forward)

       State: 2 Country:([other])/Service:([other])
       Signal: default
       Transitions:
           any -> 2 Country:([other])/Service:([other])

       State: 3 Country:([other])/Service:Call-waiting
       Signal: call-waiting
       Transitions:
           any -> 3 Country:([other])/Service:Call-waiting

       State: 4 Country:([other])/Service:(Forward)
       Signal: default
       Transitions:
           any -> 4 Country:([other])/Service:(Forward)

       State: 5 Country:Xa/Service
       Signal: XA default
       Transitions:
           Country:[other] -> 5 Country:Xa/Service
           Country:Xa -> 5 Country:Xa/Service
           Country:Xb -> 5 Country:Xa/Service
           Service:[other] -> 6 Country:Xa/Service:([other])
           Service:Call-waiting -> 7 Country:Xa/Service:Call-waiting
           Service:Forward -> 8 Country:Xa/Service:Forward

       State: 6 Country:Xa/Service:([other])
       Signal: XA default
       Transitions:
           any -> 6 Country:Xa/Service:([other])

       State: 7 Country:Xa/Service:Call-waiting
       Signal: XA call-waiting
       Transitions:
           any -> 7 Country:Xa/Service:Call-waiting

       State: 8 Country:Xa/Service:Forward
       Signal: XA forward
       Transitions:
           any -> 8 Country:Xa/Service:Forward

       State: 9 Country:Xb/Service
       Signal: XB default
       Transitions:
           Country:[other] -> 9 Country:Xb/Service
           Country:Xa -> 9 Country:Xb/Service
           Country:Xb -> 9 Country:Xb/Service
           Service:[other] -> 10 Country:Xb/Service:([other])
           Service:Call-waiting -> 11 Country:Xb/Service:(Call-waiting)
           Service:Forward -> 12 Country:Xb/Service:Forward

       State: 10 Country:Xb/Service:([other])
       Signal: XB default
       Transitions:
           any -> 10 Country:Xb/Service:([other])

       State: 11 Country:Xb/Service:(Call-waiting)
       Signal: XB default
       Transitions:
           any -> 11 Country:Xb/Service:(Call-waiting)

       State: 12 Country:Xb/Service:Forward
       Signal: XB forward
       Transitions:
           any -> 12 Country:Xb/Service:Forward

       State: 13 Country/Service:([other])
       Signal: default
       Transitions:
           Country:[other] -> 2 Country:([other])/Service:([other])
           Country:Xa -> 6 Country:Xa/Service:([other])
           Country:Xb -> 10 Country:Xb/Service:([other])
           Service:[other] -> 13 Country/Service:([other])
           Service:Call-waiting -> 13 Country/Service:([other])
           Service:Forward -> 13 Country/Service:([other])

       State: 14 Country/Service:Call-waiting
       Signal: call-waiting
       Transitions:
           Country:[other] -> 3 Country:([other])/Service:Call-waiting
           Country:Xa -> 7 Country:Xa/Service:Call-waiting
           Country:Xb -> 15 Country:(Xb)/Service:Call-waiting
           Service:[other] -> 14 Country/Service:Call-waiting
           Service:Call-waiting -> 14 Country/Service:Call-waiting
           Service:Forward -> 14 Country/Service:Call-waiting

       State: 15 Country:(Xb)/Service:Call-waiting
       Signal: call-waiting
       Transitions:
           any -> 15 Country:(Xb)/Service:Call-waiting

       State: 16 Country/Service:(Forward)
       Signal: default
       Transitions:
           Country:[other] -> 4 Country:([other])/Service:(Forward)
           Country:Xa -> 8 Country:Xa/Service:Forward
           Country:Xb -> 12 Country:Xb/Service:Forward
           Service:[other] -> 16 Country/Service:(Forward)
           Service:Call-waiting -> 16 Country/Service:(Forward)
           Service:Forward -> 16 Country/Service:(Forward)

   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.

      Alert-Info: urn:alert:country:xa,
              urn:alert:service:call-waiting

      State: 0 Country/Service
          Process: Country:Xa (urn:alert:country:xa)
      State: 5 Country:Xa/Service
          Process: Service:Call-waiting (urn:alert:service:call-waiting)
      State: 7 Country:Xa/Service:Call-waiting
      Signal: XA call-waiting

      Alert-Info: urn:alert:service:call-waiting,
              urn:alert:country:xa

      State: 0 Country/Service
          Process: Service:Call-waiting (urn:alert:service:call-waiting)
      State: 14 Country/Service:Call-waiting
          Process: Country:Xa (urn:alert:country:xa)
      State: 7 Country:Xa/Service:Call-waiting
      Signal: XA call-waiting

      Alert-Info: urn:alert:country:xb,
              urn:alert:service:call-waiting

      State: 0 Country/Service
          Process: Country:Xb (urn:alert:country:xb)
      State: 9 Country:Xb/Service
          Process: Service:Call-waiting (urn:alert:service:call-waiting)
      State: 11 Country:Xb/Service:(Call-waiting)
      Signal: XB default

      Alert-Info: urn:alert:service:call-waiting,
              urn:alert:country:xb

      State: 0 Country/Service
          Process: Service:Call-waiting (urn:alert:service:call-waiting)
      State: 14 Country/Service:Call-waiting
          Process: Country:Xb (urn:alert:country:xb)
      State: 15 Country:(Xb)/Service:Call-waiting
      Signal: call-waiting

6.  Prioritizing Signals

   The specifications provided in [RFC7462] are oriented toward giving
   the sender of Alert-Info control over which of the "alert" URNs are
   most important.  But in some situations, the UA may prefer to
   prioritize expressing one URN category over another regardless of the
   order in which their URNs appear in Alert-Info.  This section
   describes how that can be accommodated within the framework of
   [RFC7462] and presents an example FSM resulting from that approach.

   This example uses the signals of Section 5.2, 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 [RFC7462] by assigning
   the signal "high priority" for each of these combinations of URNs:

       urn:alert:priority:high
       urn:alert:priority:high, urn:alert:source:internal
       urn:alert:priority:high, urn:alert:source:external

   The result is that the signal "high priority" is the "best" signal
   for any combination of urn:alert:priority:high with "source" URNs.

   Constructing the symbols produces the same results as before.  The
   signals can express the following URNs:

       urn:alert:source:external
       urn:alert:source:internal
       urn:alert:priority:low
       urn:alert:priority:high

   The relevant categories of "alert" URNs are:

       source
       priority

   The alphabet of symbols is:

       Source
       Source:External
       Source:Internal
       Source:Other
       Priority
       Priority:Low
       Priority:High
       Priority:Other

   When the FSM is constructed, it is the same as the FSM of
   Section 5.2, except that certain states are effectively renamed and
   merged, because any "source" is defined to be expressed if high
   priority is expressed:

       Priority:(High)/Source:External and
       Priority:High/Source:(External) become:

           State: Priority:High/Source:External
           Signal: high priority

       Priority:(High)/Source:Internal and
       Priority:High/Source:(Internal) become:

           State: Priority:High/Source:Internal
           Signal: high priority

   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
   optimized FSM has 10 states.

7.  Dynamic Sets of Signals

   This section discusses how to construct FSMs for a UA that allows
   variable sets of signals -- for example, if the user can configure
   the use of ring tones.  Several approaches can be used:

   o  Whenever the set of ring tones is changed, re-execute the
      processes of Section 4.

   o  Whenever the set of ring tones is changed, rebuild the list of
      expressed URNs (Section 4.1) and reconstruct the alphabet of
      symbols (Section 4.2).  Then, use an algorithm for dynamically
      constructing the states of the FSM as needed during Alert-Info
      processing.

   o  If the sets of possible URNs expressed by the ring tones are
      sufficiently limited, the steps of Section 4 can be carried out
      "generically", and the generic FSM can be specialized for the
      current ring tone configuration.

   The remainder of this section gives an example of the third approach.

   For the example, we will use a set of ring tones that express the
   identity of the caller.  To signal this information, a private
   extension "alert" URN category, "caller@example", is used:

       urn:alert:caller@example:alice@example.com
       urn:alert:caller@example:bob@example.com
       etc.

   which we can express by the generic pattern

       urn:alert:caller@example:IDENTITY

   where "IDENTITY" is replaced in succession by the set of caller
   identities that have their own ring tones to generate the set of
   expressed URNs.

   The alphabet is then:

       Caller@example
       Caller@example:IDENTITY
       Caller@example:Other

   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
   "Caller@example:IDENTITY" symbols, i.e, where the second
   alert-ind-part is not one of the known caller identities.

   The states and transitions of the FSM are:

       State: Caller@example (initial state)
       Signal: default
       Transitions:
           Caller@example:IDENTITY -> Caller@example:IDENTITY
           Caller@example:Other -> Caller@example:(Other)

       State: Caller@example:IDENTITY
       Signal: signal for caller IDENTITY
       Transitions:
           any -> Caller@example:IDENTITY

       State: Caller@example:(Other)
       Signal: default
       Transitions:
           any -> Caller@example:(Other)

   where again, the second state is replicated once for each caller
   identity that has a ring tone, with "IDENTITY" replaced with the
   caller identity.

8.  Security Considerations

   The security considerations discussed in Section 16 of [RFC7462]
   regarding the use and processing of "alert" URNs MUST be followed
   when the algorithm described in this document is used.

   Like any implementation of [RFC7462], implementations of the
   algorithm defined in this document MUST take into account that the
   value of a received Alert-Info header field may contain URIs of any
   scheme, may contain syntactically invalid values, and may be
   syntactically invalid overall.  The handling of syntactically invalid
   values is specified by [RFC3261].  The handling of URIs other than
   "alert" URIs is outside the scope of this document (and outside the
   scope of [RFC7462]) and MAY be subject to local policy.

   Like the algorithm described in Section 12 of [RFC7462], the output
   of the algorithm defined in this document is limited to a choice
   among the signals that it has been configured for, limiting the
   security issues regarding the processing of its output.  This
   algorithm will use at most linear time and constant space to process
   a sequence of "alert" URNs.  This is significantly more efficient
   than the algorithm of [RFC7462] and minimizes the security
   vulnerabilities of this processing step that are due to resource
   consumption.

   However, the process defined in this document for constructing an FSM
   can use more than linear time and constant space -- probably
   exponential time and space in the worst case.  This SHOULD be taken
   into consideration whenever an FSM is constructed using this
   algorithm and MUST be taken into consideration when it is done
   dynamically by a UA.  Whenever an FSM is constructed by a process
   that is not under the direct supervision of a human user, procedures
   MUST be used to ensure that (1) the processing and memory consumption
   are limited to acceptable amounts and (2) if the FSM construction is
   aborted due to excessive consumption, the designated consumers of the
   FSM MUST have appropriate fallback procedures.

9.  IANA Considerations

   This document has no IANA actions.

10.  References

10.1.  Normative References

   [ISO-3166-1]
              International Organization for Standardization, "Codes for
              the representation of names of countries and their
              subdivisions -- Part 1: Country codes", ISO
              Standard 3166-1:2013, November 2013,
              <https://www.iso.org/iso-3166-country-codes.html>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              DOI 10.17487/RFC3261, June 2002,
              <https://www.rfc-editor.org/info/rfc3261>.

   [RFC7462]  Liess, L., Ed., Jesske, R., Johnston, A., Worley, D., and
              P. Kyzivat, "URNs for the Alert-Info Header Field of the
              Session Initiation Protocol (SIP)", RFC 7462,
              DOI 10.17487/RFC7462, March 2015,
              <https://www.rfc-editor.org/info/rfc7462>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in
              RFC 2119 Key Words", BCP 14, RFC 8174,
              DOI 10.17487/RFC8174, May 2017,
              <https://www.rfc-editor.org/info/rfc8174>.

10.2.  Informative References

   [code]     Worley, D., "draft-worley-alert-info-fsm.aux",
              February 2017, <http://svn.resiprocate.org/rep/
              ietf-drafts/worley/draft-worley-alert-info-fsm.aux>.

Acknowledgments

   Thanks 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 earlier Independent Submissions Editor, Nevil Brownlee, for his
   work obtaining reviewers, and the later Independent Submissions
   Editor, Adrian Farrel, for prompting me to write the Security
   Considerations section (which I had expected to be trivial but
   was not).

Author's Address

   Dale R. Worley
   Ariadne Internet Services
   738 Main St.
   Waltham, MA  02451
   United States of America

   Email: worley@ariadne.com