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
