Enterprise Use Cases and A-Level Attestation Additional Use Cases and Central TN Database approach Peter Brown | August 2019 Based on IPNNI-2019-00071R002

Restating the problem Service providers must be able to sign with A-level attestation calls from an enterprise which is using calling numbers from a different service provider. To deliver this, we explore an approach involving an authoritative source of: TN-to-Enterprise association Delegated authority by TN Providers.

Requirements statements These requirements have come from the user community as well as industry partners – enterprise customers, carriers, etc: Carriers need a consistent set of rules that they will apply for signing for enterprises. Carriers need assurances about an enterprise’s delegated authority to use TNs. The access and retrieval of Enterprises’ assigned TN information must be secured. The Originating Service Provider has to be responsible for signing the call (for traceability and accountability). Hence Enterprise self-signing is excluded from this approach. Avoid multiple Identity Headers in signed calls. Minimise the impact on Enterprises. Simplify the complexity for Carriers. Enterprises should have the ability to use toll-free numbers as their calling numbers. Enterprises should have the ability to port their numbers from one carrier to another.

Updated Use Cases

Use Case 1: Single TNSP, Single OSP Minor update: The PASSporT is signed using an STI-Certificate with a TNAuthlist containing a single SPC with a value assigned to OSP AB

Use Case 8: Call Center – a dynamic variant of Use Case 2 Enterprise may be using a Business Process Outsourcing Contact Center for outbound call campaigns Contact Center has no TNs natively assigned Contact Center receives a list of TNs when the campaign is defined. Number blocks may be fast-changing OSP choice may be fast-changing (due to LCR, say)

Use Case 9: LNP update Not a call scenario Any solution approach must ensure that A-level attestion can be maintained for an Enterprise when it has ported a number from one TNSP to another

Central TN Database Approach

Central TN Database activity on TN assignment Enterprise requests TNs Carrier informs CTND POST /TN_ENTERPRISE_LIST TN range Enterprise ID Expiry date Carrier A SPID Carrier A cert URL Carrier A signature Carrier provides TNs to Enterprise CTND Issues to be addressed: Enterprise ID must be unique – assigned and managed by the CTND Posted TNs should be unique (except 8xx) therefore CTND responses must include error cases. 2 Carrier A OSP TNSP 1 3 Enterprise

Central TN Database activity on receipt of SIP INVITE Enterprise sends INVITE Carrier requests from CTND GET /TN_STATUS (mutual TLS) Query TN & Enterprise ID CTND responds with Expiry date Owning TNSP SPID CTND cert URL CTND signature Carrier can verify that a valid TNSP has provided TN to Enterprise. Carrier sends INVITE with attestation level A PASSporT CTND Note: (b) and (c) could operate on cached/subscribed information b c Carrier A OSP TNSP d a Enterprise

Use Cases Revisited with CTND

Use Case 2: TNSP A, OSP B Carrier ‘A’ is one of many possible Originating SPs, and also one of many TN Providers Enterprise has purchased TNs from multiple TNSP, including Carrier ‘A’ Enterprise has trunks to multiple carriers, including Carrier ‘B’, for outbound call origination For each number range provided to the Enterprise, a TN Provider will have submitted an entry to the Central TN Database Optionally, these will have been signalled to the Central TN Database Client Service at each carrier that is registered with the Database When the Enterprise sends an INVITE to an Originating SP The OSP queries their Central TN Database Client Service to confirm that the number has been registered as “in use” by that Enterprise by a valid TN Provider

Use Case 2: TNSP A, OSP B Initial TN assignment to Enterprise from Carrier A acting as TNSP TNSP A informs CTND about Enterprise TN assignment. Enterprise is able to initiate A-level attested calls through OSP B OSP B uses CTND information to ensure that Enterprise has permission to use TN. CTND 1 Carrier B OSP TNSP Carrier A TNSP 1 Enterprise 2

Use Case 4: 8xx calls Implications for Central TN Database Enterprise originates calls using 8xx numbers Enterprise may split their outbound traffic between multiple carriers, including Carrier ‘A’, and switch often to minimize cost and improve reliability 8xx numbers used by the Enterprise may be resporg’d by one owner, but carried across multiple Service Providers Implications for Central TN Database More than one Enterprise can use one 8xx number There can be multiple Enterprise IDs associated with each 8xx number in the database

Use Case 8: Call Center Enterprise may be using a Business Process Outsourcing Contact Center for outbound call campaigns Contact Center has no TNs natively assigned Contact Center receives a list of TNs when the campaign is defined. Number blocks may be fast-changing OSP choice may be fast-changing (due to LCR, say) Enterprise must inform their TNSP that TNs have been assigned (and when unassigned) to Contact Center TNSP must pass this information to CTND

Use Case 8: Call Center CTND Initial TN assignment to Enterprise from Carrier B acting as TNSP Enterprise provides a subset of TNs to Call Center Enterprise informs TNSP TNSP informs CTND Call Center is able to initiate A- level attested calls through its preferred OSP(s). 1 4 Carrier A OSP TNSP Carrier B TNSP 1 3 Enterprise 5 2 Call Center

Use Case 9: Central TN Database updates due to LNP TNSPs must inform the CTND about LNP updates within number ranges that have been assigned to enterprises The source carrier (from which a TN has been ported) must specify the remaining range of numbers that has been assigned to an enterprise which is still owned by that carrier The destination carrier (to which a TN has been ported) must specify that this TN is assigned to the enterprise and is now owned by this carrier POST /TN_ENTERPRISE_LIST TN/TN-list ported-in Enterprise ID Expiry date Carrier B SPID Carrier B cert URL Carrier B signature PUT /TN_ENTERPRISE_UPDATE TN/TN-list ported-out Enterprise ID Expiry date Carrier A SPID Carrier A cert URL Carrier A signature CTND Notes: - Carrier A must pass Enterprise ID to Carrier B - No additional work pushed down to the Enterprise. Carrier A OSP TNSP Carrier B OSP TNSP

Proposed next steps Reach agreement on incorporating content into IPNNI-00071R002 Use Cases Central TN Database approach Associated issues to be resolved Enterprise ID administration Error cases to be returned from CTND API requests In particular, whether DNs will be enforced as unique in the CTND