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

From: [email-masked] (Dale R. Worley)
Date: Wed, 20 Feb 2013 15:49:44 -0500 (EST)

In draft-ietf-sipcore-rfc4244bis-callflows-02, I find the following
inconsistency.  Could people please advise me what the correct usage
is?

When a non-2xx final response is received by a proxy (or synthesized,
in the case of timeouts), the response code is to be placed in the
Reason header value in an hi-entry.  It turns out that there are two
plausible choices:  One place is the hi-entry corresponding to the
INVITE that was sent by the proxy and which matches the response
received, the "next hop" location.  The other place is the hi-entry
which is the address of the UA which generated the response, the
"leaf" location.

draft-ietf-sipcore-rfc4244bis-callflows-02 is not rich in failure
responses, but there are these examples, with the corresponding
hi-entries for the failed fork:

   3.1.  Sequentially Forking (History-Info in Response)

   History-Info: <sip:[email-masked]>;index=1.2;mp=1
   History-Info: <sip:[email-masked]?Reason=SIP%3Bcause%3D408>;\
                 index=1.2.1;index=1.2.1;rc=1.2

   3.6.  PBX Voicemail Example

   History-Info: <sip:[email-masked]>;index=1.2;mp=1
   History-Info: <sip:[email-masked]?Reason=SIP%3Bcause%3D408>;\
		      index=1.2.1;rc=1.2

   3.7.  Consumer Voicemail Example

   History-Info: <sip:[email-masked]?Reason=SIP%3Bcause%3D408>;\
                      index=1.2;mp=1
   History-Info: <sip:[email-masked]>;index=1.2.1;rc=1.2

As you can see, these are inconsistent.

My belief (which may be faulty) is that the "Reason" goes in hi-entry
corresponding to the INVITE that the proxy sent, because that's what
the proxy can easily determine.  Trying to find the right "leaf"
hi-entry to attach the Reason to would be quite complicated in some
forking cases.

What is the right answer?

Dale

---

From: OKUMURA Shinji <[email-masked]>
Date: Mon, 25 Feb 2013 19:02:56 +0900

Hi, Dale.

[email-masked] (Dale R. Worley)
Wed, 20 Feb 2013 15:49:44 -0500 (EST)
>What is the right answer?

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.

Regards,
Shinji.

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 26 Feb 2013 22:22:01 -0500 (EST)

> From: OKUMURA Shinji <[email-masked]>

[choosing one examle from several:]

> 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:[email-masked]" (index 1.2) to another proxy, which sent
"INVITE sip:[email-masked]" (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

---

From: OKUMURA Shinji <[email-masked]>
Date: Wed, 27 Feb 2013 17:22:45 +0900

Hi, Dale.

Thank you for your response, my comments inline.

[email-masked] (Dale R. Worley)
Tue, 26 Feb 2013 22:22:01 -0500 (EST)
>taken from the response itself are added to the cache later, in Step

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?

>intended to be the hi-entry upon which Step 2 and section 10.2

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

>corresponds to the INVITE that was sent from proxy "example.com" to

I think so too.

>hi-entry 1.2 as well.  (If the two proxies were separated, that is

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.