Please give users a SIP address to receive calls via ObiTALK network
MichiganTelephone:
Quote from: DaveSin on February 20, 2012, 07:55:16 am
I'm amaze how individuals can be unnecessarily rude . First Michigan Telephone had issues with RonR and now Stewart, two of the most helpful individuals on this forum.
I have said both publicly and privately that my issue with RonR is that in my opinion he is the stereotypical forum "know-it-all" that jumps in to answer every question before anyone else can get to it, often gives questionable advice, and gets really put out if you dare to question his advice — and had he just chosen not to reply to my posts (because he should have realized at some point that I didn't think much of his advice) we likely would not have had an issue. Still, I did have a problem with him pouncing on newbies and insisting they do things his way, even when his way was more complicated than it should have been.
I've never had an issue with Stewart before, and frankly was surprised that he would go out of his way to crap all over someone else's suggestion, especially with a bunch of totally unfounded statements that he must have expected me to just swallow as factual.
Quote from: DaveSin on February 20, 2012, 07:55:16 am
I personally think Stewart made some valid points as it relates to the issue of allocation of resources and prioritizing of feature request. I too think the addition of SP3 and possible SP4 would be a great feature. If I not mistaken, those capability is available through the OBiPLUS beta test program, so, it is quite doable if Obihai Technology chooses to extent outside of the OBiPLUS beta.
I wish that if possible they would extend this capability to all Obihai adapters. However, I just don't see where this is such a huge "allocation of resources" issue. Unless Obihai wrote their switching platform from scratch, it probably has the ability to handle SIP traffic built in, and all they need to do is enable it. I'm not saying it would be a ten minute job (though it might be) but I don't think we are talking days or weeks of R&D here.
Quote from: DaveSin on February 20, 2012, 07:55:16 am
I think MT could challenge Stewart's positions without be rude and overly aggressive, after all, we all like and support the OBi ATA and think it is the best ATA device on the market. Having Stewart participating on this forum only add values IMHO. BTW, I thought MT wasn't going to participate in this forum anymore? At any rate, I hope you are back for good and will continue to support the overall development of the OBi ATA. Your initial write-ups on the device have been a big plus, however,........can we all just get along?
See, this is my problem with this forum. If don't put up with the crap these "fine gentlemen" sling out, then you call me "rude and aggressive." Well maybe I am at times, but I am not going to suffer in silence when people are trying to pull the wool over my eyes. I don't put up with sh*t out of anybody and if people can't take it then perhaps that's a good reason I shouldn't participate in this forum. Thanks for reminding me that I had said that; this thread shows exactly why I made that decision and should have stuck to it.
Just be aware, though, that when you let one or two individuals develop a "personality cult" on a forum, it tends to shut out others who may have equally valid ideas. If that's what you folks want, then have fun in your little garden where the people who post the most are automatically given the status of "expert", whether they deserve it or not. In my experience there is not a correlation between quantity of posts and quality of posts, but apparently some folks don't view it that way.
Stewart:
Quote from: MichiganTelephone on February 20, 2012, 07:56:01 am
... one of the reasons I had suggested this was the possibility that if calls from a service such as Tropo could be received on the Obihai device, it might enable some Obihai users to get a number in Canada, or in certain other major cities around the world. With Tropo a "developer account" is free, but at some undefined usage level they may ask you to move to a commercial account.
...
The idea is similar to what I wrote about in this article except that instead of sending the calls to an Asterisk server, my thought was there ought to be some simple way to send them to an Obihai device (and by simple, I mean not having to route it through two or three other additional providers that really don't need to be in the call path, in addition to being simple to configure).
In the specific case of Tropo used in a simple routing/forwarding application, with their present pricing, it doesn't matter whether the outbound leg goes to a SIP URI, an iNum, or a US PSTN number. On a developer account, all three are free. On a commercial account, all three are $0.03/minute. I asked about that, as well as developer account permitted usage; the query received a precise official reply -- see https://www.tropo.com/account/tickets/tickets.jsp?bb-cid=100&bb-tid=1652350&bb-name=tropo_support
IMO, someone who does not have an available SPx on his OBi is almost certainly registered with at least one provider that will accept calls by SIP, iNum, or on a US number.
If you don't have an available SPx to register with a DID provider, Canada DIDs are still quite inexpensive, e.g. Anveo "Personal Unlimited" at $2.45/mo. (forwards free to SIP URI) or Localphone at $3/mo. (forwards free to iNum).
If you post a specific example where you feel that a SIP->OBiTalk gateway would be a big help, I'll try to come up with a decent alternative.
MichiganTelephone:
Stewart, you are like a dog with a bone. Let it go already!!!
I don't know why the f--- you keep talking about iNum. iNum is totally irrelevant to this, plus, nobody uses it. It's one of those bright ideas that someone had that never really panned out. The Obihai devices do not support iNum and neither does the Obihai network. So STFU about iNum already!
The reasons for not wanting to forward to a U.S. number could be many. If nothing else, it adds latency, and takes the call off-net (which means somebody, somewhere, has to pay for the call). In the specific case of Tropo, my suspicion is that they'd be a lot more concerned about someone using a free developer account to transfer calls if those calls were going out over the PSTN and costing Tropo money.
And anyway, the big idea here is to NOT involve additional third (or fourth or fifth) parties in the call. The more you do this, the greater the likelihood that call quality will go to hell in a handbasket.
The idea here is that the call would come direct from Tropo (or some other provider that does SIP forwarding) and come to your Obihai account. This means you do not have to use any of your SP slots, do not incur the extra latency of going through multiple providers, and don't have issues with firewalls that might block direct SIP calls. I don't know how much clearer I can make it. Your multiple (and increasingly redundant) suggestions don't accomplish those goals.
You want a specific example, show me how to route a call from Tropo to an Obihai device WITHOUT doing ANY of the following:
1) Touching the PSTN in any way (this is a HUGE no-no for me, both for technical/quality reasons and because philosophically I'm opposed to seeing a phone company get any money for a call leg that should be able to be completed over the 'net),
2) Using one of the two precious SP slots,
3) Using iNum (even if Tropo uses it, there's no way to directly route it to the Obihai device, so it's a non-starter).
4) Adding additional services in the chain of the call that increase the latency, increase the likelihood of packet loss, and could go down without notice (again, the "weakest link" principle).
5) Getting blocked by a user's (or in some cases perhaps even an ISP's) firewall (Obihai devices already connect to the OBiTALK network, and may even be able to receive calls that way when regular incoming SIP calls would fail).
You can't do it so please STOP. We already know you want additional SP slots and many of the rest of us want them too, but unless and until Obihai gives them to us, why can't we seek an alternative that might at least work from some of us? You don't have to like it but frankly I think all the solutions you've proposed so far suck, and I doubt you're going to come up with anything that would work well that does not require the use of at least one SP slot or adding an extra carrier into the call. Why do you persist in dragging this out when your posts aren't accomplishing a thing, except perhaps making me angry enough that my next post just might contain some serious profanity directed toward you, if you don't lay off (or at least come up with something original that actually meets the conditions I listed above). >:(
jimates:
Quote from: Stewart on February 20, 2012, 09:40:38 am
If you post a specific example where you feel that a SIP->OBiTalk gateway would be a big help, I'll try to come up with a decent alternative.
Why do you always have to try to come up with an alternative to everything people want. The only time you give a straight answer or advise is when there is no alternative. If an alternative exists you are for sure going to point it out. Not everyone wants to have the call forwarded through multiple providers just because "it can be done".
I use both SP1 and SP2 for google voice, and another feature that would take minimal configuration to expand on the usable services that avast our world would be more than welcome.
Stewart:
Quote from: MichiganTelephone on February 20, 2012, 03:29:43 pm
... the big idea here is to NOT involve additional third (or fourth or fifth) parties in the call. The more you do this, the greater the likelihood that call quality will go to hell in a handbasket.
I agree completely. However, you are asking to do exactly that, i.e. use OBiTalk as the third party. And, IMHO, it's not a very good one.
1. Since the beginning of this year, OBiTalk has had at least two unplanned outages, plus several hours of scheduled maintenance downtime. http://www.obitalk.com/forum/index.php?topic=2246.0 http://www.obitalk.com/forum/index.php?topic=2403.0 . Sure, that's not the worst record in the league, but users who had interconnected their OBi devices with e.g. Callcentric or Anveo have enjoyed 100% uptime.
2. Some users have had troubles with OBiTalk, probably caused by their firewall or other network element. Unfortunately, the proprietary nature of the protocol makes troubleshooting very difficult; most of them simply gave up and now use SIP or another alternative.
3. Without future enhancements to protocol and firmware, I believe that an OBiTalk relay would have to proxy the media, adding latency. (I don't have any knowledge of the protocol; this is based on observations of RTP being relayed via OBiTalk servers.)
I view VoIP as a way to obtain high-quality, reliable, full-featured and well-supported communications at reasonable cost, not as a way to squeeze out the last nickel. So, it's puzzling when so many users put two GV accounts on one OBi. I understand that many need two GV numbers (usually, it's husband and wife or home and business). My typical advice is to put the "main" GV account on the OBi directly, and have the other ring in via a SIP provider. That way, you can have 911 service, a backup provider, use additional providers for international calling, receive calls via gateways in many countries, etc. The user then complains "but I need to be able to send either of our caller IDs on outbound calls." I reply "well, send the secondary account calls via the SIP provider." "No, that costs money, and we use both lines a lot." "You're designing a new system and expect heavy usage, yet don't provide a way to make or receive a call while your wife is on the phone??" There are many good solutions; a simple one is two OBi devices with one GV account on each; this works well with a two-line multi-handset system, separate phones, or an IP phone system.
Navigation
[0] Message Index
[#] Next page
[*] Previous page