Thanks Mary.
 
By the way, RFC 4458 (voicemail URI) describes in the last paragraph of section 
4 how History-Info solves the problem of URI parameters being dropped as a 
result of routing or retargeting.
 
Therefore, if we chose the History-Info route for this problem, RFC 4458 would 
magically be forward compatible.


________________________________

        From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Barnes, 
Mary (RICH2:AR00)
        Sent: Thursday, March 13, 2008 08: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

Reply via email to