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
