Hi Dale, I have a few clarifications added below [MB].
Mary. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, March 21, 2008 10:28 PM To: [email protected] Subject: [Sip] Further observations about History-Info Considering again how History-Info handles 3xx responses, let me construct this example of multi-stage translation: Let us assume that sip:[EMAIL PROTECTED] routes to proxy 1. Proxy 1 knows that (one) target of this URI is Alice's AOR, sip:[EMAIL PROTECTED], which then routes to proxy 2. Proxy 2 knows the phone address for sip:[EMAIL PROTECTED], which is sip:[EMAIL PROTECTED] As the request reaches the UA at 10.1.1.1, the History-Info looks like this: History-Info: <sip:[EMAIL PROTECTED]>;index=1, <sip:[EMAIL PROTECTED]>;index=1.1, <sip:[EMAIL PROTECTED]>;index=1.1.1 This clearly gives the logical derivation of the destination address from the original request-URI (which is presumably also the To: value): sip:[EMAIL PROTECTED] -> sip:[EMAIL PROTECTED] -> sip:[EMAIL PROTECTED] Now let us modify the scenario by changing proxy 2 not to route the request itself, but rather to send a 302 response back to proxy 1. Within SIP, any agent that potentially routes a request can choose to send a 3xx response instead; in theory, all forking can be forced back onto the originating UA if downstream agents always send 3xx responses rather than routing. With the 302 response, the History-Info looks like this (taking liberties with the escaping): History-Info: <sip:[EMAIL PROTECTED]>;index=1, <sip:[EMAIL PROTECTED];cause=302>;index=1.1, <sip:[EMAIL PROTECTED]>;index=1.2 And this is the forking structure of the request. But it looses the logical structure of the translation; the UA at 10.1.1.1 does not see that it received the request "through" its AOR, sip:[EMAIL PROTECTED] The apparent derivation of the destination address is: sip:[EMAIL PROTECTED] -> sip:[EMAIL PROTECTED] (Although in practice the UA could guess from the "cause=302" on its ".1 sibling" that its fork was derived from the index=1.1 fork.) [MB] The idea of history-info is not to capture the "logical structure of the translation". The objective is to capture the history of the request as it makes its way to the destination. So, you do have a complete tree of the request history and your "Although,.." is the design intention. [/MB] And in the extreme case of a complex forking and retargeting structure, if all other agents used 3xx responses to implement it, the UAS would receive a History-Info whose indexes were all single integers, obscuring completely how its address was derived. [MB] Again, History-Info wasn't intended to track how an address was derived, but WHY a request was routed the way it was. So, you do know through a series of 3xx, that retargeting occurred and you do know the original target of the request and you do know the entity that handled the 3xx responses. [/MB] As I proposed earlier, I think getting around this problem will require adding an additional field-parameter to show how the address derivations are performed. In this example: History-Info: <sip:[EMAIL PROTECTED]>;index=1, <sip:[EMAIL PROTECTED];cause=302>;index=1.1, <sip:[EMAIL PROTECTED]>;index=1.2;redir=1.1 For diagnostic purposes, it would also be convenient if any other field-parameters on the Contacts of a 3xx response were copied into the derived History-Info elements. Only the "q" parameter seems to be useful information. A typical "serial fork" would then look like this when the request reached the second contact: History-Info: <sip:[EMAIL PROTECTED]>;index=1, <sip:[EMAIL PROTECTED];cause=302>;index=1.1, <sip:[EMAIL PROTECTED];cause=486>;q=1.0;index=1.2;redir=1.1 <sip:[EMAIL PROTECTED]>;q=0.9;index=1.3;redir=1.1 [MB] History-Info wasn't intended as a diagnostic tool and it doesn't seem reasonable to add all this other information to the entries. RFC 4244 clearly states that History-Info has limited diagnostic capabilities: " Some diagnostic information for debugging SIP requests. (Note that the diagnostic utility of this mechanism is limited by the fact that its use by entities that retarget is optional.) The intention is that the SIP messages themselves can be captured if you want to run diagnostics (acknowledging that you may not be able to get all traces at all nodes). [/MB] As an elaboration, if we suppose UA sip:[EMAIL PROTECTED] redirected the request to sip:[EMAIL PROTECTED], we could get: History-Info: <sip:[EMAIL PROTECTED]>;index=1, <sip:[EMAIL PROTECTED];cause=302>;index=1.1, <sip:[EMAIL PROTECTED];cause=486>;q=1.0;index=1.2;redir=1.1 <sip:[EMAIL PROTECTED];cause=302>;q=0.9;index=1.3;redir=1.1 <sip:[EMAIL PROTECTED]>;index=1.4;redir=1.3 This illustrates that the forking structure is flat (arranging the entries by their indexes): sip:[EMAIL PROTECTED] sip:[EMAIL PROTECTED] sip:[EMAIL PROTECTED] sip:[EMAIL PROTECTED] sip:[EMAIL PROTECTED] whereas the address derivation is more complex (placing each entry under the entry referenced by its 'redir' parameter): sip:[EMAIL PROTECTED] sip:[EMAIL PROTECTED] sip:[EMAIL PROTECTED] sip:[EMAIL PROTECTED] sip:[EMAIL PROTECTED] The latter is more useful for attacking the "UA loose route" problem. We still need to investigate what History-Info looks like if some of the participating proxies do not support it. Dale _______________________________________________ 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 _______________________________________________ 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
