[sipcore] 4244bis Application processing

"Worley, Dale R (Dale)" <dworley@avaya.com> Wed, 29 June 2011 16:08 UTC

From: "Worley, Dale R (Dale)" <dworley@avaya.com>
To: "sipcore@ietf.org" <sipcore@ietf.org>
Date: Wed, 29 Jun 2011 12:07:49 -0400
Thread-Topic: 4244bis Application processing
Thread-Index: AQHMNnbR1jQGF7ByY0+jF5iWwb8Uug==
Message-ID: <CD5674C3CD99574EBA7432465FC13C1B222B1F5712@DC-US1MBEX4.global.avaya.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [sipcore] 4244bis Application processing
Precedence: list

The initial part of section 11 "Application Considerations" discusses
"gaps" in the H-I values.  Unfortunately, it doesn't distinguish
between two very different types of gaps.  One type of gap is due to a
non-H-I-supporting proxy.  In the system of the draft, this results in
an hi-entry with index "1" that is not the first (root (almost))
hi-entry.  If we use the alternative proposal, a non-H-I-supporting
proxy results in an hi-entry that is fit into the tree structure in
the ordinary way and is not distinguishable (although it has no
hi-target-param).

The second type of gap is due to elder forks which had not yet
returned non-100 responses.  These gaps can be detected by examining
the index numbers; a gap of this type is evidenced by an index that is
present whose last component is greater than 1, but there is no
hi-entry whose index is the same except for having a last component 1
less.

Note that there is another sort of gap which is entirely undetectable:
a younger fork.  But in the case of parallel forking, the "current"
fork, its elder forks, and its younger forks are all have equal
status.  The fact that younger forks cannot be detected warns us to
follow the following principle:

    Gaps in the hi-entries are to be expected, and sometimes are
    undetectable.  Thus, any processing applied to History-Info that
    requires that there are no gaps in the hi-entries will likely be
    unsuccessful in practice.

The current section 11 gives some simple algorithms that can be
applied to H-I to extract information.  I believe that more effective
algorithms can be constructed based on the following considerations:

Each hi-entry (explicitly or implicitly) points to an "ancestor"
hi-entry from whose hi-targeted-to-uri its hi-targeted-to-uri was
derived (possibly through several steps, if some intermediate SIP
entities did not implement H-I).  The "ancestor" hi-entry is always
before the hi-entry in the pre-order.  If the hi-entry has an
hi-target-param, the value of the parameter is the index of the
ancestor hi-entry.  If the hi-entry does not have an hi-target-param,
the ancestor hi-entry is its parent in the tree, whose index is the
same except for having the last component deleted.

Starting at the current hi-entry (the last one sequentially, which
corresponds to the request received by this SIP entity), the chain of
ancestor hi-entries shows the derivation of the current Request-URI,
and where hi-target-params are present, it shows the nature of each
derivation step.

The application should examine the hi-targeted-to-uris in the chain of
ancestor hi-entries to see which of them it recognizes as being within
its domain of responsibility, and whose semantics it understands.  The
examination should stop when it first reaches an hi-targeted-to-uri
that it does not understand.

In many cases, there will be earlier hi-entries in the chain because
of various retargetings applied by the caller's services, and possibly
due to intermediate services.

And sometimes there will be hi-entries in the chain that the
applicaiton understands that are earlier than hi-entries in the chain
that the application does not understand.  The application should not
make the mistake of considering these hi-entries -- they are are due
to an earlier passage through (and out of) its domain, and do not
describe how the request entered the domain and reached the
application.

To emphasize, the application starts at the hi-entry describing the
request that it received, and successively examines the ancestor
hi-entries, and *stops* when it sees an hi-entry that it does not
understand.  This chain of hi-entries tells what URI the request had
when it entered the domain, and how it progressed through the domain
to the application.

In addition, the application can examine sibling hi-entries of the
ancestor hi-entries that it understands to determine alternative
destinations for the call that have already been attempted.

Looking at the use cases in
draft-barnes-sipcore-rfc4244bis-callflows-01, we can apply this
approach to implement the described use cases:

3.1.  Automatic Call Distribution

In this example, it is envisioned that example.com has two AORs,
<sip:Gold@example.com> and <sip:Silver@example.com>.  Different
categories of customers are given different AORs to call for customer
service, and due to that, the calls may be routed differently within
example.com's call center.  In addition, calls originally targeted at
one AOR may be routed to the other (due to overflow, etc.).

What is needed is:

- Determine which AOR the call was "originally" targeted to.
- Determine the set of retargetings the call was subjected to within
  example.com (as that may indicate how long the caller has been
  waiting, etc.)

(Note that retargeting from one AOR to another in this situation is
not recommended.  Better is to retarget Silver -> silver-agents and
Gold -> (both gold-agents and silver-agents), so that no call ever is
routed through more than one AOR.)

Following the chain of ancestor hi-entries eventually reaches the
hi-entry describing how the call was targets to example.com
originally:  either sip:Gold@example.com or sip:Silver@example.com.
The chain itself documents what retargeting the call has gone through.

The example is:

  History-Info: <sip:Gold@example.com>;index=1
  History-Info: <sip:Gold@gold.example.com?Reason%3BSIP%3Dcause%3B302>;\
                index=1.1
  History-Info: <sip:Silver@example.com>;index=1.2;mp=1
  History-Info: <sip:Silver@silver.example.com>;index=1.2.1
  History-Info: <sip:Silver@192.0.2.7>;index=1.2.1.1;rc=1.2.1

