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

[Shida Schubert <[e-mail]>]

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

 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. 

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

 Agree. 

 will fix. 

 Regards
  Shida

> 
> -hadriel
>