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

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

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

4. Updated Use Cases

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

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

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

8. Central TN Database Approach

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

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

11. Use Cases Revisited with CTND

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

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

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

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

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

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

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