Phantom Ringing and SipVicious
"Phantom Ringing" is a phenomenon where phones ring but if they are answered no one is there. Often the caller ID on these calls is something simple like 1000, even if there is no extension 1000 on the account.
The source of calls like this is usually a direct IP call (Invite) to the customer IP from a computer running an app like SipVicious in an attempt to exploit an unsecured SIP server. Since the Invites are not processed on the Cloud9Phone server there is no record of them in the Activity Report or the server logs. The Invites are usually sent on port 5060 because SIP servers, like SIP phones, talk on port 5060. Any phone registered on port 5060 at that IP will then ring in response to the Invite.
You can tell what port an extension uses on the WAN by clicking Show Details in the Extension detail page. About 2/3 of the way down you will see an entry with the IP and port of the extension such as Addr->IP: 184.108.40.206 Port 8580.
In many business applications, where several phones are registered from the same WAN IP, one phone will be registered externally on port 5060 and others at some other range, say 1020, 1021, 1022. The router in that case performs network address translation (NAT) to route the packets on the WAN side ports to the correct phones on the LAN side. A phantom call to port 5060 on the WAN side in this scenario will only ring the phone registered on 5060 externally and not the others. In a home user application where only one phone is registering from the LAN, the router will often allow that phone to register on 5060 on the WAN side.
The recommended fix for this is not to expose 5060 on the WAN side if possible, in one of the following ways:
Enable NAT in the router to force the phone to register an another port externally.
Configure the router to only allow SIP traffic from a specific IP (the Cloud9Phone SIP server).
Configure the phone explicitly to use another port (if NAT is not used).
Unfortunately in many applications where a simple home router is involved methods 1 and 2 are not possible and method 3 does not work with all phones.
We are continuing to look for ways to mitigate these annoyance calls.
It should be noted that sipvicious is a legitimate service probe (an application that scans large numbers of network addresses looking for systems running a specific service), and that beyond the annoyance factor such probes offer no threat to the hosted phone user since they are not running a sip server, only a sip phone. More info can be found at sipvicious.org.