SIP scanners

[QBZappy]

oleg,

Nice to see you back on the forum. The IQ of the forum just spiked off the charts.

Our good friend in the UK ianobi came up with something I used in another use case which may be of interest in your setup.
   
([^*+]@@[^+].<+:@>@@.|[^*]@@.'@'@@.)

How to set up Music on hold (MOH) (the easy way)
http://www.obitalk.com/forum/index.php?topic=5180.msg33593#msg33593

[oleg]

Hi QBZappy,
I am glad to see you again :-)

I am afraid you overrate me, I was starring at ianobi's "bizarre digitmap" like a fool :-)
Well, I guessed what that map could do, but I couldn't think how it may help in my case...

Anyway, I found the solution. The parentheses did the trick.
>'myname':ph1,ph2           <- does NOT work
>('myname'):ph1,ph2         <- works!

My final inbound call route is ">('myname'|123456@.):ph1" and it allows both "myname@sip.myhost.com:5078" and "123456_name@sip.myhost.com:5078", while rejects scanner calls like following (these are real calls ringing my phone last night):

3/20/2013 2:19:10 AM    INVITE sip:+972592280470@12.34.56.78:5078 SIP/2.0
3/20/2013 2:19:14 AM    INVITE sip:0972592280470@12.34.56.78:5078 SIP/2.0
3/20/2013 2:19:14 AM    INVITE sip:00972592280470@12.34.56.78:5078 SIP/2.0
3/20/2013 2:19:17 AM    INVITE sip:000972592280470@12.34.56.78:5078 SIP/2.0
3/20/2013 2:19:17 AM    INVITE sip:0000972592280470@12.34.56.78:5078 SIP/2.0
3/20/2013 2:19:20 AM    INVITE sip:00000972592280470@12.34.56.78:5078 SIP/2.0
.......

---oleg

[Mango]

Excellent!  This is a great solution that I hope will one day become the default setting.

Is there any way we could do this with a variable, so that changing AuthUserName resulted in the DigitMap changing?

I got such an example to work with a User Defined Macro and $VoiceService.1.VoiceProfile.1.Line.1.SIP.AuthUserName, but I think my solution is actually less convenient.  Can it be done without the Macro?

[Hortoristic]

Getting a bit lost on your examples - and I'm even a software engineer by trade!

You said: My final inbound call route is ">('myname'|123456@.):ph1" and it allows both "myname@sip.myhost.com:5078" and "123456_name@sip.myhost.com:50

What exactly am I doing with your snippet: ">('myname'|123456@.):ph1" ?

I have a couple SIP accounts, one is Callcentric and one is from 3C Softswitch in UK - by just putting your above snippet ">('myname'|123456@.):ph1" in InboundCallRoute, it will auto replace myname with the correct SIP info (either Callcentric or 3C Softswitch)?

[Mango]

I believe the InboundCallRoute for Callcentric would be: (obviously, replace 1777xxxxxxx with your actual 1777 number.)

>('1777xxxxxxx'):ph1

Does that work?

[Hortoristic]

I will try - what does the other code the poster added do the |123456@. part within his example of ">('1777xxxxxxx'|123456@.):ph1"?

And just to clarify; my GV account will never get SIP scanners because it's not a SIP account?  I only need to adjust only my SIP accounts with this type of string?  Since I'm forwarding my GV to Callcentric to get free caller name, I believe Callcentric and my UK DID is where all my scanner calls are originating.

[Mango]

My interpretation is he receives call via SIP URI and via VoIP.ms.  Depending on how your UK DID is routed to your OBi, you could use the same format.

I haven't yet heard of spam calls via a service provider configured for Google Voice.  But you can check Call History to be sure.

[Hortoristic]

But the inboundcallroute is per SP - so it seems each SP would have a different inboundcallroute setting, unique to the SP - or did I misunderstand you? 

Or is it the SIP URI is using same port at Voip.MS - thus why he mixes the settings together on the same SP?

[Mango]

Either way would certainly be appropriate.

[Hortoristic]

A bit off topic - but do we know the value of these SIP scanners?  Are they trying to harvest working phone numbers to sell to telemarketers or what gives?

[Mango]

They're trying to break into IP PBX systems so that they can route their customers' high-cost calls, make illegal/scam calls, or make calls to numbers they get compensation for.  I suspect they're not actually looking for us; we're just collateral damage.

Edited to add: an improperly-configured InboundCallRoute could allow a hacker to route calls via your OBi device.  Use extreme caution when setting up an InboundCallRoute to route calls to spx or li and be sure you're doing it safely.  (If you're routing calls to ph like Oleg demonstrated, that is fine.)

[ianobi]

Hoping not to confuse things here  

My final inbound call route is ">('myname'|123456@.):ph1"

Anything within the parentheses is simply a digit map, you can put anything you want in there. Anything matching that digit map will ring the phone. As oleg points out, whatever is sent in the SIP INVITE before the "@" is what has to match the digit map.

