More responses inline below [MB2]. -----Original Message----- From: Worley, Dale (BL60:9D30) Sent: Wednesday, February 11, 2009 3:44 PM To: Barnes, Mary (RICH2:AR00) Cc: SIP Subject: RE: [Sip] Problems with History-Info
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. [MB2] With the indices, it actually doesn't matter if the entries are added in depth first order. However, RFC 4244 does specify in section 4.3.3.1 that the entries MUST be added following any HI entry received in the request. Now, certainly, in the parallel forking situation, you wouldn't know if an entry 1.2.1 was really added before an entry 1.3.1, but that's more because the order of responses is entirely indeterminate per core SIP when a request is forked. It might be sensible (but not required for things to work) that the proxy that forked the requests would keep the HI entries grouped logically. We could add a suggestion to this effect in the -bis. [/MB2] 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. [MB2] When a proxy receives a request that doesn't have an entry for the hop that got the request to this proxy, then it is suggested to add an entry, so if I understand you, yes, when a request reaches a proxy, the last entry should be the same as the request URI in the request. I don't know how that can be stated more clearly as that's a fundamental to how HI is captured and comprises the basic definition of the "Targeted-to-URI" field in the header per section 4.1. It's also described in section 4.3.1 (UAC behavior). It may not be quite so clear in section 4.3.3.1 (Proxy behavior) and we could be more explicit about that when we discuss that "if the request doesn't contain a History-Info header" to state the "hi-targeted-to-uri" is set to the URI in the request". [/MB2] > 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. [MB2] Per the spec the only reason to drop entries is due to privacy and yes, you will know there's been a branch, you just may not know what the request URI was for that branch nor what the leaves are - kindof like an incomplete family tree. And, section 5 (item 3) does highlight the importance for applications to deal with these situations. So, I'm still confused as to what text in the current specification is lacking. [/MB2] 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. [MB2] I can't see a source of confusion in the RFC - it's talking about subsequent retargets - i.e., another instance of retargeting and it is consistent with examples. How would you state it more accurately? Sorry, I can't grok your point above, so I can't quite see a way to qualify the text to resolve your concern. [/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 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. [MB2] I'm not clear on why you see case 1 as correct, when the index is wrong. Yes, in the case of parallel forking that's all the info the proxy has - i.e., HI can't be more deterministic or provide more information than what you would get from looking at a message trace. But, that wouldn't be the case for sequential. [/MB2] > [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? [MB2] I'm not sure of your use of the term "subset" here. If you're suggesting that only the branches (and not the leaves for a given branch) are required, that's not really the case UNLESS the privacy header is being used for some of entries. You can't determine from the HI entries whether UserC was in the Contact header for the response to the request forwarded to UserA or UserB OR whether UserC was a 3rd parallel forked request. The only way to know that for certain would be to look at the message trace. It's up to a proxy as to how it might arbitrate the receipt of the 3xx responses - it is not REQUIRED that there even be a Contact header in the 3xx. History-Info captures "Why" the request to UserA and UserB was not successful and NOT why the new request URI is chosen. [/MB2] (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.) [MB2] Which request URI in the above example is contained in more than one HI entry? There are 4 HI entries with 4 different request URIs: [email protected], [email protected], [email protected] and [email protected] However, it really doesn't matter as there's nothing that states that the same HI value can't be in multiple entries - it's the indices that matter - per section 4.3.3.1, this would be just the case if you are doing loose routing. [/MB2] 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
