3-way choice? A proxy that has retargeting logic knows when it is doing so. A proxy that has rerouting logic to registered contact knows when it is doing so.
No 3-way magic there. And yes the History-Info is optional so you never know if all nodes in the chain do there bit. But that is fact of life. As long as you can ensure that in your domain it is supported you will receive correct information. /Hans Erik van Elburg On Fri, Mar 13, 2009 at 5:31 PM, Elwell, John <[email protected]>wrote: > > > > -----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. > > 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. > > 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
