Dead route information stored in e164.org

[evilbunny]

Please be aware that we have registered a free UK number (that doesn't expire) for the purposes of sending out test calls, the number will show up as 448445620415.

In future we're planning to play a recorded message to anyone that calls this number stating you were called by our SIP probe etc etc etc.

 

[inquisitor]

Do you guys happen to have placed test calls to PSTN numbers, too? After receiving your test calls on my VoIP URIs I noticed 3 calls on my cell today, which were dropped that fast, that my cell didn't ring at all. One of them followed the other immediatley, like it occured on the VoIP test calls.

 

[evilbunny]

Calls sent to the PSTN require you listen to a PIN number and enter it into the website, if there is a problem sending a call it should wait a minute or so before trying again.

 

[evilbunny]

The other suggestion instead of blocking 1 or more CIDs it might be useful to filter based on SIP headers instead.

We were thinking of something like:

X-Verify-Probe: yes

Thoughts on this?

 

[evilbunny]

I've been working on a method to "guess" the time zone based on the IP, can I get some feed back how good the "guesses" are based on what gets selected on the signup page (or myaccount page if you haven't set it yet).

 

[alvoip]

415, like 486/480 should also be accepted, it's just a handshake failed due to codec negoiations (hopefully this will never happen as I've tried to list all possible codecs in the INVITE packet)

Wouldn't 415 be the solution? Make your probe calls request a non-existing codec with no alternatives to it. All calls will be rejected with 415, but you know that the SIP URI is valid and something is answering there.

 

[evilbunny]

We tried this and it didn't work. I think the phone still rang.

 

[jcovert]

The problem with ANY timezone based system is that people travel. My phone numbers follow me wherever I go in the world, and ring on my desk, in my pocket, in my hotel room, back at home, etc., for every incoming call.

One-ringy-dingies can be very annoying, especially when you're in a hotel room somewhere on the other side of the world, having just gotten off a long flight, and have managed to get to sleep, and then the phone rings once and stops. Or even if you're awake. "Why did that ring only once? Is my Asterisk PBX screwed up? Oh. Just another call from e164.org."

While I fully agree that there needs to be a way to validate the information in e164.org before people will believe that it's worth using and this seems to be a reasonable solution for now for people with smart enough systems that they can ignore a call based on your callerID in a way that makes you believe that the number is good, some better solution may be needed for others.

Here's what I'm doing in my Asterisk dialplan:

; Answer any test calls from e164.org and then just wait a bit and hangup
exten => _[a-zA-Z0-9*#]./448445620415,1,Goto(s,1)
exten => _[a-gi-zA-Z0-9*#]/448445620415,1,Answer()
exten => _[a-gi-zA-Z0-9*#]/448445620415,n,Wait(30)
exten => _[a-gi-zA-Z0-9*#]/448445620415,n,Hangup()

Here's a proposed alternate solution.

First, let the e164.org user pick the solution he wants. One choice would be what you're doing now, with the UK 844 callerID. I'd pick that, since I've fixed my asterisk.

Another choice would be "manual validation every 3 months". If chosen, you would send an email to the address of record 75 days after the last verification, giving 15 days for the user to respond. A simple reply to the return address with "call now" in the body of the message would initiate the test call at a time of the e164.org customer's choosing. No response for 15 days would result in either a reminder and another 15 days or deregistration.

Other methods could also be devised, with the e164.org user choosing from any one of them.
/john

 

[evilbunny]

Another choice would be "manual validation every 3 months". If chosen, you would send an email to the address of record 75 days after the last verification, giving 15 days for the user to respond. A simple reply to the return address with "call now" in the body of the message would initiate the test call at a time of the e164.org customer's choosing. No response for 15 days would result in either a reminder and another 15 days or deregistration.

The problem with this is a lot can happen within 3 months, a lot can happen in a week for that matter (especially as the number of records grow).

I agree time zone based information is limited in value but ideally we'd like to test once a week and deal with any problems sooner then later.

So we're stuck not entirely sure what to do, but there is a problem and we need to figure out a solution that gets everyone to block these calls (if they are valid, or replies with a fail if they are not)

 

[jcovert]

Validating routing has always and will always be a problem. It's worse in an "open" network where you have to get people to agree on some sort of standard way to validate.

One of the better examples of misrouting was the fact that for years, anyone served by the Hempstead Toll Tandem (516 area, Long Island, NY) was unable to call any 800 numbers assigned in South Carolina. You see, someone had entered "Charleston, WV" as the route, instead of "Charleston, SC". The problem persisted for years, presumably because there weren't enough SC businesses in those days that needed to be called from Hempstead and environs that a complaint actually reached and was understood by someone who could fix it.

I just realized that the dialplan code I've put in my Asterisk server will cause e164.org to "pass" any ENUM entry that points to my server. However, the entry itself might, when a call arrives with a callerID other than the UK test ID, not go where it is supposed to. (It will at least end up in an IVR, but might not actually reach the intended destination directly.) And that's the problem with putting in a special "test" mechanism. The "test" will work, where a real call might not.

I also just punched the "Enum Test" button on my entry, and THAT placed a call from a B.C. callerID. I suppose that's intentionally different than the automated testing, and that's probably a good thing.

/john

 

[evilbunny]

Validating routing has always and will always be a problem. It's worse in an "open" network where you have to get people to agree on some sort of standard way to validate.

Well at present we still do nothing, we haven't figured out the best way to least annoy people. We have enforced SIP route verifications when adding or updating routes, but that only deals with what is valid now, not in future.

The "test" will work, where a real call might not.

Ideally if some other mechinism lived in the phones to handle this, such as a mini black list to reject calls then all would be well, but instead we need a work around to cover everyone else that can't do this.

I also just punched the "Enum Test" button on my entry, and THAT placed a call from a B.C. callerID. I suppose that's intentionally different than the automated testing, and that's probably a good thing.

Actually that's a legacy thing, although we shouldn't use the probe CID for anything else, since it would be blocked

 

[jcovert]

at present we still do nothing, we haven't figured out the best way to least annoy people

Does that mean that you got so much bad feedback from your last probes that you've stopped the probing?

 

[evilbunny]

Does that mean that you got so much bad feedback from your last probes that you've stopped the probing?

Lots of people didn't appreciate the call in the middle of the night... no... At the same time people also appreciated the effort we were making to ensure that the routing details is valid that they want them to happen, just not in the middle of the night