Subject: [sipcore] 4244bis-callflows

From: [email-masked] (Dale R. Worley)
Date: Fri, 5 Oct 2012 15:25:00 -0400 (EDT)

I've done a little work on the callflows document.  I need some help
to iron out a couple of points.

1) There is something wrong with F6 in section 3.2.  It's not indented
like the messages.  And the 3rd History-Info contains "invalidtarget
userindex":

History-Info: <sip:[email-masked]>;index=1
History-Info: <sip:[email-masked];p=x>;index=1.1;rc=1
History-Info: <sip:[email-masked] userindex=1.1.1;rc=1.1

2) Here is another example I think is needed.  It shows the operation
of the rule for when a supporting entity receives a request proxied
through a non-supporting entity.  The index values are constructed
according to the text of 4244bis, but I'm not sure that the wording
exactly matches our intentions.

   This example provides a basic call scenario without forking.  The
   distinguishing feature is that the first proxy changes the
   request-URI but does not support History-Info.

   Alice   atlanta.example.com  cadiz.example.com    Bob
   |                |                |                |
   |   INVITE F1    |                |                |
   |--------------->|                |                |
   |                |                |                |
   |                |   INVITE F2    |                |
   |                |--------------->|                |
   |                |                |                |
   |                |                | INVITE F3      |
   |                |                |--------------->|
   |                |                |                |
   |                |                |     200 F4     |
   |                |                |<---------------|
   |                |                |                |
   |                |     200 F5     |                |
   |                |<---------------|                |
   |                |                |                |
   |     200 F6     |                |                |
   |<---------------|                |                |
   |                |                |                |
   |     ACK        |                |                |
   |--------------->|    ACK         |                |
   |                |--------------->|     ACK        |
   |                |                |--------------->|

   Figure: Example with a proxy that does not support History-Info

   Message Details

   F1 INVITE alice -> atlanta.example.com

   INVITE sip:[email-masked] SIP/2.0
   Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321
   From: Alice <sip:[email-masked]>;tag=22
   To: Bob <sip:[email-masked]>
   Supported: histinfo
   Call-Id: [email-masked]
   CSeq: 1 INVITE
   History-Info: <sip:[email-masked]>;index=1
   Contact: Alice <sip:[email-masked]>
   Content-Type: application/sdp
   Content-Length: <appropriate value>
   <!-- SDP Not Shown -->

   F2 INVITE  atlanta.example.com -> cadiz.example.com

   INVITE sip:[email-masked] SIP/2.0
   Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2
   Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321
   From: Alice <sip:[email-masked]>;tag=22
   To: Bob <sip:[email-masked]>
   Supported: histinfo
   Call-Id: [email-masked]
   CSeq: 1 INVITE
   History-Info: <sip:[email-masked]>;index=1
   Contact: Alice <sip:[email-masked]>
   Content-Type: application/sdp
   Content-Length: <appropriate value>
   <!-- SDP Not Shown -->

   F3 INVITE  cadiz.example.com -> Bob

   INVITE sip:[email-masked] SIP/2.0
   Via: SIP/2.0/TCP proxy.cadiz.example.com:5060;branch=z9hG4bK
   Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2
   Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321
   From: Alice <sip:[email-masked]>;tag=22
   To: Bob <sip:[email-masked]>
   Supported: histinfo
   Call-Id: [email-masked]
   CSeq: 1 INVITE
   History-Info: <sip:[email-masked]>;index=1
   History-Info: <sip:[email-masked]>;index=1.0.1
   History-Info: <sip:[email-masked]>;index=1.0.1.1;rc=1.0.1
   Contact: Alice <sip:[email-masked]>
   Content-Type: application/sdp
   Content-Length: <appropriate value>
   <!-- SDP Not Shown -->

   F4 200 OK  Bob -> cadiz.example.com

   SIP/2.0 200 OK
   Via: SIP/2.0/TCP proxy.cadiz.example.com:5060;branch=z9hG4bK
   Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2
   Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321
   From: Alice <sip:[email-masked]>;tag=22
   To: Bob <sip:[email-masked]>;tag=33
   Supported: histinfo
   Call-Id: [email-masked]
   CSeq: 1 INVITE
   History-Info: <sip:[email-masked]>;index=1
   History-Info: <sip:[email-masked]>;index=1.0.1
   History-Info: <sip:[email-masked]>;index=1.0.1.1;rc=1.0.1
   Contact: Bob <sip:[email-masked]>
   Content-Type: application/sdp
   Content-Length: <appropriate value>
   <!-- SDP Not Shown -->

   F5 200 OK  cadiz.example.com -> atlanta.example.com

   SIP/2.0 200 OK
   Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2
   Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321
   From: Alice <sip:[email-masked]>;tag=22
   To: Bob <sip:[email-masked]>;tag=33
   Supported: histinfo
   Call-Id: [email-masked]
   CSeq: 1 INVITE
   History-Info: <sip:[email-masked]>;index=1
   History-Info: <sip:[email-masked]>;index=1.0.1
   History-Info: <sip:[email-masked]>;index=1.0.1.1;rc=1.0.1
   Contact: Bob <sip:[email-masked]>
   Content-Type: application/sdp
   Content-Length: <appropriate value>
   <!-- SDP Not Shown -->

   F6 200 OK  atlanta.example.com -> Alice

   SIP/2.0 200 OK
   Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321
   From: Alice <sip:[email-masked]>;tag=22
   To: Bob <sip:[email-masked]>;tag=33
   Supported: histinfo
   Call-Id: [email-masked]
   CSeq: 1 INVITE
   History-Info: <sip:[email-masked]>;index=1
   History-Info: <sip:[email-masked]>;index=1.0.1
   History-Info: <sip:[email-masked]>;index=1.0.1.1;rc=1.0.1
   Contact: Bob <sip:[email-masked]>
   Content-Type: application/sdp
   Content-Length: <appropriate value>
   <!-- SDP Not Shown -->

Question:  Item 6 of section 10.3 seems ambiguous to me.  Currently,
it reads:

   6.  Missing entity: If the request clearly has a gap in the hi-entry
       (i.e., the last hi-entry and Request-URI differ), the entity
       adding an hi-entry MUST add a single index with a value of "0"
       (i.e., the non-negative integer zero) prior to adding the
       appropriate index for the action to be taken.  For example, 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.

Following the reference to it in section 9.1, upon receipt of message
F1, cadiz.example.com would have to add this to the message:

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

adding a value of 0 and then the "appropriate index for the action to
be taken" (which clearly must be 1 whenever we are doing the section
9.1 processing).

Then upon sending F2, cadiz.example.com would have to add

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

Is this what is intended, or do we want to have the final History-Info
be:

   History-Info: <sip:[email-masked]>;index=1
   History-Info: <sip:[email-masked]>;index=1.0
   History-Info: <sip:[email-masked]>;index=1.0.1;rc=1.0.1

using the "0" alone to represent "unknown forwarding/branching at this
point"?

3) Here is another example, where a request is forked by a
non-supporting proxy.  Unfortunately, it leads to a situation where
there are duplicate indexes in the History-Info list.

   This is an example where a proxy/registrar forks the call to
   several alternative destinations.  The proxy/registrar does not
   support History-Info but the destinations do.

   Alice   atlanta.example.com  biloxi.example.com   Bob    Office
   |                |                |                |        |
   |   INVITE F1    |                |                |        |
   |--------------->|                |                |        |
   |                |                |                |        |
   |                |   INVITE F2    |                |        |
   |                |--------------->|                |        |
   |                |                |                |        |
   |                |                | INVITE F3      |        |
   |                |                |--------------->|        |
   |                |                |                |        |
   |                |                | 180 Ringing F4 |        |
   |                |                |<---------------|        |
   |                |                |                |        |
   |                |   180 Ringing F5                |        |
   |                |<---------------|                |        |
   |                |                |                |        |
   |   180 Ringing F6                |                |        |
   |<---------------|                |                |        |
   |                |                |                |        |
   |                |                | 408 Timeout F7 |        |
   |                |                |<---------------|        |
   |                |                |                |        |
   |                |                | INVITE F8      |        |
   |                |                |------------------------>|
   |                |                |                |        |
   |                |                | 180 Ringing F9 |        |
   |                |                |<------------------------|
   |                |                |                |        |
   |                |   180 Ringing F10               |        |
   |                |<---------------|                |        |
   |                |                |                |        |
   |   180 Ringing F11               |                |        |
   |<---------------|                |                |        |
   |                |                |                |        |
   |                |                | 200 OK F12     |        |
   |                |                |<------------------------|
   |                |                |                |        |
   |                |   200 OK F13   |                |        |
   |                |<---------------|                |        |
   |                |                |                |        |
   |    200 OK F14  |                |                |        |
   |<---------------|                |                |        |
   |                |                |                |        |
   |     ACK        |                |                |        |
   |--------------->|    ACK         |                |        |
   |                |--------------->|     ACK        |        |
   |                |                |------------------------>|

	     Example with forking by non-supporting proxy

   Note that atlanta.example.com and all the UAs support History-Info;
   biloxi.example.com does not.

   F1 INVITE alice -> atlanta.example.com

   INVITE sip:[email-masked] SIP/2.0
   Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321
   From: Alice <sip:[email-masked]>;tag=22
   To: Bob <sip:[email-masked]>
   Supported: histinfo
   Call-Id: [email-masked]
   CSeq: 1 INVITE
   History-Info: <sip:[email-masked]>;index=1
   Contact: Alice <sip:[email-masked]>
   Content-Type: application/sdp
   Content-Length: <appropriate value>
   <!-- SDP Not Shown -->

   F2 INVITE  atlanta.example.com -> biloxi.example.com

   INVITE sip:[email-masked] SIP/2.0
   Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2
   Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321
   From: Alice <sip:[email-masked]>;tag=22
   To: Bob <sip:[email-masked]>
   Supported: histinfo
   Call-Id: [email-masked]
   CSeq: 1 INVITE
   History-Info: <sip:[email-masked]>;index=1
   History-Info: <sip:[email-masked]>;index=1.1;rc=1
   Contact: Alice <sip:[email-masked]>
   Content-Type: application/sdp
   Content-Length: <appropriate value>
   <!-- SDP Not Shown -->

   F3 INVITE  biloxi.example.com -> Bob

   INVITE sip:[email-masked] SIP/2.0
   Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=z9hG4bK
   Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2
   Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321
   From: Alice <sip:[email-masked]>;tag=22
   To: Bob <sip:[email-masked]>
   Supported: histinfo
   Call-Id: [email-masked]
   CSeq: 1 INVITE
   Expires: 30
   History-Info: <sip:[email-masked]>;index=1
   History-Info: <sip:[email-masked]>;index=1.1;rc=1
   Contact: Alice <sip:[email-masked]>
   Content-Type: application/sdp
   Content-Length: <appropriate value>
   <!-- SDP Not Shown -->

   F4 180 Ringing  bob -> biloxi.example.com

   SIP/2.0 180 Ringing
   Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=z9hG4bK
   Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2
   Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321
   From: Alice <sip:[email-masked]>;tag=22
   To: Bob <sip:[email-masked]>;tag=33
   Supported: histinfo
   Call-Id: [email-masked]
   CSeq: 1 INVITE
   History-Info: <sip:[email-masked]>;index=1
   History-Info: <sip:[email-masked]>;index=1.1;rc=1
   History-Info: <sip:[email-masked]>;index=1.1.0.1
   Contact: Bob <sip:[email-masked]>
   Content-Type: application/sdp
   Content-Length: <appropriate value>
   <!-- SDP Not Shown -->

   F5 180 Ringing  biloxi.example.com -> atlanta.example.com

   SIP/2.0 180 Ringing
   Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2
   Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321
   From: Alice <sip:[email-masked]>;tag=22
   To: Bob <sip:[email-masked]>;tag=33
   Supported: histinfo
   Call-Id: [email-masked]
   CSeq: 1 INVITE
   History-Info: <sip:[email-masked]>;index=1
   History-Info: <sip:[email-masked]>;index=1.1;rc=1
   History-Info: <sip:[email-masked]>;index=1.1.0.1
   Contact: Bob <sip:[email-masked]>
   Content-Type: application/sdp
   Content-Length: <appropriate value>
   <!-- SDP Not Shown -->

   F6 180 Ringing  atlanta.example.com -> alice

   SIP/2.0 180 Ringing
   Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321
   From: Alice <sip:[email-masked]>;tag=22
   To: Bob <sip:[email-masked]>;tag=33
   Supported: histinfo
   Call-Id: [email-masked]
   CSeq: 1 INVITE
   History-Info: <sip:[email-masked]>;index=1
   History-Info: <sip:[email-masked]?Reason=SIP%3Bcause%3D180>;index=1.1;rc=1
   History-Info: <sip:[email-masked]>;index=1.1.0.1
   Contact: Bob <sip:[email-masked]>
   Content-Type: application/sdp
   Content-Length: <appropriate value>
   <!-- SDP Not Shown -->

Note that atlanta added a Reason parameter to entry 1.1, due to
receiving a 180 from that branch of the call.

   F4 408 Timeout  bob -> biloxi.example.com

   SIP/2.0 408 Timeout
   Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=z9hG4bK
   Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2
   Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321
   From: Alice <sip:[email-masked]>;tag=22
   To: Bob <sip:[email-masked]>;tag=33
   Supported: histinfo
   Call-Id: [email-masked]
   CSeq: 1 INVITE
   History-Info: <sip:[email-masked]>;index=1
   History-Info: <sip:[email-masked]>;index=1.1;rc=1
   History-Info: <sip:[email-masked]>;index=1.1.0.1
   Contact: Bob <sip:[email-masked]>
   Content-Type: application/sdp
   Content-Length: <appropriate value>
   <!-- SDP Not Shown -->

   F8 INVITE  biloxi.example.com -> office

   INVITE sip:[email-masked] SIP/2.0
   Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=z9hG4bKxyz
   Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2
   Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321
   From: Alice <sip:[email-masked]>;tag=22
   To: Bob <sip:[email-masked]>
   Supported: histinfo
   Call-Id: [email-masked]
   CSeq: 1 INVITE
   Expires: 30
   History-Info: <sip:[email-masked]>;index=1
   History-Info: <sip:[email-masked]>;index=1.1;rc=1
   Contact: Alice <sip:[email-masked]>
   Content-Type: application/sdp
   Content-Length: <appropriate value>
   <!-- SDP Not Shown -->

   F9 180 Ringing  office -> biloxi.example.com

   SIP/2.0 180 Ringing
   Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=z9hG4bKxyz
   Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2
   Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321
   From: Alice <sip:[email-masked]>;tag=22
   To: Bob <sip:[email-masked]>;tag=33
   Supported: histinfo
   Call-Id: [email-masked]
   CSeq: 1 INVITE
   History-Info: <sip:[email-masked]>;index=1
   History-Info: <sip:[email-masked]>;index=1.1;rc=1
   History-Info: <sip:[email-masked]>;index=1.1.0.1
   Contact: Office <sip:[email-masked]>
   Content-Type: application/sdp
   Content-Length: <appropriate value>
   <!-- SDP Not Shown -->

   F10 180 Ringing  biloxi.example.com -> atlanta.example.com

   SIP/2.0 180 Ringing
   Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2
   Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321
   From: Alice <sip:[email-masked]>;tag=22
   To: Bob <sip:[email-masked]>;tag=33
   Supported: histinfo
   Call-Id: [email-masked]
   CSeq: 1 INVITE
   History-Info: <sip:[email-masked]>;index=1
   History-Info: <sip:[email-masked]>;index=1.1;rc=1
   History-Info: <sip:[email-masked]>;index=1.1.0.1
   Contact: Office <sip:[email-masked]>
   Content-Type: application/sdp
   Content-Length: <appropriate value>
   <!-- SDP Not Shown -->

   F11 180 Ringing  atlanta.example.com -> alice

   SIP/2.0 180 Ringing
   Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321
   From: Alice <sip:[email-masked]>;tag=22
   To: Bob <sip:[email-masked]>;tag=33
   Supported: histinfo
   Call-Id: [email-masked]
   CSeq: 1 INVITE
   History-Info: <sip:[email-masked]>;index=1
   History-Info: <sip:[email-masked]?Reason=SIP%3Bcause%3D180>;index=1.1;rc=1
   History-Info: <sip:[email-masked]>;index=1.1.0.1
   History-Info: <sip:[email-masked]>;index=1.1.0.1
   Contact: Office <sip:[email-masked]>
   Content-Type: application/sdp
   Content-Length: <appropriate value>
   <!-- SDP Not Shown -->

atlanta needs to record a Reason specifying response 180 in index
1.1.  It presumably replaces the previous Reason 180 in that entry.

At this point, there is a problem regarding sorting the History-Info
entries correctly:  atlanta.example.com added
"<sip:[email-masked]>;index=1.1.0.1" to its cache due to receiving F5,
and added "<sip:[email-masked]>;index=1.1.0.1" due to receiving
F10, but there is no defined ordering between them.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 05 Oct 2012 15:58:26 -0400

Hi Dale,

Thanks for the review.
I'm trying to discern what sort of coverage this gives us on the 
document as a whole.

Is the issue you raise with the 3.2 case the only issue you have with 
it? Do you consider it to otherwise be ok?

IIUC, the other cases you give are *new* cases that you think are 
needed. Is that right?

And, does your lack of mention of any other cases imply that you have 
not considered them? Or that you looked at them and found them ok?

	Thanks,
	Paul

> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 8 Oct 2012 14:23:39 -0400 (EDT)

> From: Paul Kyzivat <[email-masked]>
> 
> Thanks for the review.

At this point, I've only looked at 4244bis-callflows enough to see
that there are no cases exercising the rules that deal with
non-supporting proxies.  While trying to write up examples of that, I
found an error in the algorithms of 4244bis, and error that doesn't
have an obvious fix.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 08 Oct 2012 14:40:54 -0400

> found an error in the algorithms of 4244bis, and error that doesn't

Thanks Dale!

EVERYBODY INTERESTED IN 4244bis:

This is an example of why we NEED to have careful reviews of the callflows.

So far I have been deafened by the silence.
There was quite a bit of enthusiasm for both the bis and the callflows 
as long as it only took an email containing "+1".
Who, other than the authors, wants these enough to do some work???

	Thanks,
	Paul (as co-chair)

---

From: Mary Barnes <[email-masked]>
Date: Mon, 8 Oct 2012 14:08:40 -0500

I'm confused as to the issue you noted where there isn't an obvious fix -
can you clarify what that is?  I'll respond inline to your detailed review.

I will also note that 4244 also didn't have examples of a non-supporting
proxy and it's not the usual that we have those examples in any of our
documents when we are defining optional headers.

Mary.

---

From: Shida Schubert <[email-masked]>
Date: Tue, 9 Oct 2012 09:11:27 +0900

Hi Dale;

 Thanks for your review, my comments inline..

> History-Info: <sip:[email-masked] userindex=1.1.1;rc=1.1

It was supposed to be <sip:[email-masked]>;index=1.1.1;rc=1.1

>   Alice   atlanta.example.com  cadiz.example.com    Bob

 I thinks this is a useful example. 

 As for the indexing the gap, I think we need the 1 as the 
draft currently specifies. 

 The receiving entity can in fact, if able to identify the forked message 
to be the same message, provide appropriate index. (looking at the 
dialog identifier etc.)

 For example, if the call was forked upstream and reaches the 
same entity downstream, the downstream entity by identifying 
the request to be sourced from the same message, can add 
unique index.

 e.g. 1.0.1 to the first receiving forked request
         1.0.2 to the next

>   Alice   atlanta.example.com  biloxi.example.com   Bob    Office

 Hmm.. I really don't see the issues here. 

 Sure, there are duplicate entries but receiving entity and sending 
entity can both get useful information out of this. 

 Receiving entity (UAS)
   The request was sent to bob but ultimately was received 
     at office (Because UAS serving office knows that it formed a 
     dialog with alice). It can see that path it took..
 
 Sending entity (UAC)
   Again it knows that it has established a dialog  with office 
     and depending on how it is implemented, it will probably 
     knows that bob was tried as well. 
 
 I see that even with the duplicate entries, entities that are likely 
to utilize the information can make use of the H-I entries. 

 Thanks for your comments
   Shida

---

From: Mary Barnes <[email-masked]>
Date: Tue, 9 Oct 2012 09:59:19 -0500

I have responses below to 1) and 2).  Shida addressed 3).

Mary.

On Fri, Oct 5, 2012 at 2:25 PM, Dale R. Worley <[email-masked]> wrote:

> History-Info: <sip:[email-masked]=1.1.1;rc=1.1
>

[MB] We'll fix that. [/MB]

>    Alice   atlanta.example.com  cadiz.example.com    Bob
[MB] We want the latter as is highlighted by the example. Per 4244bis, the
entity that receives a request from a non-supporting entity adds an
hi-entry on behalf of the entity sending the request.  The "0" indicates
that the hi-entries prior to this one may not reflect the complete history.
Note that this section describes how one calculates the index.  But, I
think we did lose something from the spirit of 4244 that should be
corrected.  We can add the following qualifications to highlight the index
is being added the hi-entry that is being added on behalf of the entity
that doesn't support history-Info, something like the following:

6.  Missing entity: If the request clearly has a gap in the hi-entry
       (i.e., the last hi-entry and Request-URI differ), the entity
       MUST add the missing hi-entry with an index with
       a value of "0" (i.e., the non-negative integer zero)
       prior to adding the hi-entry with the
       appropriate index for the action to be taken.  For example, 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.

[/MB]

> there are duplicate indexes in the History-Info list.
[MB] I think Shida answered this one. [/MB]

>    History-Info: <sip:[email-masked]?Reason=SIP%3Bcause%3D180
> >;index=1.1;rc=1
>    History-Info: <sip:[email-masked]?Reason=SIP%3Bcause%3D180
> >;index=1.1;rc=1

---

From: <[email-masked]>
Date: Wed, 10 Oct 2012 13:14:38 +0200

Hi,
I have looked on Example 3.2 and have a question.

4244bis states that:

10.1.2.  Applying Privacy

   When a SIP message is forwarded to a domain for which the SIP
   intermediary is not responsible, a Privacy Service at the boundary of
   the domain applies the appropriate privacy based on the value of the
   Privacy header field in the message header or in the "headers"
   component of the hi-targeted-to-uri in the individual hi-entries.

Now within the example privacy is only applied for one Entry as follows.
   F2 INVITE  example.com -> Bob

   INVITE sip:[email-masked];p=x SIP/2.0

So my question is if really only one entry has to be deleted or both.
Because the privacy service mut know the routing target which is within the Request URI.
So if the Request URI is known then also the History Info entry is known.
Now privacy apply. Privacy = history then all known history entries has to be anonymised. In this case both entries has to be deleted.

So question is now what has to be applied and why. Is my assumption correct or wrong?

With regard to that answer we should put some wording into the use case description how the privacy header field has to be interpreted.

Best Regards

Roland

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 10 Oct 2012 11:47:43 -0400

Laura Leiss has graciously agreed to review cases 3.1, 3.4, 3.6.
We have also had a partial review of 3.2 by Dale.

So we only need volunteers for the other 7.5.

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 10 Oct 2012 16:32:52 -0400 (EDT)

> We have also had a partial review of 3.2 by Dale.

I think you mean Roland there.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 10 Oct 2012 16:59:21 -0400 (EDT)

> From: Mary Barnes <[email-masked]>
> 

It is true that examples showing interoperation with non-supporting
elements are not often given.  But in *this* case, it is not trivial
to arrange that a non-supporting proxy within a call of supporting
elements works in a way that is useful, and in particular, the
mechanism we have defined includes specific actions to make that use
case work.  Because of this, it is useful to provide an example
showing exactly how the use case operates.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 10 Oct 2012 17:13:07 -0400 (EDT)

> From: Shida Schubert <[email-masked]>
> 

The core issue is this:

    Are two entries with the same index value allowed in History-Info?

No specific answer is given to this question in rfc4244bis.  (This is
part of my complaint that the draft does not enunciate the constraints
of the History-Info values.)

The entirety of rfc4424bis is written in a way that *suggests*, but
does not *state*, that no two entries in History-Info may have the
same index.  For example, all of the following passages suggest that
the lexicographic preorder of the indexes puts the History-Info
entries into a unique and well-defined order:

      By adding the new entries in order (i.e., following existing
      entries per the details in Section 10.3), [...]

   The hi-entries MUST be added to the cache in the order in
   which they were received in the request.

   The hi-entries in the outgoing request's History-Info header field
   is the preorder of the tree of hi-entries, that is, by the
   lexicographic ordering of the hi-indexes.

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

Similarly, the descriptions of the "rc", "mp", and "np" parameters
presume that the value of the parameter species *exactly one*
hi-entry:

         The "rc" header field parameter contains the value of the
         hi-index in the hi-entry with an hi-targeted-to-uri that
         reflects the Request-URI that was retargeted

It turns out that the algorithms defined in rfc4244bis will at times
insert two hi-entries with the *same* index value.  There are two
solutions:

One solution is to affirm that no two entries can exist with the same
index.  To do that, we must change the algorithm so that it doesn't
create that situation.

The other solution is to affirm that two entries *can* exist with the
same index.  That requires that we:  (1) Clearly warn the reader that
this can happen, so that implementers are not misled; (2) Revise all
the above passages to make clear what should be done when there are
multiple entries with the same index; and (3) Adjust how the "rc",
"mp", and "np" parameters are to be handled, given that their values
are not guaranteed to specify a unique hi-entry.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 10 Oct 2012 17:19:13 -0400 (EDT)

>  e.g. 1.0.1 to the first receiving forked request

Currently, at least as I read the text, the construction of the
indexes of new hi-entries on the outgoing forks of two different
incoming requests are done independently.  It seems to me that you are
suggesting that with two different forks of one request entering the
entity (and trigger the "0" processing) should have their new indexes
assigned in a way that take each other into account.

If you want to prescribe that behavior, it should be clearly specified
in the text.

As far as I can tell, in all cases, when a "0" is added to an index,
"1" must be added following it, because any forking of outgoing
requests is indicated by the *next* index component.  That is, "0" is
required to be followed by a "1".

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 10 Oct 2012 18:19:24 -0400 (EDT)

> [MB] We want the latter as is highlighted by the example. 

OK, that makes more sense to me.  I hadn't fully noticed the example
in section 10.3 item 6.

Of course, that means my example needs to be updated.

> Per 4244bis, the

I think that the relevant text (sections 9.1 and 10.3 item 6) is less
clear than it might be.  May I suggest the marked changes:

   9.1.  Receiving a Request
   [...]
   If the Request-URI of the incoming request does not match the hi-
   targeted-to-uri in the last hi-entry (i.e., the previous SIP entity
   that sent the request did not include a History-Info header field),
   the SIP entity MUST add a hi-entry to end of the cache, on behalf of
   the previous SIP entity before proceeding to Section 9.2, as follows:

      The SIP entity MUST set the hi-targeted-to-uri to the value of the
      Request-URI in the incoming request.  If the Request-URI is a Tel-
      URI, it SHOULD be transformed into a SIP URI per section 19.1.6 of
      [RFC3261] before being added as a hi-targted-to-uri.

      If privacy is required, the SIP entity MUST follow the procedures
      of Section 10.1.

      The SIP entity MUST set the hi-index parameter as described in
>     Section 10.3, that is, the hi-index will be the hi-index of the
>     previously last hi-entry, with the number "0" appended.

      The SIP entity MUST NOT include an "rc", "mp" or "np" header field
      parameter.

   10.3.  Indexing in the History-Info Header Field
   [...]
>  6.  Missing entity: When a request is received that clearly has a
>      gap in the hi-entries (i.e., the last hi-entry and Request-URI
>      differ), before other processing of History-Info, the receiver
>      must (section 9.1) add an hi-entry whose index value is that of
>      the previously last hi-entry, with an appended number "0"
>      (i.e., the non-negative integer zero).  This new hi-entry's
>      index value becomes the base from which will be constructed the
>      indexes of the hi-entries added to forwarded requests (section 9.2).
>
>      For example, 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 is forwarded to a next hop, the forwarded request will
>      have two additional hi-entries, one containing the incoming
>      Request-URI with the index 1.1.2.0 (section 9.1) and one
>      containing the outgoing Request-URI with the index 1.1.2.0.1
>      (section 9.2).  A second outgoing request to another
>      destination will have added hi-entries with the indexes 1.1.2.0
>      and 1.1.2.0.2.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 10 Oct 2012 18:27:13 -0400 (EDT)

> [MB] We want the latter as is highlighted by the example.

One interesting consequence of using the latter method is that if a
non-supporting proxy is the *last* proxy before the UAS, then the
*final* hi-entry (as they are reported back to the UAC) will have an
index that ends in "0".  There's nothing contradictory about that, but
it is not something you'd expect at first.

Dale

---

From: Shida Schubert <[email-masked]>
Date: Thu, 11 Oct 2012 12:41:31 +0900

Hi Dale;

 My comments inline..

>    Are two entries with the same index value allowed in History-Info?

 As far as I know RFC4244 doesn't have any mechanism to 
prevent this from happening, so yes it could happen. Whether this 
will happen in reality, I am not sure.. 

>      hi-entries (e.g., 1.2.1 comes after 1.2 but before 1.2.2 or

 This holds true for entity supporting the history-info and setting 
the hi-entries.. It doesn't say anything about receiving such 
duplicate information... The current spec about generating index 
on the outgoing request holds true, it is handling of requests with 
duplicate index that is not specified currently.

> index.  To do that, we must change the algorithm so that it doesn't

 You mean to create some sort of hash etc., to make each 
hi-entry a unique value and reference that instead of hi-index to 
show the correlation? Or add the uri of the processing entity to 
identify each hi-entry as a unique entry? That to me seems like an 
overkill. Furthermore with 4244 being deployed already and potentially 
allowing duplicate index on the path, don't know how much this helps.

> are not guaranteed to specify a unique hi-entry.

 (1) agree, (2) The only place I see where change is needed is to add 
some text about handling duplicate hi-index in receiving requests. 4244 
entity will not be able to sanitize the duplicate hi-index, so adding this 
behavior may help but will not solve the already existing problem with 
4244 out there (If we believe that this is a problem).. 

 Thanks
  Shida

---

From: Shida Schubert <[email-masked]>
Date: Thu, 11 Oct 2012 12:44:03 +0900

Hmm.. 

 No you wouldn't because it is the entity forwarding the 
request that always set the hi-entry of the outgoing request.

 In the following case, it is the entity that set the 

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

 that also sets the 

>>> History-Info: <sip:[email-masked]>;index=1.0.1;rc=1.0.1

 before forwarding the request to [email-masked].

 0 never hangs by itself, because an entity that sets the 
0 to the incoming request MUST set index and hi-entry to the 
outgoing request as well. 

 Regards
  Shida

---

From: <[email-masked]>
Date: Thu, 11 Oct 2012 08:16:24 +0200

Hi Paul,
I'm looking for 3.3, 3.5 and 3.7

Roland

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Paul Kyzivat
Gesendet: Mittwoch, 10. Oktober 2012 17:48
An: [email-masked]
Betreff: Re: [sipcore] VOLUNTEERS NEEDED: Another WGLC for draft-ietf-sipcore-rfc4244bis-callflows-01

        Thanks,
        Paul

---

From: <[email-masked]>
Date: Thu, 11 Oct 2012 08:56:50 +0200

Hi,
Review for 3.3 (including parts of 3.2)

1. History-Info included by the UAC
 Why does put the UA an History-Info into the INVITE? Of course the UA is allowed to do it but why?
My understanding of H-I is to track changes due to retargeting and forwarding. The UAC does not know what will happen with the Request URI.
Nevertheless I have no problem since this is an example. But I do not see an value add. (This comment belongs also to other use cases)

2. F2 INVITE
...
 History-Info: <sip:[email-masked];p=x>;index=1
   History-Info: <sip:[email-masked];p=x>;index=1.1;rc=1
...

Why is there an entry added with rc?
There is no change of the request URI therefore no reason to add anything.

This comment belongs at also to call flow 3.2 even the first entry is anonymized the 2nd has the same information.

So in 3.2 the flows indicates
F1 INVITE
...
   History-Info: <sip:[email-masked];p=x>;index=1
...

F2 INVITE

...
...

--> 2nd entry is wrong there was no retargeting/change within the request URI.

3. History-Info forwarded to the UAS
Why is the History-Info forwarded to the UAS?
That is only allowed when the UAS is within the same trust domain.
Either this must mentioned explicitly within the description or the entry has to be anonymized.

4. Question is why we have this use case?
Because in 3.2 we have already a privacy value of an entry. So from my side it is already covered by 3.2.
Which leads me to the question which privacy scenarios should be shown within the call flows.
--> I would propose to change 3.2 without an entry privacy.

Best Regards

Roland

---

From: <[email-masked]>
Date: Thu, 11 Oct 2012 13:28:15 +0200

Hi,
Review for 3.5

Main focus on this use case is UAS.
So with regard
to the UAC it is not needed that UAC supports historyinfo.
Only UAS has to do it.

Perhaps that should be mentioned within the use case.
It will be the same behaviour when the call comes from the PSTN via an MGC.
So the shown content is independent on the information given within INVITE F3.

Also in this case it is not needed that the UAC includes the History-Info. Why?

Minor editorial:
Text first paragraph:
Within the IMS the Public User Identity is used --> replacement of public identity by public user identity (PUID) is proposed.

Best Regards

Roland

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 11 Oct 2012 11:29:43 -0400

> I'm looking for 3.3, 3.5 and 3.7

Thank you Roland!

I see you have already sent comments and questions about a couple of 
these. Not surprisingly your initial comments are about the details of 
the H-I entries, which is entirely reasonable, and deserves the most 
focus. However I do request that you do your best to verify all aspects 
of the messages for correctness.

When do you expect to be finished reviewing?

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 11 Oct 2012 12:45:19 -0400 (EDT)

>  before forwarding the request to [email-masked].

Uh, what?

If a UAS receives a request where the request-URI does not match the
last hi-entry, the rules of section 9.1 "Receiving a Request" apply --
it must add an hi-entry describing the request-URI that it sees.  That
hi-entry's index will end with "0", and it will be the last hi-entry
in the cache.

Being a UAS, it does not forward the request anywhere.

But being a UAS, it sends a response, and that response contains all
the hi-entries in the cache, one of which is the hi-entry added during
the section 9.1 processing.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 11 Oct 2012 12:51:08 -0400 (EDT)

> will happen in reality, I am not sure.. 

I have previously posted a detailed example showing how it could
happen.  See
http://www.ietf.org/mail-archive/web/sipcore/current/msg05220.html,
item 3.  You may consider it to be unrealistic, but it seems quite
realistic to me.  That situation will arise any time a non-supporting
proxy forks a request to two supporting destinations.

Dale

---

From: Shida Schubert <[email-masked]>
Date: Fri, 12 Oct 2012 11:50:23 +0900

I see, you are talking about UAS receiving a request 
with gap in H-I. 

 In which case, you are right that the last entry will be 
that of its own and you would end up with 0 at the 
end of the hi-inex. 

 Regards
  Shida

---

From: Shida Schubert <[email-masked]>
Date: Fri, 12 Oct 2012 12:47:48 +0900

Hi Dale;

 I agree, this can happen. I was just thinking about our 
network.. Where this is not likely to happen.. 

 Anyway, what do you suggest we do? Do we just make 
a note stating that this can happen and when this 
happens, information will not be as useful unless the 
entity utilizing the hi-entries have extended knowledge 
of the network?? OR make use of other information 
such as (associated response code etc.) 

 Or do we add another layer of complexity to already 
complex mechanism? 

 Regards
  Shida

---

From: <[email-masked]>
Date: Fri, 12 Oct 2012 07:35:20 +0200

Sorry wrong Headline It is the review for 3.5

-----Ursprüngliche Nachricht-----
Von: Jesske, Roland
Gesendet: Donnerstag, 11. Oktober 2012 13:28
An: [email-masked]'; [email-masked]'
Betreff: WGLC 4244bis-callflows Use Case 3.3 (3.2)

Hi,
Review for 3.5

Minor editorial:
Text first paragraph:

Best Regards

Roland

---

From: <[email-masked]>
Date: Fri, 12 Oct 2012 13:55:08 +0200

Hi Paul,
I hope till Sunday latest on Monday.

Best Regards

Roland

-----Ursprüngliche Nachricht-----
Von: Paul Kyzivat [mailto:[email-masked]]
Gesendet: Donnerstag, 11. Oktober 2012 17:30
An: Jesske, Roland
Cc: [email-masked]
Betreff: Re: AW: [sipcore] VOLUNTEERS NEEDED: Another WGLC for draft-ietf-sipcore-rfc4244bis-callflows-01

Thank you Roland!

I see you have already sent comments and questions about a couple of these. Not surprisingly your initial comments are about the details of the H-I entries, which is entirely reasonable, and deserves the most focus. However I do request that you do your best to verify all aspects of the messages for correctness.

        Thanks,
        Paul

> Betreff: Re: [sipcore] VOLUNTEERS NEEDED: Another WGLC for
> draft-ietf-sipcore-rfc4244bis-callflows-01
>
>> There was quite a bit of enthusiasm for both the bis and the
>> callflows as long as it only took an email containing "+1".

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 12 Oct 2012 12:37:33 -0400 (EDT)

> such as (associated response code etc.) 

Well, we could just live with the problem.  We do have to warn
implementers, because an implementation must not drop one of a pair of
hi-entries with duplicate indexes, and the "obvious" implementations
might do that.

A problem with that approach is that the situation would arise
consistently for any call that originated from a supporting system,
was forked within a non-supporting system, and had two destinations in
supporting systems.  (And that can happen with "call forward on no
answer" and "call forward on busy".)

The number of caller/called-directory-number combinations that cause
that pattern would probably be small, but for such a combination,
*every* call would produce the *same* sort of problematic
History-Info.

> Or do we add another layer of complexity to already complex
> mechanism?

I'd phrase it, "Fix the problem with a minimum of additional
complexity."

We could use a version of what I suggested in my e-mail of 19 Apr 2012
during the WGLC
(http://www.ietf.org/mail-archive/web/sipcore/current/msg04830.html)
-- which I notice that nobody responded to:

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

The essential idea is that any entity adding a "0" hi-entry follows
the "0" with a random number taken from a sufficiently large set.
(One way to generate such random numbers is to hash the branch
parameter of the topmost Via, which has the advantage of being
stateless.)  If the range of the random numbers is sufficiently large,
the chances of the entities on two branches choosing the same number
is small enough that there isn't a problem in practice.

We can use the "birthday paradox" formulas to determine the needed
range for the random numbers. If:

k = maximum number of forks expected within the non-supported proxies
within the "gap"

L = probability of the hi-entries generated by the k forks having
duplicate random number parts

n = range of the generated random numbers

then the minimum range is (to a close approximation):

n = k^2 / 2*L

A conservative choice is k (maximum number of forks) = 10 and L =
10^-5 ("five nines" reliability), which gives n = 5,000,000.  That
requires 7 digit random numbers.  Adjusting the assumptions will
change the needed range, of course.

Given that the needed range is only half of the range of seven-digit
numbers, we could restrict the range to 1000000 to 9999999, and
eliminate the "0", since any number with seven digits could only come
from gap processing.  This would make the final response in the above
example:

    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.3431783
    History-Info: <sip:[email-masked]&Reason=SIP%3Bcause%3D4xx>;index=1.1.4294938

There may be better solutions, though.

Dale

---

From: Mary Barnes <[email-masked]>
Date: Fri, 12 Oct 2012 11:40:52 -0500

> such as (associated response code etc.)
[MB] My opinion is that we perhaps expand the text in the application
consideration section. We already highlight that this can happen.  But, I
absolutely do not believe it's useful to complicate the protocol. Note, we
already discussion backwards compatibility issues in section 16.1.  I would
like to understand what might be missing and not quite so clear in these
sections than add *anything* into the body of the document.[/MB]

---

From: Mary Barnes <[email-masked]>
Date: Fri, 12 Oct 2012 11:46:14 -0500

> *every* call would produce the *same* sort of problematic
[MB] Per the response I just sent, we already address this in sections 11
(Application considerations) and section 16.1 (Backwards compatibility).
Please review those sections and provide text that you think is missing or
might be helpful. [/MB]

> >    History-Info: <sip:[email-masked]
> &Reason=SIP%3Bcause%3D4xx>;index=1.1.0.42949
>
>     History-Info: <sip:[email-masked]
> &Reason=SIP%3Bcause%3D4xx>;index=1.1.4294938
>
[MB] This really doesn't make sense to add this complexity for the
applications that we anticipate to use 4244bis (which are those that are in
the original call flow document).  In the cases of the missing entries,
most applications will need default behavior rather than sorting through
complex indices.  For debug, you will be able to see what happened. [/MB]

---

From: Brett Tate <[email-masked]>
Date: Fri, 12 Oct 2012 18:57:58 +0000

> Why does put the UA an History-Info into the INVITE?

It is required.  The following thread contains Dale's response to my recent question.

http://www.ietf.org/mail-archive/web/sipcore/current/msg05246.html

The following are some draft-ietf-sipcore-rfc4244bis-10 snippets.

Section 6.1:

"When issuing a request, the UAC MUST follow the
 procedures in Section 9.2.  In the case of an initial request, except
 where the UAC is part of a B2BUA, there is no cache of hi- entries
 with which to populate the History-Info header field and the hi-index
 is set to 1 per Section 10.3."

Section 9.2:

"When sending a request, a SIP entity MUST include all the hi-entries
 from the cache that was created per Section 9.1.  In addition, the
 SIP entity MUST add a new hi-entry to the outgoing request,"

---

From: Shida Schubert <[email-masked]>
Date: Mon, 15 Oct 2012 20:01:09 +0900

Hi Roland;

 Many thanks for your thorough review. 

> Nevertheless I have no problem since this is an example. But I do not see an value add. (This comment belongs also to other use cases)

 As far as I recall, it was so that the first R-URI is recorded. 

 There is not guarantee that the first proxy on the path will 
support H-I and with 4244bis, and by having UAC inserting 
hi-entry when supporting 4244bis, there is more chance to 
capture the first R-URI.

> There is no change of the request URI therefore no reason to add anything.

 You are right this I believe is an error. There should NOT be any "rc".

>   History-Info: <sip:[email-masked];p=x>;index=1.1;rc=1

 True will fix this.. 

> Either this must mentioned explicitly within the description or the entry has to be anonymized.
 
 One of the use-case for History-Info is delivering the request uri parameter to the UAS, 
which is usually lost during retargeting..

 A use-case in 3.8, 3.9 and 3.10 illustrates the need to deliver history-info to 
UAS in some scenario. 

> --> I would propose to change 3.2 without an entry privacy.

 Are you saying that we don't need 3.3 because we have privacy based on privacy header and 
per-entry privacy using the uri parameter?? If so, I tend to agree if other people are okay with 
removing 3.3 and only leaving 3.2 to show call-flow with privacy enabled. 

 Many Thanks!
  Shida

---

From: Shida Schubert <[email-masked]>
Date: Mon, 15 Oct 2012 20:10:22 +0900

Hi Roland;

 You are right about the focus of the use-cases. 

 Use-case 3.5, 3.8, 3.9 are more about UAS understanding 
history-info and making use of the information. 

 Thanks for the suggested text, we will change the text as suggested. 
 
 Regards
  Shida

---

From: <[email-masked]>
Date: Mon, 15 Oct 2012 14:10:52 +0200

Hi Brett,
Thank you for the hint.

So for me it looks that the review of the call flows bring more understanding of the RFC4244bis.

Now I have some problems with backwards compatibility with regard to RFC4244 itself.
Because I'm missing at least a description how to behave as B2BUA when no H-I is received even the supported header is set to history.
It is described when we have a GAP or is this seen as a GAP even if we have no first entry  in the call.
This is not really realistic in networks already having millions of Clients supporting RFC4244. To switch this clients to the RFC4244bis. So each call will have then the entry 0 and 0.1 after passing the first network entity supporting "histinfo" regarding RFC4244bis.

So perhaps we could do something about this case to make it, from my point of view, a little bit better workable.

I see this problem only for the first hop.

Comments?

Thank you

Roland

-----Ursprüngliche Nachricht-----
Von: Brett Tate [mailto:[email-masked]]
Gesendet: Freitag, 12. Oktober 2012 20:58
An: Jesske, Roland; [email-masked]
Betreff: RE: WGLC 4244bis-callflows Use Case 3.3 (3.2)

Section 6.1:

"When issuing a request, the UAC MUST follow the  procedures in Section 9.2.  In the case of an initial request, except  where the UAC is part of a B2BUA, there is no cache of hi- entries  with which to populate the History-Info header field and the hi-index  is set to 1 per Section 10.3."

Section 9.2:

"When sending a request, a SIP entity MUST include all the hi-entries  from the cache that was created per Section 9.1.  In addition, the  SIP entity MUST add a new hi-entry to the outgoing request,"

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 15 Oct 2012 18:55:46 -0400

In addition to Laura, Roland has provided reviews of 3.3, 3.5, 3.7, and 
another partial review of 3.2.

And Brett did a quite thorough review of the non-HI-specific aspects of 
all 11 flows.

We still need people to review at least the HI-specific parts of 3.8-3.11.

PLEASE!

The reviews so far have identified things, so this is not just a 
formality. Its important!

	Thanks,
	Paul

---

From: Shida Schubert <[email-masked]>
Date: Tue, 16 Oct 2012 09:04:23 +0900

Hi Roland;

 Gap as defined in the spec is when the last hi-entry (one 
with the largest index) is different from R-URI.. May be 
we need to be more explicit that the 0 never become the 
first index. 

 Reference >> Chapter 10.3 6 
 
 Thanks
  Shida

---

From: <[email-masked]>
Date: Tue, 16 Oct 2012 14:30:10 +0200

Hi,
here is an review of Section 3.11.

1. look at Berett's SIP corrections on Max-Forwards and the to URI.
2. In consideration of Brett's comments 3&4 regarding the use of supported histinfo by the UAC I have the following view: For this use case the support of History-Info by the originating UAC is not needed. That is OK. I think this should be mentioned within the describing text.
2. F3: From my understanding the last H-I is wrong. rc must be rc=1.1.1 and the index must be index=1.1.1.1 This is how it is described within Index rule 1  "Forwarding a request without changing the target:"
 So the H-I should look like:
   History-Info: <sip:[email-masked];user=phone>;index=1,
                 <sip:[email-masked]>;index=1.1;mp=1,
                 <sip:[email-masked]>;index=1.1.1;rc=1.1
                 <sip:[email-masked]>;index=1.1.1.1;rc=1.1.1

Perhaps a hint within the text would also useful.

4. The following section is not clear (last sentence in 4th section):

...
However, in
   our example here, since the translation was performed by a SIP proxy
   upstream from the gateway, the original 8xx number would have been
   lost, and the call will not interwork properly with the PSTN.
...

How will a call with the PSTN interwork when sending it out from Atlanta.com with a alias?
That is not clear. To interwork it with the PSTN a Request URI with a telephone number is needed. So in this case a forwarding to PSTN is not possible. For having interworking the application forwarding this call has then to take the PSTN number out of the H-I and has to guarantee that it will not be retargeted again. So I think it would be good to add here some notes to describe this fact.

Best Regards

Roland

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Paul Kyzivat
Gesendet: Dienstag, 16. Oktober 2012 00:56
An: [email-masked]
Betreff: Re: [sipcore] VOLUNTEERS NEEDED: Another WGLC for draft-ietf-sipcore-rfc4244bis-callflows-01

In addition to Laura, Roland has provided reviews of 3.3, 3.5, 3.7, and another partial review of 3.2.

And Brett did a quite thorough review of the non-HI-specific aspects of all 11 flows.

PLEASE!

The reviews so far have identified things, so this is not just a formality. Its important!

        Thanks,
        Paul

---

From: <[email-masked]>
Date: Tue, 16 Oct 2012 18:01:07 +0200

Hi Shida

> with the largest index) is different from R-URI.. May be we
> need to be more explicit that the 0 never become the first index.
>
That could be also interpreted for the first entry that is missing.
So as you propose some more words help.

Thank You

Roland

> > Because I'm missing at least a description how to behave as
> B2BUA when no H-I is received even the supported header is
> set to history.
> > It is described when we have a GAP or is this seen as a GAP
> even if we have no first entry  in the call.
> > This is not really realistic in networks already having
> millions of Clients supporting RFC4244. To switch this
> clients to the RFC4244bis. So each call will have then the
> entry 0 and 0.1 after passing the first network entity
> supporting "histinfo" regarding RFC4244bis.
> >
> > So perhaps we could do something about this case to make
> it, from my point of view, a little bit better workable.
> >
> procedures in Section 9.2.  In the case of an initial
> request, except  where the UAC is part of a B2BUA, there is
> no cache of hi- entries  with which to populate the
> History-Info header field and the hi-index  is set to 1 per
> Section 10.3."
> >
> > Section 9.2:
> >
> > "When sending a request, a SIP entity MUST include all the
> hi-entries  from the cache that was created per Section 9.1.
> In addition, the  SIP entity MUST add a new hi-entry to the
> outgoing request,"
> >
>
>

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 16 Oct 2012 14:38:42 -0400 (EDT)

> From: <[email-masked]>
>
> 2. In consideration of Brett's comments 3&4 regarding the use of
> supported histinfo by the UAC I have the following view: For this
> use case the support of History-Info by the originating UAC is not
> needed. That is OK. I think this should be mentioned within the
> describing text.

It is not clear.  RFC 4244 allows a proxy to add History-Info to a
request even if the request does not contain "Supported: histinfo".
4244bis does not state that a proxy is allowed to do that, although it
doesn't clear specify that it may not do that.

> 4. The following section is not clear (last sentence in 4th
> 4. section):
> 
> ...
> However, in
> That is not clear. To interwork it with the PSTN a Request URI with
> a telephone number is needed. So in this case a forwarding to PSTN
> is not possible. For having interworking the application forwarding
> this call has then to take the PSTN number out of the H-I and has to
> guarantee that it will not be retargeted again. So I think it would
> be good to add here some notes to describe this fact.

To me, the text in section 3.11 appears to be discussing different
situations than what is shown in the message flow.  The text discusses
various aspects of freephone processing when it is not done in an
end-to-end SIP network.  The message flow is a "pure SIP"
implementation of free-phone number conversion:  The first step is
translating the free-phone number into the ordinary directory number,
the second step is translating the ordinary directory number into a
SIP AOR, and the third step is translating the SIP AOR into the
registered UAS URI.

As a matter of terminology, I believe that "freephone" is more used
internationally than "toll free", "800", or "8xx", but I might be
wrong.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 16 Oct 2012 14:55:56 -0400 (EDT)

> Now I have some problems with backwards compatibility with regard to
> RFC4244 itself.  Because I'm missing at least a description how to
> behave as B2BUA when no H-I is received even the supported header is
> set to history.  It is described when we have a GAP or is this seen
> as a GAP even if we have no first entry in the call.
>
> This is not really realistic in networks already having millions of
> Clients supporting RFC4244. To switch this clients to the
> RFC4244bis. So each call will have then the entry 0 and 0.1 after
> passing the first network entity supporting "histinfo" regarding
> RFC4244bis.
> 

My memory is that with RFC 4244, it is expected that the first proxy
will add a "1" entry containing the request-URI that it received.
(Since this is the first proxy, that request-URI will be the
request-URI when the request was originally generated by the UAC.)

Under 4244bis, I think that this would be considered a "gap"
situation, although the text is ambiguous:  the text in section 9.1
says:

   If the Request-URI of the incoming request does not match the hi-
   targeted-to-uri in the last hi-entry (i.e., the previous SIP entity
   that sent the request did not include a History-Info header field),
   the SIP entity MUST add a hi-entry to end of the cache, on behalf
   of
   the previous SIP entity before proceeding to Section 9.2, as
   follows:

But it does not make clear what is to be done if there is no "last
hi-entry".

In practice, I think the following is the desired behavior (which is
also compatible with RFC 4244):

   When receiving a request:

   If there is no hi-entry and the request contains exactly one Via,
   then the entity must add an hi-entry with index "1".
   [This is the behavior in RFC 4244.]

   If there is no hi-entry and the request contains more than one Via,
   then the entity must add an hi-entry with index "0".
   [This is the "gap" behavior.]

This is practical because the first proxy can determine that it *is*
the first proxy, and hence it can safely determine the original
request-URI.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 16 Oct 2012 18:34:40 -0400

> the first proxy, and hence it can safely determine the original

This is true as long as there are only proxies, not B2BUAs on the path.
There could have been a whole chain non-HI-aware things culminating in a 
last B2BUA that "anonymizes" by removing all the Vias and replacing them 
with one for itself. For instance, this could happen at the boundary 
between two service providers.

	Thanks,
	Paul

---

From: Shida Schubert <[email-masked]>
Date: Wed, 17 Oct 2012 09:22:54 +0900

Hi Dale, Roland;

 My comments inline..

> But it does not make clear what is to be done if there is no "last

 Right.. 

>   [This is the "gap" behavior.]

 Okay, but do we need to differentiate them? Can we just start with 
1 when there are no prior hi-entry?? Is it considered a gap when 
there were no hi-entry to start with??

 Thanks 
  Shida

---

From: <[email-masked]>
Date: Wed, 17 Oct 2012 11:35:48 +0200

Hi Dale,
see below

Roland
> > supported histinfo by the UAC I have the following view:
> For this use
> > case the support of History-Info by the originating UAC is
> not needed.
> > That is OK. I think this should be mentioned within the describing
> > text.
>
> It is not clear.  RFC 4244 allows a proxy to add History-Info
> to a request even if the request does not contain "Supported:
> histinfo".
> 4244bis does not state that a proxy is allowed to do that,
> although it doesn't clear specify that it may not do that.
>
So with regard to that we have then a GAP. Because there are Services based upon that.
3GPP has defined the Communication Forwarding using that approach.
So due to backwards compatibility we need then there a description.

---

From: Shida Schubert <[email-masked]>
Date: Thu, 18 Oct 2012 08:44:55 +0900

There is no text that prevents proxy to add hi-entries. 

 But if there is a strong feeling towards adding an explicit 
text something along the line of 

 "Intermediaries such as proxies MAY add hi-entries even 
if there is no histinfo option tag in the Supported header"

 Regards
  Shida

---

From: <[email-masked]>
Date: Thu, 18 Oct 2012 09:08:52 +0200

Hi Shida,
in the past I had many problems to express our requirements to vendors and how they have to read standards.
So if it is allowed then we need some words within the text. I think as clearer standard text is as less problems we will get with implementations.

So I'm in favour to add some text.

Best Regards

Roland

> Von: Shida Schubert [mailto:[email-masked]]
> Gesendet: Donnerstag, 18. Oktober 2012 01:45
> An: Jesske, Roland
> Cc: [email-masked]; [email-masked]
> Betreff: Re: [sipcore] WGLC for
> draft-ietf-sipcore-rfc4244bis-callflows-01 Section 3.11
>
>
>  "Intermediaries such as proxies MAY add hi-entries even if
> there is no histinfo option tag in the Supported header"
>
>  Regards
>   Shida
>
> although
> >> it doesn't clear specify that it may not do that.
> >>

---

From: Shida Schubert <[email-masked]>
Date: Thu, 18 Oct 2012 22:17:59 +0900

Hi Roland;

 I am actually looking at the spec again and 
what the spec is saying is that the intermediary 
that supports RFC4244bis MUST set hi-entries, 
it has nothing to do with whether "histinfo" is set 
on the Supported header.. 

 The only place where the behavior is affected 
by the presence of option tag in Supported header 
is "sending h-i in response (9.4)" 

 So I think RFC4244bis is fine as is.. Thoughts? 

 Regards
  shida

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 18 Oct 2012 14:10:14 -0400

If my records are correct we have now had significant reviews of all the 
callflows!!!

Many thanks to the volunteers:
- Brett
- Laura
- Marianne
- Roland

And to the others who have also contributed comments.

I have found the review comments and the resulting discussion to be 
interesting and significant. I regret not having provoked this level of 
attention sooner.

Shida has been commenting on specific points along the way.
Now I think it is time to assess where we are as a result of this exercise:
- how much is just defects to be fixed in the callflows
- have needs been identified for changes in the bis

I would like to see a "report" about this from the authors, and would be 
happy to hear more from others in the wg about it too. Hopefully we can 
wrap this all up quickly.

	Thanks,
	Paul

---

From: <[email-masked]>
Date: Fri, 19 Oct 2012 13:08:43 +0200

Hi Shida,
so if this is reflected then I'm satisfied.
But for me it is important that the first entry then starts with Index=1.

Best Regards

Roland

> Gesendet: Donnerstag, 18. Oktober 2012 15:18
> An: Jesske, Roland
>  I am actually looking at the spec again and what the spec is
> saying is that the intermediary that supports RFC4244bis MUST
> set hi-entries, it has nothing to do with whether "histinfo"
> is set on the Supported header..
>
>  The only place where the behavior is affected by the
> presence of option tag in Supported header is "sending h-i in
> response (9.4)"
>
> > in the past I had many problems to express our requirements
> to vendors and how they have to read standards.
> > So if it is allowed then we need some words within the
> text. I think as clearer standard text is as less problems we
> will get with implementations.
> >
> >> But if there is a strong feeling towards adding an explicit text
> >> something along the line of
> >>
> there is
> >> no histinfo option tag in the Supported header"
> >>
> >> Regards
> >>  Shida
> >>

---

From: Brett Tate <[email-masked]>
Date: Fri, 19 Oct 2012 11:30:16 +0000

> - how much is just defects to be fixed in the callflows

In my opinion, there were enough rfc4244bis-callflows-01 comments to require another WGLC.

> - have needs been identified for changes in the bis

Yes; the following comments correspond to draft-ietf-sipcore-rfc4244bis-10.

1) Section 5.1's example should indicate the mandatory History-Info within first INVITE.

2) For clarification and backward compatibility reasons, I recommend that the draft highlight that the UAC must now add the History-Info and highlight how the next hop should behave if History-Info is not present.

3) The last bullet of section 10.4 appears to conflict with prior text within the same section.  More specifically, the bullet does not mention that the mp-value was obtained from the 3xx response's Contact.  Thus it could be interpreted as though it may be acceptable to ignore the prior MUST NOT.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 19 Oct 2012 11:26:50 -0400

Brett,

A question below.

	Thanks,
	Paul

> In my opinion, there were enough rfc4244bis-callflows-01 comments to require another WGLC.

On the callflows, the bis, or both?

---

From: Brett Tate <[email-masked]>
Date: Fri, 19 Oct 2012 15:59:28 +0000

> On the callflows, the bis, or both?

The comment was to WGLC an updated version of draft-ietf-sipcore-rfc4244bis-callflows.

Concerning the following comments, I'm currently not sure if others agree that all should be made and if such changes would require another WGLC.

> > 2) For clarification and backward compatibility reasons, I recommend
> that the draft highlight that the UAC must now add the History-Info and
> highlight how the next hop should behave if History-Info is not
> present.
> >
> > 3) The last bullet of section 10.4 appears to conflict with prior
> text within the same section.  More specifically, the bullet does not
> mention that the mp-value was obtained from the 3xx response's Contact.
> Thus it could be interpreted as though it may be acceptable to ignore
> the prior MUST NOT.

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 19 Oct 2012 13:53:21 -0400 (EDT)

