ENUM - practical usage experience

[matka]

Thanks to Ward's ENUM article I had configured e164 with couple of my DID's and it works as advertised. Still, I have some doubts how usefull ENUM lookup is in the real, non hobby environement. Some of the concerns I have:

- it takes some time to perform a lookup, 5 or 10 seconds of silence
- call quality - some of test numbers had very bad quality, PIN number call from e164.org was almost impossible to understand, I had to record
- number harvesting, will my ENUM numbers be flooded with unwanted marketing calls ?
- how effective is the pool of numbers ? I searched for "Smith" in e164 white pages in USA and got 4 or 5 hits, possibly most of the numbers are not listed
- most of my calls are in Canada and overseas, any unique experience with Canadian numbers (I suspect that we are well behind US in sharing numbers...)

So before I plunge into ENUM as an offering, can you share your experiences from commercial or semi-commercial installations ?

Thanks;

George

 

[jmullinix]

I have set my numbers up on e164 and have never had an issue with unwanted calls coming in that way.

Dundi is more difficult to set up, but I think it will work better in the long run. It is a peer-to-peer thing that querys all of the members of the cloud for phone numbers. There is a tutorial on my website for it.

http://cohutta.com/Dundi_How_to.pdf

 

[matka]

164.arpa and e164.info lookups are commented out

I tested my ENUM and it seemed that only lookup against e164.org worked. I used this overseas number (echo cancellation test from germany) 437800047111 and could not connect. I looked into enumlookup.agi and the other enum orgs are commented out !

$enums = Array(
'e164.org',
//'e164.arpa',
//'e164.info',
);

Once I removed the comments, it does loops thru them to find a dial.
There is no enum.conf in sight being used here, just good old plain hardcoding....

I'm not sure what to do with this "discovery" ? post on free-pbx forum, post free-pbx bug ? Post a patch to read enum.conf and load into array ?

George

 

[tshif]

Just to be clear - you don't have enum.conf on your system? What version of freePBX are you using? We are running FreePBX 2.5.1.0, and enum.conf was present by default.

 

[matka]

I'm running FreePBX 2.5.1.0 also. enum.conf is avaliable in the /etc/asterisk but as far as I can see enumlookup.agi is not using it. Unless I have missed some configuration step...

 

[FitnessPlus]

My Commercial Experience

Our work environment is 10-15 extensions, 2 PSTN lines, 4 VOIP lines, and because of the nature of our business people in the office are often on the phone with our vendors and/or manufacturers. These are often 1-800 numbers and I set up an ENUM trunk to free up lines because dialing toll free numbers via ENUM is free.

This worked fine for a few weeks then we started having bad audio quality. Just a call or two at a time at the start but eventually it was most of the calls. I finally shut it off.

 

[tshif]

ENUM and `Toll Free gateways`

Ok, I have to confess to being confused a little by some of what I have read in this thread.

Perhaps I don't get ENUM - but I *think* its doing what I expect it to.

I have registered with e164.org several numbers. This provides a way for us to register A URI (sip:somewhere@ourserveraddress) to reach the number we have registered via VOIP instead of POTS DID. We then make inbound routes for each of the URI's we register.

When any PBX (Like */PBXIAF), individual client, or even some tele-providers that has ENUM lookup enabled tries to reach any of these POTS DIDs, they instead find the e164.org URI reference - and place the call to us as VOIP instead - bypassing POTS and the associated fees altogether. (Their call to us will be free for them, and for us.)

Our PBX (being ENUM enabled) does the same of course. When we try to dial a telephone number, our PBX first checks the ENUM trunck to see if there is a URI reference for the number being dialed. If there is, PBX places that call via VOIP instead of hitting the POTS network at all. (Our call to THEM is free.) This includes LOTS of 800 numbers that we call - so when the 800 number URI reference is found, those 800 calls go out VOIP, do not hit POTS, and therefor cost no money.

I dont think the cost free tollfree gateways being discussed are necessarily related to ENUM. It seems to me they are used when the ENUM lookup fails to return a URI. Then, the PBX looks to place the 800 call normally - via your outbound routes. If you insert one or more of the cost free tollfree gateways into the outbound route list (for your toll free numbers ONLY of course, with the correct pattern match), the PBX will try to place the toll free call through one of these. Again, if the call goes through - it will be free.

The last thing is if ENUM fails, and the free gateways do not land the call, it would be placed out your regular VOIP trunk. Most VOIP trunk vendors DO CHARGE for calling a toll free number - so its more or less going to cost whatever your non TF calls do.

We have been using ENUM for about 4 weeks. About 1/3 of our outbound toll-free destinations seem to be registered - thus making them free to us . I haven't checked to see exactly how many `normal` calls get routed out to ENUM - but ANY would be better than NONE - since those calls are free. We dont suffer any quality issues.

I have to agree about the no cost tollfree gateways. They have not been very reliable, and the quality of the calls has ranged between fair to unusable. We have stopped using them, and just pay for the 800 outbound calls if they dont happen to be registered for ENUM.

So - I am crazy, or did this make sense to anyone?

