Re: Terminology (was RE: Fwd: I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt

 
Hi,
 
IF we would remove that requierment, and ONLY care about the case when
the R-URI is replaced with the CONTACT, I don't think we need to do
anything. I believe P-Called-Party-ID already solves that.
 
Regards,
 
Christer


________________________________

	From: [email protected] [mailto:[email protected]] On
Behalf Of Elwell, John
	Sent: 12. maaliskuuta 2009 15:31
	To: Hans Erik van Elburg
	Cc: [email protected]
	Subject: Re: [Sip] Terminology (was RE: Fwd:
I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt
	
	
	Hans Erik,
	 
	The way I interpreted the 01 draft, you would not get the
freephone number anyway. If that is a requirement, then I accept my
suggestion won't suffice.
	 
	John


________________________________

		From: Hans Erik van Elburg
[mailto:[email protected]] 
		Sent: 12 March 2009 12:57
		To: Elwell, John
		Cc: [email protected]
		Subject: Re: [Sip] Terminology (was RE: Fwd:
I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt
		
		
		But that does not solve the freephone service use case.
Freephone represents a use case where the R-URI is replaced with an AoR
of user B - not with the contact of user B. 
		
		A calls Bfreephonenumber routed the B (AOR) routed to
B's contact.
		
		The target-uri draft is interested in obtaining:
Bfreephonenumber as that is what A used to reach B.
		
		So what we like to see that B UA receives is something
like
		    H-I:  Bfreephone; "istarget",\
		        B,\
		        contact-B
		
		So you want to get Bfreephonenumber and not B.
		
		In certain situations you are also interested in B, I
guess that  PBX's would interested in that to deliver to the correct
user. We could distinguish them like:
		    H-I:  Bfreephone; "istarget",\
		        B,"aor"\
		        contact-B
		
		BR,
		/Hans Erik van Elburg
		
		
		
		On Thu, Mar 12, 2009 at 12:08 PM, Elwell, John
<[email protected]> wrote:
		

			If 'istarget' is used only to identify the value
that was overwritten in
			the Request-URI by a contact URI, an alternative
approach would be to
			flag the contact URI H-I entry as 'iscontact'.
Then the UAS would just
			need to look for the most recent H-I entry that
is not marked
			'iscontact'.
			
			John
			
			
			________________________________
			
			       From: [email protected]
[mailto:[email protected]] On
			Behalf Of Hans Erik van Elburg
			       Sent: 12 March 2009 08:35
			       To: Mary Barnes
			       Cc: [email protected]
			       Subject: Re: [Sip] Terminology (was RE:
Fwd:
	
I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt
			


			       Yes, because you are using the 3261 use
of target and the
			4244bis introduced definition of retarget. I
thought it was clear that
			we need other words as those definitions don't
match the target-uri
			drafts use of the terms. Also they do not
suffice to provide a solution
			for the use cases in the target-uri draft.
			
			       The 3261 text you refer to is exactly
about the case where the
			home proxy overwrites the Request-URI with a new
target. This target is
			teh registered contact address. And hence this
would be what target-uri
			calls a hop or a route. This case and this is
where it gets confusing is
			not a "retarget" in the target-uri draft use of
the term.
			
			       The target-uri draft states:
			
			          "To avoid confusion, we
			          refer to a SIP URI that is an address
for a user or resource
			as a
			          "target" and a SIP URI that is a hop
for reaching that user
			as a
			
			          "hop".
			
			
			       Apparently that does not suffice to avoid
confusion.
			
			       As for the tagging, speaking about the
solution before agreeing
			on the terminology and the problem it should
solve is meaningless.
			
			       /Hans Erik van Elburg
			
			
			
			       On Thu, Mar 12, 2009 at 2:33 AM, Mary
Barnes
			<[email protected]> wrote:
			
			
			               Responses below [MB].
			
			
			               -----Original Message-----
			               From: Hans Erik van Elburg
			[mailto:[email protected]]
			
			               Sent: Wednesday, March 11, 2009
6:42 PM
			               To: Barnes, Mary (RICH2:AR00)
			               Cc: Shida Schubert; [email protected]
			               Subject: Re: Terminology (was RE:
[Sip] Fwd: I-D
	
ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt
			
			
			               I was talking about the concept.
			
			               The use cases only describe
cases where the target-uri
			(lets call that
			               current target from now) has been
lost when an initial
			request for a
			               dialog or standalone request
arrives at the UAS.
			
			               [MB] And I think this is where
the terminology confusion
			starts - I
			               don't think of the "lost"
target-uri as being the
			"current" target. In
			               my mind, the "current" target is
reflected by the last
			hi-entry and the
			               request-uri in the incoming
request at the UAS. If the
			entity that sent
			               the request was the entity that
added the last hi-entry,
			then the uri in
			               that hi-entry is the same as the
request-URI in the SIP
			request that
			               arrives at the UAS. I refer to
the "lost" uri as the one
			that was
			               "retargeted" - that's the one the
UAS wants to pull from
			the hi-entries
			               in the incoming request. That
hi-entry was not the one
			that was just
			               added by the entity that built
the request just received
			by the UAS.
			               That hi-entry is tagged with
whatever name we are going
			to tag it with
			               BEFORE the request is forwarded
(using the term forward
			per section 16.6
			               of RFC 3261).  That tag is added
once the target set of
			potential
			               candidates for the new request
uri are determined in
			section 16.5 of
			               3261 (with "target set" being a
3261 term), just before
			the request is
			               forwarded in section 16.6 to one
of those targets.  A
			new hi-entry
			               (which will be the last hi-entry
in the request received
			by the UAS) is
			               added in section 16.6 of 3261 as
the request is
			forwarded.  At this
			               point in time, the lost
information is in the previous
			hi-entry when the
			               outgoing request is sent. [/MB]
			
			
			               What has been lost is the current
target of the request:
			
			               [MB] Right - at which point in my
mind, it's no longer
			the current
			               target ;) Maybe we call it
"lost". [/MB]
			
			
			
			                    Current target
			
			                 The current target of an
initial request for a dialog
			or standalone
			                 request is the name or address
to which the request is
			targeted, i.e.
			                 either the initial target
inserted in the Request-URI
			by the UAC that
			                 originates the request, or when
a retarget occurred,
			the target
			                 provided in that retarget
operation.  Reroute and
			translation
			                 operations never change the
current target.
			
			
			               [MB] I don't think this
definition fits what you want -
			i.e., if there
			               is no retargeting, then none of
the hi-entries are
			tagged - i.e., you
			               won't have your concept of
current. The way it works is
			that if no
			               hi-entries are tagged, then you
know that there was no
			retargeting, thus
			               you know the request-uri has not
been lost. [/MB]
			
			
			               This defintion only makes sense
when the following
			definitions are used:
			
			               Name:
			
			                 A name is a moniker for an
entity which refers to it
			in a way which
			
			                 reveals nothing about where it
is in a network.  In
			SIP, tel URI
			
			                 which doesn't represent the
location of the entity is
			a name.
			
			
			               Address:
			
			                 An address is an identifier for
an entity which
			describes it by its
			
			                 location on the network.  In
SIP, the SIP URI itself
			is a form of
			
			                 address because the host part
of the URI, the only
			mandatory part of
			
			                 the URI besides the scheme
itself, indicates the
			location of a SIP
			
			                 server that can be used to
handle the request.
			
			               Route:
			
			                 Finally, a route is a
sequence of SIP entities
			(including the UA
			               itself!) which are
			
			                traversed in order to forward a
request to an address
			or name.
			
			               Retarget (other term might be
needed, as this is highly
			confusing):
			
			                  A Request-URI rewrite
operation that changes the
			target identity of
			               the request.
			
			               Reroute (other term might be
needed):
			
			                  A Request-URI rewrite
operation that does not change
			the current
			               target of the request, but
determines the route/next
			hop taken to
			               reach the target-identity.
			
			               /Hans Erik

_______________________________________________
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