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

"Worley, Dale R (Dale)" <> Wed, 22 June 2011 20:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 20DA421F857B for <>; Wed, 22 Jun 2011 13:47:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.418
X-Spam-Status: No, score=-103.418 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xASFS6w3L7RA for <>; Wed, 22 Jun 2011 13:47:07 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4A6BE21F857A for <>; Wed, 22 Jun 2011 13:47:07 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAB9UAk7GmAcF/2dsb2JhbABTpxF3iHOlFwKbY4YtBJZsiyY
X-IronPort-AV: E=Sophos;i="4.65,407,1304308800"; d="scan'208";a="286505961"
Received: from unknown (HELO ([]) by with ESMTP; 22 Jun 2011 16:47:06 -0400
Received: from (HELO ([]) by with ESMTP; 22 Jun 2011 16:46:40 -0400
Received: from ([]) by ([::1]) with mapi; Wed, 22 Jun 2011 16:47:05 -0400
From: "Worley, Dale R (Dale)" <>
To: Hadriel Kaplan <>, " WG" <>
Date: Wed, 22 Jun 2011 16:47:05 -0400
Thread-Topic: 4244bis-05: additional technical comments
Thread-Index: AcwrmPf5m+md7tDbQPehEG90d3slFAFgcx4E
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
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: Wed, 22 Jun 2011 20:47:08 -0000

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.

> 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

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.