[Modern] Use cases that people may care about

[Eric Burger <[e-mail]>]

Are we boiling the ocean?

> On Apr 30, 2015, at 11:20 AM, Steve Donovan <[e-mail]> wrote:
> 
> The working group will define a framework for the roles and functions involved in managing and resolving TNs in an IP environment.

Does this mean we are replacing not only the NPAC, LERG, NANPA, et al., but ENUM, DNS, et al. too?

Let us put aside whether it is worth working on replacing something that works in order for the incumbents to spend a lot of money to get the features and functionality they get today. I.e., they have strong negative incentives to not use any results we develop in the IETF. Putting it bluntly, I did not see a lot of people saying the problems discussed by https://tools.ietf.org/html/draft-peterson-modern-problems-00 were problems that needed to be solved, or solved any time soon.

So, let’s put aside the Charter discussion for a few minutes, and see if we can come up with some problems that *do* need to be solved, and if we can rally behind a charter to solve them. If it happens that the solution to these problems can address the issues raised by Jon’s draft, then I think in the long term *everyone* can be happy.


OVERARCHING PROBLEM: E.164 numbers are being used for more than terminating phone calls by service providers.
[Why is this the overarching problem? Because if the problem is simply that the PSTN is transitioning to an all-IP telecommunications network, then until the industry really needs it, the industry will use the NPAC, LERG, etc. as is. The code to run the databases is already written, the code to interface with the databases is already written, and the policies, governance, procedures and regulations are already known and debugged.]

So, who would benefit from access to E.164 allocations that cannot get them right now?

I see two use cases; I would love it if people could pour in more.

USE CASE #1: Enterprise DID assignment
Cullen gave the compelling example of a multi-campus enterprise. Why do they need to buy their DIDs from a registered carrier, and then pay carriers for the privilege of moving them to other carriers for termination to their own campus?

USE CASE #2: DID-based applications
Another use case would be for enhanced services, such as a single number service. Today an enhanced services company needs to be a service bureau and buy their DIDs from a registered carrier, who will provide them with termination services. I.e., technically the service bureau is buying termination service and getting DIDs as a part of that termination service. Again, if the service bureau wants to change termination service providers, they have to pay for the privilege.



Let me examine Use Case #2. I would offer this is a compelling opportunity. Why? Because there are extant IP-based protocols for entities to get numbers from carriers today. Moreover, that are a bunch of incompatible IP-based protocols for entities to get numbers from carriers. I.e., we have existence proof of a solution, we have existence proof of market need, and we have an opportunity to create standards to expand markets and solve problems (like Cullen’s). For example (and thanks to Cullen for finding the URL’s so I do not need to go hunting), see:

> AT&T is doing this - see https://developer.att.com/apis/enhanced-webrtc/docs
> 
> Tropo is doing this - see phone number pricing at https://www.tropo.com/pricing/
> 
> Twillio is doing this - their pricing at https://www.twilio.com/voice/pricing#volume-pricing - and it is used by Uber, AIrBNB, PayPal, Opentable, Home Depot and so on
Twillio is also the back end for BT and others.

Note that where there are APIs, they are all different. That is an opportunity, I would think.

Now there is a subtlety going on here. All of these services are bundled with termination services. In the AT&T case mentioned above, it has a nice integration with their wireless offering and enterprise offering. For virtual numbers (DIDs), calls get handled by AT&T for termination to their customer, the app developer. For Tropo and Twillio, they ofter termination services at their platform, presumably through contracts with various global carriers, who have access to the pool of regional E.164 numbers.

Are we interested in making it easy for carriers to rent their inventory of DIDs? Are we interested in making it easy for application developers to have access to an inventory of DIDs? I know I am. Are you?

Note that solving this problem does not require the clean-sheet reinvention of the all-IP telecommunications network. I.e., not only how numbers are managed (which we have near zero consensus there is a need) but also how they are resolved (also near zero consensus there is a need).

Building on Use Case #1, if we can do retail rental of DIDs, any reason not to do bulk assignment of DIDs? This begins to come on to Cullen’s use case he brought up at the BOF. Namely, I am an enterprise and I somehow get a bucket full of DIDs. I want to assign them as I wish to my various campuses. That means that in addition to needing to be able to grab an allocation of DIDs (Use Case #2), I will need to tell my service provider how to terminate calls to a particular DID. That is a somewhat more challenging problem. However, I would offer it would have a big payout. The big payout is my expectation is a protocol that lets an enterprise grab a DID *and* lets an enterprise specify how to route that DID would look almost the same as a protocol that enables a carrier to manage E.164 allocation and use.

So, you might ask, “Has Eric lost his mind? Eric has been saying no one wants to build a protocol to enable a carrier to manage E.164 numbers, and yet in the paragraph above he says we can enable carriers to manage E.164 numbers!” Well, here is the answer: approaching the problem from the national numbering authority perspective is doomed. It is rather clear that no one wants to tackle it, and even if we did, as Pierce rather eloquently stated, we are walking right into other folks’ SDO patch. I would offer his ARIN analogy is 100% spot on.

Let us not look at this problem as “How do we do work to remove the last reason for carriers to exist?” That is, if carriers do not vouch for subscriber identity and manager their numbers, what is left for them to do? Instead, let us look at a parallel and really valid problem: how can we automate and standardize the interaction between _some_entity_with_numbers_ (carriers in the base case) and _some_entity_that_uses_numbers_ (app service bureaux and enterprises). If it happens the solution to that could be used for the cases mentioned in Jon’s draft, that is gravy.