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

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 15 Jun 2011 16:15:27 -0400

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?

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)

-hadriel

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Wed, 22 Jun 2011 16:47:05 -0400

Thanks for writing this, as both points you made lead me to realize
errors I was making!

> From: Hadriel Kaplan [[email-masked]]
> 
> 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 :
> 
> 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.

> 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

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 23 Jun 2011 12:37:45 -0400

> From: Worley, Dale R (Dale) [[email-masked]]
> 

Ah, but in 4244, a UAC can include "Supported: histinfo" *without*
also adding History-Info.  So "Supported: histinfo" is required for
backward compatibility with 4244.

Dale

---

From: Shida Schubert <[email-masked]>
Date: Fri, 24 Jun 2011 21:17:25 +0900

Hi Hadriel;

 Thanks for your comments..

 My comments inline. 

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

 Hmm.. 

 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. 

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

 Agree. 

 will fix. 

 Regards
  Shida