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

Reply via email to