SIP scanners
Mango:
1) When considering the InboundCallRoute, the string to the left of the colon is known as the "peering-list". This takes the format: caller-list > callee-list
In this case, the AuthUserName would be considered the "callee". Does this answer your question?
2) I believe you're correct.
oleg:
I think many questions were already answered, will try to clarify some...
Early suggestions (in this thread) to block scanners were based on matching caller. Caller is a string sent by calling party, that's how it represents itself. Provided that normally you receive calls with valid 10 digits caller id and that scanners use something like "10001", "admin", etc. you can filter them out. But what if scanner uses a right pattern? Your OBi will ring the phone...
My idea was to use callee id instead. The way is documented in Inbound Call Route part of OBi manual (may be lacking more examples). Most of us use one or several providers, may-be receiving direct SIP calls - pretty much determined set of valid strings. All other calls may be dropped. That's what I made.
BTW, old good Sipura / Linksys adapters allow the only user_id, any call not matching it does not ring.
>('myname'|123456@.):ph1
This is to allow incoming calls to myname@myhost (direct SIP calls) and 123456_me@myhost (voip.ms pattern, all sub-accounts have the same prefix), forward both to ph1 (I do not use ph2 now) and disregard all other calls. Note that you may receive SIP calls from several providers on the same SPn, that's why you may want to combine several patterns. You need separate SPn only if you want to register with several providers.
>('1777xxxxxxx'):ph1
This should work for Callcentric, but I believe you may remove quotas and even parentheses.
>>> Aside from the nerdiness what advantage does one gain using SIP URIs vs the traditional way...
It may be independent from any provider (sometimes more reliable), completely free, always the best quality (direct traffic)... Not something necessary though...
>>> 3/20/2013 2:19:10 AM INVITE sip:+972592280470@12.34.56.78:5078 SIP/2.0
This is from syslog. I have it enabled on OBi, most verbose and sent to the server.
QBZappy:
Brilliant. This should put an end to sip scanners as long as they don't use the same service provider that you use. Then what would be the odds of that.
Don't you just hate it when you read something and say, why didn't I think of that!
Worthy of a sticky indeed.
lacibaci:
I tested {>(1777xxxxxxx):ph} (without quotes) and it works. I also reverted back to port 5060 and enabled syslog. I'm hoping to see a lot of messages like this:
SIP DLG reject: 486
Then I'll know it's working :)
Lac
oleg:
Quote from: QBZappy on March 21, 2013, 09:21:35 pm
This should put an end to sip scanners as long as they don't use the same service provider that you use.
Scanners do not use service providers, they are trying to establish direct SIP call and trick your device to allow them pass through. Like place international call in the example above. In simple case with VOIP adapter it may ring your phone (in the middle of night >:(). If you allow pass through (like calling from soft OBi to your home OBi and than into another trunk) - you have to be very cautious.
Quote from: lacibaci on March 22, 2013, 06:14:11 am
SIP DLG reject: 486
This also happens when your line is busy :-)
Navigation
[0] Message Index
[#] Next page
[*] Previous page