When someone is calling the AOR, it will be replaced with the registered contact. Does it matter is someone else registered the contact/AOR? The call is not for that someone.
Regards, Christer -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Mary Barnes Sent: Saturday, March 14, 2009 4:47 PM To: Hans Erik van Elburg; [email protected] Subject: Re: [Sip] Issue 3 - two tags (wasRE:I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt Correct, you don't know anything about the URI that overwrites the request-URI. BUT, you know the type of URI that was overwritten (with respect to how it is used at the incoming Proxy). You know that the request URI that was overwritten was one of the types we've been discussing - i.e., a URI that can be used for a service Lookup in a Registrar, whether that URI is mapped, configured, etc. or whether that URI is just for a proxy hop - i.e., it's not a URI for which the proxy is responsible. And, you are using that tag against the URI that is being overwritten. Mary. ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of Hans Erik van Elburg Sent: Saturday, March 14, 2009 2:55 AM To: [email protected] List Subject: Re: [Sip] 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 ---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 _______________________________________________ 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
