Exactly the sort through the HI entries approach is not well specified and therfore the outcome is not predictable. /Hans Erik
________________________________ From: Mary Barnes [mailto:[EMAIL PROTECTED] Sent: Monday, March 17, 2008 3:01 PM 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
