reboot from AA
QBZappy:
This is a good example of where a VPN client, such as OpenVPN, built into the OBi would make it possible to issue ip addresses from the local router based VPN server.
Going off topic, people considering sending OBi units to family members as a gift may want to consider sending them an inexpensive router as well. The router could be compatible with alternative firmware like Tomato. Setup the OpenVPN client on the router and ship it off with the OBi. Configure the router with a Dyndns account and you will be able to control the router and the OBi. This would also overcome any NAT issues between the two end points, and encrypt the calls.
Let us know how it goes.
HashJ:
Update:
I tried the code given by RonR and it worked like a charm. Thanks!
Then I tried the alternative suggested by Stewart to have an inbound call route directly to AA2. This was not successful. The log showed the correct number registered in the caller ID but device did not route it to AA2. (Could this be a security feature? :)
I like QBZappy's suggestion to send a pre-configured router with the device. Some good basic routers are available for less than $30.... Something to consider for the future.
RonR:
Quote from: HashJ on April 09, 2012, 04:38:46 pm
Update:
I tried the code given by RonR and it worked like a charm. Thanks!
Then I tried the alternative suggested by Stewart to have an inbound call route directly to AA2. This was not successful. The log showed the correct number registered in the caller ID but device did not route it to AA2. (Could this be a security feature? :)
It works as expected here using the following InboundCallRoute rule:
{12341234567:aa2}
where 12341234567 is the CallerID to be routed to the Configuration Menu IVR.
HashJ:
Quote from: RonR on April 09, 2012, 05:43:36 pm
It works as expected here using the following InboundCallRoute rule:
{12341234567:aa2}
where 12341234567 is the CallerID to be routed to the Configuration Menu IVR.
I have the rule as {x.2341234567:aa2} and it is still not working. The next rule in sequence gets triggered. I know that the InboundCallRoute function itself works correctly because I have been able to trigger the rule before and after this rule by creating the required conditions. I will try replacing the x. with a 1 and see if that works.
Update: The 12341234567 worked but the x.2341234567 did not work in this case.
But please note, the very first rule in my InboundCallRoute has various other numbers defined as x.1234567890 and that works. So apparently the x. works only in the very first rule in the InboundCallRoute but not in subsequent rules?
RonR:
Quote from: HashJ on April 10, 2012, 05:08:55 am
I have the rule as {x.2341234567:aa2} and it is still not working.
For the rule above to match, the CallerID would literally have to be : x.2341234567
If you're wanting to match a CallerID ending in 2341234567, the rule needs to be : {(x.2341234567):aa2}
Navigation
[0] Message Index
[#] Next page
[*] Previous page