Subject: Re: [sipcore] The functional differences between 4244bis andtarget-uri (was FW: I-DAction:draft-barnes-sipcore-rfc4244bis-01.txt)

From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
Date: Mon, 15 Jun 2009 15:27:25 -0400

These make sense to me. I do not know about your tags?

----- Original Message -----
From: Mary Barnes <[email-masked]>
To: DOLLY, MARTIN C, ATTLABS; [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Sent: Mon Jun 15 15:21:16 2009
Subject: RE: [sipcore] The functional differences between 4244bis andtarget-uri (was FW: I-DAction:draft-barnes-sipcore-rfc4244bis-01.txt)

And, how do you map those to the tags in 4244bis and target-uri?  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of DOLLY, MARTIN C, ATTLABS
Sent: Monday, June 15, 2009 2:16 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [sipcore] The functional differences between 4244bis
andtarget-uri (was FW: I-DAction:draft-barnes-sipcore-rfc4244bis-01.txt)

1. Translation
2. Retarget
3. Redirect

----- Original Message -----
From: Paul Kyzivat <[email-masked]>
To: DOLLY, MARTIN C, ATTLABS
Cc: [email-masked] <[email-masked]>; [email-masked]
<[email-masked]>
Sent: Mon Jun 15 15:13:34 2009
Subject: Re: [sipcore] The functional differences between 4244bis
andtarget- uri (was FW:
I-DAction:draft-barnes-sipcore-rfc4244bis-01.txt)

DOLLY, MARTIN C, ATTLABS wrote:
> Simple requirement: capture ALL retarget information in HI. Period

We have had the ability to capture all retargeting with H-I since it was
first published. The new requirement is to distinguish different sorts
of retargeting. If so its very important that everybody understand the
meaning of each type and how to determine that type each time a request
is retargeted. I was getting the impression (may be wrong about it) that
a third type of retargeting was now being identified.

We need to agree on what it is that we are capturing.

	Thanks,
	Paul

> ----- Original Message -----
> From: [email-masked] <[email-masked]>
> To: Paul Kyzivat <[email-masked]>
> Cc: DOLLY, MARTIN C, ATTLABS; [email-masked] <[email-masked]>
> Sent: Mon Jun 15 08:20:15 2009
> Subject: Re: [sipcore] The functional differences between 4244bis 
> andtarget- uri (was FW: 
> I-DAction:draft-barnes-sipcore-rfc4244bis-01.txt)
> 
> 
>   I don't think it's a special case for free-dial alone.
> 
>   If service URN is used to deliver a service request such as 
> emergency call or directory assistance request to a local call-center,

> and takes a similar approach to what's defined in phoneBCP to support 
> devices not compliant to service URN, the translation to service URN 
> from the dial string will be done by the proxy. But the translation 
> from 911 to "sos" will only be seen in request URI and not in the To 
> header.
> 
>   So To header even without diversion is not dependable.
> 
>   Regards
>    Shida
> 
> On 15-Jun-09, at 6:28 AM, Paul Kyzivat wrote:
> 
>>
>> Hans Erik van Elburg wrote:
>>> But that does not work when a diversion to that service number takes

>>> place. It only works for direct calls to such service number.
>> Perhaps. That depends on *if* that is a reasonable scenario, and if 
>> so precisely what you want to happen in that case.
>>
>> For instance, does it really make sense for you to call me, and for 
>> me to then divert you to an 800 number? If so, is that supposed to 
>> behave as if you had called the 800 number?
>>
>> I realize there are many possible desired outcomes, so many 
>> strategies may be used from case to case.
>>
>> 	Thanks,
>> 	Paul
>>
>>> /Hans Erik
>>> Paul Kyzivat wrote:
>>>>
>>>> Hans Erik van Elburg wrote:
>>>>> Hi Paul,
>>>>>
>>>>> For what would you want to use the To-uri?
>>>> To decide who/what the caller desired to reach, and hence what 
>>>> treatment to give the call. This seems to be the key thing for the 
>>>> call centers that use freephone numbers.
>>>>
>>>>    Thanks,
>>>>    Paul
>>>>
>>>>> /Hans Erik
>>>>>
>>>>> Paul Kyzivat wrote:
>>>>>> This thing about the freephone services is an ugly one.
>>>>>> I've thought for a long time that the mechanism is an entirely 
>>>>>> brain dead way to designate who should pay for a call.
>>>>>>
>>>>>> But it is what it is, so I guess we have to cope with it.
>>>>>>
>>>>>> I wonder if perhaps this is really one of the few circumstances 
>>>>>> where the recipient of a call ought to make call handling 
>>>>>> decisions based on the To-uri. The reason I say this is because 
>>>>>> the "contract" with these numbers is that the caller expects the 
>>>>>> call will be free based on the form of the number being called.
>>>>>> And if the caller is wrong, it is the caller who gets charged.
>>>>>>
>>>>>> So, while I generally recommend that the To-uri be used for 
>>>>>> *nothing*, it might be right here. If so, then the whole target- 
>>>>>> uri/h-i discussion may be irrelevant to it.
>>>>>>
>>>>>>    Thanks,
>>>>>>    Paul
>>>>>>
>>>>>> Christer Holmberg wrote:
>>>>>>> Hi,
>>>>>>>> I'm going to spare details, but the main different is as 
>>>>>>>> follows.
>>>>>>>>
>>>>>>>> 1) RFC 4244bis
>>>>>>>>
>>>>>>>> In RFC 4244bis, if the domain is responsible for the URI in the
>>>>>>> Request-URI and it replacing it with a Contact, it will put a 
>>>>>>> reg-uri flag (if the Request-URI was the AOR used for 
>>>>>>> registration), or
>>>>>>> reg-
>>>>>>>> uri-alias (if the Request-URI was an alias for the AOR used in
>>>>>>> registration).
>>>>>>>> If the domain is responsible for the URI and it "maps" it to a
>>>>>>> different user, then it puts a "mapped" flag.
>>>>>>>> If the domain is NOT responsible for the AOR but it changes the
>>>>>>> Request-URI nevertheless, then it is also marked as "mapped".
>>>>>>>>    Note: With loose routing, this is not supposed to  
>>>>>>>> happen     (at least in theory).
>>>>>>>>
>>>>>>>> This next statement is where there is a big difference:
>>>>>>>>
>>>>>>>> If the domain is NOT responsible for the URI, the mapping 
>>>>>>>> cannot know
>>>>>>> if the new URI is belongs to the same User than the original 
>>>>>>> one. This is why it is mapping: it is impossible for a proxy NOT
>>>>>>>> responsible for a URI to change it to something else and "know"

