Telephone Numbers and E9-1-1 for Video Relay Service - Leveraging Existing Solutions December 4, 2007 Adapted from a presentation given to NECA TRS Subcommittee.

Telephone Numbers and E9-1-1 for Video Relay Service -

Leveraging Existing Solutions

December 4, 2007

Adapted from a presentation given to NECA TRS Subcommittee

Tom McGarry

NeuStar, Inc.

[email protected]

Telephone Numbers and E9-1-1 for Video Relay Service*

• Telephone Numbers (TN)

– Telephone number assignment solution

• How do the deaf users get their TNs?

– Routing database solution

• Enables any VRS provider to complete a call to any deaf user (using a telephone number)

• E9-1-1

– Implementing the VoIP solution for video relay service (VRS)

* The term video relay service is used throughout this presentation however the described solutions apply to IP Relay except where noted.

INC Effort for Telephone Number Solutions

• In January ’06 the North American Numbering Council (NANC) charged the Industry Numbering Committee (INC) with evaluating the TN issue for VRS

– INC is not addressing E9-1-1 but must ensure that whatever solution is chosen does not conflict with providing E9-1-1 to VRS users

• The INC is expected to issue a report at the end of the year

• The NANC will create an Issues Management Group (IMG) to review the report

INC Has Been Considering 3 Options for TN Assignment

• VoIP model

– VRS providers get TNs from telcos and assign the TNs to users

– Users can port their TN to another provider using the traditional porting process

• Remote call forwarding *

– Deaf users gets a TN from their local telco and forwards the call to the 800# of the VRS provider

– Deaf user resets call forwarding to another VRS provider if they want to change provider

• TN administrator for the deaf *

– FCC designates a TN administrator for the deaf

– Deaf users go to the TN administrator for their TN

– The TN administrator goes to the deaf user’s local telco to get the TN

– The TN administrator sets remote call forwarding to the 800# of the users chosen VRS provider

* A variation on these options is that the user goes to the VRS provider for the TN and the VRS provider gets the TN on their behalf.

VoIP Model is the Logical Choice for TN Administration

• The VoIP model:

– Is functionally equivalent with how hearing people get their TNs

– Is an existing, proven model

– Has existing providers and processes for TN service implementation and delivery

– Has existing providers and processes for E9-1-1 service implementation and delivery

– Provides a single entity (the VRS provider) for the deaf person to work with for implementation and ongoing service and maintenance

– Does not require new entities involvement for funding, i.e., telco and TN administrator for the deaf

VoIP Model is the Logical Choice for TN Administration

• Remote call forwarding and TN administrator for the deaf:

– Are not functionally equivalent with how hearing people get their TNs

– Require the development of new processes for service implementation

– Require a new unique process be developed for populating the E9-1-1 database

• It’s undetermined is such a process is acceptable

– Involve many entities making implementation and ongoing service and maintenance complex and confusing

– May require new funding capabilities to fund telco and TN administrator for the deaf

– May require an RFP process to select TN administrator for the deaf

– Both require remote call forwarding and that will not work exactly the same everywhere, thus causing different service experience for different users

• In some cases the telco’s RCF implementation may make it impossible to provide the service

VoIP Model is the Logical Choice for TN Administration

• The North American Numbering Plan Administrator (NANPA) provides blocks of TNs to the telco

• The telco will provide TNs to the VRS provider from their inventory

– Identical to method used today by resellers, mobile virtual network operators (MVNOs), and VoIP providers

• The VRS provider will assign a TN to their user from their inventory

NANPA Wholesale LEC VRS Provider

Assign a TN384-922-1313

Block of TNsSmall Block

of TNs

Request a TN

VoIP Model is the Logical Choice for TN Administration

• Direct dialed call from a hearing person to a deaf person will work as follows:

1. The hearing person dials the TN

2. The Telco Network routes the call to the LEC

3. The LEC sends the call to the VRS provider

4. The call is completed to the deaf user with an interpreter on the line

Dials 310-222-1111

Trunk connectionto VRS provider

Wholesale LEC

Interpreter

Deaf Person310-222-1111

Hearing Person

VRS Provider

VoIP Model is the Logical Choice for TN Administration

• Myths about the VoIP model:

– This will create a very high demand for TNs

• False - The demand will likely be fulfilled by existing inventory already allocated to the telco

• Telcos provide TNs in very small quantities, even one at a time

• The correct model would be for the provider to request a small quantity of TNs in the most populated areas

– If there is a request for a TN in an area that they do not have a TN they can go back to the telco and ask for one

