e164.org SIP Probes
Why does e164.org need to probe SIP addresses?
While it's nice having lots of routes listed in our zone, there are numerous routes that aren'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 under 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 and 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.
The probes are sent out followed by a cancel to try to minimise/prevent phones from actually ringing, although in the real world it seems we have varied success in preventing phones from ringing while still working out if a SIP address is valid.
How does e164.org probe SIP addresses?
The probes are sent out with the caller ID info set to "e164.org test" <448445620415>
An INVITE packet is sent out from there we set a time out of 5 seconds and wait for responses, usually the remote end sends a 100 TRYING response indicating that it is attempting to use the INVITE, this prevents T1/E1s from timing out or something, and we reset the timer for an additional 30 seconds. Originally it was 10 seconds however it seems billion of devices don't return a 18x so we must give users time to answer the call so we get a 200 return code.
The next message is actually the useful one, most cases it will be 180 - 183 or 200 to indicate the call is accepted and the remote end is doing something with the request, alternatively the remote end will often send a 3xx, 4xx, 5xx or 6xx response saying the call failed, or needs to be sent else where. This is the critical point it seems where the remote end starts ringing some extensions, others don't because the cancel packet is received before ringing starts. 415, 480, 486 and 491 responses are also considered successful even though a call would have failed. This is because these packets indicate that the person was already on a phone call or what not.
In terms of a 3xx-6xx we simply respond with an ACK packet to acknowledge we received the notification of call failure so there is no need to send us any more packets.
If there was a 18x response we send a CANCEL packet, if the call was answered and the remote end sends a 200 we reply with a BYE packet. In both cases there will be another response from the remote end, usually a 487 Early Termination in which case we respond with an ACK packet, again to limit the number of packets the remote end sends.
So the probe "succeeds" if we get an initial 18x message or 200, any packets after that is just "error" handling and shouldn't be taken to mean anything differently.
We feel this action is needed to instill more confidence in the data stored in our DNS zone, and there has been a number of people requesting this before they will consider doing lookups on our zone. In fact this should give us a level of consistency better then e164.arpa.
How can I prevent these probes from ringing me in the middle of the night?
We have added a time zone and hours you are willing to accept your phone ringing, at this point in time we haven't added options for days of the week but we will most likely be adding this options as well.
Due to not wanting to make phones ring in the middle of the night we will be emailing everyone asking them to set their time zone settings, if people don't respond or don't update their settings may force us to look at disabling their SIP routing information in future.
Also SIP addresses that fail multiple probes will cause an email to be generated to people, if people are unable or unwilling to modify their settings, their SIP URIs may end up being disabled as a result as well.
Another option for some people is their devices allow you to black list a CID, in this case if you black list 448445620415 the device should return 486 BUSY, so we will still accept that that SIP URI is valid, and as if you were merely busy on the phone with another call.