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".
/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
