On Tuesday September 6th the forum will be down for maintenance from 9:30 PM to 11:59 PM PDT

Main Menu

SIP scanners

Started by lacibaci, September 06, 2012, 05:50:04 AM

Previous topic - Next topic


@QBZappy  I must say I am very happy with Google Voice on the OBI but I do like to keep an incoming SIP backup in case there is an issue with Google Voice.  I like redundancy.  Google likes to change things and it may break functionality.  I would think requiring registration would stop that issue but even when I allowed my PAP2 to take unregistered connections I never had the problems being described here. 

I'm sure we will see an increase in this type of activity due to the increased popularity of VOIP.  If the scanner is looking for SIP specific devices putting it in on another port should work.  VOIP should work on any port that isn't being used.  Here are a few ports that should not cause conflicts.

Here is a list of commonly used and unused ports.
Long live our new ObiLords!



So long as the incoming Caller ID, shown as Peer Number in OBi Call History, has more than six digits, then it will be fine.

I'm still using the original string:
I designed it that way as I need to accept some seven-digit Caller IDs. Other users have added and changed to suit there own situations.

You may simply want to try changing the UserAgentPort as to one suggested by giqcass. That worked for me for a while, but not in the long run. Maybe I should have picked a more obscure port number.


I'm not the smartest tool in the shed, so can someone explain how the SIP scanner is coming in on SP1 - when I have SP1 set up for GV? - the SIP account I have set up is actually on SP2, but my call history when the scanner calls is as:

Call History:
From '1' SP1(1)

So the {(?|x|xx|xxx|xxxx|xxxxx|xxxxxx):},{ph} string should be put into both X_InboundCallRoute for both SP1 and SP2 I'm assuming?

All my testing seems to show that a (on purpose SIP call from one of my UK DID's) SIP call is ringing one port above whatever SP1 is - I think my SP2 is port 5062, I never could get the first port to ring and thought this was because it was configured with GV.


Will blocked calls show up in my call history still, proving my X_InboundCallRoute is working?



Here is my limited understanding of what is going on. The SIP scanners are testing millions of IP addresses and at each address they test port 5060. The nuisance calls are not coming in via your service providers, but direct to your ip address/port, so it does not matter what service provider is say on sp1. In the Obi UserAgentPort for sp1 is 5060 by default. This is the one to change to some random port as posted above. I think some scanners may also look at 5061 and 5070, as I got caught using them. Using non-default ports and the above string has worked for me.

I don't have an Obi202, so I'm curious about the Call History. You says yours shows: "From '1' SP1(1)" – does this indicate a Caller ID of "1"? If so, then the |x| rule in the string will stop it and any other single-digit Caller ID.

Blocked calls will not show up in Call History, as effectively the calls are not getting into the Obi.


So I've been using {(?|x|xx|xxx|xxxx|xxxxx|xxxxxx):},{ph} string, and now I'm getting calls from FROM 'user1' SP1(user1)


Hortoristic - I'm beginning to think that you may be the scanners' number 1 target  ;) The war against scanners goes on! I've been thinking about changing the original blocking string for a while. I have decided on the following:


It blocks anonymous calls and any Caller ID with one to six alphanumeric characters. I've tested, it does block "user1". If you wish you can add more combinations of seven or more @, I stopped at six because I needed to accept seven-digit Caller IDs.


Quote from: Hortoristic on November 18, 2012, 12:07:24 AM
So I've been using {(?|x|xx|xxx|xxxx|xxxxx|xxxxxx):},{ph} string, and now I'm getting calls from FROM 'user1' SP1(user1)

Same here. I just added user1 to the list:


Thanks guys - what I haven't made time for is to change to obscure port yet too.  Just so busy with life - this is our business number too - so I'm also scared of losing legitimate sales by blocking too much...

One more question; is this happening to everyone, even folks that just use GV - is this because I am using a SIP dialed number as well as other SP's?


Can anyone tell me if the string that were putting in


blocks phone numbers less than the number of @'s? Or is it blocking peoples Caller ID NAMES? less than that?

Also so I can just change the port X_UserAgentPort to lets say 5076? And make sure I forward that port on my router to my Obi? I don't have to change the port anywhere else do I? Like the KeepAliverServerPort?

Thank you



It blocks anonymous calls and any Caller ID with one to six alphanumeric characters. For example @@@@@ blocks callerIDs with five alphanumeric characters: user1, 12345, abc23, Peter.

Each @ is one alphanumeric character - one letter or one number. If you only want to block numbers, then use x in place of @

Yes, simply change X_UserAgentPort and forward in your router. No other change is needed.


Thank you for your reply. I get it now.

I'm just finding the string to be possibly problematic. Let's say I have a chinese friend named Hong Woo.

His Caller ID might say " H Woo". So he would be blocked by this.


Yes, it may need some fine tuning for your setup. I've looked at your Call History post. This would have stopped all of those unwanted calls:


This will ban calls with no Peer Number, any Peer Number less than seven digits, any Peer Number starting 555, Peer Number "unknown" and Peer Number "anonymous".

In your OBi110 Call History it is what appears in Peer Number that matters. Peer Name has no effect.

With a blocking string to suit your setup and changing all X_UserAgentPorts (sp1 and sp2 in your case), You should not be bothered by nuisance calls.


wow. Thanks for the help.

I just disabled SP2 this morning. I only have 1 phone number. So that should take care of that end.

Thank you again! Big Help


Using similar string I was able to stop all scanners. I'm still using default Ports too - just hadn't got around to changing them


I thing which concerns me that caller ID sometimes does not come over properly on calls from overseas, especially if people use certain cheap voip services there you just get a few nonsensical numbers.. Wonder whether to take the chance.
Messing with ports is not an option for me, the U-verse gateway will not cooperate with VOIP unless put into DMZ.
On the other hand, I have to get rod off the scanners. I am already turning off everything overnight or when on the road. :(


You just need to modify the string for the correct number if digits. Our UK incoming always begins with 44xxxxxxxx, or similar, so you build a rule that had your appropriate country code and exact number of digits. All my scanner numbers seem to have been less than 5 digits. I've posted my string earlier that has completely blocked them and we receive over seas calls ok.


@hortoristic. the problem can occur when the people use a calling card or some voip services- I guess the name was Freecall where I got the short and nonsensical ID's. But you are right about the 5 digits or less with SIP scanners and I will probably take the chance. I let people know that if their calls get blocked they should e-mail me or use a regular carrier.


@ carl. I don't know anything about the U-verse gateway, but I often run my OBi110 in DMZ and changing UserAgentPorts is still a very good idea. If port 5060 is not allocated to your Obi the scanner calls to 5060 will not call your OBi phone. To try it you only have to change the UserAgentPorts in your OBi; if the OBi is in DMZ then there is no need to change any router settings.


Update:  It's been over two months since I made changes to X_InboundCallRoute, and X_UserAgentPort, and in that time, I have had no SIP scanner calls.  So, I do believe it's working.

The changes I made I posted on this thread on Oct. 19; incoming calls with no peer number or a peer number of less than 10 digits are blocked, and I'm no longer using the common 5060 user agent port.