Direct IP calls
N2VWZ:
Quote from: QBZappy on November 19, 2013, 08:22:14 am
@N2VWZ
Beg to differ. There are several ways to avoid the problem you mentioned using the OBi. Have a look here for details.
(Credit to Shale) Summary of various methods mentioned by various posters on this forum
HOWTO: Thwarting SIP Scanners during Set-up
http://www.obitalk.com/forum/index.php?topic=5467.0
The best method IMO is the oleg method because it is simple and easy to set up. I think one of the methods could be used with direct ip calls.
I shouldn't need a workaround for poorly written firmware.
Only the phone number that I assign to the ATA should allow the box to ring - this is the behavior that is expected. Unless the firmware has been fixed in the last year,the Obi ATA will ring on any number that is dialed to my IPAddress:port. Sipura and Cisco ATAs ring only on the assigned number as expected.
The Obi ATAs ring on all numbers because there is no assigned number filtering in the firmware. This is an Obihai firmware design flaw that needs to be fixed.
I gave up trying to get the Obihai ATAs to work properly with unregistered Direct IP Dialing and have been successfully using a Sipura SPA2000 that I bought on Ebay for $20 new.
giqcass:
We all agree some things should be simpler.
However,
The Obi kicks the other ATAs butts. It's a little too complicated for some people but when set up properly it has endless possibilities. Toss one line in and you can limit income calls to the Obi.
{>17771234567:ph}
Then replace 17771234567 with your auth username or add multiple user names for multiple incoming accounts. Please tell us something The Sipura SPA2000 does that Obi doesn't do.
QBZappy:
@N2VWZ
Quote from: N2VWZ on November 24, 2013, 08:03:01 pm
I shouldn't need a workaround for poorly written firmware.
The oleg method as highlighted above by gigcass is not a work around. It is by design. I agree that this feature is not integrated into the obi settings as well as competing products. It took a professional software engineer (oleg) to interpret the admin guide and to come to a solution equivalent to Sipura / Linksys adapters. This detail even escaped RonR who had come up with most of the other methods via crafting special dial plans. It did not even occur to obihai themselves to suggest this solution. I'm surprised that obihai has not simplified this control by implementing it on the configuration pages of the unit. This should be a feature request.
You can follow this thread from here to see the dynamics of how it came up:
http://www.obitalk.com/forum/index.php?topic=4067.80 (Reply 100 and 101 are especially pertinant)
MikeHObi:
Quote from: QBZappy on November 25, 2013, 07:16:19 am
@N2VWZ
The oleg method as highlighted above by gigcass is not a work around. It is by design. I agree that this feature is not integrated into the obi settings as well as competing products. It took a
I just reviewed the oleg method and the thread on sip scanners. I was curious because I hadn't been having an issue. Then I went and looked at my Expert Config for Obi and found that my inbound call route for both Anveo and Callcentric (both set at ObiTalk defaults) are setup for the oleg solution.
Anveo looks like this.
{>7XXXXXXXXX:ph1,ph2}
Callcentric looks like this.
{>1777XXXXXXX:ph1,ph2}
Seems Obihai has made that setup a default because I've never set it up that way.
QBZappy:
@MikeHObi
Yes, it was first noticed in this thread recently. It was quietly implemented by obihai.
Re: Simplify the implementation of the "oleg method" {>('1777xxxxxxx'):ph1}
http://www.obitalk.com/forum/index.php?topic=6976.msg44083#msg44083
Navigation
[0] Message Index
[*] Previous page