NANC 415

SIP and H.323 URIs in the NPAC

Origination Date :12/01/2006

Originator:Neustar

Description:

Business Need:

Video Relay Service (VRS) is the preferred method for making phone calls by deaf and hard of hearing people who rely on American Sign Language as their primary means of communication. The high level process is as follows:

Hearing people (voice callers) dial the toll free number for a VRS Provider.
A sign language interpreter (video interpreter, or VI) for the VRS Provider relays the call between the hearing caller and the deaf caller.
The connection between the hearing person (voice caller) and the deaf person (sign language user) consists of a voice line between the hearing caller and the sign language interpreter, and a video connection between the sign language interpreter and the deaf caller. The interpreter relays the conversation between the two parties.

However, there are several major issues with the current functionality:

Deaf people are not assigned TNs for VRS. Therefore, they cannot provide a telephone number on common paperwork such as job/mortgage/credit card applications, business cards, etc., the way hearing people provide contact information as this field usually allows for only ten numbers. Deaf people currently have to provide the toll-free number of their VRS provider with instructions to call the specific deaf party.
They do not have the ability to provide E911 locations information because they do not have TNs.
There is limited interoperability between VRS Providers, which appears to provide severe limits on the utility of the service. A deaf user may prefer one of the VRS Providers, and a different deaf user may prefer a different VRS Provider.
It is a cumbersome and complex process for hearing people who try to call deaf people through VRS.. Different VRS Providers use different information to identify deaf users, e.g., name, proxy number, IM handle.

This change order will assist in resolving these three issues:

Deaf people, like hearing people, desire their own TN. The VRS Providers can partner with LECs to get TNs and have access to the telephone network. This arrangement would be identical to the current arrangement between VoIP Providers and LECs.
The FCC regulation states that “all VRS providers should be able to… make calls to, any VRS consumer”. If all VRS providers use a common TN-to-Internet Address DB, calls can be completed even if the hearing caller uses one VRS Provider (shorter wait time, prefer certain interpreters) and the deaf person is registered with a different VRS Provider.
Hearing caller dials the 800# of any VRS Providers and simply gives the TN of the deaf person (no need to remember to give name for VRS Provider #1, proxy number for VRS Provider #2, IM handle for VRS Provider #3). The information in the common TN-to-Internet Address DB, allows the first VRS Provider to use the Internet Address to complete the call through the VRS network of the deaf person, even if it’s a different VRS Provider.

The NPAC is an attractive solution for the following reasons:

It is a TN-level database that supports call routing.
It has an existing governance model.
The VRS URI data for all VRS-served TNs will be available to all VRS Providers.
VRS Providers could obtain the NPAC VRS URI data from a service bureau, if they did not want to deploy their own NPAC interfaces.
It currently exists in a production environment.It would take years and considerable expense to create a new database with new interfaces, new processes and a new governance model
It would take regulatory action to create a new database.
The LNPA is an open to the public and the desire for this capability is consumer driven (there have been over 2000 consumer comments to the FCC requesting this capability).

Description of Change:

The proposed change is to use the NPAC as the common TN-level database that all VRS Providers use to associated a deaf person’s TN to the URI of their VRS Provider. This would allow a hearing person to call a deaf person, and a deaf person to call another deaf person, through the simple use of their assigned TN. By using the NPAC, the VRS industry would have a common database to store the necessary SIP and H.323 URI information to reach any VRS Provider’s customer:

H.323 is the dominant technology used by VRS Providers today.
SIP is the more current technology, and it is likely that the VRS Providers will be evolving to SIP in the future.
Both URIs are required because, 1.) A VRS Provider may provide both technologies while evolving from H.323 to SIP, and 2.) A SIP Provider may provide an H.323 gateway for interoperability with H.323-based VRS Providers.
The URIs represent the VRS Provider serving the called number, not the called number itself.

Since deaf people do not have TNs for VRS today, it’s expected that the new TNs provided for this service will be:

From new inventory provided by the LECs to the VRS Providers. Functionally, this appears like stations of a PBX.
An existing TN, assigned to a deaf person for a service other than VRS, which is ported-in to the VRS Provider’s terminating PSTN access Service Provider.
Both of these two types of TNs can make use of the NPAC to store associated VRS URI data.

Additionally, this solution also allows deaf people to keep their TN, while switching from one VRS Provider to another (port their number just like hearing people).

In summary, the deaf community would like service that is consistent with the service for hearing people. By adding a SIP URI and H.323 URI, they will be able to do this.

Dec ’06 LNPAWG Con Call – The solution proposed assumes that each VRS TN is associated with some VRS Provider in the same way as each TN in the NPAC is associated with a Service Provider. The URI associated with a TN must be resolvable to the VRS CPE IP address or to some network element which can forward or redirect a call to the VRS CPE.

Major points/processing flow/high-level requirements:

This change order proposes to add new fields to the subscription version and number pool block objects. Hence, the FRS, IIS, GDMO, and ASN.1 will need to reflect the addition of these fields. These new fields will cause changes to the NPAC CMIP interface, however they will be functionally backward compatible and optional by service provider.

Requirements:

Section 1.2, NPAC SMS Functional Overview

Add a new section that describes the functionality of the H.323/SIP URI (Uniform Resource Identifier) Fields (Optional Data). See description of Change above.

Section 3.1, NPAC SMS Data Models

Add new attribute for the H.323 and SIP URI (Uniform Resource Identifier) Parameter (Optional Data) Fields. See below:

NPAC CUSTOMER DATA MODEL
Attribute Name	Type (Size)	Required	Description
[snip]
NPAC Customer SOA H.323 URI Indicator	B	Y	A Boolean that indicates whether the NPAC Customer supports H.323 URI information from the NPAC SMS to it’s SOA. The H.323 URI is the network address to the Service Provider’s gateway for H.323 service. The default value is False.
NPAC Customer LSMS H.323 URI Indicator	B	Y	A Boolean that indicates whether the NPAC Customer supports H.323 URI information from the NPAC SMS to it’s LSMS. The H.323 URI is the network address to the Service Provider’s gateway for H.323 service. The default value is False.
NPAC Customer SOA SIP URI Indicator	B	Y	A Boolean that indicates whether the NPAC Customer supports SIP URI information from the NPAC SMS to it’s SOA. The SIP URI is the network address to the Service Provider’s gateway for multi-media messaging service. The default value is False.
NPAC Customer LSMS SIP URI Indicator	B	Y	A Boolean that indicates whether the NPAC Customer supports SIP URI information from the NPAC SMS to it’s LSMS. The SIP URI is the network address to the Service Provider’s gateway for multi-media messaging service. The default value is False.
[snip]

Table 3-2 NPAC Customer Data Model

Subscription Version Data MODEL
Attribute Name	Type (Size)	Required	Description
[snip]
H.323 URI	C (255)		H.323 URI for Subscription Version. This field may only be specified if the service provider SOA supports H.323 URI. The H.323 URI is the network address to the Service Provider’s gateway for H.323 service.
SIP URI	C (255)		SIP URI for Subscription Version. This field may only be specified if the service provider SOA supports SIP URI. The SIP URI is the network address to the Service Provider’s gateway for multi-media messaging service.
[snip]

Table 3‑6 Subscription Version Data Model

number pooling block hoder information Data MODEL
Attribute Name	Type (Size)	Required	Description
[snip]
H.323 URI	C (255)		H.323 URI for Number Pool Block. This field may only be specified if the service provider SOA supports H.323 URI. The H.323 URI is the network address to the Service Provider’s gateway for H.323 service.
SIP URI	C (255)		SIP URI for Number Pool Block. This field may only be specified if the service provider SOA supports SIP URI. The SIP URI is the network address to the Service Provider’s gateway for multi-media messaging service.
[snip]

Table 3‑8 Number Pooling Block Holder Information Data Model

R3-7.2 Administer Mass update on one or more selected Subscription Versions

NPAC SMS shall allow NPAC personnel to specify a mass update action to be applied against all Subscription Versions selected (except for Subscription Versions with a status of old, partial failure, sending, disconnect pending or canceled) for LRN, DPC values, SSN values, SV Type, Alternative SPID, H.323 URI, SIP URI, Billing ID, End User Location Type or End User Location Value.

RR3-210 Block Holder Information Mass Update – Update Fields

NPAC SMS shall allow NPAC Personnel, via a mass update, to update the block holder default routing information (LRN, DPC(s), and SSN(s), SV Type, Alternative SPID, H.323 URI, SIP URI), for a 1K Block as stored in the NPAC SMS. (Previously B-762)

R3‑8 Off-line batch updates for Local SMS Disaster Recovery

NPAC SMS shall support an off‑line batch download (via 4mm DAT tape and FTP file download) to mass update Local SMSs with Subscription Versions, NPA-NXX-X Information, Number Pool Block and Service Provider Network data.

The contents of the batch download are:

Subscriber data:

- H.323 URI (for Local SMSs that support H.323 URI data)

- SIP URI (for Local SMSs that support SIP URI)

Block Data

- H.323 URI (for Local SMSs that support H.323 URI data)

- SIP URI, (for Local SMSs that support SIP)

RR3-79.1 Number Pool NPA-NXX-X Holder Information – Routing Data Field Level Validation

NPAC SMS shall perform field-level data validations to ensure that the value formats for the following input data, are valid according to the formats specified in the Block Data Model upon Block creation scheduling for a Number Pool, or when re-scheduling a Block Create Event: (Previously N-75.1).

H.323 URI
SIP URI

RR3-149 Addition of Number Pooling Block Holder Information – Field-level Data Validation

NPAC SMS shall perform field-level data validations to ensure that the value formats for the following input data, is valid according to the formats specified in the Subscription Version Data Model upon Block creation for a Number Pool: (Previously B-250)

H.323 URI
SIP URI

RR3-157 Modification of Number Pooling Block Holder Information – Routing Data

NPAC SMS shall allow NPAC personnel, Service Provider via the SOA to NPAC SMS Interface, or Service Provider via the NPAC SOA Low-tech Interface, to modify the block holder default routing information (LRN, DPC(s), and SSN(s)), SV Type, Alternative SPID, and H.323 URI/SIP URI fields, for a 1K Block as stored in the NPAC SMS. (Previously B-320)

R4-8 Service Provider Data Elements

NPAC SMS shall require the following data if there is no existing Service Provider data:

NPAC Customer SOA H.323 URI Support Indicator
NPAC Customer LSMS H.323 URI Support Indicator
NPAC Customer SOA SIP URI Support Indicator
NPAC Customer LSMS SIP URI Support Indicator

R5‑16 Create Subscription Version - New Service Provider Optional input data

NPAC SMS shall accept the following optional fields from NPAC personnel or the new Service Provider upon Subscription Version creation for an Inter-Service Provider port:

H.323 URI (via CMIP, if supported by the Service Provider SOA)
SIP URI (via CMIP, if supported by the Service Provider SOA)

R5‑18.1 Create Subscription Version - Field-level Data Validation

NPAC SMS shall perform field-level data validations to ensure that the value formats for the following input data, if supplied, is valid according to the formats specified in Table 3-6 upon Subscription Version creation for an Inter-Service Provider port:

H.323 URI
SIP URI

RR5-5 Create “Intra-Service Provider Port” Subscription Version - Current Service Provider Optional Input Data

NPAC SMS shall accept the following optional fields from the NPAC personnel or the Current Service Provider upon a Subscription Version Creation for an Intra-Service Provider port:

H.323 URI (via CMIP, if supported by the Service Provider SOA)
SIP URI (via CMIP, if supported by the Service Provider SOA)

RR5-6.1 Create “Intra-Service Provider Port” Subscription Version - Field-level Data Validation

H.323 URI
SIP URI

R5‑27.1 Modify Subscription Version - New Service Provider Data Values

NPAC SMS shall allow the following data to be modified in a pending or conflict Subscription Version for an Inter-Service Provider or Intra-Service Provider port by the new/current Service Provider or NPAC personnel:

H.323 URI (via CMIP, if supported by the Service Provider SOA)
SIP URI (via CMIP, if supported by the Service Provider SOA)

R5‑28 Modify Subscription Version - New Service Provider Optional input data.

NPAC SMS shall accept the following optional fields from the NPAC personnel or the new Service Provider upon modification of a pending or conflict Subscription version:

H.323 URI (via CMIP, if supported by the Service Provider SOA)
SIP URI (via CMIP, if supported by the Service Provider SOA)

R5‑29.1 Modify Subscription Version - Field-level Data Validation

H.323 URI
SIP URI

R5‑36 Modify Active Subscription Version - Input Data

NPAC SMS shall allow the following data to be modified for an active Subscription Version:

H.323 URI (via CMIP, if supported by the Service Provider SOA)
SIP URI (via CMIP, if supported by the Service Provider SOA)

R5‑37 Active Subscription Version - New Service Provider Optional input data.

NPAC SMS shall accept the following optional fields from the new Service Provider or NPAC personnel for an active Subscription Version to be modified:

H.323 URI (via CMIP, if supported by the Service Provider SOA)
SIP URI (via CMIP, if supported by the Service Provider SOA)

R5‑38.1 Modify Active Subscription Version - Field-level Data Validation

H.323 URI
SIP URI

R5-74.3 Query Subscription Version - Output Data – SOA

NPAC SMS shall return the following output data for a Subscription Version query request initiated by NPAC personnel or a SOA to NPAC SMS interface user:

H.323 URI (via CMIP, if supported by the Service Provider SOA)
SIP URI (via CMIP, if supported by the Service Provider SOA)

R5-74.4 Query Subscription Version - Output Data – LSMS

NPAC SMS shall return the following output data for a Subscription Version query request initiated over the NPAC SMS to Local SMS interface:

H.323 URI (via CMIP, if supported by the Service Provider LSMS)
SIP URI (via CMIP, if supported by the Service Provider LSMS)

RR5-91 Addition of Number Pooling Subscription Version Information – Create “Pooled Number” Subscription Version

NPAC SMS shall automatically populate the following data upon Subscription Version creation for a Pooled Number port: (Previously SV-20)

H.323 URI
SIP URI

Req 1 – Service Provider SOA H.323 URI Edit Flag Indicator

NPAC SMS shall provide a Service Provider SOA H.323 URI Edit Flag Indicator tunable parameter which defines whether a SOA supports H.323 URI.

Req 2 – Service Provider SOA H.323 URI Edit Flag Indicator Default

NPAC SMS shall default the Service Provider SOA H.323 URI Edit Flag Indicator tunable parameter to FALSE.

Req 3 – Service Provider SOA H.323 URI Edit Flag Indicator Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider SOA H.323 URI Edit Flag Indicator tunable parameter.

Req 4 – Service Provider LSMS H.323 URI Edit Flag Indicator

NPAC SMS shall provide a Service Provider LSMS H.323 URI Edit Flag Indicator tunable parameter which defines whether an LSMS supports H.323 URI.

Req 5 – Service Provider LSMS H.323 URI Edit Flag Indicator Default

NPAC SMS shall default the Service Provider LSMS H.323 URI Edit Flag Indicator tunable parameter to FALSE.

Req 6 – Service Provider LSMS H.323 URI Edit Flag Indicator Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider LSMS H.323 URI Edit Flag Indicator tunable parameter.

Req 1.1 through 6.1 same as Req 1 through 6. Replace “H.323 URI” with “SIP URI”.

Req 7 Activate Subscription Version - Send H.323 URI to Local SMSs

NPAC SMS shall, for a Service Provider that supports H.323 URI, send the H.323 URI attribute for an activated Inter or Intra-Service Provider Subscription Version port via the NPAC SMS to Local SMS Interface to the Local SMSs.

Req 7.1 same as Req 7. Replace “H.323 URI” with “SIP URI”.

Req 8 Activate Number Pool Block - Send H.323 URI to Local SMSs

NPAC SMS shall, for a Service Provider that supports H.323 URI, send the H.323 URI attribute for an activated Number Pool Block via the NPAC SMS to Local SMS Interface to the Local SMSs.

Req 8.1 same as Req 8. Replace “H.323 URI” with “SIP URI”.

Req 9 Audit for Support of H.323 URI

NPAC SMS shall audit the H.323 URI attribute as part of a full audit scope, only when a Service Provider’s LSMS supports H.323 URI.

Req 9.1 same as Req 9. Replace “H.323 URI” with “SIP URI”.

Final Resolution:

Moved to closed/no-action.

Related Release:

N/A.

Status: Closed