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

[Shida Schubert <[e-mail]>]

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 [[e-mail]]
>> 
>> 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. 

 Regards
  Shida

> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore