Subject: [dispatch] TeRQ use cases

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 31 Jan 2013 21:03:12 -0500

I took an action item back in Atlanta to return to the DISPATCH list with a few use cases for TeRQ. Eventually these would probably end up being incorporated into the framework spec, provided there's agreement that these seem like good use cases to work on. Some I've fleshed out here more than others for this initial write-up, but hopefully they're all sufficient to communicate the gist. Many of these are familiar use cases, hopefully. Comments welcome.

1) Number translation (mixed public and private directories)

An Internet gateway receives a call from the PSTN destined for a telephone number. The gateway resides in a walled garden that has numerous peering points with other administrative domains, including through a number of clearinghouses, typical of a SPEERMINT architecture. The gateway queries two services to determine where it should deliver the call. The gateway first makes a number translation request of a public directory, which returns a service provider identifier (SPID) of the network to which the call should be delivered (LUF). The gateway then makes a query to a private directory, internal to its walled garden, to translate that SPID into the the address of the proper point-of-interconnection to exit the walled garden (LRF).

In this case, the SPID might take the form of a numerical identifier, a domain name or other identifier; behind the scenes, the internal private directory may contain links between several different forms of identifiers.

The internal private directory may respond with a different POI depending on which gateway is asking - a USA West Coast gateway might get a different answer than an East Coast gateway. The directory therefore authenticates incoming queries to identify the originating gateway and serve a customized answer.

Although the internal private directory is inherently trusted by the gateway, the public directory (which returns the SPID) is not directly trusted by the gateway. The data in the public directory, however, is provisioned by authorities, including the number owners. As they provision records at the public gateway, they sign those records, and when the gateway receives a response it validates the signatures on the records and trusts those records, or not, based on its association with the signer.

Translations should be available for nationally specific numbers, including freephone numbers.

A very similar use case could also be constructed for SMS (including short codes).

2) Customer name, with query aggregation at an intermediary

An Internet gateway receives a call from the PSTN. The gateway wants to put the calling number (IAM CIN) into the username portion of the From header field value of a SIP request, and also to populate the display-name of that header field. The gateway therefore launches a query to a CNAM service, which may or may not be the same as any services used for number translation. The CNAM service only accepts requests from authorized parties with whom it has a billing relationship. Since the Internet gateway launching the query is only one of many gateways in its administrative domain, not every gateway will have a trust relationship n with the CNAM service. Instead, the gateways send their requests to a local intermediary which aggregates requests and maintains a trust relationship with the CNAM service.

Under high volumes, the intermediary maintains a transport connection to the CNAM service, rather than opening a new socket and re-negotiating security for each individual request. The intermediary may also bundle multiple numbers into a single request, and expect to get back a response with multiple records associated with those numbers. In both cases, a transaction number is used to match requests to responses.

Finally, the intermediary authenticates sources of traffic and authorizes only gateways to receive responses, as CNAM data is sensitive and the CNAM service may charge for transactions.

3) Pre-port validation

A mall kiosk that sells cellular telephones has a customer that wants to purchase a new phone and port their old number onto the phone. Porting needs to be validated on the spot and typically completed in a very short time frame (say within fifteen minutes). The new service provider for the number needs to make a query to an intercarrier communications process (ICP) service to validate the customer with the old service provider. In order to validate the port, the new service provider needs to submit the telephone number, the customer's name and customer's zip code. The ICP needs to respond either confirming that the customer information is correct for the number in question or not.

The responses to ICP queries are potentially privacy-sensitive. It is not feasible for every mall kiosk to have a direct relationship with this database, therefore requests go through an intermediary which has a trust relationship with the ICP service.

4) Caller-ID Spoofing prevention

An SMS service bureau receives an SMS message from a particular telephone number. It wants to be able to consult an authoritative service to ascertain whether or not that number is allocated and SMS capable. The bureau sends a request to the service to determine if the number in question exists and has an SMS capability. Only if a record is returned proving that the number is SMS capable does the bureau forward the SMS to its destination.

A similar use case could be constructed for voice calls.

5) Prefix-based route caching

A soft client on a tablet attempts to call out to a telephone number. The client has a pre-existing association with a service that performs number translation on its behalf; the client knows the address of an intermediary belonging to the service, and has security credentials to pass requests through that intermediary. When the intermediary forwards the request to the service, the service returns a response indicating that the entire thousand-block to which that number belongs is routed to an enterprise with an Internet PBX. The intermediary receives this response along with a time-to-live and caches the response locally. When subsequent requests come in from clients, the intermediary can match the requests against this prefix, and return the appropriate response without needing to consult the service.

6) Multiple authorities

An end user and a service provider both want to provision data against the same telephone number; for example, a service provider might want to provision an endpoint address on an Internet gateway for the number, whereas an end user might want to provision the preferred voicemail service for the number. A service can permit multiple authorities to provision data for the same telephone number. Clients who query for this data might have a trust relationship with either party or both. When a client launches a query, it should receive in response any records that authorities authorize the client to receive, allowing the client to decide what it should trust and use.

7) Inventory search

A Internet service provider provisions many telephone numbers within a given number range. The provider later wants to verify which numbers are associated with the address of a particular SMSC, perhaps an SMSC that has experienced a failure. The service provider thus wants to formulate a search query across the entire number range, requesting only those numbers that have that association. The service where the numbers are provisioned must be able to authenticate the service provider as this sort of search operation would not be authorized for end users.

Jon Peterson
Neustar, Inc.