Subject: Re: [sipcore] #8: It's not clear when a Proxy should/should-not add H-I for "internal" stuff

From: Shida Schubert <[email-masked]>
Date: Wed, 1 Sep 2010 23:46:34 +0900

The intermediate target should be added.

 And I agree that usecase draft should reflect what it 
really should do which is what you suggested for 
section 7.2.

 To look for "last non-"rc" entry of the same branch, 
prior to last entry with hi-target of "rc" in the Request", 
in case of an "alias".

 Regards
  Shida

On Aug 31, 2010, at 3:17 AM, sipcore issue tracker wrote:

> #8: It's not clear when a Proxy should/should-not add H-I for "internal" stuff
> ------------------------------------+---------------------------------------
> Reporter:  hkaplan@…               |       Owner:            
>     Type:  defect                  |      Status:  new       
> Priority:  major                   |   Milestone:  milestone1
> Component:  rfc4244bis              |     Version:  2.0       
> Severity:  In WG Last Call         |    Keywords:            
> ------------------------------------+---------------------------------------
> Section 5.1 says:
>    Retargeting is an iterative process, i.e., a proxy may redirect
>    "internally " more than one time.  A typical example would be a proxy
>    that redirects a request first to a different user (i.e., it maps to
>    a different AOR), and then forwards to a registered contact bound to
>    that new AOR.  A proxy that uses such mechanism SHOULD add multiple
>    hi-entry fields (e.g., [email-masked] to [email-masked] to
>    [email-masked]) to provide a logical description of the retargeting
>    process.
> 
> This isn't clear enough.  Let's suppose you have an "alias", like
> [email-masked], but your real registered AoR is [email-masked].  When
> the proxy receives a request for [email-masked], it looks up the
> location service database and ultimately gets a registered contact for
> [email-masked].  In some architectures, the proxy would internally go from
> [email-masked] to [email-masked], and then to the registered contact.
> So does it add a H-I for [email-masked]?
> 
> The answer matters - both because it impacts the use-case rules described
> in the use-cases draft, and because it means a UA will get two different
> sets of H-I entries depending on the internal implementation of the proxy
> +location-service it uses.
> 
> -- 
> Ticket URL: <http://trac.tools.ietf.org/wg/sipcore/trac/ticket/8>
> sipcore <http://tools.ietf.org/sipcore/>
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 2 Sep 2010 15:26:52 -0400

________________________________________

The problem is (IMHO) that the text doesn't clearly capture the intention of H-I, due to a historical accident.

The point of H-I is to capture (to the degree possible) the request-URIs of the *entire* tree of INVITE messages that were generated.  If this is done thoroughly, then all of the "regargeting" operations (all all other types of operations) will necessarily be captured.  But in the past, people have tended to think that the purpose was to document some specific set of request-URI transformations (e.g., the ones called "retargeting"), and the text tends to be written in ways that echo that previous understanding.  The result is that we feel the need to debate exactly what is recorded in certain complex situations.

The solution is to clarify at the beginning that all request-URIs are intended to be recorded.

Dale

---

From: Mary Barnes <[email-masked]>
Date: Thu, 2 Sep 2010 15:03:29 -0500

Dale,

I'm not sure what you mean with regards to "historical accident".  One
of the original requirements was to capture the "complete"
information. Thus, each and every change of the Request-URI is
intended to be captured (including changes by a proxy internally).  I
would agree that the definition of retargeting in the terminology
section does not accurately reflect such, which adds to the confusion.

But, I would agree the text needs improvements to make that clear and
it's possible some of the re-arrangement of the introductory sections,
etc. resulted in the lack of clarity.  And, most importantly, we need
to make sure the normative parts of this document accurately reflect
this.

Mary.

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 2 Sep 2010 16:41:58 -0400

> The solution is to clarify at the beginning that all request-URIs are intended to be recorded.

But they're NOT "Request-URIs".  Not yet.  They're abstract target URIs during the internal local policy stages of routing, until such point as the request gets forwarded.  They're just memory blocks in a system, getting munged based on transformation rules, lookup tables, or possibly non-SIP database queries.

For example, a common routing local policy procedure of originating proxies in North America is to perform the following for received request-URIs identified as phone numbers:
1) Normalize the number by removing visual separators, and possibly transform the number to an E.164, by adding a country-code, area-code, leading-plus, etc.
2) Do a number portability dip for the called number.  That changes the target URI to include a 'npdi' and possibly 'rn' param info.
3) Determine whether the portability-corrected target is local or out of region, or if it's out of the local domain altogether (and to which peer).  That can change the target again, for example by changing the domain name, adding trunk-group info, etc.
4) Change the Request-URI to be the new target.

I'm simplifying and skipping some steps, but you get the idea.
Do you expect three or more H-I entries to be generated by this Proxy?  
What if steps 2 and 3 were performed through ENUM, DIAMETER, SS7, or even just local tables, and thus not changing "Request-URIs" until step 4?

-hadriel

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 2 Sep 2010 17:11:14 -0400

________________________________________
From: Hadriel Kaplan [[email-masked]]

Hmmm....  In the sipX architecture, each of those steps would be done separately, by the proxy sending the request to a redirect server which would return a 302.  So yes, each stage of processing would be represented by a separate hi-entry.

But I see your point, What if a proxy does it all internally?

I'd like to say that it can write hi-entry's *as if* each step was described separately by a 302 from a redirect server.  Or alternatively, as if the request had a series of passes through proxies that performed each step.  Those alternatives would lead to History-Info somewhat like these (where I've changed the use of the tags a bit):

History-Info:
	<sip:[email-masked]>;index=1,
	<sip:[email-masked]>;index=1.1,
	<sip:[email-masked];npdi>;index=1.1.1,
	<sip:[email-masked];npdi>;index=1.1.1.1,
	<sip:[email-masked];npdi>;index=1.1.1.1.1

History-Info:
	<sip:[email-masked]>;index=1,
	<sip:[email-masked]>;index=1.1,
	<sip:[email-masked];npdi>;index=1.2;from=1.1,
	<sip:[email-masked];npdi>;index=1.3;from=1.2,
	<sip:[email-masked];npdi>;index=1.4;from=1.3

In general, the recipient of a request containing such a faked H-I wouldn't be able to tell that it had been faked.  However, it would be desirable to have text to explicitly approve such behavior.

Going back to the text of the document, I see how I became misled.  The text in section 5.1 is:

   Retargeting is an iterative process, i.e., a proxy may redirect
   "internally " more than one time.  A typical example would be a proxy
   that redirects a request first to a different user (i.e., it maps to
   a different AOR), and then forwards to a registered contact bound to
   that new AOR.  A proxy that uses such mechanism SHOULD add multiple
   hi-entry fields (e.g., [email-masked] to [email-masked] to
   [email-masked]) to provide a logical description of the retargeting
   process.  A Reason MAY be associated with the hi-targeted-to-uri that
   has been retargeted as shown in the example in Appendix B.1.

Given that the word "internally" is not defined in any way, and that the example described would be implemented in sipX through multiple redirect server requests, I did not realize that the process described was performed entirely within one SIP element.  This suggests that the text could stand to be improved.

Dale