Subject: Re: [dispatch] [cnit] [stir] Application servers - Re: Call Center Implications

From: "Richard Shockey" <[email-masked]>
Date: Thu, 31 Oct 2013 08:49:19 -0400

Brian please.. Look at the mail.   I'm using the CNIT list.  

The issue is can we use the tools at hand to increase both the accuracy,
reliability and the amount of data that is delivered to the CUA over who is
attempting to establish a session.

The larger issue is the integrity of the entire real time communications
system as it moves to an all IP world.  Irrespective if CNAM it is delivered
as part of From: or PAI its not very useful to the consumer. 

CNAM as it is currently defined in SS7 is a terrible service.  15 Character
ASCII.  No support for International character sets the usual.

It is not a hard stretch to postulate that called parties might like a
richer set of data displayed on their UA's and that can be delivered by the
SIP headers in some relatively simple form. Modification of the Call-Info
header for instance. It is equally not a stretch to think that National
Regulators would be delighted with consumers having a richer set of
information displayed on their handsets in order to make more decisions.  In
addition if we can achieve better all IP to IP interconnection among
providers it would be really really useful if Enterprise systems could
extract more data from their internal directory systems  and pass that along
in the new format for enterprise calling as well.

I would certainly argue that we are not going to see ubiquitous Point to
Point video calling using WebRTC or SIP if there is not better display of
calling party information. 

In addition network operators could insert other 'hints' as to the nature of
the session based on its ability to validate the Caller ID or other forms on
analysis.

I'm well aware of how CNAM is delivered in North America and I'm equally
aware the CNAM business model is broken. 

What I'd like to know is what interest there is in this proposition and are
there parties interested in working on it in advance of say London. 

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, October 30, 2013 5:39 PM
To: Richard Shockey
Cc: [email-masked]
Subject: Re: [cnit] [stir] Application servers - Re: Call Center
Implications

More useful in what way?  Improving the reliability of caller name?  Please
use the cnit list to discuss this.

On that list, the current direction seems to be using the display name part
of the uri to carry a caller name, which is put on the call by the
origination side, and signed as the number is.

That is a significant change to the current infrastructure, which at least
in North America relies on a termination service provider dip in an
origination service provider database, but it seems feasible to consider
that.

Brian

On Oct 30, 2013, at 5:18 PM, Richard Shockey <[email-masked]> wrote:

