I think the only long term answer, which also addresses the "porting" nightmare, is to have a central per-number database. This means when any call is made by any telco they have to check the database to find where they send that call. The destination could still be an old fashion SS7 "point code" or whatever. The mechanism can be DNS, and have multiple servers and caches and even private intranet as used by mobile operators for things like GTP. DNS is such a well proven system that works for the Internet and works for a lot more DNS lookups per second than telephone calls per second.
A central database has several advantages:-
- Allocation on per number basis removes any wastage
- Porting is simply a database update and does not involve original telco in call routing
- The database can have a few critical extras such as emergency services contact data and TPS/FPS flag
- Numbers can be charged for per number not per block, which manages number hogging, but scales costs to customers so small telcos are not disadvantaged.
So, here is the idea of how you get there from here:-
- Define a simple number allocation API and DNS style lookup - try avoiding having a huge committee for this - it can be standard enum DNS, and simple SOAP/XML API.
- Get a company to run the database as a pilot - there are a lot of companies that could do this. It is not rocket science.
- Allocate a block, as a pilot - perhaps in a conservation area, but maybe in 03 or some such.
- Data fill the block conventionally with a point code of a company that can handle the DNS lookups and forward correctly to the real endpoint (maybe same company running database)
- Define an extra high interconnect cost for routing the block via that legacy gateway
- Make it that legally the numbers are per number designated to the telco even though one telco is handling the legacy routing for the block
- Make it that legally the database is run on behalf of OFCOM and owned by OFCOM, just subcontracted
- Don't make it expensive for telcos, even small telcos, to access API and DNS - ideally that should be free. Just charge per number allocated.
Run pilot in stages:-
- One block for testing everything
- All conservation areas for all remaining blocks in those areas
- All areas for all new blocks
- Changing some existing blocks over to the new system
- Changing mobile operators to same system, so same porting rules
This is all good, but phone numbers are going to end up like IP addresses and increasingly URLs before long. Only a few people will care what the address of the device is, everyone else will just pick "AAISP" or "My Dad" on their phone and then talk to them. We're pretty much at this point already. My parents still dial even on their mobile by using phone numbers, but everyone under the age of about 40 just find the contact in their phone and presses dial... All we need is a proper distributed contact list to look people up in. Half the phone numbers in my book I never put in, they came from facebook or google contacts automatically for my contacts there.
ReplyDeleteI realise that doesn't in any way resolve your problem and your ideas are good, but really I can't see anyone caring in 10 years what someones "number" is so some of the problem goes away. If you want to call someone you'll find them on facebook(1) and then click "call".
(1) Or whatever the new facebook is in 10 years.
The issue there is that noone labels everyone in their address book the same way. He might be Dad to you, but he's John to others, or Uncle, or Grandad. It might be AAISP to you, but it might also be to others, Work, ISP, My ISP, Andrews&Arnold, A&A, Andrews and Arnold, RevK etc etc.
DeletePhone numbers provide a unique address space that anyone can apply their own personal set of labels to - if you were to have a global address book, you would still need to ensure that everyone can set their own 'alias' for every entry as well anyway.
DNS is used as part of the IMS spec... but it doesn't seem suitable to me, without modification of the semantics of DNS wildcards.
ReplyDeleteFor example, you can route an entire prefix (lets say +44123....) to a certain destination with a DNS record like:
*.3.2.1.4.4.e164.arpa.
But then the owner of +44123456789 wants to port the number to another telco. So we add a record like:
9.8.7.6.5.4.3.2.1.4.4.e164.arpa.
Great - this overrides the wildcarded entry when you look up that specific number. Unfortunately, it also overrides the wildcarded entry for everything below 4.3.2.1.4.4.e164.arpa, so you end up needing wildcards at all levels - what a mess!
Certainly something DNS-like sounds good, but the semantics of DNS itself have always seemed ill-suited to having phone numbers shoe-horned into it.
As for phone numbers rapidly becoming too long to remember, the idea of creating DNS entries to convert email addresses to phone numbers (therefore you just "dial" someone's email address, which is hopefully more memorable than the phone number) has always seemed like a good idea to me, but doesn't seem to have caught on. Also disappointing is that most SIP phones seem unable to cope with non-numeric SIP addresses, so there goes the whole idea of just handing out a single foo@example.com address that works for email, SIP, XMPP, etc...
DNS would be fine with an entry per number, and should scale perfectly well. The delegation arrangements allow the actual servers to be suitable load balanced and scaled as needed.
DeleteOf course, for iMessage and FaceTime I already call people by email address :-)
There are already "per number" checks here in the U.S.. We call that "dipping". When the caller completes dialing, the phone switch communicates (using SS7 or SIGTRAN) with a database (hosted by Neustar) to identify the LRN (local routing number). It's described in more detail here: http://en.wikipedia.org/wiki/Local_Routing_Number and http://www.npac.com/number-portability/how-lnp-works and http://www.siproutes.com/local-routing-number.
ReplyDeleteWe don't dip all numbers -- just blocks that we know have had some numbers ported out.
I like this idea; ideally, I'd like to see it handled very much like DNS, delegations and all, with a per-number fee to cover the "root" hosting which handles delegation to operators' servers. Treat area codes as "TLDs" - relatively long TTL delegations to various servers to distribute load - and delegate existing number blocks to those operators' servers.
ReplyDeleteThe bit RevK will probably choke on is that I would like reciprocal fee-free termination; if this applied only to operators on the new routing/peering setup, with termination fees still applying to terminate calls via the legacy arrangement, operators should be quick to update. (I haven't looked closely at BT's interconnect pricing since the days of ST FRIACO, but they offer VoIP interconnect now - presumably someone here's familiar with the details of that?)
I am not against fee-free interconnects, like we do at LINX for IP, for example. What is an issue is that we have people that "host" our numbers on SS7 interconnects that cost them. If they get less for the call minutes that they have to pay for that interconnect, then they cannot relay to us free. If we could interconnect directly with other telcos over SIP, I'd be happy for that to be fee-free.
DeleteITSPA are actually working on something like this, the problem is that it seems Ofcoms view is its up to industry to sort something out, but obviously the big players (BT in particular) have no interest in changing the status quo as it is just expense for them...
ReplyDelete(incidentally, as a member of ITSPA if you want me to put you in contact with someone in the porting working group (ITSPA's work on this front has been in response to the difficulties of porting rather than anything to do with number block costs as that came up later), let me know...)
DeleteIsn't your idea pretty much what Ofcom proposed to speed up mobile number portability ?? Their proposals got referred to the CAT by Vodafone, and they were told to go away and thing again. Since then (2008) nothing's happened AFAIK in that arena.
ReplyDeleteThe first change that needs to happen, and should have happened promptly after the Ionica fiasco, is that ownership of numbers is transferred to the subscriber. That's a policy decision, and should be independent of the tech, and is 1000% necessary for anything else to actually happen - and this applies to mobile numbers too. Then the industry will get their heads banged together by that policy to sort the tech mess out, which is depressingly left over from TXE4A days.
Hmmm, perhaps time for a missive to my elected representative....