>>>>>>>> if it a
>>>>>>> different user (retarget) or just a "synonym" for the same user.
>>>>>>>
>>>>>>> We don't think it is "impossible", and we see no reason why we 
>>>>>>> should make that restriction without any technical 
>>>>>>> justification. The proxy does not change the URI just for fun, 
>>>>>>> with a value out of the blue - it does it based on some kind of 
>>>>>>> knowledge/configuration.
>>>>>>>
>>>>>>>> 2) Target-UI
>>>>>>>>
>>>>>>>> In target-URI, there is an assumption that a domain NOT 
>>>>>>>> responsible for
>>>>>>> a URI can change the URI to something AND know authoritatively 
>>>>>>> that the new target is a "synonym" for the original target.
>>>>>>>
>>>>>>> Correct.
>>>>>>> And, I assume the difference between "synomym" and "alias" is 
>>>>>>> that a synonym URI is not registered for the called user, right?
>>>>>>>
>>>>>>> But, one question for clarification: if the "synonym"  
>>>>>>> translation is
>>>>>>> done by an entity which IS reponsible for the domain, how is it 
>>>>>>> tagged?
>>>>>>>
>>>>>>> -------------
>>>>>>>
>>>>>>>> So this is what it boils down to.
>>>>>>> I think that is more or less what I was trying to say.
>>>>>>>
>>>>>>>> Can a domain NOT responsible for a target change the target AND

>>>>>>>> mark
>>>>>>> the new target authoritatively as "belonging" to the same user?
>>>>>>>> In target-URI, the assumption is yes.
>>>>>>>>
>>>>>>>> In 4244bis, the assumption is no (only the domain responsible 
>>>>>>>> for the
>>>>>>> URI can do so).
>>>>>>> Correct.
>>>>>>>
>>>>>>> -------------
>>>>>>>
>>>>>>>> As pointed out by Paul Kyzivat, we probably need to think on 
>>>>>>>> how this
>>>>>>> works with Tel URIs. I think for Tel URI it would be totally 
>>>>>>> different.
>>>>>>>
>>>>>>> Yes. You raised that also in our private discussions, but we 
>>>>>>> never discussed it in details.
>>>>>>>
>>>>>>> So, before we start discussing the protocol details, I think we 
>>>>>>> need to solve the issues above.
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Christer
>>>>>>> _______________________________________________
>>>>>>> sipcore mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/sipcore
>>>>>>>
>>>>>> _______________________________________________
>>>>>> sipcore mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/sipcore
>> _______________________________________________
>> sipcore mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/sipcore
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore

---

From: "Mary Barnes" <[email-masked]>
Date: Mon, 15 Jun 2009 14:48:17 -0500

Here's the two sets that we're currently discussing:

4244bis (based entirely on RFC 3261 based request routing and
forwarding, which is why it's not entirely clear what your labels imply:

       * "noop": There is no change whatsoever in the target.  The
         Request-URI is unchanged.  This would apply for example when a
         proxy merely forwards a request to a next hop proxy and loose
         routing is used.

      *  "predetermined": This is the case where retargeting is
         predetermined by the content of the request itself, i.e., the
         Request-URI contained a maddr, the domain of the Request-URI
         indicates a domain the proxy is not responsible for, or strict
         routing is used and the request is forwarded to another proxy.

      *  "reg-uri": The Request-URI is replaced with a registered
         Contact bound to the AOR indicated by the Request-URI.  For
         example, if the REGISTER message had a To header field with the
         AOR <sip:[email-masked]>, and a Contact header field of
         <sip:[email-masked]> , the Request-URI <sip:[email-masked]>
         would be changed to <sip:[email-masked]>.

      *  "reg-uri-alias": The Request-URI is replaced with a registered
         Contact bound to an AOR that is an alias of the Request-URI.
         An AOR is an Alias of another AOR if both entities belong to
         the same implicit registration set, are linked to the same
         profile and have the same data configured.  For example, if
         <sip:[email-masked];user=phone> and
         <sip:[email-masked]> are configured as aliases for the
         AOR sip:[email-masked]> (where the registered Contact of
         <sip:[email-masked]> is bound to <sip:[email-masked]>, a
         Request-URI of <sip:[email-masked]> or
         <sip:[email-masked];user=phone> would be changed to
         <sip:[email-masked]>.

      *  "mapped": The Request-URI is replaced with another URI that is
         not a Contact associated with the AOR in the Request-URI or one
         of its aliases.  For example, this would apply when the request
         is retargeted to a different user.

And here's the ones in target-uri, which is based on a combination of
tags:

   o  aor, mapped: AOR that was translated (using an abstract location
      service) to an AOR belonging to a different user or resource

   o  aor, routed: AOR that was translated (using an abstract location
      service) to a different AOR or contact address belonging to the
      same user or resource

   o  routed: Request URI was rewritten for routing purposes (including
      strict routing, no-op/loose-routing, maddr)

So, we're debating here the differences between the "aor,mapped" and
"aor,routed" vs "predetermined", "reg-uri" and "reg-uri-alias".  I think
that "reg-uri-alias" and "reg-uri" are equivalent to "aor, routed".
And, I think one could consider the "aor,mapped" as predetermined. But,
again 4244bis tags the entries entirely based on what SIP does and if
the 800 number translations (or whatever services) are setup differently
in different proxies, then you can't determine if the "aor,routed" cases
might be "reg-uri-alias" or "reg-uri".  Although, I am personally
confused as to whether an 800 number would always be "aor, mapped" or
"aor, routed" - i.e., I just don't see this being deterministic and I
think that if a service can reach a UAS through different SIP
retargeting mechanisms, then the UAS needs to be aware. 

Also, as I'm going through this, I think we need 3 more tags if we want
the proxy to do the tagging - i.e., I think we need to add "-aor" to the
"predetermined", "reg-uri" and "reg-uri-alias" IF we agree that the
proxy will mark in this manner. 

Mary. 

----- Original Message -----
From: Mary Barnes <[email-masked]>
To: DOLLY, MARTIN C, ATTLABS; [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>; [email-masked]
<[email-masked]>
Sent: Mon Jun 15 15:21:16 2009
Subject: RE: [sipcore] The functional differences between 4244bis
andtarget-uri (was FW: I-DAction:draft-barnes-sipcore-rfc4244bis-01.txt)

-----Original Message-----

1. Translation
2. Retarget
3. Redirect

----- Original Message -----
From: Paul Kyzivat <[email-masked]>
To: DOLLY, MARTIN C, ATTLABS
Cc: [email-masked] <[email-masked]>; [email-masked]
<[email-masked]>

	Thanks,
	Paul