Docstoc

neca-trs-committee-final-v3.ppt

Document Sample
neca-trs-committee-final-v3.ppt Powered By Docstoc
					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
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                     VRS Provider




                                                           Small Block
                            Block of TNs                     of TNs

                                                                         Request    Assign a TN
                                                                          a TN     384-922-1313

  •   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
VoIP Model is the Logical Choice for TN Administration


                                                                          VRS Provider
                                                            Interpreter
  Hearing Person




 Dials
 310-222-1111

                                               Trunk connection
                                               to VRS provider
                                                                                          Deaf Person
                               Wholesale LEC                                             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
          •   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



                                   Interpreter

                                                                               Routing
                                                                                 DB


    Hearing Person




               Dials                                                         Video connection
               800 #                                                         btwn Relay provider
                                        VRS provider A
                                                                             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       ENUM          ENUM Redirect
                                                   (DDNS)



                                                     DDNS              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         LEC Partner                                                     LEC Partner                VRS provider B




             Routing
               DB
                                 Routing
                                   DB
                                                        Routing
                                                          DB
                                                                             Routing
                                                                               DB
                                                                                           ….           Routing
                                                                                                          DB


     Routing DB provider A Routing DB provider B Routing DB provider C   Routing DB provider D   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




                              Interpreter                                         URI to IP
                                                                                address table
                                                           Routing
                                                          DB Provider                             Video phone updates
                                                                                                  its IP address to the
                                                                                                  user’s chosen provider

  Hearing Person


                                                    IP signaling to provide
                                                    IP address to Provider A
             Dials
             800 #                                                               VRS provider B
                                   VRS provider A
                                                                           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
                                                                                     DNS
                                                                                  DB Provider
                                            Interpreter                                                         URI to IP
                                                                                                              address table
                                                                                                                                        Video phone updates
                                                                                                                                        its IP address to the
                                                                                                                                        user’s chosen provider

    Hearing Person


                                                                            Video connection
                  Dials                                                     btwn Relay provider
                  800 #                                                     and deaf user
                                                   VRS provider A                                               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
                      location                         Database
                      info to VPC                 TN
                                                                                            E9-1-1 Provider
                                                                  ESGW        Selective Router
                                                 Location
                                                                                                              PSAP

                                            VPC
                         Originating                   ESQK
Deaf User                Softswitch
                                                                                                              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                                         Location
                                                                          & TN
                                                                                    ALI
  • Softswitch sends call to VPC
  • VPC, in conjunction with ESGW, routes the call to the correct PSAP
  • VPC provides location of caller to PSAP
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

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:0
posted:2/26/2013
language:English
pages:24