Synchronization of device configuration with OBiTalk and OBiExpert Configuration
azrobert:
Quote from: cracker on March 06, 2016, 08:05:53 pm
Is it possible to change the calling feature settings using both star codes and the OBiTalk expert configurtion tool? If so, what procedure does one follow to push the settings from the OBiTalk tool to the device?
Make the following changes for the SP trunk you want forwarded:
Voice Services -> SPx Service
CallForwardUnconditionalEnable: Checked
CallForwardUnconditionalNumber: Forwarding_Number
You must uncheck both boxes to the right of the value to be able to change the value.
Click Submit
If you set the forwarding number to just digits, the Primary Route's trunk will be used to forward the number.
You can choose the SP trunk to forward the call by setting the forwarding number to sp2(8005551212)
Now the OBi will use SP2 to forward the call.
When you use a star code to set forwarding, I believe all trunks will be setup to forward calls. Using OBiTalk you will have to setup each SP trunk individually.
SteveInWA:
Quote from: azrobert on March 06, 2016, 09:18:27 pm
Quote from: restamp on March 06, 2016, 07:27:07 pm
Is it possible to cause an OBi to update its firmware remotely? The documentation claims that clicking on the orange triangle will do it, but it just takes me to a web page in this forum which describes the various options for how to upgrade. But, I wonder if there is a work-around: For instance, would it be possible for me to call into the remote OBi's AA1 and enter ***6 from there (probably after selecting AA1's option 2) to access its AA2 and upgrade the firmware? Any other ideas?
You can access the remote OBi's AA2 over the OBiTalk network.
Local OBi:
Define a speed dial: PP(123456789*0)
Change 123456789 to the OBi Number of the remote OBi.
This will send a zero to the remote OBi.
Remote OBi:
Voice Services -> OBiTalk Service
Add the following to the beginning of the InboundCallRoute:
{987654321>0:aa2},
Change 987654321 to the OBi number of your local OBi.
If the current inbound route is just "ph" it must be changed to "{ph}".
The above will check for a zero coming from your OBi and route the call to the AA2.
You don't need to enter the "***". You will receive a prompt for the AA2 options.
In 2014, Mark at Obihai posted an excellent explanation of the product design and support strategy that Obihai implemented, taking advantage of remote support capabilities for service providers and for consumers, via the OBiTALK configuration portal: http://www.obitalk.com/forum/index.php?topic=5084.msg56824#msg56824
Your many one-off configuration hacks demonstrate a lack of work experience and understanding of I/T configuration and service management: how to deploy and manage devices with consistent, reliable, repeatable processes that don't depend on someone remembering that they made a particular change to an advanced setting at some point in the past, on one or another of their devices.
In this case, OBiTALK configuration automatically changes that InboundCallRoute parameter when new devices are added to a user's portal account. By manually changing this parameter, you're interfering with expected/supported behavior; for example, the Link Devices setting.
The big-picture concept of systems management is always: simpler is better; complexity increases the potential for failure. It reduces future support hassles and reduces dependency on fallible human memory. When someone asks here, "How do I solve this problem?" the best answer is one that will fit the support strategy.
azrobert:
Steve,
My suggestion solved restamp's problem. How would you suggest fixing the problem? Oh, I forgot. You suggested having someone at the remote site enter the aa2 commands.
restamp said:
Quote
For instance, would it be possible for me to call into the remote OBi's AA1 and enter ***6 from there (probably after selecting AA1's option 2) to access its AA2 and upgrade the firmware?
If you are as uncomfortable with my suggestion as Steve then you can use the aa1 like you asked. Just define a speed dial at the remote site as "aa2()" without the quotes. I hate these 2 step solutions, so I would use my first suggestion.
azrobert:
restamp,
I'm curious if Steve is correct that my code would interfere with the OBi functionality. Could you or someone else test this for me? Just add the code in my Reply#15 and then see if it interferes with linking to the device.
I can't easily test because I don't use OBiTalk to configure my OBi's and have OBiTalk Provisioning disabled.
Thanks
restamp:
A couple things:
First, Steve, thanks for verifying to me that clicking on the orange triangle should indeed still download the latest firmware to the associated OBi. I suspect my problem is that I am accessing the obitalk.com web site from a fairly heavily locked down browser and between AdBlockPlus and NoScript it is preventing what I suspect is a Javascript hook from working correctly. I'll have to try it on a vanilla browser later, but I'm sure you will be proven correct.
Robert, thanks a million for your first suggestion -- it worked like a charm! I didn't bother trying to test your second option, but I'm delighted to have remote aa2 access to the OBis I maintain. (I keep a special folder in my browser just for retaining some of your more useful posts here because they contain such a wealth of information.)
Regarding the linking issue, I am probably not the best one to conduct this test as I go out of my way to avoid linking the devices I maintain and remove any such code when I find it. I should really have created separate accounts for each device, but it's just too handy to maintain them all under one account. The downside to this is that by doing so OBiTalk's intent of treating all registered devices as if they were related creates problems for me. For instance, before changing the InboundCallRoute as you suggested, it was (as set by OBiTalk):
Code:
{(500111111|501222222|501333333)>(xx.):SP1},{(500111111|501222222|501333333):aa},{ph}
This, I suspect, is part of the OBiTalk set-up to facilitate the linking of the devices. But, frankly, in my situation I don't want all the devices able to access each other in this fashion, so I elided everyone's OBiTalk number above except mine. That said, I don't quite understand how simply prepending your aa2 entry to the above sequence in any way corrupts the way it works. Perhaps Steve can comment further.
(And while we are on the subject of linking (or not linking), I *wish* there was a way of maintaining separate speed dials for each device instead of forcing everyone to share one set of speed dials. Even family members and business colleagues call different sets of people.)
Anyway, thanks again for a very useful thread.
Navigation
[0] Message Index
[#] Next page
[*] Previous page