Re: [sipcore] draft-ietf-sipcore-rfc4244bis-callflows-02:"Reason"placement

[OKUMURA Shinji <[e-mail]>]

Hi, Dale.

Thank you for your response, my comments inline.

[e-mail] (Dale R. Worley)
Tue, 26 Feb 2013 22:22:01 -0500 (EST)
>> From: OKUMURA Shinji <[e-mail]>
>
>[choosing one examle from several:]
>> >   3.1.  Sequentially Forking (History-Info in Response)
>> >
>> >   History-Info: <sip:[e-mail]>;index=1.2;mp=1
>> >   History-Info: <sip:office@192.0.2.5?Reason=SIP%3Bcause%3D408>;\
>> >                 index=1.2.1;index=1.2.1;rc=1.2
>
>> draft-ietf-sipcore-rfc4244bis-11
>> 10.2.  Reason in the History-Info Header Field
>> 
>>    If the Reason header field is being added due to
>>    receipt of an explicit SIP response and the response contains any
>>    Reason header fields (see [RFC3326]), then the SIP entity MUST
>>    include the Reason header fields in the "headers" component of the
>>    hi-targeted-to-uri in the last hi-entry added to the cache, unless
>>    the hi-targeted-to-uri is a Tel-URI.  If the SIP response does not
>>    contain a Reason header field, the SIP entity MUST include a Reason
>>    header field, containing the SIP Response Code, in the "headers"
>>    component of the hi-targeted-to-uri in the last hi-entry added to the
>>    cache, unless the hi-targeted-to-uri is a Tel-URI.
>> 
>> according to this descriptions, SIP entity MUST include a Reason header
>> "in the last hi-entry added to the cache".
>> IIUC, it means "next hop" index=1.2.1.
>
>Looking at the matter more closely, it is rather complex:
>
>The text says "the last hi-entry added to the cache".  I believe that
>it means "the hi-entry that was most recently added to the cache".
>
>The processing described is in section 10.2.  The only location where
>10.2 is referenced is in Step 2 of section 9.3.  Section 9.3 begins:
>
>   9.3.  Receiving a Response with History-Info or Request Timeouts
>
>   When a SIP entity receives a non-100 response or a request times out,
>   the SIP entity performs the following steps:
>
>   Step 1:  Add hi-entry to cache
>
>      The SIP entity MUST add the hi-entry that was added to the request
>      that received the non-100 response or timed out to the cache, if
>      it was not already cached.  The hi-entry MUST be added to the
>      cache in ascending order as indicated by the values in the hi-
>      index parameters of the hi-entries (e.g., 1.2.1 comes after 1.2
>      but before 1.2.2 or 1.3).
>
>   Step 2:  Add Reason header field
>
>      The SIP entity adds one or more Reason header fields to the hi-
>      targeted-to-uri in the (newly) cached hi-entry reflecting the SIP
>      response code in the non-100 response, per the procedures of
>      Section 10.2.
>
>As you can see, the point where section 10.2 is invoked is in Step 2,
>and at that point the hi-entry that was most recently added to the
>cache is the hi-entry specified in Step 1, namely, "the hi-entry that
>was added to the request that received the ... response".  (hi-entries
>taken from the response itself are added to the cache later, in Step
>3.)

At a time when the SIP entity adds one or more Reason header
fields, "the index of the last hi-entry added to the cache"
is 1.2.1, isn't it?

>In this case, I believe there is a problem with the wording:  Step 1
>does nothing because the specified hi-entry is already in the cache
>due to reception of response F7 (in the callflow 3.1), and so the
>specified hi-entry is not "added to the cache", but I believe it is
>intended to be the hi-entry upon which Step 2 and section 10.2
>operate.

aha!

At proxy.example.com,
  when                  to the cache
  -------------------------------------------------
  receiving INVITE(F1)  add index=1
  sending INVITE(F2)    add index=1.1
  receiving 302(F4)     include a Reason in index=1.1(last at the time)
  sending INVITE(F6)    add index=1.2
                        add index=1.2.1
  receiving 180(F7)     add nothig. but it is terrible, if 180 has index=1.2.1.x...
  time out(--)          include a Reason in index=1.2.1(last at the time)

therefore,
the SIP entity MUST include a Reason header field in the last
hi-entry "created by itself".

>Within that understanding, it seems to me that the Reason value should
>be added to hi-entry 1.2.1, because that is the hi-entry that
>corresponds to the INVITE that was sent from proxy "example.com" to
>Office.

I think so too.

>There is additional complexity because this is a case of "internal
>retargeting":  It is as if the proxy sent "INVITE
>sip:[e-mail]" (index 1.2) to another proxy, which sent
>"INVITE sip:office@192.0.2.5" (index 1.2.1).
>
>Clearly (?), "example.com" should apply "Reason=...408..." to hi-entry
>1.2.1, because that corresponds to the request that timed out.
>
>But it seems to me that "example.com", in its role as the upstream
>proxy which internally receives the 408 response from itself in its
>role as the downstream proxy, should apply "Reason=...408..." to
>hi-entry 1.2 as well.  (If the two proxies were separated, that is
>what would happen.)

it seems fine that both hi-entries(1.2 and 1.2.1) have a Reason header.
The last one MUST include it, another one "should" do it.

Regards,
Shinji.