> I am actually looking at the spec again and what the spec is saying
> is that the intermediary that supports RFC4244bis MUST set
> hi-entries, it has nothing to do with whether "histinfo" is set on
> the Supported header..
> 
> The only place where the behavior is affected by the presence of
> option tag in Supported header is "sending h-i in response (9.4)"
> 

Yes, I was incorrect.  A 4244bis-compliant proxy MUST add an hi-entry,
as is described in section 7.

But I agree with Roland, we need to arrange that in almost all cases,
when a non-supporting UA sends a request to a supporting proxy, the
proxy can insert an hi-entry with index=1.  I believe that was the
behavior in RFC 4244.

Dale

---

From: Shida Schubert <[email-masked]>
Date: Sat, 20 Oct 2012 18:25:09 +0900

Hi Brett;

 My comments inline..

> 2) For clarification and backward compatibility reasons, I recommend that the draft highlight that the UAC must now add the History-Info and highlight how the next hop should behave if History-Info…

 The first point here I believe is already addressed in section 6.1 of 4244bis-10.. 
Section 16.1 in 4244bis-10 also highlights the change in normative behavior 
in respect to UAC adding the "histinfo" Supported option tag and 
addition of "history-info". 

 As for the second point I agree that there seems to be some need 
for a text explicitly stating the behavior for when this condition is 
met. 

> 3) The last bullet of section 10.4 appears to conflict with prior text within the same section.  More specifically, the bullet does not mention that the mp-value was obtained from the 3xx response'…

 I see where the confusion comes from.. The paragraph you mention is really 
talking about how and when the "mp" may be set. The MUST NOT paragraph 
you mentioned specifically talk about these values in 3xx response and how 
they should be handled. 

 I believe what you are suggesting is to wordsmith the section so it is clear 
that entity receiving the 3xx simply copy what is in the contact and try not to 
determine the appropriate header field parameters ("mp","rc" or "np") so there 
is no confusion, am I right? 

 Thanks
  Shida

---

From: Shida Schubert <[email-masked]>
Date: Sat, 20 Oct 2012 18:30:56 +0900

Hi Dale;

 That's correct.. And RFC4244bis as far as authors are 
concerned behave the same way as RFC4244 if there 
is no hi-entry in the incoming request. 

 This really depends on if we keep the semantics 
of the gap as is (Gap is considered a gap only when there 
is hi-entry and last one doesn't match the R-URI of the 
incoming request). 
   
 Obviously some text may be needed to explicitly state 
what entity should do when it is not the UAC and adding the 
first hi-entry.. 

 Thanks
  Shida

---

From: Brett Tate <[email-masked]>
Date: Sun, 21 Oct 2012 18:57:52 +0000

> addition of "history-info".

I agree; section 16.1 does address the first part of the comment.  After re-reading sections 6.1, 9.2, and 16.1, I withdraw the first part of the comment.

> I see where the confusion comes from.. The paragraph you 
> mention is really talking about how and when the "mp" may 
> be set. The MUST NOT paragraph you mentioned specifically 
> talk about these values in 3xx response and how they 
> should be handled.
> 
> I believe what you are suggesting is to wordsmith the 
> section so it is clear that entity receiving the 3xx 
> simply copy what is in the contact and try not to
> determine the appropriate header field parameters 
> ("mp","rc" or "np") so there is no confusion, am I 
> right?

Yes; I recommend clarifying the last bullet to explicitly indicate (instead of attempting to imply) that the mp-value was obtained from the 3xx response's Contact.

---

From: <[email-masked]>
Date: Mon, 22 Oct 2012 07:30:03 +0200

