Simplify the implementation of the "oleg method" {>('1777xxxxxxx'):ph1}
QBZappy:
Simplify the implementation of the "oleg method" via obi unit web configuartion pages.
{>('1777xxxxxxx'):ph1}
This method should be incorporated into the firmware in a similar fashion as the "ITSP Profile X->SIP->->X_AccessList".
It has been mentioned several times here and on other sites, that competing ATA products have this ablity while saying that the OBi units lack this ability.
The oleg method is not a work around. It is by design. 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 pertinent)
I see this as an easy fix not requiring much coding to implement as the feature itself is embedded in the firmware. This should be a selling point used by marketing to extoll the safety feature of the ATA.
(Tag: oleg method)
ianobi:
QBZappy,
I agree in principle that the "Oleg Method" should be incorporated into the firmware by default. However, there should be a check box to uncheck if we do not wish to use it on some specific spX's.
I use the Oleg Method on some spX's, but on others where I use "through-dialling" it's not possible to protect all rules with the Oleg Method. Consider:
Voice Services > SP2 Service > X_InboundCallRoute:
{(Mcot)>(Msp1):sp1},{(Mcot)>(<**2:>(Msp2)):sp2},{(Mcot)>(<**8:>(Mli)):li},{(Mcot)>(<**9:>(Mpp)):pp},{(Mcot)>**0:aa},{>1234567:ph}
Only this rule {>1234567:ph} uses the Oleg Method. All the other rules depend on CallerID for protection with the allowed CallerIDs stored in "cot". The other rules need the callee section to detail the allowed numbers that may be called on that route, so the callee section cannot be used for the Oleg Method.
Anyhow, I'm really a +1 for your request so long as there's an opt out!
gderf:
How does X_InboundCallRoute >('1777xxxxxxx'):ph1 differ from {>1777xxxxxxx:ph} ?
I have X_InboundCallRoute {>1777xxxxxxx:ph} in mt SP2 for Callcentic and I didn't put it there, if was done automatically via OBiTalk on my OBi200.
QBZappy:
Ian,
Quote from: ianobi on November 25, 2013, 08:47:12 am
However, there should be a check box to uncheck if we do not wish to use it on some specific spX's.
Yes, indeed. My example using the "ITSP Profile X->SIP->->X_AccessList" was intended to illustrate that it could be a configurable control as opposed to being hard coded into the firmware. It is interesting to note that I have never read a report of spam calls coming over the OBiTALK service. Obihai itself is more than likely using some form of spam blocking. It would be nice if they could share their approach. If it is one of several approaches already mentioned on this forum, it would be comforting to know.
QBZappy:
Quote from: gderf on November 25, 2013, 08:58:37 am
How does X_InboundCallRoute >('1777xxxxxxx'):ph1 differ from {>1777xxxxxxx:ph} ?
I used it as an example to illustrate. It seems the use of ( and ' is optional.
Quote from: gderf on November 25, 2013, 08:58:37 am
I have X_InboundCallRoute {>1777xxxxxxx:ph} in mt SP2 for Callcentic and I didn't put it there, if was done automatically via OBiTalk on my OBi200.
??? Since when is this being set up automagically via OBiTALK?
Edit: I changed the example to make it more clear.
Navigation
[0] Message Index
[#] Next page