Re: Issue 3 - two tags (was RE: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt

 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