Dale,
even a supporting RFC4244 UA should not include an H-I when not needed.
We are using RFC4244 only to show the real forwarding ("mp"). For our network this is sufficient, because we want to avoid loops in forwarding calls (max 5 times).
That was one of our requirements.

Best Regards

Roland

> Von: [email-masked]
> [mailto:[email-masked]] Im Auftrag von Dale R. Worley
> Gesendet: Freitag, 19. Oktober 2012 19:53
> An: [email-masked]
> > I am actually looking at the spec again and what the spec
> is saying is
> > that the intermediary that supports RFC4244bis MUST set
> hi-entries, it
> > has nothing to do with whether "histinfo" is set on the Supported
> > header..
> >
> Yes, I was incorrect.  A 4244bis-compliant proxy MUST add an
> hi-entry, as is described in section 7.
>
> But I agree with Roland, we need to arrange that in almost
> all cases, when a non-supporting UA sends a request to a
> supporting proxy, the proxy can insert an hi-entry with
> index=1.  I believe that was the behavior in RFC 4244.
>
> Dale

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 23 Oct 2012 16:03:13 -0400 (EDT)

> We are using RFC4244 only to show the real forwarding ("mp"). For
> our network this is sufficient, because we want to avoid loops in
> forwarding calls (max 5 times).

How could the UAC possibly know whether H-I will be needed once the
INVITE reaches a destination?  Or a proxy, for that matter?

Dale

---

From: Mary Barnes <[email-masked]>
Date: Tue, 23 Oct 2012 15:32:03 -0500

> > That was one of our requirements.
[MB] That approach is NOT compliant with 4244bis. One of the bigger changes
between 4244 and 4244bis was to change the addition of HI to a MUST. While
you may not care about "mp", you are not compliant if you don't add the
other values.  [/MB]

> INVITE reaches a destination?  Or a proxy, for that matter?
[MB] Exactly - trying to do that embeds application logic into the core SIP
message processing - not a good idea at all.  [/MB]

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 23 Oct 2012 17:45:34 -0400 (EDT)

> what entity should do when it is not the UAC and adding the 

And some thought needs to be put into what the desired behavior is.
Off the top of my head, the desiderata include:

- Updating the logic defining a "gap" so that it does not fail if
  there is no H-I present.

- Behaving the same as RFC 4244.

- Creating an H-I that resembles what would be created if the UAC
  inserted the index=1 element, in the case of the first-hop proxy
  adding the initial hi-entry.

- If the UAC is a B2BUA creating a request with only one Via header,
  the H-I should not deceive the UAS to the point of causing
  malfunction (in the bulk of cases).

(These may be incompatible!)

In regard to 4244, the relevant text is:

   4.3.  Protocol Usage

   This section describes the processing specific to UAs and Proxies for
   the History-Info header, the "histinfo" option tag, and the priv-
   value of "history".  As discussed in Section 1.3, the fundamental
   objective is to capture the target Request-URIs as a request is
   forwarded.  This allows for the capturing of the history of a request
   that would be lost due to subsequent (re)targeting and forwarding.
   To accomplish this for the entire history of a request, either the
   UAC must capture the Request-URI in a History-Info header in the
   initial request or a proxy must add a History-Info header with both a
   hi-entry for the Request-URI in the initial request and a hi-entry
   for the target Request-URI as the request is forwarded.  [...]

   4.3.1.  User Agent Client (UAC) Behavior

   The UAC SHOULD include the "histinfo" option tag in the Supported
   header in any request not associated with an established dialog for
   which the UAC would like the History-Info header in the response.  In
   addition, the UAC MAY improve the diagnostic utility of its request
   by adding a History-Info header, using the Request-URI of the request
   as the hi-target-to-uri and initializing the index to the RECOMMENDED
   value of 1 in the hi-entry.  [...]

   4.3.3.1.  Adding the History-Info Header to Requests

   [...] Additionally, if a request is received that doesn't include a
   History-Info header, the proxy MAY add a History-Info header with a
   hi-entry preceding the one being added for the current request
   being forwarded.  The index for this hi-entry is RECOMMENDED to
   start at 1.  [...]

Which suggests that the "obvious" rule is that if a supporting proxy
receives a request that does not contain a History-Info header,
instead of considering it a "gap" situation, it must add one
containing the request-URI of the incoming request, with an index of 1
before further processing.  (This is a case where the current 4244bis
"gap definition" is ambiguous as written.)

The consequences of this rule include:

- Due to section 9.4 in 4244bis, a proxy that adds such an initial
  hi-entry will not send History-Info in the response to the initial
  request.  So upstream (presumably non-supporting) elements are
  "protected" from seeing H-I.

- UASs are deceived regarding the original request-URI.  This seems to
  be tolerable, as it means that the UAS is unaware of earlier
  translation steps, but that it correctly sees the tail of the
  sequence of translation steps.  This may deny it information that it
  could act on, but the information it sees is accurate, as long as it
  is aware that the index=1 entry may not be the true user-dialed
  number.

Dale

---

From: Shida Schubert <[email-masked]>
Date: Wed, 24 Oct 2012 09:32:56 +0900

Hi Dale;

 My comments inline..

> - Updating the logic defining a "gap" so that it does not fail if

 What do you mean fail? 

> - Behaving the same as RFC 4244.

 Then we can't set 0.. We would need to set 1. 

 Right.. 

>  malfunction (in the bulk of cases).

 Can you elaborate?

>  "protected" from seeing H-I.

 Could you elaborate this? I am not quite seeing what you are 
trying to address here.. 

 Right..

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 24 Oct 2012 15:48:08 -0400 (EDT)

> > - Updating the logic defining a "gap" so that it does not fail if

Reading the text ("If the Request-URI of the incoming request does not
match the hi-targeted-to-uri in the last hi-entry") as an algorithm,
no provision is made for the possibility that there is no hi-entry.
As code, this would have a run-time error, and it is ambiguous what
action should be taken in this case.

> >  malfunction (in the bulk of cases).

Earlier, I suggested that we add a rule that if a proxy receives a
request with no "Supported: histinfo" or History-Info, but it contains
exactly one Via, then the proxy can add the incoming request-URI to
the H-I with index=1 because the proxy knows that it is receiving the
request directly from the UAC.

(In this latest proposal, the restriction "exactly one Via" is
removed.)

Paul pointed out that the UAC in question may be the client side of a
B2BUA, and so the incoming request-URI at the proxy isn't really the
origination request-URI.

So there is the question of whether the "application" in the UAS will
be confused by the History-Info in some way that makes a difference.

I believe that there is no risk, because the application does not
absolutely need to know the true origination request-URI, and will not
be deceived dangerously if the initial request-URIs are missing.

In general, the application should walk the hi-entries, starting with
the *last* one, and following the chain of URIs from which the final
request-URI was derived, until it reaches one that it does not
recognize (or it gets to the beginning).  The last-examined URI (the
earliest in the H-I) that it recognizes, is the "incoming" URI from
the point of view of the application, and answers the question of
"What URI did the user use (directly or indirectly) when he called
us?"

>From this point of view, losing initial hi-entries will degrade the
information that the application can extract, but it does not make
that information fundamentally incorrect.

> Could you elaborate this? I am not quite seeing what you are 

I seem to remember during the discussions there was a desire to not
have History-Info sent in responses to a UAC if the UAC has not
indicated support for H-I (by adding a History-Info header or
"Supported: histinfo").  This was not to prevent the UAC from being
"confused" by a header that it did not understand, but to prevent the
last-hop response from being enlarged.

RFC 4244 does not state a MUST that ensures this effect, although the
text in section 4.3.2 suggests this.  4244bis does ensure this effect
in section 9.4.

Dale

---

From: Shida Schubert <[email-masked]>
Date: Thu, 25 Oct 2012 22:09:04 +0900

Hi Dale;

 My comment inline..

> action should be taken in this case.

 For optional header to cause a run-time error because there is no 
value that is optional in the first place, sounds to me like a bad coding.. 

 Anyway, if what you are saying is to explicitly state somewhere that 
hi-entry doesn't always exist that's fine.. 

> be deceived dangerously if the initial request-URIs are missing.

 I completely agree. 

> "What URI did the user use (directly or indirectly) when he called

 Right. 

> that information fundamentally incorrect.

 Right. 

> text in section 4.3.2 suggests this.  4244bis does ensure this effect

 Right.. There was some debate about UAS sending back all the 
hi-entries with the MUST strength due to the concern about the message 
size of the response.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 25 Oct 2012 12:19:02 -0400

> hi-entries with the MUST strength due to the concern about the message

If the response was small enough to reach the proxy, then it should be 
small enough to reach the UAC. (It gets smaller with each hop due to 
removal of Via header fields.)

I guess this might not be true if link characteristics are different, or 
if the first hop was UDP and the subsequent hops were TCP.

But if PDU size is a concern, why isn't it a concern on every hop? 
Should there have been some dispensation that H-I can be pruned in 
responses if necessary to reduce PDU size?

One concern I had was if the first proxy is dialog-stateless. Then it 
will have to go to extra work to remember that the H-I should not be 
passed in the response. (Dale remineded me that a stateless proxy can do 
this by putting a flag in its Via.) This wouldn't be such an issue if 
returning the H-I in this case is optional.

	Thanks,
	Paul (as individual)