Transcript Slide 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.
[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
NANPA
Wholesale LEC
Block of TNs
VRS Provider
Small Block
of TNs
Request
a TN
•
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
Assign a TN
384-922-1313
VoIP Model is the Logical Choice for TN Administration
VRS Provider
Interpreter
Hearing Person
Dials
310-222-1111
Trunk connection
to VRS provider
Wholesale LEC
•
Deaf Person
310-222-1111
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
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
•
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
–
•
This means that all calls now go to the new VRS provider
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
Interpreter
Routing
DB
Hearing Person
Dials
800 #
VRS provider A
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
Dynamic DNS
(DDNS)
ENUM
DDNS
ENUM Redirect
DNS with delegation
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
NPAC
VRS provider A
Routing
DB
LEC Partner
Routing
DB
LEC Partner
Routing
DB
Routing DB provider A Routing DB provider B Routing DB provider C
Routing
DB
….
Routing DB provider D
VRS provider B
Routing
DB
Routing DB provider X
•
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
Call Processing Using the NPAC Solution
URI to IP
address table
Interpreter
Routing
DB Provider
Video phone updates
its IP address to the
user’s chosen provider
Hearing Person
Dials
800 #
IP signaling to provide
IP address to Provider A
VRS provider A
VRS provider B
Video connection
btwn Relay provider
and deaf user
•
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
VRS provider updates DNS
provider with IP address
Interpreter
DNS
DB Provider
URI to IP
address table
Video phone updates
its IP address to the
user’s chosen provider
Hearing Person
Dials
800 #
•
VRS provider A
Video connection
btwn Relay provider
and deaf user
VRS provider B
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
VRS Provider
VoIP Positioning Center
Interpreter
Provides user
Location
Database
location
TN
info to VPC
E9-1-1 Provider
Location
ESGW
Selective Router
PSAP
VPC
Deaf User
Originating
Softswitch
ESQK
Location
& TN
Standard VoIP E9-1-1 call processing used for VRS:
• Deaf user provides user location info for VPC
ESQK
• 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
Location
& TN
ALI
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