Responses below [MB]. ________________________________
From: Hans Erik van Elburg [mailto:[email protected]] Sent: Friday, March 13, 2009 4:17 PM To: Barnes, Mary (RICH2:AR00) Cc: Elwell, John; [email protected] Subject: Re: [Sip] Issue 3 - two tags (was RE: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt I guess you mean that you agree with John that such rule can not be reliably construed. [MB] Which rule? I fully agree we can discern the 3 cases as I explained below. Per 16.5 (Determining Request Targets) in RFC 3261, these are unique and recognized situations. The reason I refer to loose routing is that it's my understanding it is far more commonly used and RFC 3261 doesn't even describe strict routing - it focuses on loose routing and strict routing support is for 2543 backwards compatibility as I understood. But, actually it makes no difference to History-Info processing. The important thing really, is that you MUST tag the old entry as you are doing the processing per 16.5 as that information is lost by the time you get around to adding the next History-Info header in section 16.6 ( Request Forwarding). I think one thing that might be being missed in this thread is that I have been very careful to rely explicitly on what is described in 16.5 - that a must read to understand what I am saying - again there is a lack of clarity in that section and we can suggest clarifications once we all can finally agree appropriate terms. If you'd like me to pull the explicit text that supports everything I've been saying, I can do so, but it's somewhat a waste of time. [/MB] I dont think I have seen convincing proof that such is the case. [MB] And, I'm not saying that you can't construct such a rule - indeed I am saying that you certainly should be able to per RFC 3261 section 16.5. Can you point out what text below that suggests I am saying that? [/MB] Are you also saying that we may only consider loose routing being used? [MB] Nope. [/MB] Further for "configured mappings" for which we never saw a proper definition. But assuming that this is a proxy that can be configured to do a Request-URI rewrite based on some configured setting. [MB] The concept of "configured mappings" is described in RFC 3261 - perhaps not with the level of granularity or specificity that some might desire, but it's there - it's initially described as an abstract location service (1st Paragraph section 16.5). And, then later it specifies that a proxy can determine "targets" (3261 term not mine) just about any ole way it wants, so I don't know that we need to define a new term for "configured mappings" per se - there is no limitation as to the mechanism one can use to determine the request-URI for the outgoing request (once it is determined that the Proxy is ALLOWED to overwrite the request-URI - the right domain, etc.), This is a fundamental SIP concept that many products use to give a (human) user flexibility in configuring where an incoming call might terminate. So, I see no issue at all is specifying two tags to capture this rewrite as it's already in section 16.5 that this is information that a Proxy should be able to derive. [/MB] In that case there are two variants of such mapping: 1. A mapping that changes the identity of the target to be reached. (This is what call forwarding or diversion does normally.) 2. A mapping that only changes the next hop route taken towards the target identity that has not been changed. For the UAS it only matters that the home domain does the tagging consistently and correctly if it wants to rely on such information. [MB] I don't know that I agree it's the home domain - it's a proxy that has responsibility for the domain in the request-URI that is able to do the service lookup or using any other sort of mapping to determine the new URI for the request-URI in the outgoing request. I don't know that we want to restrict that to the "home" domain. If we restrict it to the home domain, then that implies that we are only tagging the entries that are determined based on service lookup in a Registrar (per RFC 3261's definition of a "home domain"). [/MB] Otherwise we would have to start adding information about the domain that added a specific hi-entry, if one wants to be sure who added the particular hi-entry. [MB] I'm not sure why this would be needed and I wasn't espousing that it would - we know by definition that the domain that mucked with a URI is the domain associated with the URI that was overwritten/lost, etc. [/MB] /Hans Erik van Elburg On Fri, Mar 13, 2009 at 7:43 PM, Mary Barnes <[email protected]> wrote: Hi John, Thanks for all your feedback thus far on this topic. I have a couple comments below [MB]. Mary. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Elwell, John Sent: Friday, March 13, 2009 11:31 AM To: Hans Erik van Elburg Cc: [email protected] Subject: Re: [Sip] Issue 3 - two tags (was RE: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt > -----Original Message----- > From: Hans Erik van Elburg [mailto:[email protected]] > Sent: 13 March 2009 14:52 > To: Elwell, John > Cc: [email protected] > Subject: Re: [Sip] Issue 3 - two tags (was RE: > I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt > > It knows when it rewrites the Request-URI due to a location lookup --> > tag "aor". > It knows (is configured to) when it rewrites the Request-URI with a > value that leads the request to target with a different identity then > the one that has been replaced --> tag new entry "istarget". > It knows when it rewrites the Request-URI with a value and this leads > to the first History-Info entry being recorded --> tag "istarget". [JRE] It does not know that this is the first target, because upstream nodes may have retargeted without inserting H-I. In any case, the To header field URI is the first target, so we don't need that anyway. [MB] John is correct. There is no rule about tagging the first History-Info entry. It may be tagged if the next node changes the request-URI via a service lookup or some other manner such as configuration.[/MB] I can accept that a proxy might know, having done a LS look-up, whether the new URI is a registered contact or some other URI, and on that basis it could choose whether or not to insert a single tag. I thought that was the basis on which we agreed to go ahead with this updated to RFC 4424, rather than following the loose route draft. It is not clear to me that a proxy would have enough information to make a 3-way choice. [MB] My understanding is that there are just two ways in which the request-URI changes if you are using loose routing. It's either changed due to a lookup in a location server, whose information was populated by the UA during registration, OR it is changed due to configuration data (either system, user, etc.). In both cases, obviously, the proxy that is doing this is responsible for the domain of the request-URI in the incoming request. If it were not the case, then all the proxy can do is forward the outgoing request to the next hop. So, I think that may be where the concept of a 3rd choice comes in. But, as far as tagging, we (as I understand it) at least were discussing the potential of two tags only - i.e., further differentiating the cases that are currently all captured by the "retarget" as defined in 4244bis, which is the same mechanism that is specified in the target-uri document EXCEPT that document was only capturing the service lookups, which we believe is incorrect. [/MB] John > ---remainder of theread snipped by Mary. -------- _______________________________________________ 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
