Re: [sipcore] 4244bis-05: additional technical comments

Shida Schubert <> Sun, 10 July 2011 08:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2E45921F8A93 for <>; Sun, 10 Jul 2011 01:14:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.265
X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id T5kRg3vp4h3i for <>; Sun, 10 Jul 2011 01:14:29 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8AFD021F89F2 for <>; Sun, 10 Jul 2011 01:14:29 -0700 (PDT)
Received: from [] (port=56536 helo=[]) by with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from <>) id 1Qfp9h-0003gB-LN; Sun, 10 Jul 2011 03:14:22 -0500
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Shida Schubert <>
In-Reply-To: <>
Date: Sun, 10 Jul 2011 17:14:19 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: "Worley, Dale R (Dale)" <>
X-Mailer: Apple Mail (2.1084)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-BWhitelist: no
X-Source-Sender: ([]) []:56536
X-Email-Count: 4
X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t
Cc: "" <>, " WG" <>
Subject: Re: [sipcore] 4244bis-05: additional technical comments
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: Sun, 10 Jul 2011 08:14:30 -0000

Hi Dale;

 My comments inline..

On Jun 23, 2011, at 5:47 AM, Worley, Dale R (Dale) wrote:

> Thanks for writing this, as both points you made lead me to realize
> errors I was making!
>> From: Hadriel Kaplan []
>> 1) Section 10.3, page 19, says:
>>   In the case that a SIP entity (intermediary or UAS) adds an hi-entry
>>   on behalf of the previous hop, the hi-index MUST be set to 1.
>> Taken literally, this means when a request already marked with H-I
>> entries happens to cross a legacy non-HI system, the next downstream
>> element will add an additional H-I entry starting at 1 again.  Is that
>> intentional/on-purpose??  At first I thought this was just an
>> editorial mistake, but section 11, page 22, says :
>>   Gaps are possible if the request is forwarded through
>>   intermediaries that do not support the History-info header field and
>>   are reflected by the existence of multiple hi-entries with an index
>>   of "1".
>> So a single SIP request can actually have multiple H-I trees with
>> multiple root indexes of 1?  Wouldn't this make UAS logic code more
>> complicated, because now the "mp=X" and "rc=X" index values are
>> relative "X" values, scoped to within their particular tree, as
>> opposed to being an absolute number for the whole H-I list?
> I had mis-read this to mean that the receiving entity would construct
> an H-I entry on behalf of the previous hop by adding a new H-I entry
> with index "[whatever].1", that is, the entry the previous hop would
> have added, had it forwarded to only one destination.
> But that's not what the draft says, the draft says that the new index
> is just "1".
> Given the specifications, that new H-I entry must be the child of the
> immediately preceeding H-I entry, so the H-I header is not ambiguous.
> But it does destroy the principle that the three of H-I entries is
> described simply by the index values.

 Your understanding is correct AFAIK. 

 The index added for entity which didn't log H-I (didn't support H-I) 
SHOULD be "[last-hi-entry's index].1".

>> 2) Section 9.4, page 16 says:
>>   When sending a response other than a 100, a SIP entity MUST include
>>   all the cached hi-entries in the response, subject to the privacy
>>   consideration in Section 10.1.2 with the following exception: If the
>>   received request contained no hi-entries and there is no "histinfo"
>>   option tag in the Supported header field, the SIP entity MUST NOT
>>   include hi-entries in the response.
>> Note the "If the received request contained no hi-entries and...".  I
>> don't know what having H-I entries has to do with it.  We have an
>> option-tag for this purpose: histinfo.  If the option-tag is in the
>> Supported, then you can send H-I entries in response.  Else not.  Even
>> if the request contained H-I entries but no "histinfo" option tag, you
>> can't send 'em back. (e.g., such would be the case if proxies added
>> the entries but the UAC does not support it)
> Hmm, I would be inclinded to agree with you, but, as written, the
> draft solves a "problem" I was wondering about:
> phone A (no H-I supt.) --> proxy B (H-I supt.) --> proxy C (H-I) --> phone D (H-I)
>    Phone A does not insert H-I in the request.
>    Proxy B inserts H-I in the request to proxy C:  One entry, index
>    1, containing the original request-URI, and a second entry, index
>    1.1, containing the request-URI it sends to proxy C.
>    Proxy C inserts H-I in the request to phone D: index 1.1.1,
>    containing the request-URI it sends to phone D.
>    Phone D copies the H-I into its response -- because it received
>    H-I in the request (which implies that some upstream entity can
>    understand the H-I).
>    Proxy C copies the H-I into its response, adding Reason to index
>    1.1.1 -- because it received H-I in the request.
>    Proxy B *does not* include H-I in its response.  The absence of
>    "Supported: histinfo" and an incoming H-I in its request shows that no
>    upstream entity understands H-I.
>    Phone A receives a response without H-I, as it expected.
> This arrangement satisfies these requirements:
> 1) No phone will receive H-I in a response if it does not support it.
> Thus, no pre-H-I phone will receive a response that is unexpectedly
> large.
> 2) Every H-I-aware entity will receive H-I information from every
> upstream and downstream entity H-I-aware entity.
> An implication of this is that "Supported: histinfo" is redundant and
> can be eliminated from the protocol; a phone can indicate whether or
> not it supports H-I by whether it includes a History-Info header.
> Dale

 We still need "Supported: histinfo" for backward compatibility as 
you stated yourself in the following e-mail. 


> _______________________________________________
> sipcore mailing list