On Wed, 2009-02-11 at 11:44 -0500, Barnes, Mary (RICH2:AR00) wrote: > > 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]
What I see is that all examples are presented in depth-first order, and various operations are described in terms of "adding a value". But I don't see a specification that the values must be listed in depth-first order, nor that the added values must go in a certain position in the list of values. Given that the values are tagged with indexes, I could interpret the text to mean that the values are associated based on their index values, and it was just convenience or accident that all examples presented in the RFC were written in depth-first order. In regard to "syntactically last", I was looking at the question of knowing which entry in History-Info is meant to describe the request that contains it. It seems from the examples that the current request is described by the linearly last (lowest-rightmost in tree order) element, but it's not clear that is intended to be specified. One could search for the request-URI in the History-Info elements, but (1) URI matching is treacherous, and (2) one can construct cases where the same request-URI can sensibly appear in more than one incarnation of an INVITE. It seems that the intention is that the last element is expected to match the current request, but I don't see that stated. > 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] I'll grant I overlooked that example. The implication is that the tree presented in History-Info can be *incomplete*, there can be a 1.2 branch without a 1.1 branch, not because the user used weird numbering, but because there is a 1.1. branch that is not being described in this History-Info -- something that is not so common in representations of trees, and doesn't seem to be explicitly pointed out in the text. In regard to 4.3.3.1.3, the text is not very clear if you don't already know what it means: Retargeting within a Proxy - subsequent instance: For each subsequent retargeting of a request by the same proxy, another branch is added. With the index for each new branch calculated by incrementing the last/lowest digit at the current level, the index in the next request forwarded by this same proxy, following the example above, would be 1.1.2. What is not stated is that the first forked request gets the xxx.1 value added to its History-Info, the second forked request gets the xxx.2 value added to its History-Info (but not the xxx.1 value), etc. When I read this, I assumed that "instance" meant History-Info value, and that each forked request was expected to have the same set of History-Info values, namely the whole set generated by the forking, of which the first "instance" would be numbers xxx.1, etc. > (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 So the correct answer is case 1, but modified in that the index for sip:[email protected] is 1.2; the numbering was globally consistent across all the History-Info values, but that each value was a subset of the global forking tree. > [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] I was thinking of the case where there are two or more forks preceding the current fork that have returned 3xx. It seems that you'd get H-I like: History-Info: <sip:[email protected]>;index=1, <sip:[email protected]?reason=sip;cause=302>;index=1.1, <sip:[email protected]?reason=sip;cause=302>;index=1.2, <sip:[email protected]>;index=1.3 >From that, I don't see how to determine whether UserC was generated from UserA1 or UserB, or for that matter, if it was derived from UserA. Perhaps there is an unstated rule that History-Info should contain only that subset of the global forking tree that describes requests that are logically ancestral to the request that contains it? (Oh, yeah, and the example in RFC 4244 from which I derived the above example is: F12 486 Busy Here Proxy1 -> UA1 SIP/2.0 486 Busy Here Via: SIP/2.0/UDP example.net:5060 From: Alice <sip:[email protected]> To: Bob <sip:[email protected]> Call-Id: [email protected] History-Info: <sip:[email protected]>; index=1, <sip:[email protected]?reason=sip;\ cause=302; text="Moved Temporarily">;index=1.1, <sip:[email protected]?reason=sip;cause=480;\ text="Temporarily Unavailable" >;index=1.2, <sip:[email protected]>;index=1.3 CSeq: 1 INVITE Content-Length: 0 Note that it presents a case where one request-URI appears in more than one History-Info value, which was a question I raised above.) 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