The chain of ancestor hi-entries is:

  <sip:Silver@192.0.2.7>;index=1.2.1.1;rc=1.2.1
  <sip:Silver@silver.example.com>;index=1.2.1
  <sip:Silver@example.com>;index=1.2;mp=1
  <sip:Gold@example.com>;index=1

showing that the call was made to <sip:Gold@example.com> and that it
has been retargeted from Gold to Silver.

3.2.  Determining the Alias used.

       History-Info: <sip:john.smith@example.com>;index=1;
       History-Info: <sip:john@192.0.2.1?Reason%3BSIP%3Dcause%3B408>;index=1.1;rc=1;
       History-Info: <sip:john@192.0.2.5>;index=1.2;rc=1;

The chain of ancestor hi-entries is:

       <sip:john@192.0.2.5>;index=1.2;rc=1;
       <sip:john.smith@example.com>;index=1;

The UA recognizes <sip:john@192.0.2.5> as (one of) its contact URIs,
and <sip:john.smith@example.com> as an AOR/alias which it has been
configured to treat specially.

3.3.  PBX Voicemail Example

In this example, a call to Bob has been call-forward-always to Carol,
who has not answered.  The proxy handling the call wants to route the
call to the voicemail system, using Bob's mailbox not Carol's
mailbox.  This requires determining that the call "was originally for
Bob".

The History-Info of the failed call to Carol is as follows.  (This has
been updated with the failure reason, and is actually the cache at the
proxy at the time the INVITE to the VM system is generated.)

     History-Info: <sip:bob@example.com>;index=1
     History-Info: <sip:bob@192.0.2.3?Reason%3BSIP%3Dcause%3B302>;\
                   index=1.1;rc=1
     History-Info: <sip:carol@example.com>;index=1.2;mp=1
     History-Info: <sip:carol@192.0.2.4?Reason%3BSIP%3Dcause%3B408>;\
                   index=1.2.1;rc=1.2

(Note that the chain must start at the hi-entry of the failed fork.
there may have been younger forks added since that fork was initiated,
so the failed fork may not be the last hi-entry.)  The chain of
ancestor hi-entries is:

     <sip:carol@192.0.2.4?Reason%3BSIP%3Dcause%3B408>;index=1.2.1;rc=1.2
     <sip:carol@example.com>;index=1.2;mp=1
     <sip:bob@example.com>;index=1

The application recognizes indexes 1.2 and 1 as AORs for the system,
and so can route the call to the VM system knowing that the "original
callee" is sip:bob@example.com, and the cause for sending the call to
VM was no-answer.

3.4.  Consumer Voicemail Example

     History-Info: <sip:bob@example.com>;index=1
     History-Info: <sip:bob@192.0.2.3?Reason%3BSIP%3Dcause%3B302>;\
                   index=1.1;rc
     History-Info: <sip:carol@example.com?Reason%3BSIP%3Dcause%3B408>;\
                   index=1.2;mp=1
     History-Info: <sip:carol@192.0.2.4>;index=1.2.1;rc=1.2

The chain of ancestor hi-entries is:

     <sip:carol@example.com?Reason%3BSIP%3Dcause%3B408>;index=1.2;mp=1
     <sip:bob@example.com>;index=1

In this case, the desired behavior is for the call to go to Carol's
voicemail, and the application, seeing that hi-entry 1.2 contains
Carol's AOR, it looks no further back.

3.5.  GRUU

   History-Info: <sip:john@example.com
    ;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>;index=1
   History-Info: <sip:john@192.0.2.1>;index=1.1

The chain of ancestor hi-entries is:

   <sip:john@192.0.2.1>;index=1.1
   <sip:john@example.com;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>;index=1

The application can see that its contact URI was derived from the GRUU
at index 1.

3.6.  Limited Use Address [accessing URI parameters in a mapped-from URI]

   History-Info:
    <sip:tgruu.7hs==jd7vnzga5w7fajsc7-ajd6fabz0f8g5@example.com;gr>
    ;index=1
   History-Info: <sip:john@192.0.2.1>;index=1.1

The chain of ancestor hi-entries is:

   <sip:john@192.0.2.1>;index=1.1
   <sip:tgruu.7hs==jd7vnzga5w7fajsc7-ajd6fabz0f8g5@example.com;gr>;index=1

Since the application knows it has provided limited-use-addresses that
map into sip:john@192.0.2.1, it knows to look at the ancestor hi-entry
to find the additional information.

3.7.  Service Invocation

   History-Info: <sip:+18005551002@example.com;user=phone>;index=1,
                 <sip:+15555551002@atlanta.com>;index=1.1;mp=1,
                 <sip:john@atlanta.com>;index=1.1.1,
                 <sip:john@198.51.100.2>;index=1.1.2;rc=1.1

The chain of ancestor hi-entries is:

   <sip:john@198.51.100.2>;index=1.1.2;rc=1.1
   <sip:+15555551002@atlanta.com>;index=1.1;mp=1,
   <sip:+18005551002@example.com;user=phone>;index=1,

The application knows that the first URI is its contact, and that the
second URI is the PSTN incoming number, and so it examines the 3rd URI
to find the toll-free PSTN number that indicates the service that is
desired.

Dale

[sipcore] 4244bis Application processing Worley, Dale R (Dale)
Re: [sipcore] 4244bis Application processing Shida Schubert