Hi Dale, Sorry for the delay in responding - responses below [MB].
Mary. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Worley, Dale (BL60:9D30) Sent: Sunday, February 01, 2009 1:54 PM To: SIP Subject: [Sip] Problems with History-Info 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. [MB] RFC 4244 is clear that the entries are in a tree structure - you are correct that we don't identify it as a "depth-first" and perhaps we can add that, although I think it's quite clear from examples and normative text. As far as your concern wrt to "synctactically *last* value corresponds to the request carrying HI", I'm not sure what you mean here. [/MB] 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: [MB] There is not a problem here. The spec is very clear about what happens when a proxy (sip:[email protected]) retargets either sequentially or in parallel. And, RFC 4244 defines a 4th choice not listed below: 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.2 This is specified in section 4.3.3.1.3, in particular steps 2 and 3 result in the above HI entries with an example of this behavior in section 4.5 (sorry no figure number - something we should add in the -bis). Per the spec, there are never any entries that are identical - if there, it's a bug. If you think there is text in RFC 4244 that contradicts this, please identify it and we can clarify it in the -bis. [/MB] (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]. [MB] I don't see a problem here, as you can indeed determine that the request was retargetted to User2 as a result of the 3xx - Proxy 1 absolutely knows that and that's the reason why the "reason" is added to the previous HI entry - i.e., the rule being that the reason is associated with the "Why the request was retargeted?" from the previous HI entry ([email protected]) to the new HI entry [email protected]). Thus, you can derive the sequence from the above -i.e., it's ALL there in that last INVITE. It does require that you look for the reason, but you really don't need the redundant data. An old, old version of this document actually did have redundant data in that the "old" and "new" were captured in each entry. The current approach is that if the "old" isn't captured, then the entity retargeting captures it along with the "new" to ensure that you have the entire chain. If you can point to the specific text that seems to introduce the gap you suggest, that would be helpful and we can make sure it's clear in the -bis. [/MB] 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 _______________________________________________ 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
