To get discussion going for 2009, let me start with some complaints about the History-Info header.
One problem is identifying which value in the History-Info header corresponds to the request carrying the header, that is, which branch of the History-Info request tree represents the current request. Reading RFC 4244, it's clear that what is intended is that the History-Info values will be written in depth-first tree-walk order, and that syntactically *last* value corresponds to the request carrying the History-Info header. Neither of these principles is stated explicitly as far as I can tell. Difficulty arises when there is parallel forking, or any similar situation when a request has multiple redirects or retargets that become known in one processing step. If one maintains the rule that the enclosing request corresponds to the last History-Info value, one must choose among: (Assume that sip:[email protected] has been retargeted to sip:[email protected] and sip:[email protected].) 1.each derived request carries only one of the new History-Info values INVITE sip:[email protected] History-Info: <sip:[email protected]>;index=1, <sip:[email protected]>;index=1.1 INVITE sip:[email protected] History-Info: <sip:[email protected]>;index=1, <sip:[email protected]>;index=1.1 2.each derived request carries only the new History-Info values that are "before" (in some ordering) the one for the current request INVITE sip:[email protected] History-Info: <sip:[email protected]>;index=1, <sip:[email protected]>;index=1.1 INVITE sip:[email protected] History-Info: <sip:[email protected]>;index=1, <sip:[email protected]>;index=1.1, <sip:[email protected]>;index=1.2 3.each derived request carries all of the new History-Info values, but in each request, they are ordered so that the value corresponding to the request is last INVITE sip:[email protected] History-Info: <sip:[email protected]>;index=1, <sip:[email protected]>;index=1.1, <sip:[email protected]>;index=1.2 INVITE sip:[email protected] History-Info: <sip:[email protected]>;index=1, <sip:[email protected]>;index=1.1, <sip:[email protected]>;index=1.2 Solutions 1 and 3 are troublesome because the generated History-Info values are not consistent between the derived requests, and solutions 1 and 2 are troublesome because the downstream network elements are given less information than is available about the forking of the request. Note that this isn't just a theoretical problem, draft-rosenberg-sip-target-uri-delivery-00 is already running up against it (section 5): "Furthermore, if that URI had an 'index' of N, the URIs with indices N.M for all M, are the registered contacts to that URI." If the I-D is taken at face value, solution 3 must be used, giving different History-Info values on different derived requests. Let us then consider putting all known targets of a request in History-Info, but not require that the last History-Info value corresponds to the containing request. In terms of the above example, both derived requests would have the same History-Info header: INVITE sip:[email protected] History-Info: <sip:[email protected]>;index=1, <sip:[email protected]>;index=1.1, <sip:[email protected]>;index=1.2 INVITE sip:[email protected] History-Info: <sip:[email protected]>;index=1, <sip:[email protected]>;index=1.1, <sip:[email protected]>;index=1.2 If we do this, we need to be able to identify the value that corresponds to the current request by some method other than the index values and syntactic ordering. In a perfect world, we could compare the request-URI with the URIs in History-Info to see which one matches. However, this fails if: - two URIs in History-Info are the same (In theory, this should not happen, but it can happen sensibly if two derived requests differed substantially in some manner which could affect the ultimate resolution of the request-URI; e.g., caller preferences.) - if an intermediate proxy has changed the request-URI but not updated History-Info (In this case, we want to know which History-Info value corresponds to the most recent parent request that was logged in History-Info.) A more reliable solution would be to add a "current" marker to the leaf of the History-Info tree that corresponds to the containing request. In the example above: INVITE sip:[email protected] History-Info: <sip:[email protected]>;index=1, <sip:[email protected]>;index=1.1;current, <sip:[email protected]>;index=1.2 INVITE sip:[email protected] History-Info: <sip:[email protected]>;index=1, <sip:[email protected]>;index=1.1, <sip:[email protected]>;index=1.2;current ---------------------------------------------------------------------- A second problem with History-Info as it is currently structured is in the handling of requests generated as a consequence of recursing on 3xx responses. History-Info as it is now defined correctly shows the "forking structure" of a request. But we also want to know the "derivation" of the current request-URI, the sequence of transformations from the original request-URI (presumably the same as the To URI) to the current request-URI. Assuming that the transformations are done in the ordinary manner by proxies, History-Info carries the needed information. From RFC 4244 section 4.5: UA1 Proxy1 Proxy2 UA2 | | | | |--INVITE sip:b...@p1... -->| | | History-Info: <sip:[email protected]>;index=1 | |-INVITE sip:b...@p2... -->| | History-Info: <sip:[email protected]>;index=1, <sip:[email protected]>;index=1.1 | | | | | | |-INVITE sip:[email protected]>| History-Info: <sip:[email protected]>;index=1, <sip:[email protected]>;index=1.1, <sip:[email protected]>;index=1.1.1 In the last INVITE, starting with the last URI and working our way up the tree, we see that the URI sequence is: sip:[email protected] -> sip:[email protected] -> sip:[email protected] However, if one of the transformations is supplied by a 3xx response (e.g., if the request is sent to a "redirect server"), the History-Info data does not effectively show the source of the current request-URI: UA1 Proxy1 Proxy2 UA2 | | | | |--INVITE sip:b...@p1... -->| | | History-Info: <sip:[email protected]>;index=1 | |-INVITE sip:b...@p2... -->| | History-Info: <sip:[email protected]>;index=1, <sip:[email protected]>;index=1.1 | |<-- 302 Contact: <sip:[email protected]> | | | | | |-INVITE sip:[email protected]>| History-Info: <sip:[email protected]>;index=1, <sip:[email protected]?reason=sip%3bcause%3d302>;index=1.1, <sip:[email protected]>;index=1.2 The apparent URI sequence is: sip:[email protected] -> sip:[email protected] There is no unambiguous way determine that the target sip:[email protected] came from the 302 response to the request to sip:[email protected]. What is needed is a pointer from a History-Info value to the value representing the request which yielded the 3xx response that cause the value in question. I suggest using a parameter named "3xx" for this purpose, so that the last request in the above example becomes: INVITE sip:[email protected] History-Info: <sip:[email protected]>;index=1, <sip:[email protected]?reason=sip%3bcause%3d302>;index=1.1, <sip:[email protected]>;index=1.2;3xx=1.1 Which this additional information present, the predecessor of a listed URI is either the URI of its 3xx value (if present), or its parent in the tree. This allows us to recover the URI transformation sequence: sip:[email protected] -> sip:[email protected] -> sip:[email protected] 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
