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 14:58:34 -0400

Simple requirement: capture ALL retarget information in HI. Period

----- 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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 15 Jun 2009 15:13:34 -0400

> 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