So, it appears we are both talking about the solutions that are currently described in 4244bis and target-uri (they are the same and one in 4244bis is more complete than the one in target-uri for obvious reasons). I view this solution to be tagging the entries with the "action" (whatever we call it) that resulted in the uri reflected in the hi-entry in the incoming request being overwritten by a "new" Request-URI in the outgoing request. Whereas, I had been concerned that the solution you had in mind was one whereby we were tagging the "new" Request-URI with the action that resulted in the "new" request URI. So your response clears my confusion, so we'll ignore the alternative suggestion (as that would only apply to that latter view of the solution - i.e., the one suggested below). Thanks, Mary.
________________________________ From: Hans Erik van Elburg [mailto:[email protected]] Sent: Thursday, March 12, 2009 4:26 PM To: Barnes, Mary (RICH2:AR00) Cc: Hans Erik van Elburg; [email protected] Subject: Re: [Sip] Issue 3 - two tags (was RE: I-D ACTION: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
