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

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