Re: [stir] Call Forward/Follow-me

[Hadriel Kaplan <[e-mail]>]

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