This is how we send digits in more complex InboundCallRoutes using rules such as {>(Msp2):sp2}, where any digits sent before the "@" in the SIP INVITE that also match Msp2 are sent out to sp2.

[ianobi]

oleg,

Well you certainly got us all talking 

This: ([^*+]@@[^+].<+:@>@@.|[^*]@@.'@'@@.) is my entry for the most bizarre OBi digit map competition     It does have a use for sending SIP URI format calls over the OBiTALK network as described in another post. It does not have a function here as far as I can see!

[Mango]

Wouldn't an InboundCallRoute of {>(Msp2):sp2} have the potential to be rather insecure?  I would rather see it restricted to something like {('ianobi')>(Msp2):sp2}, thus preventing anyone who's not you from using it.  That is, assuming whatever you've configured for sp2 is not intended to be publicly accessible.

[Ostracus]

oleg,

Well you certainly got us all talking 

This: ([^*+]@@[^+].<+:@>@@.|[^*]@@.'@'@@.) is my entry for the most bizarre OBi digit map competition     It does have a use for sending SIP URI format calls over the OBiTALK network as described in another post. It does not have a function here as far as I can see!

Indeed. Aside from the nerdiness what advantage does one gain using SIP URIs vs the traditional way of calling, remembering that the ATAs and VoIP providers handle most of the complexity anyway?

[ianobi]

Mango,

Yes, very true. I tried to pick a simple illustration from my actual sp2 InboundCallRoute, which is:

{(Mcot)>(<**7:>(Mtg1))|(Mtg1):tg1},{(Mcot)>(<**7:>(Mextns))|(Mextns)|(<**7:>(Msp2))|(<**2:>(Msp2)):sp2},{(Mcot)>(<**7:>(Mvg4))|(<**4:>(Mvg4)):vg4},{(Mcot)>(<**7:>(Msoft)),(Mcot)>(Msoft):pp},{(Mcot)>(<**7:>(Msoft))|(Msoft)|(<**7:>(Mpp))|(<**9:>(Mpp)):pp},{(Mcot)>(<**7:>(**0))|**0:aa},{(Mcot)>(<**7:>(0|61))|(0|61):ph},{(Mcot):aa}

cot contains the allowed CallerIDs.

This rule from above may be of interest to this thread:
{(Mcot)>(<**7:>(0|61))|(0|61):ph}
Where you can see that the callee digit map (0|61) is used to call the phone.

[Mango]

I see that you certainly know what you are talking about.      Thanks for sharing your InboundCallRoute.

[ianobi]

Ostracus,

It was my solution to calling a SIP URI directly over the OBiTALK network using OBiON from a cell phone or OBiAPP from a softphone. The OBiTALK network does not accept "@", so I replaced "@" with "+" and then translated "+" back to "@" using the bizarre digit map.

[ianobi]

Mango,

It all makes sense if you read posts concerning using CSipSimple with OBi and using any OBI as a home PBX. Each idea just adds a little to the complexity!

[Shale]

Mango has suggested that I add Oleg's method as a good alternative way to thwart SIP scanners.  I would like to understand and then be able to describe the method in a way that a person doing setup could use.

As I understand this, the modification of the InboundCallRoute looking for the AuthUserName is an alternative method of thwarting SIP scanners.  The InboundCallRoute is what identifies whether to send a given call to ph, ph1 or ph2 on OBi202, or AA,
or to kick it to the byte bucket.

Question 1: The strings on the left side of colons are compared against the incoming caller ID equivalent -- what do we call that string?

Oleg's situation seems to be that he gets connections directly from his company rather than a sip provider...  maybe I am wrong on this.

Question 2.  Is this method be suitable as the method for avoiding SIP scanners if they receive their calls through Anveo, Callcentric, voip.ms, etc?  This method seems particularly useful for providers that have too many server IPs to list.  It also
seems useful for those that want to permit some direct connections without opening the path to everybody.

Oleg posted
3/20/2013 2:19:10 AM    INVITE sip:+972592280470@12.34.56.78:5078 SIP/2.0
3/20/2013 2:19:14 AM    INVITE sip:0972592280470@12.34.56.78:5078 SIP/2.0
3/20/2013 2:19:14 AM    INVITE sip:00972592280470@12.34.56.78:5078 SIP/2.0
3/20/2013 2:19:17 AM    INVITE sip:000972592280470@12.34.56.78:5078 SIP/2.0
3/20/2013 2:19:17 AM    INVITE sip:0000972592280470@12.34.56.78:5078 SIP/2.0
3/20/2013 2:19:20 AM    INVITE sip:00000972592280470@12.34.56.78:5078 SIP/2.0

Question 3: Where did Oleg get these logs and how would I get them?  The Call History from my OBi202 does not resemble that.