Subject: [sipcore] Comments on draft-ietf-sipcore-rfc4244bis-07 - substantival questions

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 19 Apr 2012 22:34:10 -0400

Here are a few questions about how 4244bis operates in certain
situations.  They may have been discussed already.  If so, I hope that
they have straightforward answers (which would show that the mechanism
is clean and thought through).

I. Numbering of gaps

When an entity receives a request, it checks to see whether the last
hi-entry matches the request-URI, and if not, adds an hi-entry to
document the difference:

   6.  Missing entity: If the request clearly has a gap in the hi-entry
       (e.g. by evaluating via header to the existing request history to
       see if it traversed a domain which doesn't exist in History-Info
       header field.), the entity adding an hi-entry MUST add an index a
       digit of "0" to the current index prior to adding appropriate
       index for the action to be taken.  If the index of the last hi-
       entry in the request received was 1.1.2 and there was a missing
       hi-entry and the request was being forwarded to the next hop, the
       resulting index will be 1.1.2.0.1.

However, if in the un-logged processing of the request, the request
forked, the two forks can then receive hi-entries with the *same*
gap-indicating hi-index.  These hi-entries can be carried upstream in
responses and accumulate in the cache at some point upstream of the
gap, resulting in two entries in the cache with the same hi-index.

Modifying the example in Figure 1, assume that biloxi.example.com does
not understand H-I.  If I understand the details correctly, Bob@pc and
Bob@phone will independently create hi-entries with hi-index 1.1.0.
The two entries will be put into the cache at atlanta.exmple.com:

   Alice   atlanta.example.com  biloxi.example.com   Bob@pc  Bob@phone
   |                |                |                |          |
   |   INVITE sip:[email-masked];p=x          |          |
   |--------------->|                |                |          |
   | Supported: histinfo             |                |          |
   |                |                |                |          |
   |                |   INVITE sip:[email-masked];p=x    |
   |                |--------------->|                |          |
   | History-Info: <sip:[email-masked];p=x>;index=1      |
   | History-Info: <sip:[email-masked];p=x>;np=1;index=1.1
   |                |                |                |          |
   |                |                |   INVITE sip:[email-masked]|
   |                |                |--------------->|          |
   | History-Info: <sip:[email-masked];p=x>;index=1      |
   | History-Info: <sip:[email-masked];p=x>;np=1;index=1.1
   |                |                |                |          |
   | As modified by Bob@pc due to section 9.1:        |          |
   | History-Info: <sip:[email-masked];p=x>;index=1      |
   | History-Info: <sip:[email-masked];p=x>;np=1;index=1.1
   | History-Info: <sip:[email-masked]>;index=1.1.0    |          |
   |                |                |                |          |
   |                |                |   INVITE sip:[email-masked]|
   |                |                |-------------------------->|
   | History-Info: <sip:[email-masked];p=x>;index=1
   | History-Info: <sip:[email-masked];p=x>;np=1;index=1.1
   |                |                |                |          |
   | As modified by Bob@phone due to section 9.1:     |          |
   | History-Info: <sip:[email-masked];p=x>;index=1      |
   | History-Info: <sip:[email-masked];p=x>;np=1;index=1.1
   | History-Info: <sip:[email-masked]>;index=1.1.0    |          |
   |                |                |     4xx        |          |
   |                |                |<---------------|          |
   | History-Info: <sip:[email-masked];p=x>;index=1      |
   | History-Info: <sip:[email-masked];p=x>;np=1;index=1.1
   | History-Info: <sip:[email-masked]>;index=1.1.0    |          |
   |                |                |                |          |
   |                |     4xx        |                |          |
   |                |<---------------|                |          |
   | History-Info: <sip:[email-masked];p=x>;index=1      |
   | History-Info: <sip:[email-masked];p=x>;np=1;index=1.1
   | History-Info: <sip:[email-masked]>;index=1.1.0    |          |
   |                |                |                |          |
   |                |                |      200       |          |
   |                |                |<--------------------------|
   | History-Info: <sip:[email-masked];p=x>;index=1      |
   | History-Info: <sip:[email-masked];p=x>;np=1;index=1.1
   | History-Info: <sip:[email-masked]>;index=1.1.0    |          |
   |                |                |                |          |
   |     200        |                |                |          |
   |<---------------|                |                |          |
   | History-Info: <sip:[email-masked];p=x>;index=1      |
   | History-Info: <sip:[email-masked];p=x>;np=1;index=1.1
   | History-Info: <sip:[email-masked]&Reason=SIP%3Bcause%3D4xx>;index=1.1.0
   | History-Info: <sip:[email-masked]>;index=1.1.0    |          |
   |                |                |                |          |
   |     ACK        |                |                |          |
   |--------------->|    ACK         |                |          |
   |                |--------------->|     ACK        |          |
   |                |                |--------------->|          |