Jeremy - I was wondering - since your ENUM calls would have been placed VOIP - are you using any VOIP lines, or are you all FXO other than when you tried ENUM?
Tony

 

[matka]

Exactly as you described

Your description of the process fits exactly what I can see when testing.

Lookup is performed, if it succeeds, then the pure internet call is issued without using a voip or pstn provider.

On a failed lookup, If you have more than just an enum trunk in the outbound route, then it will try the next trunk.

Caution when testing, I picked an overseas test number from voip-info.org (437800047111) and discover that this number is on a premium Austrian route, paid 39 cents a minute when lookups were failing... Now when testing, I have only ENUM trunk in my outbound...

Good news about 1800 lookup ratio, if this is the case then the ENUM is worth including just for 1800. Would you be willing to check if you had any non 1800 connections ?

George

 

[FitnessPlus]

Jeremy - I was wondering - since your ENUM calls would have been placed VOIP - are you using any VOIP lines, or are you all FXO other than when you tried ENUM?
Tony

When we were using ENUM, the fail over was an FXO.
Basically the outbound route for a toll free number was:
ENUM
FXO trunk (our fax line)
FXO trunk (business line that receives a decent number of incoming calls)
SIP trunk - VoicePulse Connect.

I had to remove the ENUM from the beginning because the quality was poor. Voicepulse will actually let us place toll free calls outbound without charging us for minutes, but we had problems with calls dropping after 60 seconds. In talking to their technical support they told me that some toll-free providers were using something called "Pre Audio" that their system couldn't handle. Basically the audio is sent before the system on the other end signals that the call has successfully connected. This lack of successful connection code makes their system think the call has not been successful and their system just hangs up. In practice this would mean that we would pick up the phone, dial a toll free number, we would hear the IVR on the other end, start pushing numbers to go through their IVR, and then the call would just end about 60 seconds into the call.

All that history to say, VoicePulse Connect...although free to make outbound toll-free calls, is now the last resort if all other lines are tied up.

 

[matka]

1800 tollfree gateway

I just found something interesting regarding toll-free gateways.

If you query Dell 1-800-999-3355 on enumquery.com/ it return 3 sip addresses. In this sequence

service address
sip sip:[email protected]
sip sip:[email protected]
sip sip:[email protected]

when dialling the number in PIAF, enumlookup.agi returns the following

Set("SIP/1007-093f7128", "TRYDIAL=sip/[email protected]|sip/[email protected]|sip/[email protected]|") in new stack

and then proceeds to dial the first sip number

Called [email protected]

Connection was established and it sounded ok, however, does this mean that by using enum 1800 we might have to use toll free gateways ? Are any of those addresses (especially sip:[email protected]) more preferable then others ?
And what is "sip-happens.com" ?

George

 

[matka]

1800 tollfree gateway - few more observations

Few things that are apparent after some testing:

- dns lookup in enumlookup.agi returns the e164 sip addresses in random order
- FreePbx dial plan tries only the first sip address, if it fails, it goes to the next trunk

