You will know whether or not the last entity that retargeted or routed the request to the terminator added an HI entry, since the concept of the old and new is captured - i.e., the entity receiving the request determines whether the last HI entry matches the request-URI in the request. It was a fundamental requirement (CONTENT-Req) that both the new URI and the one that was retargetted are captured. In that case, you can know that the previous HI entry was the request-URI for the previous hop. So, in that respect History-Info is better than the Target-ID. I also think that if you do the detailed flows for your scenarios, including the complete HI, you can see the pattern for determining the right entry to use due to the indices and reasons included in the entries. Basically, you're moving the logic to the endpoint that receives the request rather than having the proxies do extra work along the way to determine what the Target-ID should be. Mary.
________________________________ From: Audet, Francois (SC100:3055) Sent: Thursday, March 13, 2008 2:07 PM To: Elwell, John; Barnes, Mary (RICH2:AR00); [email protected] Subject: RE: [Sip] History-Info: UA loose route versus Target header Well, yes, of course. That is not a solvable problem. ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Elwell, John Sent: Thursday, March 13, 2008 11:30 To: Barnes, Mary (RICH2:AR00); [email protected] Subject: Re: [Sip] History-Info: UA loose route versus Target header One problem identified with Target-Id was that a proxy that retargets and doesn't support Target-Id might just forward an existing Target-Id rather than remove it. I think history-info has a similar property, i.e., the last history entry will not necessarily reflect the most recent target. Would anybody care to comment on this? John ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mary Barnes Sent: 13 March 2008 15:34 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
