Re: [sipcore] 4244bis Application processing

Hi Dale;

 Thanks again for your thorough analysis of the draft.

 My comments inline..

On Jun 30, 2011, at 1:07 AM, Worley, Dale R (Dale) wrote:

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

 As I mentioned in another thread, I think this is a bug. 

 The index for missing entity should be {whatever}.1. 

 If the last index of H-I was 1.1, then the index for R-URI 
representing an entity that did not support H-I SHOULD be 
1.1.1. 

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

 This is true, in case of parallel forking. 

  First branch would only see 1.1 
  Second branch would only see 1.2 
  Third 1.3 etc. 

 If it is a serial forking, you would have the whole brunches, 
unless there are entities not supporting RFC4244bis or RFC4244. 

 First branch would see 1.1
 Second would see 1.1 and 1.2 
 Third would see 1.1, 1.2 and 1.3

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

 I think changing the semantics of "rc" to mean the "change of R-URI" will 
make it easier for application to read the ancestor hi-entries.

 Regards
  Shida

> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore