reboot from AA

[HashJ]

Here's the situation...
The devices are remote. Power outage is frequent (the back-ups don't last long enough many times). When the power is restored, the Obi110 boots before router. This results in the device not connecting to the Obi network. HOWEVER, the GV accounts always come back up (happens with multiple remote devices at different locations and seems to be a consistent behaviour).
So now I can reach the Auto Attendant on these devices via the GV but cannot access them via the Obitalk portal. So if I could find a way to reboot these via the AA it would then connect to Obitalk network and I wouldn't have to depend on someone at the remote location.

All suggestions are welcome. Thanks!

[Stewart]

I haven't tried this, but you can probably set OutboundCallRoute for AA to have an entry for AA2; you could then dial 9 (and 1 to confirm) for a reboot.  If that fails, try a special entry in InboundCallRoute for the SPx in question, which routes directly to AA2 (you would spoof a special caller ID to trigger it).

If none of these work, set up a way to access the web interface of the remote OBi.  Simplest is to forward an obscure port and use a strong password.  For better security, use a VPN connection, or remote desktop to a machine at the site and run a browser there to access the OBi.

[RonR]

The following will allow access to the OBi's Device Configuration Menu from the Auto Attendant by dialing ***.  Configuration option 9 will perform a reboot after pressing 1 to confirm.  Password protection (PIN) will prevent use by unauthorized callers.

NOTE:  There is is bug in the OBi that causes the first configuration option entered which requires a PIN to be discarded.  The discarded configuration option will have to be entered again after entering the PIN.


Voice Services -> Auto Attendant -> DigitMaP:

([1-9]x?*(Mpli)|[1-9]|[1-9][0-9]|<00:$1>|0|***|**1(Msp1)|**2(Msp2)|**8(Mli)|**9(Mpp)|(Mpli))

Voice Services -> Auto Attendant -> OutboundCallRoute:

{([1-9]x?*(Mpli)):pp},{0:ph},{***:aa2},{(<**1:>(Msp1)):sp1},{(<**2:>(Msp2)):sp2},
{(<**8:>(Mli)):li},{(<**9:>(Mpp)):pp},{(Mpli):pli}

System Management -> Device Admin -> IVR -> Password : (numeric PIN)

[QBZappy]

HashJ,

I was thinking if your OBi had a static ip instead of dynamic (waiting for the router to assign an ip to the OBi) it might be possible to avoid this problem all together. It may not work, just something I would try.

Stewart/RonR
Rebooting the OBi via the AA could come in handy.

[HashJ]

Thanks all for the great suggestions. I will try these and post my results.
QBZappy, I had thought of doing something on the router, but I have very limited technical help at the remote locations... hence the inclination for the AA solution.

[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]

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]

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]

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}

[HashJ]

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}

That makes much more sense ... I had completely misunderstood the reason for the parens in the syntax. Thanks RonR.