I guess you mean that you agree with John that such rule can not be reliably construed. I dont think I have seen convincing proof that such is the case.
Are you also saying that we may only consider loose routing being used? 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. 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. 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. /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 > > > > > > /Hans Erik van Elburg > > > > > > > > On Fri, Mar 13, 2009 at 3:39 PM, Elwell, John > > <[email protected]> wrote: > > > > > > Hans Erik, > > > > But how does a proxy know what to use? How does it know whether > the > > received Request-URI, which it uses to query the LS, is a target > or > > an > > AoR? Does it need to scan back up the H-I chain to see whether > there > > is > > already an 'istarget' present, and if so use 'aor' instead of > > 'istarget'? > > > > John > > > > > > > > ________________________________ > > > > From: Hans Erik van Elburg > > [mailto:[email protected]] > > > > Sent: 13 March 2009 14:33 > > 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 > > > > > > Hi John, > > > > Well that is simple one would use different tags for > different > > type of entries, like in the example I already gave: > > > > H-I: Bfreephone; "istarget",\ > > B,"aor"\ > > contact-B > > > > Where the UAS interested in the initial target with which > it > > was > > addressed it would obtain the "istarget" tagged entry. > > Where the UAS interested in the AOR that was used to > address > > it > > would obtain the "aor" tagged entry. > > > > In simpler cases it could be that one entry holds the > "aor" as > > well as the "istarget" tag. > > > > Of course the algorithm needs some work to make it > complete. > > > > /Hans Erik van Elburg > > > > > > > > On Fri, Mar 13, 2009 at 3:24 PM, Elwell, John > > <[email protected]> wrote: > > > > > > Hans Erik, > > > > Following your detailed description, it seems > that the > > UAS serving a > > freephone number could receive one of the > following > > (assuming H-I is > > supported by all relevant nodes): > > > > 1) H-I containing: > > - the freephone number (tagged); > > - the AoR (tagged); > > - the contact URI (not tagged). > > > > Or > > > > 2) H-I containing: > > - the freephone number (tagged); > > - the contact URI (not tagged). > > > > The latter would occur when the same proxy > translates > > the freephone > > number (via the AoR) to the contact directly. > > > > So how does this help the UAS to figure out the > > freephone number? It > > seems the UAS would have to search back through > the > > tagged entries > > looking for one that matches a freephone number > it > > recognises? Does the > > tagging really add much value? > > > > John > > > > > > ________________________________ > > > > From: [email protected] > > [mailto:[email protected]] On > > Behalf Of Hans Erik van Elburg > > Sent: 12 March 2009 21:26 > > To: Mary Barnes > > Cc: Hans Erik van Elburg; [email protected] > > Subject: Re: [Sip] Issue 3 - two tags (was > RE: > > > > I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt > > > > > > > > Inline... > > > > /Hans Erik van Elburg > > > > > > > > On Thu, Mar 12, 2009 at 7:10 PM, Mary > Barnes > > <[email protected]> wrote: > > > > > > I think there is another solution > > proposal that we > > should pursue for issue 3 identified in the email > > summary sent by Shida > > earlier this week - I've snipped all the text > except > > for > > that issue and > > issue 2 in the summary below. I do think the > > discussion > > has confounded > > the two issues and I think it ought to be > clarified > > that > > if we agree to > > the two tags per issue 3, that the options for > the > > terminology MUST > > change. And, perhaps this is why the other > discussion > > threads aren't > > progressing well. > > > > > > Agree. > > > > > > > > So, Hans Erick, I would like > > clarification on as to your > > view on the solution: > > > > In general, ISTM that one of the > issues > > we're having in > > this terminology thread is that you are > considering > > the > > solution to be > > that the hi-entries are tagged as they > > are added to the request. > > And, just for > > clarification > > from my perspective, that is NOT the solution in > > either > > 4244bis or > > target-uri. > > > > > > The principle should be that the node that > has > > the information > > about what type of rewrite is performed should > add the > > tag. (This is > > done by the current target-uri draft allthough > the > > solution is not > > complete.) > > > > For the freephone service, that would be > the > > freephone service. > > For the AOR that is the home proxy. > > > > Assume that the freephone service receives > an > > INVITE request > > that either > > 1. received request contains History-Info > > header > > that contains > > the freephone number (as in R-URI) as last entry, > THEN > > when rewriting > > the Request-URI it has to tag that existing > received > > entry AND add the > > new entry with the new value of the Request-URI. > (I > > think that was how > > History-Info works right.) > > 2. received request contains History-Info > > header > > that does not > > contain the freephone number as last entry, THEN > when > > rewriting the > > Request-URI it has add an entry with the > freephone > > number and tag that > > entry AND add the new entry with the new value of > the > > Request-URI. > > 3. received request does not contain a > > History-Info header, THEN > > when rewriting the Request-URI it has to add an > entry > > with the freephone > > number and tag that entry AND add the new entry > with > > the > > new value of > > the Request-URI. > > > > After forwarding this request it arrives > at the > > home proxy: > > 1. received request contains History-Info > > header > > that contains > > the AOR (as in R-URI) as last entry, THEN when > > rewriting > > the Request-URI > > it has to tag that existing received entry AND > add the > > new entry with > > the new value of the Request-URI i.e. > > the registered > > contact. (I think > > that was how History-Info works right.) > > 2. received request contains History-Info > > header > > that does not > > contain the AOR (as in R-URI) as last entry, THEN > when > > rewriting the > > Request-URI it has add an entry with the AOR and > tag > > that entry AND add > > the new entry with the new value of the > Request-URI > > i.e. > > the registered > > contact. > > 3. received request does not contain a > > History-Info header, THEN > > when rewriting the Request-URI it has to add an > entry > > with the AOR as in > > the Request-URI and tag that entry AND add the > new > > entry > > with the new > > value of the Request-URI i.e. the registered > contact.. > > > > > > I don't view it as a problem > > necessarily > > if you'd like > > to pursue an alternate solution, we just need to > be > > clear that's what > > you're advocating. In that case, I would agree > the > > "retarget" is not an > > appropriate tag for the entries, as you don't > know at > > the point in time > > that you add an hi-entry that it will be > retargeted. > > In > > the case of this > > approach to the solution, you do have to alter > the > > mechanism for > > determining the hi-entry that your services would > want > > to use. You would > > need to skip the most recent/last hi-entry (as > that > > would contain the > > same as the Request-URI in the incoming request), > > > since > > it would be > > tagged if you use this solution approach. > > > > > > Yes, but only if the previous proxy added > it. > > As > > History-Info is > > optional one never knows really. > > > > > > > > Thus, you'd have to take the next > > hi-entry that you find > > that has the desired "tag". I will posit that we > > > could > > accomplish this > > solution without any changes to 4244 by just > > registering > > new SIP URI > > parameter(s). And, that's not to say > > we shouldn't do > > a 4244bis as > > there are other issues to address in that > document, > > but > > that allows the > > target-uri to describe a solution that makes use > of > > 4244bis "as is". > > > > > > > > Are you proposing to decouple the > target-uri > > and > > the 4244bis > > discussion? > > > > > > So, feedback on this specific > point > > (from > > Hans Erik and > > others) would be appreciated. > > > > > > > > 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 >
_______________________________________________ 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