– This is exactly what VoIP providers do

– The VRS providers will have to put circuits in (i.e., trunks) to every rate center that they want a TN

• False – The VRS provider can put in one set of trunks to the telco (just like they do for 800 calls), all calls will come to the VRS provider over that one set of trunks

– This will be much more expensive than what is done today

• False – While there will a new cost from the telcos for TNs, otherwise the costs are similar to today’s costs, e.g., it requires trunks to a telco and there is a usage cost for the traffic from the telco to the provider

– Usage is moving from 800 TNs to geographic TNs

– Usage for geographic TNs will cost less than usage for 800 TNs

INC has been considering 2 Basic Options for the Routing Database

• All solutions have the following characteristics in common:

1. The deaf user selects a specific VRS provider to always receive calls that are direct dialed, i.e., the hearing person dials the 10 digit TN

2. The deaf user can change their VRS provider and keep their TN

• This means that all calls now go to the new VRS provider

3. If a hearing caller wants to use a different VRS provider they can call the 800# of the provider then provide them with the TN that he or she wants to talk to

– The VRS provider will use the TN to connect to the deaf user

• The routing database is necessary to enable the 3rd characteristic

Routing Database Enables Greater Choice

Dials 800 #

VRS provider A

Interpreter

Hearing Person

RoutingDB

Video connection btwn Relay provider and deaf user

• The hearing person dials the 800# of their chosen VRS provider

• The hearing person provides the TN of the deaf person that they want to talk to

• The VRS switch queries the Routing database that maps TNs to Internet addresses to complete the call to the deaf user

• A video connection is set up between the VRS provider and the deaf user

INC has been considering 2 Basic Options for the Routing Database

NPAC Solution DNS Solution

ENUM RedirectENUMDynamic DNS(DDNS)

DNS with delegationDDNS

DDNS

• There have always been 2 basic solutions; NPAC and DNS

• The DNS solution initially had 3 variations; 2 were combined to create 2 variations, then the last 2 were combined to create 1 DNS solution – DDNS

• Both solutions have evolved over time, things you’ve heard in the past attributed to a solution may no longer be relevant

NPAC Solution for the Routing Database

• NPAC is the only industry-wide database with FCC oversight that supports 10 digit geographic TNs

• The proposed solution would add a field in the NPAC that provides the Internet address in the form of a Uniform Resource Identifier (URI) for the VRS provider and user

• Due to privacy concerns from the VRS providers the URI data would only be provided to a neutral third party routing database provider

– There are many existing routing database providers that provide Internet routing service using NPAC data

– VRS providers would not get the data

• The user will update their chosen VRS provider with their IP address

• The calling VRS provider would use the URI to get the IP address from the user’s chosen VRS provider

Routing Database Update Process Using the NPAC

• Relay providers would provision URIs for their customer’s TNs through their LEC partner

• The LEC partner updates the NPAC with the URI data

• The URI data is downloaded to routing database providers

• If a TN ports from VRS provider A to VRS provider B then VRS provider B will update the information in the NPAC through its LEC partner

Routing DB provider A

RoutingDB

Routing DB provider B

RoutingDB

Routing DB provider C

RoutingDB

Routing DB provider D

RoutingDB

Routing DB provider X

RoutingDB

….

NPACLEC PartnerVRS provider A LEC Partner VRS provider B

Call Processing Using the NPAC Solution

Dials 800 #

VRS provider A

Interpreter

Hearing Person

VRS provider B

RoutingDB Provider

Video connection btwn Relay provider and deaf user

IP signaling to provideIP address to Provider A

URI to IPaddress table

Video phone updatesits IP address to the user’s chosen provider

• Call processing is consistent with existing standards and practices– Customer updates their service provider with their IP address (client to server)

– Call set-up signaling occurs between the service providers (server to server)

– Media connection goes directly from originating service provider to customer (server to client)

DDNS Solution for the Routing Database

• The industry will select a neutral third party DDNS Provider

– The provider hosts the DDNS DB that is updated by the VRS providers and queried by the VRS providers

• The user will update their chosen VRS provider with their IP address

• The user’s chosen VRS provider will update the DDNS Provider’s DB

• The VRS providers query the DDNS Provider’s DB to obtain the IP address of the deaf user

• The VRS provider does signaling for call set-up directly to the user’s device

Call Processing Using the DDNS Solution

Dials 800 #

VRS provider A

Interpreter

Hearing Person

VRS provider B

DNSDB Provider

Video connection btwn Relay provider and deaf user

