VoIP and ENUM

Regular readers of my blog may have the slight suspicion from some of my postings that I am not what you may call "a fan of IMS". One of my favorite blogs in this direction is the IMS Insider Blog, and I already posted some comments about some of their entries. So I was very keen to read the last entry on Addessing & Numbering Strategy in IMS World, because this is of course one of my major territories. To my utter surprise, the editor is providing a PS in his posting:

For those wanting to get more into the technical aspects of this, I would strongly recommend an excellent blog voipandenum.blogspot.com.

Ahem, blush, ok. So, if they are reading me, I am oblidged at least to try to give a serious answer to this posting, with my comments inline:

A number of mobile operators have been in contact with us recently asking about addressing and numbering strategy as they move towards an IMS world.

I understand that there is a problem or even a vacuum regarding numbering and addressing strategy for IMS, because the relevant (standard) bodies have neglected these issues since years. ETSI TISPAN, 3GPP and also GSMA have ignored Numbering, Naming, Addressing and Routing including ENUM since years. They have been so busy in defining new boxes separating their networks that they completely forgot about the boxes required for connecting these networks and interworking (a Freudian lapsus?).

Whole TISPAN is entirely ignoring numbering and addressing? Well, not entirely... One small village of indomitable Gauls still holds out against - uups - one small workgroup holds out - TISPAN WG4 is trying to convince since years the rest of TISPAN that there is a problem - with not very much success. Only very recently some awareness could be reached.

There is (was?) also a group (GSMNA ENUM AdHoc) within GSMA working on implementing ENUM within the GRX network to allow interworking between mobile networks. The two groups sometimes tried to communicate, but this is officially not possible, because GSMA documents are not public and no liaisons exist.

It is clear that mobile operators for various reasons do not even think to use Public User ENUM as defined by IETF and implemented already in some countries.

What GSMA tried to achieve is private ENUM (ENUM in a closed network), similar to the Private ENUM implementations between the US Cable operators and also e.g. by XConnect et. al. The problem with all these solutions is that one may interoperate only within the federation, but how to interoperate with everybody else?

The real problem is not ENUM, the real problem is IP Interconnect or VoIP Peering based on SIP URIs - the so-called L5 peering in IETF terminology.

IETF now extended the charter of the ENUM WG to deal also with Public Infrastructure ENUM. In addition, a new workgroup is planned to be established, dealing with the IP Interconnect or VoIP Peering issues based on SIP- currently called SPEERMINT (Session PEERing for Multimedia INTerconnect)

Infrastructure ENUM and SPEERMINT is currently getting a lot of attention as possibility for a global solution to solve the VoIP Interconnect problem (VoIP standing here for basically all real-time communications possible with SIP).

The basic idea is very simple:

Infrastructure ENUM within "e164.arpa" will provide a global mapping for any E.164 number to DNS NAPTRs containing a SIP URI(s), keeping the privacy of the end-user intact. The SIP URI for an E.164 Number (e.g. +436644204100) will be a Public User Identity such as sip:+436644204100@mobilkom.at, not disclosing any information except the hosting service provider (number assignee). Here ends the scope of IETF ENUM WG.

Within the domain "mobilkom.at" the calling service provider will find all required information whether he is able to establish a call on IP to the destination network and how. He will find the NAPTRs and SRV RRs according to RFC3263 to find the border elements of the destination network and eventually also information about the federations and other requirements the destination network requires for access. These issues will be within the scope of IETF SPEERMINT WG.

ETSI TISPAN WG4 and ECC PT2 - TRIS will hold a combined workshop on NGN Interconnection and Numbering on Wednesday, January 18th, 2006 during their meetings at the ERO premises in Copenhagen this week. For more information see see the ERO webpage.
Since also participants from GSMA and other bodies are expected, hopefully some progress will be made.

Now back to the IMS Insider posting:

In the short term, as operators offer more SIP-based services, how do they help their customers manage the potential complexity of having more (and more complicated) numbers/URIs to remember/use?

Why should one have more than one numbers and/or SIP URIs to remember? The basic idea of SIP (Session Initiation Protocol) was that ALL services can be accessed via one SIP URI (Address-of-Record AoR). And ENUM is mapping one E.164 number to this SIP URI. The above mentioned problem simply doas not exist.

Part of the problem is that senior management don't necessary appreciate the problem.

My sympathy goes with you and I fully understand the problem ;-)

So, my colleagues at our sister consulting practice, STL (www.stlpartners.com), put together this simple summary of the issue for their Operator clients to use with senior management:

Transiting to SIP-based services - Address and Numbering Strategy - How to make it seamless for our customers and business partners, and differentiate vs competitors?

Now lets analyse this statement-by-statement:

Situation
- We [the Operator] are moving towards an IP-based core network, using IMS architectures.

