Presentation is loading. Please wait.

Presentation is loading. Please wait.

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.

Similar presentations


Presentation on theme: "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."— Presentation transcript:

1 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. tom.mcgarry@neustar.biz

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

3 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

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

5 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

6 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 Its 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 telcos RCF implementation may make it impossible to provide the service

7 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 LECVRS Provider Assign a TN 384-922-1313 Block of TNs Small Block of TNs Request a TN

8 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 connection to VRS provider Wholesale LEC Interpreter Deaf Person 310-222-1111 Hearing Person VRS Provider

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

10 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 3 rd characteristic

11 Routing Database Enables Greater Choice Dials 800 # VRS provider A Interpreter Hearing Person Routing DB 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

12 INC has been considering 2 Basic Options for the Routing Database NPAC SolutionDNS Solution ENUM Redirect ENUM Dynamic DNS (DDNS) DNS with delegationDDNS 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 youve heard in the past attributed to a solution may no longer be relevant

13 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 users chosen VRS provider

14 Routing Database Update Process Using the NPAC Relay providers would provision URIs for their customers 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 Routing DB Routing DB provider B Routing DB Routing DB provider C Routing DB Routing DB provider D Routing DB Routing DB provider X Routing DB …. NPAC LEC PartnerVRS provider ALEC PartnerVRS provider B

15 Call Processing Using the NPAC Solution Dials 800 # VRS provider A Interpreter Hearing Person VRS provider B Routing DB Provider Video connection btwn Relay provider and deaf user IP signaling to provide IP address to Provider A URI to IP address table Video phone updates its IP address to the users 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)

16 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 users chosen VRS provider will update the DDNS Providers DB The VRS providers query the DDNS Providers DB to obtain the IP address of the deaf user The VRS provider does signaling for call set-up directly to the users device

17 Call Processing Using the DDNS Solution Dials 800 # VRS provider A Interpreter Hearing Person VRS provider B DNS DB Provider Video connection btwn Relay provider and deaf user URI to IP address table Video phone updates its IP address to the users 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 users (i.e., clients) 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

18 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

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

20 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) Users 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

21 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 wouldnt be automatic.

22 E9-1-1 Call – Deaf Person to PSAP Interpreter Deaf User ALI PSAP Selective Router ESGW VPC Originating Softswitch Location Database TN Location & TN ESQK Location & TN ESQK VoIP Positioning Center VRS 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

23 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

24 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


Download ppt "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."

Similar presentations


Ads by Google