Re: [sipcore] 4244bis-05: Semantics of History-Info

[Dean Willis <[e-mail]>]

On Jun 20, 2011, at 2:52 PM, Worley, Dale R (Dale) wrote:

> 
> 
> But it seems like it would be useful to allow a proxy to insert "Supported: histinfo"
> into an outgoing request, as long as it purged the History-Info from any response
> it sent upstream.
> 

Perfectly doable. Such a "proxy" is called a back-to-back user agent. The world is full of them. I personally don't use a SIP proxy anymore, AFAIK, to drive my devices. There might be one at my TISP handling DID routing.


> 
> [Suppose the UAC sends
> "History-Info: AOR;index=1", and a non-History-Info-supporting entity forks it
> to two destinations, UAS A and UAS B, both of which support
> History-Info.  UAS A normalizes the request to "History-Info:
> AOR;index=1, UAS-A;index=1.1" while UAS B normalizes the request to
> "History-Info: AOR;index=1, UAS-B;index=1.1".]
> 
> These two normalized requests violate the rule that everybody expects
> to be satisfied, viz., that all hi-entries in the entire forking
> structure with the same index represent the same request.  As a
> result, the responses from the two UASs cannot be merged in any useful
> way.  Since both UASs could send 1xx responses containing History-Info,
> the UAC can see two different hi-entries with index=1.1.
> 
> 

Otherwise said, suppose a B2BUA has added "Supported: histinfo". If it doesn't also add a first "History-Info", things can get hosed. Answer: If you insert a Supported, insert an appropriate 1st index H-I.

But what happens if there are two such b2buas, each deciding to add "Supported: histinfo" along with index-1 records? Chaos ensues...

> In section 9.1 are the rules to help in the case where a H-I-supporting entity
> receives a request from a non-H-I-supporting entity.  As written, it only discusses
> the case where there is already an H-I header in the request.  Strictly speaking,
> the algorithm given faults if there is no H-I header present.  But ISTR that we
> intended that in this case, an hi-entry with index=1 should be inserted by the receiving
> entity.
> 
> 
> [Also need to take care of the case where the UAC generates several
> requests as forks of a theoretical ancestral request, as is used in
> draft-ietf-bliss-call-completion.  It seems like they should have
> index=1, index=2, index=3, etc.  But this does mean that the "tree" now
> has an invisible root node whose index is the empty string of integers.]
> 

The problem is that we're used a numeric-sequenced tree for something that has rather different cardinality.

Perhaps if instead of "1", we used a tag that identified both the inserter AND the ordinal sequence at that inserter relative to this request?

One could look at it as akin to the double-record-route problem for dual homed proxies.

--
Dean