> 
> Ok since Brian is being picky..
> 
> I'm actually interested if anyone is interested in the possibility of 
> making SIP Identity to the UA more useful.
> 
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Richard Shockey
> Sent: Wednesday, October 30, 2013 3:05 PM
> To: [email-masked]
> Subject: Re: [stir] Application servers - Re: Call Center Implications
> 
> Dan great post. I couldn't agree more.  There needs to be some rules here.
> Some may be regulatory some may be technical.
> 
> First the voice application service providers need to provide the 
> terminating CUA, "an accurate and truthful" Caller-ID for the call 
> even if it is originated from a source that is not directly associated
with the
> business entity for whom the call is being made.   That could be an 800
> number for instance but I won't bore you with the issues with SMS800 
> RESPORGS.
> 
> If the originating UA can prove/assert it is legally authorized to use 
> such an identity on behalf of a customer then that is step one.  The 
> presumption after that is there is some contractual obligation between 
> the service provider and the network about the use of such identities. 
> The network can then "validate" such an assertion.
> 
> There is something larger here to consider.  Though the focus of STIR 
> is validation of a Caller-ID number at some point the RAI area should take
a
> look at the other side of the coin so to speak.   
> 
> CNAM.  That is NOT something STIR can do but I do believe there is an 
> emerging requirement that under some cases the calling party wants to 
> or should provide more substantive information about themselves to the 
> called party and frankly 15 character ASCII is not enough. Consumers 
> or businesses should be able to see more complete and validated 
> information about the session in order to make an better and informed 
> decision on whether to accept the 'call' or not.  Regulators may want 
> to require telemarketing firms to display NG CNAM or CNAM + like data 
> as a condition of doing business.
> 
> All of the examples you cite are excellent examples where such verbose 
> calling party identification could be displayed.  I certainly want to 
> answer a call from my doctor on my test results just as I wish to 
> ignore a call from Bill Clinton begging me to vote in the Virginia 
> Governors election next Tuesday.  This is a case where annominity is not a
good idea.
> 
> 
> All you need now is a little standardization.
> Technically this should is very easy to understand in SIP.  It would 
> probably a reasonable modification of the Call INFO header in SIP with 
> something like a XML based VCARD or JCARD URI whatever and probably 
> 3GPP would need to look at how such data is displayed on the mobile 
> VoLTE handsets. The network operators would have to understand not to 
> modify the contents of such a URI and its source validated but that is 
> a task for another day.
> 
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Dan York
> Sent: Tuesday, October 29, 2013 5:10 PM
> To: Brian Rosen; Cullen Jennings
> Cc: [email-masked]; Richard Shockey; [email-masked]; 
> Fernando Mousinho (fmousinh); Alex Bobotek; Michael Hammer; Henning 
> Schulzrinne
> Subject: [stir] Application servers - Re: Call Center Implications
> 
> Getting caught up on some of the STIR discussions, I'd just note that 
> when we talk about "call centers" or "BPOs" we also need to remember 
> that we're not only talking about "traditional" call centers but also 
> what I'll call "voice application service providers".  They are 
> generally automated platforms running applications that a company uses 
> for some kind of outbound service.  Examples include:
> 
> - calling everyone in a school district with a weather-related 
> cancellation (or, unfortunately, a school shooting or similar event)
> - calling patients to provide reminders of appointments or 
> notifications of subscriptions available
> - calling customers to let them know that a package was delivered or 
> could be picked up, etc.
> - calling people scheduled for a flight to let know they are going to 
> be delayed
> - calling members of an organization with an automated survey about 
> current issues
> - performing a call-back to provide an additional layer of 
> authentication for some service
> 
> There is a large (and growing) market for these kind of automated 
> tools and services and the distinction between these calls and 
> "robocalls" is really only one of intent and the fact that the recipient
has "opted in"
> through some kind of system.
> 
> Generally, though, many of the companies want the application to 
> appear as if it is coming from their own phone number in the same way 
> that they want an outbound call center to appear as if it is coming 
> from one of their own phone numbers.
> 
> You could think of these in the same way as "call centers", but I 
> point this out because some of these new services are very automated 
> and there are always new startups now emerging in this space.  Some of 
> them are very "self-service" where the customer does it all while 
> others have teams of people involved.  Some of the companies involved 
> include Nuance, Microsoft Tellme, Voxeo (now Aspect, and also my 
> former employer), Tropo, Twilio, Convergys and many more[1].
> 
> If STIR is to succeed, these kind of application platforms will also 
> need to be able to make calls on behalf of the companies using those
platforms.
> 
> Dan
> 
> [1] One report about this market:
> http://www.voxeo.com/pdf/OvumDecisionMatrix-2011.pdf
> 
> 
> --
> Dan York
> Senior Content Strategist, Internet Society
> [email-masked] <mailto:[email-masked]>   +1-802-735-1624
> Jabber: [email-masked] <mailto:[email-masked]>
> Skype: danyork   http://twitter.com/danyork
> 
> http://www.internetsociety.org/deploy360/
> 
> 
> 
> 
> On 10/21/13 9:15 AM, "Brian Rosen" <[email-masked]> wrote:
> 
>> We really need to give each BPO different keys I think.   The notion that
>> we are sharing private keys among multiple competing entities who 
>> provide services for a single enterprise strikes me as a VBI (Very 
>> Bad Idea).  I can't see any real difficulty in having more than one 
>> authorized entity, each with it's own credentials.  Who would have a 
>> problem?  We're already agreeing that there are multiple credentials 
>> for a number, because the number gets delegated multiple times.
>> Consider, just as an example, the BPO and the contracting enterprise 
>> that was actually delegated the number can both send calls from that 
>> number.  You certainly don't want the enterprise giving out IT'S key 
>> to it's contractors.  At best it's a key it authorizes to one or more 
>> of it's
> BPOs.
>> 
>> Brian
>> 
>> On Oct 20, 2013, at 1:12 AM, Cullen Jennings (fluffy) 
>> <[email-masked]>
>> wrote:
>> 
>>> 
>>> What Fernando is saying makes sense to me a desirable property of 
>>> the solution and I agree  that if we gave each BPO a different 
>>> private key that would solve it but that might be pretty hard to 
>>> mange in other ways. I like the requirements but the solution is not 
>>> 100% obvious to me.
>>> 
>>> 
>>> On Oct 2, 2013, at 10:27 AM, Brian Rosen <[email-masked]> wrote:
>>> 
>>>> Sure.
>>>> 
>>>> Each BPO would have a different private/public key pair.
>>>> 
>>>> So you can trace which one placed the call.
>>>> 
>>>> Brian
>>>> 
>>>> On Oct 2, 2013, at 12:59 PM, Fernando Mousinho (fmousinh) 
>>>> <[email-masked]> wrote:
>>>> 
>>>>> Point taken on PAI, but am still struggling with this BPO model.
>>>>> Apologies
>>>>> upfront if this is obvious and I'm just failing to understand.
>>>>> 
>>>>> If the company hires several BPOs and authorizes all of them to 
>>>>> sign calls  on its behalf, is there a way to trace back the 
>>>>> originator (specific
>>>>> BPO)
>>>>> later on? I suppose that at some level the actual caller must be 
>>>>> exposed  (perhaps to trace malicious activity, such as malicious 
>>>>> person infiltrated  in an otherwise legitimate BPO).
>>>>> 
>>>>> Via headers would be the obvious pick, but they don't survive the 
>>>>> plethora  of SBCs that the call is likely to transverse. Or maybe 
>>>>> the certs  themselves can carry this type of data (actual caller 
>>>>> identity).
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On 9/19/13 9:43 PM, "Brian Rosen" <[email-masked]> wrote:
>>>>> 
>>>>>> Don't think that would work without related changes in the networks.
>>>>>> In
>>>>>> some networks, PAI is used for called id.  They would have to 
>>>>>> change to  use From (if signed maybe).  It also doesn't fit the 
>>>>>> definition of PAI.
>>>>>> 
>>>>>> Brian
>>>>>> 
>>>>>> On Sep 19, 2013, at 9:14 PM, Fernando Mousinho (fmousinh) 
>>>>>> <[email-masked]> wrote:
>>>>>> 
>>>>>>> Could a signed PAI be a potential solution to the BPO use case?
>>>>>>> "From"
>>>>>>> identifies the BPO, "PAI" the c
>>>>>>> ompany hiring the BPO - based on the delegation process Rosen 
>>>>>>> mentions.
>>>>>>> PAI's use is widespread, and it's main limitation is being 
>>>>>>> spoofable -  but this is exactly the problem we are trying to 
>>>>>>> solve anyway.
>>>>>>> 
>>>>>>> 
>>>>>>>> On Sep 19, 2013, at 5:39 PM, "Richard Shockey" 
>>>>>>>> <[email-masked]>
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>> Excellent point a profile or BCP to complement the work.
>>>>>>>> 
>>>>>>>> -----Original Message-----
>>>>>>>> From: [email-masked] [mailto:[email-masked]] On 
>>>>>>>> Behalf  Of Alex  Bobotek
>>>>>>>> Sent: Thursday, September 19, 2013 5:27 PM
>>>>>>>> To: Henning Schulzrinne; Michael Hammer; [email-masked]; 
>>>>>>>> [email-masked]; [email-masked]
>>>>>>>> Cc: [email-masked]
>>>>>>>> Subject: Re: [stir] Call Center Implications
>>>>>>>> 
>>>>>>>> +1
>>>>>>>> I've assumed that we are headed towards a "sign whatever extras 
>>>>>>>> you wish, and indicate what your signature covers" mechanism.
>>>>>>>> 
>>>>>>>> Based on this, standards would need to identify only a minimal 
>>>>>>>> subset  of  what shall/should be signed, and ensure that any 
>>>>>>>> required group of  signed  items survives transit intact.
>>>>>>>> 
>>>>>>>> Best signing practices may be needed to complement the 
>>>>>>>> standard, and an  appropriate place for all but the most basic 
>>>>>>>> 'what to sign'
>>>>>>>> recommendations.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Regards,
>>>>>>>> 
>>>>>>>> Alex
>>>>>>>> 
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: [email-masked] [mailto:[email-masked]] On 
>>>>>>>>> Behalf  Of Henning Schulzrinne
>>>>>>>>> Sent: Thursday, September 19, 2013 2:24 PM
>>>>>>>>> To: Michael Hammer; [email-masked]; 
>>>>>>>>> [email-masked]; [email-masked]
>>>>>>>>> Cc: [email-masked]
>>>>>>>>> Subject: Re: [stir] Call Center Implications
>>>>>>>>> 
>>>>>>>>> I see no reason not to allow signing any number-related field 
>>>>>>>>> in the  SIP request. (Signing may well be done by different
>>>>>>>>> parties.)
>>>>>>>>> 
>>>>>>>>> As far as I know, callback numbers (SIP Reply-To) aren't 
>>>>>>>>> conveyable  in  legacy systems, however, so this may be of 
>>>>>>>>> somewhat limited use for a
>>>>>>>> while.
>>>>>>>>> 
>>>>>>>>> ________________________________________
>>>>>>>>> From: [email-masked] [[email-masked]] on behalf 
>>>>>>>>> of Michael Hammer [[email-masked]]
>>>>>>>>> Sent: Thursday, September 19, 2013 4:34 PM
>>>>>>>>> To: [email-masked]; [email-masked]; 
>>>>>>>>> [email-masked]
>>>>>>>>> Cc: [email-masked]
>>>>>>>>> Subject: Re: [stir] Call Center Implications
>>>>>>>>> 
>>>>>>>>> Don't we still want to know the true originator of the call, 
>>>>>>>>> even  when  we have some token that says "Doctor so and so 
>>>>>>>>> approved this message."
>>>>>>>>> 
>>>>>>>>> Originating number, display number, and call-back number could 
>>>>>>>>> be
>>>>>>>>> 3
>>>>>>>>> different things.
>>>>>>>>> Should all of them be verifiable?
>>>>>>>>> 
>>>>>>>>> Mike
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: [email-masked] [mailto:[email-masked]] On 
>>>>>>>>> Behalf  Of Fernando Mousinho (fmousinh)
>>>>>>>>> Sent: Thursday, September 19, 2013 4:00 PM
>>>>>>>>> To: Schumacher, Gregory [CTO]; Brian Rosen
>>>>>>>>> Cc: [email-masked]
>>>>>>>>> Subject: Re: [stir] Call Center Implications
>>>>>>>>> 
>>>>>>>>> I believe the scenario telemarketing here is when a client 
>>>>>>>>> hires a  BPO  to place outbound calls, but expect customers to 
>>>>>>>>> return these calls  to  a different place (say, their own and 
>>>>>>>>> operated call center). This  way,  this client is authorizing 
>>>>>>>>> the BPO to use an identity that it
>>>>>>>>> (BPO)
>>>>>>>> doesn't own.
>>>>>>>>> These numbers in this scenario are always operational, just at 
>>>>>>>>> a different place.
>>>>>>>>> 
>>>>>>>>> The same telemarketing operator would then outpulse multiple 
>>>>>>>>> numbers  for their multiple clients, none of these numbers 
>>>>>>>>> belonging to the
>>>>>>>> telemarketer.
>>>>>>>>> BTW, we are using the term "telemarketing" in a very generic 
>>>>>>>>> sense -  this could just as easily be a public service 
>>>>>>>>> announcement,  fundraiser,
>>>>>>>> etc.
>>>>>>>>> 
>>>>>>>>> If the telemarketer happens to own the inbound call center as 
>>>>>>>>> well,  it  very likely owns the number as well and this would 
>>>>>>>>> necessarily be a  special case
>>>>>>>>> - it would fall under the same characteristics of any call center.
>>>>>>>>> 
>>>>>>>>> On a different note, it would help a lot of we standardized 
>>>>>>>>> terminology.
>>>>>>>>> Telemarketing, BPO, call center, end customer, clientsŠ it may 
>>>>>>>>> be hard for others to follow the discussion later.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> (generic term for any type of outbound calling, including 
>>>>>>>>> public service announcement, so don't think it's all about
>>>>>>>>> sales!)
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On 9/19/13 3:22 PM, "Schumacher, Gregory [CTO]"
>>>>>>>>> <[email-masked]> wrote:
>>>>>>>>> 
>>>>>>>>>> There are some benefits from this approach, but also some 
>>>>>>>>>> scenarios  that need clarification how they could function.
>>>>>>>>>> 
>>>>>>>>>> The benefit is that the credential represents both the 
>>>>>>>>>> company "responsible" for the sales campaign (the "company" 
>>>>>>>>>> in your
>>>>>>>>>> scenario)
>>>>>>>>>> and the company operating the sales campaign (the call center 
>>>>>>>>>> in  your  scenario).  For the use in forensics (after the 
>>>>>>>>>> fact
>>>>>>>>>> analysis) such  as pursuit of fraud investigation, we then 
>>>>>>>>>> can follow both paths.
>>>>>>>>>> 
>>>>>>>>>> However can you clarify the following -
>>>>>>>>>> - If a SP "signs" the call, is it attesting to the "responsible"
>>>>>>>>>> party for the telemarketing call or the party executing the 
>>>>>>>>>> telemarketing campaign  or both?
>>>>>>>>>> 
>>>>>>>>>> - How is the SP supposed to know all the parties that it is 
>>>>>>>>>> attesting to
>>>>>>>>>> - the responsible party and/or executing party?
>>>>>>>>>> 
>>>>>>>>>> -It seems likely that some of the numbers assigned to a 
>>>>>>>>>> company in  your scenario will not be assigned to real 
>>>>>>>>>> telephones (or call  center
>>>>>>>>>> trunk) until a telemarketing campaign is initiated or a call 
>>>>>>>>>> center  selected to execute the sales campaign, is it 
>>>>>>>>>> possible to have these  unassigned or floating numbers when 
>>>>>>>>>> not in use for a telemarketing  campaign?  Is it allowed 
>>>>>>>>>> under most national numbering regimes?
>>>>>>>>>> 
>>>>>>>>>> - How important is it to have a known or recognized phone 
>>>>>>>>>> number as  the caller id as part of a telemarketing campaign?
>>>>>>>>>> I am assuming  that not all campaigns care about having a 
>>>>>>>>>> number that is known or
>>>>>>>> recognized.
>>>>>>>>>> 
>>>>>>>>>> -In other words for this last bit, if a call center 
>>>>>>>>>> (telemarketing  campaign operator) is using their own set of 
>>>>>>>>>> numbers but serve  multiple simultaneous telemarketing 
>>>>>>>>>> campaigns using the same  originating numbers, what will they 
>>>>>>>>>> sign?  Will they just have a  credential representing the 
>>>>>>>>>> call center alone, or a different  credential per 
>>>>>>>>>> telemarketing campaign, or a different credential per  
>>>>>>>>>> responsible party (per client)?  This will affect what is 
>>>>>>>>>> possible  for
>>>>>>>> any forensic activity.
>>>>>>>>>> 
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: [email-masked] [mailto:[email-masked]] On 
>>>>>>>>>> Behalf  Of Brian Rosen
>>>>>>>>>> Sent: Tuesday, September 17, 2013 9:44 AM
>>>>>>>>>> To: Fernando Mousinho
>>>>>>>>>> Cc: [email-masked]; Hadriel Kaplan
>>>>>>>>>> Subject: Re: [stir] Call Center Implications
>>>>>>>>>> 
>>>>>>>>>> We have a requirement to support the BPO use case.
>>>>>>>>>> 
>>>>>>>>>> The notion we had is that the company contracting the call 
>>>>>>>>>> center  approves the use, and the call center, or the SP 
>>>>>>>>>> acting on its  behalf, signs.
>>>>>>>>>> Think of this as another level of delegation.  An SP 
>>>>>>>>>> delegates numbers to the company.  The company "delegates" 
>>>>>>>>>> use of those numbers  to the call center.  The call center 
>>>>>>>>>> calls, using that delegation.
>>>>>>>>>> The credentials of the call center would be different from 
>>>>>>>>>> those of  the company, but would cover the same number.  
>>>>>>>>>> Having multiple  credentials covering the same number will be 
>>>>>>>>>> very common due to the  way delegation happens.  In order to 
>>>>>>>>>> allow SPs to sign, without  creating credential per TN, we 
>>>>>>>>>> allow credentials with ranges.
>>>>>>>>>> The
>>>>>>>>>> ranges could overlap when delegation happens.
>>>>>>>>>> 
>>>>>>>>>> Consider the following complex US case:
>>>>>>>>>> The North American Number Plan Administrator delegates 
>>>>>>>>>> 202-555-xxxx  to the Pooling Administrator.  The PA now has a 
>>>>>>>>>> credential covering  the entire 10K block.
>>>>>>>>>> The Pooling Administrator delegates 202-555-1xxx to SP A.  SP 
>>>>>>>>>> A has  a  credential for the entire 1K block SP A resells 
>>>>>>>>>> 202-555-12xx to SP B  .
>>>>>>>>>> SP B has a credential for a 100 TN block SP B delegates 
>>>>>>>>>> 202-555-123x  to Company C.  Company C has a credential for a
>>>>>>>>>> 10 number block  Company C authorizes 202-555-1234 to BPO D.  
>>>>>>>>>> BPO D has credential  for  a 1 number block
>>>>>>>>>> 
>>>>>>>>>> NANPA and the PA never are in a call path, so they would 
>>>>>>>>>> never sign  a  call.
>>>>>>>>>> 
>>>>>>>>>> However, SP A or SP B could sign a call from either Company C 
>>>>>>>>>> or BPO  D using the credential they have.
>>>>>>>>>> 
>>>>>>>>>> The SP for the call center could acquire credentials from the 
>>>>>>>>>> BPO  and  sign on its behalf.  I suspect than many service 
>>>>>>>>>> providers would be  reluctant to do so unless the numbers 
>>>>>>>>>> were from their own inventory  (that is, the company got its 
>>>>>>>>>> numbers from the same SP as the call
>>>>>>>> center).
>>>>>>>>>> Since that won't be the common case, the call center probably 
>>>>>>>>>> has to  do the signing itself.
>>>>>>>>>> 
>>>>>>>>>> Brian
>>>>>>>>>> 
>>>>>>>>>> On Sep 17, 2013, at 8:46 AM, Fernando Mousinho (fmousinh) 
>>>>>>>>>> <[email-masked]> wrote:
>>>>>>>>>> 
>>>>>>>>>>> I agree, Hadriel. While large call centers (including BPOs, 
>>>>>>>>>>> which  provide services for other companies) may have 
>>>>>>>>>>> special arrangements  with SPs, the majority (small to 
>>>>>>>>>>> mid-size) will probably rely on  the SPs to do provide to 
>>>>>>>>>>> vouch for their identity. This would  probably be the case 
>>>>>>>>>>> for the home analog caller anyway. This would  imply that 
>>>>>>>>>>> the "originating" SP's willingness to provide this  
>>>>>>>>>>> signature is a critical success factor for the proposal's
adoption.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> But back to the business process outsourcers (BPO) case - 
>>>>>>>>>>> where a  call center is providing service on behalf of 
>>>>>>>>>>> multiple companies. I  can see the value of them sending 
>>>>>>>>>>> different numbers based on the  clients they represent.
>>>>>>>>>>> Wouldn't that create a billing issue though?
>>>>>>>>>>> This is not an area I understand well, but I would suspect 
>>>>>>>>>>> that SP
>>>>>>>>>>> 1 allowing one of its subscribers to send an outbound call 
>>>>>>>>>>> using a  number registered to SP 2 could be a no-no. If this 
>>>>>>>>>>> hypothesis is  correct, then we are back to the case where 
>>>>>>>>>>> the SP is signing all  calls,
>>>>>>>>> even for BPOs.
>>>>>>>>>>> 
>>>>>>>>>>> Or maybe this is another problem we are trying to fix in the 
>>>>>>>>>>> working group, in which case we perhaps should state as a 
>>>>>>>>>>> goal or
>>>>>>>> benefit:
>>>>>>>>>>> "providing a reliable mechanism to let calls originated from 
>>>>>>>>>>> one
>>>>>>>>>>> SP1 to outpulse numbers that belong to another".
>>>>>>>>>>> 
>>>>>>>>>>> Fernando
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On 9/16/13 12:12 PM, "Hadriel Kaplan"
>>>>>>>>>>> <[email-masked]>
>>>>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Any of them could do it.  My guess is service providers 
>>>>>>>>>>>> will do it  for most call centers, although larger call 
>>>>>>>>>>>> centers might do it  themselves...
>>>>>>>>>>>> especially ones which have trunks from multiple providers 
>>>>>>>>>>>> and can  source calls using the same number(s) out through 
>>>>>>>>>>>> multiple  providers on a call-by-call basis.
>>>>>>>>>>>> 
>>>>>>>>>>>> -hadriel
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> On Sep 16, 2013, at 9:49 AM, Fernando Mousinho (fmousinh) 
>>>>>>>>>>>> <[email-masked]> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> I'm catching up with the discussions in this working 
>>>>>>>>>>>>> group, and  am trying to understand some architecture 
>>>>>>>>>>>>> implications in call  centers (which is where my 
>>>>>>>>>>>>> background is). It seems that many of  the problems we are 
>>>>>>>>>>>>> trying to fix are related to contact centers  anyway, so 
>>>>>>>>>>>>> it is probably a good idea to have everyone in the  same
>>>>>>>>> page.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Forgive me if it is an obvious question, but which 
>>>>>>>>>>>>> components in  a "typical call center architecture" do you 
>>>>>>>>>>>>> see signature and  verification taking place? Such "typical"
>>>>>>>>>>>>> deployments have  premises based equipment (PME), a 
>>>>>>>>>>>>> session border controller
>>>>>>>>>>>>> (SBC)
>>>>>>>>>>>>> and of course a SIP service provider  all three could 
>>>>>>>>>>>>> potentially  be used throughout the authorization process.
>>>>>>>>>>>>> There are different  ramifications depending on where your 
>>>>>>>>>>>>> mind is at.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Fernando Mousinho
>>>>>>>>>>>>> Cisco Systems
>>>>>>>>>>> 
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> stir mailing list
>>>>>>>>>>> [email-masked]
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir
>>>>>>>>>> 
>>>>>>>>>> _______________________________________________
>>>>>>>>>> stir mailing list
>>>>>>>>>> [email-masked]
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> ________________________________
>>>>>>>>>> 
>>>>>>>>>> This e-mail may contain Sprint proprietary information 
>>>>>>>>>> intended for  the sole use of the recipient(s). Any use by 
>>>>>>>>>> others is prohibited.
>>>>>>>>>> If
>>>>>>>>>> you are not the intended recipient, please contact the sender 
>>>>>>>>>> and  delete all copies of the message.
>>>>>>>>>> 
>>>>>>>>>> _______________________________________________
>>>>>>>>>> stir mailing list
>>>>>>>>>> [email-masked]
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir
>>>>>>>>> 
>>>>>>>>> _______________________________________________
>>>>>>>>> stir mailing list
>>>>>>>>> [email-masked]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir
>>>>>>>>> _______________________________________________
>>>>>>>>> stir mailing list
>>>>>>>>> [email-masked]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir
>>>>>>>> _______________________________________________
>>>>>>>> stir mailing list
>>>>>>>> [email-masked]
>>>>>>>> https://www.ietf.org/mailman/listinfo/stir
>>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>> _______________________________________________
>>>> stir mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/stir
>>> 
>> 
>> _______________________________________________
>> stir mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/stir
> 
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir
> 
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir
> 
> _______________________________________________
> cnit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cnit