One way to avoid this problem is to add a random number after the "0",
so the hi-entries created by the two UASs are (probably) different:

   History-Info: <sip:[email-masked]>;index=1.1.0.42949
   History-Info: <sip:[email-masked]>;index=1.1.0.34317

To do this consistently and statelessly, one can hash the branch
parameter of the topmost Via of the incoming request, extract 16 bits
and add 1.  By the Birthday Paradox, using 16 bits for the number,
twenty forks can be accommodated with a low probability (0.3%) of
collision.

With this change, the final response would have this H-I:

   History-Info: <sip:[email-masked];p=x>;index=1
   History-Info: <sip:[email-masked];p=x>;np=1;index=1.1
   History-Info: <sip:[email-masked]>;index=1.1.0.34317
   History-Info: <sip:[email-masked]&Reason=SIP%3Bcause%3D4xx>;index=1.1.0.42949

This approach implies that H-I processing must allow index values of
at least 65537; otherwise 100 would suffice in practice and the limit
would not need to be specified.

II. Reason headers added by processing provisional responses

Looking at the example in section B.1 ... I don't see what I need,
which is the H-I from the 180 Ringing response or the 200 OK response
which is sent to Alice.  It would be useful to have those shown.

But based on section 10.2:

   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.

there must be a "Reason=SIP%3Bcause%3D180" attached to the URI in
hi-entry 1.2 because request 1.2 had a 180 response.

I suspect that my error is that the above rule is only intended to be
applied for (non-2xx) *final* responses.

III. What is added to "Reason" elements?

What gets added to "Reason" elements is:

- "Reason" header values received in responses

- SIP (final) failure response codes, if the response did not have a
  "Reason" header value

Have we deliberately excluded "SIP 2xx" reason values and SIP response
codes if an explicit Reason was provided?  At first glance, it seems
to me that a SIP failure final response code is always useful to know,
even if there was an accompanying Reason value.  But perhaps brevity
is more valuable.

IV. Locating the hi-entry corresponding to a message

By the algorithms, in a request, the final hi-entry corresponds to the
request and shows the request's position in the forking structure.
(Or rather, it will correspond if all SIP entities support H-I.)

But there is no such correspondence in a response, because a response
can carry hi-entries from responses to requests generated after the
request that generated the response.

As a simple case, a 4xx response with

   History-Info: <sip:[email-masked];p=x>;index=1
   History-Info: <sip:[email-masked]&Reason=SIP%3Bcause%3D4xx>;index=1.1
   History-Info: <sip:[email-masked]&Reason=SIP%3Bcause%3D4xx>;index=1.2

could have ultimately been generated by either sip:[email-masked] or
sip:[email-masked]; there is no way to distinguish the two cases.

There is no harm in this as long as we don't need the recipient of a
response to be able to determine the ultimate source of a response.

-------------------------------------------------------------------------------------

That is the last of my review comments.  Now I have to respond to the
authors' comments on my review comments.

Dale