Dead route information stored in e164.org
 

While it's nice having lots of routes listed in our zone, there are numerous routes weren't setup correctly or are no longer valid. This can be because of VSPs no longer allowing anonymous calls, incorrectly configured servers, configuration changes and so on and so forth.

All these problems can lead to a lag in call setup times and other kinds of surprises that shouldn't happen in a real time environment demanded by VoIP calls.

So with that in mind we (e164.org) have started working on methods to probe a every SIP URI in the database to see if "calls" will be accepted or not. At this stage we are monitoring the results from running a probe over SIP routes stored in our database.

We haven't come to a conclusion in terms of a policy for failed routes, but we feel that sending people a warning email should be done at the very minimum. We are still debating about when and what circumstances dead routes should be removed.

While we'd like to have probes for all protocols at this stage it isn't feasible (both coding and maintaining) so we encourage everyone to use SIP at the minimum for inter-connections as SIP routes will soon have a level of vetting. SIP is also the most widely supported open protocol on the internet so it makes sense to get everyone to use a common method of communication (even if people list additional protocols as well).

New/Edited SIP enum entries under the "Phone Numbers" tab now are checked to see if you can accept a call before allowing you to add the number into the system. Please let me know if there is a problem with our SIP probe functionality that adversely effects anyone where it shouldn't.

At present we seem to be compliant with relevant SIP RFCs, however there is always going to be a manufacturer somewhere that has a implementation that isn't 100% SIP compliant that we will need to work around.

I saw a SIP request sourced from 0123456789 heading to my phone just now (18:13 GMT) which directly got canceled by the peer. Is that the test? :)

Yes that is our test, although we sent caller name as well "e164.org route test", we tried to send the cancel as quickly as possible to minimise/prevent any ringing, although it seems it isn't quite quick enough in all cases and I'm planning to modify the database somehow to allow people to enter time of day/time zone information so as to reduce the number of calls to people in the middle of the night in their respective time zones.

I've setup a wiki page to cover most/all information I posted in this thread, however as things change etc the page will contain the updates.

http://www.e164.org/wiki/SIPProbe

Well that explains it then.

I got two separate calls that showed up as "e164.org route" on my callerID yesterday (I'm guessing that it just says "e164.org route" due to the length of the callID display on my phones). In both cases the phone rang, the callerID showed up on the phone, I picked up the phone and said "hello", and then silence (no recording saying what was happening, or anything). Luckily I was up at the time with family visiting for the holidays (vs being woken up by the phone), but it was still a WTF type situation...

BTW: My guess is that your software called twice, because I have 2 ENUM numbers registered. However, since both of those ENUM numbers point to the same SIP address (a FWD account, if you were wondering), isn't it a little redundant (not to mention annoying on this end) to call me twice (when you already know that the SIP address is good, as you have already tried that address from the other number)?

Other things I noticed:
When I just logged into my e164.org account now (after reading this thread) I got a notice to set my time zone (good). But your pull down menu does NOT let you set the time zone (bad). Instead, it stupidly requires you to pick a city/country that is in the same time zone as you, to indirectly set your time zone.

While some people no doubt like this (and some people are more used to thinking about what is near them, than what time zone they are in), many of us find it a PITA to try to look carefully trough the list to find somewhere which has a time zone equivalent to ours (since most cities/countries aren't included in the list, so most of us can't just find our city/country listed). Could you please actually add in (to the drop-down list) the 24 time zones that are offsets from "universal time" (such as GMT, GMT+1, GMT+2, ... GMT-1, GMT-2, ...), and maybe also include the 4 common USA time zone names (i.e. USA: Pacific; USA: Mountain; USA: Central; and USA: Eastern)? I'm sure adding in those time zone entries (to your list) will make it much easier for some people to set their preferred time zone...

It didn't occur to me to group by `URI`, but now that you mention it I'll add that to the auto check script...

I did this to account for time zone changes due to daylight savings time, not to annoy people, because some places have it some don't and even within the same country it can vary.

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.

lr=on = dead route
 

We were woken up by a probe call early Sunday morning. So the probe successfully validated my URI.

However, even though e164 successfully validated my URI, for anyone using SipBroker / VoXaLot, my URI is effectively a dead-route, because of the "lr=on" problem :(
http://forum.voxalot.com/showthread.php?t=53&page=2

I spent a little time thinking about this, long story short the system will attempt to guess your time zone based on whois info of your IP, no idea how accurate it will be, but it should go close most of the time.