I just realised that there is an additional problem that makes it even harder to do any distinction.
A UA may register as a contact an AOR of another user or resource. Effectively this causes the request to be forwarded to the other user by overwriting the Request-URI. So the fact that the Request-URI was overwritten due to a location lookup, doesn't tell you a bit about the nature of the rewrite. /Hans Erik van Elburg On Fri, Mar 13, 2009 at 10:53 PM, Mary Barnes <[email protected]>wrote: > 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
