I just realised that there is an additional problem that makes it
even harder to do any distinction.
A UA may register as a contact an AOR of another user or resource.
Effectively this causes the request to be forwarded to the other
user by overwriting the Request-URI.
So the fact that the Request-URI was overwritten due to a location
lookup, doesn't tell you a bit about the nature of the rewrite.
/Hans Erik van Elburg
On Fri, Mar 13, 2009 at 10:53 PM, Mary Barnes
<[email protected]> wrote:
Responses below [MB].
________________________________
From: Hans Erik van Elburg [mailto:[email protected]]
Sent: Friday, March 13, 2009 4:17 PM
To: Barnes, Mary (RICH2:AR00)
Cc: Elwell, John; [email protected]
Subject: Re: [Sip] Issue 3 - two tags (was RE:
I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt
I guess you mean that you agree with John that such rule can not be
reliably construed.
[MB] Which rule? I fully agree we can discern the 3 cases as I
explained below. Per 16.5 (Determining Request Targets) in RFC 3261,
these are unique and recognized situations. The reason I refer to
loose
routing is that it's my understanding it is far more commonly used and
RFC 3261 doesn't even describe strict routing - it focuses on loose
routing and strict routing support is for 2543 backwards compatibility
as I understood. But, actually it makes no difference to History-Info
processing. The important thing really, is that you MUST tag the old
entry as you are doing the processing per 16.5 as that information is
lost by the time you get around to adding the next History-Info header
in section 16.6 ( Request Forwarding). I think one thing that might be
being missed in this thread is that I have been very careful to rely
explicitly on what is described in 16.5 - that a must read to
understand
what I am saying - again there is a lack of clarity in that section
and
we can suggest clarifications once we all can finally agree
appropriate
terms. If you'd like me to pull the explicit text that supports
everything I've been saying, I can do so, but it's somewhat a waste of
time. [/MB]
I dont think I have seen convincing proof that such is the case.
[MB] And, I'm not saying that you can't construct such a rule -
indeed I
am saying that you certainly should be able to per RFC 3261 section
16.5. Can you point out what text below that suggests I am saying
that?
[/MB]
Are you also saying that we may only consider loose routing being
used?
[MB] Nope. [/MB]
Further for "configured mappings" for which we never saw a proper
definition. But assuming that this is a proxy that can be configured
to
do a Request-URI rewrite based on some configured setting.
[MB] The concept of "configured mappings" is described in RFC 3261 -
perhaps not with the level of granularity or specificity that some
might
desire, but it's there - it's initially described as an abstract
location service (1st Paragraph section 16.5). And, then later it
specifies that a proxy can determine "targets" (3261 term not mine)
just
about any ole way it wants, so I don't know that we need to define a
new
term for "configured mappings" per se - there is no limitation as to
the
mechanism one can use to determine the request-URI for the outgoing
request (once it is determined that the Proxy is ALLOWED to overwrite
the request-URI - the right domain, etc.), This is a fundamental SIP
concept that many products use to give a (human) user flexibility in
configuring where an incoming call might terminate. So, I see no issue
at all is specifying two tags to capture this rewrite as it's
already in
section 16.5 that this is information that a Proxy should be able to
derive. [/MB]
In that case there are two variants of such mapping:
1. A mapping that changes the identity of the target to be reached.
(This is what call forwarding or diversion does normally.)
2. A mapping that only changes the next hop route taken towards the
target identity that has not been changed.
For the UAS it only matters that the home domain does the tagging
consistently and correctly if it wants to rely on such information.
[MB] I don't know that I agree it's the home domain - it's a proxy
that
has responsibility for the domain in the request-URI that is able to
do
the service lookup or using any other sort of mapping to determine the
new URI for the request-URI in the outgoing request. I don't know
that
we want to restrict that to the "home" domain. If we restrict it to
the
home domain, then that implies that we are only tagging the entries
that
are determined based on service lookup in a Registrar (per RFC 3261's
definition of a "home domain"). [/MB]
Otherwise we would have to start adding information about the domain
that added a specific hi-entry, if one wants to be sure who added the
particular hi-entry.
[MB] I'm not sure why this would be needed and I wasn't espousing that
it would - we know by definition that the domain that mucked with a
URI
is the domain associated with the URI that was overwritten/lost, etc.
[/MB]
/Hans Erik van Elburg
On Fri, Mar 13, 2009 at 7:43 PM, Mary Barnes <[email protected]>
wrote:
Hi John,
Thanks for all your feedback thus far on this topic. I have a
couple
comments below [MB].
Mary.
-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of
Elwell, John
Sent: Friday, March 13, 2009 11:31 AM
To: Hans Erik van Elburg
Cc: [email protected]
Subject: Re: [Sip] Issue 3 - two tags (was RE:
I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt
> -----Original Message-----
> From: Hans Erik van Elburg [mailto:[email protected]]
> Sent: 13 March 2009 14:52
> 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
>
> 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".
[JRE] It does not know that this is the first target, because
upstream
nodes may have retargeted without inserting H-I. In any case,
the To
header field URI is the first target, so we don't need that
anyway.
[MB] John is correct. There is no rule about tagging the first
History-Info entry. It may be tagged if the next node changes
the
request-URI via a service lookup or some other manner such as
configuration.[/MB]
I can accept that a proxy might know, having done a LS look-up,
whether
the new URI is a registered contact or some other URI, and on
that basis
it could choose whether or not to insert a single tag. I
thought
that
was the basis on which we agreed to go ahead with this updated
to RFC
4424, rather than following the loose route draft. It is not
clear to me
that a proxy would have enough information to make a 3-way
choice.
[MB] My understanding is that there are just two ways in which
the
request-URI changes if you are using loose routing. It's either
changed
due to a lookup in a location server, whose information was
populated by
the UA during registration, OR it is changed due to
configuration data
(either system, user, etc.). In both cases, obviously, the
proxy
that is
doing this is responsible for the domain of the request-URI in
the
incoming request. If it were not the case, then all the proxy
can do is
forward the outgoing request to the next hop. So, I think that
may be
where the concept of a 3rd choice comes in. But, as far as
tagging, we
(as I understand it) at least were discussing the potential of
two tags
only - i.e., further differentiating the cases that are
currently all
captured by the "retarget" as defined in 4244bis, which is the
same
mechanism that is specified in the target-uri document EXCEPT
that
document was only capturing the service lookups, which we
believe is
incorrect. [/MB]
John
>
---remainder of theread snipped by 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