---

From: Brian Rosen <[email-masked]>
Date: Thu, 31 Oct 2013 13:19:29 -0400

I think the issue is whether we think what is usually called “contact” information is reasonable to send on every call.

I do think if we were to do anything like that, we would do it with xCard and Call-Info, so mechanism is something I agree with you on.

If we did use display name for caller name, we get the SIP version of that, which fixes the 15 US-ASCII character problem of the name.

If we were to go farther, I’d probably want a request, rather than automatic sending.

I am very interested in working on improving caller name.

Brian

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 31 Oct 2013 17:37:03 +0000

Call-info: ;purpose=card or purpose=info

would seem to address part of that need. Obviously, there has to be a cryptographic binding to the calling number, but this could be relatively simple if the vCard/xCard is signed with the same key as the TN.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Thursday, October 31, 2013 1:19 PM
To: Richard Shockey
Cc: [email-masked]; DISPATCH
Subject: Re: [dispatch] [cnit] [stir] Application servers - Re: Call Center Implications

I think the issue is whether we think what is usually called "contact" information is reasonable to send on every call.

If we were to go farther, I'd probably want a request, rather than automatic sending.

Brian

On Oct 31, 2013, at 8:49 AM, Richard Shockey <[email-masked]> wrote:

> The issue is can we use the tools at hand to increase both the 
> accuracy, reliability and the amount of data that is delivered to the 
> CUA over who is attempting to establish a session.
> 
> The larger issue is the integrity of the entire real time 
> communications system as it moves to an all IP world.  Irrespective if 
> CNAM it is delivered as part of From: or PAI its not very useful to the consumer.
> 
> CNAM as it is currently defined in SS7 is a terrible service.  15 
> Character ASCII.  No support for International character sets the usual.
> 
> richer set of data displayed on their UA's and that can be delivered 
> by the SIP headers in some relatively simple form. Modification of the 
> Call-Info header for instance. It is equally not a stretch to think 
> that National Regulators would be delighted with consumers having a 
> richer set of information displayed on their handsets in order to make 
> more decisions.  In addition if we can achieve better all IP to IP 
> interconnection among providers it would be really really useful if 
> Enterprise systems could extract more data from their internal 
> directory systems  and pass that along in the new format for enterprise calling as well.
> 
> I would certainly argue that we are not going to see ubiquitous Point 
> to Point video calling using WebRTC or SIP if there is not better 
> display of calling party information.
> 
> In addition network operators could insert other 'hints' as to the 
> nature of the session based on its ability to validate the Caller ID 
> or other forms on analysis.
> 
> I'm well aware of how CNAM is delivered in North America and I'm 
> equally aware the CNAM business model is broken.
> 
> What I'd like to know is what interest there is in this proposition 
> and are there parties interested in working on it in advance of say London.
> 
> More useful in what way?  Improving the reliability of caller name?  
> Please use the cnit list to discuss this.
> 
> On that list, the current direction seems to be using the display name 
> part of the uri to carry a caller name, which is put on the call by 
> the origination side, and signed as the number is.
> 
> That is a significant change to the current infrastructure, which at 
> least in North America relies on a termination service provider dip in 
> an origination service provider database, but it seems feasible to 
> consider that.
> 
> Brian
> 
>> If the originating UA can prove/assert it is legally authorized to 
>> use such an identity on behalf of a customer then that is step one.  
>> The presumption after that is there is some contractual obligation 
>> between the service provider and the network about the use of such identities.
>> or should provide more substantive information about themselves to 
>> the called party and frankly 15 character ASCII is not enough. 
>> Consumers or businesses should be able to see more complete and 
>> validated information about the session in order to make an better 
>> and informed decision on whether to accept the 'call' or not.  
>> Regulators may want to require telemarketing firms to display NG CNAM 
>> or CNAM + like data as a condition of doing business.
>> 
>> All of the examples you cite are excellent examples where such 
>> verbose calling party identification could be displayed.  I certainly 
>> want to answer a call from my doctor on my test results just as I 
>> wish to ignore a call from Bill Clinton begging me to vote in the 
>> Virginia Governors election next Tuesday.  This is a case where 
>> annominity is not a
> good idea.
>> 
>> 
>> probably a reasonable modification of the Call INFO header in SIP 
>> with something like a XML based VCARD or JCARD URI whatever and 
>> probably 3GPP would need to look at how such data is displayed on the 
>> mobile VoLTE handsets. The network operators would have to understand 
>> not to modify the contents of such a URI and its source validated but 
>> that is a task for another day.
>> 
>> 
>> 
>> generally automated platforms running applications that a company 
>> uses for some kind of outbound service.  Examples include:
>> 
>> and there are always new startups now emerging in this space.  Some 
>> of them are very "self-service" where the customer does it all while 
>>> to it's contractors.  At best it's a key it authorizes to one or 
>>> more of it's
>> BPOs.
>>> 
>>> Brian
>>> 
>>>> mange in other ways. I like the requirements but the solution is 
>>>> not 100% obvious to me.
>>>> 
>>>> 
>>>>>>>> identifies the BPO, "PAI" the c ompany hiring the BPO - based 
>>>>>>>> on the delegation process Rosen mentions.
>>>>>>>>> I've assumed that we are headed towards a "sign whatever 
>>>>>>>>> extras you wish, and indicate what your signature covers" mechanism.
>>>>>>>>> 
>>>>>>>>>> Originating number, display number, and call-back number 
>>>>>>>>>> could be
>>>>>>>>>> 3
>>>>>>>>>> different things.
>>>>>>>>>> hires a  BPO  to place outbound calls, but expect customers 
>>>>>>>>>> to return these calls  to  a different place (say, their own 
>>>>>>>>>> and operated call center). This  way,  this client is 
>>>>>>>>>> authorizing the BPO to use an identity that it
>>>>>>>>>> (BPO)
>>>>>>>>> doesn't own.
>>>>>>>>>> These numbers in this scenario are always operational, just 
>>>>>>>>>> at a different place.
>>>>>>>>>> 
>>>>>>>>>> Telemarketing, BPO, call center, end customer, clientsŠ it 
>>>>>>>>>> may be hard for others to follow the discussion later.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> and the company operating the sales campaign (the call 
>>>>>>>>>>> center in  your  scenario).  For the use in forensics (after 
>>>>>>>>>>> the fact
>>>>>>>>>>> campaigns using the same  originating numbers, what will 
>>>>>>>>>>> they sign?  Will they just have a  credential representing 
>>>>>>>>>>> the call center alone, or a different  credential per 
>>>>>>>>>>> From: [email-masked] [mailto:[email-masked]] 
>>>>>>>>>>> On Behalf  Of Brian Rosen
>>>>>>>>>>> Having multiple  credentials covering the same number will 
>>>>>>>>>>> be very common due to the  way delegation happens.  In order 
>>>>>>>>>>> to allow SPs to sign, without  creating credential per TN, 
>>>>>>>>>>> we allow credentials with ranges.
>>>>>>>>>>> The
>>>>>>>>>>> 202-555-xxxx  to the Pooling Administrator.  The PA now has 
>>>>>>>>>>> a credential covering  the entire 10K block.
>>>>>>>>>>> The Pooling Administrator delegates 202-555-1xxx to SP A.  
>>>>>>>>>>> SP A has  a  credential for the entire 1K block SP A resells 
>>>>>>>>>>> 202-555-12xx to SP B  .
>>>>>>>>>>> However, SP A or SP B could sign a call from either Company 
>>>>>>>>>>> C or BPO  D using the credential they have.
>>>>>>>>>>> 
>>>>>>>>>>> The SP for the call center could acquire credentials from 
>>>>>>>>>>> the BPO  and  sign on its behalf.  I suspect than many 
>>>>>>>>>>> service providers would be  reluctant to do so unless the 
>>>>>>>>>>> numbers were from their own inventory  (that is, the company 
>>>>>>>>>>> got its numbers from the same SP as the call
>>>>>>>>> center).
>>>>>>>>>>> Since that won't be the common case, the call center 
>>>>>>>>>>> probably has to  do the signing itself.
>>>>>>>>>>> 
>>>>>>>>>>> Brian
>>>>>>>>>>> 
>>>>>>>>>>>> using a  number registered to SP 2 could be a no-no. If 
>>>>>>>>>>>> this hypothesis is  correct, then we are back to the case 
>>>>>>>>>>>> where the SP is signing all  calls,
>>>>>>>>>> even for BPOs.
>>>>>>>>>>>> 
>>>>>>>>>>>> Or maybe this is another problem we are trying to fix in 
>>>>>>>>>>>> the working group, in which case we perhaps should state as 
>>>>>>>>>>>> a goal or
>>>>>>>>> benefit:
>>>>>>>>>>>> "providing a reliable mechanism to let calls originated 
>>>>>>>>>>>> from one
>>>>>>>>>>>>>> background is). It seems that many of  the problems we 
>>>>>>>>>>>>>> are trying to fix are related to contact centers  anyway, 
>>>>>>>>>>>>>> so it is probably a good idea to have everyone in the  
>>>>>>>>>>>>>> same
>>>>>>>>>> page.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> components in  a "typical call center architecture" do 
>>>>>>>>>>>>>> you see signature and  verification taking place? Such "typical"
>>>>>>>>>>>>>> There are different  ramifications depending on where 
>>>>>>>>>>>>>> your mind is at.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Fernando Mousinho
>>>>>>>>>>>>>> Cisco Systems
>>>>>>>>>>>> 
>>>>>>>>>>> you are not the intended recipient, please contact the 
>>>>>>>>>>> sender and  delete all copies of the message.
>>>>>>>>>>> 

_______________________________________________
dispatch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dispatch

---

From: Michael Hammer <[email-masked]>
Date: Thu, 31 Oct 2013 18:11:27 +0000

It might also be nice to have an options indication, so we can tell the
other side that we are not just a limited rotary dial phone.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Henning Schulzrinne
Sent: Thursday, October 31, 2013 1:37 PM
To: 'Brian Rosen'; Richard Shockey
Cc: [email-masked]; DISPATCH
Subject: Re: [dispatch] [cnit] [stir] Application servers - Re: Call Center
Implications

would seem to address part of that need. Obviously, there has to be a
cryptographic binding to the calling number, but this could be relatively
simple if the vCard/xCard is signed with the same key as the TN.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Brian Rosen
Sent: Thursday, October 31, 2013 1:19 PM
To: Richard Shockey
Cc: [email-masked]; DISPATCH
Subject: Re: [dispatch] [cnit] [stir] Application servers - Re: Call Center
Implications

I think the issue is whether we think what is usually called "contact"
information is reasonable to send on every call.

I do think if we were to do anything like that, we would do it with xCard
and Call-Info, so mechanism is something I agree with you on.

If we did use display name for caller name, we get the SIP version of that,
which fixes the 15 US-ASCII character problem of the name.

If we were to go farther, I'd probably want a request, rather than automatic
sending.

Brian

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 31 Oct 2013 17:33:07 -0400

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Thursday, October 31, 2013 1:19 PM
To: Richard Shockey
Cc: [email-masked]; DISPATCH
Subject: Re: [cnit] [stir] Application servers - Re: Call Center
Implications

[RS> ] Exactly we have a big tool box and the tools are there.  The larger
point I was trying to make is as we look at the larger Caller ID Spoofing
security area one of the thinks Henning and others have pointed out is we
are actually trying to preserve the integrity of the whole system and giving
consumers something that is actually better is a useful thing to do. 

[RS> ]  You could transmit both but if CNAM + were available then use that.
Plus any other helpful information such as red flashing text... "WARNING
WARNING POLITICAL CALL POLITICAL CALL ANSWER AT YOUR PERIL"  That is a
service I could pay real money for. 

If we were to go farther, I'd probably want a request, rather than automatic
sending.
[
[RS> ]  Why does it not surprise me you would say that.  That said actually
SS7 did allow for either model in CNAM.  PUSH or PULL.  It was implemented
in Canadian Tandem Access platforms but Canadian Carriers like US carriers
choose the dip model into LIDB.  In any event it makes no difference. That
is properly an interconnection negotiation between service providers or some
general technical policy that a PBX hosted assertion is not tampered with
during transit.  I do believe the current business model is broken, however
we don't need to nor should debate that. I also believe it is potentially a
good business and essential in making things like P2P video communications
more palatable for enterprises and consumers to use. 

[RS> ]  So I'm not completely insane?  :-)  Ok then it seams the
conversation is worth having and there is productive work here .. See you in
London.  

Brian

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 31 Oct 2013 17:36:04 -0400

Could you explain what you mean here? I'm modestly confused.  Options
indicator for what .. what the other side is capable of?  

Now you really are in a favorite subject of mine.  Before the INVITE "dip"
for capability as well as terminating carrier SBC etc.   Welcome to the new
world of numbering databases. 

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]] 
Sent: Thursday, October 31, 2013 2:11 PM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [dispatch] [cnit] [stir] Application servers - Re: Call Center
Implications

Mike

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

Brian

---

From: Michael Hammer <[email-masked]>
Date: Thu, 31 Oct 2013 21:44:40 +0000

What you sign and send may depend on what the receiver is capable of
displaying.
What triggered the  thought was a restriction to 15 characters, when todays
phones can display a whole lot more.
I am just saying don't let obsolete technology hobble future technology.
Was wondering what might be possible with VoLTE, for example.

Mike

-----Original Message-----
From: Richard Shockey [mailto:[email-masked]] 
Sent: Thursday, October 31, 2013 5:36 PM
To: Michael Hammer; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [dispatch] [cnit] [stir] Application servers - Re: Call Center
Implications

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: Thursday, October 31, 2013 2:11 PM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [dispatch] [cnit] [stir] Application servers - Re: Call Center
Implications

Mike

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

Brian

On Oct 31, 2013, at 8:49 AM, Richard Shockey <[email-masked]> wrote:

> CNAM it is delivered as part of From: or PAI its not very useful to 
> the
consumer.
> directory systems  and pass that along in the new format for 
> enterprise
calling as well.

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 31 Oct 2013 17:33:42 -0400

+1

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Thursday, October 31, 2013 1:37 PM
To: 'Brian Rosen'; Richard Shockey
Cc: [email-masked]; DISPATCH
Subject: RE: [dispatch] [cnit] [stir] Application servers - Re: Call Center
Implications

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

Brian

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 31 Oct 2013 18:11:51 -0400

Excellent question!    No need to send or dip for data if the UA can't
display it.  But then the last hop proxy presumably knows something about
its endpoints. I just don't know. 

What can IMS do here does anyone know?  

I would suspect that our friends at Google/Android and Apple etal are also
in favor of anything that could "Enhance the User Experience" 

Not to mention Cable. You know you have that big 60 inch phone in your
living room ...  :-)   

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]] 
Sent: Thursday, October 31, 2013 5:45 PM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [dispatch] [cnit] [stir] Application servers - Re: Call Center
Implications

Mike

-----Original Message-----
From: Richard Shockey [mailto:[email-masked]] 
Sent: Thursday, October 31, 2013 5:36 PM
To: Michael Hammer; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [dispatch] [cnit] [stir] Application servers - Re: Call Center
Implications

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: Thursday, October 31, 2013 2:11 PM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [dispatch] [cnit] [stir] Application servers - Re: Call Center
Implications

Mike

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

Brian

consumer.
calling as well.