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

[[e-mail] (Dale R. Worley)]

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

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.

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.

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

Dale