HOWTO: Thwarting SIP Scanners during Set-up
pointpeninsula:
Hello all, another newbie here.
I realize this thread is getting old, but as I'm just now transitioning from GV to Anveo, I've run into this problem. Many thanks to you all for the help, and with luck I'll get a good night's sleep without unplugging the phone.
I do have one question, though. I've implemented the #3 solution (X_InboundCallRoute method), and nowhere in the allowable syntax for digitmaps can I find a single '>' symbol used. Can anyone explain how that's used as a prefix to the AuthUserName?
Another comment: Nowhere in the manual, or online, have I seen the admonition that you can change these settings with the webserver built into the unit on the local IP address until your fingers fall off, but the variables will always revert to the default. The expert configuration must be done on the Obitalk web site. It seems odd that it should be the case, but Obihai's support folks told me that outright, and by experimentation, I've found it to be the case.
I emphasize this as a warning to other newbies as GV is turned off.
Thanks again,
Tom
Mango:
I believe the InboundCallRoute syntax is described here: http://www.obihai.com/OBiDeviceAdminGuide#_Toc367543130
Specifically, the > character is used in a peering-list to denote a callee-list.
With regards to a post earlier in the thread: while the Oleg method may make your device perform properly if in DMZ, it will not fully protect your device like a properly-configured firewall would. For example, your device could still be brute forced if it is in DMZ.
Terry:
Quote from: pointpeninsula on April 30, 2014, 07:26:41 pm
Another comment: Nowhere in the manual, or online, have I seen the admonition that you can change these settings with the webserver built into the unit on the local IP address until your fingers fall off, but the variables will always revert to the default. The expert configuration must be done on the Obitalk web site. It seems odd that it should be the case, but Obihai's support folks told me that outright, and by experimentation, I've found it to be the case.
If I understand what's going on with Obi's "preferred" providers and their special offers, they are controlling things via "provisioning" to make sure that well-meaning customers don't change something inadvertently and cause them (customer and provider) frustrating and expensive service calls. The provisioning does seem to assert more control over settings than, say, GV used to have.
On that subject, if the setting Anveo (for example) "provisions" to my Obi is allowing the annoying sip scanners in, even though Anveo can't control what the scanners do, since they CAN and DO control the settings of my Obi through their provisioning, and since there is a simple and working way to reject the sip scanner calls, I think it is perfectly logical to blame Anveo for the sip scanner calls getting through, since it is THEIR setup that is leaking.
If they are going to have that much control over my device, they need to take more responsibility. And, hey, since the solution is simple and therefore inexpensive (or free) to implement, just set it up in the provisioning. No excuses.
drgeoff:
Quote from: pointpeninsula on April 30, 2014, 07:26:41 pm
Another comment: Nowhere in the manual, or online, have I seen the admonition that you can change these settings with the webserver built into the unit on the local IP address until your fingers fall off, but the variables will always revert to the default. The expert configuration must be done on the Obitalk web site. It seems odd that it should be the case, but Obihai's support folks told me that outright, and by experimentation, I've found it to be the case.
So you haven't noticed the fourth 'sticky' at http://www.obitalk.com/forum/index.php?board=1.0 with the title: "Managing Your OBi Device Configuration: OBiTALK or OBi Web Page but NOT Both".
And the last 'sticky' at http://www.obitalk.com/forum/index.php?board=3.0 has the same title and is a link to the one above.
It is quite simple to make configuration changes using the OBi's built-in web pages and not have them reverted back by the OBiTALK portal.
dconway:
I recently switched to PhonePower (with the whole Google Voice deprecation of XMPP) and am having trouble with back to back SIP scanner calls coming from "2001" on my callerID. I want to use "Oleg's Method #4" from this thread but the AuthUserName is blank in ObiTalk portal (whereas for a service like Callcentric you have a clear ID typically beginning with 1777...).
Anyway, when I log into phonepower portal, there's an option to turn on SIP credentials but there's a massive disclaimer about risk (quoted below) and they will disable features like international dialing.
Does anyone know what value I need to subsitute for {ph}in X_InboundCallRoute to get "Oleg's Method #4" to work with PhonePower? Thanks for this great thread and for any help you can provide.
Quote
SIP Credentials
Your SIP Credentials are currently not enabled. SIP Credentials are designed for advanced users. Customers with SIP Credentials enabled have a limit of 4 registrations and 2 total concurrent calls. Disabling your SIP Credentials will remove these restrictions.
By choosing to enable your SIP Credentials you understand that Phone Power will not offer any technical support for your hand-configured device(s). Phone Power will continue to offer normal support for all auto-provisioning devices, including Phone Power supplied phone adapters, softphones, zippyphones, BYOD devices that use Phone Power’s auto provisioning system, etc. If you are unable to configure your device(s) yourself, please deactivate your SIP Credentials and contact support.
After enabling your SIP Credentials, you will need to reboot all devices connected to the Phone Power network. This includes rebooting Phone Power supplied adapters, softphones, zippyphones, BYOD devices that use Phone Power’s auto provisioning system, etc.
Navigation
[0] Message Index
[#] Next page
[*] Previous page