Simplify the implementation of the "oleg method" {>('1777xxxxxxx'):ph1}
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:
Quote from: gderf on November 25, 2013, 09:27:57 am
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:
Quote
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 ???
Navigation
[0] Message Index
[#] Next page
[*] Previous page