Ok, agreed. Using IMS architectures is your problem, not mine. But you should not forget that this is not a divine law cast in stone.

- We are trialling basic SIP-based functionality with customers (Push to Talk, Video Sharing, Multimedia Messaging, Voice Enrichment).

OK, although you may also consider presence and location based services. I also consider the term "trialling" interesting. Out in the wild west of the Internet these servives are already existing in version 2.0.

- This functionality will be available on our own network only (ie. Won’t allow roaming).

Now we are reaching the real problem. Why only in your own network? Won't allow roaming? Or are you not able to provide roaming yet? Consider how many users the largest national GSM operator has and how many additional customers he may get. And now consider how many customers your real competitors already have and how many they can reach. I am talking here about Skype/EBay, Google, Yahoo! et. al.

- In 18-24 months we will be looking to launch more sophisticated converged IP-based services (via multiple bearers and devices) to compete with fixed and internet players.

I do not think that IMS will be ready for this in 24 month. Since especially the Internet players have all these services on a global scale already NOW, thinketh where they will be in 24 month. You will never be able to compete with them in your walled garden. Servicewise, all your customers will be save out side already. And you will have no support or help from your device manufacturers. The new dual-mode devices (GSM/WiFi) are already announced and to be on the safe (and customer) side, Nokia has already announced that the E60/61/70 series will feature TWO SIP stacks - the 3GPP stack and the standard IETF stack.

- IP-services require a very different address/numbering system (SIP based) than voice (MSISDN based).
- Some standards bodies exist to help with the address and numbering aspects of this (eg. ENUM)

Yes, they require SIP URIs, but with ENUM they may keep their old MSISDN, no problem here.

Complication
- SIP-based services make address/numbering much more complex and confusing for the customer. Technically, this issue has not yet been solved by the industry as a whole.

Huh? Confusing maybe for your senior managers not being able to read and write their e-mail without the help of their secretaries. SIP is working exactly like e-mail, and what part of sip:richard@stastny.com you do not understand? Which industry you are talking about?

- Unless addressed quickly, customers will be required to have multiple addresses/numbers/identities for multiple IP-based services types.

As I already said, this is simply not true. Your customers may keep their MSISDN and may use in addition, if they want so, an SIP URI similar to an e-mail address. There may be one challenge: customers may not want to have sip:detlef@vodafone.de, they may want to have also sip:richard@stastny.com, because this is also the e-mail address. This is valid especially for enterprises. This may cause a serious problem in the walled garden approach.

- Customers are already demanding single address/number schemes to access multiple services across multiple networks – they will gravitate towards the Operators who can offer this.

And are already getting it, from the Internet players, as you call them. And they already can provide access to multiple services across multiple networks NOW, and this is the reason why they will gravite to them. And you will loose (maybe not the customer, because he still will use the UMTS access), but he will not use your services.

- Third parties (content providers, business partners) will gravitate to Operators who have the most efficient way of delivering and charging end users for bundled IP-based services.

Yes, and especially business customers are really pissed off with the insane roaming charges, both for calls and data, and will find immediately the most efficient (and cheapest) way to get their services done. Enterprises will provide themselves anyway all services, including voice. Does any business customer use the e-mail service from a mobile operator? No, he is using the e-mail from the company. Why should this be different with voice? Especially if it is combined with presence and Outlook?

- Industry standards on these issues are not in place yet.

They are. Maybe not in 3GPP and ETSI TISPAN.

- Some solution vendors are selling proprietary solutions which may prevent us from creating scaleable IP-based service propositions in the longer term.

Hm, how true. Think about this. Maybe the whole IMS is such a solution? Maybe you are already taking hostage by some manufacturers wanting to continue to sell you expensive and unnecessary boxes?

Question
How can we differentiate vs competitors by creating an approach to address/numbering which is simple and effective for our customers?

Who are the competitors? Who is we? Are you competing with fixed operators, cable operators, the Internet players? Or are you competing with other mobile operators? Is the competition in future on the access or with services. With enterprises (your best customers,btw, or are this the parents of the kids you rip-off with SMS and ring-tones?) you have to compete with the customer - not a good idea after Clay Shirky's ZapMail. And since your competitors will have these solutions much sooner, you may have a problem here.

Answer
Deal with 2 interrelated issues now, to avoid headaches later on:
1.) Plan how to help the customer make an easy transition to a SIP-based address/numbers system (MSISDN/SIP co-existence, roaming, number portability, etc.)
2.) Ensure our internal technology development and interconnect strategy is in line with this.
Create a Future Address and Numbering Strategy.

Ok, get going, but consider: you are not the only service provider federation. Customers do not want walled gardens.

A consumer friendly Future Address and Numbering Strategy can only be created by ALL service providers, not only be the mobile operators.

So lets work together (or you will be Left Behind)