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,

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]

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.

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.

[gderf]

I can't tell you when this started being set up automagically via OBiTALK, but I just deleted that SP and X_InboundCallRoute was set to ph.

Then I used OBiTALK to set up that SP again for Callcentric and now have X_InboundCallRoute {>1777xxxxxxx:ph}

So, it looks like the OBiTALK folks are on top of this already.

[QBZappy]

I can't tell you when this started being set up automagically via OBiTALK, but I just deleted that SP and X_InboundCallRoute was set to ph.

Then I used OBiTALK to set up that SP again for Callcentric and now have X_InboundCallRoute {>1777xxxxxxx:ph}

So, it looks like the OBiTALK folks are on top of this already.

This implies that obihai has given it its seal of approval since they implemented the oleg method as "THE" spam solution themselves. This is yet another reason to simplify the implementation of this feature in the ATA itself. I can see obihai claiming that they have simplified it already as evidenced by gderf, since the inbound call route is set up in that way when selecting CC. I think it is safe to assume that every voip service provider listed on the obihai list of supported providers paid to be on that list. For every other voip service provider the simplicity of setting this up is simply not there. From my perspective as an end user, I would like it to be an obvious generic setting as opposed chalking one up to the learning curve.

[ianobi]

I have tested this further using two "Generic Service Providers". I deleted sipgate.co.uk and sip2sip.info.

When I set them both up again, OBiTALK took whatever was input as "User Name" and used that to implement the Oleg Method. This assumes that you have the OBiTALK checkbox checked for each InboundCallRoute. (This is the default setting).

Looks like Obihai do read this forum. I hope that they have put Oleg on their Christmas card list   

[QBZappy]

Ian

It is good to see obihai reads the forums. I still think that this setting also belongs on the ATA as well because it creates a disconnect between how the devices are configured. It is not intuitive if the portal configures the unit one way and there does not seem to be a corresponding behavior via the unit web page. The portal should mirror the abilities of the unit and visa versa, otherwise it creates needless confusion. The litmus test of a feature should be a simple + or - analysis of value added preferably based on need, and then mirror the portal and web unit abilities since obihai decided to to offer dual configuration portals (one local, one external).

The big disconnect very apparent to me at this point is that obihai does a very poor job of explaining any improvements/changes to the product. What's new about that! The culture of obihai shows that the software engineers and the marketing people don't seem to be talking to each other. Who's job is it anyways to do the marketing of these products? They really, really need to improve in the communications dept. Hire someone to tie up this loose end. This position will have a positive ROI and won't cost anything to obihai in the medium/long term. This should be a feature request! I don't see anything positive in a strategy of keeping mum on product enhancements. This is very un-American.

[ianobi]

The big disconnect very apparent to me at this point is that obihai does a very poor job of explaining any improvements/changes to the product.

Everyone reading this thread will be nodding their heads and asking why do we need to experiment to find out these things?

Obihai have a good product, then they make it better and they don't tell anyone about the improvement. Beats me   

[giqcass]

I have noticed some of this stuff does eventually make it into the user manual but that document is quite long and we shouldn't need to dig through it for changes.