from the freegateways that I listed (same gateways are showing up for a number of 1800's)

sip:[email protected] - server error each time I try
sip:[email protected] - connects eventually, even after 10-15 seconds
sip sip:[email protected] connects right a way

So it is hit or miss...

Did anybody tried to loop thru all retruned sip addresses ? And, an easy way to suppress a bad gateway or specify order preference ?

George

 

[matka]

Actually it should loop thru but it does not...

Found another bug in enumlookup.agi.

When multiple sip are returned from agi they are separated by "|", this does not allow for a CUT function to separate the entries.

exten => s,n,Set(TRYDIAL=${CUT(DIALARR,%,1)})
exten => s,n,Set(DIALARR=${CUT(DIALARR,%,2-)})

there are messages in asterisk log to such effect. Once I replaced "|" in agi with "%", it loops thru found sip gateways.

George

 

[tshif]

ENUM hit ratios

Would you be willing to check if you had any non 1800 connections ?

George

Sure - but my methods are not very sophisticated. My ratio for 800 calls came from observing live results during business hours. I haven't quite figured out the best way to ferret out that kind of info in the logs yet. Do you have a recommended way?

 

[tshif]

Interesting - Semi pseudo VOIP

I just found something interesting regarding toll-free gateways.

If you query Dell 1-800-999-3355 on enumquery.com/ it return 3 sip addresses. In this sequence

service address
sip sip:[email protected]
sip sip:[email protected]
sip sip:[email protected]

...

Connection was established and it sounded ok, however, does this mean that by using enum 1800 we might have to use toll free gateways ? Are any of those addresses (especially sip:[email protected]) more preferable then others ?
And what is "sip-happens.com" ?

George

This is really interesting.
This suggests that Dell doesn't really have a VOIP gateway for themselves - but that instead - to reduce the cost of their 800 service (destination pays for 800 calls typically) they have registered their TF numbers with ENUM, but are actually sending calls through the no cost TF gateways. Interesting twist. They are using ENUM to actually make it a POTS call by referencing the TF gateways.

Thats to bad - I have had poor luck with the quality from the TF gateways. I'd rather avoid them - but it seems if 800 number owners register their TF lines in enum, and reference the gateway - were stuck using them.

I would prefer they installed an actual VOIP entry point to their pbx's and avoid the TF gateways. It seems this way is a convolution of the purpose of ENUM - to make an otherwise POTS call via straight VOIP.

I suppose if these are for TF #'s we call regularly - we could estabish a seperate route for known numbers that doesnt use ENUM.

 

[tshif]

Surprise!

I'm running FreePBX 2.5.1.0 also. enum.conf is available in the /etc/asterisk but as far as I can see enumlookup.agi is not using it. Unless I have missed some configuration step...

Found another bug in enumlookup.agi.

When multiple sip are returned from agi they are separated by "|", this does not allow for a CUT function to separate the entries.

exten => s,n,Set(TRYDIAL=${CUT(DIALARR,%,1)})
exten => s,n,Set(DIALARR=${CUT(DIALARR,%,2-)})

there are messages in asterisk log to such effect. Once I replaced "|" in agi with "%", it loops thru found sip gateways.

I have very poor luck when posting anything on the FreePBX forum, or bug list. (My favorite cursory response to receive is `Closed, works for me.`) But you might want to bring it up and see if you can get their attention and an answer about what you have found here. It seems important to me.

 

[matka]

try this. very simplistic...

Do you have a recommended way?

My regex is not very good, but I tried this

egrep sip/ Master.csv | egrep -c -v 1800

It will give you a count of sip calls that do not contain 1800, but it will also include 1866...

I'm sure that regex experts in the forum here will help us out...

George

 

[matka]

Posted a bug with a patch to FreePbx.

http://freepbx.org/trac/ticket/3423

George

 

[jeremywillden]

A note to anyone else trying this out - perhaps I just overlooked it in Ward's setup instructions, but it's vital that all ENUM lookups occur with the form of the number as it would be dialed internationally. For US numbers, that means it must go out the trunk starting with 1 followed by the area code and number.

Depending on how your routes are configured, you will probably want to add these dial rules to the ENUM trunk settings:
1801+NXXXXXX
1+NXXNXXXXXX

 

[jeremywillden]

Work-around for Toll-free gateway issues

I think I understand what's going on with the toll-free gateways. It appears that three different toll-free "gateway" providers have registered their services as enum records.

The specification for how these records work allows a regular expression match, not just an exact number match, meaning that the companies have simply registered any number starting with 1800 (and so on) as a call they can originate (from VoIP to POTS). It's pretty clear that they are able to do this by receiving some of the money that the receiving company pays to receive a toll-free call. One in particular advises clients that if they place over 1 million minutes of toll-free calls per month, it can become a source of revenue for them.

Keeping that in mind, obviously not all the gateways are of equal quality, and at least one has a long delay, another never seems to complete a call, but tollfreegateway.com appears (at least with my handful of test calls) to do a good job.

The easy fix I see is to add (unless you already have one) an outbound route specifically for toll-free calls and *do not* include your ENUM trunk on the trunk list. This prevents the ENUM lookup from resulting in a call that won't connect (not due to a problem with our end, but rather the problem with the toll-free gateway company).

If your main phone provider gives you free toll-free calling, then you can stop here and still have the advantage of ENUM on all your other outbound routes.

Next, if you choose to, you can create a special trunk to take advantage of the toll-free gateway that actually seems to work. I did it this way:

In FreePBX, create a new CUSTOM trunk. Set the callerID for outbound calls (though I don't know if it will be used) and leave everything else blank except for the Custom Dial String, which should be:

sip/[email protected]

This will take any call routed to this trunk and throw it to the tollfreegateway.com server (edit: while adding the 164164 prefix the gateway wants).

Now go back to the outbound route you created for toll-free calls and make this custom trunk the first entry in the trunk list. If tollfreegateway.com fails to complete the call, I expect that your box will fail through to the next route.

Everyone try it out and post your results here.

 

[matka]

There might be other solutions

but tollfreegateway.com appears (at least with my handful of test calls) to do a good job.

I guess you want to avoid:

tf.voipmich.com
tollfree.sip-happens.com

In the patch that I have submitted to freepbx, I left an opening for additional parameters in enum.conf. Something like that

[general]
search => e164.org
search => someother164.org
skipgateway = > tf.voipmich.com

All the parms are returned from enum.conf general section, but only search is used, I did not wanted to introduce too much functionality (this is my first patch there ).

Another solution, long term and more sound from the design point of view, is the improvement request logged by evilbunny from e164.org. He has asked to add functionality to try diff gateways in a parallel and retain the first one to answer. This request was assigned and maybe there is a way to implement it. Correction: he asked to do parallel dsn lookups, not calls to gateways.

One potential weakness to dial sip directly is that the number you dial does not always ends up being the sip dial, this is probably more important with non 1800 enums.

Meantime, I loop thru gateways, play a little sound file ("trying gatweay 1....) and wait for timeout or error out from gateway. tf.voipmich.com errors out quickly, sip-happens sometimes takes 15-20 seconds, tollfreegateway connect usually well as you mentioned.

George