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

Shida Schubert <> Fri, 24 June 2011 12:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E820411E80CB for <>; Fri, 24 Jun 2011 05:40:12 -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=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9oAAHeFD-TB4 for <>; Fri, 24 Jun 2011 05:40:12 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7A03E11E80B5 for <>; Fri, 24 Jun 2011 05:40:12 -0700 (PDT)
Received: from ([]:49761 helo=[]) by with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from <>) id 1Qa5K9-00015b-JC; Fri, 24 Jun 2011 07:17:25 -0500
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Shida Schubert <>
In-Reply-To: <>
Date: Fri, 24 Jun 2011 21:17:25 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Hadriel Kaplan <>
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: ([]) []:49761
X-Email-Count: 31
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: Fri, 24 Jun 2011 12:40:13 -0000

Hi Hadriel;

 Thanks for your comments..

 My comments inline. 

On Jun 16, 2011, at 5:15 AM, Hadriel Kaplan wrote:

> Hi,
> some more technical comments:
> 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?


 This doesn't sound right. 

 My understanding of the text was to have entity receiving the 
request with a gap in H-I to add hi-entry and add it as a new hop, 
meaning add a dot and index of "1". 

 Gap could still exists as text mentions, if there are multiple hops 
between entities that support H-I. Because the entity receiving the 
H-I on behalf of the entity not supporting the H-I could only record 
R-URI it received. 

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


 will fix. 


> -hadriel