Re: [stir] Call Forward/Follow-me

[Paul Kyzivat <[e-mail]>]

Hadriel,

You are right. I wasn't thinking clearly.

What H-I *can* do is identify who forwarded a call. This might be 
important to the forwardee - he might not want to answer unless it is 
from someone he knows. So H-I *can* serve as an alternative to an 
intermediary changing From or To when forwarding. (But it then leaves 
the recipient with difficulty in deciding which number it will display.)

	Thanks,
	Paul

On 6/7/13 4:10 PM, Hadriel Kaplan wrote:
>
> I'm getting confused by this thread.
> History-Info (or Diversion) is only useful to know the original *called* destination party, not *calling* source party.
>
> I.e., if the To-username gets changed by the PBX, Hist-info might tell you what it used to be... if the req-uri matched the To, and the PBX does Hist-Info, and all downstream devices pass it on, and if the final UAS could decipher which Hist-info to look at, and if the stars aligned.
>
> But if the From username got changed nothing will tell you what it used to be.  I think Brian was arguing the From should be changed by the PBX to be the new source of the new call, namely the PBX's main number or the To-number being forwarded from - because otherwise it's spoofing the From for this "new" call - but I don't think it should change the From because I contend it's not spoofing, but just routing the same call as a B2BUA.
>
> -hadriel
>
>
> On Jun 7, 2013, at 3:56 PM, Paul Kyzivat <[e-mail]> wrote:
>
>> On 6/7/13 2:23 PM, Alan Johnston wrote:
>>> I think that History-Info should be the solution going forward,
>>> certainly for SIP networks.
>>
>> I expect that there will be a variety of "solutions".
>> We aren't obligated to mandate one. Its only necessary to ban spoofing, and let people decide which alternative they want to use.
>>
>> If H-I was deployed across the full range of equipment out there, I'd expect that correct reporting of calling party would be very spotty.
>>
>> Now that calling is typically cheap enough that most people don't think about it, a simple solution to forwarding is 3xx, and to transfer is basic REFER. Those will get the calling party right. (Except in cases where you *want* the identify of the intermediary to be displayed. And that is the easy case.)
>>
>> 	Thanks,
>> 	Paul
>>
>>> - Alan -
>>>
>>>
>>> On Fri, Jun 7, 2013 at 1:17 PM, Rosen, Brian <[e-mail]
>>> <mailto:[e-mail]>> wrote:
>>>
>>>     A problem that has been noted is PBXs and other services that
>>>     implement Call Forward and Follow-me by spoofing From to be the
>>>     original caller when they originate a call from the PBX to the
>>>     ultimate destination.  They do this so that the called party sees
>>>     the original caller when they get the call.
>>>
>>>     If we outlaw spoofing, these services wouldn't be able to do that.
>>>       They would have to use History or other headers to pass the
>>>     original calling party number.
>>>
>>>     I believe that we can't continue to allow this kind of spoofing.
>>>       There are other headers which are appropriate for use.
>>>
>>>     One of the arguments given is that in older systems such as POTS or
>>>     2G/3G, there is no way to get caller ID to show data from the other
>>>     headers.  I think we have to accept such limitations.  Newer systems
>>>     would not have that problem of course.
>>>
>>>     While it may be unfortunate that something like forward or follow-me
>>>     doesn't work as well as it did, I think that it's the right tradeoff.
>>>
>>>     Please note that there are another class of calling party number
>>>     spoofing circumstances we CAN do something about.  Suppose a doctor
>>>     wants to place a call on her mobile that appears to come from her
>>>     office number.  In that case the doctor can authorize the service
>>>     that arranges that call.  They can get the cert for the office
>>>     number and authorize the service to place calls with that number by
>>>     giving them a cert for that authorization.  This also works for, as
>>>     an example, a call center placing calls for an enterprise.
>>>
>>>     The difference is, of course, that the "spoofed" number is a number
>>>     delegated to the entity spoofing, rather than the forward/follow me
>>>     case where the spoofed number is the calling party and the entity
>>>     spoofing is authorized by the called party.
>>>
>>>     Brian
>>>     _______________________________________________
>>>     stir mailing list
>>>     [e-mail] <mailto:[e-mail]>
>>>     https://www.ietf.org/mailman/listinfo/stir
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> stir mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/stir
>>>
>>
>> _______________________________________________
>> stir mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/stir
>
>