Right. I think adding something indicating it's a reroute for the last hop
would be useful.
________________________________
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Barnes,
Mary (RICH2:AR00)
Sent: Monday, March 17, 2008 07:01
To: Hans Erik van Elburg; [email protected]
Subject: Re: [Sip] History-Info: UA loose route versus Target header
The reason every rewrite of a Request URI is a retarget is because the
base SIP spec did not distinguish reroute from retargeting, which is the gist
of Jonathan's proposal. There are explicit reasons associated with some of the
retargets (e.g., 3xx redirections), but I would agree that isn't always the
case. But, I still contend that you can tell from the structure of the
combination of routes/retargets what was the intended target, especially
considering the use cases given. It does require that the entity that does
the retargeting to capture the History-Info, but the "Target" header solution
has the same requirement.
If the concern is the processing to sort through the HI entries (the
reason that Jonathan's draft suggests HI is not a good solution), then you
could add a "retarget" (and "reroute") tags to the appropriate HI entry, since
History-Info was designed to be extensible.
Mary.
________________________________
From: Hans Erik van Elburg [mailto:[EMAIL PROTECTED]
Sent: Monday, March 17, 2008 5:40 AM
To: Barnes, Mary (RICH2:AR00); [email protected]
Subject: RE: [Sip] History-Info: UA loose route versus Target header
A reroute and a retarget (using the definitions of the ua-loose-route
draft) may both be caused by some local policy deployed on a proxy, it is not
clear how they should be distinguished by reason values. And it is certainly
nowhere defined what different reasons would be applicable in these cases.
To complicate things further to RFC4244 any rewrite of the Request URI
is a retarget, not so in the more subtle definitions used in the ua-loose-route
draft which distinguishes retargets from reroutes.
Therefore I insist that History-Info as it is today, does not cover
this.
/Hans Erik
________________________________
From: Mary Barnes [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 13, 2008 10:47 PM
To: Hans Erik van Elburg; [email protected]
Subject: RE: [Sip] History-Info: UA loose route versus Target header
You can tell retargets versus rerouting due to combination of the
reasons in the various responses and the indices. With the indices you can get
a trace (in the form of a tree structure due to the nesting of the indices)
that shows the entire history of a request.
Mary.
________________________________
From: Hans Erik van Elburg [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 13, 2008 2:48 PM
To: Barnes, Mary (RICH2:AR00); [email protected]
Subject: RE: [Sip] History-Info: UA loose route versus Target header
Hi Mary,
I dont think that the objective should be to change the fundamental
nature of SIP processing for no good reason. It will break things.
The probem with the History-Info is that one can not distinguish
reroutes from retargets and hence it can not be used for this. If you disagree
with that could you address why you think this is not the case?
/Hans Erik
________________________________
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mary
Barnes
Sent: Thursday, March 13, 2008 11:34 AM
To: [email protected]
Subject: [Sip] History-Info: UA loose route versus Target header
Per my comments at the microphone, here's my assessment of the
difference between the two documents as they apply to History-Info as a
potential solution.
draft-rosenberg-sip-ua-loose-route-02 clearly states that History-Info
functionally can be used to solve the problem described in that document.
However, Jonathan's objective is to solve a fundamental problem of not
distinguishing routing versus re-targeting (read section 5). This document
would actually change the content of the History-Info headers for the same
requests, just as it's already identified in RFC 4244 that if you have loose
routing in general, that the information is different in History-Info.
The document draft-holmberg-sip-target-uri-delivery-01.txt doesn't do
anything to change fundamental SIP processing. It just adds another header that
contains information that would already be contained in History-Info.
History-info provides a complete history of the processing of a request, with
the indexing provided by the entries and the reasons, you know exactly why a
request was either "retargetted" or "re-routed". The examples in the appendix
would apply to the use cases you are attempting to solve as described in
Jonathan's document.
Mary.
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
