Subject: Re: [stir] Call Center Implications

From: "Fernando Mousinho (fmousinh)" <[email-masked]>
Date: Wed, 2 Oct 2013 16:59:04 +0000

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

---

From: Brian Rosen <[email-masked]>
Date: Wed, 2 Oct 2013 13:27:14 -0400

Sure.

Each BPO would have a different private/public key pair.

So you can trace which one placed the call.

Brian

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Sun, 20 Oct 2013 05:12:03 +0000

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.

---

From: Brian Rosen <[email-masked]>
Date: Mon, 21 Oct 2013 09:15:46 -0400

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

---

From: Dan York <[email-masked]>
Date: Tue, 29 Oct 2013 21:09:58 +0000

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 29 Oct 2013 21:59:32 +0000

One model is something like OAuth, where the holder of the number (i.e., the customer of the BPO or voice ASP) allows them to retrieve a key pair for a number. A simpler version is that the number holder gets an app key, similar to what Google does, and hands this to the VASP. That key can then be used to submit the certificate signing request, e.g., via HTTPS with basic authentication.

My understanding is, however, that outfits like Twilio often provide those numbers since most users don't really have good ways of getting their own and many of these services handle inbound calls, not just outbound. But we clearly need to support the "borrowed" number model.

-----Original Message-----
From: Dan York [mailto:[email-masked]] 
Sent: Tuesday, October 29, 2013 5:10 PM
To: Brian Rosen; Cullen Jennings
Cc: [email-masked]; Richard Shockey; Henning Schulzrinne; [email-masked]; Alex Bobotek; Michael Hammer; Fernando Mousinho (fmousinh)
Subject: Application servers - Re: [stir] 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

On 10/21/13 9:15 AM, "Brian Rosen" <[email-masked]> wrote:

>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:
>
>> 
>>>> 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).
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> 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
>>>>> 
>>>>>> 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.
>>>>>> 
>>>>>> 
>>>>>>> From: [email-masked] [mailto:[email-masked]] On 
>>>>>>>Behalf  Of Alex  Bobotek
>>>>>>> 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
>>>>>>> 
>>>>>>>> From: [email-masked] [mailto:[email-masked]] On 
>>>>>>>>Behalf  Of Henning Schulzrinne
>>>>>>>> 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]]
>>>>>>>> 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.
>>>>>>>> From: [email-masked] [mailto:[email-masked]] On 
>>>>>>>>Behalf  Of Fernando Mousinho (fmousinh)
>>>>>>>> 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
>>>>>>>> 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!)
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> There are some benefits from this approach, but also some 
>>>>>>>>>scenarios  that need clarification how they could function.
>>>>>>>>> 
>>>>>>>>> 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.
>>>>>>>>> 
>>>>>>>>> attesting to
>>>>>>>>> -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.
>>>>>>>>> 
>>>>>>>>> From: [email-masked] [mailto:[email-masked]] On 
>>>>>>>>>Behalf  Of Brian Rosen
>>>>>>>>> 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.
>>>>>>>>>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
>>>>>>>>> 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
>>>>>>>>> 
>>>>>>>>>> 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?
>>>>>>>>>> 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.
>>>>>>>>>> 
>>>>>>>>>>> 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
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>> 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
>>>>>>>>>> 
>>>>>>>>> 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.
>>>>>>>>>

---

From: Brian Rosen <[email-masked]>
Date: Wed, 30 Oct 2013 09:22:48 -0400

I look at these authorized uses as just another delegation.

When you delegate, you don’t lose the ability to sign for that number.  For example, if a service provider delegates a number to an end user, the end user device or the service provider can sign.  In these cases, the end device, its delegates, or the service provider can sign.  I think once you get authorization to sign, you have a credential (to use for signing).  That credential can also be used to authorize further delegation.  I’d make that “can”, to allow the possibility that a service provider have a single, or small number of, credentials that it uses to authorize delegations that are independent of the signing keys.  Using it means that the database doesn’t need to have some identity for delegates other than their signing keys.  It could have some other credential, but the simple solution is “if you are authorized to place a call and sign for that TN, then you are authorized to delegate signing authority to anyone you trust”.  I suppose the service provider could decide to limit that ability if it wanted to.

That makes the mechanism simpler - we’re not special-casing the authorized additional user case. 

I certainly don’t like any notion of sharing private keys.

Brian

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 30 Oct 2013 15:05:06 -0400

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.

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

---

From: Brian Rosen <[email-masked]>
Date: Wed, 30 Oct 2013 15:21:03 -0400

We have a separate list for caller name (cnit).

I don’t see any difference between these authorized users of a TN and a BPO.  The customer can get a credential authorized by the service provider who delegated the TN to him.  The customer can then “delegate” the BPO or the mass calling service provider to use that number on its behalf.  There is no difference from our point of view why the authorized entity is placing the call, what kind of service it offers, or how many calls it places.  If it’s authorized by the subscriber to use the TN, then the contractor can use the TN and sign for it.

Brian

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 30 Oct 2013 13:42:25 -0400

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

Dan

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 30 Oct 2013 14:32:25 -0400

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

Dan