URI to IPaddress table

Video phone updatesits IP address to the user’s chosen provider

VRS provider updates DNS provider with IP address

• Call processing is not consistent with existing standards and practices– Call set-up signaling occurs between the service provider and the customer (server to client)

• There will be firewall and security issues that will effect the ability to provide reliable service to all users

– The service provider serving the customer must update a central DDNS server with the user’s (i.e., client’s) IP address• This will require software development and the creation of new standards

• This will create a divergent path from existing standards solely for deaf people

• This alternative standard will have to be maintained solely for deaf people into the foreseeable future

The NPAC Solution is the Logical Choice for the Routing Database

• Uses current call processing standards used by hearing people

– The DDNS call processing method will be unique to deaf people

• Therefore it will not benefit from ongoing development and evolution of the current standard process

• And it will require its own ongoing development and evolution

• Uses existing infrastructure

– NPAC exists

– NPAC update process exists

• There is the need for a new capability in the NPAC and some additional processes and procedures

– There is an existing competitive market of companies that provide routing services based on NPAC data for IP enabled applications

– No need to select a neutral third party routing database provider

The NPAC Solution is the Logical Choice for the Routing Database

• URI architecture is necessary to support important capabilities in current configuration

– It is necessary to distinguish between SIP and H.323, the two protocols used for call processing

• With the IP address architecture a default protocol will have to be established for all providers and video phones

• Default protocol will likely be H.323, currently the dominant protocol, however it is also the outdated and less flexible protocol

– It is necessary to support IP relay

• URI architecture is extensible to future services and service bundling

– Would enable capabilities such as voice mail (speech to text VM)

E9-1-1 VoIP Solution for VRS users

• Implementing the E9-1-1 service requires:

– The calling party must have a valid TN

– The VRS provider must contract with a VoIP Positioning Center (VPC)

• User’s TN and location are provided to the VPC• VPCs provide location information to PSAPs

– The VRS provider must contract with an Emergency Services Gateway provider (ESGW)

• ESGWs provide a network to complete calls to PSAPs

• This solution:

– Is based on the solution that wireless and VoIP providers use

– Is an existing proven solution with existing proven providers

– There are multiple competing VPC and ESGW providers

Relationships between PSAPs and VRS/IP Relay Providers

• The 9-1-1 system assumes a tight relationship between a carrier and a call

• The PSAP looks to the VRS/IP relay provider to assist when there is a problem

• The PSAP wants to be able to identify the provider handling the call and contact it to assist when there is a problem. This should be in the ALI record.

• The ALI record (which comes from the VPC), needs to have all of the fields populated. This is only possible if there is ONE VRS/IP Relay provider per TN (same as VoIP)

• If a call is dropped, we really want to be able to re-establish the call with the same CA. This is only possible if a call back reaches the same VRS provider, which implies the default VRS provider.

• The user can still connect to any VRS provider and use them for the call, although location and routing wouldn’t be automatic.

E9-1-1 Call – Deaf Person to PSAP

Interpreter

Deaf User

ALI

PSAPSelective RouterESGW

VPCOriginating Softswitch

LocationDatabase

TN

Location

Location& TN

ESQK

Location& TN

ESQK

VoIP Positioning CenterVRS Provider

E9-1-1 Provider

Standard VoIP E9-1-1 call processing used for VRS:

• Deaf user provides user location info for VPC

• Deaf caller inputs 9-1-1 into their video phone

• Interpreter is added to call

• Softswitch sends call to VPC

• VPC, in conjunction with ESGW, routes the call to the correct PSAP

• VPC provides location of caller to PSAP

Provides user

location

info to VPC

VRS Numbering Solutions – Existing solutions will be more efficient than developing new solutions

• Using existing capabilities and solutions to provide VRS users with TNs and E9-1-1 service will speed implementation and minimize costs

– Existing solutions have proven processes and procedures

– Leveraging existing processes, procedures, and systems that resellers, MVNOs, VoIP providers and others use to provide their customers with TNs and E9-1-1 service will keep costs down and promote functional equivalency

• VRS providers should contract with VPCs and ESGWs to provide E9-1-1 service to their deaf users

– These services use proven systems and processes

Summary

• Use existing capabilities and processes used by hearing people to enable TNs and E911 to deaf people

– Adopt VoIP model for TN administration

– Adopt NPAC as authoritative routing database

– Adopt VoIP solution for E911

• Using existing capabilities and processes will be faster, cheaper and will ensure these services evolve hand in hand with services provided to hearing people