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

["Worley, Dale R (Dale)" <[e-mail]>]

________________________________________
> #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., [e-mail] to [e-mail] 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
> [e-mail], but your real registered AoR is [e-mail].  When
> the proxy receives a request for [e-mail], it looks up the
> location service database and ultimately gets a registered contact for
> [e-mail].  In some architectures, the proxy would internally go from
> [e-mail] to [e-mail], and then to the registered contact.
> So does it add a H-I for [e-mail]?
>
> 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.
_______________________________________________

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