From richard@shockey.us Wed Oct 30 14:18:52 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41DAF11E8244 for ; Wed, 30 Oct 2013 14:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.348 X-Spam-Level: X-Spam-Status: No, score=-102.348 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jzcM85HEMBWk for ; Wed, 30 Oct 2013 14:18:48 -0700 (PDT) Received: from oproxy7-pub.mail.unifiedlayer.com (oproxy7-pub.mail.unifiedlayer.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id D891211E813A for ; Wed, 30 Oct 2013 14:18:47 -0700 (PDT) Received: (qmail 8331 invoked by uid 0); 30 Oct 2013 21:18:22 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy7.mail.unifiedlayer.com with SMTP; 30 Oct 2013 21:18:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=PxD/Vn4hP5B+fBwsyTxYWHsi56ojNwMS3bsqXnRnWHY=; b=ePTW11I/O8Jxd3kw2AxuQGB81k410exMFDc2ZXMMZnqkQGFmPXapv049P5OxbRSqZuYGJD6x+w83N6Xp+vAaZjZjKnzS2e1xyywgb134DnO2BdwFU5gbkkrOHpNg7pac; Received: from [173.79.179.104] (port=55571 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Vbd9h-0000jl-Hz for cnit@ietf.org; Wed, 30 Oct 2013 15:18:21 -0600 From: "Richard Shockey" To: References: <32C55AFE-FA17-4776-AD91-259AD3E226BE@brianrosen.net> <024001ced5a2$f3268810$d9739830$@shockey.us> In-Reply-To: <024001ced5a2$f3268810$d9739830$@shockey.us> Date: Wed, 30 Oct 2013 17:18:20 -0400 Message-ID: <029501ced5b5$8fa9f480$aefddd80$@shockey.us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQLTdCvgrcMvmbDsv2xAt2r4G5TZbQLC46EgAqz016eX2QNxsA== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.79.179.104 authed with richard@shockey.us} Subject: [cnit] FW: [stir] Application servers - Re: Call Center Implications X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 21:18:52 -0000 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: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Wednesday, October 30, 2013 3:05 PM To: stir@ietf.org 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.=20 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. =20 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.=20 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.=20 -----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of = Dan York Sent: Tuesday, October 29, 2013 5:10 PM To: Brian Rosen; Cullen Jennings Cc: Gregory.Schumacher@sprint.com; Richard Shockey; stir@ietf.org; = 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 york@isoc.org +1-802-735-1624 Jabber: york@jabber.isoc.org Skype: danyork http://twitter.com/danyork http://www.internetsociety.org/deploy360/ On 10/21/13 9:15 AM, "Brian Rosen" 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=20 >provide services for a single enterprise strikes me as a VBI (Very Bad=20 >Idea). I can't see any real difficulty in having more than one=20 >authorized entity, each with it's own credentials. Who would have a=20 >problem? We're already agreeing that there are multiple credentials=20 >for a number, because the number gets delegated multiple times. >Consider, just as an example, the BPO and the contracting enterprise=20 >that was actually delegated the number can both send calls from that=20 >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=20 >it's BPOs. > >Brian > >On Oct 20, 2013, at 1:12 AM, Cullen Jennings (fluffy)=20 > >wrote: > >>=20 >> 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=20 >>ways. I like the requirements but the solution is not 100% obvious to=20 >>me. >>=20 >>=20 >> On Oct 2, 2013, at 10:27 AM, Brian Rosen wrote: >>=20 >>> Sure. >>>=20 >>> Each BPO would have a different private/public key pair. >>>=20 >>> So you can trace which one placed the call. >>>=20 >>> Brian >>>=20 >>> On Oct 2, 2013, at 12:59 PM, Fernando Mousinho (fmousinh)=20 >>> wrote: >>>=20 >>>> 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. >>>>=20 >>>> If the company hires several BPOs and authorizes all of them to=20 >>>>sign calls on its behalf, is there a way to trace back the=20 >>>>originator (specific >>>>BPO) >>>> later on? I suppose that at some level the actual caller must be=20 >>>>exposed (perhaps to trace malicious activity, such as malicious=20 >>>>person infiltrated in an otherwise legitimate BPO). >>>>=20 >>>> Via headers would be the obvious pick, but they don't survive the=20 >>>>plethora of SBCs that the call is likely to transverse. Or maybe=20 >>>>the certs themselves can carry this type of data (actual caller=20 >>>>identity). >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On 9/19/13 9:43 PM, "Brian Rosen" wrote: >>>>=20 >>>>> 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=20 >>>>>change to use From (if signed maybe). It also doesn't fit the=20 >>>>>definition of PAI. >>>>>=20 >>>>> Brian >>>>>=20 >>>>> On Sep 19, 2013, at 9:14 PM, Fernando Mousinho (fmousinh)=20 >>>>> wrote: >>>>>=20 >>>>>> 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=20 >>>>>>mentions. >>>>>> PAI's use is widespread, and it's main limitation is being=20 >>>>>>spoofable - but this is exactly the problem we are trying to=20 >>>>>>solve anyway. >>>>>>=20 >>>>>>=20 >>>>>>> On Sep 19, 2013, at 5:39 PM, "Richard Shockey"=20 >>>>>>> >>>>>>> wrote: >>>>>>>=20 >>>>>>> Excellent point a profile or BCP to complement the work. >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On=20 >>>>>>>Behalf Of Alex Bobotek >>>>>>> Sent: Thursday, September 19, 2013 5:27 PM >>>>>>> To: Henning Schulzrinne; Michael Hammer; fmousinh@cisco.com;=20 >>>>>>>Gregory.Schumacher@sprint.com; br@brianrosen.net >>>>>>> Cc: stir@ietf.org >>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>=20 >>>>>>> +1 >>>>>>> I've assumed that we are headed towards a "sign whatever extras=20 >>>>>>> you wish, and indicate what your signature covers" mechanism. >>>>>>>=20 >>>>>>> Based on this, standards would need to identify only a minimal=20 >>>>>>>subset of what shall/should be signed, and ensure that any=20 >>>>>>>required group of signed items survives transit intact. >>>>>>>=20 >>>>>>> Best signing practices may be needed to complement the standard, = >>>>>>>and an appropriate place for all but the most basic 'what to=20 >>>>>>>sign' >>>>>>> recommendations. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Regards, >>>>>>>=20 >>>>>>> Alex >>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On=20 >>>>>>>>Behalf Of Henning Schulzrinne >>>>>>>> Sent: Thursday, September 19, 2013 2:24 PM >>>>>>>> To: Michael Hammer; fmousinh@cisco.com;=20 >>>>>>>>Gregory.Schumacher@sprint.com; >>>>>>>> br@brianrosen.net >>>>>>>> Cc: stir@ietf.org >>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>=20 >>>>>>>> I see no reason not to allow signing any number-related field=20 >>>>>>>>in the SIP request. (Signing may well be done by different >>>>>>>>parties.) >>>>>>>>=20 >>>>>>>> As far as I know, callback numbers (SIP Reply-To) aren't=20 >>>>>>>>conveyable in legacy systems, however, so this may be of=20 >>>>>>>>somewhat limited use for a >>>>>>> while. >>>>>>>>=20 >>>>>>>> ________________________________________ >>>>>>>> From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf=20 >>>>>>>> of Michael Hammer [michael.hammer@yaanatech.com] >>>>>>>> Sent: Thursday, September 19, 2013 4:34 PM >>>>>>>> To: fmousinh@cisco.com; Gregory.Schumacher@sprint.com;=20 >>>>>>>> br@brianrosen.net >>>>>>>> Cc: stir@ietf.org >>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>=20 >>>>>>>> Don't we still want to know the true originator of the call,=20 >>>>>>>>even when we have some token that says "Doctor so and so=20 >>>>>>>>approved this message." >>>>>>>>=20 >>>>>>>> Originating number, display number, and call-back number could=20 >>>>>>>>be >>>>>>>>3 >>>>>>>> different things. >>>>>>>> Should all of them be verifiable? >>>>>>>>=20 >>>>>>>> Mike >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On=20 >>>>>>>>Behalf Of Fernando Mousinho (fmousinh) >>>>>>>> Sent: Thursday, September 19, 2013 4:00 PM >>>>>>>> To: Schumacher, Gregory [CTO]; Brian Rosen >>>>>>>> Cc: stir@ietf.org >>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>=20 >>>>>>>> I believe the scenario telemarketing here is when a client=20 >>>>>>>>hires a BPO to place outbound calls, but expect customers to=20 >>>>>>>>return these calls to a different place (say, their own and=20 >>>>>>>>operated call center). This way, this client is authorizing=20 >>>>>>>>the BPO to use an identity that it >>>>>>>>(BPO) >>>>>>> doesn't own. >>>>>>>> These numbers in this scenario are always operational, just at=20 >>>>>>>> a different place. >>>>>>>>=20 >>>>>>>> The same telemarketing operator would then outpulse multiple=20 >>>>>>>>numbers for their multiple clients, none of these numbers=20 >>>>>>>>belonging to the >>>>>>> telemarketer. >>>>>>>> BTW, we are using the term "telemarketing" in a very generic=20 >>>>>>>>sense - this could just as easily be a public service=20 >>>>>>>>announcement, fundraiser, >>>>>>> etc. >>>>>>>>=20 >>>>>>>> If the telemarketer happens to own the inbound call center as=20 >>>>>>>>well, it very likely owns the number as well and this would=20 >>>>>>>>necessarily be a special case >>>>>>>> - it would fall under the same characteristics of any call = center. >>>>>>>>=20 >>>>>>>> On a different note, it would help a lot of we standardized=20 >>>>>>>> terminology. >>>>>>>> Telemarketing, BPO, call center, end customer, clients=A9 it = may=20 >>>>>>>> be hard for others to follow the discussion later. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> (generic term for any type of outbound calling, including=20 >>>>>>>> public service announcement, so don't think it's all about >>>>>>>> sales!) >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 9/19/13 3:22 PM, "Schumacher, Gregory [CTO]" >>>>>>>> wrote: >>>>>>>>=20 >>>>>>>>> There are some benefits from this approach, but also some=20 >>>>>>>>>scenarios that need clarification how they could function. >>>>>>>>>=20 >>>>>>>>> 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=20 >>>>>>>>>in your scenario). For the use in forensics (after the fact >>>>>>>>>analysis) such as pursuit of fraud investigation, we then can=20 >>>>>>>>>follow both paths. >>>>>>>>>=20 >>>>>>>>> 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=20 >>>>>>>>> telemarketing campaign or both? >>>>>>>>>=20 >>>>>>>>> - How is the SP supposed to know all the parties that it is=20 >>>>>>>>> attesting to >>>>>>>>> - the responsible party and/or executing party? >>>>>>>>>=20 >>>>>>>>> -It seems likely that some of the numbers assigned to a=20 >>>>>>>>>company in your scenario will not be assigned to real=20 >>>>>>>>>telephones (or call center >>>>>>>>> trunk) until a telemarketing campaign is initiated or a call=20 >>>>>>>>>center selected to execute the sales campaign, is it possible=20 >>>>>>>>>to have these unassigned or floating numbers when not in use=20 >>>>>>>>>for a telemarketing campaign? Is it allowed under most=20 >>>>>>>>>national numbering regimes? >>>>>>>>>=20 >>>>>>>>> - How important is it to have a known or recognized phone=20 >>>>>>>>>number as the caller id as part of a telemarketing campaign? >>>>>>>>>I am assuming that not all campaigns care about having a=20 >>>>>>>>>number that is known or >>>>>>> recognized. >>>>>>>>>=20 >>>>>>>>> -In other words for this last bit, if a call center=20 >>>>>>>>>(telemarketing campaign operator) is using their own set of=20 >>>>>>>>>numbers but serve multiple simultaneous telemarketing=20 >>>>>>>>>campaigns using the same originating numbers, what will they=20 >>>>>>>>>sign? Will they just have a credential representing the call=20 >>>>>>>>>center alone, or a different credential per telemarketing=20 >>>>>>>>>campaign, or a different credential per responsible party (per = >>>>>>>>>client)? This will affect what is possible for >>>>>>> any forensic activity. >>>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On=20 >>>>>>>>>Behalf Of Brian Rosen >>>>>>>>> Sent: Tuesday, September 17, 2013 9:44 AM >>>>>>>>> To: Fernando Mousinho >>>>>>>>> Cc: stir@ietf.org; Hadriel Kaplan >>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>=20 >>>>>>>>> We have a requirement to support the BPO use case. >>>>>>>>>=20 >>>>>>>>> The notion we had is that the company contracting the call=20 >>>>>>>>>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=20 >>>>>>>>>numbers to the call center. The call center calls, using that = >>>>>>>>>delegation. >>>>>>>>> The credentials of the call center would be different from=20 >>>>>>>>>those of the company, but would cover the same number. Having = >>>>>>>>>multiple credentials covering the same number will be very=20 >>>>>>>>>common due to the way delegation happens. In order to allow=20 >>>>>>>>>SPs to sign, without creating credential per TN, we allow=20 >>>>>>>>>credentials with ranges. >>>>>>>>>The >>>>>>>>> ranges could overlap when delegation happens. >>>>>>>>>=20 >>>>>>>>> Consider the following complex US case: >>>>>>>>> The North American Number Plan Administrator delegates=20 >>>>>>>>>202-555-xxxx to the Pooling Administrator. The PA now has a=20 >>>>>>>>>credential covering the entire 10K block. >>>>>>>>> The Pooling Administrator delegates 202-555-1xxx to SP A. SP=20 >>>>>>>>>A has a credential for the entire 1K block SP A resells=20 >>>>>>>>>202-555-12xx to SP B . >>>>>>>>> SP B has a credential for a 100 TN block SP B delegates=20 >>>>>>>>>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. =20 >>>>>>>>>BPO D has credential for a 1 number block >>>>>>>>>=20 >>>>>>>>> NANPA and the PA never are in a call path, so they would never = >>>>>>>>>sign a call. >>>>>>>>>=20 >>>>>>>>> However, SP A or SP B could sign a call from either Company C=20 >>>>>>>>>or BPO D using the credential they have. >>>>>>>>>=20 >>>>>>>>> The SP for the call center could acquire credentials from the=20 >>>>>>>>>BPO and sign on its behalf. I suspect than many service=20 >>>>>>>>>providers would be reluctant to do so unless the numbers were=20 >>>>>>>>>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=20 >>>>>>>>>has to do the signing itself. >>>>>>>>>=20 >>>>>>>>> Brian >>>>>>>>>=20 >>>>>>>>> On Sep 17, 2013, at 8:46 AM, Fernando Mousinho (fmousinh)=20 >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>>> I agree, Hadriel. While large call centers (including BPOs,=20 >>>>>>>>>>which provide services for other companies) may have special=20 >>>>>>>>>>arrangements with SPs, the majority (small to mid-size) will=20 >>>>>>>>>>probably rely on the SPs to do provide to vouch for their=20 >>>>>>>>>>identity. This would probably be the case for the home analog = >>>>>>>>>>caller anyway. This would imply that the "originating" SP's=20 >>>>>>>>>>willingness to provide this signature is a critical success=20 >>>>>>>>>>factor for the proposal's adoption. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> But back to the business process outsourcers (BPO) case -=20 >>>>>>>>>>where a call center is providing service on behalf of=20 >>>>>>>>>>multiple companies. I can see the value of them sending=20 >>>>>>>>>>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=20 >>>>>>>>>>that SP >>>>>>>>>> 1 allowing one of its subscribers to send an outbound call=20 >>>>>>>>>>using a number registered to SP 2 could be a no-no. If this=20 >>>>>>>>>>hypothesis is correct, then we are back to the case where the = >>>>>>>>>>SP is signing all calls, >>>>>>>> even for BPOs. >>>>>>>>>>=20 >>>>>>>>>> Or maybe this is another problem we are trying to fix in the=20 >>>>>>>>>>working group, in which case we perhaps should state as a goal = >>>>>>>>>>or >>>>>>> benefit: >>>>>>>>>> "providing a reliable mechanism to let calls originated from=20 >>>>>>>>>> one >>>>>>>>>> SP1 to outpulse numbers that belong to another". >>>>>>>>>>=20 >>>>>>>>>> Fernando >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On 9/16/13 12:12 PM, "Hadriel Kaplan" >>>>>>>>>> >>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Any of them could do it. My guess is service providers will = >>>>>>>>>>>do it for most call centers, although larger call centers=20 >>>>>>>>>>>might do it themselves... >>>>>>>>>>> especially ones which have trunks from multiple providers=20 >>>>>>>>>>>and can source calls using the same number(s) out through=20 >>>>>>>>>>>multiple providers on a call-by-call basis. >>>>>>>>>>>=20 >>>>>>>>>>> -hadriel >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> On Sep 16, 2013, at 9:49 AM, Fernando Mousinho (fmousinh)=20 >>>>>>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> I'm catching up with the discussions in this working group, = >>>>>>>>>>>>and am trying to understand some architecture implications=20 >>>>>>>>>>>>in call centers (which is where my background is). It seems = >>>>>>>>>>>>that many of the problems we are trying to fix are related=20 >>>>>>>>>>>>to contact centers anyway, so it is probably a good idea to = >>>>>>>>>>>>have everyone in the same >>>>>>>> page. >>>>>>>>>>>>=20 >>>>>>>>>>>> Forgive me if it is an obvious question, but which=20 >>>>>>>>>>>>components in a "typical call center architecture" do you=20 >>>>>>>>>>>>see signature and verification taking place? Such "typical" >>>>>>>>>>>>deployments have premises based equipment (PME), a session=20 >>>>>>>>>>>>border controller >>>>>>>>>>>>(SBC) >>>>>>>>>>>> and of course a SIP service provider all three could=20 >>>>>>>>>>>>potentially be used throughout the authorization process. >>>>>>>>>>>>There are different ramifications depending on where your=20 >>>>>>>>>>>>mind is at. >>>>>>>>>>>>=20 >>>>>>>>>>>> Fernando Mousinho >>>>>>>>>>>> Cisco Systems >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> stir mailing list >>>>>>>>>> stir@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> stir mailing list >>>>>>>>> stir@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> ________________________________ >>>>>>>>>=20 >>>>>>>>> This e-mail may contain Sprint proprietary information=20 >>>>>>>>>intended for the sole use of the recipient(s). Any use by=20 >>>>>>>>>others is prohibited. >>>>>>>>> If >>>>>>>>> you are not the intended recipient, please contact the sender=20 >>>>>>>>>and delete all copies of the message. >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> stir mailing list >>>>>>>>> stir@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> stir mailing list >>>>>>>> stir@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>> _______________________________________________ >>>>>>>> stir mailing list >>>>>>>> stir@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>> _______________________________________________ >>>>>>> stir mailing list >>>>>>> stir@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >>=20 > >_______________________________________________ >stir mailing list >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From br@brianrosen.net Wed Oct 30 14:39:18 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1308411E8178 for ; Wed, 30 Oct 2013 14:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.504 X-Spam-Level: X-Spam-Status: No, score=-103.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ylegrl2YvzCk for ; Wed, 30 Oct 2013 14:39:12 -0700 (PDT) Received: from mail-qe0-f49.google.com (mail-qe0-f49.google.com [209.85.128.49]) by ietfa.amsl.com (Postfix) with ESMTP id 15D6221F9D70 for ; Wed, 30 Oct 2013 14:38:55 -0700 (PDT) Received: by mail-qe0-f49.google.com with SMTP id a11so1240034qen.36 for ; Wed, 30 Oct 2013 14:38:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=ewJXlBaTH8hBo0GgkuCxbQZXvY9Bc0nhavIq/Uou/1s=; b=EKy/VMGkRLcJJupf/KaqSkJ5ar/hdalIcYnlaeHZuRh8+am7v0Tpw5nUfKUyRza049 mWKz5RQ8QRWzUYutMD3GbD6aFo0nP+/FuWXGwaXezhU40xzTrj9IBQr24dk3x1EeZ41G wXrab1iYHnkCAhvtMtrdrAIZHsLAbhO4bV7nelRKD/QbW5GHE6uwRSBKy0mt0iIi76lf vGfLqmFqfNwLJ4+01Rzo7bJjPJ04ygbO+Vw0QYoVi9TjERsDCPEVXD60/yyEDsnZ3veB MzPYdnmE5xUqMfUmv52j/TwNdkXE7zd639upJsTqv7pz8HsI6f0911uNAshWGzTFimc/ 3tCQ== X-Gm-Message-State: ALoCoQn0V9WuOloUv+397jyzFWH7xtNh585mE77ZC++6MMwh+w+/KhCzURlubd9oTH7zutjj+vaL X-Received: by 10.224.113.199 with SMTP id b7mr915271qaq.4.1383169134698; Wed, 30 Oct 2013 14:38:54 -0700 (PDT) Received: from [10.33.192.35] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id 5sm1616909qao.3.2013.10.30.14.38.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Oct 2013 14:38:53 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-2 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Brian Rosen In-Reply-To: <029501ced5b5$8fa9f480$aefddd80$@shockey.us> Date: Wed, 30 Oct 2013 17:38:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2AA32171-1AE3-4AEE-AEDC-B2031562B7BD@brianrosen.net> References: <32C55AFE-FA17-4776-AD91-259AD3E226BE@brianrosen.net> <024001ced5a2$f3268810$d9739830$@shockey.us> <029501ced5b5$8fa9f480$aefddd80$@shockey.us> To: Richard Shockey X-Mailer: Apple Mail (2.1816) Cc: cnit@ietf.org Subject: Re: [cnit] [stir] Application servers - Re: Call Center Implications X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 21:39:18 -0000 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 wrote: >=20 > Ok since Brian is being picky.. >=20 > I'm actually interested if anyone is interested in the possibility of = making > SIP Identity to the UA more useful. >=20 >=20 >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of > Richard Shockey > Sent: Wednesday, October 30, 2013 3:05 PM > To: stir@ietf.org > Subject: Re: [stir] Application servers - Re: Call Center Implications >=20 > Dan great post. I couldn't agree more. There needs to be some rules = here. > Some may be regulatory some may be technical. >=20 > 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. >=20 > 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.=20 >=20 > 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. =20 >=20 > 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. >=20 > 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.=20 >=20 >=20 > 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.=20 >=20 >=20 >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = Of Dan > York > Sent: Tuesday, October 29, 2013 5:10 PM > To: Brian Rosen; Cullen Jennings > Cc: Gregory.Schumacher@sprint.com; Richard Shockey; stir@ietf.org; = Fernando > Mousinho (fmousinh); Alex Bobotek; Michael Hammer; Henning Schulzrinne > Subject: [stir] Application servers - Re: Call Center Implications >=20 > 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: >=20 > - 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 >=20 > 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. >=20 > 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. >=20 > 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]. >=20 > 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. >=20 > Dan >=20 > [1] One report about this market: > http://www.voxeo.com/pdf/OvumDecisionMatrix-2011.pdf >=20 >=20 > -- > Dan York > Senior Content Strategist, Internet Society > york@isoc.org +1-802-735-1624 > Jabber: york@jabber.isoc.org > Skype: danyork http://twitter.com/danyork >=20 > http://www.internetsociety.org/deploy360/ >=20 >=20 >=20 >=20 > On 10/21/13 9:15 AM, "Brian Rosen" wrote: >=20 >> We really need to give each BPO different keys I think. The notion = that >> we are sharing private keys among multiple competing entities who=20 >> provide services for a single enterprise strikes me as a VBI (Very = Bad=20 >> Idea). I can't see any real difficulty in having more than one=20 >> authorized entity, each with it's own credentials. Who would have a=20= >> problem? We're already agreeing that there are multiple credentials=20= >> for a number, because the number gets delegated multiple times. >> Consider, just as an example, the BPO and the contracting enterprise=20= >> that was actually delegated the number can both send calls from that=20= >> number. You certainly don't want the enterprise giving out IT'S key = to=20 >> it's contractors. At best it's a key it authorizes to one or more of=20= >> it's > BPOs. >>=20 >> Brian >>=20 >> On Oct 20, 2013, at 1:12 AM, Cullen Jennings (fluffy)=20 >> >> wrote: >>=20 >>>=20 >>> What Fernando is saying makes sense to me a desirable property of = the=20 >>> solution and I agree that if we gave each BPO a different private = key=20 >>> that would solve it but that might be pretty hard to mange in other=20= >>> ways. I like the requirements but the solution is not 100% obvious = to=20 >>> me. >>>=20 >>>=20 >>> On Oct 2, 2013, at 10:27 AM, Brian Rosen wrote: >>>=20 >>>> Sure. >>>>=20 >>>> Each BPO would have a different private/public key pair. >>>>=20 >>>> So you can trace which one placed the call. >>>>=20 >>>> Brian >>>>=20 >>>> On Oct 2, 2013, at 12:59 PM, Fernando Mousinho (fmousinh)=20 >>>> wrote: >>>>=20 >>>>> 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. >>>>>=20 >>>>> If the company hires several BPOs and authorizes all of them to=20 >>>>> sign calls on its behalf, is there a way to trace back the=20 >>>>> originator (specific >>>>> BPO) >>>>> later on? I suppose that at some level the actual caller must be=20= >>>>> exposed (perhaps to trace malicious activity, such as malicious=20= >>>>> person infiltrated in an otherwise legitimate BPO). >>>>>=20 >>>>> Via headers would be the obvious pick, but they don't survive the=20= >>>>> plethora of SBCs that the call is likely to transverse. Or maybe=20= >>>>> the certs themselves can carry this type of data (actual caller=20= >>>>> identity). >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 9/19/13 9:43 PM, "Brian Rosen" wrote: >>>>>=20 >>>>>> 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=20 >>>>>> change to use =46rom (if signed maybe). It also doesn't fit the=20= >>>>>> definition of PAI. >>>>>>=20 >>>>>> Brian >>>>>>=20 >>>>>> On Sep 19, 2013, at 9:14 PM, Fernando Mousinho (fmousinh)=20 >>>>>> wrote: >>>>>>=20 >>>>>>> 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=20 >>>>>>> mentions. >>>>>>> PAI's use is widespread, and it's main limitation is being=20 >>>>>>> spoofable - but this is exactly the problem we are trying to=20 >>>>>>> solve anyway. >>>>>>>=20 >>>>>>>=20 >>>>>>>> On Sep 19, 2013, at 5:39 PM, "Richard Shockey"=20 >>>>>>>> >>>>>>>> wrote: >>>>>>>>=20 >>>>>>>> Excellent point a profile or BCP to complement the work. >>>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On=20= >>>>>>>> Behalf Of Alex Bobotek >>>>>>>> Sent: Thursday, September 19, 2013 5:27 PM >>>>>>>> To: Henning Schulzrinne; Michael Hammer; fmousinh@cisco.com;=20 >>>>>>>> Gregory.Schumacher@sprint.com; br@brianrosen.net >>>>>>>> Cc: stir@ietf.org >>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>=20 >>>>>>>> +1 >>>>>>>> I've assumed that we are headed towards a "sign whatever extras=20= >>>>>>>> you wish, and indicate what your signature covers" mechanism. >>>>>>>>=20 >>>>>>>> Based on this, standards would need to identify only a minimal=20= >>>>>>>> subset of what shall/should be signed, and ensure that any=20 >>>>>>>> required group of signed items survives transit intact. >>>>>>>>=20 >>>>>>>> Best signing practices may be needed to complement the = standard,=20 >>>>>>>> and an appropriate place for all but the most basic 'what to=20= >>>>>>>> sign' >>>>>>>> recommendations. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Regards, >>>>>>>>=20 >>>>>>>> Alex >>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On=20= >>>>>>>>> Behalf Of Henning Schulzrinne >>>>>>>>> Sent: Thursday, September 19, 2013 2:24 PM >>>>>>>>> To: Michael Hammer; fmousinh@cisco.com;=20 >>>>>>>>> Gregory.Schumacher@sprint.com; >>>>>>>>> br@brianrosen.net >>>>>>>>> Cc: stir@ietf.org >>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>=20 >>>>>>>>> I see no reason not to allow signing any number-related field=20= >>>>>>>>> in the SIP request. (Signing may well be done by different >>>>>>>>> parties.) >>>>>>>>>=20 >>>>>>>>> As far as I know, callback numbers (SIP Reply-To) aren't=20 >>>>>>>>> conveyable in legacy systems, however, so this may be of=20 >>>>>>>>> somewhat limited use for a >>>>>>>> while. >>>>>>>>>=20 >>>>>>>>> ________________________________________ >>>>>>>>> From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf=20= >>>>>>>>> of Michael Hammer [michael.hammer@yaanatech.com] >>>>>>>>> Sent: Thursday, September 19, 2013 4:34 PM >>>>>>>>> To: fmousinh@cisco.com; Gregory.Schumacher@sprint.com;=20 >>>>>>>>> br@brianrosen.net >>>>>>>>> Cc: stir@ietf.org >>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>=20 >>>>>>>>> Don't we still want to know the true originator of the call,=20= >>>>>>>>> even when we have some token that says "Doctor so and so=20 >>>>>>>>> approved this message." >>>>>>>>>=20 >>>>>>>>> Originating number, display number, and call-back number could=20= >>>>>>>>> be >>>>>>>>> 3 >>>>>>>>> different things. >>>>>>>>> Should all of them be verifiable? >>>>>>>>>=20 >>>>>>>>> Mike >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On=20= >>>>>>>>> Behalf Of Fernando Mousinho (fmousinh) >>>>>>>>> Sent: Thursday, September 19, 2013 4:00 PM >>>>>>>>> To: Schumacher, Gregory [CTO]; Brian Rosen >>>>>>>>> Cc: stir@ietf.org >>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>=20 >>>>>>>>> I believe the scenario telemarketing here is when a client=20 >>>>>>>>> hires a BPO to place outbound calls, but expect customers to=20= >>>>>>>>> return these calls to a different place (say, their own and=20= >>>>>>>>> operated call center). This way, this client is authorizing=20= >>>>>>>>> the BPO to use an identity that it >>>>>>>>> (BPO) >>>>>>>> doesn't own. >>>>>>>>> These numbers in this scenario are always operational, just at=20= >>>>>>>>> a different place. >>>>>>>>>=20 >>>>>>>>> The same telemarketing operator would then outpulse multiple=20= >>>>>>>>> numbers for their multiple clients, none of these numbers=20 >>>>>>>>> belonging to the >>>>>>>> telemarketer. >>>>>>>>> BTW, we are using the term "telemarketing" in a very generic=20= >>>>>>>>> sense - this could just as easily be a public service=20 >>>>>>>>> announcement, fundraiser, >>>>>>>> etc. >>>>>>>>>=20 >>>>>>>>> If the telemarketer happens to own the inbound call center as=20= >>>>>>>>> well, it very likely owns the number as well and this would=20= >>>>>>>>> necessarily be a special case >>>>>>>>> - it would fall under the same characteristics of any call = center. >>>>>>>>>=20 >>>>>>>>> On a different note, it would help a lot of we standardized=20 >>>>>>>>> terminology. >>>>>>>>> Telemarketing, BPO, call center, end customer, clients=A9 it = may=20 >>>>>>>>> be hard for others to follow the discussion later. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> (generic term for any type of outbound calling, including=20 >>>>>>>>> public service announcement, so don't think it's all about >>>>>>>>> sales!) >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On 9/19/13 3:22 PM, "Schumacher, Gregory [CTO]" >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>>> There are some benefits from this approach, but also some=20 >>>>>>>>>> scenarios that need clarification how they could function. >>>>>>>>>>=20 >>>>>>>>>> The benefit is that the credential represents both the = company=20 >>>>>>>>>> "responsible" for the sales campaign (the "company" in your >>>>>>>>>> scenario) >>>>>>>>>> and the company operating the sales campaign (the call center=20= >>>>>>>>>> in your scenario). For the use in forensics (after the = fact >>>>>>>>>> analysis) such as pursuit of fraud investigation, we then = can=20 >>>>>>>>>> follow both paths. >>>>>>>>>>=20 >>>>>>>>>> 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=20= >>>>>>>>>> telemarketing campaign or both? >>>>>>>>>>=20 >>>>>>>>>> - How is the SP supposed to know all the parties that it is=20= >>>>>>>>>> attesting to >>>>>>>>>> - the responsible party and/or executing party? >>>>>>>>>>=20 >>>>>>>>>> -It seems likely that some of the numbers assigned to a=20 >>>>>>>>>> company in your scenario will not be assigned to real=20 >>>>>>>>>> telephones (or call center >>>>>>>>>> trunk) until a telemarketing campaign is initiated or a call=20= >>>>>>>>>> center selected to execute the sales campaign, is it = possible=20 >>>>>>>>>> to have these unassigned or floating numbers when not in use=20= >>>>>>>>>> for a telemarketing campaign? Is it allowed under most=20 >>>>>>>>>> national numbering regimes? >>>>>>>>>>=20 >>>>>>>>>> - How important is it to have a known or recognized phone=20 >>>>>>>>>> number as the caller id as part of a telemarketing campaign? >>>>>>>>>> I am assuming that not all campaigns care about having a=20 >>>>>>>>>> number that is known or >>>>>>>> recognized. >>>>>>>>>>=20 >>>>>>>>>> -In other words for this last bit, if a call center=20 >>>>>>>>>> (telemarketing campaign operator) is using their own set of=20= >>>>>>>>>> numbers but serve multiple simultaneous telemarketing=20 >>>>>>>>>> campaigns using the same originating numbers, what will they=20= >>>>>>>>>> sign? Will they just have a credential representing the = call=20 >>>>>>>>>> center alone, or a different credential per telemarketing=20 >>>>>>>>>> campaign, or a different credential per responsible party = (per=20 >>>>>>>>>> client)? This will affect what is possible for >>>>>>>> any forensic activity. >>>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On=20= >>>>>>>>>> Behalf Of Brian Rosen >>>>>>>>>> Sent: Tuesday, September 17, 2013 9:44 AM >>>>>>>>>> To: Fernando Mousinho >>>>>>>>>> Cc: stir@ietf.org; Hadriel Kaplan >>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>=20 >>>>>>>>>> We have a requirement to support the BPO use case. >>>>>>>>>>=20 >>>>>>>>>> The notion we had is that the company contracting the call=20 >>>>>>>>>> center approves the use, and the call center, or the SP = acting=20 >>>>>>>>>> on its behalf, signs. >>>>>>>>>> Think of this as another level of delegation. An SP = delegates=20 >>>>>>>>>> numbers to the company. The company "delegates" use of those=20= >>>>>>>>>> numbers to the call center. The call center calls, using = that=20 >>>>>>>>>> delegation. >>>>>>>>>> The credentials of the call center would be different from=20 >>>>>>>>>> those of the company, but would cover the same number. = Having=20 >>>>>>>>>> multiple credentials covering the same number will be very=20= >>>>>>>>>> common due to the way delegation happens. In order to allow=20= >>>>>>>>>> SPs to sign, without creating credential per TN, we allow=20 >>>>>>>>>> credentials with ranges. >>>>>>>>>> The >>>>>>>>>> ranges could overlap when delegation happens. >>>>>>>>>>=20 >>>>>>>>>> Consider the following complex US case: >>>>>>>>>> The North American Number Plan Administrator delegates=20 >>>>>>>>>> 202-555-xxxx to the Pooling Administrator. The PA now has a=20= >>>>>>>>>> credential covering the entire 10K block. >>>>>>>>>> The Pooling Administrator delegates 202-555-1xxx to SP A. SP=20= >>>>>>>>>> A has a credential for the entire 1K block SP A resells=20 >>>>>>>>>> 202-555-12xx to SP B . >>>>>>>>>> SP B has a credential for a 100 TN block SP B delegates=20 >>>>>>>>>> 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. =20= >>>>>>>>>> BPO D has credential for a 1 number block >>>>>>>>>>=20 >>>>>>>>>> NANPA and the PA never are in a call path, so they would = never=20 >>>>>>>>>> sign a call. >>>>>>>>>>=20 >>>>>>>>>> However, SP A or SP B could sign a call from either Company C=20= >>>>>>>>>> or BPO D using the credential they have. >>>>>>>>>>=20 >>>>>>>>>> The SP for the call center could acquire credentials from the=20= >>>>>>>>>> BPO and sign on its behalf. I suspect than many service=20 >>>>>>>>>> providers would be reluctant to do so unless the numbers = were=20 >>>>>>>>>> from their own inventory (that is, the company got its = numbers=20 >>>>>>>>>> from the same SP as the call >>>>>>>> center). >>>>>>>>>> Since that won't be the common case, the call center probably=20= >>>>>>>>>> has to do the signing itself. >>>>>>>>>>=20 >>>>>>>>>> Brian >>>>>>>>>>=20 >>>>>>>>>> On Sep 17, 2013, at 8:46 AM, Fernando Mousinho (fmousinh)=20 >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>> I agree, Hadriel. While large call centers (including BPOs,=20= >>>>>>>>>>> which provide services for other companies) may have = special=20 >>>>>>>>>>> arrangements with SPs, the majority (small to mid-size) = will=20 >>>>>>>>>>> probably rely on the SPs to do provide to vouch for their=20= >>>>>>>>>>> identity. This would probably be the case for the home = analog=20 >>>>>>>>>>> caller anyway. This would imply that the "originating" SP's=20= >>>>>>>>>>> willingness to provide this signature is a critical success=20= >>>>>>>>>>> factor for the proposal's adoption. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> But back to the business process outsourcers (BPO) case -=20 >>>>>>>>>>> where a call center is providing service on behalf of=20 >>>>>>>>>>> multiple companies. I can see the value of them sending=20 >>>>>>>>>>> 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=20= >>>>>>>>>>> that SP >>>>>>>>>>> 1 allowing one of its subscribers to send an outbound call=20= >>>>>>>>>>> using a number registered to SP 2 could be a no-no. If this=20= >>>>>>>>>>> hypothesis is correct, then we are back to the case where = the=20 >>>>>>>>>>> SP is signing all calls, >>>>>>>>> even for BPOs. >>>>>>>>>>>=20 >>>>>>>>>>> Or maybe this is another problem we are trying to fix in the=20= >>>>>>>>>>> working group, in which case we perhaps should state as a = goal=20 >>>>>>>>>>> or >>>>>>>> benefit: >>>>>>>>>>> "providing a reliable mechanism to let calls originated from=20= >>>>>>>>>>> one >>>>>>>>>>> SP1 to outpulse numbers that belong to another". >>>>>>>>>>>=20 >>>>>>>>>>> Fernando >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> On 9/16/13 12:12 PM, "Hadriel Kaplan" >>>>>>>>>>> >>>>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Any of them could do it. My guess is service providers = will=20 >>>>>>>>>>>> do it for most call centers, although larger call centers=20= >>>>>>>>>>>> might do it themselves... >>>>>>>>>>>> especially ones which have trunks from multiple providers=20= >>>>>>>>>>>> and can source calls using the same number(s) out through=20= >>>>>>>>>>>> multiple providers on a call-by-call basis. >>>>>>>>>>>>=20 >>>>>>>>>>>> -hadriel >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> On Sep 16, 2013, at 9:49 AM, Fernando Mousinho (fmousinh)=20= >>>>>>>>>>>> wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>> I'm catching up with the discussions in this working = group,=20 >>>>>>>>>>>>> and am trying to understand some architecture = implications=20 >>>>>>>>>>>>> in call centers (which is where my background is). It = seems=20 >>>>>>>>>>>>> that many of the problems we are trying to fix are = related=20 >>>>>>>>>>>>> to contact centers anyway, so it is probably a good idea = to=20 >>>>>>>>>>>>> have everyone in the same >>>>>>>>> page. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Forgive me if it is an obvious question, but which=20 >>>>>>>>>>>>> components in a "typical call center architecture" do you=20= >>>>>>>>>>>>> see signature and verification taking place? Such = "typical" >>>>>>>>>>>>> deployments have premises based equipment (PME), a = session=20 >>>>>>>>>>>>> border controller >>>>>>>>>>>>> (SBC) >>>>>>>>>>>>> and of course a SIP service provider all three could=20 >>>>>>>>>>>>> potentially be used throughout the authorization process. >>>>>>>>>>>>> There are different ramifications depending on where your=20= >>>>>>>>>>>>> mind is at. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Fernando Mousinho >>>>>>>>>>>>> Cisco Systems >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> stir mailing list >>>>>>>>>>> stir@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> stir mailing list >>>>>>>>>> stir@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> ________________________________ >>>>>>>>>>=20 >>>>>>>>>> This e-mail may contain Sprint proprietary information=20 >>>>>>>>>> intended for the sole use of the recipient(s). Any use by=20 >>>>>>>>>> others is prohibited. >>>>>>>>>> If >>>>>>>>>> you are not the intended recipient, please contact the sender=20= >>>>>>>>>> and delete all copies of the message. >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> stir mailing list >>>>>>>>>> stir@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> stir mailing list >>>>>>>>> stir@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>> _______________________________________________ >>>>>>>>> stir mailing list >>>>>>>>> stir@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>> _______________________________________________ >>>>>>>> stir mailing list >>>>>>>> stir@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> stir mailing list >>>> stir@ietf.org >>>> https://www.ietf.org/mailman/listinfo/stir >>>=20 >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 > _______________________________________________ > cnit mailing list > cnit@ietf.org > https://www.ietf.org/mailman/listinfo/cnit From richard@shockey.us Thu Oct 31 10:11:47 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9616611E817F for ; Thu, 31 Oct 2013 10:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.465 X-Spam-Level: X-Spam-Status: No, score=-102.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fDD2DWcRaeiT for ; Thu, 31 Oct 2013 10:11:43 -0700 (PDT) Received: from outbound-ss-1033.hostmonster.com (outbound-ss-1033.hostmonster.com [74.220.205.131]) by ietfa.amsl.com (Postfix) with SMTP id 0381221F9F45 for ; Thu, 31 Oct 2013 10:11:42 -0700 (PDT) Received: (qmail 5101 invoked by uid 0); 31 Oct 2013 12:49:20 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.mail.unifiedlayer.com with SMTP; 31 Oct 2013 12:49:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=bW2RqQaBKWGeS+oTx02WEx5rOdELK1jov0TLAUUOMak=; b=IOQy7/YE+rGzETpepYJhFD5ljWZ67nJb4x2WgzpMJA9HBA7sqZWpIMVjZbHIa20v2htuClooEscpH5hgmCRTsP6B5vSm8n0WfFuaaRii2tD7R3it6V+j//AuGCHHuuAL; Received: from [173.79.179.104] (port=49445 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Vbrge-0007Rd-6Z; Thu, 31 Oct 2013 06:49:20 -0600 From: "Richard Shockey" To: "'Brian Rosen'" References: <32C55AFE-FA17-4776-AD91-259AD3E226BE@brianrosen.net> <024001ced5a2$f3268810$d9739830$@shockey.us> <029501ced5b5$8fa9f480$aefddd80$@shockey.us> <2AA32171-1AE3-4AEE-AEDC-B2031562B7BD@brianrosen.net> In-Reply-To: <2AA32171-1AE3-4AEE-AEDC-B2031562B7BD@brianrosen.net> Date: Thu, 31 Oct 2013 08:49:19 -0400 Message-ID: <00d901ced637$9e8143a0$db83cae0$@shockey.us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQLTdCvgrcMvmbDsv2xAt2r4G5TZbQLC46EgAqz016cBpe129QIWVK8Pl7ss6oA= X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.79.179.104 authed with richard@shockey.us} Cc: cnit@ietf.org, 'DISPATCH' Subject: Re: [cnit] [stir] Application servers - Re: Call Center Implications X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 17:11:47 -0000 Brian please.. Look at the mail. I'm using the CNIT list. =20 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.=20 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.=20 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.=20 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.=20 -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Wednesday, October 30, 2013 5:39 PM To: Richard Shockey Cc: cnit@ietf.org 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 wrote: >=20 > Ok since Brian is being picky.. >=20 > I'm actually interested if anyone is interested in the possibility of=20 > making SIP Identity to the UA more useful. >=20 >=20 >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 > Of Richard Shockey > Sent: Wednesday, October 30, 2013 3:05 PM > To: stir@ietf.org > Subject: Re: [stir] Application servers - Re: Call Center Implications >=20 > Dan great post. I couldn't agree more. There needs to be some rules = here. > Some may be regulatory some may be technical. >=20 > First the voice application service providers need to provide the=20 > terminating CUA, "an accurate and truthful" Caller-ID for the call=20 > 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=20 > RESPORGS. >=20 > 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=20 > 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. >=20 > There is something larger here to consider. Though the focus of STIR=20 > 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. =20 >=20 > CNAM. That is NOT something STIR can do but I do believe there is an=20 > emerging requirement that under some cases the calling party wants to=20 > or should provide more substantive information about themselves to the = > called party and frankly 15 character ASCII is not enough. Consumers=20 > or businesses should be able to see more complete and validated=20 > information about the session in order to make an better and informed=20 > decision on whether to accept the 'call' or not. Regulators may want=20 > to require telemarketing firms to display NG CNAM or CNAM + like data=20 > as a condition of doing business. >=20 > All of the examples you cite are excellent examples where such verbose = > calling party identification could be displayed. I certainly want to=20 > answer a call from my doctor on my test results just as I wish to=20 > ignore a call from Bill Clinton begging me to vote in the Virginia=20 > Governors election next Tuesday. This is a case where annominity is = not a good idea. >=20 >=20 > All you need now is a little standardization. > Technically this should is very easy to understand in SIP. It would=20 > probably a reasonable modification of the Call INFO header in SIP with = > something like a XML based VCARD or JCARD URI whatever and probably=20 > 3GPP would need to look at how such data is displayed on the mobile=20 > VoLTE handsets. The network operators would have to understand not to=20 > modify the contents of such a URI and its source validated but that is = > a task for another day. >=20 >=20 >=20 > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 > Of Dan York > Sent: Tuesday, October 29, 2013 5:10 PM > To: Brian Rosen; Cullen Jennings > Cc: Gregory.Schumacher@sprint.com; Richard Shockey; stir@ietf.org;=20 > Fernando Mousinho (fmousinh); Alex Bobotek; Michael Hammer; Henning=20 > Schulzrinne > Subject: [stir] Application servers - Re: Call Center Implications >=20 > Getting caught up on some of the STIR discussions, I'd just note that=20 > when we talk about "call centers" or "BPOs" we also need to remember=20 > that we're not only talking about "traditional" call centers but also=20 > what I'll call "voice application service providers". They are=20 > generally automated platforms running applications that a company uses = > for some kind of outbound service. Examples include: >=20 > - calling everyone in a school district with a weather-related=20 > cancellation (or, unfortunately, a school shooting or similar event) > - calling patients to provide reminders of appointments or=20 > notifications of subscriptions available > - calling customers to let them know that a package was delivered or=20 > could be picked up, etc. > - calling people scheduled for a flight to let know they are going to=20 > be delayed > - calling members of an organization with an automated survey about=20 > current issues > - performing a call-back to provide an additional layer of=20 > authentication for some service >=20 > There is a large (and growing) market for these kind of automated=20 > tools and services and the distinction between these calls and=20 > "robocalls" is really only one of intent and the fact that the = recipient has "opted in" > through some kind of system. >=20 > Generally, though, many of the companies want the application to=20 > appear as if it is coming from their own phone number in the same way=20 > that they want an outbound call center to appear as if it is coming=20 > from one of their own phone numbers. >=20 > You could think of these in the same way as "call centers", but I=20 > point this out because some of these new services are very automated=20 > 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=20 > others have teams of people involved. Some of the companies involved=20 > include Nuance, Microsoft Tellme, Voxeo (now Aspect, and also my=20 > former employer), Tropo, Twilio, Convergys and many more[1]. >=20 > If STIR is to succeed, these kind of application platforms will also=20 > need to be able to make calls on behalf of the companies using those platforms. >=20 > Dan >=20 > [1] One report about this market: > http://www.voxeo.com/pdf/OvumDecisionMatrix-2011.pdf >=20 >=20 > -- > Dan York > Senior Content Strategist, Internet Society > york@isoc.org +1-802-735-1624 > Jabber: york@jabber.isoc.org > Skype: danyork http://twitter.com/danyork >=20 > http://www.internetsociety.org/deploy360/ >=20 >=20 >=20 >=20 > On 10/21/13 9:15 AM, "Brian Rosen" wrote: >=20 >> We really need to give each BPO different keys I think. The notion = that >> we are sharing private keys among multiple competing entities who=20 >> provide services for a single enterprise strikes me as a VBI (Very=20 >> Bad Idea). I can't see any real difficulty in having more than one=20 >> authorized entity, each with it's own credentials. Who would have a=20 >> problem? We're already agreeing that there are multiple credentials=20 >> for a number, because the number gets delegated multiple times. >> Consider, just as an example, the BPO and the contracting enterprise=20 >> that was actually delegated the number can both send calls from that=20 >> number. You certainly don't want the enterprise giving out IT'S key=20 >> to it's contractors. At best it's a key it authorizes to one or more = >> of it's > BPOs. >>=20 >> Brian >>=20 >> On Oct 20, 2013, at 1:12 AM, Cullen Jennings (fluffy)=20 >> >> wrote: >>=20 >>>=20 >>> What Fernando is saying makes sense to me a desirable property of=20 >>> the solution and I agree that if we gave each BPO a different=20 >>> private key that would solve it but that might be pretty hard to=20 >>> mange in other ways. I like the requirements but the solution is not = >>> 100% obvious to me. >>>=20 >>>=20 >>> On Oct 2, 2013, at 10:27 AM, Brian Rosen wrote: >>>=20 >>>> Sure. >>>>=20 >>>> Each BPO would have a different private/public key pair. >>>>=20 >>>> So you can trace which one placed the call. >>>>=20 >>>> Brian >>>>=20 >>>> On Oct 2, 2013, at 12:59 PM, Fernando Mousinho (fmousinh)=20 >>>> wrote: >>>>=20 >>>>> 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. >>>>>=20 >>>>> If the company hires several BPOs and authorizes all of them to=20 >>>>> sign calls on its behalf, is there a way to trace back the=20 >>>>> originator (specific >>>>> BPO) >>>>> later on? I suppose that at some level the actual caller must be=20 >>>>> exposed (perhaps to trace malicious activity, such as malicious=20 >>>>> person infiltrated in an otherwise legitimate BPO). >>>>>=20 >>>>> Via headers would be the obvious pick, but they don't survive the=20 >>>>> plethora of SBCs that the call is likely to transverse. Or maybe=20 >>>>> the certs themselves can carry this type of data (actual caller=20 >>>>> identity). >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 9/19/13 9:43 PM, "Brian Rosen" wrote: >>>>>=20 >>>>>> 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=20 >>>>>> change to use From (if signed maybe). It also doesn't fit the=20 >>>>>> definition of PAI. >>>>>>=20 >>>>>> Brian >>>>>>=20 >>>>>> On Sep 19, 2013, at 9:14 PM, Fernando Mousinho (fmousinh)=20 >>>>>> wrote: >>>>>>=20 >>>>>>> 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=20 >>>>>>> mentions. >>>>>>> PAI's use is widespread, and it's main limitation is being=20 >>>>>>> spoofable - but this is exactly the problem we are trying to=20 >>>>>>> solve anyway. >>>>>>>=20 >>>>>>>=20 >>>>>>>> On Sep 19, 2013, at 5:39 PM, "Richard Shockey"=20 >>>>>>>> >>>>>>>> wrote: >>>>>>>>=20 >>>>>>>> Excellent point a profile or BCP to complement the work. >>>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On=20 >>>>>>>> Behalf Of Alex Bobotek >>>>>>>> Sent: Thursday, September 19, 2013 5:27 PM >>>>>>>> To: Henning Schulzrinne; Michael Hammer; fmousinh@cisco.com;=20 >>>>>>>> Gregory.Schumacher@sprint.com; br@brianrosen.net >>>>>>>> Cc: stir@ietf.org >>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>=20 >>>>>>>> +1 >>>>>>>> I've assumed that we are headed towards a "sign whatever extras = >>>>>>>> you wish, and indicate what your signature covers" mechanism. >>>>>>>>=20 >>>>>>>> Based on this, standards would need to identify only a minimal=20 >>>>>>>> subset of what shall/should be signed, and ensure that any=20 >>>>>>>> required group of signed items survives transit intact. >>>>>>>>=20 >>>>>>>> Best signing practices may be needed to complement the=20 >>>>>>>> standard, and an appropriate place for all but the most basic=20 >>>>>>>> 'what to sign' >>>>>>>> recommendations. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Regards, >>>>>>>>=20 >>>>>>>> Alex >>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On=20 >>>>>>>>> Behalf Of Henning Schulzrinne >>>>>>>>> Sent: Thursday, September 19, 2013 2:24 PM >>>>>>>>> To: Michael Hammer; fmousinh@cisco.com;=20 >>>>>>>>> Gregory.Schumacher@sprint.com; br@brianrosen.net >>>>>>>>> Cc: stir@ietf.org >>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>=20 >>>>>>>>> I see no reason not to allow signing any number-related field=20 >>>>>>>>> in the SIP request. (Signing may well be done by different >>>>>>>>> parties.) >>>>>>>>>=20 >>>>>>>>> As far as I know, callback numbers (SIP Reply-To) aren't=20 >>>>>>>>> conveyable in legacy systems, however, so this may be of=20 >>>>>>>>> somewhat limited use for a >>>>>>>> while. >>>>>>>>>=20 >>>>>>>>> ________________________________________ >>>>>>>>> From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf=20 >>>>>>>>> of Michael Hammer [michael.hammer@yaanatech.com] >>>>>>>>> Sent: Thursday, September 19, 2013 4:34 PM >>>>>>>>> To: fmousinh@cisco.com; Gregory.Schumacher@sprint.com;=20 >>>>>>>>> br@brianrosen.net >>>>>>>>> Cc: stir@ietf.org >>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>=20 >>>>>>>>> Don't we still want to know the true originator of the call,=20 >>>>>>>>> even when we have some token that says "Doctor so and so=20 >>>>>>>>> approved this message." >>>>>>>>>=20 >>>>>>>>> Originating number, display number, and call-back number could = >>>>>>>>> be >>>>>>>>> 3 >>>>>>>>> different things. >>>>>>>>> Should all of them be verifiable? >>>>>>>>>=20 >>>>>>>>> Mike >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On=20 >>>>>>>>> Behalf Of Fernando Mousinho (fmousinh) >>>>>>>>> Sent: Thursday, September 19, 2013 4:00 PM >>>>>>>>> To: Schumacher, Gregory [CTO]; Brian Rosen >>>>>>>>> Cc: stir@ietf.org >>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>=20 >>>>>>>>> I believe the scenario telemarketing here is when a client=20 >>>>>>>>> hires a BPO to place outbound calls, but expect customers to = >>>>>>>>> return these calls to a different place (say, their own and=20 >>>>>>>>> operated call center). This way, this client is authorizing=20 >>>>>>>>> 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. >>>>>>>>>=20 >>>>>>>>> The same telemarketing operator would then outpulse multiple=20 >>>>>>>>> numbers for their multiple clients, none of these numbers=20 >>>>>>>>> belonging to the >>>>>>>> telemarketer. >>>>>>>>> BTW, we are using the term "telemarketing" in a very generic=20 >>>>>>>>> sense - this could just as easily be a public service=20 >>>>>>>>> announcement, fundraiser, >>>>>>>> etc. >>>>>>>>>=20 >>>>>>>>> If the telemarketer happens to own the inbound call center as=20 >>>>>>>>> well, it very likely owns the number as well and this would=20 >>>>>>>>> necessarily be a special case >>>>>>>>> - it would fall under the same characteristics of any call = center. >>>>>>>>>=20 >>>>>>>>> On a different note, it would help a lot of we standardized=20 >>>>>>>>> terminology. >>>>>>>>> Telemarketing, BPO, call center, end customer, clients=A9 it = may=20 >>>>>>>>> be hard for others to follow the discussion later. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> (generic term for any type of outbound calling, including=20 >>>>>>>>> public service announcement, so don't think it's all about >>>>>>>>> sales!) >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On 9/19/13 3:22 PM, "Schumacher, Gregory [CTO]" >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>>> There are some benefits from this approach, but also some=20 >>>>>>>>>> scenarios that need clarification how they could function. >>>>>>>>>>=20 >>>>>>>>>> The benefit is that the credential represents both the=20 >>>>>>>>>> company "responsible" for the sales campaign (the "company"=20 >>>>>>>>>> in your >>>>>>>>>> scenario) >>>>>>>>>> and the company operating the sales campaign (the call center = >>>>>>>>>> in your scenario). For the use in forensics (after the=20 >>>>>>>>>> fact >>>>>>>>>> analysis) such as pursuit of fraud investigation, we then=20 >>>>>>>>>> can follow both paths. >>>>>>>>>>=20 >>>>>>>>>> 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=20 >>>>>>>>>> telemarketing campaign or both? >>>>>>>>>>=20 >>>>>>>>>> - How is the SP supposed to know all the parties that it is=20 >>>>>>>>>> attesting to >>>>>>>>>> - the responsible party and/or executing party? >>>>>>>>>>=20 >>>>>>>>>> -It seems likely that some of the numbers assigned to a=20 >>>>>>>>>> company in your scenario will not be assigned to real=20 >>>>>>>>>> telephones (or call center >>>>>>>>>> trunk) until a telemarketing campaign is initiated or a call=20 >>>>>>>>>> center selected to execute the sales campaign, is it=20 >>>>>>>>>> possible to have these unassigned or floating numbers when=20 >>>>>>>>>> not in use for a telemarketing campaign? Is it allowed=20 >>>>>>>>>> under most national numbering regimes? >>>>>>>>>>=20 >>>>>>>>>> - How important is it to have a known or recognized phone=20 >>>>>>>>>> number as the caller id as part of a telemarketing campaign? >>>>>>>>>> I am assuming that not all campaigns care about having a=20 >>>>>>>>>> number that is known or >>>>>>>> recognized. >>>>>>>>>>=20 >>>>>>>>>> -In other words for this last bit, if a call center=20 >>>>>>>>>> (telemarketing campaign operator) is using their own set of=20 >>>>>>>>>> numbers but serve multiple simultaneous telemarketing=20 >>>>>>>>>> campaigns using the same originating numbers, what will they = >>>>>>>>>> sign? Will they just have a credential representing the=20 >>>>>>>>>> call center alone, or a different credential per=20 >>>>>>>>>> telemarketing campaign, or a different credential per =20 >>>>>>>>>> responsible party (per client)? This will affect what is=20 >>>>>>>>>> possible for >>>>>>>> any forensic activity. >>>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On = >>>>>>>>>> Behalf Of Brian Rosen >>>>>>>>>> Sent: Tuesday, September 17, 2013 9:44 AM >>>>>>>>>> To: Fernando Mousinho >>>>>>>>>> Cc: stir@ietf.org; Hadriel Kaplan >>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>=20 >>>>>>>>>> We have a requirement to support the BPO use case. >>>>>>>>>>=20 >>>>>>>>>> The notion we had is that the company contracting the call=20 >>>>>>>>>> center approves the use, and the call center, or the SP=20 >>>>>>>>>> acting on its behalf, signs. >>>>>>>>>> Think of this as another level of delegation. An SP=20 >>>>>>>>>> delegates numbers to the company. The company "delegates"=20 >>>>>>>>>> use of those numbers to the call center. The call center=20 >>>>>>>>>> calls, using that delegation. >>>>>>>>>> The credentials of the call center would be different from=20 >>>>>>>>>> those of the company, but would cover the same number. =20 >>>>>>>>>> Having multiple credentials covering the same number will be = >>>>>>>>>> very common due to the way delegation happens. In order to=20 >>>>>>>>>> allow SPs to sign, without creating credential per TN, we=20 >>>>>>>>>> allow credentials with ranges. >>>>>>>>>> The >>>>>>>>>> ranges could overlap when delegation happens. >>>>>>>>>>=20 >>>>>>>>>> Consider the following complex US case: >>>>>>>>>> The North American Number Plan Administrator delegates=20 >>>>>>>>>> 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=20 >>>>>>>>>> 202-555-12xx to SP B . >>>>>>>>>> SP B has a credential for a 100 TN block SP B delegates=20 >>>>>>>>>> 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 >>>>>>>>>>=20 >>>>>>>>>> NANPA and the PA never are in a call path, so they would=20 >>>>>>>>>> never sign a call. >>>>>>>>>>=20 >>>>>>>>>> However, SP A or SP B could sign a call from either Company C = >>>>>>>>>> or BPO D using the credential they have. >>>>>>>>>>=20 >>>>>>>>>> The SP for the call center could acquire credentials from the = >>>>>>>>>> BPO and sign on its behalf. I suspect than many service=20 >>>>>>>>>> providers would be reluctant to do so unless the numbers=20 >>>>>>>>>> were from their own inventory (that is, the company got its=20 >>>>>>>>>> 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. >>>>>>>>>>=20 >>>>>>>>>> Brian >>>>>>>>>>=20 >>>>>>>>>> On Sep 17, 2013, at 8:46 AM, Fernando Mousinho (fmousinh)=20 >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>> I agree, Hadriel. While large call centers (including BPOs,=20 >>>>>>>>>>> which provide services for other companies) may have=20 >>>>>>>>>>> special arrangements with SPs, the majority (small to=20 >>>>>>>>>>> mid-size) will probably rely on the SPs to do provide to=20 >>>>>>>>>>> vouch for their identity. This would probably be the case=20 >>>>>>>>>>> for the home analog caller anyway. This would imply that=20 >>>>>>>>>>> the "originating" SP's willingness to provide this =20 >>>>>>>>>>> signature is a critical success factor for the proposal's adoption. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> But back to the business process outsourcers (BPO) case -=20 >>>>>>>>>>> where a call center is providing service on behalf of=20 >>>>>>>>>>> multiple companies. I can see the value of them sending=20 >>>>>>>>>>> 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=20 >>>>>>>>>>> that SP >>>>>>>>>>> 1 allowing one of its subscribers to send an outbound call=20 >>>>>>>>>>> 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=20 >>>>>>>>>>> the SP is signing all calls, >>>>>>>>> even for BPOs. >>>>>>>>>>>=20 >>>>>>>>>>> Or maybe this is another problem we are trying to fix in the = >>>>>>>>>>> working group, in which case we perhaps should state as a=20 >>>>>>>>>>> goal or >>>>>>>> benefit: >>>>>>>>>>> "providing a reliable mechanism to let calls originated from = >>>>>>>>>>> one >>>>>>>>>>> SP1 to outpulse numbers that belong to another". >>>>>>>>>>>=20 >>>>>>>>>>> Fernando >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> On 9/16/13 12:12 PM, "Hadriel Kaplan" >>>>>>>>>>> >>>>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Any of them could do it. My guess is service providers=20 >>>>>>>>>>>> will do it for most call centers, although larger call=20 >>>>>>>>>>>> centers might do it themselves... >>>>>>>>>>>> especially ones which have trunks from multiple providers=20 >>>>>>>>>>>> and can source calls using the same number(s) out through=20 >>>>>>>>>>>> multiple providers on a call-by-call basis. >>>>>>>>>>>>=20 >>>>>>>>>>>> -hadriel >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> On Sep 16, 2013, at 9:49 AM, Fernando Mousinho (fmousinh)=20 >>>>>>>>>>>> wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>> I'm catching up with the discussions in this working=20 >>>>>>>>>>>>> group, and am trying to understand some architecture=20 >>>>>>>>>>>>> implications in call centers (which is where my=20 >>>>>>>>>>>>> background is). It seems that many of the problems we are = >>>>>>>>>>>>> trying to fix are related to contact centers anyway, so=20 >>>>>>>>>>>>> it is probably a good idea to have everyone in the same >>>>>>>>> page. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Forgive me if it is an obvious question, but which=20 >>>>>>>>>>>>> components in a "typical call center architecture" do you = >>>>>>>>>>>>> see signature and verification taking place? Such = "typical" >>>>>>>>>>>>> deployments have premises based equipment (PME), a=20 >>>>>>>>>>>>> session border controller >>>>>>>>>>>>> (SBC) >>>>>>>>>>>>> and of course a SIP service provider all three could=20 >>>>>>>>>>>>> potentially be used throughout the authorization process. >>>>>>>>>>>>> There are different ramifications depending on where your = >>>>>>>>>>>>> mind is at. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Fernando Mousinho >>>>>>>>>>>>> Cisco Systems >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> stir mailing list >>>>>>>>>>> stir@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> stir mailing list >>>>>>>>>> stir@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> ________________________________ >>>>>>>>>>=20 >>>>>>>>>> This e-mail may contain Sprint proprietary information=20 >>>>>>>>>> intended for the sole use of the recipient(s). Any use by=20 >>>>>>>>>> others is prohibited. >>>>>>>>>> If >>>>>>>>>> you are not the intended recipient, please contact the sender = >>>>>>>>>> and delete all copies of the message. >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> stir mailing list >>>>>>>>>> stir@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> stir mailing list >>>>>>>>> stir@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>> _______________________________________________ >>>>>>>>> stir mailing list >>>>>>>>> stir@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>> _______________________________________________ >>>>>>>> stir mailing list >>>>>>>> stir@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> stir mailing list >>>> stir@ietf.org >>>> https://www.ietf.org/mailman/listinfo/stir >>>=20 >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 > _______________________________________________ > cnit mailing list > cnit@ietf.org > https://www.ietf.org/mailman/listinfo/cnit From br@brianrosen.net Thu Oct 31 10:19:41 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 067FA21E80F7 for ; Thu, 31 Oct 2013 10:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.512 X-Spam-Level: X-Spam-Status: No, score=-103.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zEd9NSziot7Q for ; Thu, 31 Oct 2013 10:19:36 -0700 (PDT) Received: from mail-qc0-f178.google.com (mail-qc0-f178.google.com [209.85.216.178]) by ietfa.amsl.com (Postfix) with ESMTP id 59E9711E8169 for ; Thu, 31 Oct 2013 10:19:33 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id x19so1839317qcw.9 for ; Thu, 31 Oct 2013 10:19:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=f82e7eAEYhgiMxXizC1JCfcg3LyxAIxi8yKTiWkKXxs=; b=BT+bbzPGMU7O4UWmcy83CNMlZKl4/lw9uY9fcD7wnrXyP9Nu6KL8Cm94xpPIrF5SkE thanFXi91KT894F4dEZDVPEsONFl5ZV95sjBbYo/KKgNzxgpDll2eBx0Dymoub7HQ1qI C0pBMIBAzai9Ci4cr7k7Hl/Qdk5LFut1N7asDtqMQ3ZIvhYJBFHh1BS5e5JZOPllYpMr GJmglx+Sfo4tryTrCVUDRfjA+Twcx0eiFNd6+MqWqMh3m4pYff9832Juy8Q8Fi+tq6+x mevpQnoq0vZeupFZDv5t+uC7Ve0/yh1acaEG0z71KN/4oxLPCICR6R006b6H6VqqPS78 al2A== X-Gm-Message-State: ALoCoQkFrLEAqIcHDlE7wRL0pDc9OAbcJKmN5FjB8AL7BXK5+BssqCASbnHlbNF6TT0nhe9d97lb X-Received: by 10.224.75.200 with SMTP id z8mr6607062qaj.71.1383239972475; Thu, 31 Oct 2013 10:19:32 -0700 (PDT) Received: from [10.33.192.35] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id kz8sm8826249qeb.0.2013.10.31.10.19.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 31 Oct 2013 10:19:31 -0700 (PDT) Content-Type: text/plain; charset=windows-1250 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Brian Rosen In-Reply-To: <00d901ced637$9e8143a0$db83cae0$@shockey.us> Date: Thu, 31 Oct 2013 13:19:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8B0027B8-D777-48F3-B5BF-B8F81F038E37@brianrosen.net> References: <32C55AFE-FA17-4776-AD91-259AD3E226BE@brianrosen.net> <024001ced5a2$f3268810$d9739830$@shockey.us> <029501ced5b5$8fa9f480$aefddd80$@shockey.us> <2AA32171-1AE3-4AEE-AEDC-B2031562B7BD@brianrosen.net> <00d901ced637$9e8143a0$db83cae0$@shockey.us> To: Richard Shockey X-Mailer: Apple Mail (2.1816) Cc: cnit@ietf.org, DISPATCH Subject: Re: [cnit] [stir] Application servers - Re: Call Center Implications X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 17:19:41 -0000 I think the issue is whether we think what is usually called =93contact=94= 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=92d probably want a request, rather than = automatic sending. I am very interested in working on improving caller name. Brian On Oct 31, 2013, at 8:49 AM, Richard Shockey wrote: >=20 > Brian please.. Look at the mail. I'm using the CNIT list. =20 >=20 > 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. >=20 > 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.=20 >=20 > CNAM as it is currently defined in SS7 is a terrible service. 15 = Character > ASCII. No support for International character sets the usual. >=20 > 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. >=20 > 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.=20 >=20 > 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. >=20 > I'm well aware of how CNAM is delivered in North America and I'm = equally > aware the CNAM business model is broken.=20 >=20 > 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.=20 >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Wednesday, October 30, 2013 5:39 PM > To: Richard Shockey > Cc: cnit@ietf.org > Subject: Re: [cnit] [stir] Application servers - Re: Call Center > Implications >=20 > More useful in what way? Improving the reliability of caller name? = Please > use the cnit list to discuss this. >=20 > 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. >=20 > 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. >=20 > Brian >=20 > On Oct 30, 2013, at 5:18 PM, Richard Shockey = wrote: >=20 >>=20 >> Ok since Brian is being picky.. >>=20 >> I'm actually interested if anyone is interested in the possibility of=20= >> making SIP Identity to the UA more useful. >>=20 >>=20 >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20= >> Of Richard Shockey >> Sent: Wednesday, October 30, 2013 3:05 PM >> To: stir@ietf.org >> Subject: Re: [stir] Application servers - Re: Call Center = Implications >>=20 >> Dan great post. I couldn't agree more. There needs to be some rules = here. >> Some may be regulatory some may be technical. >>=20 >> First the voice application service providers need to provide the=20 >> terminating CUA, "an accurate and truthful" Caller-ID for the call=20 >> 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=20= >> RESPORGS. >>=20 >> If the originating UA can prove/assert it is legally authorized to = use=20 >> such an identity on behalf of a customer then that is step one. The=20= >> presumption after that is there is some contractual obligation = between=20 >> the service provider and the network about the use of such = identities.=20 >> The network can then "validate" such an assertion. >>=20 >> There is something larger here to consider. Though the focus of STIR=20= >> 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. =20 >>=20 >> CNAM. That is NOT something STIR can do but I do believe there is an=20= >> emerging requirement that under some cases the calling party wants to=20= >> or should provide more substantive information about themselves to = the=20 >> called party and frankly 15 character ASCII is not enough. Consumers=20= >> or businesses should be able to see more complete and validated=20 >> information about the session in order to make an better and informed=20= >> decision on whether to accept the 'call' or not. Regulators may want=20= >> to require telemarketing firms to display NG CNAM or CNAM + like data=20= >> as a condition of doing business. >>=20 >> All of the examples you cite are excellent examples where such = verbose=20 >> calling party identification could be displayed. I certainly want to=20= >> answer a call from my doctor on my test results just as I wish to=20 >> ignore a call from Bill Clinton begging me to vote in the Virginia=20 >> Governors election next Tuesday. This is a case where annominity is = not a > good idea. >>=20 >>=20 >> All you need now is a little standardization. >> Technically this should is very easy to understand in SIP. It would=20= >> probably a reasonable modification of the Call INFO header in SIP = with=20 >> something like a XML based VCARD or JCARD URI whatever and probably=20= >> 3GPP would need to look at how such data is displayed on the mobile=20= >> VoLTE handsets. The network operators would have to understand not to=20= >> modify the contents of such a URI and its source validated but that = is=20 >> a task for another day. >>=20 >>=20 >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20= >> Of Dan York >> Sent: Tuesday, October 29, 2013 5:10 PM >> To: Brian Rosen; Cullen Jennings >> Cc: Gregory.Schumacher@sprint.com; Richard Shockey; stir@ietf.org;=20 >> Fernando Mousinho (fmousinh); Alex Bobotek; Michael Hammer; Henning=20= >> Schulzrinne >> Subject: [stir] Application servers - Re: Call Center Implications >>=20 >> Getting caught up on some of the STIR discussions, I'd just note that=20= >> when we talk about "call centers" or "BPOs" we also need to remember=20= >> that we're not only talking about "traditional" call centers but also=20= >> what I'll call "voice application service providers". They are=20 >> generally automated platforms running applications that a company = uses=20 >> for some kind of outbound service. Examples include: >>=20 >> - calling everyone in a school district with a weather-related=20 >> cancellation (or, unfortunately, a school shooting or similar event) >> - calling patients to provide reminders of appointments or=20 >> notifications of subscriptions available >> - calling customers to let them know that a package was delivered or=20= >> could be picked up, etc. >> - calling people scheduled for a flight to let know they are going to=20= >> be delayed >> - calling members of an organization with an automated survey about=20= >> current issues >> - performing a call-back to provide an additional layer of=20 >> authentication for some service >>=20 >> There is a large (and growing) market for these kind of automated=20 >> tools and services and the distinction between these calls and=20 >> "robocalls" is really only one of intent and the fact that the = recipient > has "opted in" >> through some kind of system. >>=20 >> Generally, though, many of the companies want the application to=20 >> appear as if it is coming from their own phone number in the same way=20= >> that they want an outbound call center to appear as if it is coming=20= >> from one of their own phone numbers. >>=20 >> You could think of these in the same way as "call centers", but I=20 >> point this out because some of these new services are very automated=20= >> and there are always new startups now emerging in this space. Some = of=20 >> them are very "self-service" where the customer does it all while=20 >> others have teams of people involved. Some of the companies involved=20= >> include Nuance, Microsoft Tellme, Voxeo (now Aspect, and also my=20 >> former employer), Tropo, Twilio, Convergys and many more[1]. >>=20 >> If STIR is to succeed, these kind of application platforms will also=20= >> need to be able to make calls on behalf of the companies using those > platforms. >>=20 >> Dan >>=20 >> [1] One report about this market: >> http://www.voxeo.com/pdf/OvumDecisionMatrix-2011.pdf >>=20 >>=20 >> -- >> Dan York >> Senior Content Strategist, Internet Society >> york@isoc.org +1-802-735-1624 >> Jabber: york@jabber.isoc.org >> Skype: danyork http://twitter.com/danyork >>=20 >> http://www.internetsociety.org/deploy360/ >>=20 >>=20 >>=20 >>=20 >> On 10/21/13 9:15 AM, "Brian Rosen" wrote: >>=20 >>> We really need to give each BPO different keys I think. The notion = that >>> we are sharing private keys among multiple competing entities who=20 >>> provide services for a single enterprise strikes me as a VBI (Very=20= >>> Bad Idea). I can't see any real difficulty in having more than one=20= >>> authorized entity, each with it's own credentials. Who would have a=20= >>> problem? We're already agreeing that there are multiple credentials=20= >>> for a number, because the number gets delegated multiple times. >>> Consider, just as an example, the BPO and the contracting enterprise=20= >>> that was actually delegated the number can both send calls from that=20= >>> number. You certainly don't want the enterprise giving out IT'S key=20= >>> to it's contractors. At best it's a key it authorizes to one or = more=20 >>> of it's >> BPOs. >>>=20 >>> Brian >>>=20 >>> On Oct 20, 2013, at 1:12 AM, Cullen Jennings (fluffy)=20 >>> >>> wrote: >>>=20 >>>>=20 >>>> What Fernando is saying makes sense to me a desirable property of=20= >>>> the solution and I agree that if we gave each BPO a different=20 >>>> private key that would solve it but that might be pretty hard to=20 >>>> mange in other ways. I like the requirements but the solution is = not=20 >>>> 100% obvious to me. >>>>=20 >>>>=20 >>>> On Oct 2, 2013, at 10:27 AM, Brian Rosen wrote: >>>>=20 >>>>> Sure. >>>>>=20 >>>>> Each BPO would have a different private/public key pair. >>>>>=20 >>>>> So you can trace which one placed the call. >>>>>=20 >>>>> Brian >>>>>=20 >>>>> On Oct 2, 2013, at 12:59 PM, Fernando Mousinho (fmousinh)=20 >>>>> wrote: >>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> If the company hires several BPOs and authorizes all of them to=20= >>>>>> sign calls on its behalf, is there a way to trace back the=20 >>>>>> originator (specific >>>>>> BPO) >>>>>> later on? I suppose that at some level the actual caller must be=20= >>>>>> exposed (perhaps to trace malicious activity, such as malicious=20= >>>>>> person infiltrated in an otherwise legitimate BPO). >>>>>>=20 >>>>>> Via headers would be the obvious pick, but they don't survive the=20= >>>>>> plethora of SBCs that the call is likely to transverse. Or maybe=20= >>>>>> the certs themselves can carry this type of data (actual caller=20= >>>>>> identity). >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 9/19/13 9:43 PM, "Brian Rosen" wrote: >>>>>>=20 >>>>>>> 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=20 >>>>>>> change to use =46rom (if signed maybe). It also doesn't fit = the=20 >>>>>>> definition of PAI. >>>>>>>=20 >>>>>>> Brian >>>>>>>=20 >>>>>>> On Sep 19, 2013, at 9:14 PM, Fernando Mousinho (fmousinh)=20 >>>>>>> wrote: >>>>>>>=20 >>>>>>>> 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=20= >>>>>>>> mentions. >>>>>>>> PAI's use is widespread, and it's main limitation is being=20 >>>>>>>> spoofable - but this is exactly the problem we are trying to=20= >>>>>>>> solve anyway. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> On Sep 19, 2013, at 5:39 PM, "Richard Shockey"=20 >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>> Excellent point a profile or BCP to complement the work. >>>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On=20= >>>>>>>>> Behalf Of Alex Bobotek >>>>>>>>> Sent: Thursday, September 19, 2013 5:27 PM >>>>>>>>> To: Henning Schulzrinne; Michael Hammer; fmousinh@cisco.com;=20= >>>>>>>>> Gregory.Schumacher@sprint.com; br@brianrosen.net >>>>>>>>> Cc: stir@ietf.org >>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>=20 >>>>>>>>> +1 >>>>>>>>> I've assumed that we are headed towards a "sign whatever = extras=20 >>>>>>>>> you wish, and indicate what your signature covers" mechanism. >>>>>>>>>=20 >>>>>>>>> Based on this, standards would need to identify only a minimal=20= >>>>>>>>> subset of what shall/should be signed, and ensure that any=20= >>>>>>>>> required group of signed items survives transit intact. >>>>>>>>>=20 >>>>>>>>> Best signing practices may be needed to complement the=20 >>>>>>>>> standard, and an appropriate place for all but the most basic=20= >>>>>>>>> 'what to sign' >>>>>>>>> recommendations. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Regards, >>>>>>>>>=20 >>>>>>>>> Alex >>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On=20= >>>>>>>>>> Behalf Of Henning Schulzrinne >>>>>>>>>> Sent: Thursday, September 19, 2013 2:24 PM >>>>>>>>>> To: Michael Hammer; fmousinh@cisco.com;=20 >>>>>>>>>> Gregory.Schumacher@sprint.com; br@brianrosen.net >>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>=20 >>>>>>>>>> I see no reason not to allow signing any number-related field=20= >>>>>>>>>> in the SIP request. (Signing may well be done by different >>>>>>>>>> parties.) >>>>>>>>>>=20 >>>>>>>>>> As far as I know, callback numbers (SIP Reply-To) aren't=20 >>>>>>>>>> conveyable in legacy systems, however, so this may be of=20 >>>>>>>>>> somewhat limited use for a >>>>>>>>> while. >>>>>>>>>>=20 >>>>>>>>>> ________________________________________ >>>>>>>>>> From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf=20= >>>>>>>>>> of Michael Hammer [michael.hammer@yaanatech.com] >>>>>>>>>> Sent: Thursday, September 19, 2013 4:34 PM >>>>>>>>>> To: fmousinh@cisco.com; Gregory.Schumacher@sprint.com;=20 >>>>>>>>>> br@brianrosen.net >>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>=20 >>>>>>>>>> Don't we still want to know the true originator of the call,=20= >>>>>>>>>> even when we have some token that says "Doctor so and so=20 >>>>>>>>>> approved this message." >>>>>>>>>>=20 >>>>>>>>>> Originating number, display number, and call-back number = could=20 >>>>>>>>>> be >>>>>>>>>> 3 >>>>>>>>>> different things. >>>>>>>>>> Should all of them be verifiable? >>>>>>>>>>=20 >>>>>>>>>> Mike >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On=20= >>>>>>>>>> Behalf Of Fernando Mousinho (fmousinh) >>>>>>>>>> Sent: Thursday, September 19, 2013 4:00 PM >>>>>>>>>> To: Schumacher, Gregory [CTO]; Brian Rosen >>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>=20 >>>>>>>>>> I believe the scenario telemarketing here is when a client=20 >>>>>>>>>> hires a BPO to place outbound calls, but expect customers = to=20 >>>>>>>>>> return these calls to a different place (say, their own and=20= >>>>>>>>>> operated call center). This way, this client is authorizing=20= >>>>>>>>>> the BPO to use an identity that it >>>>>>>>>> (BPO) >>>>>>>>> doesn't own. >>>>>>>>>> These numbers in this scenario are always operational, just = at=20 >>>>>>>>>> a different place. >>>>>>>>>>=20 >>>>>>>>>> The same telemarketing operator would then outpulse multiple=20= >>>>>>>>>> numbers for their multiple clients, none of these numbers=20 >>>>>>>>>> belonging to the >>>>>>>>> telemarketer. >>>>>>>>>> BTW, we are using the term "telemarketing" in a very generic=20= >>>>>>>>>> sense - this could just as easily be a public service=20 >>>>>>>>>> announcement, fundraiser, >>>>>>>>> etc. >>>>>>>>>>=20 >>>>>>>>>> If the telemarketer happens to own the inbound call center as=20= >>>>>>>>>> well, it very likely owns the number as well and this would=20= >>>>>>>>>> necessarily be a special case >>>>>>>>>> - it would fall under the same characteristics of any call = center. >>>>>>>>>>=20 >>>>>>>>>> On a different note, it would help a lot of we standardized=20= >>>>>>>>>> terminology. >>>>>>>>>> Telemarketing, BPO, call center, end customer, clients=8A it = may=20 >>>>>>>>>> be hard for others to follow the discussion later. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> (generic term for any type of outbound calling, including=20 >>>>>>>>>> public service announcement, so don't think it's all about >>>>>>>>>> sales!) >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On 9/19/13 3:22 PM, "Schumacher, Gregory [CTO]" >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>> There are some benefits from this approach, but also some=20 >>>>>>>>>>> scenarios that need clarification how they could function. >>>>>>>>>>>=20 >>>>>>>>>>> The benefit is that the credential represents both the=20 >>>>>>>>>>> company "responsible" for the sales campaign (the "company"=20= >>>>>>>>>>> in your >>>>>>>>>>> scenario) >>>>>>>>>>> and the company operating the sales campaign (the call = center=20 >>>>>>>>>>> in your scenario). For the use in forensics (after the=20 >>>>>>>>>>> fact >>>>>>>>>>> analysis) such as pursuit of fraud investigation, we then=20= >>>>>>>>>>> can follow both paths. >>>>>>>>>>>=20 >>>>>>>>>>> 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=20= >>>>>>>>>>> telemarketing campaign or both? >>>>>>>>>>>=20 >>>>>>>>>>> - How is the SP supposed to know all the parties that it is=20= >>>>>>>>>>> attesting to >>>>>>>>>>> - the responsible party and/or executing party? >>>>>>>>>>>=20 >>>>>>>>>>> -It seems likely that some of the numbers assigned to a=20 >>>>>>>>>>> company in your scenario will not be assigned to real=20 >>>>>>>>>>> telephones (or call center >>>>>>>>>>> trunk) until a telemarketing campaign is initiated or a call=20= >>>>>>>>>>> center selected to execute the sales campaign, is it=20 >>>>>>>>>>> possible to have these unassigned or floating numbers when=20= >>>>>>>>>>> not in use for a telemarketing campaign? Is it allowed=20 >>>>>>>>>>> under most national numbering regimes? >>>>>>>>>>>=20 >>>>>>>>>>> - How important is it to have a known or recognized phone=20 >>>>>>>>>>> number as the caller id as part of a telemarketing = campaign? >>>>>>>>>>> I am assuming that not all campaigns care about having a=20 >>>>>>>>>>> number that is known or >>>>>>>>> recognized. >>>>>>>>>>>=20 >>>>>>>>>>> -In other words for this last bit, if a call center=20 >>>>>>>>>>> (telemarketing campaign operator) is using their own set of=20= >>>>>>>>>>> numbers but serve multiple simultaneous telemarketing=20 >>>>>>>>>>> campaigns using the same originating numbers, what will = they=20 >>>>>>>>>>> sign? Will they just have a credential representing the=20 >>>>>>>>>>> call center alone, or a different credential per=20 >>>>>>>>>>> telemarketing campaign, or a different credential per =20 >>>>>>>>>>> responsible party (per client)? This will affect what is=20 >>>>>>>>>>> possible for >>>>>>>>> any forensic activity. >>>>>>>>>>>=20 >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] = On=20 >>>>>>>>>>> Behalf Of Brian Rosen >>>>>>>>>>> Sent: Tuesday, September 17, 2013 9:44 AM >>>>>>>>>>> To: Fernando Mousinho >>>>>>>>>>> Cc: stir@ietf.org; Hadriel Kaplan >>>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>>=20 >>>>>>>>>>> We have a requirement to support the BPO use case. >>>>>>>>>>>=20 >>>>>>>>>>> The notion we had is that the company contracting the call=20= >>>>>>>>>>> center approves the use, and the call center, or the SP=20 >>>>>>>>>>> acting on its behalf, signs. >>>>>>>>>>> Think of this as another level of delegation. An SP=20 >>>>>>>>>>> delegates numbers to the company. The company "delegates"=20= >>>>>>>>>>> use of those numbers to the call center. The call center=20= >>>>>>>>>>> calls, using that delegation. >>>>>>>>>>> The credentials of the call center would be different from=20= >>>>>>>>>>> those of the company, but would cover the same number. =20 >>>>>>>>>>> Having multiple credentials covering the same number will = be=20 >>>>>>>>>>> very common due to the way delegation happens. In order to=20= >>>>>>>>>>> allow SPs to sign, without creating credential per TN, we=20= >>>>>>>>>>> allow credentials with ranges. >>>>>>>>>>> The >>>>>>>>>>> ranges could overlap when delegation happens. >>>>>>>>>>>=20 >>>>>>>>>>> Consider the following complex US case: >>>>>>>>>>> The North American Number Plan Administrator delegates=20 >>>>>>>>>>> 202-555-xxxx to the Pooling Administrator. The PA now has = a=20 >>>>>>>>>>> credential covering the entire 10K block. >>>>>>>>>>> The Pooling Administrator delegates 202-555-1xxx to SP A. = SP=20 >>>>>>>>>>> A has a credential for the entire 1K block SP A resells=20 >>>>>>>>>>> 202-555-12xx to SP B . >>>>>>>>>>> SP B has a credential for a 100 TN block SP B delegates=20 >>>>>>>>>>> 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. = =20 >>>>>>>>>>> BPO D has credential for a 1 number block >>>>>>>>>>>=20 >>>>>>>>>>> NANPA and the PA never are in a call path, so they would=20 >>>>>>>>>>> never sign a call. >>>>>>>>>>>=20 >>>>>>>>>>> However, SP A or SP B could sign a call from either Company = C=20 >>>>>>>>>>> or BPO D using the credential they have. >>>>>>>>>>>=20 >>>>>>>>>>> The SP for the call center could acquire credentials from = the=20 >>>>>>>>>>> BPO and sign on its behalf. I suspect than many service=20= >>>>>>>>>>> providers would be reluctant to do so unless the numbers=20 >>>>>>>>>>> were from their own inventory (that is, the company got its=20= >>>>>>>>>>> numbers from the same SP as the call >>>>>>>>> center). >>>>>>>>>>> Since that won't be the common case, the call center = probably=20 >>>>>>>>>>> has to do the signing itself. >>>>>>>>>>>=20 >>>>>>>>>>> Brian >>>>>>>>>>>=20 >>>>>>>>>>> On Sep 17, 2013, at 8:46 AM, Fernando Mousinho (fmousinh)=20 >>>>>>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> I agree, Hadriel. While large call centers (including BPOs,=20= >>>>>>>>>>>> which provide services for other companies) may have=20 >>>>>>>>>>>> special arrangements with SPs, the majority (small to=20 >>>>>>>>>>>> mid-size) will probably rely on the SPs to do provide to=20= >>>>>>>>>>>> vouch for their identity. This would probably be the case=20= >>>>>>>>>>>> for the home analog caller anyway. This would imply that=20= >>>>>>>>>>>> the "originating" SP's willingness to provide this =20 >>>>>>>>>>>> signature is a critical success factor for the proposal's > adoption. >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> But back to the business process outsourcers (BPO) case -=20= >>>>>>>>>>>> where a call center is providing service on behalf of=20 >>>>>>>>>>>> multiple companies. I can see the value of them sending=20 >>>>>>>>>>>> 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=20= >>>>>>>>>>>> that SP >>>>>>>>>>>> 1 allowing one of its subscribers to send an outbound call=20= >>>>>>>>>>>> using a number registered to SP 2 could be a no-no. If = this=20 >>>>>>>>>>>> hypothesis is correct, then we are back to the case where=20= >>>>>>>>>>>> the SP is signing all calls, >>>>>>>>>> even for BPOs. >>>>>>>>>>>>=20 >>>>>>>>>>>> Or maybe this is another problem we are trying to fix in = the=20 >>>>>>>>>>>> working group, in which case we perhaps should state as a=20= >>>>>>>>>>>> goal or >>>>>>>>> benefit: >>>>>>>>>>>> "providing a reliable mechanism to let calls originated = from=20 >>>>>>>>>>>> one >>>>>>>>>>>> SP1 to outpulse numbers that belong to another". >>>>>>>>>>>>=20 >>>>>>>>>>>> Fernando >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> On 9/16/13 12:12 PM, "Hadriel Kaplan" >>>>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Any of them could do it. My guess is service providers=20 >>>>>>>>>>>>> will do it for most call centers, although larger call=20 >>>>>>>>>>>>> centers might do it themselves... >>>>>>>>>>>>> especially ones which have trunks from multiple providers=20= >>>>>>>>>>>>> and can source calls using the same number(s) out through=20= >>>>>>>>>>>>> multiple providers on a call-by-call basis. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> -hadriel >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Sep 16, 2013, at 9:49 AM, Fernando Mousinho (fmousinh)=20= >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I'm catching up with the discussions in this working=20 >>>>>>>>>>>>>> group, and am trying to understand some architecture=20 >>>>>>>>>>>>>> implications in call centers (which is where my=20 >>>>>>>>>>>>>> background is). It seems that many of the problems we = are=20 >>>>>>>>>>>>>> trying to fix are related to contact centers anyway, so=20= >>>>>>>>>>>>>> it is probably a good idea to have everyone in the same >>>>>>>>>> page. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Forgive me if it is an obvious question, but which=20 >>>>>>>>>>>>>> components in a "typical call center architecture" do = you=20 >>>>>>>>>>>>>> see signature and verification taking place? Such = "typical" >>>>>>>>>>>>>> deployments have premises based equipment (PME), a=20 >>>>>>>>>>>>>> session border controller >>>>>>>>>>>>>> (SBC) >>>>>>>>>>>>>> and of course a SIP service provider all three could=20 >>>>>>>>>>>>>> potentially be used throughout the authorization = process. >>>>>>>>>>>>>> There are different ramifications depending on where = your=20 >>>>>>>>>>>>>> mind is at. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Fernando Mousinho >>>>>>>>>>>>>> Cisco Systems >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> stir mailing list >>>>>>>>>>>> stir@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> stir mailing list >>>>>>>>>>> stir@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> ________________________________ >>>>>>>>>>>=20 >>>>>>>>>>> This e-mail may contain Sprint proprietary information=20 >>>>>>>>>>> intended for the sole use of the recipient(s). Any use by=20= >>>>>>>>>>> others is prohibited. >>>>>>>>>>> If >>>>>>>>>>> you are not the intended recipient, please contact the = sender=20 >>>>>>>>>>> and delete all copies of the message. >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> stir mailing list >>>>>>>>>>> stir@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> stir mailing list >>>>>>>>>> stir@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>> _______________________________________________ >>>>>>>>>> stir mailing list >>>>>>>>>> stir@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>> _______________________________________________ >>>>>>>>> stir mailing list >>>>>>>>> stir@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> stir mailing list >>>>> stir@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/stir >>>>=20 >>>=20 >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> cnit mailing list >> cnit@ietf.org >> https://www.ietf.org/mailman/listinfo/cnit >=20 From Henning.Schulzrinne@fcc.gov Thu Oct 31 10:37:34 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFF1D11E822D; Thu, 31 Oct 2013 10:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[AWL=-1.450, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, MANGLED_COMPNY=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5KOptAL-Ap3E; Thu, 31 Oct 2013 10:37:27 -0700 (PDT) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id B5D1911E8231; Thu, 31 Oct 2013 10:37:10 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: 'Brian Rosen' , Richard Shockey Thread-Topic: [dispatch] [cnit] [stir] Application servers - Re: Call Center Implications Thread-Index: AQHO1lxcjDutnFkddUaRrL0uS5DUkpoPUQuA///BJaA= Date: Thu, 31 Oct 2013 17:37:03 +0000 References: <32C55AFE-FA17-4776-AD91-259AD3E226BE@brianrosen.net> <024001ced5a2$f3268810$d9739830$@shockey.us> <029501ced5b5$8fa9f480$aefddd80$@shockey.us> <2AA32171-1AE3-4AEE-AEDC-B2031562B7BD@brianrosen.net> <00d901ced637$9e8143a0$db83cae0$@shockey.us> <8B0027B8-D777-48F3-B5BF-B8F81F038E37@brianrosen.net> In-Reply-To: <8B0027B8-D777-48F3-B5BF-B8F81F038E37@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cnit@ietf.org" , DISPATCH Subject: Re: [cnit] [dispatch] [stir] Application servers - Re: Call Center Implications X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 17:37:34 -0000 Call-info: ;purpose=3Dcard or purpose=3Dinfo would seem to address part of that need. Obviously, there has to be a crypt= ographic 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: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Brian Rosen Sent: Thursday, October 31, 2013 1:19 PM To: Richard Shockey Cc: cnit@ietf.org; 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" info= rmation is reasonable to send on every call. I do think if we were to do anything like that, we would do it with xCard a= nd 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 automati= c sending. I am very interested in working on improving caller name. Brian On Oct 31, 2013, at 8:49 AM, Richard Shockey wrote: >=20 > Brian please.. Look at the mail. I'm using the CNIT list. =20 >=20 > The issue is can we use the tools at hand to increase both the=20 > accuracy, reliability and the amount of data that is delivered to the=20 > CUA over who is attempting to establish a session. >=20 > The larger issue is the integrity of the entire real time=20 > communications system as it moves to an all IP world. Irrespective if=20 > CNAM it is delivered as part of From: or PAI its not very useful to the c= onsumer. >=20 > CNAM as it is currently defined in SS7 is a terrible service. 15=20 > Character ASCII. No support for International character sets the usual. >=20 > It is not a hard stretch to postulate that called parties might like a=20 > richer set of data displayed on their UA's and that can be delivered=20 > by the SIP headers in some relatively simple form. Modification of the=20 > Call-Info header for instance. It is equally not a stretch to think=20 > that National Regulators would be delighted with consumers having a=20 > richer set of information displayed on their handsets in order to make=20 > more decisions. In addition if we can achieve better all IP to IP=20 > interconnection among providers it would be really really useful if=20 > Enterprise systems could extract more data from their internal=20 > directory systems and pass that along in the new format for enterprise c= alling as well. >=20 > I would certainly argue that we are not going to see ubiquitous Point=20 > to Point video calling using WebRTC or SIP if there is not better=20 > display of calling party information. >=20 > In addition network operators could insert other 'hints' as to the=20 > nature of the session based on its ability to validate the Caller ID=20 > or other forms on analysis. >=20 > I'm well aware of how CNAM is delivered in North America and I'm=20 > equally aware the CNAM business model is broken. >=20 > What I'd like to know is what interest there is in this proposition=20 > and are there parties interested in working on it in advance of say Londo= n. >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, October 30, 2013 5:39 PM > To: Richard Shockey > Cc: cnit@ietf.org > Subject: Re: [cnit] [stir] Application servers - Re: Call Center=20 > Implications >=20 > More useful in what way? Improving the reliability of caller name? =20 > Please use the cnit list to discuss this. >=20 > On that list, the current direction seems to be using the display name=20 > part of the uri to carry a caller name, which is put on the call by=20 > the origination side, and signed as the number is. >=20 > That is a significant change to the current infrastructure, which at=20 > least in North America relies on a termination service provider dip in=20 > an origination service provider database, but it seems feasible to=20 > consider that. >=20 > Brian >=20 > On Oct 30, 2013, at 5:18 PM, Richard Shockey wrote: >=20 >>=20 >> Ok since Brian is being picky.. >>=20 >> I'm actually interested if anyone is interested in the possibility of=20 >> making SIP Identity to the UA more useful. >>=20 >>=20 >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >> Of Richard Shockey >> Sent: Wednesday, October 30, 2013 3:05 PM >> To: stir@ietf.org >> Subject: Re: [stir] Application servers - Re: Call Center=20 >> Implications >>=20 >> Dan great post. I couldn't agree more. There needs to be some rules her= e. >> Some may be regulatory some may be technical. >>=20 >> First the voice application service providers need to provide the=20 >> terminating CUA, "an accurate and truthful" Caller-ID for the call=20 >> even if it is originated from a source that is not directly=20 >> 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=20 >> RESPORGS. >>=20 >> If the originating UA can prove/assert it is legally authorized to=20 >> use such an identity on behalf of a customer then that is step one. =20 >> The presumption after that is there is some contractual obligation=20 >> between the service provider and the network about the use of such ident= ities. >> The network can then "validate" such an assertion. >>=20 >> There is something larger here to consider. Though the focus of STIR=20 >> is validation of a Caller-ID number at some point the RAI area should=20 >> take > a >> look at the other side of the coin so to speak. =20 >>=20 >> CNAM. That is NOT something STIR can do but I do believe there is an=20 >> emerging requirement that under some cases the calling party wants to=20 >> or should provide more substantive information about themselves to=20 >> the called party and frankly 15 character ASCII is not enough.=20 >> Consumers or businesses should be able to see more complete and=20 >> validated information about the session in order to make an better=20 >> and informed decision on whether to accept the 'call' or not. =20 >> Regulators may want to require telemarketing firms to display NG CNAM=20 >> or CNAM + like data as a condition of doing business. >>=20 >> All of the examples you cite are excellent examples where such=20 >> verbose calling party identification could be displayed. I certainly=20 >> want to answer a call from my doctor on my test results just as I=20 >> wish to ignore a call from Bill Clinton begging me to vote in the=20 >> Virginia Governors election next Tuesday. This is a case where=20 >> annominity is not a > good idea. >>=20 >>=20 >> All you need now is a little standardization. >> Technically this should is very easy to understand in SIP. It would=20 >> probably a reasonable modification of the Call INFO header in SIP=20 >> with something like a XML based VCARD or JCARD URI whatever and=20 >> probably 3GPP would need to look at how such data is displayed on the=20 >> mobile VoLTE handsets. The network operators would have to understand=20 >> not to modify the contents of such a URI and its source validated but=20 >> that is a task for another day. >>=20 >>=20 >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >> Of Dan York >> Sent: Tuesday, October 29, 2013 5:10 PM >> To: Brian Rosen; Cullen Jennings >> Cc: Gregory.Schumacher@sprint.com; Richard Shockey; stir@ietf.org;=20 >> Fernando Mousinho (fmousinh); Alex Bobotek; Michael Hammer; Henning=20 >> Schulzrinne >> Subject: [stir] Application servers - Re: Call Center Implications >>=20 >> Getting caught up on some of the STIR discussions, I'd just note that=20 >> when we talk about "call centers" or "BPOs" we also need to remember=20 >> that we're not only talking about "traditional" call centers but also=20 >> what I'll call "voice application service providers". They are=20 >> generally automated platforms running applications that a company=20 >> uses for some kind of outbound service. Examples include: >>=20 >> - calling everyone in a school district with a weather-related=20 >> cancellation (or, unfortunately, a school shooting or similar event) >> - calling patients to provide reminders of appointments or=20 >> notifications of subscriptions available >> - calling customers to let them know that a package was delivered or=20 >> could be picked up, etc. >> - calling people scheduled for a flight to let know they are going to=20 >> be delayed >> - calling members of an organization with an automated survey about=20 >> current issues >> - performing a call-back to provide an additional layer of=20 >> authentication for some service >>=20 >> There is a large (and growing) market for these kind of automated=20 >> tools and services and the distinction between these calls and=20 >> "robocalls" is really only one of intent and the fact that the=20 >> recipient > has "opted in" >> through some kind of system. >>=20 >> Generally, though, many of the companies want the application to=20 >> appear as if it is coming from their own phone number in the same way=20 >> that they want an outbound call center to appear as if it is coming=20 >> from one of their own phone numbers. >>=20 >> You could think of these in the same way as "call centers", but I=20 >> point this out because some of these new services are very automated=20 >> and there are always new startups now emerging in this space. Some=20 >> of them are very "self-service" where the customer does it all while=20 >> others have teams of people involved. Some of the companies involved=20 >> include Nuance, Microsoft Tellme, Voxeo (now Aspect, and also my=20 >> former employer), Tropo, Twilio, Convergys and many more[1]. >>=20 >> If STIR is to succeed, these kind of application platforms will also=20 >> need to be able to make calls on behalf of the companies using those > platforms. >>=20 >> Dan >>=20 >> [1] One report about this market: >> http://www.voxeo.com/pdf/OvumDecisionMatrix-2011.pdf >>=20 >>=20 >> -- >> Dan York >> Senior Content Strategist, Internet Society >> york@isoc.org +1-802-735-1624 >> Jabber: york@jabber.isoc.org >> Skype: danyork http://twitter.com/danyork >>=20 >> http://www.internetsociety.org/deploy360/ >>=20 >>=20 >>=20 >>=20 >> On 10/21/13 9:15 AM, "Brian Rosen" wrote: >>=20 >>> We really need to give each BPO different keys I think. The notion th= at >>> we are sharing private keys among multiple competing entities who=20 >>> provide services for a single enterprise strikes me as a VBI (Very=20 >>> Bad Idea). I can't see any real difficulty in having more than one=20 >>> authorized entity, each with it's own credentials. Who would have a=20 >>> problem? We're already agreeing that there are multiple credentials=20 >>> for a number, because the number gets delegated multiple times. >>> Consider, just as an example, the BPO and the contracting enterprise=20 >>> that was actually delegated the number can both send calls from that=20 >>> number. You certainly don't want the enterprise giving out IT'S key=20 >>> to it's contractors. At best it's a key it authorizes to one or=20 >>> more of it's >> BPOs. >>>=20 >>> Brian >>>=20 >>> On Oct 20, 2013, at 1:12 AM, Cullen Jennings (fluffy)=20 >>> >>> wrote: >>>=20 >>>>=20 >>>> What Fernando is saying makes sense to me a desirable property of=20 >>>> the solution and I agree that if we gave each BPO a different=20 >>>> private key that would solve it but that might be pretty hard to=20 >>>> mange in other ways. I like the requirements but the solution is=20 >>>> not 100% obvious to me. >>>>=20 >>>>=20 >>>> On Oct 2, 2013, at 10:27 AM, Brian Rosen wrote: >>>>=20 >>>>> Sure. >>>>>=20 >>>>> Each BPO would have a different private/public key pair. >>>>>=20 >>>>> So you can trace which one placed the call. >>>>>=20 >>>>> Brian >>>>>=20 >>>>> On Oct 2, 2013, at 12:59 PM, Fernando Mousinho (fmousinh)=20 >>>>> wrote: >>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> If the company hires several BPOs and authorizes all of them to=20 >>>>>> sign calls on its behalf, is there a way to trace back the=20 >>>>>> originator (specific >>>>>> BPO) >>>>>> later on? I suppose that at some level the actual caller must be=20 >>>>>> exposed (perhaps to trace malicious activity, such as malicious=20 >>>>>> person infiltrated in an otherwise legitimate BPO). >>>>>>=20 >>>>>> Via headers would be the obvious pick, but they don't survive the=20 >>>>>> plethora of SBCs that the call is likely to transverse. Or maybe=20 >>>>>> the certs themselves can carry this type of data (actual caller=20 >>>>>> identity). >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 9/19/13 9:43 PM, "Brian Rosen" wrote: >>>>>>=20 >>>>>>> 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=20 >>>>>>> change to use From (if signed maybe). It also doesn't fit the=20 >>>>>>> definition of PAI. >>>>>>>=20 >>>>>>> Brian >>>>>>>=20 >>>>>>> On Sep 19, 2013, at 9:14 PM, Fernando Mousinho (fmousinh)=20 >>>>>>> wrote: >>>>>>>=20 >>>>>>>> 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=20 >>>>>>>> on the delegation process Rosen mentions. >>>>>>>> PAI's use is widespread, and it's main limitation is being=20 >>>>>>>> spoofable - but this is exactly the problem we are trying to=20 >>>>>>>> solve anyway. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> On Sep 19, 2013, at 5:39 PM, "Richard Shockey"=20 >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>> Excellent point a profile or BCP to complement the work. >>>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On=20 >>>>>>>>> Behalf Of Alex Bobotek >>>>>>>>> Sent: Thursday, September 19, 2013 5:27 PM >>>>>>>>> To: Henning Schulzrinne; Michael Hammer; fmousinh@cisco.com;=20 >>>>>>>>> Gregory.Schumacher@sprint.com; br@brianrosen.net >>>>>>>>> Cc: stir@ietf.org >>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>=20 >>>>>>>>> +1 >>>>>>>>> I've assumed that we are headed towards a "sign whatever=20 >>>>>>>>> extras you wish, and indicate what your signature covers" mechani= sm. >>>>>>>>>=20 >>>>>>>>> Based on this, standards would need to identify only a minimal=20 >>>>>>>>> subset of what shall/should be signed, and ensure that any=20 >>>>>>>>> required group of signed items survives transit intact. >>>>>>>>>=20 >>>>>>>>> Best signing practices may be needed to complement the=20 >>>>>>>>> standard, and an appropriate place for all but the most basic=20 >>>>>>>>> 'what to sign' >>>>>>>>> recommendations. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Regards, >>>>>>>>>=20 >>>>>>>>> Alex >>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On=20 >>>>>>>>>> Behalf Of Henning Schulzrinne >>>>>>>>>> Sent: Thursday, September 19, 2013 2:24 PM >>>>>>>>>> To: Michael Hammer; fmousinh@cisco.com;=20 >>>>>>>>>> Gregory.Schumacher@sprint.com; br@brianrosen.net >>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>=20 >>>>>>>>>> I see no reason not to allow signing any number-related field=20 >>>>>>>>>> in the SIP request. (Signing may well be done by different >>>>>>>>>> parties.) >>>>>>>>>>=20 >>>>>>>>>> As far as I know, callback numbers (SIP Reply-To) aren't=20 >>>>>>>>>> conveyable in legacy systems, however, so this may be of=20 >>>>>>>>>> somewhat limited use for a >>>>>>>>> while. >>>>>>>>>>=20 >>>>>>>>>> ________________________________________ >>>>>>>>>> From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf=20 >>>>>>>>>> of Michael Hammer [michael.hammer@yaanatech.com] >>>>>>>>>> Sent: Thursday, September 19, 2013 4:34 PM >>>>>>>>>> To: fmousinh@cisco.com; Gregory.Schumacher@sprint.com;=20 >>>>>>>>>> br@brianrosen.net >>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>=20 >>>>>>>>>> Don't we still want to know the true originator of the call,=20 >>>>>>>>>> even when we have some token that says "Doctor so and so=20 >>>>>>>>>> approved this message." >>>>>>>>>>=20 >>>>>>>>>> Originating number, display number, and call-back number=20 >>>>>>>>>> could be >>>>>>>>>> 3 >>>>>>>>>> different things. >>>>>>>>>> Should all of them be verifiable? >>>>>>>>>>=20 >>>>>>>>>> Mike >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On=20 >>>>>>>>>> Behalf Of Fernando Mousinho (fmousinh) >>>>>>>>>> Sent: Thursday, September 19, 2013 4:00 PM >>>>>>>>>> To: Schumacher, Gregory [CTO]; Brian Rosen >>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>=20 >>>>>>>>>> I believe the scenario telemarketing here is when a client=20 >>>>>>>>>> hires a BPO to place outbound calls, but expect customers=20 >>>>>>>>>> to return these calls to a different place (say, their own=20 >>>>>>>>>> and operated call center). This way, this client is=20 >>>>>>>>>> authorizing the BPO to use an identity that it >>>>>>>>>> (BPO) >>>>>>>>> doesn't own. >>>>>>>>>> These numbers in this scenario are always operational, just=20 >>>>>>>>>> at a different place. >>>>>>>>>>=20 >>>>>>>>>> The same telemarketing operator would then outpulse multiple=20 >>>>>>>>>> numbers for their multiple clients, none of these numbers=20 >>>>>>>>>> belonging to the >>>>>>>>> telemarketer. >>>>>>>>>> BTW, we are using the term "telemarketing" in a very generic=20 >>>>>>>>>> sense - this could just as easily be a public service=20 >>>>>>>>>> announcement, fundraiser, >>>>>>>>> etc. >>>>>>>>>>=20 >>>>>>>>>> If the telemarketer happens to own the inbound call center as=20 >>>>>>>>>> well, it very likely owns the number as well and this would=20 >>>>>>>>>> necessarily be a special case >>>>>>>>>> - it would fall under the same characteristics of any call cente= r. >>>>>>>>>>=20 >>>>>>>>>> On a different note, it would help a lot of we standardized=20 >>>>>>>>>> terminology. >>>>>>>>>> Telemarketing, BPO, call center, end customer, clients=A9 it=20 >>>>>>>>>> may be hard for others to follow the discussion later. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> (generic term for any type of outbound calling, including=20 >>>>>>>>>> public service announcement, so don't think it's all about >>>>>>>>>> sales!) >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On 9/19/13 3:22 PM, "Schumacher, Gregory [CTO]" >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>> There are some benefits from this approach, but also some=20 >>>>>>>>>>> scenarios that need clarification how they could function. >>>>>>>>>>>=20 >>>>>>>>>>> The benefit is that the credential represents both the=20 >>>>>>>>>>> company "responsible" for the sales campaign (the "company" >>>>>>>>>>> in your >>>>>>>>>>> scenario) >>>>>>>>>>> and the company operating the sales campaign (the call=20 >>>>>>>>>>> center in your scenario). For the use in forensics (after=20 >>>>>>>>>>> the fact >>>>>>>>>>> analysis) such as pursuit of fraud investigation, we then=20 >>>>>>>>>>> can follow both paths. >>>>>>>>>>>=20 >>>>>>>>>>> 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=20 >>>>>>>>>>> telemarketing campaign or both? >>>>>>>>>>>=20 >>>>>>>>>>> - How is the SP supposed to know all the parties that it is=20 >>>>>>>>>>> attesting to >>>>>>>>>>> - the responsible party and/or executing party? >>>>>>>>>>>=20 >>>>>>>>>>> -It seems likely that some of the numbers assigned to a=20 >>>>>>>>>>> company in your scenario will not be assigned to real=20 >>>>>>>>>>> telephones (or call center >>>>>>>>>>> trunk) until a telemarketing campaign is initiated or a call=20 >>>>>>>>>>> center selected to execute the sales campaign, is it=20 >>>>>>>>>>> possible to have these unassigned or floating numbers when=20 >>>>>>>>>>> not in use for a telemarketing campaign? Is it allowed=20 >>>>>>>>>>> under most national numbering regimes? >>>>>>>>>>>=20 >>>>>>>>>>> - How important is it to have a known or recognized phone=20 >>>>>>>>>>> number as the caller id as part of a telemarketing campaign? >>>>>>>>>>> I am assuming that not all campaigns care about having a=20 >>>>>>>>>>> number that is known or >>>>>>>>> recognized. >>>>>>>>>>>=20 >>>>>>>>>>> -In other words for this last bit, if a call center=20 >>>>>>>>>>> (telemarketing campaign operator) is using their own set of=20 >>>>>>>>>>> numbers but serve multiple simultaneous telemarketing=20 >>>>>>>>>>> campaigns using the same originating numbers, what will=20 >>>>>>>>>>> they sign? Will they just have a credential representing=20 >>>>>>>>>>> the call center alone, or a different credential per=20 >>>>>>>>>>> telemarketing campaign, or a different credential per=20 >>>>>>>>>>> responsible party (per client)? This will affect what is=20 >>>>>>>>>>> possible for >>>>>>>>> any forensic activity. >>>>>>>>>>>=20 >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org]=20 >>>>>>>>>>> On Behalf Of Brian Rosen >>>>>>>>>>> Sent: Tuesday, September 17, 2013 9:44 AM >>>>>>>>>>> To: Fernando Mousinho >>>>>>>>>>> Cc: stir@ietf.org; Hadriel Kaplan >>>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>>=20 >>>>>>>>>>> We have a requirement to support the BPO use case. >>>>>>>>>>>=20 >>>>>>>>>>> The notion we had is that the company contracting the call=20 >>>>>>>>>>> center approves the use, and the call center, or the SP=20 >>>>>>>>>>> acting on its behalf, signs. >>>>>>>>>>> Think of this as another level of delegation. An SP=20 >>>>>>>>>>> delegates numbers to the company. The company "delegates" >>>>>>>>>>> use of those numbers to the call center. The call center=20 >>>>>>>>>>> calls, using that delegation. >>>>>>>>>>> The credentials of the call center would be different from=20 >>>>>>>>>>> those of the company, but would cover the same number. >>>>>>>>>>> Having multiple credentials covering the same number will=20 >>>>>>>>>>> be very common due to the way delegation happens. In order=20 >>>>>>>>>>> to allow SPs to sign, without creating credential per TN,=20 >>>>>>>>>>> we allow credentials with ranges. >>>>>>>>>>> The >>>>>>>>>>> ranges could overlap when delegation happens. >>>>>>>>>>>=20 >>>>>>>>>>> Consider the following complex US case: >>>>>>>>>>> The North American Number Plan Administrator delegates=20 >>>>>>>>>>> 202-555-xxxx to the Pooling Administrator. The PA now has=20 >>>>>>>>>>> a credential covering the entire 10K block. >>>>>>>>>>> The Pooling Administrator delegates 202-555-1xxx to SP A. =20 >>>>>>>>>>> SP A has a credential for the entire 1K block SP A resells=20 >>>>>>>>>>> 202-555-12xx to SP B . >>>>>>>>>>> SP B has a credential for a 100 TN block SP B delegates=20 >>>>>>>>>>> 202-555-123x to Company C. Company C has a credential for=20 >>>>>>>>>>> a >>>>>>>>>>> 10 number block Company C authorizes 202-555-1234 to BPO D. =20 >>>>>>>>>>> BPO D has credential for a 1 number block >>>>>>>>>>>=20 >>>>>>>>>>> NANPA and the PA never are in a call path, so they would=20 >>>>>>>>>>> never sign a call. >>>>>>>>>>>=20 >>>>>>>>>>> However, SP A or SP B could sign a call from either Company=20 >>>>>>>>>>> C or BPO D using the credential they have. >>>>>>>>>>>=20 >>>>>>>>>>> The SP for the call center could acquire credentials from=20 >>>>>>>>>>> the BPO and sign on its behalf. I suspect than many=20 >>>>>>>>>>> service providers would be reluctant to do so unless the=20 >>>>>>>>>>> numbers were from their own inventory (that is, the company=20 >>>>>>>>>>> got its numbers from the same SP as the call >>>>>>>>> center). >>>>>>>>>>> Since that won't be the common case, the call center=20 >>>>>>>>>>> probably has to do the signing itself. >>>>>>>>>>>=20 >>>>>>>>>>> Brian >>>>>>>>>>>=20 >>>>>>>>>>> On Sep 17, 2013, at 8:46 AM, Fernando Mousinho (fmousinh)=20 >>>>>>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> I agree, Hadriel. While large call centers (including BPOs,=20 >>>>>>>>>>>> which provide services for other companies) may have=20 >>>>>>>>>>>> special arrangements with SPs, the majority (small to >>>>>>>>>>>> mid-size) will probably rely on the SPs to do provide to=20 >>>>>>>>>>>> vouch for their identity. This would probably be the case=20 >>>>>>>>>>>> for the home analog caller anyway. This would imply that=20 >>>>>>>>>>>> the "originating" SP's willingness to provide this=20 >>>>>>>>>>>> signature is a critical success factor for the proposal's > adoption. >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> But back to the business process outsourcers (BPO) case -=20 >>>>>>>>>>>> where a call center is providing service on behalf of=20 >>>>>>>>>>>> multiple companies. I can see the value of them sending=20 >>>>>>>>>>>> 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=20 >>>>>>>>>>>> that SP >>>>>>>>>>>> 1 allowing one of its subscribers to send an outbound call=20 >>>>>>>>>>>> using a number registered to SP 2 could be a no-no. If=20 >>>>>>>>>>>> this hypothesis is correct, then we are back to the case=20 >>>>>>>>>>>> where the SP is signing all calls, >>>>>>>>>> even for BPOs. >>>>>>>>>>>>=20 >>>>>>>>>>>> Or maybe this is another problem we are trying to fix in=20 >>>>>>>>>>>> the working group, in which case we perhaps should state as=20 >>>>>>>>>>>> a goal or >>>>>>>>> benefit: >>>>>>>>>>>> "providing a reliable mechanism to let calls originated=20 >>>>>>>>>>>> from one >>>>>>>>>>>> SP1 to outpulse numbers that belong to another". >>>>>>>>>>>>=20 >>>>>>>>>>>> Fernando >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> On 9/16/13 12:12 PM, "Hadriel Kaplan" >>>>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Any of them could do it. My guess is service providers=20 >>>>>>>>>>>>> will do it for most call centers, although larger call=20 >>>>>>>>>>>>> centers might do it themselves... >>>>>>>>>>>>> especially ones which have trunks from multiple providers=20 >>>>>>>>>>>>> and can source calls using the same number(s) out through=20 >>>>>>>>>>>>> multiple providers on a call-by-call basis. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> -hadriel >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Sep 16, 2013, at 9:49 AM, Fernando Mousinho (fmousinh)=20 >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I'm catching up with the discussions in this working=20 >>>>>>>>>>>>>> group, and am trying to understand some architecture=20 >>>>>>>>>>>>>> implications in call centers (which is where my=20 >>>>>>>>>>>>>> background is). It seems that many of the problems we=20 >>>>>>>>>>>>>> are trying to fix are related to contact centers anyway,=20 >>>>>>>>>>>>>> so it is probably a good idea to have everyone in the =20 >>>>>>>>>>>>>> same >>>>>>>>>> page. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Forgive me if it is an obvious question, but which=20 >>>>>>>>>>>>>> components in a "typical call center architecture" do=20 >>>>>>>>>>>>>> you see signature and verification taking place? Such "typi= cal" >>>>>>>>>>>>>> deployments have premises based equipment (PME), a=20 >>>>>>>>>>>>>> session border controller >>>>>>>>>>>>>> (SBC) >>>>>>>>>>>>>> and of course a SIP service provider all three could=20 >>>>>>>>>>>>>> potentially be used throughout the authorization process. >>>>>>>>>>>>>> There are different ramifications depending on where=20 >>>>>>>>>>>>>> your mind is at. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Fernando Mousinho >>>>>>>>>>>>>> Cisco Systems >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> stir mailing list >>>>>>>>>>>> stir@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> stir mailing list >>>>>>>>>>> stir@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> ________________________________ >>>>>>>>>>>=20 >>>>>>>>>>> This e-mail may contain Sprint proprietary information=20 >>>>>>>>>>> intended for the sole use of the recipient(s). Any use by=20 >>>>>>>>>>> others is prohibited. >>>>>>>>>>> If >>>>>>>>>>> you are not the intended recipient, please contact the=20 >>>>>>>>>>> sender and delete all copies of the message. >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> stir mailing list >>>>>>>>>>> stir@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> stir mailing list >>>>>>>>>> stir@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>> _______________________________________________ >>>>>>>>>> stir mailing list >>>>>>>>>> stir@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>> _______________________________________________ >>>>>>>>> stir mailing list >>>>>>>>> stir@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> stir mailing list >>>>> stir@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/stir >>>>=20 >>>=20 >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> cnit mailing list >> cnit@ietf.org >> https://www.ietf.org/mailman/listinfo/cnit >=20 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From michael.hammer@yaanatech.com Thu Oct 31 11:11:33 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4F7721F9EAF; Thu, 31 Oct 2013 11:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[AWL=-1.450, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, MANGLED_COMPNY=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWUSE7WOl7ey; Thu, 31 Oct 2013 11:11:30 -0700 (PDT) Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) by ietfa.amsl.com (Postfix) with ESMTP id ED94421F9D90; Thu, 31 Oct 2013 11:11:29 -0700 (PDT) Received: from SC9-EX2K10MB1.corp.yaanatech.com ([fe80::149d:c2e1:8065:2a47]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Thu, 31 Oct 2013 11:11:29 -0700 From: Michael Hammer To: "Henning.Schulzrinne@fcc.gov" , "br@brianrosen.net" , "richard@shockey.us" Thread-Topic: [dispatch] [cnit] [stir] Application servers - Re: Call Center Implications Thread-Index: AQHO1l/vPBmavPqkd0evJj3dEIAHMJoPHFMw Date: Thu, 31 Oct 2013 18:11:27 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBEF4DB6@sc9-ex2k10mb1.corp.yaanatech.com> References: <32C55AFE-FA17-4776-AD91-259AD3E226BE@brianrosen.net> <024001ced5a2$f3268810$d9739830$@shockey.us> <029501ced5b5$8fa9f480$aefddd80$@shockey.us> <2AA32171-1AE3-4AEE-AEDC-B2031562B7BD@brianrosen.net> <00d901ced637$9e8143a0$db83cae0$@shockey.us> <8B0027B8-D777-48F3-B5BF-B8F81F038E37@brianrosen.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.113] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_01FF_01CED643.16603600" MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 31 Oct 2013 11:20:10 -0700 Cc: "cnit@ietf.org" , "dispatch@ietf.org" Subject: Re: [cnit] [dispatch] [stir] Application servers - Re: Call Center Implications X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 18:11:33 -0000 ------=_NextPart_000_01FF_01CED643.16603600 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable 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: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Henning Schulzrinne Sent: Thursday, October 31, 2013 1:37 PM To: 'Brian Rosen'; Richard Shockey Cc: cnit@ietf.org; DISPATCH Subject: Re: [dispatch] [cnit] [stir] Application servers - Re: Call = Center Implications Call-info: ;purpose=3Dcard or purpose=3Dinfo 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: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Brian Rosen Sent: Thursday, October 31, 2013 1:19 PM To: Richard Shockey Cc: cnit@ietf.org; 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. I am very interested in working on improving caller name. Brian On Oct 31, 2013, at 8:49 AM, Richard Shockey wrote: >=20 > Brian please.. Look at the mail. I'm using the CNIT list. =20 >=20 > The issue is can we use the tools at hand to increase both the=20 > accuracy, reliability and the amount of data that is delivered to the=20 > CUA over who is attempting to establish a session. >=20 > The larger issue is the integrity of the entire real time=20 > 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. >=20 > CNAM as it is currently defined in SS7 is a terrible service. 15=20 > Character ASCII. No support for International character sets the = usual. >=20 > 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=20 > 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=20 > that National Regulators would be delighted with consumers having a=20 > 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=20 > interconnection among providers it would be really really useful if=20 > Enterprise systems could extract more data from their internal=20 > directory systems and pass that along in the new format for = enterprise calling as well. >=20 > I would certainly argue that we are not going to see ubiquitous Point=20 > to Point video calling using WebRTC or SIP if there is not better=20 > display of calling party information. >=20 > In addition network operators could insert other 'hints' as to the=20 > nature of the session based on its ability to validate the Caller ID=20 > or other forms on analysis. >=20 > I'm well aware of how CNAM is delivered in North America and I'm=20 > equally aware the CNAM business model is broken. >=20 > What I'd like to know is what interest there is in this proposition=20 > and are there parties interested in working on it in advance of say London. >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, October 30, 2013 5:39 PM > To: Richard Shockey > Cc: cnit@ietf.org > Subject: Re: [cnit] [stir] Application servers - Re: Call Center=20 > Implications >=20 > More useful in what way? Improving the reliability of caller name? =20 > Please use the cnit list to discuss this. >=20 > 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=20 > the origination side, and signed as the number is. >=20 > That is a significant change to the current infrastructure, which at=20 > least in North America relies on a termination service provider dip in = > an origination service provider database, but it seems feasible to=20 > consider that. >=20 > Brian >=20 > On Oct 30, 2013, at 5:18 PM, Richard Shockey = wrote: >=20 >>=20 >> Ok since Brian is being picky.. >>=20 >> I'm actually interested if anyone is interested in the possibility of = >> making SIP Identity to the UA more useful. >>=20 >>=20 >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >> Of Richard Shockey >> Sent: Wednesday, October 30, 2013 3:05 PM >> To: stir@ietf.org >> Subject: Re: [stir] Application servers - Re: Call Center=20 >> Implications >>=20 >> Dan great post. I couldn't agree more. There needs to be some rules here. >> Some may be regulatory some may be technical. >>=20 >> First the voice application service providers need to provide the=20 >> terminating CUA, "an accurate and truthful" Caller-ID for the call=20 >> even if it is originated from a source that is not directly=20 >> 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=20 >> RESPORGS. >>=20 >> If the originating UA can prove/assert it is legally authorized to=20 >> use such an identity on behalf of a customer then that is step one. >> The presumption after that is there is some contractual obligation=20 >> between the service provider and the network about the use of such identities. >> The network can then "validate" such an assertion. >>=20 >> 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. =20 >>=20 >> 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=20 >> the called party and frankly 15 character ASCII is not enough. >> Consumers or businesses should be able to see more complete and=20 >> validated information about the session in order to make an better=20 >> 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. >>=20 >> All of the examples you cite are excellent examples where such=20 >> verbose calling party identification could be displayed. I certainly = >> want to answer a call from my doctor on my test results just as I=20 >> wish to ignore a call from Bill Clinton begging me to vote in the=20 >> Virginia Governors election next Tuesday. This is a case where=20 >> annominity is not a > good idea. >>=20 >>=20 >> All you need now is a little standardization. >> Technically this should is very easy to understand in SIP. It would=20 >> probably a reasonable modification of the Call INFO header in SIP=20 >> with something like a XML based VCARD or JCARD URI whatever and=20 >> 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. >>=20 >>=20 >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >> Of Dan York >> Sent: Tuesday, October 29, 2013 5:10 PM >> To: Brian Rosen; Cullen Jennings >> Cc: Gregory.Schumacher@sprint.com; Richard Shockey; stir@ietf.org;=20 >> Fernando Mousinho (fmousinh); Alex Bobotek; Michael Hammer; Henning=20 >> Schulzrinne >> Subject: [stir] Application servers - Re: Call Center Implications >>=20 >> 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=20 >> that we're not only talking about "traditional" call centers but also = >> what I'll call "voice application service providers". They are=20 >> generally automated platforms running applications that a company=20 >> uses for some kind of outbound service. Examples include: >>=20 >> - calling everyone in a school district with a weather-related=20 >> cancellation (or, unfortunately, a school shooting or similar event) >> - calling patients to provide reminders of appointments or=20 >> notifications of subscriptions available >> - calling customers to let them know that a package was delivered or=20 >> 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=20 >> current issues >> - performing a call-back to provide an additional layer of=20 >> authentication for some service >>=20 >> There is a large (and growing) market for these kind of automated=20 >> tools and services and the distinction between these calls and=20 >> "robocalls" is really only one of intent and the fact that the=20 >> recipient > has "opted in" >> through some kind of system. >>=20 >> Generally, though, many of the companies want the application to=20 >> 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=20 >> from one of their own phone numbers. >>=20 >> You could think of these in the same way as "call centers", but I=20 >> point this out because some of these new services are very automated=20 >> and there are always new startups now emerging in this space. Some=20 >> of them are very "self-service" where the customer does it all while=20 >> others have teams of people involved. Some of the companies involved = >> include Nuance, Microsoft Tellme, Voxeo (now Aspect, and also my=20 >> former employer), Tropo, Twilio, Convergys and many more[1]. >>=20 >> If STIR is to succeed, these kind of application platforms will also=20 >> need to be able to make calls on behalf of the companies using those > platforms. >>=20 >> Dan >>=20 >> [1] One report about this market: >> http://www.voxeo.com/pdf/OvumDecisionMatrix-2011.pdf >>=20 >>=20 >> -- >> Dan York >> Senior Content Strategist, Internet Society >> york@isoc.org +1-802-735-1624 >> Jabber: york@jabber.isoc.org >> Skype: danyork http://twitter.com/danyork >>=20 >> http://www.internetsociety.org/deploy360/ >>=20 >>=20 >>=20 >>=20 >> On 10/21/13 9:15 AM, "Brian Rosen" wrote: >>=20 >>> We really need to give each BPO different keys I think. The notion that >>> we are sharing private keys among multiple competing entities who=20 >>> provide services for a single enterprise strikes me as a VBI (Very=20 >>> Bad Idea). I can't see any real difficulty in having more than one=20 >>> 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=20 >>> more of it's >> BPOs. >>>=20 >>> Brian >>>=20 >>> On Oct 20, 2013, at 1:12 AM, Cullen Jennings (fluffy)=20 >>> >>> wrote: >>>=20 >>>>=20 >>>> What Fernando is saying makes sense to me a desirable property of=20 >>>> the solution and I agree that if we gave each BPO a different=20 >>>> private key that would solve it but that might be pretty hard to=20 >>>> mange in other ways. I like the requirements but the solution is=20 >>>> not 100% obvious to me. >>>>=20 >>>>=20 >>>> On Oct 2, 2013, at 10:27 AM, Brian Rosen wrote: >>>>=20 >>>>> Sure. >>>>>=20 >>>>> Each BPO would have a different private/public key pair. >>>>>=20 >>>>> So you can trace which one placed the call. >>>>>=20 >>>>> Brian >>>>>=20 >>>>> On Oct 2, 2013, at 12:59 PM, Fernando Mousinho (fmousinh)=20 >>>>> wrote: >>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> If the company hires several BPOs and authorizes all of them to=20 >>>>>> sign calls on its behalf, is there a way to trace back the=20 >>>>>> originator (specific >>>>>> BPO) >>>>>> later on? I suppose that at some level the actual caller must be=20 >>>>>> exposed (perhaps to trace malicious activity, such as malicious=20 >>>>>> person infiltrated in an otherwise legitimate BPO). >>>>>>=20 >>>>>> 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=20 >>>>>> identity). >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 9/19/13 9:43 PM, "Brian Rosen" wrote: >>>>>>=20 >>>>>>> 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=20 >>>>>>> change to use From (if signed maybe). It also doesn't fit the=20 >>>>>>> definition of PAI. >>>>>>>=20 >>>>>>> Brian >>>>>>>=20 >>>>>>> On Sep 19, 2013, at 9:14 PM, Fernando Mousinho (fmousinh)=20 >>>>>>> wrote: >>>>>>>=20 >>>>>>>> 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=20 >>>>>>>> on the delegation process Rosen mentions. >>>>>>>> PAI's use is widespread, and it's main limitation is being=20 >>>>>>>> spoofable - but this is exactly the problem we are trying to=20 >>>>>>>> solve anyway. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> On Sep 19, 2013, at 5:39 PM, "Richard Shockey"=20 >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>> Excellent point a profile or BCP to complement the work. >>>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On=20 >>>>>>>>> Behalf Of Alex Bobotek >>>>>>>>> Sent: Thursday, September 19, 2013 5:27 PM >>>>>>>>> To: Henning Schulzrinne; Michael Hammer; fmousinh@cisco.com;=20 >>>>>>>>> Gregory.Schumacher@sprint.com; br@brianrosen.net >>>>>>>>> Cc: stir@ietf.org >>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>=20 >>>>>>>>> +1 >>>>>>>>> I've assumed that we are headed towards a "sign whatever=20 >>>>>>>>> extras you wish, and indicate what your signature covers" mechanism. >>>>>>>>>=20 >>>>>>>>> Based on this, standards would need to identify only a minimal = >>>>>>>>> subset of what shall/should be signed, and ensure that any=20 >>>>>>>>> required group of signed items survives transit intact. >>>>>>>>>=20 >>>>>>>>> Best signing practices may be needed to complement the=20 >>>>>>>>> standard, and an appropriate place for all but the most basic = >>>>>>>>> 'what to sign' >>>>>>>>> recommendations. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Regards, >>>>>>>>>=20 >>>>>>>>> Alex >>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On = >>>>>>>>>> Behalf Of Henning Schulzrinne >>>>>>>>>> Sent: Thursday, September 19, 2013 2:24 PM >>>>>>>>>> To: Michael Hammer; fmousinh@cisco.com;=20 >>>>>>>>>> Gregory.Schumacher@sprint.com; br@brianrosen.net >>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>=20 >>>>>>>>>> I see no reason not to allow signing any number-related field = >>>>>>>>>> in the SIP request. (Signing may well be done by different >>>>>>>>>> parties.) >>>>>>>>>>=20 >>>>>>>>>> As far as I know, callback numbers (SIP Reply-To) aren't=20 >>>>>>>>>> conveyable in legacy systems, however, so this may be of=20 >>>>>>>>>> somewhat limited use for a >>>>>>>>> while. >>>>>>>>>>=20 >>>>>>>>>> ________________________________________ >>>>>>>>>> From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf = >>>>>>>>>> of Michael Hammer [michael.hammer@yaanatech.com] >>>>>>>>>> Sent: Thursday, September 19, 2013 4:34 PM >>>>>>>>>> To: fmousinh@cisco.com; Gregory.Schumacher@sprint.com;=20 >>>>>>>>>> br@brianrosen.net >>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>=20 >>>>>>>>>> Don't we still want to know the true originator of the call,=20 >>>>>>>>>> even when we have some token that says "Doctor so and so=20 >>>>>>>>>> approved this message." >>>>>>>>>>=20 >>>>>>>>>> Originating number, display number, and call-back number=20 >>>>>>>>>> could be >>>>>>>>>> 3 >>>>>>>>>> different things. >>>>>>>>>> Should all of them be verifiable? >>>>>>>>>>=20 >>>>>>>>>> Mike >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On = >>>>>>>>>> Behalf Of Fernando Mousinho (fmousinh) >>>>>>>>>> Sent: Thursday, September 19, 2013 4:00 PM >>>>>>>>>> To: Schumacher, Gregory [CTO]; Brian Rosen >>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>=20 >>>>>>>>>> I believe the scenario telemarketing here is when a client=20 >>>>>>>>>> hires a BPO to place outbound calls, but expect customers=20 >>>>>>>>>> to return these calls to a different place (say, their own=20 >>>>>>>>>> and operated call center). This way, this client is=20 >>>>>>>>>> authorizing the BPO to use an identity that it >>>>>>>>>> (BPO) >>>>>>>>> doesn't own. >>>>>>>>>> These numbers in this scenario are always operational, just=20 >>>>>>>>>> at a different place. >>>>>>>>>>=20 >>>>>>>>>> The same telemarketing operator would then outpulse multiple=20 >>>>>>>>>> numbers for their multiple clients, none of these numbers=20 >>>>>>>>>> belonging to the >>>>>>>>> telemarketer. >>>>>>>>>> BTW, we are using the term "telemarketing" in a very generic=20 >>>>>>>>>> sense - this could just as easily be a public service=20 >>>>>>>>>> announcement, fundraiser, >>>>>>>>> etc. >>>>>>>>>>=20 >>>>>>>>>> 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. >>>>>>>>>>=20 >>>>>>>>>> On a different note, it would help a lot of we standardized=20 >>>>>>>>>> terminology. >>>>>>>>>> Telemarketing, BPO, call center, end customer, clients=A9 it=20 >>>>>>>>>> may be hard for others to follow the discussion later. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> (generic term for any type of outbound calling, including=20 >>>>>>>>>> public service announcement, so don't think it's all about >>>>>>>>>> sales!) >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On 9/19/13 3:22 PM, "Schumacher, Gregory [CTO]" >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>> There are some benefits from this approach, but also some=20 >>>>>>>>>>> scenarios that need clarification how they could function. >>>>>>>>>>>=20 >>>>>>>>>>> The benefit is that the credential represents both the=20 >>>>>>>>>>> company "responsible" for the sales campaign (the "company" >>>>>>>>>>> in your >>>>>>>>>>> scenario) >>>>>>>>>>> and the company operating the sales campaign (the call=20 >>>>>>>>>>> center in your scenario). For the use in forensics (after = >>>>>>>>>>> the fact >>>>>>>>>>> analysis) such as pursuit of fraud investigation, we then=20 >>>>>>>>>>> can follow both paths. >>>>>>>>>>>=20 >>>>>>>>>>> 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=20 >>>>>>>>>>> telemarketing campaign or both? >>>>>>>>>>>=20 >>>>>>>>>>> - How is the SP supposed to know all the parties that it is=20 >>>>>>>>>>> attesting to >>>>>>>>>>> - the responsible party and/or executing party? >>>>>>>>>>>=20 >>>>>>>>>>> -It seems likely that some of the numbers assigned to a=20 >>>>>>>>>>> company in your scenario will not be assigned to real=20 >>>>>>>>>>> telephones (or call center >>>>>>>>>>> trunk) until a telemarketing campaign is initiated or a call = >>>>>>>>>>> center selected to execute the sales campaign, is it=20 >>>>>>>>>>> possible to have these unassigned or floating numbers when=20 >>>>>>>>>>> not in use for a telemarketing campaign? Is it allowed=20 >>>>>>>>>>> under most national numbering regimes? >>>>>>>>>>>=20 >>>>>>>>>>> - How important is it to have a known or recognized phone=20 >>>>>>>>>>> number as the caller id as part of a telemarketing = campaign? >>>>>>>>>>> I am assuming that not all campaigns care about having a=20 >>>>>>>>>>> number that is known or >>>>>>>>> recognized. >>>>>>>>>>>=20 >>>>>>>>>>> -In other words for this last bit, if a call center=20 >>>>>>>>>>> (telemarketing campaign operator) is using their own set of = >>>>>>>>>>> numbers but serve multiple simultaneous telemarketing=20 >>>>>>>>>>> campaigns using the same originating numbers, what will=20 >>>>>>>>>>> they sign? Will they just have a credential representing=20 >>>>>>>>>>> the call center alone, or a different credential per=20 >>>>>>>>>>> telemarketing campaign, or a different credential per=20 >>>>>>>>>>> responsible party (per client)? This will affect what is=20 >>>>>>>>>>> possible for >>>>>>>>> any forensic activity. >>>>>>>>>>>=20 >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org]=20 >>>>>>>>>>> On Behalf Of Brian Rosen >>>>>>>>>>> Sent: Tuesday, September 17, 2013 9:44 AM >>>>>>>>>>> To: Fernando Mousinho >>>>>>>>>>> Cc: stir@ietf.org; Hadriel Kaplan >>>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>>=20 >>>>>>>>>>> We have a requirement to support the BPO use case. >>>>>>>>>>>=20 >>>>>>>>>>> The notion we had is that the company contracting the call=20 >>>>>>>>>>> center approves the use, and the call center, or the SP=20 >>>>>>>>>>> acting on its behalf, signs. >>>>>>>>>>> Think of this as another level of delegation. An SP=20 >>>>>>>>>>> delegates numbers to the company. The company "delegates" >>>>>>>>>>> use of those numbers to the call center. The call center=20 >>>>>>>>>>> calls, using that delegation. >>>>>>>>>>> The credentials of the call center would be different from=20 >>>>>>>>>>> those of the company, but would cover the same number. >>>>>>>>>>> Having multiple credentials covering the same number will=20 >>>>>>>>>>> be very common due to the way delegation happens. In order = >>>>>>>>>>> to allow SPs to sign, without creating credential per TN,=20 >>>>>>>>>>> we allow credentials with ranges. >>>>>>>>>>> The >>>>>>>>>>> ranges could overlap when delegation happens. >>>>>>>>>>>=20 >>>>>>>>>>> Consider the following complex US case: >>>>>>>>>>> The North American Number Plan Administrator delegates=20 >>>>>>>>>>> 202-555-xxxx to the Pooling Administrator. The PA now has=20 >>>>>>>>>>> a credential covering the entire 10K block. >>>>>>>>>>> The Pooling Administrator delegates 202-555-1xxx to SP A. =20 >>>>>>>>>>> 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=20 >>>>>>>>>>> 202-555-123x to Company C. Company C has a credential for=20 >>>>>>>>>>> a >>>>>>>>>>> 10 number block Company C authorizes 202-555-1234 to BPO D. = =20 >>>>>>>>>>> BPO D has credential for a 1 number block >>>>>>>>>>>=20 >>>>>>>>>>> NANPA and the PA never are in a call path, so they would=20 >>>>>>>>>>> never sign a call. >>>>>>>>>>>=20 >>>>>>>>>>> However, SP A or SP B could sign a call from either Company=20 >>>>>>>>>>> C or BPO D using the credential they have. >>>>>>>>>>>=20 >>>>>>>>>>> The SP for the call center could acquire credentials from=20 >>>>>>>>>>> the BPO and sign on its behalf. I suspect than many=20 >>>>>>>>>>> service providers would be reluctant to do so unless the=20 >>>>>>>>>>> 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=20 >>>>>>>>>>> probably has to do the signing itself. >>>>>>>>>>>=20 >>>>>>>>>>> Brian >>>>>>>>>>>=20 >>>>>>>>>>> On Sep 17, 2013, at 8:46 AM, Fernando Mousinho (fmousinh)=20 >>>>>>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> I agree, Hadriel. While large call centers (including BPOs, = >>>>>>>>>>>> which provide services for other companies) may have=20 >>>>>>>>>>>> special arrangements with SPs, the majority (small to >>>>>>>>>>>> mid-size) will probably rely on the SPs to do provide to=20 >>>>>>>>>>>> vouch for their identity. This would probably be the case=20 >>>>>>>>>>>> for the home analog caller anyway. This would imply that=20 >>>>>>>>>>>> the "originating" SP's willingness to provide this=20 >>>>>>>>>>>> signature is a critical success factor for the proposal's > adoption. >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> But back to the business process outsourcers (BPO) case -=20 >>>>>>>>>>>> where a call center is providing service on behalf of=20 >>>>>>>>>>>> multiple companies. I can see the value of them sending=20 >>>>>>>>>>>> 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=20 >>>>>>>>>>>> that SP >>>>>>>>>>>> 1 allowing one of its subscribers to send an outbound call=20 >>>>>>>>>>>> using a number registered to SP 2 could be a no-no. If=20 >>>>>>>>>>>> this hypothesis is correct, then we are back to the case=20 >>>>>>>>>>>> where the SP is signing all calls, >>>>>>>>>> even for BPOs. >>>>>>>>>>>>=20 >>>>>>>>>>>> Or maybe this is another problem we are trying to fix in=20 >>>>>>>>>>>> the working group, in which case we perhaps should state as = >>>>>>>>>>>> a goal or >>>>>>>>> benefit: >>>>>>>>>>>> "providing a reliable mechanism to let calls originated=20 >>>>>>>>>>>> from one >>>>>>>>>>>> SP1 to outpulse numbers that belong to another". >>>>>>>>>>>>=20 >>>>>>>>>>>> Fernando >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> On 9/16/13 12:12 PM, "Hadriel Kaplan" >>>>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Any of them could do it. My guess is service providers=20 >>>>>>>>>>>>> will do it for most call centers, although larger call=20 >>>>>>>>>>>>> centers might do it themselves... >>>>>>>>>>>>> especially ones which have trunks from multiple providers=20 >>>>>>>>>>>>> and can source calls using the same number(s) out through = >>>>>>>>>>>>> multiple providers on a call-by-call basis. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> -hadriel >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Sep 16, 2013, at 9:49 AM, Fernando Mousinho (fmousinh)=20 >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I'm catching up with the discussions in this working=20 >>>>>>>>>>>>>> group, and am trying to understand some architecture=20 >>>>>>>>>>>>>> implications in call centers (which is where my=20 >>>>>>>>>>>>>> background is). It seems that many of the problems we=20 >>>>>>>>>>>>>> are trying to fix are related to contact centers anyway, = >>>>>>>>>>>>>> so it is probably a good idea to have everyone in the=20 >>>>>>>>>>>>>> same >>>>>>>>>> page. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Forgive me if it is an obvious question, but which=20 >>>>>>>>>>>>>> components in a "typical call center architecture" do=20 >>>>>>>>>>>>>> you see signature and verification taking place? Such "typical" >>>>>>>>>>>>>> deployments have premises based equipment (PME), a=20 >>>>>>>>>>>>>> session border controller >>>>>>>>>>>>>> (SBC) >>>>>>>>>>>>>> and of course a SIP service provider all three could=20 >>>>>>>>>>>>>> potentially be used throughout the authorization = process. >>>>>>>>>>>>>> There are different ramifications depending on where=20 >>>>>>>>>>>>>> your mind is at. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Fernando Mousinho >>>>>>>>>>>>>> Cisco Systems >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> stir mailing list >>>>>>>>>>>> stir@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> stir mailing list >>>>>>>>>>> stir@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> ________________________________ >>>>>>>>>>>=20 >>>>>>>>>>> This e-mail may contain Sprint proprietary information=20 >>>>>>>>>>> intended for the sole use of the recipient(s). Any use by=20 >>>>>>>>>>> others is prohibited. >>>>>>>>>>> If >>>>>>>>>>> you are not the intended recipient, please contact the=20 >>>>>>>>>>> sender and delete all copies of the message. >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> stir mailing list >>>>>>>>>>> stir@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> stir mailing list >>>>>>>>>> stir@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>> _______________________________________________ >>>>>>>>>> stir mailing list >>>>>>>>>> stir@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>> _______________________________________________ >>>>>>>>> stir mailing list >>>>>>>>> stir@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> stir mailing list >>>>> stir@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/stir >>>>=20 >>>=20 >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> cnit mailing list >> cnit@ietf.org >> https://www.ietf.org/mailman/listinfo/cnit >=20 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch ------=_NextPart_000_01FF_01CED643.16603600 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMTAz MTE4MTEyNlowIwYJKoZIhvcNAQkEMRYEFMguhiHOL/FiPdRacVnZj++4ea7ZMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAOy7f+gTrnu5vNMXf11sX22puffkIlH83H+GFhout D60uYkRQNU5ZvK4WdGNnjS9JkLfJ5CY7BOnAWrBh84eFHOT34M5BfjMILlBUY/gk/Tl6jfVmpWDM 9uPJXuVpvzQxGIHqixyfsB+1iuLuTBQRW7IY4lMQrebBVigIVlzbeYwyarqenLwy1iM672k0xJK3 WXZa2L2C5fQPKHZ8UV04z0qL05WLW2gqDKihGu3p6NwJF+W9Y5d8SagQuCOsu/Vn7PwjNpjCe3J+ 30/aBdbmb+jp1cM7vEURuvm9xaqtbEmUDPgAIVZnn6GmWzSuRrIubCmC3Z/oMfTVDaJYp0QeggAA AAAAAA== ------=_NextPart_000_01FF_01CED643.16603600-- From Pierce.Gorman@sprint.com Thu Oct 31 11:22:15 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D67D511E826E for ; Thu, 31 Oct 2013 11:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_COMPNY=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q3eJ84wJmYHZ for ; Thu, 31 Oct 2013 11:22:11 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id B68C211E81D2 for ; Thu, 31 Oct 2013 11:22:10 -0700 (PDT) Received: from mail231-va3-R.bigfish.com (10.7.14.250) by VA3EHSOBE007.bigfish.com (10.7.40.11) with Microsoft SMTP Server id 14.1.225.22; Thu, 31 Oct 2013 18:22:09 +0000 Received: from mail231-va3 (localhost [127.0.0.1]) by mail231-va3-R.bigfish.com (Postfix) with ESMTP id B14B93C0116; Thu, 31 Oct 2013 18:22:09 +0000 (UTC) X-Forefront-Antispam-Report: CIP:144.230.168.26; KIP:(null); UIP:(null); IPV:NLI; H:plsasdm2.corp.sprint.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: VS-24(zzbb2dIdb82h98dI9371I146fI542I1432Ic6d4mzz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL177df4h17326ah8275bh8275dh1de097h186068h5eeeKz2fh2a8h839hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h2216h1155h) Received-SPF: pass (mail231-va3: domain of sprint.com designates 144.230.168.26 as permitted sender) client-ip=144.230.168.26; envelope-from=Pierce.Gorman@sprint.com; helo=plsasdm2.corp.sprint.com ; p.sprint.com ; Received: from mail231-va3 (localhost.localdomain [127.0.0.1]) by mail231-va3 (MessageSwitch) id 1383243726742031_12117; Thu, 31 Oct 2013 18:22:06 +0000 (UTC) Received: from VA3EHSMHS045.bigfish.com (unknown [10.7.14.229]) by mail231-va3.bigfish.com (Postfix) with ESMTP id B12EACC0052; Thu, 31 Oct 2013 18:22:06 +0000 (UTC) Received: from plsasdm2.corp.sprint.com (144.230.168.26) by VA3EHSMHS045.bigfish.com (10.7.99.55) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 31 Oct 2013 18:22:06 +0000 Received: from PLSWEH04.ad.sprint.com (plsweh04.corp.sprint.com [144.226.251.22]) by plsasdm2.corp.sprint.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r9VIM46W011371 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 31 Oct 2013 13:22:04 -0500 Received: from pdawm10a.ad.sprint.com ([169.254.2.186]) by PLSWEH04.ad.sprint.com ([144.226.251.22]) with mapi id 14.03.0123.003; Thu, 31 Oct 2013 13:22:04 -0500 From: "Gorman, Pierce A [NTK]" To: Brian Rosen , Richard Shockey Thread-Topic: [cnit] [stir] Application servers - Re: Call Center Implications Thread-Index: AQHO1l1nYYND9uXQCUuBUdMxKwt+KZoPEAiQ Date: Thu, 31 Oct 2013 18:22:02 +0000 Message-ID: References: <32C55AFE-FA17-4776-AD91-259AD3E226BE@brianrosen.net> <024001ced5a2$f3268810$d9739830$@shockey.us> <029501ced5b5$8fa9f480$aefddd80$@shockey.us> <2AA32171-1AE3-4AEE-AEDC-B2031562B7BD@brianrosen.net> <00d901ced637$9e8143a0$db83cae0$@shockey.us> <8B0027B8-D777-48F3-B5BF-B8F81F038E37@brianrosen.net> In-Reply-To: <8B0027B8-D777-48F3-B5BF-B8F81F038E37@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.122.53.23] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sprint.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "cnit@ietf.org" , "Schumacher, Gregory \[CTO\]" Subject: Re: [cnit] [stir] Application servers - Re: Call Center Implications X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 18:22:16 -0000 I'm not sure I'd say the CNAM business model is broken if there are CNAM pr= oviders making a profit. :-) To be a little more serious, there is value in using content indirection (w= hich is the CNAM model). The verified calling ID (assuming STIR will be su= ccessful) would be a lightweight pointer to content a UA might like to pres= ent or see/hear. With respect to how to pass additional information in SIP= (including content), IMHO it might be easier to add something like a 2nd m= essage body with (verified?) XML or URI, et cetera, than to try to add new = SIP headers or change handling for parts of existing headers such as the di= splay name. (The B2BUAs in many softswitches simply discard display name.) Best regards, Pierce Gorman Voice Architecture Core Planning/Sprint 913-439-4368 (Desk) -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: October 31, 2013 12:19 PM To: Richard Shockey Cc: cnit@ietf.org; DISPATCH Subject: Re: [cnit] [stir] Application servers - Re: Call Center Implicatio= ns I think the issue is whether we think what is usually called "contact" info= rmation is reasonable to send on every call. I do think if we were to do anything like that, we would do it with xCard a= nd 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 automati= c sending. I am very interested in working on improving caller name. Brian On Oct 31, 2013, at 8:49 AM, Richard Shockey wrote: > > 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 c= onsumer. > > 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 c= alling 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 Londo= n. > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, October 30, 2013 5:39 PM > To: Richard Shockey > Cc: cnit@ietf.org > 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 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: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >> Of Richard Shockey >> Sent: Wednesday, October 30, 2013 3:05 PM >> To: stir@ietf.org >> Subject: Re: [stir] Application servers - Re: Call Center >> Implications >> >> Dan great post. I couldn't agree more. There needs to be some rules her= e. >> 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 ident= ities. >> 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: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >> Of Dan York >> Sent: Tuesday, October 29, 2013 5:10 PM >> To: Brian Rosen; Cullen Jennings >> Cc: Gregory.Schumacher@sprint.com; Richard Shockey; stir@ietf.org; >> 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 >> york@isoc.org +1-802-735-1624 >> Jabber: york@jabber.isoc.org >> Skype: danyork http://twitter.com/danyork >> >> http://www.internetsociety.org/deploy360/ >> >> >> >> >> On 10/21/13 9:15 AM, "Brian Rosen" wrote: >> >>> We really need to give each BPO different keys I think. The notion th= at >>> 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) >>> >>> 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 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) >>>>> 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" 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) >>>>>>> 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" >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Excellent point a profile or BCP to complement the work. >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On >>>>>>>>> Behalf Of Alex Bobotek >>>>>>>>> Sent: Thursday, September 19, 2013 5:27 PM >>>>>>>>> To: Henning Schulzrinne; Michael Hammer; fmousinh@cisco.com; >>>>>>>>> Gregory.Schumacher@sprint.com; br@brianrosen.net >>>>>>>>> Cc: stir@ietf.org >>>>>>>>> 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" mechani= sm. >>>>>>>>> >>>>>>>>> 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: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On >>>>>>>>>> Behalf Of Henning Schulzrinne >>>>>>>>>> Sent: Thursday, September 19, 2013 2:24 PM >>>>>>>>>> To: Michael Hammer; fmousinh@cisco.com; >>>>>>>>>> Gregory.Schumacher@sprint.com; br@brianrosen.net >>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>> 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: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf >>>>>>>>>> of Michael Hammer [michael.hammer@yaanatech.com] >>>>>>>>>> Sent: Thursday, September 19, 2013 4:34 PM >>>>>>>>>> To: fmousinh@cisco.com; Gregory.Schumacher@sprint.com; >>>>>>>>>> br@brianrosen.net >>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>> 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: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On >>>>>>>>>> Behalf Of Fernando Mousinho (fmousinh) >>>>>>>>>> Sent: Thursday, September 19, 2013 4:00 PM >>>>>>>>>> To: Schumacher, Gregory [CTO]; Brian Rosen >>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>> 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 cente= r. >>>>>>>>>> >>>>>>>>>> On a different note, it would help a lot of we standardized >>>>>>>>>> terminology. >>>>>>>>>> Telemarketing, BPO, call center, end customer, clients=A9 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]" >>>>>>>>>> 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: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] >>>>>>>>>>> On Behalf Of Brian Rosen >>>>>>>>>>> Sent: Tuesday, September 17, 2013 9:44 AM >>>>>>>>>>> To: Fernando Mousinho >>>>>>>>>>> Cc: stir@ietf.org; 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) >>>>>>>>>>> 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" >>>>>>>>>>>> >>>>>>>>>> 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) >>>>>>>>>>>>> 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 "typi= cal" >>>>>>>>>>>>>> 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 >>>>>>>>>>>> stir@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> stir mailing list >>>>>>>>>>> stir@ietf.org >>>>>>>>>>> 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 >>>>>>>>>>> stir@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> stir mailing list >>>>>>>>>> stir@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>> _______________________________________________ >>>>>>>>>> stir mailing list >>>>>>>>>> stir@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>> _______________________________________________ >>>>>>>>> stir mailing list >>>>>>>>> stir@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> stir mailing list >>>>> stir@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/stir >>>> >>> >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >> >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >> >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >> >> _______________________________________________ >> cnit mailing list >> cnit@ietf.org >> https://www.ietf.org/mailman/listinfo/cnit > ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e 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 br@brianrosen.net Thu Oct 31 11:39:32 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 556D611E817A for ; Thu, 31 Oct 2013 11:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.365 X-Spam-Level: X-Spam-Status: No, score=-102.365 tagged_above=-999 required=5 tests=[AWL=-1.066, BAYES_00=-2.599, MANGLED_COMPNY=2.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Cp-pgEFn5pX for ; Thu, 31 Oct 2013 11:39:26 -0700 (PDT) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF8521F9E4F for ; Thu, 31 Oct 2013 11:39:23 -0700 (PDT) Received: by mail-qc0-f170.google.com with SMTP id n9so1907398qcw.29 for ; Thu, 31 Oct 2013 11:39:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=3mITXp9Z64BJ63WrwAE+ST1jW4EJ9PjSyfsSbJ04ed4=; b=ZRT+TNb8EQkXC3hkyxJNOZlmgRkqo8IAxHPKuZAaBVgwnDtu3U2zBF6hypyNkvJmSL MV62ruag+WtY7WYgYzGqUUMXRdKgHHQMWdB+mvBnWHbyNVIiVAXI/yEzeAdJg793qH/p ZijHMp1F7TCWIkRCNKfhywDUzQhrbTSZcSKsA5BY8zlHz9J7Ru3r+EGu6xldJU3Hg9Yx nCFLp/dDcBjczK8CSYx53e3c/Yld0hlodvzPCbPHLGYK9xlOvtmV1uXCCEebdywIUu0s 3+bUiPCWwwyRiyYspkk0glBDhgmFiYJ6BJA/qG3tn+PtUKkXDKZ4nO7inYwAKU/c+/sn dnzg== X-Gm-Message-State: ALoCoQmX/mkSSCQiCvaGyy6O0iplTp4Eung41jz4WDEGFjHDqTRcTGqU0F1RHoCTPKxVyl9wwzHH X-Received: by 10.229.69.202 with SMTP id a10mr6227110qcj.24.1383244760193; Thu, 31 Oct 2013 11:39:20 -0700 (PDT) Received: from [10.33.192.35] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id n7sm11987245qai.1.2013.10.31.11.39.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 31 Oct 2013 11:39:18 -0700 (PDT) Content-Type: text/plain; charset=windows-1250 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Brian Rosen In-Reply-To: Date: Thu, 31 Oct 2013 14:39:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <61B8913D-852E-4B43-ABC1-95FEA7DDEF0D@brianrosen.net> References: <32C55AFE-FA17-4776-AD91-259AD3E226BE@brianrosen.net> <024001ced5a2$f3268810$d9739830$@shockey.us> <029501ced5b5$8fa9f480$aefddd80$@shockey.us> <2AA32171-1AE3-4AEE-AEDC-B2031562B7BD@brianrosen.net> <00d901ced637$9e8143a0$db83cae0$@shockey.us> <8B0027B8-D777-48F3-B5BF-B8F81F038E37@brianrosen.net> To: "Gorman, Pierce A [NTK]" X-Mailer: Apple Mail (2.1816) Cc: "cnit@ietf.org" , "Schumacher, Gregory \[CTO\]" , Richard Shockey Subject: Re: [cnit] [stir] Application servers - Re: Call Center Implications X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 18:39:32 -0000 We=92ve evolved a very nice mechanism for passing data like xCards in = SIP. You define the header (in this case, we already have the Call-Info = header, all we need is a purpose parameter value) that takes a URI. If = you want to pass by reference, the URI leads to the value using an HTTP = GET. If you want to pass by value, you put the value in a body = (requires mime/multipart) and use a Content Indirect URL (RFC2392) = pointing to the body. See RFC6442 for an example of how this is done. Since we=92re using the mechanism to pass location for emergency calls, = the SBCs need to get used to allowing it :) Brian On Oct 31, 2013, at 2:22 PM, Gorman, Pierce A [NTK] = wrote: > I'm not sure I'd say the CNAM business model is broken if there are = CNAM providers making a profit. :-) >=20 > To be a little more serious, there is value in using content = indirection (which is the CNAM model). The verified calling ID = (assuming STIR will be successful) would be a lightweight pointer to = content a UA might like to present or see/hear. With respect to how to = pass additional information in SIP (including content), IMHO it might be = easier to add something like a 2nd message body with (verified?) XML or = URI, et cetera, than to try to add new SIP headers or change handling = for parts of existing headers such as the display name. (The B2BUAs in = many softswitches simply discard display name.) >=20 > Best regards, >=20 >=20 > Pierce Gorman > Voice Architecture > Core Planning/Sprint > 913-439-4368 (Desk) >=20 >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: October 31, 2013 12:19 PM > To: Richard Shockey > Cc: cnit@ietf.org; DISPATCH > Subject: Re: [cnit] [stir] Application servers - Re: Call Center = Implications >=20 > I think the issue is whether we think what is usually called "contact" = information is reasonable to send on every call. >=20 > 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. >=20 > 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. >=20 > If we were to go farther, I'd probably want a request, rather than = automatic sending. >=20 > I am very interested in working on improving caller name. >=20 > Brian >=20 > On Oct 31, 2013, at 8:49 AM, Richard Shockey = wrote: >=20 >>=20 >> Brian please.. Look at the mail. I'm using the CNIT list. >>=20 >> 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. >>=20 >> 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. >>=20 >> CNAM as it is currently defined in SS7 is a terrible service. 15 >> Character ASCII. No support for International character sets the = usual. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> I'm well aware of how CNAM is delivered in North America and I'm >> equally aware the CNAM business model is broken. >>=20 >> 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. >>=20 >> -----Original Message----- >> From: Brian Rosen [mailto:br@brianrosen.net] >> Sent: Wednesday, October 30, 2013 5:39 PM >> To: Richard Shockey >> Cc: cnit@ietf.org >> Subject: Re: [cnit] [stir] Application servers - Re: Call Center >> Implications >>=20 >> More useful in what way? Improving the reliability of caller name? >> Please use the cnit list to discuss this. >>=20 >> 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. >>=20 >> 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. >>=20 >> Brian >>=20 >> On Oct 30, 2013, at 5:18 PM, Richard Shockey = wrote: >>=20 >>>=20 >>> Ok since Brian is being picky.. >>>=20 >>> I'm actually interested if anyone is interested in the possibility = of >>> making SIP Identity to the UA more useful. >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >>> Of Richard Shockey >>> Sent: Wednesday, October 30, 2013 3:05 PM >>> To: stir@ietf.org >>> Subject: Re: [stir] Application servers - Re: Call Center >>> Implications >>>=20 >>> Dan great post. I couldn't agree more. There needs to be some rules = here. >>> Some may be regulatory some may be technical. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>>=20 >>> 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. >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf >>> Of Dan York >>> Sent: Tuesday, October 29, 2013 5:10 PM >>> To: Brian Rosen; Cullen Jennings >>> Cc: Gregory.Schumacher@sprint.com; Richard Shockey; stir@ietf.org; >>> Fernando Mousinho (fmousinh); Alex Bobotek; Michael Hammer; Henning >>> Schulzrinne >>> Subject: [stir] Application servers - Re: Call Center Implications >>>=20 >>> 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: >>>=20 >>> - 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 >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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]. >>>=20 >>> 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. >>>=20 >>> Dan >>>=20 >>> [1] One report about this market: >>> http://www.voxeo.com/pdf/OvumDecisionMatrix-2011.pdf >>>=20 >>>=20 >>> -- >>> Dan York >>> Senior Content Strategist, Internet Society >>> york@isoc.org +1-802-735-1624 >>> Jabber: york@jabber.isoc.org >>> Skype: danyork http://twitter.com/danyork >>>=20 >>> http://www.internetsociety.org/deploy360/ >>>=20 >>>=20 >>>=20 >>>=20 >>> On 10/21/13 9:15 AM, "Brian Rosen" wrote: >>>=20 >>>> 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. >>>>=20 >>>> Brian >>>>=20 >>>> On Oct 20, 2013, at 1:12 AM, Cullen Jennings (fluffy) >>>> >>>> wrote: >>>>=20 >>>>>=20 >>>>> 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. >>>>>=20 >>>>>=20 >>>>> On Oct 2, 2013, at 10:27 AM, Brian Rosen = wrote: >>>>>=20 >>>>>> Sure. >>>>>>=20 >>>>>> Each BPO would have a different private/public key pair. >>>>>>=20 >>>>>> So you can trace which one placed the call. >>>>>>=20 >>>>>> Brian >>>>>>=20 >>>>>> On Oct 2, 2013, at 12:59 PM, Fernando Mousinho (fmousinh) >>>>>> wrote: >>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> 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). >>>>>>>=20 >>>>>>> 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). >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On 9/19/13 9:43 PM, "Brian Rosen" wrote: >>>>>>>=20 >>>>>>>> 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 =46rom (if signed maybe). It also doesn't fit = the >>>>>>>> definition of PAI. >>>>>>>>=20 >>>>>>>> Brian >>>>>>>>=20 >>>>>>>> On Sep 19, 2013, at 9:14 PM, Fernando Mousinho (fmousinh) >>>>>>>> wrote: >>>>>>>>=20 >>>>>>>>> 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. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> On Sep 19, 2013, at 5:39 PM, "Richard Shockey" >>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>> Excellent point a profile or BCP to complement the work. >>>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On >>>>>>>>>> Behalf Of Alex Bobotek >>>>>>>>>> Sent: Thursday, September 19, 2013 5:27 PM >>>>>>>>>> To: Henning Schulzrinne; Michael Hammer; fmousinh@cisco.com; >>>>>>>>>> Gregory.Schumacher@sprint.com; br@brianrosen.net >>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>=20 >>>>>>>>>> +1 >>>>>>>>>> I've assumed that we are headed towards a "sign whatever >>>>>>>>>> extras you wish, and indicate what your signature covers" = mechanism. >>>>>>>>>>=20 >>>>>>>>>> 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. >>>>>>>>>>=20 >>>>>>>>>> Best signing practices may be needed to complement the >>>>>>>>>> standard, and an appropriate place for all but the most = basic >>>>>>>>>> 'what to sign' >>>>>>>>>> recommendations. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Regards, >>>>>>>>>>=20 >>>>>>>>>> Alex >>>>>>>>>>=20 >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] = On >>>>>>>>>>> Behalf Of Henning Schulzrinne >>>>>>>>>>> Sent: Thursday, September 19, 2013 2:24 PM >>>>>>>>>>> To: Michael Hammer; fmousinh@cisco.com; >>>>>>>>>>> Gregory.Schumacher@sprint.com; br@brianrosen.net >>>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>>=20 >>>>>>>>>>> I see no reason not to allow signing any number-related = field >>>>>>>>>>> in the SIP request. (Signing may well be done by different >>>>>>>>>>> parties.) >>>>>>>>>>>=20 >>>>>>>>>>> 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. >>>>>>>>>>>=20 >>>>>>>>>>> ________________________________________ >>>>>>>>>>> From: stir-bounces@ietf.org [stir-bounces@ietf.org] on = behalf >>>>>>>>>>> of Michael Hammer [michael.hammer@yaanatech.com] >>>>>>>>>>> Sent: Thursday, September 19, 2013 4:34 PM >>>>>>>>>>> To: fmousinh@cisco.com; Gregory.Schumacher@sprint.com; >>>>>>>>>>> br@brianrosen.net >>>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>>=20 >>>>>>>>>>> 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." >>>>>>>>>>>=20 >>>>>>>>>>> Originating number, display number, and call-back number >>>>>>>>>>> could be >>>>>>>>>>> 3 >>>>>>>>>>> different things. >>>>>>>>>>> Should all of them be verifiable? >>>>>>>>>>>=20 >>>>>>>>>>> Mike >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] = On >>>>>>>>>>> Behalf Of Fernando Mousinho (fmousinh) >>>>>>>>>>> Sent: Thursday, September 19, 2013 4:00 PM >>>>>>>>>>> To: Schumacher, Gregory [CTO]; Brian Rosen >>>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>>=20 >>>>>>>>>>> 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. >>>>>>>>>>>=20 >>>>>>>>>>> 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. >>>>>>>>>>>=20 >>>>>>>>>>> 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. >>>>>>>>>>>=20 >>>>>>>>>>> On a different note, it would help a lot of we standardized >>>>>>>>>>> terminology. >>>>>>>>>>> Telemarketing, BPO, call center, end customer, clients=8A it >>>>>>>>>>> may be hard for others to follow the discussion later. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> (generic term for any type of outbound calling, including >>>>>>>>>>> public service announcement, so don't think it's all about >>>>>>>>>>> sales!) >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> On 9/19/13 3:22 PM, "Schumacher, Gregory [CTO]" >>>>>>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> There are some benefits from this approach, but also some >>>>>>>>>>>> scenarios that need clarification how they could function. >>>>>>>>>>>>=20 >>>>>>>>>>>> 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. >>>>>>>>>>>>=20 >>>>>>>>>>>> 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? >>>>>>>>>>>>=20 >>>>>>>>>>>> - How is the SP supposed to know all the parties that it is >>>>>>>>>>>> attesting to >>>>>>>>>>>> - the responsible party and/or executing party? >>>>>>>>>>>>=20 >>>>>>>>>>>> -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? >>>>>>>>>>>>=20 >>>>>>>>>>>> - 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. >>>>>>>>>>>>=20 >>>>>>>>>>>> -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. >>>>>>>>>>>>=20 >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] >>>>>>>>>>>> On Behalf Of Brian Rosen >>>>>>>>>>>> Sent: Tuesday, September 17, 2013 9:44 AM >>>>>>>>>>>> To: Fernando Mousinho >>>>>>>>>>>> Cc: stir@ietf.org; Hadriel Kaplan >>>>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>>>=20 >>>>>>>>>>>> We have a requirement to support the BPO use case. >>>>>>>>>>>>=20 >>>>>>>>>>>> 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. >>>>>>>>>>>>=20 >>>>>>>>>>>> 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 >>>>>>>>>>>>=20 >>>>>>>>>>>> NANPA and the PA never are in a call path, so they would >>>>>>>>>>>> never sign a call. >>>>>>>>>>>>=20 >>>>>>>>>>>> However, SP A or SP B could sign a call from either Company >>>>>>>>>>>> C or BPO D using the credential they have. >>>>>>>>>>>>=20 >>>>>>>>>>>> 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. >>>>>>>>>>>>=20 >>>>>>>>>>>> Brian >>>>>>>>>>>>=20 >>>>>>>>>>>> On Sep 17, 2013, at 8:46 AM, Fernando Mousinho (fmousinh) >>>>>>>>>>>> wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>> 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. >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> 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. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> 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". >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Fernando >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On 9/16/13 12:12 PM, "Hadriel Kaplan" >>>>>>>>>>>>> >>>>>>>>>>> wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> 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. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> -hadriel >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On Sep 16, 2013, at 9:49 AM, Fernando Mousinho (fmousinh) >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> 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. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> 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. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Fernando Mousinho >>>>>>>>>>>>>>> Cisco Systems >>>>>>>>>>>>>=20 >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> stir mailing list >>>>>>>>>>>>> stir@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> stir mailing list >>>>>>>>>>>> stir@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> ________________________________ >>>>>>>>>>>>=20 >>>>>>>>>>>> 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. >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> stir mailing list >>>>>>>>>>>> stir@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> stir mailing list >>>>>>>>>>> stir@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> stir mailing list >>>>>>>>>>> stir@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>> _______________________________________________ >>>>>>>>>> stir mailing list >>>>>>>>>> stir@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> stir mailing list >>>>>> stir@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> stir mailing list >>>> stir@ietf.org >>>> https://www.ietf.org/mailman/listinfo/stir >>>=20 >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >>>=20 >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >>>=20 >>> _______________________________________________ >>> cnit mailing list >>> cnit@ietf.org >>> https://www.ietf.org/mailman/listinfo/cnit >>=20 >=20 >=20 >=20 > ________________________________ >=20 > 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. >=20 From Henning.Schulzrinne@fcc.gov Thu Oct 31 11:40:57 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD9621E8114 for ; Thu, 31 Oct 2013 11:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.724 X-Spam-Level: X-Spam-Status: No, score=-0.724 tagged_above=-999 required=5 tests=[AWL=-0.425, BAYES_00=-2.599, MANGLED_COMPNY=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EpiiVC9vGiQd for ; Thu, 31 Oct 2013 11:40:53 -0700 (PDT) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id CA32921E8118 for ; Thu, 31 Oct 2013 11:40:52 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "'Gorman, Pierce A [NTK]'" , Brian Rosen , Richard Shockey Thread-Topic: [cnit] [stir] Application servers - Re: Call Center Implications Thread-Index: AQHO1mYuOzeKvr6NQUyldyFcb1Y5J5oPI50Q Date: Thu, 31 Oct 2013 18:40:35 +0000 References: <32C55AFE-FA17-4776-AD91-259AD3E226BE@brianrosen.net> <024001ced5a2$f3268810$d9739830$@shockey.us> <029501ced5b5$8fa9f480$aefddd80$@shockey.us> <2AA32171-1AE3-4AEE-AEDC-B2031562B7BD@brianrosen.net> <00d901ced637$9e8143a0$db83cae0$@shockey.us> <8B0027B8-D777-48F3-B5BF-B8F81F038E37@brianrosen.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cnit@ietf.org" , "Schumacher, Gregory \[CTO\]" Subject: Re: [cnit] [stir] Application servers - Re: Call Center Implications X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 18:40:57 -0000 There are probably two cases: * by number only, for non-VoIP calls, as an addition to the CNAM model. Kin= d of like a whois for phone numbers. * for end-to-end SIP, as per my previous message (by Call-Info) I agree that reference is probably better than value, given size and the co= mmon case that the same information is transmitted for lots of calls (e.g.,= alert calls that reach every employee in a company). Call-Info could handl= e either, by a pointer to the MIME body (cid:). Henning -----Original Message----- From: cnit-bounces@ietf.org [mailto:cnit-bounces@ietf.org] On Behalf Of Gor= man, Pierce A [NTK] Sent: Thursday, October 31, 2013 2:22 PM To: Brian Rosen; Richard Shockey Cc: cnit@ietf.org; Schumacher, Gregory [CTO] Subject: Re: [cnit] [stir] Application servers - Re: Call Center Implicatio= ns I'm not sure I'd say the CNAM business model is broken if there are CNAM pr= oviders making a profit. :-) To be a little more serious, there is value in using content indirection (w= hich is the CNAM model). The verified calling ID (assuming STIR will be su= ccessful) would be a lightweight pointer to content a UA might like to pres= ent or see/hear. With respect to how to pass additional information in SIP= (including content), IMHO it might be easier to add something like a 2nd m= essage body with (verified?) XML or URI, et cetera, than to try to add new = SIP headers or change handling for parts of existing headers such as the di= splay name. (The B2BUAs in many softswitches simply discard display name.) Best regards, Pierce Gorman Voice Architecture Core Planning/Sprint 913-439-4368 (Desk) -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: October 31, 2013 12:19 PM To: Richard Shockey Cc: cnit@ietf.org; DISPATCH Subject: Re: [cnit] [stir] Application servers - Re: Call Center Implicatio= ns I think the issue is whether we think what is usually called "contact" info= rmation is reasonable to send on every call. I do think if we were to do anything like that, we would do it with xCard a= nd 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 automati= c sending. I am very interested in working on improving caller name. Brian On Oct 31, 2013, at 8:49 AM, Richard Shockey wrote: > > 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=20 > accuracy, reliability and the amount of data that is delivered to the=20 > CUA over who is attempting to establish a session. > > The larger issue is the integrity of the entire real time=20 > communications system as it moves to an all IP world. Irrespective if=20 > CNAM it is delivered as part of From: or PAI its not very useful to the c= onsumer. > > CNAM as it is currently defined in SS7 is a terrible service. 15=20 > Character ASCII. No support for International character sets the usual. > > It is not a hard stretch to postulate that called parties might like a=20 > richer set of data displayed on their UA's and that can be delivered=20 > by the SIP headers in some relatively simple form. Modification of the=20 > Call-Info header for instance. It is equally not a stretch to think=20 > that National Regulators would be delighted with consumers having a=20 > richer set of information displayed on their handsets in order to make=20 > more decisions. In addition if we can achieve better all IP to IP=20 > interconnection among providers it would be really really useful if=20 > Enterprise systems could extract more data from their internal=20 > directory systems and pass that along in the new format for enterprise c= alling as well. > > I would certainly argue that we are not going to see ubiquitous Point=20 > to Point video calling using WebRTC or SIP if there is not better=20 > display of calling party information. > > In addition network operators could insert other 'hints' as to the=20 > nature of the session based on its ability to validate the Caller ID=20 > or other forms on analysis. > > I'm well aware of how CNAM is delivered in North America and I'm=20 > equally aware the CNAM business model is broken. > > What I'd like to know is what interest there is in this proposition=20 > and are there parties interested in working on it in advance of say Londo= n. > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, October 30, 2013 5:39 PM > To: Richard Shockey > Cc: cnit@ietf.org > Subject: Re: [cnit] [stir] Application servers - Re: Call Center=20 > 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=20 > part of the uri to carry a caller name, which is put on the call by=20 > the origination side, and signed as the number is. > > That is a significant change to the current infrastructure, which at=20 > least in North America relies on a termination service provider dip in=20 > an origination service provider database, but it seems feasible to=20 > consider that. > > Brian > > On Oct 30, 2013, at 5:18 PM, Richard Shockey wrote: > >> >> Ok since Brian is being picky.. >> >> I'm actually interested if anyone is interested in the possibility of=20 >> making SIP Identity to the UA more useful. >> >> >> >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >> Of Richard Shockey >> Sent: Wednesday, October 30, 2013 3:05 PM >> To: stir@ietf.org >> Subject: Re: [stir] Application servers - Re: Call Center=20 >> Implications >> >> Dan great post. I couldn't agree more. There needs to be some rules her= e. >> Some may be regulatory some may be technical. >> >> First the voice application service providers need to provide the=20 >> terminating CUA, "an accurate and truthful" Caller-ID for the call=20 >> even if it is originated from a source that is not directly=20 >> 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=20 >> RESPORGS. >> >> If the originating UA can prove/assert it is legally authorized to=20 >> use such an identity on behalf of a customer then that is step one. >> The presumption after that is there is some contractual obligation=20 >> between the service provider and the network about the use of such ident= ities. >> The network can then "validate" such an assertion. >> >> There is something larger here to consider. Though the focus of STIR=20 >> is validation of a Caller-ID number at some point the RAI area should=20 >> 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=20 >> emerging requirement that under some cases the calling party wants to=20 >> or should provide more substantive information about themselves to=20 >> the called party and frankly 15 character ASCII is not enough. >> Consumers or businesses should be able to see more complete and=20 >> validated information about the session in order to make an better=20 >> and informed decision on whether to accept the 'call' or not. >> Regulators may want to require telemarketing firms to display NG CNAM=20 >> or CNAM + like data as a condition of doing business. >> >> All of the examples you cite are excellent examples where such=20 >> verbose calling party identification could be displayed. I certainly=20 >> want to answer a call from my doctor on my test results just as I=20 >> wish to ignore a call from Bill Clinton begging me to vote in the=20 >> Virginia Governors election next Tuesday. This is a case where=20 >> 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=20 >> probably a reasonable modification of the Call INFO header in SIP=20 >> with something like a XML based VCARD or JCARD URI whatever and=20 >> probably 3GPP would need to look at how such data is displayed on the=20 >> mobile VoLTE handsets. The network operators would have to understand=20 >> not to modify the contents of such a URI and its source validated but=20 >> that is a task for another day. >> >> >> >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >> Of Dan York >> Sent: Tuesday, October 29, 2013 5:10 PM >> To: Brian Rosen; Cullen Jennings >> Cc: Gregory.Schumacher@sprint.com; Richard Shockey; stir@ietf.org;=20 >> Fernando Mousinho (fmousinh); Alex Bobotek; Michael Hammer; Henning=20 >> Schulzrinne >> Subject: [stir] Application servers - Re: Call Center Implications >> >> Getting caught up on some of the STIR discussions, I'd just note that=20 >> when we talk about "call centers" or "BPOs" we also need to remember=20 >> that we're not only talking about "traditional" call centers but also=20 >> what I'll call "voice application service providers". They are=20 >> generally automated platforms running applications that a company=20 >> uses for some kind of outbound service. Examples include: >> >> - calling everyone in a school district with a weather-related=20 >> cancellation (or, unfortunately, a school shooting or similar event) >> - calling patients to provide reminders of appointments or=20 >> notifications of subscriptions available >> - calling customers to let them know that a package was delivered or=20 >> could be picked up, etc. >> - calling people scheduled for a flight to let know they are going to=20 >> be delayed >> - calling members of an organization with an automated survey about=20 >> current issues >> - performing a call-back to provide an additional layer of=20 >> authentication for some service >> >> There is a large (and growing) market for these kind of automated=20 >> tools and services and the distinction between these calls and=20 >> "robocalls" is really only one of intent and the fact that the=20 >> recipient > has "opted in" >> through some kind of system. >> >> Generally, though, many of the companies want the application to=20 >> appear as if it is coming from their own phone number in the same way=20 >> that they want an outbound call center to appear as if it is coming=20 >> from one of their own phone numbers. >> >> You could think of these in the same way as "call centers", but I=20 >> point this out because some of these new services are very automated=20 >> and there are always new startups now emerging in this space. Some=20 >> of them are very "self-service" where the customer does it all while=20 >> others have teams of people involved. Some of the companies involved=20 >> include Nuance, Microsoft Tellme, Voxeo (now Aspect, and also my=20 >> former employer), Tropo, Twilio, Convergys and many more[1]. >> >> If STIR is to succeed, these kind of application platforms will also=20 >> 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 >> york@isoc.org +1-802-735-1624 >> Jabber: york@jabber.isoc.org >> Skype: danyork http://twitter.com/danyork >> >> http://www.internetsociety.org/deploy360/ >> >> >> >> >> On 10/21/13 9:15 AM, "Brian Rosen" wrote: >> >>> We really need to give each BPO different keys I think. The notion th= at >>> we are sharing private keys among multiple competing entities who=20 >>> provide services for a single enterprise strikes me as a VBI (Very=20 >>> Bad Idea). I can't see any real difficulty in having more than one=20 >>> authorized entity, each with it's own credentials. Who would have a=20 >>> problem? We're already agreeing that there are multiple credentials=20 >>> for a number, because the number gets delegated multiple times. >>> Consider, just as an example, the BPO and the contracting enterprise=20 >>> that was actually delegated the number can both send calls from that=20 >>> number. You certainly don't want the enterprise giving out IT'S key=20 >>> to it's contractors. At best it's a key it authorizes to one or=20 >>> more of it's >> BPOs. >>> >>> Brian >>> >>> On Oct 20, 2013, at 1:12 AM, Cullen Jennings (fluffy)=20 >>> >>> wrote: >>> >>>> >>>> What Fernando is saying makes sense to me a desirable property of=20 >>>> the solution and I agree that if we gave each BPO a different=20 >>>> private key that would solve it but that might be pretty hard to=20 >>>> mange in other ways. I like the requirements but the solution is=20 >>>> not 100% obvious to me. >>>> >>>> >>>> On Oct 2, 2013, at 10:27 AM, Brian Rosen 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)=20 >>>>> 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=20 >>>>>> sign calls on its behalf, is there a way to trace back the=20 >>>>>> originator (specific >>>>>> BPO) >>>>>> later on? I suppose that at some level the actual caller must be=20 >>>>>> exposed (perhaps to trace malicious activity, such as malicious=20 >>>>>> person infiltrated in an otherwise legitimate BPO). >>>>>> >>>>>> Via headers would be the obvious pick, but they don't survive the=20 >>>>>> plethora of SBCs that the call is likely to transverse. Or maybe=20 >>>>>> the certs themselves can carry this type of data (actual caller=20 >>>>>> identity). >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 9/19/13 9:43 PM, "Brian Rosen" 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=20 >>>>>>> change to use From (if signed maybe). It also doesn't fit the=20 >>>>>>> definition of PAI. >>>>>>> >>>>>>> Brian >>>>>>> >>>>>>> On Sep 19, 2013, at 9:14 PM, Fernando Mousinho (fmousinh)=20 >>>>>>> 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=20 >>>>>>>> on the delegation process Rosen mentions. >>>>>>>> PAI's use is widespread, and it's main limitation is being=20 >>>>>>>> spoofable - but this is exactly the problem we are trying to=20 >>>>>>>> solve anyway. >>>>>>>> >>>>>>>> >>>>>>>>> On Sep 19, 2013, at 5:39 PM, "Richard Shockey" >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Excellent point a profile or BCP to complement the work. >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On=20 >>>>>>>>> Behalf Of Alex Bobotek >>>>>>>>> Sent: Thursday, September 19, 2013 5:27 PM >>>>>>>>> To: Henning Schulzrinne; Michael Hammer; fmousinh@cisco.com;=20 >>>>>>>>> Gregory.Schumacher@sprint.com; br@brianrosen.net >>>>>>>>> Cc: stir@ietf.org >>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>> >>>>>>>>> +1 >>>>>>>>> I've assumed that we are headed towards a "sign whatever=20 >>>>>>>>> extras you wish, and indicate what your signature covers" mechani= sm. >>>>>>>>> >>>>>>>>> Based on this, standards would need to identify only a minimal=20 >>>>>>>>> subset of what shall/should be signed, and ensure that any=20 >>>>>>>>> required group of signed items survives transit intact. >>>>>>>>> >>>>>>>>> Best signing practices may be needed to complement the=20 >>>>>>>>> standard, and an appropriate place for all but the most basic=20 >>>>>>>>> 'what to sign' >>>>>>>>> recommendations. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Alex >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On=20 >>>>>>>>>> Behalf Of Henning Schulzrinne >>>>>>>>>> Sent: Thursday, September 19, 2013 2:24 PM >>>>>>>>>> To: Michael Hammer; fmousinh@cisco.com;=20 >>>>>>>>>> Gregory.Schumacher@sprint.com; br@brianrosen.net >>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>> >>>>>>>>>> I see no reason not to allow signing any number-related field=20 >>>>>>>>>> in the SIP request. (Signing may well be done by different >>>>>>>>>> parties.) >>>>>>>>>> >>>>>>>>>> As far as I know, callback numbers (SIP Reply-To) aren't=20 >>>>>>>>>> conveyable in legacy systems, however, so this may be of=20 >>>>>>>>>> somewhat limited use for a >>>>>>>>> while. >>>>>>>>>> >>>>>>>>>> ________________________________________ >>>>>>>>>> From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf=20 >>>>>>>>>> of Michael Hammer [michael.hammer@yaanatech.com] >>>>>>>>>> Sent: Thursday, September 19, 2013 4:34 PM >>>>>>>>>> To: fmousinh@cisco.com; Gregory.Schumacher@sprint.com;=20 >>>>>>>>>> br@brianrosen.net >>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>> >>>>>>>>>> Don't we still want to know the true originator of the call,=20 >>>>>>>>>> even when we have some token that says "Doctor so and so=20 >>>>>>>>>> approved this message." >>>>>>>>>> >>>>>>>>>> Originating number, display number, and call-back number=20 >>>>>>>>>> could be >>>>>>>>>> 3 >>>>>>>>>> different things. >>>>>>>>>> Should all of them be verifiable? >>>>>>>>>> >>>>>>>>>> Mike >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On=20 >>>>>>>>>> Behalf Of Fernando Mousinho (fmousinh) >>>>>>>>>> Sent: Thursday, September 19, 2013 4:00 PM >>>>>>>>>> To: Schumacher, Gregory [CTO]; Brian Rosen >>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>> >>>>>>>>>> I believe the scenario telemarketing here is when a client=20 >>>>>>>>>> hires a BPO to place outbound calls, but expect customers=20 >>>>>>>>>> to return these calls to a different place (say, their own=20 >>>>>>>>>> and operated call center). This way, this client is=20 >>>>>>>>>> authorizing the BPO to use an identity that it >>>>>>>>>> (BPO) >>>>>>>>> doesn't own. >>>>>>>>>> These numbers in this scenario are always operational, just=20 >>>>>>>>>> at a different place. >>>>>>>>>> >>>>>>>>>> The same telemarketing operator would then outpulse multiple=20 >>>>>>>>>> numbers for their multiple clients, none of these numbers=20 >>>>>>>>>> belonging to the >>>>>>>>> telemarketer. >>>>>>>>>> BTW, we are using the term "telemarketing" in a very generic=20 >>>>>>>>>> sense - this could just as easily be a public service=20 >>>>>>>>>> announcement, fundraiser, >>>>>>>>> etc. >>>>>>>>>> >>>>>>>>>> If the telemarketer happens to own the inbound call center as=20 >>>>>>>>>> well, it very likely owns the number as well and this would=20 >>>>>>>>>> necessarily be a special case >>>>>>>>>> - it would fall under the same characteristics of any call cente= r. >>>>>>>>>> >>>>>>>>>> On a different note, it would help a lot of we standardized=20 >>>>>>>>>> terminology. >>>>>>>>>> Telemarketing, BPO, call center, end customer, clients=A9 it=20 >>>>>>>>>> may be hard for others to follow the discussion later. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> (generic term for any type of outbound calling, including=20 >>>>>>>>>> public service announcement, so don't think it's all about >>>>>>>>>> sales!) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 9/19/13 3:22 PM, "Schumacher, Gregory [CTO]" >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> There are some benefits from this approach, but also some=20 >>>>>>>>>>> scenarios that need clarification how they could function. >>>>>>>>>>> >>>>>>>>>>> The benefit is that the credential represents both the=20 >>>>>>>>>>> company "responsible" for the sales campaign (the "company" >>>>>>>>>>> in your >>>>>>>>>>> scenario) >>>>>>>>>>> and the company operating the sales campaign (the call=20 >>>>>>>>>>> center in your scenario). For the use in forensics (after=20 >>>>>>>>>>> the fact >>>>>>>>>>> analysis) such as pursuit of fraud investigation, we then=20 >>>>>>>>>>> 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=20 >>>>>>>>>>> telemarketing campaign or both? >>>>>>>>>>> >>>>>>>>>>> - How is the SP supposed to know all the parties that it is=20 >>>>>>>>>>> attesting to >>>>>>>>>>> - the responsible party and/or executing party? >>>>>>>>>>> >>>>>>>>>>> -It seems likely that some of the numbers assigned to a=20 >>>>>>>>>>> company in your scenario will not be assigned to real=20 >>>>>>>>>>> telephones (or call center >>>>>>>>>>> trunk) until a telemarketing campaign is initiated or a call=20 >>>>>>>>>>> center selected to execute the sales campaign, is it=20 >>>>>>>>>>> possible to have these unassigned or floating numbers when=20 >>>>>>>>>>> not in use for a telemarketing campaign? Is it allowed=20 >>>>>>>>>>> under most national numbering regimes? >>>>>>>>>>> >>>>>>>>>>> - How important is it to have a known or recognized phone=20 >>>>>>>>>>> number as the caller id as part of a telemarketing campaign? >>>>>>>>>>> I am assuming that not all campaigns care about having a=20 >>>>>>>>>>> number that is known or >>>>>>>>> recognized. >>>>>>>>>>> >>>>>>>>>>> -In other words for this last bit, if a call center=20 >>>>>>>>>>> (telemarketing campaign operator) is using their own set of=20 >>>>>>>>>>> numbers but serve multiple simultaneous telemarketing=20 >>>>>>>>>>> campaigns using the same originating numbers, what will=20 >>>>>>>>>>> they sign? Will they just have a credential representing=20 >>>>>>>>>>> the call center alone, or a different credential per=20 >>>>>>>>>>> telemarketing campaign, or a different credential per=20 >>>>>>>>>>> responsible party (per client)? This will affect what is=20 >>>>>>>>>>> possible for >>>>>>>>> any forensic activity. >>>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org]=20 >>>>>>>>>>> On Behalf Of Brian Rosen >>>>>>>>>>> Sent: Tuesday, September 17, 2013 9:44 AM >>>>>>>>>>> To: Fernando Mousinho >>>>>>>>>>> Cc: stir@ietf.org; 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=20 >>>>>>>>>>> center approves the use, and the call center, or the SP=20 >>>>>>>>>>> acting on its behalf, signs. >>>>>>>>>>> Think of this as another level of delegation. An SP=20 >>>>>>>>>>> delegates numbers to the company. The company "delegates" >>>>>>>>>>> use of those numbers to the call center. The call center=20 >>>>>>>>>>> calls, using that delegation. >>>>>>>>>>> The credentials of the call center would be different from=20 >>>>>>>>>>> those of the company, but would cover the same number. >>>>>>>>>>> Having multiple credentials covering the same number will=20 >>>>>>>>>>> be very common due to the way delegation happens. In order=20 >>>>>>>>>>> to allow SPs to sign, without creating credential per TN,=20 >>>>>>>>>>> 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=20 >>>>>>>>>>> 202-555-xxxx to the Pooling Administrator. The PA now has=20 >>>>>>>>>>> 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=20 >>>>>>>>>>> 202-555-12xx to SP B . >>>>>>>>>>> SP B has a credential for a 100 TN block SP B delegates=20 >>>>>>>>>>> 202-555-123x to Company C. Company C has a credential for=20 >>>>>>>>>>> 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=20 >>>>>>>>>>> never sign a call. >>>>>>>>>>> >>>>>>>>>>> However, SP A or SP B could sign a call from either Company=20 >>>>>>>>>>> C or BPO D using the credential they have. >>>>>>>>>>> >>>>>>>>>>> The SP for the call center could acquire credentials from=20 >>>>>>>>>>> the BPO and sign on its behalf. I suspect than many=20 >>>>>>>>>>> service providers would be reluctant to do so unless the=20 >>>>>>>>>>> numbers were from their own inventory (that is, the company=20 >>>>>>>>>>> got its numbers from the same SP as the call >>>>>>>>> center). >>>>>>>>>>> Since that won't be the common case, the call center=20 >>>>>>>>>>> probably has to do the signing itself. >>>>>>>>>>> >>>>>>>>>>> Brian >>>>>>>>>>> >>>>>>>>>>> On Sep 17, 2013, at 8:46 AM, Fernando Mousinho (fmousinh)=20 >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> I agree, Hadriel. While large call centers (including BPOs,=20 >>>>>>>>>>>> which provide services for other companies) may have=20 >>>>>>>>>>>> special arrangements with SPs, the majority (small to >>>>>>>>>>>> mid-size) will probably rely on the SPs to do provide to=20 >>>>>>>>>>>> vouch for their identity. This would probably be the case=20 >>>>>>>>>>>> for the home analog caller anyway. This would imply that=20 >>>>>>>>>>>> the "originating" SP's willingness to provide this=20 >>>>>>>>>>>> signature is a critical success factor for the proposal's > adoption. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> But back to the business process outsourcers (BPO) case -=20 >>>>>>>>>>>> where a call center is providing service on behalf of=20 >>>>>>>>>>>> multiple companies. I can see the value of them sending=20 >>>>>>>>>>>> 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=20 >>>>>>>>>>>> that SP >>>>>>>>>>>> 1 allowing one of its subscribers to send an outbound call=20 >>>>>>>>>>>> using a number registered to SP 2 could be a no-no. If=20 >>>>>>>>>>>> this hypothesis is correct, then we are back to the case=20 >>>>>>>>>>>> where the SP is signing all calls, >>>>>>>>>> even for BPOs. >>>>>>>>>>>> >>>>>>>>>>>> Or maybe this is another problem we are trying to fix in=20 >>>>>>>>>>>> the working group, in which case we perhaps should state as=20 >>>>>>>>>>>> a goal or >>>>>>>>> benefit: >>>>>>>>>>>> "providing a reliable mechanism to let calls originated=20 >>>>>>>>>>>> from one >>>>>>>>>>>> SP1 to outpulse numbers that belong to another". >>>>>>>>>>>> >>>>>>>>>>>> Fernando >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 9/16/13 12:12 PM, "Hadriel Kaplan" >>>>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Any of them could do it. My guess is service providers=20 >>>>>>>>>>>>> will do it for most call centers, although larger call=20 >>>>>>>>>>>>> centers might do it themselves... >>>>>>>>>>>>> especially ones which have trunks from multiple providers=20 >>>>>>>>>>>>> and can source calls using the same number(s) out through=20 >>>>>>>>>>>>> multiple providers on a call-by-call basis. >>>>>>>>>>>>> >>>>>>>>>>>>> -hadriel >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Sep 16, 2013, at 9:49 AM, Fernando Mousinho (fmousinh)=20 >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> I'm catching up with the discussions in this working=20 >>>>>>>>>>>>>> group, and am trying to understand some architecture=20 >>>>>>>>>>>>>> implications in call centers (which is where my=20 >>>>>>>>>>>>>> background is). It seems that many of the problems we=20 >>>>>>>>>>>>>> are trying to fix are related to contact centers anyway,=20 >>>>>>>>>>>>>> so it is probably a good idea to have everyone in the=20 >>>>>>>>>>>>>> same >>>>>>>>>> page. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Forgive me if it is an obvious question, but which=20 >>>>>>>>>>>>>> components in a "typical call center architecture" do=20 >>>>>>>>>>>>>> you see signature and verification taking place? Such "typi= cal" >>>>>>>>>>>>>> deployments have premises based equipment (PME), a=20 >>>>>>>>>>>>>> session border controller >>>>>>>>>>>>>> (SBC) >>>>>>>>>>>>>> and of course a SIP service provider all three could=20 >>>>>>>>>>>>>> potentially be used throughout the authorization process. >>>>>>>>>>>>>> There are different ramifications depending on where=20 >>>>>>>>>>>>>> your mind is at. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Fernando Mousinho >>>>>>>>>>>>>> Cisco Systems >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> stir mailing list >>>>>>>>>>>> stir@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> stir mailing list >>>>>>>>>>> stir@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ________________________________ >>>>>>>>>>> >>>>>>>>>>> This e-mail may contain Sprint proprietary information=20 >>>>>>>>>>> intended for the sole use of the recipient(s). Any use by=20 >>>>>>>>>>> others is prohibited. >>>>>>>>>>> If >>>>>>>>>>> you are not the intended recipient, please contact the=20 >>>>>>>>>>> sender and delete all copies of the message. >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> stir mailing list >>>>>>>>>>> stir@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> stir mailing list >>>>>>>>>> stir@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>> _______________________________________________ >>>>>>>>>> stir mailing list >>>>>>>>>> stir@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>> _______________________________________________ >>>>>>>>> stir mailing list >>>>>>>>> stir@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> stir mailing list >>>>> stir@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/stir >>>> >>> >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >> >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >> >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >> >> _______________________________________________ >> cnit mailing list >> cnit@ietf.org >> https://www.ietf.org/mailman/listinfo/cnit > ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e 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. _______________________________________________ cnit mailing list cnit@ietf.org https://www.ietf.org/mailman/listinfo/cnit From richard@shockey.us Thu Oct 31 14:34:09 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C151D11E826D for ; Thu, 31 Oct 2013 14:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.179 X-Spam-Level: X-Spam-Status: No, score=-101.179 tagged_above=-999 required=5 tests=[AWL=-1.214, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MANGLED_COMPNY=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7M6RpbxLGrJ for ; Thu, 31 Oct 2013 14:34:04 -0700 (PDT) Received: from oproxy13-pub.mail.unifiedlayer.com (oproxy13-pub.mail.unifiedlayer.com [69.89.16.30]) by ietfa.amsl.com (Postfix) with SMTP id 1306611E8261 for ; Thu, 31 Oct 2013 14:33:35 -0700 (PDT) Received: (qmail 19129 invoked by uid 0); 31 Oct 2013 21:33:09 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy13.mail.unifiedlayer.com with SMTP; 31 Oct 2013 21:33:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=LdbuowNHufpaX/WZkhXqZ/JfE9P3E5uUrY7xWGHLmsw=; b=SYoc+WuipIeFIuaMc326JXAiaRUg2NQsslJcTZ2i2b3V9ry5MdIZgTigTVzO2wFGKH1yk6Jsw9whGf+Js+Qw5dBtawQvCzIoAQ/SpD+x7t0f4i2nxtDn6as3MyBMxGni; Received: from [173.79.179.104] (port=54345 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VbzrY-0002OE-5x; Thu, 31 Oct 2013 15:33:08 -0600 From: "Richard Shockey" To: "'Brian Rosen'" References: <32C55AFE-FA17-4776-AD91-259AD3E226BE@brianrosen.net> <024001ced5a2$f3268810$d9739830$@shockey.us> <029501ced5b5$8fa9f480$aefddd80$@shockey.us> <2AA32171-1AE3-4AEE-AEDC-B2031562B7BD@brianrosen.net> <00d901ced637$9e8143a0$db83cae0$@shockey.us> <8B0027B8-D777-48F3-B5BF-B8F81F038E37@brianrosen.net> In-Reply-To: <8B0027B8-D777-48F3-B5BF-B8F81F038E37@brianrosen.net> Date: Thu, 31 Oct 2013 17:33:07 -0400 Message-ID: <020a01ced680$caf4ec90$60dec5b0$@shockey.us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQLTdCvgrcMvmbDsv2xAt2r4G5TZbQLC46EgAqz016cBpe129QIWVK8PAdOJjcEBFampjJela41g X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.79.179.104 authed with richard@shockey.us} Cc: cnit@ietf.org, 'DISPATCH' Subject: Re: [cnit] [stir] Application servers - Re: Call Center Implications X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 21:34:09 -0000 -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Thursday, October 31, 2013 1:19 PM To: Richard Shockey Cc: cnit@ietf.org; DISPATCH Subject: Re: [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. [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.=20 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. [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.=20 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.=20 I am very interested in working on improving caller name. [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. =20 Brian On Oct 31, 2013, at 8:49 AM, Richard Shockey wrote: >=20 > Brian please.. Look at the mail. I'm using the CNIT list. =20 >=20 > The issue is can we use the tools at hand to increase both the=20 > accuracy, reliability and the amount of data that is delivered to the=20 > CUA over who is attempting to establish a session. >=20 > The larger issue is the integrity of the entire real time=20 > 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. >=20 > CNAM as it is currently defined in SS7 is a terrible service. 15=20 > Character ASCII. No support for International character sets the = usual. >=20 > 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=20 > 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=20 > that National Regulators would be delighted with consumers having a=20 > 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=20 > interconnection among providers it would be really really useful if=20 > Enterprise systems could extract more data from their internal=20 > directory systems and pass that along in the new format for = enterprise calling as well. >=20 > I would certainly argue that we are not going to see ubiquitous Point=20 > to Point video calling using WebRTC or SIP if there is not better=20 > display of calling party information. >=20 > In addition network operators could insert other 'hints' as to the=20 > nature of the session based on its ability to validate the Caller ID=20 > or other forms on analysis. >=20 > I'm well aware of how CNAM is delivered in North America and I'm=20 > equally aware the CNAM business model is broken. >=20 > What I'd like to know is what interest there is in this proposition=20 > and are there parties interested in working on it in advance of say London. >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, October 30, 2013 5:39 PM > To: Richard Shockey > Cc: cnit@ietf.org > Subject: Re: [cnit] [stir] Application servers - Re: Call Center=20 > Implications >=20 > More useful in what way? Improving the reliability of caller name? =20 > Please use the cnit list to discuss this. >=20 > 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=20 > the origination side, and signed as the number is. >=20 > That is a significant change to the current infrastructure, which at=20 > least in North America relies on a termination service provider dip in = > an origination service provider database, but it seems feasible to=20 > consider that. >=20 > Brian >=20 > On Oct 30, 2013, at 5:18 PM, Richard Shockey = wrote: >=20 >>=20 >> Ok since Brian is being picky.. >>=20 >> I'm actually interested if anyone is interested in the possibility of = >> making SIP Identity to the UA more useful. >>=20 >>=20 >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >> Of Richard Shockey >> Sent: Wednesday, October 30, 2013 3:05 PM >> To: stir@ietf.org >> Subject: Re: [stir] Application servers - Re: Call Center=20 >> Implications >>=20 >> Dan great post. I couldn't agree more. There needs to be some rules here. >> Some may be regulatory some may be technical. >>=20 >> First the voice application service providers need to provide the=20 >> terminating CUA, "an accurate and truthful" Caller-ID for the call=20 >> even if it is originated from a source that is not directly=20 >> 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=20 >> RESPORGS. >>=20 >> If the originating UA can prove/assert it is legally authorized to=20 >> use such an identity on behalf of a customer then that is step one. =20 >> The presumption after that is there is some contractual obligation=20 >> between the service provider and the network about the use of such identities. >> The network can then "validate" such an assertion. >>=20 >> 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. =20 >>=20 >> 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=20 >> the called party and frankly 15 character ASCII is not enough.=20 >> Consumers or businesses should be able to see more complete and=20 >> validated information about the session in order to make an better=20 >> and informed decision on whether to accept the 'call' or not. =20 >> Regulators may want to require telemarketing firms to display NG CNAM = >> or CNAM + like data as a condition of doing business. >>=20 >> All of the examples you cite are excellent examples where such=20 >> verbose calling party identification could be displayed. I certainly = >> want to answer a call from my doctor on my test results just as I=20 >> wish to ignore a call from Bill Clinton begging me to vote in the=20 >> Virginia Governors election next Tuesday. This is a case where=20 >> annominity is not a > good idea. >>=20 >>=20 >> All you need now is a little standardization. >> Technically this should is very easy to understand in SIP. It would=20 >> probably a reasonable modification of the Call INFO header in SIP=20 >> with something like a XML based VCARD or JCARD URI whatever and=20 >> 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. >>=20 >>=20 >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >> Of Dan York >> Sent: Tuesday, October 29, 2013 5:10 PM >> To: Brian Rosen; Cullen Jennings >> Cc: Gregory.Schumacher@sprint.com; Richard Shockey; stir@ietf.org;=20 >> Fernando Mousinho (fmousinh); Alex Bobotek; Michael Hammer; Henning=20 >> Schulzrinne >> Subject: [stir] Application servers - Re: Call Center Implications >>=20 >> 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=20 >> that we're not only talking about "traditional" call centers but also = >> what I'll call "voice application service providers". They are=20 >> generally automated platforms running applications that a company=20 >> uses for some kind of outbound service. Examples include: >>=20 >> - calling everyone in a school district with a weather-related=20 >> cancellation (or, unfortunately, a school shooting or similar event) >> - calling patients to provide reminders of appointments or=20 >> notifications of subscriptions available >> - calling customers to let them know that a package was delivered or=20 >> 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=20 >> current issues >> - performing a call-back to provide an additional layer of=20 >> authentication for some service >>=20 >> There is a large (and growing) market for these kind of automated=20 >> tools and services and the distinction between these calls and=20 >> "robocalls" is really only one of intent and the fact that the=20 >> recipient > has "opted in" >> through some kind of system. >>=20 >> Generally, though, many of the companies want the application to=20 >> 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=20 >> from one of their own phone numbers. >>=20 >> You could think of these in the same way as "call centers", but I=20 >> point this out because some of these new services are very automated=20 >> and there are always new startups now emerging in this space. Some=20 >> of them are very "self-service" where the customer does it all while=20 >> others have teams of people involved. Some of the companies involved = >> include Nuance, Microsoft Tellme, Voxeo (now Aspect, and also my=20 >> former employer), Tropo, Twilio, Convergys and many more[1]. >>=20 >> If STIR is to succeed, these kind of application platforms will also=20 >> need to be able to make calls on behalf of the companies using those > platforms. >>=20 >> Dan >>=20 >> [1] One report about this market: >> http://www.voxeo.com/pdf/OvumDecisionMatrix-2011.pdf >>=20 >>=20 >> -- >> Dan York >> Senior Content Strategist, Internet Society >> york@isoc.org +1-802-735-1624 >> Jabber: york@jabber.isoc.org >> Skype: danyork http://twitter.com/danyork >>=20 >> http://www.internetsociety.org/deploy360/ >>=20 >>=20 >>=20 >>=20 >> On 10/21/13 9:15 AM, "Brian Rosen" wrote: >>=20 >>> We really need to give each BPO different keys I think. The notion that >>> we are sharing private keys among multiple competing entities who=20 >>> provide services for a single enterprise strikes me as a VBI (Very=20 >>> Bad Idea). I can't see any real difficulty in having more than one=20 >>> 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=20 >>> more of it's >> BPOs. >>>=20 >>> Brian >>>=20 >>> On Oct 20, 2013, at 1:12 AM, Cullen Jennings (fluffy)=20 >>> >>> wrote: >>>=20 >>>>=20 >>>> What Fernando is saying makes sense to me a desirable property of=20 >>>> the solution and I agree that if we gave each BPO a different=20 >>>> private key that would solve it but that might be pretty hard to=20 >>>> mange in other ways. I like the requirements but the solution is=20 >>>> not 100% obvious to me. >>>>=20 >>>>=20 >>>> On Oct 2, 2013, at 10:27 AM, Brian Rosen wrote: >>>>=20 >>>>> Sure. >>>>>=20 >>>>> Each BPO would have a different private/public key pair. >>>>>=20 >>>>> So you can trace which one placed the call. >>>>>=20 >>>>> Brian >>>>>=20 >>>>> On Oct 2, 2013, at 12:59 PM, Fernando Mousinho (fmousinh)=20 >>>>> wrote: >>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> If the company hires several BPOs and authorizes all of them to=20 >>>>>> sign calls on its behalf, is there a way to trace back the=20 >>>>>> originator (specific >>>>>> BPO) >>>>>> later on? I suppose that at some level the actual caller must be=20 >>>>>> exposed (perhaps to trace malicious activity, such as malicious=20 >>>>>> person infiltrated in an otherwise legitimate BPO). >>>>>>=20 >>>>>> 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=20 >>>>>> identity). >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 9/19/13 9:43 PM, "Brian Rosen" wrote: >>>>>>=20 >>>>>>> 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=20 >>>>>>> change to use From (if signed maybe). It also doesn't fit the=20 >>>>>>> definition of PAI. >>>>>>>=20 >>>>>>> Brian >>>>>>>=20 >>>>>>> On Sep 19, 2013, at 9:14 PM, Fernando Mousinho (fmousinh)=20 >>>>>>> wrote: >>>>>>>=20 >>>>>>>> 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=20 >>>>>>>> on the delegation process Rosen mentions. >>>>>>>> PAI's use is widespread, and it's main limitation is being=20 >>>>>>>> spoofable - but this is exactly the problem we are trying to=20 >>>>>>>> solve anyway. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> On Sep 19, 2013, at 5:39 PM, "Richard Shockey"=20 >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>> Excellent point a profile or BCP to complement the work. >>>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On=20 >>>>>>>>> Behalf Of Alex Bobotek >>>>>>>>> Sent: Thursday, September 19, 2013 5:27 PM >>>>>>>>> To: Henning Schulzrinne; Michael Hammer; fmousinh@cisco.com;=20 >>>>>>>>> Gregory.Schumacher@sprint.com; br@brianrosen.net >>>>>>>>> Cc: stir@ietf.org >>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>=20 >>>>>>>>> +1 >>>>>>>>> I've assumed that we are headed towards a "sign whatever=20 >>>>>>>>> extras you wish, and indicate what your signature covers" mechanism. >>>>>>>>>=20 >>>>>>>>> Based on this, standards would need to identify only a minimal = >>>>>>>>> subset of what shall/should be signed, and ensure that any=20 >>>>>>>>> required group of signed items survives transit intact. >>>>>>>>>=20 >>>>>>>>> Best signing practices may be needed to complement the=20 >>>>>>>>> standard, and an appropriate place for all but the most basic = >>>>>>>>> 'what to sign' >>>>>>>>> recommendations. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Regards, >>>>>>>>>=20 >>>>>>>>> Alex >>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On = >>>>>>>>>> Behalf Of Henning Schulzrinne >>>>>>>>>> Sent: Thursday, September 19, 2013 2:24 PM >>>>>>>>>> To: Michael Hammer; fmousinh@cisco.com;=20 >>>>>>>>>> Gregory.Schumacher@sprint.com; br@brianrosen.net >>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>=20 >>>>>>>>>> I see no reason not to allow signing any number-related field = >>>>>>>>>> in the SIP request. (Signing may well be done by different >>>>>>>>>> parties.) >>>>>>>>>>=20 >>>>>>>>>> As far as I know, callback numbers (SIP Reply-To) aren't=20 >>>>>>>>>> conveyable in legacy systems, however, so this may be of=20 >>>>>>>>>> somewhat limited use for a >>>>>>>>> while. >>>>>>>>>>=20 >>>>>>>>>> ________________________________________ >>>>>>>>>> From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf = >>>>>>>>>> of Michael Hammer [michael.hammer@yaanatech.com] >>>>>>>>>> Sent: Thursday, September 19, 2013 4:34 PM >>>>>>>>>> To: fmousinh@cisco.com; Gregory.Schumacher@sprint.com;=20 >>>>>>>>>> br@brianrosen.net >>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>=20 >>>>>>>>>> Don't we still want to know the true originator of the call,=20 >>>>>>>>>> even when we have some token that says "Doctor so and so=20 >>>>>>>>>> approved this message." >>>>>>>>>>=20 >>>>>>>>>> Originating number, display number, and call-back number=20 >>>>>>>>>> could be >>>>>>>>>> 3 >>>>>>>>>> different things. >>>>>>>>>> Should all of them be verifiable? >>>>>>>>>>=20 >>>>>>>>>> Mike >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On = >>>>>>>>>> Behalf Of Fernando Mousinho (fmousinh) >>>>>>>>>> Sent: Thursday, September 19, 2013 4:00 PM >>>>>>>>>> To: Schumacher, Gregory [CTO]; Brian Rosen >>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>=20 >>>>>>>>>> I believe the scenario telemarketing here is when a client=20 >>>>>>>>>> hires a BPO to place outbound calls, but expect customers=20 >>>>>>>>>> to return these calls to a different place (say, their own=20 >>>>>>>>>> and operated call center). This way, this client is=20 >>>>>>>>>> authorizing the BPO to use an identity that it >>>>>>>>>> (BPO) >>>>>>>>> doesn't own. >>>>>>>>>> These numbers in this scenario are always operational, just=20 >>>>>>>>>> at a different place. >>>>>>>>>>=20 >>>>>>>>>> The same telemarketing operator would then outpulse multiple=20 >>>>>>>>>> numbers for their multiple clients, none of these numbers=20 >>>>>>>>>> belonging to the >>>>>>>>> telemarketer. >>>>>>>>>> BTW, we are using the term "telemarketing" in a very generic=20 >>>>>>>>>> sense - this could just as easily be a public service=20 >>>>>>>>>> announcement, fundraiser, >>>>>>>>> etc. >>>>>>>>>>=20 >>>>>>>>>> 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. >>>>>>>>>>=20 >>>>>>>>>> On a different note, it would help a lot of we standardized=20 >>>>>>>>>> terminology. >>>>>>>>>> Telemarketing, BPO, call center, end customer, clients=A9 it=20 >>>>>>>>>> may be hard for others to follow the discussion later. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> (generic term for any type of outbound calling, including=20 >>>>>>>>>> public service announcement, so don't think it's all about >>>>>>>>>> sales!) >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On 9/19/13 3:22 PM, "Schumacher, Gregory [CTO]" >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>> There are some benefits from this approach, but also some=20 >>>>>>>>>>> scenarios that need clarification how they could function. >>>>>>>>>>>=20 >>>>>>>>>>> The benefit is that the credential represents both the=20 >>>>>>>>>>> company "responsible" for the sales campaign (the "company" >>>>>>>>>>> in your >>>>>>>>>>> scenario) >>>>>>>>>>> and the company operating the sales campaign (the call=20 >>>>>>>>>>> center in your scenario). For the use in forensics (after = >>>>>>>>>>> the fact >>>>>>>>>>> analysis) such as pursuit of fraud investigation, we then=20 >>>>>>>>>>> can follow both paths. >>>>>>>>>>>=20 >>>>>>>>>>> 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=20 >>>>>>>>>>> telemarketing campaign or both? >>>>>>>>>>>=20 >>>>>>>>>>> - How is the SP supposed to know all the parties that it is=20 >>>>>>>>>>> attesting to >>>>>>>>>>> - the responsible party and/or executing party? >>>>>>>>>>>=20 >>>>>>>>>>> -It seems likely that some of the numbers assigned to a=20 >>>>>>>>>>> company in your scenario will not be assigned to real=20 >>>>>>>>>>> telephones (or call center >>>>>>>>>>> trunk) until a telemarketing campaign is initiated or a call = >>>>>>>>>>> center selected to execute the sales campaign, is it=20 >>>>>>>>>>> possible to have these unassigned or floating numbers when=20 >>>>>>>>>>> not in use for a telemarketing campaign? Is it allowed=20 >>>>>>>>>>> under most national numbering regimes? >>>>>>>>>>>=20 >>>>>>>>>>> - How important is it to have a known or recognized phone=20 >>>>>>>>>>> number as the caller id as part of a telemarketing = campaign? >>>>>>>>>>> I am assuming that not all campaigns care about having a=20 >>>>>>>>>>> number that is known or >>>>>>>>> recognized. >>>>>>>>>>>=20 >>>>>>>>>>> -In other words for this last bit, if a call center=20 >>>>>>>>>>> (telemarketing campaign operator) is using their own set of = >>>>>>>>>>> numbers but serve multiple simultaneous telemarketing=20 >>>>>>>>>>> campaigns using the same originating numbers, what will=20 >>>>>>>>>>> they sign? Will they just have a credential representing=20 >>>>>>>>>>> the call center alone, or a different credential per=20 >>>>>>>>>>> telemarketing campaign, or a different credential per=20 >>>>>>>>>>> responsible party (per client)? This will affect what is=20 >>>>>>>>>>> possible for >>>>>>>>> any forensic activity. >>>>>>>>>>>=20 >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org]=20 >>>>>>>>>>> On Behalf Of Brian Rosen >>>>>>>>>>> Sent: Tuesday, September 17, 2013 9:44 AM >>>>>>>>>>> To: Fernando Mousinho >>>>>>>>>>> Cc: stir@ietf.org; Hadriel Kaplan >>>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>>=20 >>>>>>>>>>> We have a requirement to support the BPO use case. >>>>>>>>>>>=20 >>>>>>>>>>> The notion we had is that the company contracting the call=20 >>>>>>>>>>> center approves the use, and the call center, or the SP=20 >>>>>>>>>>> acting on its behalf, signs. >>>>>>>>>>> Think of this as another level of delegation. An SP=20 >>>>>>>>>>> delegates numbers to the company. The company "delegates" >>>>>>>>>>> use of those numbers to the call center. The call center=20 >>>>>>>>>>> calls, using that delegation. >>>>>>>>>>> The credentials of the call center would be different from=20 >>>>>>>>>>> those of the company, but would cover the same number. >>>>>>>>>>> Having multiple credentials covering the same number will=20 >>>>>>>>>>> be very common due to the way delegation happens. In order = >>>>>>>>>>> to allow SPs to sign, without creating credential per TN,=20 >>>>>>>>>>> we allow credentials with ranges. >>>>>>>>>>> The >>>>>>>>>>> ranges could overlap when delegation happens. >>>>>>>>>>>=20 >>>>>>>>>>> Consider the following complex US case: >>>>>>>>>>> The North American Number Plan Administrator delegates=20 >>>>>>>>>>> 202-555-xxxx to the Pooling Administrator. The PA now has=20 >>>>>>>>>>> a credential covering the entire 10K block. >>>>>>>>>>> The Pooling Administrator delegates 202-555-1xxx to SP A. =20 >>>>>>>>>>> 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=20 >>>>>>>>>>> 202-555-123x to Company C. Company C has a credential for=20 >>>>>>>>>>> a >>>>>>>>>>> 10 number block Company C authorizes 202-555-1234 to BPO D. = =20 >>>>>>>>>>> BPO D has credential for a 1 number block >>>>>>>>>>>=20 >>>>>>>>>>> NANPA and the PA never are in a call path, so they would=20 >>>>>>>>>>> never sign a call. >>>>>>>>>>>=20 >>>>>>>>>>> However, SP A or SP B could sign a call from either Company=20 >>>>>>>>>>> C or BPO D using the credential they have. >>>>>>>>>>>=20 >>>>>>>>>>> The SP for the call center could acquire credentials from=20 >>>>>>>>>>> the BPO and sign on its behalf. I suspect than many=20 >>>>>>>>>>> service providers would be reluctant to do so unless the=20 >>>>>>>>>>> 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=20 >>>>>>>>>>> probably has to do the signing itself. >>>>>>>>>>>=20 >>>>>>>>>>> Brian >>>>>>>>>>>=20 >>>>>>>>>>> On Sep 17, 2013, at 8:46 AM, Fernando Mousinho (fmousinh)=20 >>>>>>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> I agree, Hadriel. While large call centers (including BPOs, = >>>>>>>>>>>> which provide services for other companies) may have=20 >>>>>>>>>>>> special arrangements with SPs, the majority (small to >>>>>>>>>>>> mid-size) will probably rely on the SPs to do provide to=20 >>>>>>>>>>>> vouch for their identity. This would probably be the case=20 >>>>>>>>>>>> for the home analog caller anyway. This would imply that=20 >>>>>>>>>>>> the "originating" SP's willingness to provide this=20 >>>>>>>>>>>> signature is a critical success factor for the proposal's > adoption. >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> But back to the business process outsourcers (BPO) case -=20 >>>>>>>>>>>> where a call center is providing service on behalf of=20 >>>>>>>>>>>> multiple companies. I can see the value of them sending=20 >>>>>>>>>>>> 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=20 >>>>>>>>>>>> that SP >>>>>>>>>>>> 1 allowing one of its subscribers to send an outbound call=20 >>>>>>>>>>>> using a number registered to SP 2 could be a no-no. If=20 >>>>>>>>>>>> this hypothesis is correct, then we are back to the case=20 >>>>>>>>>>>> where the SP is signing all calls, >>>>>>>>>> even for BPOs. >>>>>>>>>>>>=20 >>>>>>>>>>>> Or maybe this is another problem we are trying to fix in=20 >>>>>>>>>>>> the working group, in which case we perhaps should state as = >>>>>>>>>>>> a goal or >>>>>>>>> benefit: >>>>>>>>>>>> "providing a reliable mechanism to let calls originated=20 >>>>>>>>>>>> from one >>>>>>>>>>>> SP1 to outpulse numbers that belong to another". >>>>>>>>>>>>=20 >>>>>>>>>>>> Fernando >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> On 9/16/13 12:12 PM, "Hadriel Kaplan" >>>>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Any of them could do it. My guess is service providers=20 >>>>>>>>>>>>> will do it for most call centers, although larger call=20 >>>>>>>>>>>>> centers might do it themselves... >>>>>>>>>>>>> especially ones which have trunks from multiple providers=20 >>>>>>>>>>>>> and can source calls using the same number(s) out through = >>>>>>>>>>>>> multiple providers on a call-by-call basis. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> -hadriel >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Sep 16, 2013, at 9:49 AM, Fernando Mousinho (fmousinh)=20 >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I'm catching up with the discussions in this working=20 >>>>>>>>>>>>>> group, and am trying to understand some architecture=20 >>>>>>>>>>>>>> implications in call centers (which is where my=20 >>>>>>>>>>>>>> background is). It seems that many of the problems we=20 >>>>>>>>>>>>>> are trying to fix are related to contact centers anyway, = >>>>>>>>>>>>>> so it is probably a good idea to have everyone in the =20 >>>>>>>>>>>>>> same >>>>>>>>>> page. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Forgive me if it is an obvious question, but which=20 >>>>>>>>>>>>>> components in a "typical call center architecture" do=20 >>>>>>>>>>>>>> you see signature and verification taking place? Such "typical" >>>>>>>>>>>>>> deployments have premises based equipment (PME), a=20 >>>>>>>>>>>>>> session border controller >>>>>>>>>>>>>> (SBC) >>>>>>>>>>>>>> and of course a SIP service provider all three could=20 >>>>>>>>>>>>>> potentially be used throughout the authorization = process. >>>>>>>>>>>>>> There are different ramifications depending on where=20 >>>>>>>>>>>>>> your mind is at. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Fernando Mousinho >>>>>>>>>>>>>> Cisco Systems >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> stir mailing list >>>>>>>>>>>> stir@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> stir mailing list >>>>>>>>>>> stir@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> ________________________________ >>>>>>>>>>>=20 >>>>>>>>>>> This e-mail may contain Sprint proprietary information=20 >>>>>>>>>>> intended for the sole use of the recipient(s). Any use by=20 >>>>>>>>>>> others is prohibited. >>>>>>>>>>> If >>>>>>>>>>> you are not the intended recipient, please contact the=20 >>>>>>>>>>> sender and delete all copies of the message. >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> stir mailing list >>>>>>>>>>> stir@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> stir mailing list >>>>>>>>>> stir@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>> _______________________________________________ >>>>>>>>>> stir mailing list >>>>>>>>>> stir@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>> _______________________________________________ >>>>>>>>> stir mailing list >>>>>>>>> stir@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> stir mailing list >>>>> stir@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/stir >>>>=20 >>>=20 >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> cnit mailing list >> cnit@ietf.org >> https://www.ietf.org/mailman/listinfo/cnit >=20 From richard@shockey.us Thu Oct 31 14:36:39 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 368D111E825F for ; Thu, 31 Oct 2013 14:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.884 X-Spam-Level: X-Spam-Status: No, score=-100.884 tagged_above=-999 required=5 tests=[AWL=-1.185, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, MANGLED_COMPNY=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 478TLURTcJ7b for ; Thu, 31 Oct 2013 14:36:31 -0700 (PDT) Received: from outbound-ss-2175.bluehost.com (outbound-ss-2175.bluehost.com [74.220.218.8]) by ietfa.amsl.com (Postfix) with SMTP id DBA0F11E8256 for ; Thu, 31 Oct 2013 14:36:11 -0700 (PDT) Received: (qmail 6607 invoked by uid 0); 31 Oct 2013 21:36:06 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy16-pub.mail.unifiedlayer.com with SMTP; 31 Oct 2013 21:36:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=RdgpHb6eieeioawSmr7mcDJEMcgHcFQ5DSlU6vBcKgU=; b=PaHTkI4xISe5/x9wWYZfyzes25M6O++DLtWFGw6c7bvUKzkzss1U8NjJWZH73JQDmfOAzbBazDEYWg9s0ItK/cpsCHEAj6VEAsTdLJAESn7Ms0gEG3y5tIgmCJt6Zf2I; Received: from [173.79.179.104] (port=54366 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VbzuP-0004nX-HB; Thu, 31 Oct 2013 15:36:05 -0600 From: "Richard Shockey" To: "'Michael Hammer'" , , References: <32C55AFE-FA17-4776-AD91-259AD3E226BE@brianrosen.net> <024001ced5a2$f3268810$d9739830$@shockey.us> <029501ced5b5$8fa9f480$aefddd80$@shockey.us> <2AA32171-1AE3-4AEE-AEDC-B2031562B7BD@brianrosen.net> <00d901ced637$9e8143a0$db83cae0$@shockey.us> <8B0027B8-D777-48F3-B5BF-B8F81F038E37@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBEF4DB6@sc9-ex2k10mb1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBEF4DB6@sc9-ex2k10mb1.corp.yaanatech.com> Date: Thu, 31 Oct 2013 17:36:04 -0400 Message-ID: <021401ced681$34ab2640$9e0172c0$@shockey.us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQLTdCvgrcMvmbDsv2xAt2r4G5TZbQLC46EgAqz016cBpe129QIWVK8PAdOJjcEBFampjAIH39XjAZ4KSLyXiD+zcA== X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.79.179.104 authed with richard@shockey.us} Cc: cnit@ietf.org, dispatch@ietf.org Subject: Re: [cnit] [dispatch] [stir] Application servers - Re: Call Center Implications X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 21:36:39 -0000 Could you explain what you mean here? I'm modestly confused. Options indicator for what .. what the other side is capable of? =20 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.=20 -----Original Message----- From: Michael Hammer [mailto:michael.hammer@yaanatech.com]=20 Sent: Thursday, October 31, 2013 2:11 PM To: Henning.Schulzrinne@fcc.gov; br@brianrosen.net; richard@shockey.us Cc: cnit@ietf.org; dispatch@ietf.org Subject: RE: [dispatch] [cnit] [stir] Application servers - Re: Call = Center Implications 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: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Henning Schulzrinne Sent: Thursday, October 31, 2013 1:37 PM To: 'Brian Rosen'; Richard Shockey Cc: cnit@ietf.org; DISPATCH Subject: Re: [dispatch] [cnit] [stir] Application servers - Re: Call = Center Implications Call-info: ;purpose=3Dcard or purpose=3Dinfo 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: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Brian Rosen Sent: Thursday, October 31, 2013 1:19 PM To: Richard Shockey Cc: cnit@ietf.org; 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. I am very interested in working on improving caller name. Brian On Oct 31, 2013, at 8:49 AM, Richard Shockey wrote: >=20 > Brian please.. Look at the mail. I'm using the CNIT list. =20 >=20 > The issue is can we use the tools at hand to increase both the=20 > accuracy, reliability and the amount of data that is delivered to the=20 > CUA over who is attempting to establish a session. >=20 > The larger issue is the integrity of the entire real time=20 > 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. >=20 > CNAM as it is currently defined in SS7 is a terrible service. 15=20 > Character ASCII. No support for International character sets the = usual. >=20 > 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=20 > 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=20 > that National Regulators would be delighted with consumers having a=20 > 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=20 > interconnection among providers it would be really really useful if=20 > Enterprise systems could extract more data from their internal=20 > directory systems and pass that along in the new format for = enterprise calling as well. >=20 > I would certainly argue that we are not going to see ubiquitous Point=20 > to Point video calling using WebRTC or SIP if there is not better=20 > display of calling party information. >=20 > In addition network operators could insert other 'hints' as to the=20 > nature of the session based on its ability to validate the Caller ID=20 > or other forms on analysis. >=20 > I'm well aware of how CNAM is delivered in North America and I'm=20 > equally aware the CNAM business model is broken. >=20 > What I'd like to know is what interest there is in this proposition=20 > and are there parties interested in working on it in advance of say London. >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, October 30, 2013 5:39 PM > To: Richard Shockey > Cc: cnit@ietf.org > Subject: Re: [cnit] [stir] Application servers - Re: Call Center=20 > Implications >=20 > More useful in what way? Improving the reliability of caller name? =20 > Please use the cnit list to discuss this. >=20 > 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=20 > the origination side, and signed as the number is. >=20 > That is a significant change to the current infrastructure, which at=20 > least in North America relies on a termination service provider dip in = > an origination service provider database, but it seems feasible to=20 > consider that. >=20 > Brian >=20 > On Oct 30, 2013, at 5:18 PM, Richard Shockey = wrote: >=20 >>=20 >> Ok since Brian is being picky.. >>=20 >> I'm actually interested if anyone is interested in the possibility of = >> making SIP Identity to the UA more useful. >>=20 >>=20 >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >> Of Richard Shockey >> Sent: Wednesday, October 30, 2013 3:05 PM >> To: stir@ietf.org >> Subject: Re: [stir] Application servers - Re: Call Center=20 >> Implications >>=20 >> Dan great post. I couldn't agree more. There needs to be some rules here. >> Some may be regulatory some may be technical. >>=20 >> First the voice application service providers need to provide the=20 >> terminating CUA, "an accurate and truthful" Caller-ID for the call=20 >> even if it is originated from a source that is not directly=20 >> 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=20 >> RESPORGS. >>=20 >> If the originating UA can prove/assert it is legally authorized to=20 >> use such an identity on behalf of a customer then that is step one. >> The presumption after that is there is some contractual obligation=20 >> between the service provider and the network about the use of such identities. >> The network can then "validate" such an assertion. >>=20 >> 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. =20 >>=20 >> 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=20 >> the called party and frankly 15 character ASCII is not enough. >> Consumers or businesses should be able to see more complete and=20 >> validated information about the session in order to make an better=20 >> 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. >>=20 >> All of the examples you cite are excellent examples where such=20 >> verbose calling party identification could be displayed. I certainly = >> want to answer a call from my doctor on my test results just as I=20 >> wish to ignore a call from Bill Clinton begging me to vote in the=20 >> Virginia Governors election next Tuesday. This is a case where=20 >> annominity is not a > good idea. >>=20 >>=20 >> All you need now is a little standardization. >> Technically this should is very easy to understand in SIP. It would=20 >> probably a reasonable modification of the Call INFO header in SIP=20 >> with something like a XML based VCARD or JCARD URI whatever and=20 >> 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. >>=20 >>=20 >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >> Of Dan York >> Sent: Tuesday, October 29, 2013 5:10 PM >> To: Brian Rosen; Cullen Jennings >> Cc: Gregory.Schumacher@sprint.com; Richard Shockey; stir@ietf.org;=20 >> Fernando Mousinho (fmousinh); Alex Bobotek; Michael Hammer; Henning=20 >> Schulzrinne >> Subject: [stir] Application servers - Re: Call Center Implications >>=20 >> 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=20 >> that we're not only talking about "traditional" call centers but also = >> what I'll call "voice application service providers". They are=20 >> generally automated platforms running applications that a company=20 >> uses for some kind of outbound service. Examples include: >>=20 >> - calling everyone in a school district with a weather-related=20 >> cancellation (or, unfortunately, a school shooting or similar event) >> - calling patients to provide reminders of appointments or=20 >> notifications of subscriptions available >> - calling customers to let them know that a package was delivered or=20 >> 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=20 >> current issues >> - performing a call-back to provide an additional layer of=20 >> authentication for some service >>=20 >> There is a large (and growing) market for these kind of automated=20 >> tools and services and the distinction between these calls and=20 >> "robocalls" is really only one of intent and the fact that the=20 >> recipient > has "opted in" >> through some kind of system. >>=20 >> Generally, though, many of the companies want the application to=20 >> 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=20 >> from one of their own phone numbers. >>=20 >> You could think of these in the same way as "call centers", but I=20 >> point this out because some of these new services are very automated=20 >> and there are always new startups now emerging in this space. Some=20 >> of them are very "self-service" where the customer does it all while=20 >> others have teams of people involved. Some of the companies involved = >> include Nuance, Microsoft Tellme, Voxeo (now Aspect, and also my=20 >> former employer), Tropo, Twilio, Convergys and many more[1]. >>=20 >> If STIR is to succeed, these kind of application platforms will also=20 >> need to be able to make calls on behalf of the companies using those > platforms. >>=20 >> Dan >>=20 >> [1] One report about this market: >> http://www.voxeo.com/pdf/OvumDecisionMatrix-2011.pdf >>=20 >>=20 >> -- >> Dan York >> Senior Content Strategist, Internet Society >> york@isoc.org +1-802-735-1624 >> Jabber: york@jabber.isoc.org >> Skype: danyork http://twitter.com/danyork >>=20 >> http://www.internetsociety.org/deploy360/ >>=20 >>=20 >>=20 >>=20 >> On 10/21/13 9:15 AM, "Brian Rosen" wrote: >>=20 >>> We really need to give each BPO different keys I think. The notion that >>> we are sharing private keys among multiple competing entities who=20 >>> provide services for a single enterprise strikes me as a VBI (Very=20 >>> Bad Idea). I can't see any real difficulty in having more than one=20 >>> 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=20 >>> more of it's >> BPOs. >>>=20 >>> Brian >>>=20 >>> On Oct 20, 2013, at 1:12 AM, Cullen Jennings (fluffy)=20 >>> >>> wrote: >>>=20 >>>>=20 >>>> What Fernando is saying makes sense to me a desirable property of=20 >>>> the solution and I agree that if we gave each BPO a different=20 >>>> private key that would solve it but that might be pretty hard to=20 >>>> mange in other ways. I like the requirements but the solution is=20 >>>> not 100% obvious to me. >>>>=20 >>>>=20 >>>> On Oct 2, 2013, at 10:27 AM, Brian Rosen wrote: >>>>=20 >>>>> Sure. >>>>>=20 >>>>> Each BPO would have a different private/public key pair. >>>>>=20 >>>>> So you can trace which one placed the call. >>>>>=20 >>>>> Brian >>>>>=20 >>>>> On Oct 2, 2013, at 12:59 PM, Fernando Mousinho (fmousinh)=20 >>>>> wrote: >>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> If the company hires several BPOs and authorizes all of them to=20 >>>>>> sign calls on its behalf, is there a way to trace back the=20 >>>>>> originator (specific >>>>>> BPO) >>>>>> later on? I suppose that at some level the actual caller must be=20 >>>>>> exposed (perhaps to trace malicious activity, such as malicious=20 >>>>>> person infiltrated in an otherwise legitimate BPO). >>>>>>=20 >>>>>> 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=20 >>>>>> identity). >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 9/19/13 9:43 PM, "Brian Rosen" wrote: >>>>>>=20 >>>>>>> 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=20 >>>>>>> change to use From (if signed maybe). It also doesn't fit the=20 >>>>>>> definition of PAI. >>>>>>>=20 >>>>>>> Brian >>>>>>>=20 >>>>>>> On Sep 19, 2013, at 9:14 PM, Fernando Mousinho (fmousinh)=20 >>>>>>> wrote: >>>>>>>=20 >>>>>>>> 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=20 >>>>>>>> on the delegation process Rosen mentions. >>>>>>>> PAI's use is widespread, and it's main limitation is being=20 >>>>>>>> spoofable - but this is exactly the problem we are trying to=20 >>>>>>>> solve anyway. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> On Sep 19, 2013, at 5:39 PM, "Richard Shockey"=20 >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>> Excellent point a profile or BCP to complement the work. >>>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On=20 >>>>>>>>> Behalf Of Alex Bobotek >>>>>>>>> Sent: Thursday, September 19, 2013 5:27 PM >>>>>>>>> To: Henning Schulzrinne; Michael Hammer; fmousinh@cisco.com;=20 >>>>>>>>> Gregory.Schumacher@sprint.com; br@brianrosen.net >>>>>>>>> Cc: stir@ietf.org >>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>=20 >>>>>>>>> +1 >>>>>>>>> I've assumed that we are headed towards a "sign whatever=20 >>>>>>>>> extras you wish, and indicate what your signature covers" mechanism. >>>>>>>>>=20 >>>>>>>>> Based on this, standards would need to identify only a minimal = >>>>>>>>> subset of what shall/should be signed, and ensure that any=20 >>>>>>>>> required group of signed items survives transit intact. >>>>>>>>>=20 >>>>>>>>> Best signing practices may be needed to complement the=20 >>>>>>>>> standard, and an appropriate place for all but the most basic = >>>>>>>>> 'what to sign' >>>>>>>>> recommendations. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Regards, >>>>>>>>>=20 >>>>>>>>> Alex >>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On = >>>>>>>>>> Behalf Of Henning Schulzrinne >>>>>>>>>> Sent: Thursday, September 19, 2013 2:24 PM >>>>>>>>>> To: Michael Hammer; fmousinh@cisco.com;=20 >>>>>>>>>> Gregory.Schumacher@sprint.com; br@brianrosen.net >>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>=20 >>>>>>>>>> I see no reason not to allow signing any number-related field = >>>>>>>>>> in the SIP request. (Signing may well be done by different >>>>>>>>>> parties.) >>>>>>>>>>=20 >>>>>>>>>> As far as I know, callback numbers (SIP Reply-To) aren't=20 >>>>>>>>>> conveyable in legacy systems, however, so this may be of=20 >>>>>>>>>> somewhat limited use for a >>>>>>>>> while. >>>>>>>>>>=20 >>>>>>>>>> ________________________________________ >>>>>>>>>> From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf = >>>>>>>>>> of Michael Hammer [michael.hammer@yaanatech.com] >>>>>>>>>> Sent: Thursday, September 19, 2013 4:34 PM >>>>>>>>>> To: fmousinh@cisco.com; Gregory.Schumacher@sprint.com;=20 >>>>>>>>>> br@brianrosen.net >>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>=20 >>>>>>>>>> Don't we still want to know the true originator of the call,=20 >>>>>>>>>> even when we have some token that says "Doctor so and so=20 >>>>>>>>>> approved this message." >>>>>>>>>>=20 >>>>>>>>>> Originating number, display number, and call-back number=20 >>>>>>>>>> could be >>>>>>>>>> 3 >>>>>>>>>> different things. >>>>>>>>>> Should all of them be verifiable? >>>>>>>>>>=20 >>>>>>>>>> Mike >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On = >>>>>>>>>> Behalf Of Fernando Mousinho (fmousinh) >>>>>>>>>> Sent: Thursday, September 19, 2013 4:00 PM >>>>>>>>>> To: Schumacher, Gregory [CTO]; Brian Rosen >>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>=20 >>>>>>>>>> I believe the scenario telemarketing here is when a client=20 >>>>>>>>>> hires a BPO to place outbound calls, but expect customers=20 >>>>>>>>>> to return these calls to a different place (say, their own=20 >>>>>>>>>> and operated call center). This way, this client is=20 >>>>>>>>>> authorizing the BPO to use an identity that it >>>>>>>>>> (BPO) >>>>>>>>> doesn't own. >>>>>>>>>> These numbers in this scenario are always operational, just=20 >>>>>>>>>> at a different place. >>>>>>>>>>=20 >>>>>>>>>> The same telemarketing operator would then outpulse multiple=20 >>>>>>>>>> numbers for their multiple clients, none of these numbers=20 >>>>>>>>>> belonging to the >>>>>>>>> telemarketer. >>>>>>>>>> BTW, we are using the term "telemarketing" in a very generic=20 >>>>>>>>>> sense - this could just as easily be a public service=20 >>>>>>>>>> announcement, fundraiser, >>>>>>>>> etc. >>>>>>>>>>=20 >>>>>>>>>> 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. >>>>>>>>>>=20 >>>>>>>>>> On a different note, it would help a lot of we standardized=20 >>>>>>>>>> terminology. >>>>>>>>>> Telemarketing, BPO, call center, end customer, clients=A9 it=20 >>>>>>>>>> may be hard for others to follow the discussion later. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> (generic term for any type of outbound calling, including=20 >>>>>>>>>> public service announcement, so don't think it's all about >>>>>>>>>> sales!) >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On 9/19/13 3:22 PM, "Schumacher, Gregory [CTO]" >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>> There are some benefits from this approach, but also some=20 >>>>>>>>>>> scenarios that need clarification how they could function. >>>>>>>>>>>=20 >>>>>>>>>>> The benefit is that the credential represents both the=20 >>>>>>>>>>> company "responsible" for the sales campaign (the "company" >>>>>>>>>>> in your >>>>>>>>>>> scenario) >>>>>>>>>>> and the company operating the sales campaign (the call=20 >>>>>>>>>>> center in your scenario). For the use in forensics (after = >>>>>>>>>>> the fact >>>>>>>>>>> analysis) such as pursuit of fraud investigation, we then=20 >>>>>>>>>>> can follow both paths. >>>>>>>>>>>=20 >>>>>>>>>>> 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=20 >>>>>>>>>>> telemarketing campaign or both? >>>>>>>>>>>=20 >>>>>>>>>>> - How is the SP supposed to know all the parties that it is=20 >>>>>>>>>>> attesting to >>>>>>>>>>> - the responsible party and/or executing party? >>>>>>>>>>>=20 >>>>>>>>>>> -It seems likely that some of the numbers assigned to a=20 >>>>>>>>>>> company in your scenario will not be assigned to real=20 >>>>>>>>>>> telephones (or call center >>>>>>>>>>> trunk) until a telemarketing campaign is initiated or a call = >>>>>>>>>>> center selected to execute the sales campaign, is it=20 >>>>>>>>>>> possible to have these unassigned or floating numbers when=20 >>>>>>>>>>> not in use for a telemarketing campaign? Is it allowed=20 >>>>>>>>>>> under most national numbering regimes? >>>>>>>>>>>=20 >>>>>>>>>>> - How important is it to have a known or recognized phone=20 >>>>>>>>>>> number as the caller id as part of a telemarketing = campaign? >>>>>>>>>>> I am assuming that not all campaigns care about having a=20 >>>>>>>>>>> number that is known or >>>>>>>>> recognized. >>>>>>>>>>>=20 >>>>>>>>>>> -In other words for this last bit, if a call center=20 >>>>>>>>>>> (telemarketing campaign operator) is using their own set of = >>>>>>>>>>> numbers but serve multiple simultaneous telemarketing=20 >>>>>>>>>>> campaigns using the same originating numbers, what will=20 >>>>>>>>>>> they sign? Will they just have a credential representing=20 >>>>>>>>>>> the call center alone, or a different credential per=20 >>>>>>>>>>> telemarketing campaign, or a different credential per=20 >>>>>>>>>>> responsible party (per client)? This will affect what is=20 >>>>>>>>>>> possible for >>>>>>>>> any forensic activity. >>>>>>>>>>>=20 >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org]=20 >>>>>>>>>>> On Behalf Of Brian Rosen >>>>>>>>>>> Sent: Tuesday, September 17, 2013 9:44 AM >>>>>>>>>>> To: Fernando Mousinho >>>>>>>>>>> Cc: stir@ietf.org; Hadriel Kaplan >>>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>>=20 >>>>>>>>>>> We have a requirement to support the BPO use case. >>>>>>>>>>>=20 >>>>>>>>>>> The notion we had is that the company contracting the call=20 >>>>>>>>>>> center approves the use, and the call center, or the SP=20 >>>>>>>>>>> acting on its behalf, signs. >>>>>>>>>>> Think of this as another level of delegation. An SP=20 >>>>>>>>>>> delegates numbers to the company. The company "delegates" >>>>>>>>>>> use of those numbers to the call center. The call center=20 >>>>>>>>>>> calls, using that delegation. >>>>>>>>>>> The credentials of the call center would be different from=20 >>>>>>>>>>> those of the company, but would cover the same number. >>>>>>>>>>> Having multiple credentials covering the same number will=20 >>>>>>>>>>> be very common due to the way delegation happens. In order = >>>>>>>>>>> to allow SPs to sign, without creating credential per TN,=20 >>>>>>>>>>> we allow credentials with ranges. >>>>>>>>>>> The >>>>>>>>>>> ranges could overlap when delegation happens. >>>>>>>>>>>=20 >>>>>>>>>>> Consider the following complex US case: >>>>>>>>>>> The North American Number Plan Administrator delegates=20 >>>>>>>>>>> 202-555-xxxx to the Pooling Administrator. The PA now has=20 >>>>>>>>>>> a credential covering the entire 10K block. >>>>>>>>>>> The Pooling Administrator delegates 202-555-1xxx to SP A. =20 >>>>>>>>>>> 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=20 >>>>>>>>>>> 202-555-123x to Company C. Company C has a credential for=20 >>>>>>>>>>> a >>>>>>>>>>> 10 number block Company C authorizes 202-555-1234 to BPO D. = =20 >>>>>>>>>>> BPO D has credential for a 1 number block >>>>>>>>>>>=20 >>>>>>>>>>> NANPA and the PA never are in a call path, so they would=20 >>>>>>>>>>> never sign a call. >>>>>>>>>>>=20 >>>>>>>>>>> However, SP A or SP B could sign a call from either Company=20 >>>>>>>>>>> C or BPO D using the credential they have. >>>>>>>>>>>=20 >>>>>>>>>>> The SP for the call center could acquire credentials from=20 >>>>>>>>>>> the BPO and sign on its behalf. I suspect than many=20 >>>>>>>>>>> service providers would be reluctant to do so unless the=20 >>>>>>>>>>> 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=20 >>>>>>>>>>> probably has to do the signing itself. >>>>>>>>>>>=20 >>>>>>>>>>> Brian >>>>>>>>>>>=20 >>>>>>>>>>> On Sep 17, 2013, at 8:46 AM, Fernando Mousinho (fmousinh)=20 >>>>>>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> I agree, Hadriel. While large call centers (including BPOs, = >>>>>>>>>>>> which provide services for other companies) may have=20 >>>>>>>>>>>> special arrangements with SPs, the majority (small to >>>>>>>>>>>> mid-size) will probably rely on the SPs to do provide to=20 >>>>>>>>>>>> vouch for their identity. This would probably be the case=20 >>>>>>>>>>>> for the home analog caller anyway. This would imply that=20 >>>>>>>>>>>> the "originating" SP's willingness to provide this=20 >>>>>>>>>>>> signature is a critical success factor for the proposal's > adoption. >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> But back to the business process outsourcers (BPO) case -=20 >>>>>>>>>>>> where a call center is providing service on behalf of=20 >>>>>>>>>>>> multiple companies. I can see the value of them sending=20 >>>>>>>>>>>> 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=20 >>>>>>>>>>>> that SP >>>>>>>>>>>> 1 allowing one of its subscribers to send an outbound call=20 >>>>>>>>>>>> using a number registered to SP 2 could be a no-no. If=20 >>>>>>>>>>>> this hypothesis is correct, then we are back to the case=20 >>>>>>>>>>>> where the SP is signing all calls, >>>>>>>>>> even for BPOs. >>>>>>>>>>>>=20 >>>>>>>>>>>> Or maybe this is another problem we are trying to fix in=20 >>>>>>>>>>>> the working group, in which case we perhaps should state as = >>>>>>>>>>>> a goal or >>>>>>>>> benefit: >>>>>>>>>>>> "providing a reliable mechanism to let calls originated=20 >>>>>>>>>>>> from one >>>>>>>>>>>> SP1 to outpulse numbers that belong to another". >>>>>>>>>>>>=20 >>>>>>>>>>>> Fernando >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> On 9/16/13 12:12 PM, "Hadriel Kaplan" >>>>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Any of them could do it. My guess is service providers=20 >>>>>>>>>>>>> will do it for most call centers, although larger call=20 >>>>>>>>>>>>> centers might do it themselves... >>>>>>>>>>>>> especially ones which have trunks from multiple providers=20 >>>>>>>>>>>>> and can source calls using the same number(s) out through = >>>>>>>>>>>>> multiple providers on a call-by-call basis. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> -hadriel >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Sep 16, 2013, at 9:49 AM, Fernando Mousinho (fmousinh)=20 >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I'm catching up with the discussions in this working=20 >>>>>>>>>>>>>> group, and am trying to understand some architecture=20 >>>>>>>>>>>>>> implications in call centers (which is where my=20 >>>>>>>>>>>>>> background is). It seems that many of the problems we=20 >>>>>>>>>>>>>> are trying to fix are related to contact centers anyway, = >>>>>>>>>>>>>> so it is probably a good idea to have everyone in the=20 >>>>>>>>>>>>>> same >>>>>>>>>> page. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Forgive me if it is an obvious question, but which=20 >>>>>>>>>>>>>> components in a "typical call center architecture" do=20 >>>>>>>>>>>>>> you see signature and verification taking place? Such "typical" >>>>>>>>>>>>>> deployments have premises based equipment (PME), a=20 >>>>>>>>>>>>>> session border controller >>>>>>>>>>>>>> (SBC) >>>>>>>>>>>>>> and of course a SIP service provider all three could=20 >>>>>>>>>>>>>> potentially be used throughout the authorization = process. >>>>>>>>>>>>>> There are different ramifications depending on where=20 >>>>>>>>>>>>>> your mind is at. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Fernando Mousinho >>>>>>>>>>>>>> Cisco Systems >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> stir mailing list >>>>>>>>>>>> stir@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> stir mailing list >>>>>>>>>>> stir@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> ________________________________ >>>>>>>>>>>=20 >>>>>>>>>>> This e-mail may contain Sprint proprietary information=20 >>>>>>>>>>> intended for the sole use of the recipient(s). Any use by=20 >>>>>>>>>>> others is prohibited. >>>>>>>>>>> If >>>>>>>>>>> you are not the intended recipient, please contact the=20 >>>>>>>>>>> sender and delete all copies of the message. >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> stir mailing list >>>>>>>>>>> stir@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> stir mailing list >>>>>>>>>> stir@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>> _______________________________________________ >>>>>>>>>> stir mailing list >>>>>>>>>> stir@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>> _______________________________________________ >>>>>>>>> stir mailing list >>>>>>>>> stir@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> stir mailing list >>>>> stir@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/stir >>>>=20 >>>=20 >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> cnit mailing list >> cnit@ietf.org >> https://www.ietf.org/mailman/listinfo/cnit >=20 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From michael.hammer@yaanatech.com Thu Oct 31 14:44:50 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10E0C21F9DD0; Thu, 31 Oct 2013 14:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.859 X-Spam-Level: X-Spam-Status: No, score=-0.859 tagged_above=-999 required=5 tests=[AWL=-1.160, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, MANGLED_COMPNY=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDDWKLUUad3k; Thu, 31 Oct 2013 14:44:46 -0700 (PDT) Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) by ietfa.amsl.com (Postfix) with ESMTP id A29C411E8243; Thu, 31 Oct 2013 14:44:42 -0700 (PDT) Received: from SC9-EX2K10MB1.corp.yaanatech.com ([fe80::149d:c2e1:8065:2a47]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Thu, 31 Oct 2013 14:44:42 -0700 From: Michael Hammer To: "richard@shockey.us" , "Henning.Schulzrinne@fcc.gov" , "br@brianrosen.net" Thread-Topic: [dispatch] [cnit] [stir] Application servers - Re: Call Center Implications Thread-Index: AQHO1l/vPBmavPqkd0evJj3dEIAHMJoPHFMwgACurAD//4ySgA== Date: Thu, 31 Oct 2013 21:44:40 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBEF5224@sc9-ex2k10mb1.corp.yaanatech.com> References: <32C55AFE-FA17-4776-AD91-259AD3E226BE@brianrosen.net> <024001ced5a2$f3268810$d9739830$@shockey.us> <029501ced5b5$8fa9f480$aefddd80$@shockey.us> <2AA32171-1AE3-4AEE-AEDC-B2031562B7BD@brianrosen.net> <00d901ced637$9e8143a0$db83cae0$@shockey.us> <8B0027B8-D777-48F3-B5BF-B8F81F038E37@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBEF4DB6@sc9-ex2k10mb1.corp.yaanatech.com> <021401ced681$34ab2640$9e0172c0$@shockey.us> In-Reply-To: <021401ced681$34ab2640$9e0172c0$@shockey.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.113] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_031A_01CED660.DFA107C0" MIME-Version: 1.0 Cc: "cnit@ietf.org" , "dispatch@ietf.org" Subject: Re: [cnit] [dispatch] [stir] Application servers - Re: Call Center Implications X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 21:44:50 -0000 ------=_NextPart_000_031A_01CED660.DFA107C0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable 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:richard@shockey.us]=20 Sent: Thursday, October 31, 2013 5:36 PM To: Michael Hammer; Henning.Schulzrinne@fcc.gov; br@brianrosen.net Cc: cnit@ietf.org; dispatch@ietf.org Subject: RE: [dispatch] [cnit] [stir] Application servers - Re: Call = Center Implications Could you explain what you mean here? I'm modestly confused. Options indicator for what .. what the other side is capable of? =20 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.=20 -----Original Message----- From: Michael Hammer [mailto:michael.hammer@yaanatech.com] Sent: Thursday, October 31, 2013 2:11 PM To: Henning.Schulzrinne@fcc.gov; br@brianrosen.net; richard@shockey.us Cc: cnit@ietf.org; dispatch@ietf.org Subject: RE: [dispatch] [cnit] [stir] Application servers - Re: Call = Center Implications 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: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Henning Schulzrinne Sent: Thursday, October 31, 2013 1:37 PM To: 'Brian Rosen'; Richard Shockey Cc: cnit@ietf.org; DISPATCH Subject: Re: [dispatch] [cnit] [stir] Application servers - Re: Call = Center Implications Call-info: ;purpose=3Dcard or purpose=3Dinfo 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: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Brian Rosen Sent: Thursday, October 31, 2013 1:19 PM To: Richard Shockey Cc: cnit@ietf.org; 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. I am very interested in working on improving caller name. Brian On Oct 31, 2013, at 8:49 AM, Richard Shockey wrote: >=20 > Brian please.. Look at the mail. I'm using the CNIT list. =20 >=20 > The issue is can we use the tools at hand to increase both the=20 > accuracy, reliability and the amount of data that is delivered to the=20 > CUA over who is attempting to establish a session. >=20 > The larger issue is the integrity of the entire real time=20 > 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=20 > the consumer. >=20 > CNAM as it is currently defined in SS7 is a terrible service. 15=20 > Character ASCII. No support for International character sets the = usual. >=20 > 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=20 > 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=20 > that National Regulators would be delighted with consumers having a=20 > 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=20 > interconnection among providers it would be really really useful if=20 > Enterprise systems could extract more data from their internal=20 > directory systems and pass that along in the new format for=20 > enterprise calling as well. >=20 > I would certainly argue that we are not going to see ubiquitous Point=20 > to Point video calling using WebRTC or SIP if there is not better=20 > display of calling party information. >=20 > In addition network operators could insert other 'hints' as to the=20 > nature of the session based on its ability to validate the Caller ID=20 > or other forms on analysis. >=20 > I'm well aware of how CNAM is delivered in North America and I'm=20 > equally aware the CNAM business model is broken. >=20 > What I'd like to know is what interest there is in this proposition=20 > and are there parties interested in working on it in advance of say London. >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, October 30, 2013 5:39 PM > To: Richard Shockey > Cc: cnit@ietf.org > Subject: Re: [cnit] [stir] Application servers - Re: Call Center=20 > Implications >=20 > More useful in what way? Improving the reliability of caller name? =20 > Please use the cnit list to discuss this. >=20 > 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=20 > the origination side, and signed as the number is. >=20 > That is a significant change to the current infrastructure, which at=20 > least in North America relies on a termination service provider dip in = > an origination service provider database, but it seems feasible to=20 > consider that. >=20 > Brian >=20 > On Oct 30, 2013, at 5:18 PM, Richard Shockey = wrote: >=20 >>=20 >> Ok since Brian is being picky.. >>=20 >> I'm actually interested if anyone is interested in the possibility of = >> making SIP Identity to the UA more useful. >>=20 >>=20 >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >> Of Richard Shockey >> Sent: Wednesday, October 30, 2013 3:05 PM >> To: stir@ietf.org >> Subject: Re: [stir] Application servers - Re: Call Center=20 >> Implications >>=20 >> Dan great post. I couldn't agree more. There needs to be some rules here. >> Some may be regulatory some may be technical. >>=20 >> First the voice application service providers need to provide the=20 >> terminating CUA, "an accurate and truthful" Caller-ID for the call=20 >> even if it is originated from a source that is not directly=20 >> 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=20 >> RESPORGS. >>=20 >> If the originating UA can prove/assert it is legally authorized to=20 >> use such an identity on behalf of a customer then that is step one. >> The presumption after that is there is some contractual obligation=20 >> between the service provider and the network about the use of such identities. >> The network can then "validate" such an assertion. >>=20 >> 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. =20 >>=20 >> 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=20 >> the called party and frankly 15 character ASCII is not enough. >> Consumers or businesses should be able to see more complete and=20 >> validated information about the session in order to make an better=20 >> 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. >>=20 >> All of the examples you cite are excellent examples where such=20 >> verbose calling party identification could be displayed. I certainly = >> want to answer a call from my doctor on my test results just as I=20 >> wish to ignore a call from Bill Clinton begging me to vote in the=20 >> Virginia Governors election next Tuesday. This is a case where=20 >> annominity is not a > good idea. >>=20 >>=20 >> All you need now is a little standardization. >> Technically this should is very easy to understand in SIP. It would=20 >> probably a reasonable modification of the Call INFO header in SIP=20 >> with something like a XML based VCARD or JCARD URI whatever and=20 >> 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. >>=20 >>=20 >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >> Of Dan York >> Sent: Tuesday, October 29, 2013 5:10 PM >> To: Brian Rosen; Cullen Jennings >> Cc: Gregory.Schumacher@sprint.com; Richard Shockey; stir@ietf.org;=20 >> Fernando Mousinho (fmousinh); Alex Bobotek; Michael Hammer; Henning=20 >> Schulzrinne >> Subject: [stir] Application servers - Re: Call Center Implications >>=20 >> 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=20 >> that we're not only talking about "traditional" call centers but also = >> what I'll call "voice application service providers". They are=20 >> generally automated platforms running applications that a company=20 >> uses for some kind of outbound service. Examples include: >>=20 >> - calling everyone in a school district with a weather-related=20 >> cancellation (or, unfortunately, a school shooting or similar event) >> - calling patients to provide reminders of appointments or=20 >> notifications of subscriptions available >> - calling customers to let them know that a package was delivered or=20 >> 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=20 >> current issues >> - performing a call-back to provide an additional layer of=20 >> authentication for some service >>=20 >> There is a large (and growing) market for these kind of automated=20 >> tools and services and the distinction between these calls and=20 >> "robocalls" is really only one of intent and the fact that the=20 >> recipient > has "opted in" >> through some kind of system. >>=20 >> Generally, though, many of the companies want the application to=20 >> 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=20 >> from one of their own phone numbers. >>=20 >> You could think of these in the same way as "call centers", but I=20 >> point this out because some of these new services are very automated=20 >> and there are always new startups now emerging in this space. Some=20 >> of them are very "self-service" where the customer does it all while=20 >> others have teams of people involved. Some of the companies involved = >> include Nuance, Microsoft Tellme, Voxeo (now Aspect, and also my=20 >> former employer), Tropo, Twilio, Convergys and many more[1]. >>=20 >> If STIR is to succeed, these kind of application platforms will also=20 >> need to be able to make calls on behalf of the companies using those > platforms. >>=20 >> Dan >>=20 >> [1] One report about this market: >> http://www.voxeo.com/pdf/OvumDecisionMatrix-2011.pdf >>=20 >>=20 >> -- >> Dan York >> Senior Content Strategist, Internet Society >> york@isoc.org +1-802-735-1624 >> Jabber: york@jabber.isoc.org >> Skype: danyork http://twitter.com/danyork >>=20 >> http://www.internetsociety.org/deploy360/ >>=20 >>=20 >>=20 >>=20 >> On 10/21/13 9:15 AM, "Brian Rosen" wrote: >>=20 >>> We really need to give each BPO different keys I think. The notion that >>> we are sharing private keys among multiple competing entities who=20 >>> provide services for a single enterprise strikes me as a VBI (Very=20 >>> Bad Idea). I can't see any real difficulty in having more than one=20 >>> 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=20 >>> more of it's >> BPOs. >>>=20 >>> Brian >>>=20 >>> On Oct 20, 2013, at 1:12 AM, Cullen Jennings (fluffy)=20 >>> >>> wrote: >>>=20 >>>>=20 >>>> What Fernando is saying makes sense to me a desirable property of=20 >>>> the solution and I agree that if we gave each BPO a different=20 >>>> private key that would solve it but that might be pretty hard to=20 >>>> mange in other ways. I like the requirements but the solution is=20 >>>> not 100% obvious to me. >>>>=20 >>>>=20 >>>> On Oct 2, 2013, at 10:27 AM, Brian Rosen wrote: >>>>=20 >>>>> Sure. >>>>>=20 >>>>> Each BPO would have a different private/public key pair. >>>>>=20 >>>>> So you can trace which one placed the call. >>>>>=20 >>>>> Brian >>>>>=20 >>>>> On Oct 2, 2013, at 12:59 PM, Fernando Mousinho (fmousinh)=20 >>>>> wrote: >>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> If the company hires several BPOs and authorizes all of them to=20 >>>>>> sign calls on its behalf, is there a way to trace back the=20 >>>>>> originator (specific >>>>>> BPO) >>>>>> later on? I suppose that at some level the actual caller must be=20 >>>>>> exposed (perhaps to trace malicious activity, such as malicious=20 >>>>>> person infiltrated in an otherwise legitimate BPO). >>>>>>=20 >>>>>> 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=20 >>>>>> identity). >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 9/19/13 9:43 PM, "Brian Rosen" wrote: >>>>>>=20 >>>>>>> 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=20 >>>>>>> change to use From (if signed maybe). It also doesn't fit the=20 >>>>>>> definition of PAI. >>>>>>>=20 >>>>>>> Brian >>>>>>>=20 >>>>>>> On Sep 19, 2013, at 9:14 PM, Fernando Mousinho (fmousinh)=20 >>>>>>> wrote: >>>>>>>=20 >>>>>>>> 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=20 >>>>>>>> on the delegation process Rosen mentions. >>>>>>>> PAI's use is widespread, and it's main limitation is being=20 >>>>>>>> spoofable - but this is exactly the problem we are trying to=20 >>>>>>>> solve anyway. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> On Sep 19, 2013, at 5:39 PM, "Richard Shockey"=20 >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>> Excellent point a profile or BCP to complement the work. >>>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On=20 >>>>>>>>> Behalf Of Alex Bobotek >>>>>>>>> Sent: Thursday, September 19, 2013 5:27 PM >>>>>>>>> To: Henning Schulzrinne; Michael Hammer; fmousinh@cisco.com;=20 >>>>>>>>> Gregory.Schumacher@sprint.com; br@brianrosen.net >>>>>>>>> Cc: stir@ietf.org >>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>=20 >>>>>>>>> +1 >>>>>>>>> I've assumed that we are headed towards a "sign whatever=20 >>>>>>>>> extras you wish, and indicate what your signature covers" mechanism. >>>>>>>>>=20 >>>>>>>>> Based on this, standards would need to identify only a minimal = >>>>>>>>> subset of what shall/should be signed, and ensure that any=20 >>>>>>>>> required group of signed items survives transit intact. >>>>>>>>>=20 >>>>>>>>> Best signing practices may be needed to complement the=20 >>>>>>>>> standard, and an appropriate place for all but the most basic = >>>>>>>>> 'what to sign' >>>>>>>>> recommendations. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Regards, >>>>>>>>>=20 >>>>>>>>> Alex >>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On = >>>>>>>>>> Behalf Of Henning Schulzrinne >>>>>>>>>> Sent: Thursday, September 19, 2013 2:24 PM >>>>>>>>>> To: Michael Hammer; fmousinh@cisco.com;=20 >>>>>>>>>> Gregory.Schumacher@sprint.com; br@brianrosen.net >>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>=20 >>>>>>>>>> I see no reason not to allow signing any number-related field = >>>>>>>>>> in the SIP request. (Signing may well be done by different >>>>>>>>>> parties.) >>>>>>>>>>=20 >>>>>>>>>> As far as I know, callback numbers (SIP Reply-To) aren't=20 >>>>>>>>>> conveyable in legacy systems, however, so this may be of=20 >>>>>>>>>> somewhat limited use for a >>>>>>>>> while. >>>>>>>>>>=20 >>>>>>>>>> ________________________________________ >>>>>>>>>> From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf = >>>>>>>>>> of Michael Hammer [michael.hammer@yaanatech.com] >>>>>>>>>> Sent: Thursday, September 19, 2013 4:34 PM >>>>>>>>>> To: fmousinh@cisco.com; Gregory.Schumacher@sprint.com;=20 >>>>>>>>>> br@brianrosen.net >>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>=20 >>>>>>>>>> Don't we still want to know the true originator of the call,=20 >>>>>>>>>> even when we have some token that says "Doctor so and so=20 >>>>>>>>>> approved this message." >>>>>>>>>>=20 >>>>>>>>>> Originating number, display number, and call-back number=20 >>>>>>>>>> could be >>>>>>>>>> 3 >>>>>>>>>> different things. >>>>>>>>>> Should all of them be verifiable? >>>>>>>>>>=20 >>>>>>>>>> Mike >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On = >>>>>>>>>> Behalf Of Fernando Mousinho (fmousinh) >>>>>>>>>> Sent: Thursday, September 19, 2013 4:00 PM >>>>>>>>>> To: Schumacher, Gregory [CTO]; Brian Rosen >>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>=20 >>>>>>>>>> I believe the scenario telemarketing here is when a client=20 >>>>>>>>>> hires a BPO to place outbound calls, but expect customers=20 >>>>>>>>>> to return these calls to a different place (say, their own=20 >>>>>>>>>> and operated call center). This way, this client is=20 >>>>>>>>>> authorizing the BPO to use an identity that it >>>>>>>>>> (BPO) >>>>>>>>> doesn't own. >>>>>>>>>> These numbers in this scenario are always operational, just=20 >>>>>>>>>> at a different place. >>>>>>>>>>=20 >>>>>>>>>> The same telemarketing operator would then outpulse multiple=20 >>>>>>>>>> numbers for their multiple clients, none of these numbers=20 >>>>>>>>>> belonging to the >>>>>>>>> telemarketer. >>>>>>>>>> BTW, we are using the term "telemarketing" in a very generic=20 >>>>>>>>>> sense - this could just as easily be a public service=20 >>>>>>>>>> announcement, fundraiser, >>>>>>>>> etc. >>>>>>>>>>=20 >>>>>>>>>> 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. >>>>>>>>>>=20 >>>>>>>>>> On a different note, it would help a lot of we standardized=20 >>>>>>>>>> terminology. >>>>>>>>>> Telemarketing, BPO, call center, end customer, clients=A9 it=20 >>>>>>>>>> may be hard for others to follow the discussion later. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> (generic term for any type of outbound calling, including=20 >>>>>>>>>> public service announcement, so don't think it's all about >>>>>>>>>> sales!) >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On 9/19/13 3:22 PM, "Schumacher, Gregory [CTO]" >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>> There are some benefits from this approach, but also some=20 >>>>>>>>>>> scenarios that need clarification how they could function. >>>>>>>>>>>=20 >>>>>>>>>>> The benefit is that the credential represents both the=20 >>>>>>>>>>> company "responsible" for the sales campaign (the "company" >>>>>>>>>>> in your >>>>>>>>>>> scenario) >>>>>>>>>>> and the company operating the sales campaign (the call=20 >>>>>>>>>>> center in your scenario). For the use in forensics (after = >>>>>>>>>>> the fact >>>>>>>>>>> analysis) such as pursuit of fraud investigation, we then=20 >>>>>>>>>>> can follow both paths. >>>>>>>>>>>=20 >>>>>>>>>>> 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=20 >>>>>>>>>>> telemarketing campaign or both? >>>>>>>>>>>=20 >>>>>>>>>>> - How is the SP supposed to know all the parties that it is=20 >>>>>>>>>>> attesting to >>>>>>>>>>> - the responsible party and/or executing party? >>>>>>>>>>>=20 >>>>>>>>>>> -It seems likely that some of the numbers assigned to a=20 >>>>>>>>>>> company in your scenario will not be assigned to real=20 >>>>>>>>>>> telephones (or call center >>>>>>>>>>> trunk) until a telemarketing campaign is initiated or a call = >>>>>>>>>>> center selected to execute the sales campaign, is it=20 >>>>>>>>>>> possible to have these unassigned or floating numbers when=20 >>>>>>>>>>> not in use for a telemarketing campaign? Is it allowed=20 >>>>>>>>>>> under most national numbering regimes? >>>>>>>>>>>=20 >>>>>>>>>>> - How important is it to have a known or recognized phone=20 >>>>>>>>>>> number as the caller id as part of a telemarketing = campaign? >>>>>>>>>>> I am assuming that not all campaigns care about having a=20 >>>>>>>>>>> number that is known or >>>>>>>>> recognized. >>>>>>>>>>>=20 >>>>>>>>>>> -In other words for this last bit, if a call center=20 >>>>>>>>>>> (telemarketing campaign operator) is using their own set of = >>>>>>>>>>> numbers but serve multiple simultaneous telemarketing=20 >>>>>>>>>>> campaigns using the same originating numbers, what will=20 >>>>>>>>>>> they sign? Will they just have a credential representing=20 >>>>>>>>>>> the call center alone, or a different credential per=20 >>>>>>>>>>> telemarketing campaign, or a different credential per=20 >>>>>>>>>>> responsible party (per client)? This will affect what is=20 >>>>>>>>>>> possible for >>>>>>>>> any forensic activity. >>>>>>>>>>>=20 >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org]=20 >>>>>>>>>>> On Behalf Of Brian Rosen >>>>>>>>>>> Sent: Tuesday, September 17, 2013 9:44 AM >>>>>>>>>>> To: Fernando Mousinho >>>>>>>>>>> Cc: stir@ietf.org; Hadriel Kaplan >>>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>>=20 >>>>>>>>>>> We have a requirement to support the BPO use case. >>>>>>>>>>>=20 >>>>>>>>>>> The notion we had is that the company contracting the call=20 >>>>>>>>>>> center approves the use, and the call center, or the SP=20 >>>>>>>>>>> acting on its behalf, signs. >>>>>>>>>>> Think of this as another level of delegation. An SP=20 >>>>>>>>>>> delegates numbers to the company. The company "delegates" >>>>>>>>>>> use of those numbers to the call center. The call center=20 >>>>>>>>>>> calls, using that delegation. >>>>>>>>>>> The credentials of the call center would be different from=20 >>>>>>>>>>> those of the company, but would cover the same number. >>>>>>>>>>> Having multiple credentials covering the same number will=20 >>>>>>>>>>> be very common due to the way delegation happens. In order = >>>>>>>>>>> to allow SPs to sign, without creating credential per TN,=20 >>>>>>>>>>> we allow credentials with ranges. >>>>>>>>>>> The >>>>>>>>>>> ranges could overlap when delegation happens. >>>>>>>>>>>=20 >>>>>>>>>>> Consider the following complex US case: >>>>>>>>>>> The North American Number Plan Administrator delegates=20 >>>>>>>>>>> 202-555-xxxx to the Pooling Administrator. The PA now has=20 >>>>>>>>>>> a credential covering the entire 10K block. >>>>>>>>>>> The Pooling Administrator delegates 202-555-1xxx to SP A. =20 >>>>>>>>>>> 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=20 >>>>>>>>>>> 202-555-123x to Company C. Company C has a credential for=20 >>>>>>>>>>> a >>>>>>>>>>> 10 number block Company C authorizes 202-555-1234 to BPO D. = =20 >>>>>>>>>>> BPO D has credential for a 1 number block >>>>>>>>>>>=20 >>>>>>>>>>> NANPA and the PA never are in a call path, so they would=20 >>>>>>>>>>> never sign a call. >>>>>>>>>>>=20 >>>>>>>>>>> However, SP A or SP B could sign a call from either Company=20 >>>>>>>>>>> C or BPO D using the credential they have. >>>>>>>>>>>=20 >>>>>>>>>>> The SP for the call center could acquire credentials from=20 >>>>>>>>>>> the BPO and sign on its behalf. I suspect than many=20 >>>>>>>>>>> service providers would be reluctant to do so unless the=20 >>>>>>>>>>> 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=20 >>>>>>>>>>> probably has to do the signing itself. >>>>>>>>>>>=20 >>>>>>>>>>> Brian >>>>>>>>>>>=20 >>>>>>>>>>> On Sep 17, 2013, at 8:46 AM, Fernando Mousinho (fmousinh)=20 >>>>>>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> I agree, Hadriel. While large call centers (including BPOs, = >>>>>>>>>>>> which provide services for other companies) may have=20 >>>>>>>>>>>> special arrangements with SPs, the majority (small to >>>>>>>>>>>> mid-size) will probably rely on the SPs to do provide to=20 >>>>>>>>>>>> vouch for their identity. This would probably be the case=20 >>>>>>>>>>>> for the home analog caller anyway. This would imply that=20 >>>>>>>>>>>> the "originating" SP's willingness to provide this=20 >>>>>>>>>>>> signature is a critical success factor for the proposal's > adoption. >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> But back to the business process outsourcers (BPO) case -=20 >>>>>>>>>>>> where a call center is providing service on behalf of=20 >>>>>>>>>>>> multiple companies. I can see the value of them sending=20 >>>>>>>>>>>> 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=20 >>>>>>>>>>>> that SP >>>>>>>>>>>> 1 allowing one of its subscribers to send an outbound call=20 >>>>>>>>>>>> using a number registered to SP 2 could be a no-no. If=20 >>>>>>>>>>>> this hypothesis is correct, then we are back to the case=20 >>>>>>>>>>>> where the SP is signing all calls, >>>>>>>>>> even for BPOs. >>>>>>>>>>>>=20 >>>>>>>>>>>> Or maybe this is another problem we are trying to fix in=20 >>>>>>>>>>>> the working group, in which case we perhaps should state as = >>>>>>>>>>>> a goal or >>>>>>>>> benefit: >>>>>>>>>>>> "providing a reliable mechanism to let calls originated=20 >>>>>>>>>>>> from one >>>>>>>>>>>> SP1 to outpulse numbers that belong to another". >>>>>>>>>>>>=20 >>>>>>>>>>>> Fernando >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> On 9/16/13 12:12 PM, "Hadriel Kaplan" >>>>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Any of them could do it. My guess is service providers=20 >>>>>>>>>>>>> will do it for most call centers, although larger call=20 >>>>>>>>>>>>> centers might do it themselves... >>>>>>>>>>>>> especially ones which have trunks from multiple providers=20 >>>>>>>>>>>>> and can source calls using the same number(s) out through = >>>>>>>>>>>>> multiple providers on a call-by-call basis. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> -hadriel >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Sep 16, 2013, at 9:49 AM, Fernando Mousinho (fmousinh)=20 >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I'm catching up with the discussions in this working=20 >>>>>>>>>>>>>> group, and am trying to understand some architecture=20 >>>>>>>>>>>>>> implications in call centers (which is where my=20 >>>>>>>>>>>>>> background is). It seems that many of the problems we=20 >>>>>>>>>>>>>> are trying to fix are related to contact centers anyway, = >>>>>>>>>>>>>> so it is probably a good idea to have everyone in the=20 >>>>>>>>>>>>>> same >>>>>>>>>> page. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Forgive me if it is an obvious question, but which=20 >>>>>>>>>>>>>> components in a "typical call center architecture" do=20 >>>>>>>>>>>>>> you see signature and verification taking place? Such "typical" >>>>>>>>>>>>>> deployments have premises based equipment (PME), a=20 >>>>>>>>>>>>>> session border controller >>>>>>>>>>>>>> (SBC) >>>>>>>>>>>>>> and of course a SIP service provider all three could=20 >>>>>>>>>>>>>> potentially be used throughout the authorization = process. >>>>>>>>>>>>>> There are different ramifications depending on where=20 >>>>>>>>>>>>>> your mind is at. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Fernando Mousinho >>>>>>>>>>>>>> Cisco Systems >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> stir mailing list >>>>>>>>>>>> stir@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> stir mailing list >>>>>>>>>>> stir@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> ________________________________ >>>>>>>>>>>=20 >>>>>>>>>>> This e-mail may contain Sprint proprietary information=20 >>>>>>>>>>> intended for the sole use of the recipient(s). Any use by=20 >>>>>>>>>>> others is prohibited. >>>>>>>>>>> If >>>>>>>>>>> you are not the intended recipient, please contact the=20 >>>>>>>>>>> sender and delete all copies of the message. >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> stir mailing list >>>>>>>>>>> stir@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> stir mailing list >>>>>>>>>> stir@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>> _______________________________________________ >>>>>>>>>> stir mailing list >>>>>>>>>> stir@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>> _______________________________________________ >>>>>>>>> stir mailing list >>>>>>>>> stir@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> stir mailing list >>>>> stir@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/stir >>>>=20 >>>=20 >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> cnit mailing list >> cnit@ietf.org >> https://www.ietf.org/mailman/listinfo/cnit >=20 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch ------=_NextPart_000_031A_01CED660.DFA107C0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMTAz MTIxNDQzOVowIwYJKoZIhvcNAQkEMRYEFDsGKr9OCPbIwhOh38GGPJjtejwhMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEANSQfmzlXco018noX2ApDq3+ASAARcjma4oquI6o7 yQLt4Ze46Mo2ImA0mIygnH0mDSdYlRiOSjo40eSCsep/2l8OJwe4AQco64syQE74Qxy/RRe67dWo YCBORVZpxc1buLWcCKLGSX0BzEVl2rnAo0AsrffDoc2GpfflbsSmzCz5XzaEDIKwpdabQJwo92jK D9jDUeinCogIMzpRIRA7BjzozIPtrBxLjx6Hpf9QKwsIvNUYEUOTQVc59rfEACHOaHvJuD46WrHP tQY6yWY18qxy+3sHGKKNabbsn4OJgE9Z6EvgdjsHpUfRuo5jCtlWqX6x0hH9qH1tsehsVYk47gAA AAAAAA== ------=_NextPart_000_031A_01CED660.DFA107C0-- From richard@shockey.us Thu Oct 31 14:47:34 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F406F11E825F for ; Thu, 31 Oct 2013 14:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.11 X-Spam-Level: X-Spam-Status: No, score=-101.11 tagged_above=-999 required=5 tests=[AWL=-0.811, BAYES_00=-2.599, MANGLED_COMPNY=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ELVKL9WNuTD2 for ; Thu, 31 Oct 2013 14:47:21 -0700 (PDT) Received: from qproxy1-pub.mail.unifiedlayer.com (qproxy1-pub.mail.unifiedlayer.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id 979A011E814C for ; Thu, 31 Oct 2013 14:47:21 -0700 (PDT) Received: (qmail 15323 invoked by uid 0); 31 Oct 2013 21:46:59 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by qproxy1.mail.unifiedlayer.com with SMTP; 31 Oct 2013 21:46:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=g9D0YNfZMrZgAyX7nq/2VHPQfaqqLSad2/HjLDv75Gs=; b=NS1daryAreYmFJzdJQiCLN9LMw/m9X7QAFvjWJvZkH6uFwP/NAlcFH3u37+tkNTOuFamcmuSWg0ZXub2116caFBb8aMQqERkl2qotG0fnSg5vRKkuI4MGeoz3UpNtMG0; Received: from [173.79.179.104] (port=54429 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Vc04w-0005Ew-K9; Thu, 31 Oct 2013 15:46:59 -0600 From: "Richard Shockey" To: "'Gorman, Pierce A [NTK]'" , "'Brian Rosen'" References: <32C55AFE-FA17-4776-AD91-259AD3E226BE@brianrosen.net> <024001ced5a2$f3268810$d9739830$@shockey.us> <029501ced5b5$8fa9f480$aefddd80$@shockey.us> <2AA32171-1AE3-4AEE-AEDC-B2031562B7BD@brianrosen.net> <00d901ced637$9e8143a0$db83cae0$@shockey.us> <8B0027B8-D777-48F3-B5BF-B8F81F038E37@brianrosen.net> In-Reply-To: Date: Thu, 31 Oct 2013 17:46:57 -0400 Message-ID: <021501ced682$b9ef18b0$2dcd4a10$@shockey.us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQLTdCvgrcMvmbDsv2xAt2r4G5TZbQLC46EgAqz016cBpe129QIWVK8PAdOJjcEBFampjAM/6Rz4l4twfGA= X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.79.179.104 authed with richard@shockey.us} Cc: cnit@ietf.org, "'Schumacher, Gregory \[CTO\]'" Subject: Re: [cnit] [stir] Application servers - Re: Call Center Implications X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 21:47:34 -0000 -----Original Message----- From: Gorman, Pierce A [NTK] [mailto:Pierce.Gorman@sprint.com]=20 Sent: Thursday, October 31, 2013 2:22 PM To: Brian Rosen; Richard Shockey Cc: cnit@ietf.org; Schumacher, Gregory [CTO] Subject: RE: [cnit] [stir] Application servers - Re: Call Center Implications I'm not sure I'd say the CNAM business model is broken if there are CNAM providers making a profit. :-) [RS> ] We don't need to go there in this forum but the existing = structure has "issues". That is not to say CNAM or something like a NG CNAM or = CNAM + is not a good business and could drive ARPU. Far from it. Orthogonally = but related HD Voice in VoLTE is IMHO going to be a gigantic money maker for mobile operators. Just today I was joking with a colleague that the = second most successful marketing campaign in the history of US Telecom was = Sprint Pin Drop. The First being MCI Friends and Family. There is no doubt = in my mind the some smart brain in Sprint should dust off those commercials = when HD Voice rolls out. Candice Bergen is still around BTW. A better CNAM = I would be happy to argue is actually enhancing the overall service presentation to the consumer which our regulatory friends would never = object to .. IMHO.=20 To be a little more serious, there is value in using content indirection (which is the CNAM model). The verified calling ID (assuming STIR will = be successful) would be a lightweight pointer to content a UA might like to present or see/hear. With respect to how to pass additional information = in SIP (including content), IMHO it might be easier to add something like a = 2nd message body with (verified?) XML or URI, et cetera, than to try to add = new SIP headers or change handling for parts of existing headers such as the display name. (The B2BUAs in many softswitches simply discard display name.) [RS> ]=20 [RS> ] So I'm assuming then you don't think I'm insane either? :-)=20 Best regards, Pierce Gorman Voice Architecture Core Planning/Sprint 913-439-4368 (Desk) -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: October 31, 2013 12:19 PM To: Richard Shockey Cc: cnit@ietf.org; DISPATCH Subject: Re: [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. I am very interested in working on improving caller name. Brian On Oct 31, 2013, at 8:49 AM, Richard Shockey wrote: > > 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=20 > accuracy, reliability and the amount of data that is delivered to the=20 > CUA over who is attempting to establish a session. > > The larger issue is the integrity of the entire real time=20 > 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=20 > 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=20 > 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=20 > that National Regulators would be delighted with consumers having a=20 > 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=20 > interconnection among providers it would be really really useful if=20 > Enterprise systems could extract more data from their internal=20 > 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=20 > to Point video calling using WebRTC or SIP if there is not better=20 > display of calling party information. > > In addition network operators could insert other 'hints' as to the=20 > nature of the session based on its ability to validate the Caller ID=20 > or other forms on analysis. > > I'm well aware of how CNAM is delivered in North America and I'm=20 > equally aware the CNAM business model is broken. > > What I'd like to know is what interest there is in this proposition=20 > and are there parties interested in working on it in advance of say London. > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, October 30, 2013 5:39 PM > To: Richard Shockey > Cc: cnit@ietf.org > Subject: Re: [cnit] [stir] Application servers - Re: Call Center=20 > 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=20 > the origination side, and signed as the number is. > > That is a significant change to the current infrastructure, which at=20 > least in North America relies on a termination service provider dip in = > an origination service provider database, but it seems feasible to=20 > consider that. > > Brian > > On Oct 30, 2013, at 5:18 PM, Richard Shockey = 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: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >> Of Richard Shockey >> Sent: Wednesday, October 30, 2013 3:05 PM >> To: stir@ietf.org >> Subject: Re: [stir] Application servers - Re: Call Center=20 >> 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=20 >> terminating CUA, "an accurate and truthful" Caller-ID for the call=20 >> even if it is originated from a source that is not directly=20 >> 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=20 >> RESPORGS. >> >> If the originating UA can prove/assert it is legally authorized to=20 >> use such an identity on behalf of a customer then that is step one. >> The presumption after that is there is some contractual obligation=20 >> 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=20 >> the called party and frankly 15 character ASCII is not enough. >> Consumers or businesses should be able to see more complete and=20 >> validated information about the session in order to make an better=20 >> 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=20 >> verbose calling party identification could be displayed. I certainly = >> want to answer a call from my doctor on my test results just as I=20 >> wish to ignore a call from Bill Clinton begging me to vote in the=20 >> Virginia Governors election next Tuesday. This is a case where=20 >> 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=20 >> probably a reasonable modification of the Call INFO header in SIP=20 >> with something like a XML based VCARD or JCARD URI whatever and=20 >> 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: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >> Of Dan York >> Sent: Tuesday, October 29, 2013 5:10 PM >> To: Brian Rosen; Cullen Jennings >> Cc: Gregory.Schumacher@sprint.com; Richard Shockey; stir@ietf.org;=20 >> Fernando Mousinho (fmousinh); Alex Bobotek; Michael Hammer; Henning=20 >> 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=20 >> that we're not only talking about "traditional" call centers but also = >> what I'll call "voice application service providers". They are=20 >> generally automated platforms running applications that a company=20 >> uses for some kind of outbound service. Examples include: >> >> - calling everyone in a school district with a weather-related=20 >> cancellation (or, unfortunately, a school shooting or similar event) >> - calling patients to provide reminders of appointments or=20 >> notifications of subscriptions available >> - calling customers to let them know that a package was delivered or=20 >> 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=20 >> current issues >> - performing a call-back to provide an additional layer of=20 >> authentication for some service >> >> There is a large (and growing) market for these kind of automated=20 >> tools and services and the distinction between these calls and=20 >> "robocalls" is really only one of intent and the fact that the=20 >> recipient > has "opted in" >> through some kind of system. >> >> Generally, though, many of the companies want the application to=20 >> 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=20 >> from one of their own phone numbers. >> >> You could think of these in the same way as "call centers", but I=20 >> point this out because some of these new services are very automated=20 >> and there are always new startups now emerging in this space. Some=20 >> of them are very "self-service" where the customer does it all while=20 >> others have teams of people involved. Some of the companies involved = >> include Nuance, Microsoft Tellme, Voxeo (now Aspect, and also my=20 >> former employer), Tropo, Twilio, Convergys and many more[1]. >> >> If STIR is to succeed, these kind of application platforms will also=20 >> 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 >> york@isoc.org +1-802-735-1624 >> Jabber: york@jabber.isoc.org >> Skype: danyork http://twitter.com/danyork >> >> http://www.internetsociety.org/deploy360/ >> >> >> >> >> On 10/21/13 9:15 AM, "Brian Rosen" 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=20 >>> provide services for a single enterprise strikes me as a VBI (Very=20 >>> Bad Idea). I can't see any real difficulty in having more than one=20 >>> 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=20 >>> more of it's >> BPOs. >>> >>> Brian >>> >>> On Oct 20, 2013, at 1:12 AM, Cullen Jennings (fluffy)=20 >>> >>> wrote: >>> >>>> >>>> What Fernando is saying makes sense to me a desirable property of=20 >>>> the solution and I agree that if we gave each BPO a different=20 >>>> private key that would solve it but that might be pretty hard to=20 >>>> mange in other ways. I like the requirements but the solution is=20 >>>> not 100% obvious to me. >>>> >>>> >>>> On Oct 2, 2013, at 10:27 AM, Brian Rosen 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)=20 >>>>> 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=20 >>>>>> sign calls on its behalf, is there a way to trace back the=20 >>>>>> originator (specific >>>>>> BPO) >>>>>> later on? I suppose that at some level the actual caller must be=20 >>>>>> exposed (perhaps to trace malicious activity, such as malicious=20 >>>>>> 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=20 >>>>>> identity). >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 9/19/13 9:43 PM, "Brian Rosen" 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=20 >>>>>>> change to use From (if signed maybe). It also doesn't fit the=20 >>>>>>> definition of PAI. >>>>>>> >>>>>>> Brian >>>>>>> >>>>>>> On Sep 19, 2013, at 9:14 PM, Fernando Mousinho (fmousinh)=20 >>>>>>> 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=20 >>>>>>>> on the delegation process Rosen mentions. >>>>>>>> PAI's use is widespread, and it's main limitation is being=20 >>>>>>>> spoofable - but this is exactly the problem we are trying to=20 >>>>>>>> solve anyway. >>>>>>>> >>>>>>>> >>>>>>>>> On Sep 19, 2013, at 5:39 PM, "Richard Shockey" >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Excellent point a profile or BCP to complement the work. >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On=20 >>>>>>>>> Behalf Of Alex Bobotek >>>>>>>>> Sent: Thursday, September 19, 2013 5:27 PM >>>>>>>>> To: Henning Schulzrinne; Michael Hammer; fmousinh@cisco.com;=20 >>>>>>>>> Gregory.Schumacher@sprint.com; br@brianrosen.net >>>>>>>>> Cc: stir@ietf.org >>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>> >>>>>>>>> +1 >>>>>>>>> I've assumed that we are headed towards a "sign whatever=20 >>>>>>>>> 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=20 >>>>>>>>> required group of signed items survives transit intact. >>>>>>>>> >>>>>>>>> Best signing practices may be needed to complement the=20 >>>>>>>>> standard, and an appropriate place for all but the most basic = >>>>>>>>> 'what to sign' >>>>>>>>> recommendations. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Alex >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On = >>>>>>>>>> Behalf Of Henning Schulzrinne >>>>>>>>>> Sent: Thursday, September 19, 2013 2:24 PM >>>>>>>>>> To: Michael Hammer; fmousinh@cisco.com;=20 >>>>>>>>>> Gregory.Schumacher@sprint.com; br@brianrosen.net >>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>> 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=20 >>>>>>>>>> conveyable in legacy systems, however, so this may be of=20 >>>>>>>>>> somewhat limited use for a >>>>>>>>> while. >>>>>>>>>> >>>>>>>>>> ________________________________________ >>>>>>>>>> From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf = >>>>>>>>>> of Michael Hammer [michael.hammer@yaanatech.com] >>>>>>>>>> Sent: Thursday, September 19, 2013 4:34 PM >>>>>>>>>> To: fmousinh@cisco.com; Gregory.Schumacher@sprint.com;=20 >>>>>>>>>> br@brianrosen.net >>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>> >>>>>>>>>> Don't we still want to know the true originator of the call,=20 >>>>>>>>>> even when we have some token that says "Doctor so and so=20 >>>>>>>>>> approved this message." >>>>>>>>>> >>>>>>>>>> Originating number, display number, and call-back number=20 >>>>>>>>>> could be >>>>>>>>>> 3 >>>>>>>>>> different things. >>>>>>>>>> Should all of them be verifiable? >>>>>>>>>> >>>>>>>>>> Mike >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On = >>>>>>>>>> Behalf Of Fernando Mousinho (fmousinh) >>>>>>>>>> Sent: Thursday, September 19, 2013 4:00 PM >>>>>>>>>> To: Schumacher, Gregory [CTO]; Brian Rosen >>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>> >>>>>>>>>> I believe the scenario telemarketing here is when a client=20 >>>>>>>>>> hires a BPO to place outbound calls, but expect customers=20 >>>>>>>>>> to return these calls to a different place (say, their own=20 >>>>>>>>>> and operated call center). This way, this client is=20 >>>>>>>>>> authorizing the BPO to use an identity that it >>>>>>>>>> (BPO) >>>>>>>>> doesn't own. >>>>>>>>>> These numbers in this scenario are always operational, just=20 >>>>>>>>>> at a different place. >>>>>>>>>> >>>>>>>>>> The same telemarketing operator would then outpulse multiple=20 >>>>>>>>>> numbers for their multiple clients, none of these numbers=20 >>>>>>>>>> belonging to the >>>>>>>>> telemarketer. >>>>>>>>>> BTW, we are using the term "telemarketing" in a very generic=20 >>>>>>>>>> sense - this could just as easily be a public service=20 >>>>>>>>>> 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=20 >>>>>>>>>> terminology. >>>>>>>>>> Telemarketing, BPO, call center, end customer, clients=A9 it=20 >>>>>>>>>> may be hard for others to follow the discussion later. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> (generic term for any type of outbound calling, including=20 >>>>>>>>>> public service announcement, so don't think it's all about >>>>>>>>>> sales!) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 9/19/13 3:22 PM, "Schumacher, Gregory [CTO]" >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> There are some benefits from this approach, but also some=20 >>>>>>>>>>> scenarios that need clarification how they could function. >>>>>>>>>>> >>>>>>>>>>> The benefit is that the credential represents both the=20 >>>>>>>>>>> company "responsible" for the sales campaign (the "company" >>>>>>>>>>> in your >>>>>>>>>>> scenario) >>>>>>>>>>> and the company operating the sales campaign (the call=20 >>>>>>>>>>> center in your scenario). For the use in forensics (after = >>>>>>>>>>> the fact >>>>>>>>>>> analysis) such as pursuit of fraud investigation, we then=20 >>>>>>>>>>> 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=20 >>>>>>>>>>> telemarketing campaign or both? >>>>>>>>>>> >>>>>>>>>>> - How is the SP supposed to know all the parties that it is=20 >>>>>>>>>>> attesting to >>>>>>>>>>> - the responsible party and/or executing party? >>>>>>>>>>> >>>>>>>>>>> -It seems likely that some of the numbers assigned to a=20 >>>>>>>>>>> company in your scenario will not be assigned to real=20 >>>>>>>>>>> telephones (or call center >>>>>>>>>>> trunk) until a telemarketing campaign is initiated or a call = >>>>>>>>>>> center selected to execute the sales campaign, is it=20 >>>>>>>>>>> possible to have these unassigned or floating numbers when=20 >>>>>>>>>>> not in use for a telemarketing campaign? Is it allowed=20 >>>>>>>>>>> under most national numbering regimes? >>>>>>>>>>> >>>>>>>>>>> - How important is it to have a known or recognized phone=20 >>>>>>>>>>> number as the caller id as part of a telemarketing = campaign? >>>>>>>>>>> I am assuming that not all campaigns care about having a=20 >>>>>>>>>>> number that is known or >>>>>>>>> recognized. >>>>>>>>>>> >>>>>>>>>>> -In other words for this last bit, if a call center=20 >>>>>>>>>>> (telemarketing campaign operator) is using their own set of = >>>>>>>>>>> numbers but serve multiple simultaneous telemarketing=20 >>>>>>>>>>> campaigns using the same originating numbers, what will=20 >>>>>>>>>>> they sign? Will they just have a credential representing=20 >>>>>>>>>>> the call center alone, or a different credential per=20 >>>>>>>>>>> telemarketing campaign, or a different credential per=20 >>>>>>>>>>> responsible party (per client)? This will affect what is=20 >>>>>>>>>>> possible for >>>>>>>>> any forensic activity. >>>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org]=20 >>>>>>>>>>> On Behalf Of Brian Rosen >>>>>>>>>>> Sent: Tuesday, September 17, 2013 9:44 AM >>>>>>>>>>> To: Fernando Mousinho >>>>>>>>>>> Cc: stir@ietf.org; 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=20 >>>>>>>>>>> center approves the use, and the call center, or the SP=20 >>>>>>>>>>> acting on its behalf, signs. >>>>>>>>>>> Think of this as another level of delegation. An SP=20 >>>>>>>>>>> delegates numbers to the company. The company "delegates" >>>>>>>>>>> use of those numbers to the call center. The call center=20 >>>>>>>>>>> calls, using that delegation. >>>>>>>>>>> The credentials of the call center would be different from=20 >>>>>>>>>>> those of the company, but would cover the same number. >>>>>>>>>>> Having multiple credentials covering the same number will=20 >>>>>>>>>>> be very common due to the way delegation happens. In order = >>>>>>>>>>> to allow SPs to sign, without creating credential per TN,=20 >>>>>>>>>>> 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=20 >>>>>>>>>>> 202-555-xxxx to the Pooling Administrator. The PA now has=20 >>>>>>>>>>> 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=20 >>>>>>>>>>> 202-555-123x to Company C. Company C has a credential for=20 >>>>>>>>>>> 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=20 >>>>>>>>>>> never sign a call. >>>>>>>>>>> >>>>>>>>>>> However, SP A or SP B could sign a call from either Company=20 >>>>>>>>>>> C or BPO D using the credential they have. >>>>>>>>>>> >>>>>>>>>>> The SP for the call center could acquire credentials from=20 >>>>>>>>>>> the BPO and sign on its behalf. I suspect than many=20 >>>>>>>>>>> service providers would be reluctant to do so unless the=20 >>>>>>>>>>> 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=20 >>>>>>>>>>> probably has to do the signing itself. >>>>>>>>>>> >>>>>>>>>>> Brian >>>>>>>>>>> >>>>>>>>>>> On Sep 17, 2013, at 8:46 AM, Fernando Mousinho (fmousinh)=20 >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> I agree, Hadriel. While large call centers (including BPOs, = >>>>>>>>>>>> which provide services for other companies) may have=20 >>>>>>>>>>>> special arrangements with SPs, the majority (small to >>>>>>>>>>>> mid-size) will probably rely on the SPs to do provide to=20 >>>>>>>>>>>> vouch for their identity. This would probably be the case=20 >>>>>>>>>>>> for the home analog caller anyway. This would imply that=20 >>>>>>>>>>>> the "originating" SP's willingness to provide this=20 >>>>>>>>>>>> signature is a critical success factor for the proposal's > adoption. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> But back to the business process outsourcers (BPO) case -=20 >>>>>>>>>>>> where a call center is providing service on behalf of=20 >>>>>>>>>>>> multiple companies. I can see the value of them sending=20 >>>>>>>>>>>> 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=20 >>>>>>>>>>>> that SP >>>>>>>>>>>> 1 allowing one of its subscribers to send an outbound call=20 >>>>>>>>>>>> using a number registered to SP 2 could be a no-no. If=20 >>>>>>>>>>>> this hypothesis is correct, then we are back to the case=20 >>>>>>>>>>>> where the SP is signing all calls, >>>>>>>>>> even for BPOs. >>>>>>>>>>>> >>>>>>>>>>>> Or maybe this is another problem we are trying to fix in=20 >>>>>>>>>>>> the working group, in which case we perhaps should state as = >>>>>>>>>>>> a goal or >>>>>>>>> benefit: >>>>>>>>>>>> "providing a reliable mechanism to let calls originated=20 >>>>>>>>>>>> from one >>>>>>>>>>>> SP1 to outpulse numbers that belong to another". >>>>>>>>>>>> >>>>>>>>>>>> Fernando >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 9/16/13 12:12 PM, "Hadriel Kaplan" >>>>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Any of them could do it. My guess is service providers=20 >>>>>>>>>>>>> will do it for most call centers, although larger call=20 >>>>>>>>>>>>> centers might do it themselves... >>>>>>>>>>>>> especially ones which have trunks from multiple providers=20 >>>>>>>>>>>>> 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)=20 >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> I'm catching up with the discussions in this working=20 >>>>>>>>>>>>>> group, and am trying to understand some architecture=20 >>>>>>>>>>>>>> implications in call centers (which is where my=20 >>>>>>>>>>>>>> background is). It seems that many of the problems we=20 >>>>>>>>>>>>>> are trying to fix are related to contact centers anyway, = >>>>>>>>>>>>>> so it is probably a good idea to have everyone in the=20 >>>>>>>>>>>>>> same >>>>>>>>>> page. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Forgive me if it is an obvious question, but which=20 >>>>>>>>>>>>>> components in a "typical call center architecture" do=20 >>>>>>>>>>>>>> you see signature and verification taking place? Such "typical" >>>>>>>>>>>>>> deployments have premises based equipment (PME), a=20 >>>>>>>>>>>>>> session border controller >>>>>>>>>>>>>> (SBC) >>>>>>>>>>>>>> and of course a SIP service provider all three could=20 >>>>>>>>>>>>>> potentially be used throughout the authorization = process. >>>>>>>>>>>>>> There are different ramifications depending on where=20 >>>>>>>>>>>>>> your mind is at. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Fernando Mousinho >>>>>>>>>>>>>> Cisco Systems >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> stir mailing list >>>>>>>>>>>> stir@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> stir mailing list >>>>>>>>>>> stir@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ________________________________ >>>>>>>>>>> >>>>>>>>>>> This e-mail may contain Sprint proprietary information=20 >>>>>>>>>>> intended for the sole use of the recipient(s). Any use by=20 >>>>>>>>>>> others is prohibited. >>>>>>>>>>> If >>>>>>>>>>> you are not the intended recipient, please contact the=20 >>>>>>>>>>> sender and delete all copies of the message. >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> stir mailing list >>>>>>>>>>> stir@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> stir mailing list >>>>>>>>>> stir@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>> _______________________________________________ >>>>>>>>>> stir mailing list >>>>>>>>>> stir@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>> _______________________________________________ >>>>>>>>> stir mailing list >>>>>>>>> stir@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> stir mailing list >>>>> stir@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/stir >>>> >>> >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >> >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >> >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >> >> _______________________________________________ >> cnit mailing list >> cnit@ietf.org >> https://www.ietf.org/mailman/listinfo/cnit > ________________________________ 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 richard@shockey.us Thu Oct 31 15:12:27 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1284821E8102 for ; Thu, 31 Oct 2013 15:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.763 X-Spam-Level: X-Spam-Status: No, score=-100.763 tagged_above=-999 required=5 tests=[AWL=-1.064, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, MANGLED_COMPNY=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jaVzVGnmz1ub for ; Thu, 31 Oct 2013 15:12:22 -0700 (PDT) Received: from outbound-ss-2.hostmonster.com (outbound-ss-2.hostmonster.com [66.147.240.26]) by ietfa.amsl.com (Postfix) with SMTP id 6518E11E81BE for ; Thu, 31 Oct 2013 15:12:22 -0700 (PDT) Received: (qmail 4598 invoked by uid 0); 31 Oct 2013 21:33:43 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy14.mail.unifiedlayer.com with SMTP; 31 Oct 2013 21:33:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=TndjlG0YKSQV5cuDnoZInODPFsLJfT4RG4CQ6bBynqo=; b=OcvspdOh0vbKzl6lX7XT4x1zPuAYQPZiQ3Kr8UYZ/RE+74CqSkjvni8M7SiYVQPH7/jp5TQWKLS9Os5b/aUweVEh6AYF+kPIcNMAN/K3orMuCsH2ExCfPs89c0K/Rrp9; Received: from [173.79.179.104] (port=54349 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Vbzs6-0002oy-S1; Thu, 31 Oct 2013 15:33:43 -0600 From: "Richard Shockey" To: "'Henning Schulzrinne'" , "'Brian Rosen'" References: <32C55AFE-FA17-4776-AD91-259AD3E226BE@brianrosen.net> <024001ced5a2$f3268810$d9739830$@shockey.us> <029501ced5b5$8fa9f480$aefddd80$@shockey.us> <2AA32171-1AE3-4AEE-AEDC-B2031562B7BD@brianrosen.net> <00d901ced637$9e8143a0$db83cae0$@shockey.us> <8B0027B8-D777-48F3-B5BF-B8F81F038E37@brianrosen.net> In-Reply-To: Date: Thu, 31 Oct 2013 17:33:42 -0400 Message-ID: <021301ced680$dfa0d320$9ee27960$@shockey.us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQLTdCvgrcMvmbDsv2xAt2r4G5TZbQLC46EgAqz016cBpe129QIWVK8PAdOJjcEBFampjAIH39Xjl5Uv3eA= X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.79.179.104 authed with richard@shockey.us} Cc: cnit@ietf.org, 'DISPATCH' Subject: Re: [cnit] [dispatch] [stir] Application servers - Re: Call Center Implications X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 22:12:27 -0000 +1 -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]=20 Sent: Thursday, October 31, 2013 1:37 PM To: 'Brian Rosen'; Richard Shockey Cc: cnit@ietf.org; DISPATCH Subject: RE: [dispatch] [cnit] [stir] Application servers - Re: Call = Center Implications Call-info: ;purpose=3Dcard or purpose=3Dinfo 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: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Brian Rosen Sent: Thursday, October 31, 2013 1:19 PM To: Richard Shockey Cc: cnit@ietf.org; 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. I am very interested in working on improving caller name. Brian On Oct 31, 2013, at 8:49 AM, Richard Shockey wrote: >=20 > Brian please.. Look at the mail. I'm using the CNIT list. =20 >=20 > The issue is can we use the tools at hand to increase both the=20 > accuracy, reliability and the amount of data that is delivered to the=20 > CUA over who is attempting to establish a session. >=20 > The larger issue is the integrity of the entire real time=20 > 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. >=20 > CNAM as it is currently defined in SS7 is a terrible service. 15=20 > Character ASCII. No support for International character sets the = usual. >=20 > 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=20 > 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=20 > that National Regulators would be delighted with consumers having a=20 > 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=20 > interconnection among providers it would be really really useful if=20 > Enterprise systems could extract more data from their internal=20 > directory systems and pass that along in the new format for = enterprise calling as well. >=20 > I would certainly argue that we are not going to see ubiquitous Point=20 > to Point video calling using WebRTC or SIP if there is not better=20 > display of calling party information. >=20 > In addition network operators could insert other 'hints' as to the=20 > nature of the session based on its ability to validate the Caller ID=20 > or other forms on analysis. >=20 > I'm well aware of how CNAM is delivered in North America and I'm=20 > equally aware the CNAM business model is broken. >=20 > What I'd like to know is what interest there is in this proposition=20 > and are there parties interested in working on it in advance of say London. >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, October 30, 2013 5:39 PM > To: Richard Shockey > Cc: cnit@ietf.org > Subject: Re: [cnit] [stir] Application servers - Re: Call Center=20 > Implications >=20 > More useful in what way? Improving the reliability of caller name? =20 > Please use the cnit list to discuss this. >=20 > 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=20 > the origination side, and signed as the number is. >=20 > That is a significant change to the current infrastructure, which at=20 > least in North America relies on a termination service provider dip in = > an origination service provider database, but it seems feasible to=20 > consider that. >=20 > Brian >=20 > On Oct 30, 2013, at 5:18 PM, Richard Shockey = wrote: >=20 >>=20 >> Ok since Brian is being picky.. >>=20 >> I'm actually interested if anyone is interested in the possibility of = >> making SIP Identity to the UA more useful. >>=20 >>=20 >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >> Of Richard Shockey >> Sent: Wednesday, October 30, 2013 3:05 PM >> To: stir@ietf.org >> Subject: Re: [stir] Application servers - Re: Call Center=20 >> Implications >>=20 >> Dan great post. I couldn't agree more. There needs to be some rules here. >> Some may be regulatory some may be technical. >>=20 >> First the voice application service providers need to provide the=20 >> terminating CUA, "an accurate and truthful" Caller-ID for the call=20 >> even if it is originated from a source that is not directly=20 >> 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=20 >> RESPORGS. >>=20 >> If the originating UA can prove/assert it is legally authorized to=20 >> use such an identity on behalf of a customer then that is step one. >> The presumption after that is there is some contractual obligation=20 >> between the service provider and the network about the use of such identities. >> The network can then "validate" such an assertion. >>=20 >> 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. =20 >>=20 >> 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=20 >> the called party and frankly 15 character ASCII is not enough. >> Consumers or businesses should be able to see more complete and=20 >> validated information about the session in order to make an better=20 >> 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. >>=20 >> All of the examples you cite are excellent examples where such=20 >> verbose calling party identification could be displayed. I certainly = >> want to answer a call from my doctor on my test results just as I=20 >> wish to ignore a call from Bill Clinton begging me to vote in the=20 >> Virginia Governors election next Tuesday. This is a case where=20 >> annominity is not a > good idea. >>=20 >>=20 >> All you need now is a little standardization. >> Technically this should is very easy to understand in SIP. It would=20 >> probably a reasonable modification of the Call INFO header in SIP=20 >> with something like a XML based VCARD or JCARD URI whatever and=20 >> 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. >>=20 >>=20 >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >> Of Dan York >> Sent: Tuesday, October 29, 2013 5:10 PM >> To: Brian Rosen; Cullen Jennings >> Cc: Gregory.Schumacher@sprint.com; Richard Shockey; stir@ietf.org;=20 >> Fernando Mousinho (fmousinh); Alex Bobotek; Michael Hammer; Henning=20 >> Schulzrinne >> Subject: [stir] Application servers - Re: Call Center Implications >>=20 >> 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=20 >> that we're not only talking about "traditional" call centers but also = >> what I'll call "voice application service providers". They are=20 >> generally automated platforms running applications that a company=20 >> uses for some kind of outbound service. Examples include: >>=20 >> - calling everyone in a school district with a weather-related=20 >> cancellation (or, unfortunately, a school shooting or similar event) >> - calling patients to provide reminders of appointments or=20 >> notifications of subscriptions available >> - calling customers to let them know that a package was delivered or=20 >> 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=20 >> current issues >> - performing a call-back to provide an additional layer of=20 >> authentication for some service >>=20 >> There is a large (and growing) market for these kind of automated=20 >> tools and services and the distinction between these calls and=20 >> "robocalls" is really only one of intent and the fact that the=20 >> recipient > has "opted in" >> through some kind of system. >>=20 >> Generally, though, many of the companies want the application to=20 >> 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=20 >> from one of their own phone numbers. >>=20 >> You could think of these in the same way as "call centers", but I=20 >> point this out because some of these new services are very automated=20 >> and there are always new startups now emerging in this space. Some=20 >> of them are very "self-service" where the customer does it all while=20 >> others have teams of people involved. Some of the companies involved = >> include Nuance, Microsoft Tellme, Voxeo (now Aspect, and also my=20 >> former employer), Tropo, Twilio, Convergys and many more[1]. >>=20 >> If STIR is to succeed, these kind of application platforms will also=20 >> need to be able to make calls on behalf of the companies using those > platforms. >>=20 >> Dan >>=20 >> [1] One report about this market: >> http://www.voxeo.com/pdf/OvumDecisionMatrix-2011.pdf >>=20 >>=20 >> -- >> Dan York >> Senior Content Strategist, Internet Society >> york@isoc.org +1-802-735-1624 >> Jabber: york@jabber.isoc.org >> Skype: danyork http://twitter.com/danyork >>=20 >> http://www.internetsociety.org/deploy360/ >>=20 >>=20 >>=20 >>=20 >> On 10/21/13 9:15 AM, "Brian Rosen" wrote: >>=20 >>> We really need to give each BPO different keys I think. The notion that >>> we are sharing private keys among multiple competing entities who=20 >>> provide services for a single enterprise strikes me as a VBI (Very=20 >>> Bad Idea). I can't see any real difficulty in having more than one=20 >>> 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=20 >>> more of it's >> BPOs. >>>=20 >>> Brian >>>=20 >>> On Oct 20, 2013, at 1:12 AM, Cullen Jennings (fluffy)=20 >>> >>> wrote: >>>=20 >>>>=20 >>>> What Fernando is saying makes sense to me a desirable property of=20 >>>> the solution and I agree that if we gave each BPO a different=20 >>>> private key that would solve it but that might be pretty hard to=20 >>>> mange in other ways. I like the requirements but the solution is=20 >>>> not 100% obvious to me. >>>>=20 >>>>=20 >>>> On Oct 2, 2013, at 10:27 AM, Brian Rosen wrote: >>>>=20 >>>>> Sure. >>>>>=20 >>>>> Each BPO would have a different private/public key pair. >>>>>=20 >>>>> So you can trace which one placed the call. >>>>>=20 >>>>> Brian >>>>>=20 >>>>> On Oct 2, 2013, at 12:59 PM, Fernando Mousinho (fmousinh)=20 >>>>> wrote: >>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> If the company hires several BPOs and authorizes all of them to=20 >>>>>> sign calls on its behalf, is there a way to trace back the=20 >>>>>> originator (specific >>>>>> BPO) >>>>>> later on? I suppose that at some level the actual caller must be=20 >>>>>> exposed (perhaps to trace malicious activity, such as malicious=20 >>>>>> person infiltrated in an otherwise legitimate BPO). >>>>>>=20 >>>>>> 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=20 >>>>>> identity). >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 9/19/13 9:43 PM, "Brian Rosen" wrote: >>>>>>=20 >>>>>>> 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=20 >>>>>>> change to use From (if signed maybe). It also doesn't fit the=20 >>>>>>> definition of PAI. >>>>>>>=20 >>>>>>> Brian >>>>>>>=20 >>>>>>> On Sep 19, 2013, at 9:14 PM, Fernando Mousinho (fmousinh)=20 >>>>>>> wrote: >>>>>>>=20 >>>>>>>> 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=20 >>>>>>>> on the delegation process Rosen mentions. >>>>>>>> PAI's use is widespread, and it's main limitation is being=20 >>>>>>>> spoofable - but this is exactly the problem we are trying to=20 >>>>>>>> solve anyway. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> On Sep 19, 2013, at 5:39 PM, "Richard Shockey"=20 >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>> Excellent point a profile or BCP to complement the work. >>>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On=20 >>>>>>>>> Behalf Of Alex Bobotek >>>>>>>>> Sent: Thursday, September 19, 2013 5:27 PM >>>>>>>>> To: Henning Schulzrinne; Michael Hammer; fmousinh@cisco.com;=20 >>>>>>>>> Gregory.Schumacher@sprint.com; br@brianrosen.net >>>>>>>>> Cc: stir@ietf.org >>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>=20 >>>>>>>>> +1 >>>>>>>>> I've assumed that we are headed towards a "sign whatever=20 >>>>>>>>> extras you wish, and indicate what your signature covers" mechanism. >>>>>>>>>=20 >>>>>>>>> Based on this, standards would need to identify only a minimal = >>>>>>>>> subset of what shall/should be signed, and ensure that any=20 >>>>>>>>> required group of signed items survives transit intact. >>>>>>>>>=20 >>>>>>>>> Best signing practices may be needed to complement the=20 >>>>>>>>> standard, and an appropriate place for all but the most basic = >>>>>>>>> 'what to sign' >>>>>>>>> recommendations. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Regards, >>>>>>>>>=20 >>>>>>>>> Alex >>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On = >>>>>>>>>> Behalf Of Henning Schulzrinne >>>>>>>>>> Sent: Thursday, September 19, 2013 2:24 PM >>>>>>>>>> To: Michael Hammer; fmousinh@cisco.com;=20 >>>>>>>>>> Gregory.Schumacher@sprint.com; br@brianrosen.net >>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>=20 >>>>>>>>>> I see no reason not to allow signing any number-related field = >>>>>>>>>> in the SIP request. (Signing may well be done by different >>>>>>>>>> parties.) >>>>>>>>>>=20 >>>>>>>>>> As far as I know, callback numbers (SIP Reply-To) aren't=20 >>>>>>>>>> conveyable in legacy systems, however, so this may be of=20 >>>>>>>>>> somewhat limited use for a >>>>>>>>> while. >>>>>>>>>>=20 >>>>>>>>>> ________________________________________ >>>>>>>>>> From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf = >>>>>>>>>> of Michael Hammer [michael.hammer@yaanatech.com] >>>>>>>>>> Sent: Thursday, September 19, 2013 4:34 PM >>>>>>>>>> To: fmousinh@cisco.com; Gregory.Schumacher@sprint.com;=20 >>>>>>>>>> br@brianrosen.net >>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>=20 >>>>>>>>>> Don't we still want to know the true originator of the call,=20 >>>>>>>>>> even when we have some token that says "Doctor so and so=20 >>>>>>>>>> approved this message." >>>>>>>>>>=20 >>>>>>>>>> Originating number, display number, and call-back number=20 >>>>>>>>>> could be >>>>>>>>>> 3 >>>>>>>>>> different things. >>>>>>>>>> Should all of them be verifiable? >>>>>>>>>>=20 >>>>>>>>>> Mike >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On = >>>>>>>>>> Behalf Of Fernando Mousinho (fmousinh) >>>>>>>>>> Sent: Thursday, September 19, 2013 4:00 PM >>>>>>>>>> To: Schumacher, Gregory [CTO]; Brian Rosen >>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>=20 >>>>>>>>>> I believe the scenario telemarketing here is when a client=20 >>>>>>>>>> hires a BPO to place outbound calls, but expect customers=20 >>>>>>>>>> to return these calls to a different place (say, their own=20 >>>>>>>>>> and operated call center). This way, this client is=20 >>>>>>>>>> authorizing the BPO to use an identity that it >>>>>>>>>> (BPO) >>>>>>>>> doesn't own. >>>>>>>>>> These numbers in this scenario are always operational, just=20 >>>>>>>>>> at a different place. >>>>>>>>>>=20 >>>>>>>>>> The same telemarketing operator would then outpulse multiple=20 >>>>>>>>>> numbers for their multiple clients, none of these numbers=20 >>>>>>>>>> belonging to the >>>>>>>>> telemarketer. >>>>>>>>>> BTW, we are using the term "telemarketing" in a very generic=20 >>>>>>>>>> sense - this could just as easily be a public service=20 >>>>>>>>>> announcement, fundraiser, >>>>>>>>> etc. >>>>>>>>>>=20 >>>>>>>>>> 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. >>>>>>>>>>=20 >>>>>>>>>> On a different note, it would help a lot of we standardized=20 >>>>>>>>>> terminology. >>>>>>>>>> Telemarketing, BPO, call center, end customer, clients=A9 it=20 >>>>>>>>>> may be hard for others to follow the discussion later. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> (generic term for any type of outbound calling, including=20 >>>>>>>>>> public service announcement, so don't think it's all about >>>>>>>>>> sales!) >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On 9/19/13 3:22 PM, "Schumacher, Gregory [CTO]" >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>> There are some benefits from this approach, but also some=20 >>>>>>>>>>> scenarios that need clarification how they could function. >>>>>>>>>>>=20 >>>>>>>>>>> The benefit is that the credential represents both the=20 >>>>>>>>>>> company "responsible" for the sales campaign (the "company" >>>>>>>>>>> in your >>>>>>>>>>> scenario) >>>>>>>>>>> and the company operating the sales campaign (the call=20 >>>>>>>>>>> center in your scenario). For the use in forensics (after = >>>>>>>>>>> the fact >>>>>>>>>>> analysis) such as pursuit of fraud investigation, we then=20 >>>>>>>>>>> can follow both paths. >>>>>>>>>>>=20 >>>>>>>>>>> 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=20 >>>>>>>>>>> telemarketing campaign or both? >>>>>>>>>>>=20 >>>>>>>>>>> - How is the SP supposed to know all the parties that it is=20 >>>>>>>>>>> attesting to >>>>>>>>>>> - the responsible party and/or executing party? >>>>>>>>>>>=20 >>>>>>>>>>> -It seems likely that some of the numbers assigned to a=20 >>>>>>>>>>> company in your scenario will not be assigned to real=20 >>>>>>>>>>> telephones (or call center >>>>>>>>>>> trunk) until a telemarketing campaign is initiated or a call = >>>>>>>>>>> center selected to execute the sales campaign, is it=20 >>>>>>>>>>> possible to have these unassigned or floating numbers when=20 >>>>>>>>>>> not in use for a telemarketing campaign? Is it allowed=20 >>>>>>>>>>> under most national numbering regimes? >>>>>>>>>>>=20 >>>>>>>>>>> - How important is it to have a known or recognized phone=20 >>>>>>>>>>> number as the caller id as part of a telemarketing = campaign? >>>>>>>>>>> I am assuming that not all campaigns care about having a=20 >>>>>>>>>>> number that is known or >>>>>>>>> recognized. >>>>>>>>>>>=20 >>>>>>>>>>> -In other words for this last bit, if a call center=20 >>>>>>>>>>> (telemarketing campaign operator) is using their own set of = >>>>>>>>>>> numbers but serve multiple simultaneous telemarketing=20 >>>>>>>>>>> campaigns using the same originating numbers, what will=20 >>>>>>>>>>> they sign? Will they just have a credential representing=20 >>>>>>>>>>> the call center alone, or a different credential per=20 >>>>>>>>>>> telemarketing campaign, or a different credential per=20 >>>>>>>>>>> responsible party (per client)? This will affect what is=20 >>>>>>>>>>> possible for >>>>>>>>> any forensic activity. >>>>>>>>>>>=20 >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org]=20 >>>>>>>>>>> On Behalf Of Brian Rosen >>>>>>>>>>> Sent: Tuesday, September 17, 2013 9:44 AM >>>>>>>>>>> To: Fernando Mousinho >>>>>>>>>>> Cc: stir@ietf.org; Hadriel Kaplan >>>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>>=20 >>>>>>>>>>> We have a requirement to support the BPO use case. >>>>>>>>>>>=20 >>>>>>>>>>> The notion we had is that the company contracting the call=20 >>>>>>>>>>> center approves the use, and the call center, or the SP=20 >>>>>>>>>>> acting on its behalf, signs. >>>>>>>>>>> Think of this as another level of delegation. An SP=20 >>>>>>>>>>> delegates numbers to the company. The company "delegates" >>>>>>>>>>> use of those numbers to the call center. The call center=20 >>>>>>>>>>> calls, using that delegation. >>>>>>>>>>> The credentials of the call center would be different from=20 >>>>>>>>>>> those of the company, but would cover the same number. >>>>>>>>>>> Having multiple credentials covering the same number will=20 >>>>>>>>>>> be very common due to the way delegation happens. In order = >>>>>>>>>>> to allow SPs to sign, without creating credential per TN,=20 >>>>>>>>>>> we allow credentials with ranges. >>>>>>>>>>> The >>>>>>>>>>> ranges could overlap when delegation happens. >>>>>>>>>>>=20 >>>>>>>>>>> Consider the following complex US case: >>>>>>>>>>> The North American Number Plan Administrator delegates=20 >>>>>>>>>>> 202-555-xxxx to the Pooling Administrator. The PA now has=20 >>>>>>>>>>> a credential covering the entire 10K block. >>>>>>>>>>> The Pooling Administrator delegates 202-555-1xxx to SP A. =20 >>>>>>>>>>> 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=20 >>>>>>>>>>> 202-555-123x to Company C. Company C has a credential for=20 >>>>>>>>>>> a >>>>>>>>>>> 10 number block Company C authorizes 202-555-1234 to BPO D. = =20 >>>>>>>>>>> BPO D has credential for a 1 number block >>>>>>>>>>>=20 >>>>>>>>>>> NANPA and the PA never are in a call path, so they would=20 >>>>>>>>>>> never sign a call. >>>>>>>>>>>=20 >>>>>>>>>>> However, SP A or SP B could sign a call from either Company=20 >>>>>>>>>>> C or BPO D using the credential they have. >>>>>>>>>>>=20 >>>>>>>>>>> The SP for the call center could acquire credentials from=20 >>>>>>>>>>> the BPO and sign on its behalf. I suspect than many=20 >>>>>>>>>>> service providers would be reluctant to do so unless the=20 >>>>>>>>>>> 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=20 >>>>>>>>>>> probably has to do the signing itself. >>>>>>>>>>>=20 >>>>>>>>>>> Brian >>>>>>>>>>>=20 >>>>>>>>>>> On Sep 17, 2013, at 8:46 AM, Fernando Mousinho (fmousinh)=20 >>>>>>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> I agree, Hadriel. While large call centers (including BPOs, = >>>>>>>>>>>> which provide services for other companies) may have=20 >>>>>>>>>>>> special arrangements with SPs, the majority (small to >>>>>>>>>>>> mid-size) will probably rely on the SPs to do provide to=20 >>>>>>>>>>>> vouch for their identity. This would probably be the case=20 >>>>>>>>>>>> for the home analog caller anyway. This would imply that=20 >>>>>>>>>>>> the "originating" SP's willingness to provide this=20 >>>>>>>>>>>> signature is a critical success factor for the proposal's > adoption. >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> But back to the business process outsourcers (BPO) case -=20 >>>>>>>>>>>> where a call center is providing service on behalf of=20 >>>>>>>>>>>> multiple companies. I can see the value of them sending=20 >>>>>>>>>>>> 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=20 >>>>>>>>>>>> that SP >>>>>>>>>>>> 1 allowing one of its subscribers to send an outbound call=20 >>>>>>>>>>>> using a number registered to SP 2 could be a no-no. If=20 >>>>>>>>>>>> this hypothesis is correct, then we are back to the case=20 >>>>>>>>>>>> where the SP is signing all calls, >>>>>>>>>> even for BPOs. >>>>>>>>>>>>=20 >>>>>>>>>>>> Or maybe this is another problem we are trying to fix in=20 >>>>>>>>>>>> the working group, in which case we perhaps should state as = >>>>>>>>>>>> a goal or >>>>>>>>> benefit: >>>>>>>>>>>> "providing a reliable mechanism to let calls originated=20 >>>>>>>>>>>> from one >>>>>>>>>>>> SP1 to outpulse numbers that belong to another". >>>>>>>>>>>>=20 >>>>>>>>>>>> Fernando >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> On 9/16/13 12:12 PM, "Hadriel Kaplan" >>>>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Any of them could do it. My guess is service providers=20 >>>>>>>>>>>>> will do it for most call centers, although larger call=20 >>>>>>>>>>>>> centers might do it themselves... >>>>>>>>>>>>> especially ones which have trunks from multiple providers=20 >>>>>>>>>>>>> and can source calls using the same number(s) out through = >>>>>>>>>>>>> multiple providers on a call-by-call basis. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> -hadriel >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Sep 16, 2013, at 9:49 AM, Fernando Mousinho (fmousinh)=20 >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I'm catching up with the discussions in this working=20 >>>>>>>>>>>>>> group, and am trying to understand some architecture=20 >>>>>>>>>>>>>> implications in call centers (which is where my=20 >>>>>>>>>>>>>> background is). It seems that many of the problems we=20 >>>>>>>>>>>>>> are trying to fix are related to contact centers anyway, = >>>>>>>>>>>>>> so it is probably a good idea to have everyone in the=20 >>>>>>>>>>>>>> same >>>>>>>>>> page. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Forgive me if it is an obvious question, but which=20 >>>>>>>>>>>>>> components in a "typical call center architecture" do=20 >>>>>>>>>>>>>> you see signature and verification taking place? Such "typical" >>>>>>>>>>>>>> deployments have premises based equipment (PME), a=20 >>>>>>>>>>>>>> session border controller >>>>>>>>>>>>>> (SBC) >>>>>>>>>>>>>> and of course a SIP service provider all three could=20 >>>>>>>>>>>>>> potentially be used throughout the authorization = process. >>>>>>>>>>>>>> There are different ramifications depending on where=20 >>>>>>>>>>>>>> your mind is at. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Fernando Mousinho >>>>>>>>>>>>>> Cisco Systems >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> stir mailing list >>>>>>>>>>>> stir@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> stir mailing list >>>>>>>>>>> stir@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> ________________________________ >>>>>>>>>>>=20 >>>>>>>>>>> This e-mail may contain Sprint proprietary information=20 >>>>>>>>>>> intended for the sole use of the recipient(s). Any use by=20 >>>>>>>>>>> others is prohibited. >>>>>>>>>>> If >>>>>>>>>>> you are not the intended recipient, please contact the=20 >>>>>>>>>>> sender and delete all copies of the message. >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> stir mailing list >>>>>>>>>>> stir@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> stir mailing list >>>>>>>>>> stir@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>> _______________________________________________ >>>>>>>>>> stir mailing list >>>>>>>>>> stir@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>> _______________________________________________ >>>>>>>>> stir mailing list >>>>>>>>> stir@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> stir mailing list >>>>> stir@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/stir >>>>=20 >>>=20 >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> cnit mailing list >> cnit@ietf.org >> https://www.ietf.org/mailman/listinfo/cnit >=20 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From richard@shockey.us Thu Oct 31 15:13:44 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B53A311E81EB for ; Thu, 31 Oct 2013 15:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.003 X-Spam-Level: X-Spam-Status: No, score=-101.003 tagged_above=-999 required=5 tests=[AWL=-0.704, BAYES_00=-2.599, MANGLED_COMPNY=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJuL+m4mnX0a for ; Thu, 31 Oct 2013 15:13:40 -0700 (PDT) Received: from outbound-ss-2.hostmonster.com (outbound-ss-2.hostmonster.com [66.147.240.26]) by ietfa.amsl.com (Postfix) with SMTP id E7B3D11E824C for ; Thu, 31 Oct 2013 15:13:36 -0700 (PDT) Received: (qmail 8271 invoked by uid 0); 31 Oct 2013 21:47:58 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy14.mail.unifiedlayer.com with SMTP; 31 Oct 2013 21:47:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=pNyZkvm5qQIkN94/UaDI4YmAaA5WvFSAAS0lb+QatNw=; b=M/kPdSgGYadGhNLfhmlTiZpd972N1mtAsAtrG6YaVfWf86zeo5mYVFgkKlOvlfzyEtnZkpfzY1bGGe5aTuEfs2ZKu4L1HLuRhQjD9pIhNQ8YuTaUTnVSGshpf0GQA8S7; Received: from [173.79.179.104] (port=54442 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Vc05t-00060O-6x; Thu, 31 Oct 2013 15:47:57 -0600 From: "Richard Shockey" To: "'Brian Rosen'" , "'Gorman, Pierce A [NTK]'" References: <32C55AFE-FA17-4776-AD91-259AD3E226BE@brianrosen.net> <024001ced5a2$f3268810$d9739830$@shockey.us> <029501ced5b5$8fa9f480$aefddd80$@shockey.us> <2AA32171-1AE3-4AEE-AEDC-B2031562B7BD@brianrosen.net> <00d901ced637$9e8143a0$db83cae0$@shockey.us> <8B0027B8-D777-48F3-B5BF-B8F81F038E37@brianrosen.net> <61B8913D-852E-4B43-ABC1-95FEA7DDEF0D@brianrosen.net> In-Reply-To: <61B8913D-852E-4B43-ABC1-95FEA7DDEF0D@brianrosen.net> Date: Thu, 31 Oct 2013 17:47:56 -0400 Message-ID: <021601ced682$dcdb5fa0$96921ee0$@shockey.us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQLTdCvgrcMvmbDsv2xAt2r4G5TZbQLC46EgAqz016cBpe129QIWVK8PAdOJjcEBFampjAM/6Rz4AhpJpsGXeqEgAA== X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.79.179.104 authed with richard@shockey.us} Cc: cnit@ietf.org, "'Schumacher, Gregory \[CTO\]'" Subject: Re: [cnit] [stir] Application servers - Re: Call Center Implications X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 22:13:44 -0000 -----Original Message----- From: cnit-bounces@ietf.org [mailto:cnit-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Thursday, October 31, 2013 2:39 PM To: Gorman, Pierce A [NTK] Cc: cnit@ietf.org; Schumacher, Gregory [CTO]; Richard Shockey Subject: Re: [cnit] [stir] Application servers - Re: Call Center Implications We've evolved a very nice mechanism for passing data like xCards in SIP. You define the header (in this case, we already have the Call-Info = header, all we need is a purpose parameter value) that takes a URI. If you want = to pass by reference, the URI leads to the value using an HTTP GET. If you want to pass by value, you put the value in a body (requires = mime/multipart) and use a Content Indirect URL (RFC2392) pointing to the body. See = RFC6442 for an example of how this is done. Since we're using the mechanism to pass location for emergency calls, = the SBCs need to get used to allowing it :) [RS> ] Thank you for pointing that out. Something future NNI profiles should consider.=20 Brian On Oct 31, 2013, at 2:22 PM, Gorman, Pierce A [NTK] wrote: > I'm not sure I'd say the CNAM business model is broken if there are=20 > CNAM providers making a profit. :-) >=20 > To be a little more serious, there is value in using content=20 > indirection (which is the CNAM model). The verified calling ID=20 > (assuming STIR will be successful) would be a lightweight pointer to=20 > content a UA might like to present or see/hear. With respect to how=20 > to pass additional information in SIP (including content), IMHO it=20 > might be easier to add something like a 2nd message body with=20 > (verified?) XML or URI, et cetera, than to try to add new SIP headers=20 > or change handling for parts of existing headers such as the display=20 > name. (The B2BUAs in many softswitches simply discard display name.) >=20 > Best regards, >=20 >=20 > Pierce Gorman > Voice Architecture > Core Planning/Sprint > 913-439-4368 (Desk) >=20 >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: October 31, 2013 12:19 PM > To: Richard Shockey > Cc: cnit@ietf.org; DISPATCH > Subject: Re: [cnit] [stir] Application servers - Re: Call Center=20 > Implications >=20 > I think the issue is whether we think what is usually called "contact" information is reasonable to send on every call. >=20 > 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. >=20 > 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. >=20 > If we were to go farther, I'd probably want a request, rather than automatic sending. >=20 > I am very interested in working on improving caller name. >=20 > Brian >=20 > On Oct 31, 2013, at 8:49 AM, Richard Shockey = wrote: >=20 >>=20 >> Brian please.. Look at the mail. I'm using the CNIT list. >>=20 >> The issue is can we use the tools at hand to increase both the=20 >> accuracy, reliability and the amount of data that is delivered to the = >> CUA over who is attempting to establish a session. >>=20 >> The larger issue is the integrity of the entire real time=20 >> communications system as it moves to an all IP world. Irrespective=20 >> if CNAM it is delivered as part of From: or PAI its not very useful = to the consumer. >>=20 >> CNAM as it is currently defined in SS7 is a terrible service. 15=20 >> Character ASCII. No support for International character sets the = usual. >>=20 >> It is not a hard stretch to postulate that called parties might like=20 >> a richer set of data displayed on their UA's and that can be=20 >> delivered by the SIP headers in some relatively simple form.=20 >> Modification of the Call-Info header for instance. It is equally not=20 >> a stretch to think that National Regulators would be delighted with=20 >> consumers having a richer set of information displayed on their=20 >> handsets in order to make more decisions. In addition if we can=20 >> achieve better all IP to IP interconnection among providers it would=20 >> 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. >>=20 >> 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=20 >> display of calling party information. >>=20 >> In addition network operators could insert other 'hints' as to the=20 >> nature of the session based on its ability to validate the Caller ID=20 >> or other forms on analysis. >>=20 >> I'm well aware of how CNAM is delivered in North America and I'm=20 >> equally aware the CNAM business model is broken. >>=20 >> What I'd like to know is what interest there is in this proposition=20 >> and are there parties interested in working on it in advance of say London. >>=20 >> -----Original Message----- >> From: Brian Rosen [mailto:br@brianrosen.net] >> Sent: Wednesday, October 30, 2013 5:39 PM >> To: Richard Shockey >> Cc: cnit@ietf.org >> Subject: Re: [cnit] [stir] Application servers - Re: Call Center=20 >> Implications >>=20 >> More useful in what way? Improving the reliability of caller name? >> Please use the cnit list to discuss this. >>=20 >> On that list, the current direction seems to be using the display=20 >> 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. >>=20 >> That is a significant change to the current infrastructure, which at=20 >> least in North America relies on a termination service provider dip=20 >> in an origination service provider database, but it seems feasible to = >> consider that. >>=20 >> Brian >>=20 >> On Oct 30, 2013, at 5:18 PM, Richard Shockey = wrote: >>=20 >>>=20 >>> Ok since Brian is being picky.. >>>=20 >>> I'm actually interested if anyone is interested in the possibility=20 >>> of making SIP Identity to the UA more useful. >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = >>> Of Richard Shockey >>> Sent: Wednesday, October 30, 2013 3:05 PM >>> To: stir@ietf.org >>> Subject: Re: [stir] Application servers - Re: Call Center=20 >>> Implications >>>=20 >>> Dan great post. I couldn't agree more. There needs to be some rules here. >>> Some may be regulatory some may be technical. >>>=20 >>> First the voice application service providers need to provide the=20 >>> terminating CUA, "an accurate and truthful" Caller-ID for the call=20 >>> even if it is originated from a source that is not directly=20 >>> 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. >>>=20 >>> If the originating UA can prove/assert it is legally authorized to=20 >>> use such an identity on behalf of a customer then that is step one. >>> The presumption after that is there is some contractual obligation=20 >>> between the service provider and the network about the use of such identities. >>> The network can then "validate" such an assertion. >>>=20 >>> There is something larger here to consider. Though the focus of=20 >>> STIR is validation of a Caller-ID number at some point the RAI area=20 >>> should take >> a >>> look at the other side of the coin so to speak. >>>=20 >>> CNAM. That is NOT something STIR can do but I do believe there is=20 >>> an emerging requirement that under some cases the calling party=20 >>> wants to or should provide more substantive information about=20 >>> themselves to the called party and frankly 15 character ASCII is not enough. >>> Consumers or businesses should be able to see more complete and=20 >>> validated information about the session in order to make an better=20 >>> and informed decision on whether to accept the 'call' or not. >>> Regulators may want to require telemarketing firms to display NG=20 >>> CNAM or CNAM + like data as a condition of doing business. >>>=20 >>> All of the examples you cite are excellent examples where such=20 >>> verbose calling party identification could be displayed. I=20 >>> certainly want to answer a call from my doctor on my test results=20 >>> 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=20 >>> where annominity is not a >> good idea. >>>=20 >>>=20 >>> 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=20 >>> with something like a XML based VCARD or JCARD URI whatever and=20 >>> probably 3GPP would need to look at how such data is displayed on=20 >>> the mobile VoLTE handsets. The network operators would have to=20 >>> understand not to modify the contents of such a URI and its source=20 >>> validated but that is a task for another day. >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf = >>> Of Dan York >>> Sent: Tuesday, October 29, 2013 5:10 PM >>> To: Brian Rosen; Cullen Jennings >>> Cc: Gregory.Schumacher@sprint.com; Richard Shockey; stir@ietf.org;=20 >>> Fernando Mousinho (fmousinh); Alex Bobotek; Michael Hammer; Henning=20 >>> Schulzrinne >>> Subject: [stir] Application servers - Re: Call Center Implications >>>=20 >>> Getting caught up on some of the STIR discussions, I'd just note=20 >>> that when we talk about "call centers" or "BPOs" we also need to=20 >>> remember that we're not only talking about "traditional" call=20 >>> centers but also what I'll call "voice application service=20 >>> providers". They are generally automated platforms running=20 >>> applications that a company uses for some kind of outbound service. Examples include: >>>=20 >>> - calling everyone in a school district with a weather-related=20 >>> cancellation (or, unfortunately, a school shooting or similar event) >>> - calling patients to provide reminders of appointments or=20 >>> 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=20 >>> to be delayed >>> - calling members of an organization with an automated survey about=20 >>> current issues >>> - performing a call-back to provide an additional layer of=20 >>> authentication for some service >>>=20 >>> There is a large (and growing) market for these kind of automated=20 >>> tools and services and the distinction between these calls and=20 >>> "robocalls" is really only one of intent and the fact that the=20 >>> recipient >> has "opted in" >>> through some kind of system. >>>=20 >>> Generally, though, many of the companies want the application to=20 >>> appear as if it is coming from their own phone number in the same=20 >>> way that they want an outbound call center to appear as if it is=20 >>> coming from one of their own phone numbers. >>>=20 >>> You could think of these in the same way as "call centers", but I=20 >>> point this out because some of these new services are very automated = >>> and there are always new startups now emerging in this space. Some=20 >>> of them are very "self-service" where the customer does it all while = >>> others have teams of people involved. Some of the companies=20 >>> involved include Nuance, Microsoft Tellme, Voxeo (now Aspect, and=20 >>> also my former employer), Tropo, Twilio, Convergys and many more[1]. >>>=20 >>> 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. >>>=20 >>> Dan >>>=20 >>> [1] One report about this market: >>> http://www.voxeo.com/pdf/OvumDecisionMatrix-2011.pdf >>>=20 >>>=20 >>> -- >>> Dan York >>> Senior Content Strategist, Internet Society >>> york@isoc.org +1-802-735-1624 >>> Jabber: york@jabber.isoc.org >>> Skype: danyork http://twitter.com/danyork >>>=20 >>> http://www.internetsociety.org/deploy360/ >>>=20 >>>=20 >>>=20 >>>=20 >>> On 10/21/13 9:15 AM, "Brian Rosen" wrote: >>>=20 >>>> We really need to give each BPO different keys I think. The = notion that >>>> we are sharing private keys among multiple competing entities who=20 >>>> provide services for a single enterprise strikes me as a VBI (Very=20 >>>> 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=20 >>>> a problem? We're already agreeing that there are multiple=20 >>>> credentials for a number, because the number gets delegated = multiple times. >>>> Consider, just as an example, the BPO and the contracting=20 >>>> enterprise that was actually delegated the number can both send=20 >>>> calls from that number. You certainly don't want the enterprise=20 >>>> giving out IT'S key to it's contractors. At best it's a key it=20 >>>> authorizes to one or more of it's >>> BPOs. >>>>=20 >>>> Brian >>>>=20 >>>> On Oct 20, 2013, at 1:12 AM, Cullen Jennings (fluffy)=20 >>>> >>>> wrote: >>>>=20 >>>>>=20 >>>>> What Fernando is saying makes sense to me a desirable property of=20 >>>>> the solution and I agree that if we gave each BPO a different=20 >>>>> private key that would solve it but that might be pretty hard to=20 >>>>> mange in other ways. I like the requirements but the solution is=20 >>>>> not 100% obvious to me. >>>>>=20 >>>>>=20 >>>>> On Oct 2, 2013, at 10:27 AM, Brian Rosen = wrote: >>>>>=20 >>>>>> Sure. >>>>>>=20 >>>>>> Each BPO would have a different private/public key pair. >>>>>>=20 >>>>>> So you can trace which one placed the call. >>>>>>=20 >>>>>> Brian >>>>>>=20 >>>>>> On Oct 2, 2013, at 12:59 PM, Fernando Mousinho (fmousinh)=20 >>>>>> wrote: >>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> If the company hires several BPOs and authorizes all of them to=20 >>>>>>> sign calls on its behalf, is there a way to trace back the=20 >>>>>>> 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). >>>>>>>=20 >>>>>>> Via headers would be the obvious pick, but they don't survive=20 >>>>>>> the plethora of SBCs that the call is likely to transverse. Or=20 >>>>>>> maybe the certs themselves can carry this type of data (actual=20 >>>>>>> caller identity). >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On 9/19/13 9:43 PM, "Brian Rosen" wrote: >>>>>>>=20 >>>>>>>> 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=20 >>>>>>>> change to use From (if signed maybe). It also doesn't fit the = >>>>>>>> definition of PAI. >>>>>>>>=20 >>>>>>>> Brian >>>>>>>>=20 >>>>>>>> On Sep 19, 2013, at 9:14 PM, Fernando Mousinho (fmousinh)=20 >>>>>>>> wrote: >>>>>>>>=20 >>>>>>>>> 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=20 >>>>>>>>> on the delegation process Rosen mentions. >>>>>>>>> PAI's use is widespread, and it's main limitation is being=20 >>>>>>>>> spoofable - but this is exactly the problem we are trying to=20 >>>>>>>>> solve anyway. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> On Sep 19, 2013, at 5:39 PM, "Richard Shockey" >>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>> Excellent point a profile or BCP to complement the work. >>>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On = >>>>>>>>>> Behalf Of Alex Bobotek >>>>>>>>>> Sent: Thursday, September 19, 2013 5:27 PM >>>>>>>>>> To: Henning Schulzrinne; Michael Hammer; fmousinh@cisco.com;=20 >>>>>>>>>> Gregory.Schumacher@sprint.com; br@brianrosen.net >>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>=20 >>>>>>>>>> +1 >>>>>>>>>> I've assumed that we are headed towards a "sign whatever=20 >>>>>>>>>> extras you wish, and indicate what your signature covers" mechanism. >>>>>>>>>>=20 >>>>>>>>>> Based on this, standards would need to identify only a=20 >>>>>>>>>> minimal subset of what shall/should be signed, and ensure=20 >>>>>>>>>> that any required group of signed items survives transit intact. >>>>>>>>>>=20 >>>>>>>>>> Best signing practices may be needed to complement the=20 >>>>>>>>>> standard, and an appropriate place for all but the most=20 >>>>>>>>>> basic 'what to sign' >>>>>>>>>> recommendations. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Regards, >>>>>>>>>>=20 >>>>>>>>>> Alex >>>>>>>>>>=20 >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org]=20 >>>>>>>>>>> On Behalf Of Henning Schulzrinne >>>>>>>>>>> Sent: Thursday, September 19, 2013 2:24 PM >>>>>>>>>>> To: Michael Hammer; fmousinh@cisco.com;=20 >>>>>>>>>>> Gregory.Schumacher@sprint.com; br@brianrosen.net >>>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>>=20 >>>>>>>>>>> I see no reason not to allow signing any number-related=20 >>>>>>>>>>> field in the SIP request. (Signing may well be done by=20 >>>>>>>>>>> different >>>>>>>>>>> parties.) >>>>>>>>>>>=20 >>>>>>>>>>> As far as I know, callback numbers (SIP Reply-To) aren't=20 >>>>>>>>>>> conveyable in legacy systems, however, so this may be of=20 >>>>>>>>>>> somewhat limited use for a >>>>>>>>>> while. >>>>>>>>>>>=20 >>>>>>>>>>> ________________________________________ >>>>>>>>>>> From: stir-bounces@ietf.org [stir-bounces@ietf.org] on=20 >>>>>>>>>>> behalf of Michael Hammer [michael.hammer@yaanatech.com] >>>>>>>>>>> Sent: Thursday, September 19, 2013 4:34 PM >>>>>>>>>>> To: fmousinh@cisco.com; Gregory.Schumacher@sprint.com;=20 >>>>>>>>>>> br@brianrosen.net >>>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>>=20 >>>>>>>>>>> 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=20 >>>>>>>>>>> approved this message." >>>>>>>>>>>=20 >>>>>>>>>>> Originating number, display number, and call-back number=20 >>>>>>>>>>> could be >>>>>>>>>>> 3 >>>>>>>>>>> different things. >>>>>>>>>>> Should all of them be verifiable? >>>>>>>>>>>=20 >>>>>>>>>>> Mike >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org]=20 >>>>>>>>>>> On Behalf Of Fernando Mousinho (fmousinh) >>>>>>>>>>> Sent: Thursday, September 19, 2013 4:00 PM >>>>>>>>>>> To: Schumacher, Gregory [CTO]; Brian Rosen >>>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>>=20 >>>>>>>>>>> I believe the scenario telemarketing here is when a client=20 >>>>>>>>>>> hires a BPO to place outbound calls, but expect customers=20 >>>>>>>>>>> to return these calls to a different place (say, their own = >>>>>>>>>>> and operated call center). This way, this client is=20 >>>>>>>>>>> authorizing the BPO to use an identity that it >>>>>>>>>>> (BPO) >>>>>>>>>> doesn't own. >>>>>>>>>>> These numbers in this scenario are always operational, just=20 >>>>>>>>>>> at a different place. >>>>>>>>>>>=20 >>>>>>>>>>> The same telemarketing operator would then outpulse multiple = >>>>>>>>>>> numbers for their multiple clients, none of these numbers=20 >>>>>>>>>>> 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=20 >>>>>>>>>>> announcement, fundraiser, >>>>>>>>>> etc. >>>>>>>>>>>=20 >>>>>>>>>>> If the telemarketer happens to own the inbound call center=20 >>>>>>>>>>> as well, it very likely owns the number as well and this=20 >>>>>>>>>>> would necessarily be a special case >>>>>>>>>>> - it would fall under the same characteristics of any call center. >>>>>>>>>>>=20 >>>>>>>>>>> On a different note, it would help a lot of we standardized=20 >>>>>>>>>>> terminology. >>>>>>>>>>> Telemarketing, BPO, call center, end customer, clients=A9 it = >>>>>>>>>>> may be hard for others to follow the discussion later. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> (generic term for any type of outbound calling, including=20 >>>>>>>>>>> public service announcement, so don't think it's all about >>>>>>>>>>> sales!) >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> On 9/19/13 3:22 PM, "Schumacher, Gregory [CTO]" >>>>>>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> There are some benefits from this approach, but also some=20 >>>>>>>>>>>> scenarios that need clarification how they could function. >>>>>>>>>>>>=20 >>>>>>>>>>>> The benefit is that the credential represents both the=20 >>>>>>>>>>>> company "responsible" for the sales campaign (the "company" >>>>>>>>>>>> in your >>>>>>>>>>>> scenario) >>>>>>>>>>>> and the company operating the sales campaign (the call=20 >>>>>>>>>>>> center in your scenario). For the use in forensics=20 >>>>>>>>>>>> (after the fact >>>>>>>>>>>> analysis) such as pursuit of fraud investigation, we then=20 >>>>>>>>>>>> can follow both paths. >>>>>>>>>>>>=20 >>>>>>>>>>>> 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? >>>>>>>>>>>>=20 >>>>>>>>>>>> - How is the SP supposed to know all the parties that it is = >>>>>>>>>>>> attesting to >>>>>>>>>>>> - the responsible party and/or executing party? >>>>>>>>>>>>=20 >>>>>>>>>>>> -It seems likely that some of the numbers assigned to a=20 >>>>>>>>>>>> company in your scenario will not be assigned to real=20 >>>>>>>>>>>> telephones (or call center >>>>>>>>>>>> trunk) until a telemarketing campaign is initiated or a=20 >>>>>>>>>>>> call center selected to execute the sales campaign, is it=20 >>>>>>>>>>>> possible to have these unassigned or floating numbers when = >>>>>>>>>>>> not in use for a telemarketing campaign? Is it allowed=20 >>>>>>>>>>>> under most national numbering regimes? >>>>>>>>>>>>=20 >>>>>>>>>>>> - How important is it to have a known or recognized phone=20 >>>>>>>>>>>> number as the caller id as part of a telemarketing = campaign? >>>>>>>>>>>> I am assuming that not all campaigns care about having a=20 >>>>>>>>>>>> number that is known or >>>>>>>>>> recognized. >>>>>>>>>>>>=20 >>>>>>>>>>>> -In other words for this last bit, if a call center=20 >>>>>>>>>>>> (telemarketing campaign operator) is using their own set=20 >>>>>>>>>>>> of numbers but serve multiple simultaneous telemarketing=20 >>>>>>>>>>>> campaigns using the same originating numbers, what will=20 >>>>>>>>>>>> they sign? Will they just have a credential representing=20 >>>>>>>>>>>> the call center alone, or a different credential per=20 >>>>>>>>>>>> telemarketing campaign, or a different credential per=20 >>>>>>>>>>>> responsible party (per client)? This will affect what is=20 >>>>>>>>>>>> possible for >>>>>>>>>> any forensic activity. >>>>>>>>>>>>=20 >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org]=20 >>>>>>>>>>>> On Behalf Of Brian Rosen >>>>>>>>>>>> Sent: Tuesday, September 17, 2013 9:44 AM >>>>>>>>>>>> To: Fernando Mousinho >>>>>>>>>>>> Cc: stir@ietf.org; Hadriel Kaplan >>>>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>>>=20 >>>>>>>>>>>> We have a requirement to support the BPO use case. >>>>>>>>>>>>=20 >>>>>>>>>>>> The notion we had is that the company contracting the call=20 >>>>>>>>>>>> center approves the use, and the call center, or the SP=20 >>>>>>>>>>>> acting on its behalf, signs. >>>>>>>>>>>> Think of this as another level of delegation. An SP=20 >>>>>>>>>>>> delegates numbers to the company. The company "delegates" >>>>>>>>>>>> use of those numbers to the call center. The call center=20 >>>>>>>>>>>> calls, using that delegation. >>>>>>>>>>>> The credentials of the call center would be different from=20 >>>>>>>>>>>> those of the company, but would cover the same number. >>>>>>>>>>>> Having multiple credentials covering the same number will=20 >>>>>>>>>>>> be very common due to the way delegation happens. In=20 >>>>>>>>>>>> order to allow SPs to sign, without creating credential=20 >>>>>>>>>>>> per TN, we allow credentials with ranges. >>>>>>>>>>>> The >>>>>>>>>>>> ranges could overlap when delegation happens. >>>>>>>>>>>>=20 >>>>>>>>>>>> Consider the following complex US case: >>>>>>>>>>>> The North American Number Plan Administrator delegates=20 >>>>>>>>>>>> 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=20 >>>>>>>>>>>> resells 202-555-12xx to SP B . >>>>>>>>>>>> SP B has a credential for a 100 TN block SP B delegates=20 >>>>>>>>>>>> 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 >>>>>>>>>>>>=20 >>>>>>>>>>>> NANPA and the PA never are in a call path, so they would=20 >>>>>>>>>>>> never sign a call. >>>>>>>>>>>>=20 >>>>>>>>>>>> However, SP A or SP B could sign a call from either Company = >>>>>>>>>>>> C or BPO D using the credential they have. >>>>>>>>>>>>=20 >>>>>>>>>>>> The SP for the call center could acquire credentials from=20 >>>>>>>>>>>> the BPO and sign on its behalf. I suspect than many=20 >>>>>>>>>>>> service providers would be reluctant to do so unless the=20 >>>>>>>>>>>> numbers were from their own inventory (that is, the=20 >>>>>>>>>>>> company got its numbers from the same SP as the call >>>>>>>>>> center). >>>>>>>>>>>> Since that won't be the common case, the call center=20 >>>>>>>>>>>> probably has to do the signing itself. >>>>>>>>>>>>=20 >>>>>>>>>>>> Brian >>>>>>>>>>>>=20 >>>>>>>>>>>> On Sep 17, 2013, at 8:46 AM, Fernando Mousinho (fmousinh)=20 >>>>>>>>>>>> wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>> I agree, Hadriel. While large call centers (including=20 >>>>>>>>>>>>> BPOs, which provide services for other companies) may=20 >>>>>>>>>>>>> have special arrangements with SPs, the majority (small=20 >>>>>>>>>>>>> to >>>>>>>>>>>>> mid-size) will probably rely on the SPs to do provide to=20 >>>>>>>>>>>>> vouch for their identity. This would probably be the case = >>>>>>>>>>>>> for the home analog caller anyway. This would imply that=20 >>>>>>>>>>>>> the "originating" SP's willingness to provide this=20 >>>>>>>>>>>>> signature is a critical success factor for the proposal's >> adoption. >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> But back to the business process outsourcers (BPO) case -=20 >>>>>>>>>>>>> where a call center is providing service on behalf of=20 >>>>>>>>>>>>> multiple companies. I can see the value of them sending=20 >>>>>>>>>>>>> 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=20 >>>>>>>>>>>>> this hypothesis is correct, then we are back to the case=20 >>>>>>>>>>>>> where the SP is signing all calls, >>>>>>>>>>> even for BPOs. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Or maybe this is another problem we are trying to fix in=20 >>>>>>>>>>>>> the working group, in which case we perhaps should state=20 >>>>>>>>>>>>> as a goal or >>>>>>>>>> benefit: >>>>>>>>>>>>> "providing a reliable mechanism to let calls originated=20 >>>>>>>>>>>>> from one >>>>>>>>>>>>> SP1 to outpulse numbers that belong to another". >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Fernando >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On 9/16/13 12:12 PM, "Hadriel Kaplan" >>>>>>>>>>>>> >>>>>>>>>>> wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Any of them could do it. My guess is service providers=20 >>>>>>>>>>>>>> will do it for most call centers, although larger call=20 >>>>>>>>>>>>>> centers might do it themselves... >>>>>>>>>>>>>> especially ones which have trunks from multiple providers = >>>>>>>>>>>>>> and can source calls using the same number(s) out=20 >>>>>>>>>>>>>> through multiple providers on a call-by-call basis. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> -hadriel >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On Sep 16, 2013, at 9:49 AM, Fernando Mousinho (fmousinh) = >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> I'm catching up with the discussions in this working=20 >>>>>>>>>>>>>>> group, and am trying to understand some architecture=20 >>>>>>>>>>>>>>> implications in call centers (which is where my=20 >>>>>>>>>>>>>>> background is). It seems that many of the problems we=20 >>>>>>>>>>>>>>> are trying to fix are related to contact centers =20 >>>>>>>>>>>>>>> anyway, so it is probably a good idea to have everyone=20 >>>>>>>>>>>>>>> in the same >>>>>>>>>>> page. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Forgive me if it is an obvious question, but which=20 >>>>>>>>>>>>>>> components in a "typical call center architecture" do=20 >>>>>>>>>>>>>>> you see signature and verification taking place? Such "typical" >>>>>>>>>>>>>>> deployments have premises based equipment (PME), a=20 >>>>>>>>>>>>>>> session border controller >>>>>>>>>>>>>>> (SBC) >>>>>>>>>>>>>>> and of course a SIP service provider all three could=20 >>>>>>>>>>>>>>> potentially be used throughout the authorization = process. >>>>>>>>>>>>>>> There are different ramifications depending on where=20 >>>>>>>>>>>>>>> your mind is at. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Fernando Mousinho >>>>>>>>>>>>>>> Cisco Systems >>>>>>>>>>>>>=20 >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> stir mailing list >>>>>>>>>>>>> stir@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> stir mailing list >>>>>>>>>>>> stir@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> ________________________________ >>>>>>>>>>>>=20 >>>>>>>>>>>> This e-mail may contain Sprint proprietary information=20 >>>>>>>>>>>> intended for the sole use of the recipient(s). Any use by=20 >>>>>>>>>>>> others is prohibited. >>>>>>>>>>>> If >>>>>>>>>>>> you are not the intended recipient, please contact the=20 >>>>>>>>>>>> sender and delete all copies of the message. >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> stir mailing list >>>>>>>>>>>> stir@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> stir mailing list >>>>>>>>>>> stir@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> stir mailing list >>>>>>>>>>> stir@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>> _______________________________________________ >>>>>>>>>> stir mailing list >>>>>>>>>> stir@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> stir mailing list >>>>>> stir@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> stir mailing list >>>> stir@ietf.org >>>> https://www.ietf.org/mailman/listinfo/stir >>>=20 >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >>>=20 >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >>>=20 >>> _______________________________________________ >>> cnit mailing list >>> cnit@ietf.org >>> https://www.ietf.org/mailman/listinfo/cnit >>=20 >=20 >=20 >=20 > ________________________________ >=20 > 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. >=20 _______________________________________________ cnit mailing list cnit@ietf.org https://www.ietf.org/mailman/listinfo/cnit From richard@shockey.us Thu Oct 31 15:20:31 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0891911E826C for ; Thu, 31 Oct 2013 15:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.635 X-Spam-Level: X-Spam-Status: No, score=-100.635 tagged_above=-999 required=5 tests=[AWL=-0.936, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, MANGLED_COMPNY=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kuaYX7SVWDLp for ; Thu, 31 Oct 2013 15:20:26 -0700 (PDT) Received: from oproxy4-pub.mail.unifiedlayer.com (oproxy4-pub.mail.unifiedlayer.com [74.220.216.66]) by ietfa.amsl.com (Postfix) with SMTP id E266B21F9F20 for ; Thu, 31 Oct 2013 15:20:23 -0700 (PDT) Received: (qmail 29965 invoked by uid 0); 31 Oct 2013 22:11:52 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy4.mail.unifiedlayer.com with SMTP; 31 Oct 2013 22:11:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=/eSwNJrJnUxo3RqnB7V+3o7MIAMYXB3p0xu6nkaula0=; b=Y/vha9jx9o81GbJroYDeJhqt+KB0siDREeXzOeVYAWaJP/IfhOXr/DVXBy2bcJvbAGC7eFCsn+snvfBrMmmY4Kd1HZGd/0s6WOrosXgWwfAPzqq0TYVAYeiG3SQYLGKQ; Received: from [173.79.179.104] (port=54594 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Vc0T2-0000i4-BM; Thu, 31 Oct 2013 16:11:52 -0600 From: "Richard Shockey" To: "'Michael Hammer'" , , References: <32C55AFE-FA17-4776-AD91-259AD3E226BE@brianrosen.net> <024001ced5a2$f3268810$d9739830$@shockey.us> <029501ced5b5$8fa9f480$aefddd80$@shockey.us> <2AA32171-1AE3-4AEE-AEDC-B2031562B7BD@brianrosen.net> <00d901ced637$9e8143a0$db83cae0$@shockey.us> <8B0027B8-D777-48F3-B5BF-B8F81F038E37@brianrosen.net> <00C069FD01E0324C9FFCADF539701DB3BBEF4DB6@sc9-ex2k10mb1.corp.yaanatech.com> <021401ced681$34ab2640$9e0172c0$@shockey.us> <00C069FD01E0324C9FFCADF539701DB3BBEF5224@sc9-ex2k10mb1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBEF5224@sc9-ex2k10mb1.corp.yaanatech.com> Date: Thu, 31 Oct 2013 18:11:51 -0400 Message-ID: <024001ced686$34437180$9cca5480$@shockey.us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQLTdCvgrcMvmbDsv2xAt2r4G5TZbQLC46EgAqz016cBpe129QIWVK8PAdOJjcEBFampjAIH39XjAZ4KSLwDad9ZjgE+6VwIl2MB81A= X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.79.179.104 authed with richard@shockey.us} Cc: cnit@ietf.org, dispatch@ietf.org Subject: Re: [cnit] [dispatch] [stir] Application servers - Re: Call Center Implications X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 22:20:31 -0000 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.=20 What can IMS do here does anyone know? =20 I would suspect that our friends at Google/Android and Apple etal are = also in favor of anything that could "Enhance the User Experience"=20 Not to mention Cable. You know you have that big 60 inch phone in your living room ... :-) =20 -----Original Message----- From: Michael Hammer [mailto:michael.hammer@yaanatech.com]=20 Sent: Thursday, October 31, 2013 5:45 PM To: richard@shockey.us; Henning.Schulzrinne@fcc.gov; br@brianrosen.net Cc: cnit@ietf.org; dispatch@ietf.org Subject: RE: [dispatch] [cnit] [stir] Application servers - Re: Call = Center Implications 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:richard@shockey.us]=20 Sent: Thursday, October 31, 2013 5:36 PM To: Michael Hammer; Henning.Schulzrinne@fcc.gov; br@brianrosen.net Cc: cnit@ietf.org; dispatch@ietf.org Subject: RE: [dispatch] [cnit] [stir] Application servers - Re: Call = Center Implications Could you explain what you mean here? I'm modestly confused. Options indicator for what .. what the other side is capable of? =20 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.=20 -----Original Message----- From: Michael Hammer [mailto:michael.hammer@yaanatech.com] Sent: Thursday, October 31, 2013 2:11 PM To: Henning.Schulzrinne@fcc.gov; br@brianrosen.net; richard@shockey.us Cc: cnit@ietf.org; dispatch@ietf.org Subject: RE: [dispatch] [cnit] [stir] Application servers - Re: Call = Center Implications 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: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Henning Schulzrinne Sent: Thursday, October 31, 2013 1:37 PM To: 'Brian Rosen'; Richard Shockey Cc: cnit@ietf.org; DISPATCH Subject: Re: [dispatch] [cnit] [stir] Application servers - Re: Call = Center Implications Call-info: ;purpose=3Dcard or purpose=3Dinfo 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: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Brian Rosen Sent: Thursday, October 31, 2013 1:19 PM To: Richard Shockey Cc: cnit@ietf.org; 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. I am very interested in working on improving caller name. Brian On Oct 31, 2013, at 8:49 AM, Richard Shockey wrote: >=20 > Brian please.. Look at the mail. I'm using the CNIT list. =20 >=20 > The issue is can we use the tools at hand to increase both the=20 > accuracy, reliability and the amount of data that is delivered to the=20 > CUA over who is attempting to establish a session. >=20 > The larger issue is the integrity of the entire real time=20 > 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=20 > the consumer. >=20 > CNAM as it is currently defined in SS7 is a terrible service. 15=20 > Character ASCII. No support for International character sets the = usual. >=20 > 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=20 > 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=20 > that National Regulators would be delighted with consumers having a=20 > 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=20 > interconnection among providers it would be really really useful if=20 > Enterprise systems could extract more data from their internal=20 > directory systems and pass that along in the new format for=20 > enterprise calling as well. >=20 > I would certainly argue that we are not going to see ubiquitous Point=20 > to Point video calling using WebRTC or SIP if there is not better=20 > display of calling party information. >=20 > In addition network operators could insert other 'hints' as to the=20 > nature of the session based on its ability to validate the Caller ID=20 > or other forms on analysis. >=20 > I'm well aware of how CNAM is delivered in North America and I'm=20 > equally aware the CNAM business model is broken. >=20 > What I'd like to know is what interest there is in this proposition=20 > and are there parties interested in working on it in advance of say London. >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, October 30, 2013 5:39 PM > To: Richard Shockey > Cc: cnit@ietf.org > Subject: Re: [cnit] [stir] Application servers - Re: Call Center=20 > Implications >=20 > More useful in what way? Improving the reliability of caller name? =20 > Please use the cnit list to discuss this. >=20 > 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=20 > the origination side, and signed as the number is. >=20 > That is a significant change to the current infrastructure, which at=20 > least in North America relies on a termination service provider dip in = > an origination service provider database, but it seems feasible to=20 > consider that. >=20 > Brian >=20 > On Oct 30, 2013, at 5:18 PM, Richard Shockey = wrote: >=20 >>=20 >> Ok since Brian is being picky.. >>=20 >> I'm actually interested if anyone is interested in the possibility of = >> making SIP Identity to the UA more useful. >>=20 >>=20 >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >> Of Richard Shockey >> Sent: Wednesday, October 30, 2013 3:05 PM >> To: stir@ietf.org >> Subject: Re: [stir] Application servers - Re: Call Center=20 >> Implications >>=20 >> Dan great post. I couldn't agree more. There needs to be some rules here. >> Some may be regulatory some may be technical. >>=20 >> First the voice application service providers need to provide the=20 >> terminating CUA, "an accurate and truthful" Caller-ID for the call=20 >> even if it is originated from a source that is not directly=20 >> 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=20 >> RESPORGS. >>=20 >> If the originating UA can prove/assert it is legally authorized to=20 >> use such an identity on behalf of a customer then that is step one. >> The presumption after that is there is some contractual obligation=20 >> between the service provider and the network about the use of such identities. >> The network can then "validate" such an assertion. >>=20 >> 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. =20 >>=20 >> 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=20 >> the called party and frankly 15 character ASCII is not enough. >> Consumers or businesses should be able to see more complete and=20 >> validated information about the session in order to make an better=20 >> 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. >>=20 >> All of the examples you cite are excellent examples where such=20 >> verbose calling party identification could be displayed. I certainly = >> want to answer a call from my doctor on my test results just as I=20 >> wish to ignore a call from Bill Clinton begging me to vote in the=20 >> Virginia Governors election next Tuesday. This is a case where=20 >> annominity is not a > good idea. >>=20 >>=20 >> All you need now is a little standardization. >> Technically this should is very easy to understand in SIP. It would=20 >> probably a reasonable modification of the Call INFO header in SIP=20 >> with something like a XML based VCARD or JCARD URI whatever and=20 >> 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. >>=20 >>=20 >>=20 >> -----Original Message----- >> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf=20 >> Of Dan York >> Sent: Tuesday, October 29, 2013 5:10 PM >> To: Brian Rosen; Cullen Jennings >> Cc: Gregory.Schumacher@sprint.com; Richard Shockey; stir@ietf.org;=20 >> Fernando Mousinho (fmousinh); Alex Bobotek; Michael Hammer; Henning=20 >> Schulzrinne >> Subject: [stir] Application servers - Re: Call Center Implications >>=20 >> 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=20 >> that we're not only talking about "traditional" call centers but also = >> what I'll call "voice application service providers". They are=20 >> generally automated platforms running applications that a company=20 >> uses for some kind of outbound service. Examples include: >>=20 >> - calling everyone in a school district with a weather-related=20 >> cancellation (or, unfortunately, a school shooting or similar event) >> - calling patients to provide reminders of appointments or=20 >> notifications of subscriptions available >> - calling customers to let them know that a package was delivered or=20 >> 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=20 >> current issues >> - performing a call-back to provide an additional layer of=20 >> authentication for some service >>=20 >> There is a large (and growing) market for these kind of automated=20 >> tools and services and the distinction between these calls and=20 >> "robocalls" is really only one of intent and the fact that the=20 >> recipient > has "opted in" >> through some kind of system. >>=20 >> Generally, though, many of the companies want the application to=20 >> 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=20 >> from one of their own phone numbers. >>=20 >> You could think of these in the same way as "call centers", but I=20 >> point this out because some of these new services are very automated=20 >> and there are always new startups now emerging in this space. Some=20 >> of them are very "self-service" where the customer does it all while=20 >> others have teams of people involved. Some of the companies involved = >> include Nuance, Microsoft Tellme, Voxeo (now Aspect, and also my=20 >> former employer), Tropo, Twilio, Convergys and many more[1]. >>=20 >> If STIR is to succeed, these kind of application platforms will also=20 >> need to be able to make calls on behalf of the companies using those > platforms. >>=20 >> Dan >>=20 >> [1] One report about this market: >> http://www.voxeo.com/pdf/OvumDecisionMatrix-2011.pdf >>=20 >>=20 >> -- >> Dan York >> Senior Content Strategist, Internet Society >> york@isoc.org +1-802-735-1624 >> Jabber: york@jabber.isoc.org >> Skype: danyork http://twitter.com/danyork >>=20 >> http://www.internetsociety.org/deploy360/ >>=20 >>=20 >>=20 >>=20 >> On 10/21/13 9:15 AM, "Brian Rosen" wrote: >>=20 >>> We really need to give each BPO different keys I think. The notion that >>> we are sharing private keys among multiple competing entities who=20 >>> provide services for a single enterprise strikes me as a VBI (Very=20 >>> Bad Idea). I can't see any real difficulty in having more than one=20 >>> 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=20 >>> more of it's >> BPOs. >>>=20 >>> Brian >>>=20 >>> On Oct 20, 2013, at 1:12 AM, Cullen Jennings (fluffy)=20 >>> >>> wrote: >>>=20 >>>>=20 >>>> What Fernando is saying makes sense to me a desirable property of=20 >>>> the solution and I agree that if we gave each BPO a different=20 >>>> private key that would solve it but that might be pretty hard to=20 >>>> mange in other ways. I like the requirements but the solution is=20 >>>> not 100% obvious to me. >>>>=20 >>>>=20 >>>> On Oct 2, 2013, at 10:27 AM, Brian Rosen wrote: >>>>=20 >>>>> Sure. >>>>>=20 >>>>> Each BPO would have a different private/public key pair. >>>>>=20 >>>>> So you can trace which one placed the call. >>>>>=20 >>>>> Brian >>>>>=20 >>>>> On Oct 2, 2013, at 12:59 PM, Fernando Mousinho (fmousinh)=20 >>>>> wrote: >>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> If the company hires several BPOs and authorizes all of them to=20 >>>>>> sign calls on its behalf, is there a way to trace back the=20 >>>>>> originator (specific >>>>>> BPO) >>>>>> later on? I suppose that at some level the actual caller must be=20 >>>>>> exposed (perhaps to trace malicious activity, such as malicious=20 >>>>>> person infiltrated in an otherwise legitimate BPO). >>>>>>=20 >>>>>> 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=20 >>>>>> identity). >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 9/19/13 9:43 PM, "Brian Rosen" wrote: >>>>>>=20 >>>>>>> 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=20 >>>>>>> change to use From (if signed maybe). It also doesn't fit the=20 >>>>>>> definition of PAI. >>>>>>>=20 >>>>>>> Brian >>>>>>>=20 >>>>>>> On Sep 19, 2013, at 9:14 PM, Fernando Mousinho (fmousinh)=20 >>>>>>> wrote: >>>>>>>=20 >>>>>>>> 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=20 >>>>>>>> on the delegation process Rosen mentions. >>>>>>>> PAI's use is widespread, and it's main limitation is being=20 >>>>>>>> spoofable - but this is exactly the problem we are trying to=20 >>>>>>>> solve anyway. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> On Sep 19, 2013, at 5:39 PM, "Richard Shockey"=20 >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>> Excellent point a profile or BCP to complement the work. >>>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On=20 >>>>>>>>> Behalf Of Alex Bobotek >>>>>>>>> Sent: Thursday, September 19, 2013 5:27 PM >>>>>>>>> To: Henning Schulzrinne; Michael Hammer; fmousinh@cisco.com;=20 >>>>>>>>> Gregory.Schumacher@sprint.com; br@brianrosen.net >>>>>>>>> Cc: stir@ietf.org >>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>=20 >>>>>>>>> +1 >>>>>>>>> I've assumed that we are headed towards a "sign whatever=20 >>>>>>>>> extras you wish, and indicate what your signature covers" mechanism. >>>>>>>>>=20 >>>>>>>>> Based on this, standards would need to identify only a minimal = >>>>>>>>> subset of what shall/should be signed, and ensure that any=20 >>>>>>>>> required group of signed items survives transit intact. >>>>>>>>>=20 >>>>>>>>> Best signing practices may be needed to complement the=20 >>>>>>>>> standard, and an appropriate place for all but the most basic = >>>>>>>>> 'what to sign' >>>>>>>>> recommendations. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Regards, >>>>>>>>>=20 >>>>>>>>> Alex >>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On = >>>>>>>>>> Behalf Of Henning Schulzrinne >>>>>>>>>> Sent: Thursday, September 19, 2013 2:24 PM >>>>>>>>>> To: Michael Hammer; fmousinh@cisco.com;=20 >>>>>>>>>> Gregory.Schumacher@sprint.com; br@brianrosen.net >>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>=20 >>>>>>>>>> I see no reason not to allow signing any number-related field = >>>>>>>>>> in the SIP request. (Signing may well be done by different >>>>>>>>>> parties.) >>>>>>>>>>=20 >>>>>>>>>> As far as I know, callback numbers (SIP Reply-To) aren't=20 >>>>>>>>>> conveyable in legacy systems, however, so this may be of=20 >>>>>>>>>> somewhat limited use for a >>>>>>>>> while. >>>>>>>>>>=20 >>>>>>>>>> ________________________________________ >>>>>>>>>> From: stir-bounces@ietf.org [stir-bounces@ietf.org] on behalf = >>>>>>>>>> of Michael Hammer [michael.hammer@yaanatech.com] >>>>>>>>>> Sent: Thursday, September 19, 2013 4:34 PM >>>>>>>>>> To: fmousinh@cisco.com; Gregory.Schumacher@sprint.com;=20 >>>>>>>>>> br@brianrosen.net >>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>=20 >>>>>>>>>> Don't we still want to know the true originator of the call,=20 >>>>>>>>>> even when we have some token that says "Doctor so and so=20 >>>>>>>>>> approved this message." >>>>>>>>>>=20 >>>>>>>>>> Originating number, display number, and call-back number=20 >>>>>>>>>> could be >>>>>>>>>> 3 >>>>>>>>>> different things. >>>>>>>>>> Should all of them be verifiable? >>>>>>>>>>=20 >>>>>>>>>> Mike >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On = >>>>>>>>>> Behalf Of Fernando Mousinho (fmousinh) >>>>>>>>>> Sent: Thursday, September 19, 2013 4:00 PM >>>>>>>>>> To: Schumacher, Gregory [CTO]; Brian Rosen >>>>>>>>>> Cc: stir@ietf.org >>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>=20 >>>>>>>>>> I believe the scenario telemarketing here is when a client=20 >>>>>>>>>> hires a BPO to place outbound calls, but expect customers=20 >>>>>>>>>> to return these calls to a different place (say, their own=20 >>>>>>>>>> and operated call center). This way, this client is=20 >>>>>>>>>> authorizing the BPO to use an identity that it >>>>>>>>>> (BPO) >>>>>>>>> doesn't own. >>>>>>>>>> These numbers in this scenario are always operational, just=20 >>>>>>>>>> at a different place. >>>>>>>>>>=20 >>>>>>>>>> The same telemarketing operator would then outpulse multiple=20 >>>>>>>>>> numbers for their multiple clients, none of these numbers=20 >>>>>>>>>> belonging to the >>>>>>>>> telemarketer. >>>>>>>>>> BTW, we are using the term "telemarketing" in a very generic=20 >>>>>>>>>> sense - this could just as easily be a public service=20 >>>>>>>>>> announcement, fundraiser, >>>>>>>>> etc. >>>>>>>>>>=20 >>>>>>>>>> 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. >>>>>>>>>>=20 >>>>>>>>>> On a different note, it would help a lot of we standardized=20 >>>>>>>>>> terminology. >>>>>>>>>> Telemarketing, BPO, call center, end customer, clients=A9 it=20 >>>>>>>>>> may be hard for others to follow the discussion later. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> (generic term for any type of outbound calling, including=20 >>>>>>>>>> public service announcement, so don't think it's all about >>>>>>>>>> sales!) >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On 9/19/13 3:22 PM, "Schumacher, Gregory [CTO]" >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>> There are some benefits from this approach, but also some=20 >>>>>>>>>>> scenarios that need clarification how they could function. >>>>>>>>>>>=20 >>>>>>>>>>> The benefit is that the credential represents both the=20 >>>>>>>>>>> company "responsible" for the sales campaign (the "company" >>>>>>>>>>> in your >>>>>>>>>>> scenario) >>>>>>>>>>> and the company operating the sales campaign (the call=20 >>>>>>>>>>> center in your scenario). For the use in forensics (after = >>>>>>>>>>> the fact >>>>>>>>>>> analysis) such as pursuit of fraud investigation, we then=20 >>>>>>>>>>> can follow both paths. >>>>>>>>>>>=20 >>>>>>>>>>> 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=20 >>>>>>>>>>> telemarketing campaign or both? >>>>>>>>>>>=20 >>>>>>>>>>> - How is the SP supposed to know all the parties that it is=20 >>>>>>>>>>> attesting to >>>>>>>>>>> - the responsible party and/or executing party? >>>>>>>>>>>=20 >>>>>>>>>>> -It seems likely that some of the numbers assigned to a=20 >>>>>>>>>>> company in your scenario will not be assigned to real=20 >>>>>>>>>>> telephones (or call center >>>>>>>>>>> trunk) until a telemarketing campaign is initiated or a call = >>>>>>>>>>> center selected to execute the sales campaign, is it=20 >>>>>>>>>>> possible to have these unassigned or floating numbers when=20 >>>>>>>>>>> not in use for a telemarketing campaign? Is it allowed=20 >>>>>>>>>>> under most national numbering regimes? >>>>>>>>>>>=20 >>>>>>>>>>> - How important is it to have a known or recognized phone=20 >>>>>>>>>>> number as the caller id as part of a telemarketing = campaign? >>>>>>>>>>> I am assuming that not all campaigns care about having a=20 >>>>>>>>>>> number that is known or >>>>>>>>> recognized. >>>>>>>>>>>=20 >>>>>>>>>>> -In other words for this last bit, if a call center=20 >>>>>>>>>>> (telemarketing campaign operator) is using their own set of = >>>>>>>>>>> numbers but serve multiple simultaneous telemarketing=20 >>>>>>>>>>> campaigns using the same originating numbers, what will=20 >>>>>>>>>>> they sign? Will they just have a credential representing=20 >>>>>>>>>>> the call center alone, or a different credential per=20 >>>>>>>>>>> telemarketing campaign, or a different credential per=20 >>>>>>>>>>> responsible party (per client)? This will affect what is=20 >>>>>>>>>>> possible for >>>>>>>>> any forensic activity. >>>>>>>>>>>=20 >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org]=20 >>>>>>>>>>> On Behalf Of Brian Rosen >>>>>>>>>>> Sent: Tuesday, September 17, 2013 9:44 AM >>>>>>>>>>> To: Fernando Mousinho >>>>>>>>>>> Cc: stir@ietf.org; Hadriel Kaplan >>>>>>>>>>> Subject: Re: [stir] Call Center Implications >>>>>>>>>>>=20 >>>>>>>>>>> We have a requirement to support the BPO use case. >>>>>>>>>>>=20 >>>>>>>>>>> The notion we had is that the company contracting the call=20 >>>>>>>>>>> center approves the use, and the call center, or the SP=20 >>>>>>>>>>> acting on its behalf, signs. >>>>>>>>>>> Think of this as another level of delegation. An SP=20 >>>>>>>>>>> delegates numbers to the company. The company "delegates" >>>>>>>>>>> use of those numbers to the call center. The call center=20 >>>>>>>>>>> calls, using that delegation. >>>>>>>>>>> The credentials of the call center would be different from=20 >>>>>>>>>>> those of the company, but would cover the same number. >>>>>>>>>>> Having multiple credentials covering the same number will=20 >>>>>>>>>>> be very common due to the way delegation happens. In order = >>>>>>>>>>> to allow SPs to sign, without creating credential per TN,=20 >>>>>>>>>>> we allow credentials with ranges. >>>>>>>>>>> The >>>>>>>>>>> ranges could overlap when delegation happens. >>>>>>>>>>>=20 >>>>>>>>>>> Consider the following complex US case: >>>>>>>>>>> The North American Number Plan Administrator delegates=20 >>>>>>>>>>> 202-555-xxxx to the Pooling Administrator. The PA now has=20 >>>>>>>>>>> a credential covering the entire 10K block. >>>>>>>>>>> The Pooling Administrator delegates 202-555-1xxx to SP A. =20 >>>>>>>>>>> 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=20 >>>>>>>>>>> 202-555-123x to Company C. Company C has a credential for=20 >>>>>>>>>>> a >>>>>>>>>>> 10 number block Company C authorizes 202-555-1234 to BPO D. = =20 >>>>>>>>>>> BPO D has credential for a 1 number block >>>>>>>>>>>=20 >>>>>>>>>>> NANPA and the PA never are in a call path, so they would=20 >>>>>>>>>>> never sign a call. >>>>>>>>>>>=20 >>>>>>>>>>> However, SP A or SP B could sign a call from either Company=20 >>>>>>>>>>> C or BPO D using the credential they have. >>>>>>>>>>>=20 >>>>>>>>>>> The SP for the call center could acquire credentials from=20 >>>>>>>>>>> the BPO and sign on its behalf. I suspect than many=20 >>>>>>>>>>> service providers would be reluctant to do so unless the=20 >>>>>>>>>>> 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=20 >>>>>>>>>>> probably has to do the signing itself. >>>>>>>>>>>=20 >>>>>>>>>>> Brian >>>>>>>>>>>=20 >>>>>>>>>>> On Sep 17, 2013, at 8:46 AM, Fernando Mousinho (fmousinh)=20 >>>>>>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> I agree, Hadriel. While large call centers (including BPOs, = >>>>>>>>>>>> which provide services for other companies) may have=20 >>>>>>>>>>>> special arrangements with SPs, the majority (small to >>>>>>>>>>>> mid-size) will probably rely on the SPs to do provide to=20 >>>>>>>>>>>> vouch for their identity. This would probably be the case=20 >>>>>>>>>>>> for the home analog caller anyway. This would imply that=20 >>>>>>>>>>>> the "originating" SP's willingness to provide this=20 >>>>>>>>>>>> signature is a critical success factor for the proposal's > adoption. >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> But back to the business process outsourcers (BPO) case -=20 >>>>>>>>>>>> where a call center is providing service on behalf of=20 >>>>>>>>>>>> multiple companies. I can see the value of them sending=20 >>>>>>>>>>>> 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=20 >>>>>>>>>>>> that SP >>>>>>>>>>>> 1 allowing one of its subscribers to send an outbound call=20 >>>>>>>>>>>> using a number registered to SP 2 could be a no-no. If=20 >>>>>>>>>>>> this hypothesis is correct, then we are back to the case=20 >>>>>>>>>>>> where the SP is signing all calls, >>>>>>>>>> even for BPOs. >>>>>>>>>>>>=20 >>>>>>>>>>>> Or maybe this is another problem we are trying to fix in=20 >>>>>>>>>>>> the working group, in which case we perhaps should state as = >>>>>>>>>>>> a goal or >>>>>>>>> benefit: >>>>>>>>>>>> "providing a reliable mechanism to let calls originated=20 >>>>>>>>>>>> from one >>>>>>>>>>>> SP1 to outpulse numbers that belong to another". >>>>>>>>>>>>=20 >>>>>>>>>>>> Fernando >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> On 9/16/13 12:12 PM, "Hadriel Kaplan" >>>>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Any of them could do it. My guess is service providers=20 >>>>>>>>>>>>> will do it for most call centers, although larger call=20 >>>>>>>>>>>>> centers might do it themselves... >>>>>>>>>>>>> especially ones which have trunks from multiple providers=20 >>>>>>>>>>>>> and can source calls using the same number(s) out through = >>>>>>>>>>>>> multiple providers on a call-by-call basis. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> -hadriel >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Sep 16, 2013, at 9:49 AM, Fernando Mousinho (fmousinh)=20 >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I'm catching up with the discussions in this working=20 >>>>>>>>>>>>>> group, and am trying to understand some architecture=20 >>>>>>>>>>>>>> implications in call centers (which is where my=20 >>>>>>>>>>>>>> background is). It seems that many of the problems we=20 >>>>>>>>>>>>>> are trying to fix are related to contact centers anyway, = >>>>>>>>>>>>>> so it is probably a good idea to have everyone in the=20 >>>>>>>>>>>>>> same >>>>>>>>>> page. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Forgive me if it is an obvious question, but which=20 >>>>>>>>>>>>>> components in a "typical call center architecture" do=20 >>>>>>>>>>>>>> you see signature and verification taking place? Such "typical" >>>>>>>>>>>>>> deployments have premises based equipment (PME), a=20 >>>>>>>>>>>>>> session border controller >>>>>>>>>>>>>> (SBC) >>>>>>>>>>>>>> and of course a SIP service provider all three could=20 >>>>>>>>>>>>>> potentially be used throughout the authorization = process. >>>>>>>>>>>>>> There are different ramifications depending on where=20 >>>>>>>>>>>>>> your mind is at. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Fernando Mousinho >>>>>>>>>>>>>> Cisco Systems >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> stir mailing list >>>>>>>>>>>> stir@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> stir mailing list >>>>>>>>>>> stir@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> ________________________________ >>>>>>>>>>>=20 >>>>>>>>>>> This e-mail may contain Sprint proprietary information=20 >>>>>>>>>>> intended for the sole use of the recipient(s). Any use by=20 >>>>>>>>>>> others is prohibited. >>>>>>>>>>> If >>>>>>>>>>> you are not the intended recipient, please contact the=20 >>>>>>>>>>> sender and delete all copies of the message. >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> stir mailing list >>>>>>>>>>> stir@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> stir mailing list >>>>>>>>>> stir@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>> _______________________________________________ >>>>>>>>>> stir mailing list >>>>>>>>>> stir@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>> _______________________________________________ >>>>>>>>> stir mailing list >>>>>>>>> stir@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> stir mailing list >>>>> stir@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/stir >>>>=20 >>>=20 >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> cnit mailing list >> cnit@ietf.org >> https://www.ietf.org/mailman/listinfo/cnit >=20 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From york@isoc.org Thu Oct 31 17:23:47 2013 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9B8311E8214; Thu, 31 Oct 2013 17:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6RuN-cPzYXD8; Thu, 31 Oct 2013 17:23:42 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0208.outbound.protection.outlook.com [207.46.163.208]) by ietfa.amsl.com (Postfix) with ESMTP id BD54E11E8274; Thu, 31 Oct 2013 17:23:39 -0700 (PDT) Received: from BLUPR06MB067.namprd06.prod.outlook.com (10.242.187.146) by BLUPR06MB066.namprd06.prod.outlook.com (10.242.187.145) with Microsoft SMTP Server (TLS) id 15.0.800.7; Fri, 1 Nov 2013 00:23:32 +0000 Received: from BLUPR06MB067.namprd06.prod.outlook.com ([169.254.16.179]) by BLUPR06MB067.namprd06.prod.outlook.com ([169.254.16.186]) with mapi id 15.00.0800.005; Fri, 1 Nov 2013 00:23:32 +0000 From: Dan York To: Richard Shockey Thread-Topic: [cnit] [stir] Application servers - Re: Call Center Implications Thread-Index: AQHO1biA3G/gb2mTzke6nbeDituM9JoOw8mAgABLfICAAEbdgIAAL5yn Date: Fri, 1 Nov 2013 00:23:31 +0000 Message-ID: References: <32C55AFE-FA17-4776-AD91-259AD3E226BE@brianrosen.net> <024001ced5a2$f3268810$d9739830$@shockey.us> <029501ced5b5$8fa9f480$aefddd80$@shockey.us> <2AA32171-1AE3-4AEE-AEDC-B2031562B7BD@brianrosen.net> <00d901ced637$9e8143a0$db83cae0$@shockey.us> <8B0027B8-D777-48F3-B5BF-B8F81F038E37@brianrosen.net>, <020a01ced680$caf4ec90$60dec5b0$@shockey.us> In-Reply-To: <020a01ced680$caf4ec90$60dec5b0$@shockey.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [74.75.92.114] x-forefront-prvs: 00179089FD x-forefront-antispam-report: SFV:NSPM; SFS:(55674002)(51704005)(24454002)(377454003)(189002)(199002)(85306002)(77096001)(82746002)(33656001)(74706001)(74876001)(74366001)(87266001)(83072001)(53806001)(56816003)(54356001)(36756003)(76482001)(54316002)(81542001)(56776001)(76786001)(76796001)(77982001)(51856001)(31966008)(74662001)(59766001)(49866001)(69226001)(74502001)(47446002)(81342001)(19580395003)(83716003)(47976001)(4396001)(65816001)(81816001)(63696002)(83322001)(50986001)(19580405001)(80976001)(46102001)(47736001)(79102001)(81686001)(66066001)(80022001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR06MB066; H:BLUPR06MB067.namprd06.prod.outlook.com; CLIP:74.75.92.114; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: isoc.org Cc: "cnit@ietf.org" , DISPATCH , Brian Rosen Subject: Re: [cnit] [stir] Application servers - Re: Call Center Implications X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 00:23:47 -0000 Richard, > On Oct 31, 2013, at 5:34 PM, "Richard Shockey" wrote= : >=20 > I am very interested in working on improving caller name. >=20 > [RS> ] So I'm not completely insane? :-) =20 Welllllll... we can debate that! ;-) But... If you are insane then a number= of us are because I, too, am interested in working on this. > Ok then it seams the > conversation is worth having and there is productive work here .. I will admit that when we started working on STIR, I had it in my head that= when we talking about "secure origin identification" we were talking about= BOTH the phone number and the displayed caller name. I don't think securin= g ONLY the phone number fully helps regular users, because the regular pers= on out there usually looks at (and trusts!) the displayed "Caller ID".=20 If we secure the phone number but not the display name, attackers/spammers = are simply going to figure out ways to send a valid phone number but a conf= using display name. Sure, the secured phone number may help track the attac= ker down, but in the meantime victims have been fooled into giving up infor= mation.=20 So I think we have to look at how we secure both. > See you in > London. =20 Why London? Are you not in Vancouver? Or were you just saying this is post-= Vancouver work? Dan=