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
