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

 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., bob@example.com to office@example.com to
>    office@192.0.2.5) to provide a logical description of the retargeting
>    process.
> 
> This isn't clear enough.  Let's suppose you have an "alias", like
> john.smith@ssp.com, but your real registered AoR is jsmith@ssp.com.  When
> the proxy receives a request for john.smith@ssp.com, it looks up the
> location service database and ultimately gets a registered contact for
> jsmith@ssp.com.  In some architectures, the proxy would internally go from
> john.smith@ssp.com to jsmith@ssp.com, and then to the registered contact.
> So does it add a H-I for jsmith@ssp.com?
> 
> 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
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore