VoIP and ENUM

Now to the last presentation of the ENUM Update session from Baruch Sterman on XConnect

So what is the problem of the VoIP providers in XConnect?

1. I want to peer with other providers. To do so, I have finally to publish somewhere the information which E.164 numbers I host and also to publish the information how my SIP server - ahh - my ingress gateways, session border controllers and other evil devices can be reached. A SIP AoR (no - one can derive my identity from this) or at least an IP-address (IP address - that's good)

2. BUT, I do not want to publish this information because the world is evil and the worst enemies are the other VoIP providers. First they should not know how many customers I have - I do not want them ROTFL that I have only 200. And if they know this 200, they first thing they will do is to take them away from me.

This is called a typical Catch 22.

So I cannot use ENUM and DNS as is, because with ENUM and DNS the data is hosted within my Tier 2 or uploaded to a Tier 1 hostig the NAPTRs providing the SIP URIs. SIP URIs will disclose which numbers I host and also can be harvested.

Therefor the data need to be anonymized. I have to trust of course XConnect. XConnect is not giving back the URI, only the IP address. This cannot be harvested? I do not want to answer this question.

In addition I have a performance problem (have I?). I do not want to make an all call query to the XConnect database all the time, only if it really provides me with usefull answer.

I want to have a local copy of the database, but of course the other do not want me to harvest their data either, so the only information left in the local database (called Local Intelligent Caching Server - LICS) is:

• Proxy sends ENUM query to LICS
• LICS checks its cache, if so it returns the IP address or void/tel:
• If not, it sends out an ENUM query to central authority
• CA returns either IP address or void/tel:
• LICS passes on the response and caches the data

Seriously, I am not making this up. The information contained in this complicated structure is basically 1 (one) bit (number in XConnect or not), but to improve performance the bit is of couse cached.

This in turn causes of course a Time-To-Live (TTL) problem:

• Persistence TTL (expiration from cache)
• Update TTL (refresh rate)
• Data can be “touched” without real-time constraints
• Data refreshing is important
• Port from a previously called number on PSTN
• Port from one ITSP to another

I agree, data refreshing is important.

Nominum is announcing on their webpage a full ENUM database hosting 200 Mio records and performing up to 45000 queries per second and this VoIP providers have already performance problem with a 1 bit ENUM?

I have BTW no idea why they are calling this ENUM at all.

How paranoid one can get?

And these VoIP providers will NEVER issue a SIP URI to a customer. Imagine an evil competitor starts harvesting user ENUM for the numbers the other VoIP provider has in his 1-bit ENUM.