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

Dean Willis <> Mon, 20 June 2011 20:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1A8AF11E8097 for <>; Mon, 20 Jun 2011 13:35:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1hDIwhqkW55j for <>; Mon, 20 Jun 2011 13:35:26 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5CE7811E808E for <>; Mon, 20 Jun 2011 13:35:26 -0700 (PDT)
Received: by yxt33 with SMTP id 33so3873579yxt.31 for <>; Mon, 20 Jun 2011 13:35:25 -0700 (PDT)
Received: by with SMTP id g80mr8931691yhf.165.1308602125291; Mon, 20 Jun 2011 13:35:25 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id i30sm3792711yhm.49.2011. (version=TLSv1/SSLv3 cipher=OTHER); Mon, 20 Jun 2011 13:35:24 -0700 (PDT)
References: <> <>
In-Reply-To: <>
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
Message-Id: <>
Content-Transfer-Encoding: quoted-printable
From: Dean Willis <>
Date: Mon, 20 Jun 2011 15:35:21 -0500
To: "Worley, Dale R (Dale)" <>
X-Mailer: Apple Mail (2.1084)
Cc: "" <>
Subject: Re: [sipcore] 4244bis-05: Semantics of History-Info
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 20 Jun 2011 20:35:27 -0000

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.