1. © 2008 AT&T Knowledge Ventures. All rights reserved. AT&T and the AT&T logo are trademarks of AT&T Knowledge Ventures. 1 Video Relay Service and Assignment of Numbers for IP Based Services February 16, 2008 Penn Pfautz ppfautz@att.com

2. 2 Introduction All proposals seek to provide functional equivalence in reachability and access to emergency services to meet FCC mandates by – Assigning geographic NANP numbers to relay users – Implementing a central database to support routing by any relay provider to any relay user – Providing E911 by leveraging the technology deployed for VoIP Where they differ is on – Whether users should get numbers thru relay providers or some new neutral third party – The implementation of the database NPAC vs. DNS, what it contains besides telephone number who updates it who can access it – Whether or not to use a common E911 VPC

3. 3 Number Administration AT&T Favors the “VoIP Model”: Relay users get numbers from their chosen relay provider Relay providers get numbers through commercial agreements with voice service providers Proven model in use today by VoIP service providers Avoids expense and delay of setting of third party administrator

4. 4 Database Implementation AT&T (like CSDVRS) favors DNS approach: Standard Internet approach to phone number to IP mapping Proven technology widely available from many vendors Contains IP address to support direct connection of any provider with any user (NPAC involves designated provider on all calls, even where the hearing user had selected a different provider) Unlike CSDVRS DNS updated by user’s chosen relay provider to accommodate existing user equipment (100K+) DNS accessed by relay providers – To maintain security – To accommodate existing user equipment

5. 5 VRS Provider A IP IP Change Updates Number IP Change Updates Hearing to Deaf Call: 1.Hearing person can direct dial deaf persons personal telephone number (10 digit NANP #). 2.Call routed by LEC to VRS provider. 3.VRS provider looks up IP in local or central database and completes VRS call to Deaf user. Direct Dialed (Hearing to Deaf) Call Secure DDNS LEC/ CLEC IP Number Central DB IP Number Local DB IP Number Local DB VRS Provider B 1 2 3

6. 6 Direct Dialing (Deaf to Deaf) Deaf to Deaf Call: 1. Deaf user dials 10 digit number of friend (not knowing or caring what device they use). 2. VP queries provider database, VRS provider db queries central db if needed to return current IP address of friend. 3. Direct call established to friend using current IP address. VRS Provider IP Secure DDNS IP Number Central DB IP Number Local DB Number 1 2 3 IP

7. 7 VRS Provider 1 VRS Provider 2 URI IP DNS NPAC Dynamic DNS Number Portability Administration Center URI Number COPY IP URI IP URI Number NPAC URI Change Updates VRS Provider DDNS IP Number IP Number 3 rd Party NPAC Alternate Relay Provider Selection Toll Free Number

8. 8 Deaf 911 Call Flow – Leveraging Current Wireless & VoIP 911 Solutions 911 Location Server Phone, Name & Street Address Central db VRS Provider 1 Phone Number User dials 911 through any VRS Provider Voice IP Address 911 Routing Sign Language Routes to proper 911 Call Center Pre-Emergency Setup: User registers Phone, Name, & Street Address for 911 purposes 911 Call Center receives caller’s Phone, Name & Street Address When a VRS user obtains her phone number she registers her current street address with the 911 location server – through the VRS provider of her choice. VRS provider obtains user phone number from the Central DB (or its local database if available) and routes call to the 911 service provider for delivery to the appropriate PSAP and interprets, the emergency call for the user & 911 operator. If caller is not pre-registered, VI will need to obtain location information from caller, load address information in real time prior to routing the 911 call.

9. 9 Back Up

10. 10 Video Relay Service (from 1/6/2006 CSD Presentation to NANC) Internet PSTN Deaf or Hard of Hearing ASL User Hearing User Communications Assistant (Video Interpreter) ASL Communication Between Deaf and CA Voice Communication Between Hearing and CA 6

11. 11 VRS Provider B Today Multiple VRS Providers operate Multiple Separate Databases There are an estimated 100,000 video phones in use today by Deaf & Hard of Hearing consumers. Each provider maintains a separate and closed database of its users and devices, including their unique IP address on the Internet. Some provider assign proxy numbers, some assign extensions, others provide Toll Free numbers or none at all – dialing methods vary depending upon provider and device. Because these databases are closed and do not communicate with each other end users are restricted from being able to easily dial each other. VRS Provider A VRS Provider C

12. 12 Simple Solution for Creating Dialing Parity 1.VRS providers assign NANP geographic numbers to deaf users. (providers can obtain numbers through commercial agreements in the same manner that VoIP service providers do today) 2.New secure 3 rd Party database containing current IP address & telephone numbers of VRS users. 3.Each VRS provider must keep the Central Database current with end user IP address & telephone number using a secure Dynamic DNS interface. 4.The 100,000+ existing video phones remain the same, communicating their current IP address to the provider of the device as they do today. Telephone numbers to IP address

13. 13 NPAC Proposal has significant challenges The NPAC is not a call processing database and will not contain IP addresses Instead the NPAC will have URIs, e.g. 7948675309@vrssp1.come.g. 7948675309@vrssp1.com The NPAC downloads the URIs to a 3rd party database, which VRS companies would have to interface with. On calls to VRS users other than their own, the calling VRS SP must – Query the 3 rd party database for the URI – Query DNS to resolve the URI to the IP address of the serving VRS SP – Send the SETUP message to the serving VRS SP for forwarding or redirection to the called VRS user New development in the NPAC is required VRS SPs must – Work through the company providing telephone numbers to provision the NPAC – contract with a database provider and meet their query interface – Plan to redirect or forward calls originated by other providers