September 22, 2014, 05:12:37 am *
Welcome, Guest. Please login or register.
News:
 
   Forum Home   Search Login Register OBiTALK  
Pages: [1] 2
  Print  
Author Topic: Please give users a SIP address to receive calls via ObiTALK network  (Read 19187 times)
MichiganTelephone
OBi110 Beta Testers
***
Posts: 484


« on: February 19, 2012, 10:30:17 am »

I was wondering if it would be possible to add a setting in the advanced settings that would let you enable a SIP address that would allow incoming SIP calls to your OBiTALK number.  So, for example, if you check this box, any SIP call coming to your 9 digit OBiTALK number @obihai.com (e.g. sip:222222222@obihai.com) would come to your Obihai device via the OBiTALK network.  If you did not check the box then SIP calls to that address would be ignored (this is so only people who know what they are doing could enable this).

The reason for this is that then you could use an OBi device with a service like Tropo, which will transfer calls to a SIP address and provides DID numbers in many major cities around the world.  It would make the Obihai devices even more valuable, and I would think it shouldn't be that difficult to add.
« Last Edit: February 19, 2012, 10:34:12 am by MichiganTelephone » Logged

Inactive, no longer posting or responding to messages.  Goodbye and good luck.  Some of my old Obihai-related blog posts have been moved to http://tech.iprock.com - note this in NOT my blog; I have simply given the owner permission to repost some of my old stuff.
Stewart
Hero Member
*****
Posts: 1125


« Reply #1 on: February 19, 2012, 10:47:30 am »

I was wondering if it would be possible to add a setting in the advanced settings that would let you enable a SIP address that would allow incoming SIP calls to your OBiTALK number.
IMO, this would only be useful in rare situations, where other constraints preclude a more straightforward approach.

First, you can send SIP calls directly to the OBi (using a dynamic DNS name, if you don't have a static IP).  If that's not desirable, you can register to a SIP provider (Callcentric, VoIP.ms, etc.) that accepts calls via SIP URI.  Or, send the call to <your iNum>@sip.inum.net .  All of these are standards based (easier to debug), more reliable and don't necessarily involve proxying the media.
Logged
MichiganTelephone
OBi110 Beta Testers
***
Posts: 484


« Reply #2 on: February 19, 2012, 03:15:22 pm »

Stewart, why go out of your way to stomp all over someone else's request?  The situations where this may be useful might not be as rare as you think.

Sending calls directly to the OBi has a host of issues.  The first is that many OBi uses don't have a Dynamic DNS, don't know how to use it, or may have their SIP ports pointed to something else in their local network.  Also, there may be firewall issues, both at the user level and at the provider level (especially in certain countries).

If you already have both service provider slots in use (for example, for two Google Voice accounts) then using a SIP provider, even a free one, is not an option.

And how on earth will using an iNum help?  Unless the Obihai devices have some magical iNum support that we don't know about, the use of iNum won't help at all and just complicates matters.  Are OBiTALK numbers mapped to iNum numbers now?  If so, I guess I missed that announcement.

The reason I suggested this is that it would provide an EASY way to direct incoming SIP calls to a particular Obihai device, from providers have no facility for SIP registration (Tropo, for example) and/or in cases where you already have both SP slots in use.  Isn't part of the philosophy behind the Obihai devices to make things as easy as possible for the end user?

I do not appreciate your dismissive attitude.  If you don't need this feature or think you know of better ways to do it, fine, use what you know on your device.  But, you have no business saying that "this would only be useful in rare situations."  Did you do some actual research to back that statement up, or did you just pull it out of the nether regions of your posterior?

I would point out that Obihai has introduced several features that I happen to think would only be useful in rare situations, and that I don't personally use.  But obviously someone had a use for them, or they wouldn't have been implemented.  I happen to think this feature would get a lot of use, if only because it would be easier (for the user) to implement than any of the things you have suggested.  And it would make it easier for people to get DID's in parts of the world not covered by Google Voice.

Some people...   Angry
Logged

Inactive, no longer posting or responding to messages.  Goodbye and good luck.  Some of my old Obihai-related blog posts have been moved to http://tech.iprock.com - note this in NOT my blog; I have simply given the owner permission to repost some of my old stuff.
Stewart
Hero Member
*****
Posts: 1125


« Reply #3 on: February 19, 2012, 06:32:30 pm »

Obihai, like any company, has limited resources.  So, I'd like to see their enhancement efforts devoted to projects that provide the largest benefits to the most users, for a given cost.  That should increase product demand and Obihai profitability, and ultimately result in more ever-cooler products in the marketplace.

Accepting SIP calls on OBiTalk would be an expensive upgrade and also entail ongoing costs.  The present  reliability record for OBiTalk is less than stellar.  I also have some concerns about its proprietary protocol, privacy and security.

Let me ask a simple question:  If the OBi had SP3, SP4, etc., would you be asking for this feature?  Possibly you would still have a need, but IMO the vast majority of users would just register with Callcentric or one of the dozens of other free SIP registrars.  I don't know whether the lack of more SPx slots is merely a marketing decision by Obihai, or is imposed by storage and processing limitations in the device.  If the latter, I have a feature request:  Replace the dedicated OBiTalk Service slot with SP3, and have OBiTalk be an option for SignalingProtocol (where present choices are SIP or Google Voice).  That would allow e.g. two GV + one SIP, or vice-versa.

The first is that many OBi uses don't have a Dynamic DNS, don't know how to use it, or may have their SIP ports pointed to something else in their local network.
I agree that there are issues, but most modern routers, even ISP-supplied ones, have a dynamic DNS client, and you can set X_UserAgentPort (and e.g. Tropo) to use any available port on your network.

And how on earth will using an iNum help?
For example, Tropo -> 1777xxxxxxx@in.callcentric.com -> VoxOx iNum -> Your GV Number -> OBi.  Not the most reliable, poorly supported, but free.  IMHO, that's also true of OBiTalk.

Logged
MichiganTelephone
OBi110 Beta Testers
***
Posts: 484


« Reply #4 on: February 19, 2012, 10:07:17 pm »

Stewart, you know what I don't like about you?  It's that you ride in here on your high horse and presume to know what would "provide the largest benefits to the most users" when in fact you have no idea what that is.  Then you say "Accepting SIP calls on OBiTalk would be an expensive upgrade and also entail ongoing costs."  And just how on earth would YOU know THAT?  What is it that would make it so difficult and expensive for Obihai to accept SIP calls when virtually every other VoIP platform in the world (that hasn't been around since the "stone age" of VoiP) can do it?  You make blanket statements like this without a shred of evidence.  They are mere conjecture on your part, yet you expect us to take your word for it.  Well guess what, I don't.

I've been wondering just what your agenda is here, because most people wouldn't devote the amount of energy you have to shooting down someone else's suggestion, unless they were truly an ass OR they thought that if that request were implemented, it might reduce the chances that a feature they want might not be implemented sometime down the road.  Assuming you're not an ass, I get the feeling that what YOU want is for Obihai to implement additional Service Provider slots, and maybe you want others to pressure them to do that, so you don't want to see any other suggestions implemented that might be "good enough" for some of the rest of us.  Which, if true, is pretty selfish on your part, particularly if Obihai has a good reason for not implementing additional Service Provider slots (such as, not enough memory in the device).  The suggestion I have made would not require ANY additional memory in the device itself.  It would only require Obihai to configure their switch (the one that handles Obihai network calls) to accept incoming SIP calls and redirect them to the proper Obihai device.  Contrary to your beliefs, I doubt that this would be a difficult or expensive thing for them to do.  Neither one of us can speak from a position of authority here, but I'm sure Obihai doesn't need you to tell them if this will be too expensive or require too many resources.

People (including myself) have asked for additional Service Provider capability (see http://www.obitalk.com/forum/index.php?topic=141.0).  Obihai has, for whatever reason, chosen to ignore such requests (which makes me wonder sometimes if any Obihai developers actually read this forum).  If they the reason they have ignored such requests is due to memory or resource constraints, then what I have suggested would be an alternative that could at least satisfy some users.

Finally, you say that "The present  reliability record for OBiTalk is less than stellar."  Really?  I haven't observed that.  But then you would have me route calls through THREE other providers (Callcentric, VoxOx, and Google Voice).  Gee, ya THINK that might not be the most reliable?  What about latency, or the idea that a chain is only as strong as its weakest link? You basically allege that the OBiTALK network is unreliable and then offer an even LESS reliable alternative.  Your arguments don't even come close to being convincing.

Ultimately, it's up to Obihai whether they will act on this request, so why don't you just back off?  Feel free to propose the features you want (you could even add some support at the link I mentioned above, if you want additional Service Providers). But don't come in here and crap all over other people's requests.  Such behavior just might come back to bite you one of these days.
Logged

Inactive, no longer posting or responding to messages.  Goodbye and good luck.  Some of my old Obihai-related blog posts have been moved to http://tech.iprock.com - note this in NOT my blog; I have simply given the owner permission to repost some of my old stuff.
jimates
OBi110 Beta Testers
***
Posts: 1613


« Reply #5 on: February 19, 2012, 11:48:19 pm »

MT,
welcome back.
Logged
QBZappy
Hero Member & Beta Tester
*****
Posts: 2302



« Reply #6 on: February 20, 2012, 05:11:07 am »

MT
Yes indeed, welcome back.
Logged

Owner of the 1st OBi110/100 units in service in Canada & South America. 1st OBi202 on my street.
DaveSin
Newbie
*
Posts: 34


« Reply #7 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 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 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?
Logged
MichiganTelephone
OBi110 Beta Testers
***
Posts: 484


« Reply #8 on: February 20, 2012, 07:56:01 am »

Hi, jimates and QBZappy!  What you see here is a perfect example of why I tend not to post in forums much anymore.  There's always that guy…  Roll Eyes

But anyway, 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.  It's not the easiest service to set up (it's sort of designed for programmers, so you have to write your own script, although it can be in any of several supported languages and can be as little as one line of code to transfer the incoming calls).

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).

I already have access to an Asterisk server (actually two of them) that I could use to route calls between Tropo and an Obihai device, assuming I want to use one of my Service Provider slots on the OBi to connect to that server.  But that doesn't help most other folks, nor those who are already using both SP1 and SP2!
Logged

Inactive, no longer posting or responding to messages.  Goodbye and good luck.  Some of my old Obihai-related blog posts have been moved to http://tech.iprock.com - note this in NOT my blog; I have simply given the owner permission to repost some of my old stuff.
BobTeatow
Newbie
*
Posts: 26


« Reply #9 on: February 20, 2012, 08:18:19 am »

SP3,4,5 makes sense to me.  If the OBI device runs "out of gas" handling more than n calls, just have it signal busy at that point.  The interest here is not so much simultaneous calls, but being able to handle calls to/from multiple VOIP providers, choosing whichever has the best rates, reliability, quality, DID, etc...
Logged
MichiganTelephone
OBi110 Beta Testers
***
Posts: 484


« Reply #10 on: February 20, 2012, 08:19:02 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.

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.

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.
« Last Edit: February 20, 2012, 08:20:54 am by MichiganTelephone » Logged

Inactive, no longer posting or responding to messages.  Goodbye and good luck.  Some of my old Obihai-related blog posts have been moved to http://tech.iprock.com - note this in NOT my blog; I have simply given the owner permission to repost some of my old stuff.
Stewart
Hero Member
*****
Posts: 1125


« Reply #11 on: February 20, 2012, 09:40:38 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.
Logged
MichiganTelephone
OBi110 Beta Testers
***
Posts: 484


« Reply #12 on: February 20, 2012, 03:29:43 pm »

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).  Angry
Logged

Inactive, no longer posting or responding to messages.  Goodbye and good luck.  Some of my old Obihai-related blog posts have been moved to http://tech.iprock.com - note this in NOT my blog; I have simply given the owner permission to repost some of my old stuff.
jimates
OBi110 Beta Testers
***
Posts: 1613


« Reply #13 on: February 20, 2012, 03:55:03 pm »

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.
Logged
Stewart
Hero Member
*****
Posts: 1125


« Reply #14 on: February 20, 2012, 08:29:01 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.
« Last Edit: February 20, 2012, 08:33:44 pm by Stewart » Logged
jimates
OBi110 Beta Testers
***
Posts: 1613


« Reply #15 on: February 23, 2012, 09:02:30 am »

MT,
See txcas' post about sip calls coming in on the Obitalk network.
http://www.obitalk.com/forum/index.php?topic=2588.0
Logged
QBZappy
Hero Member & Beta Tester
*****
Posts: 2302



« Reply #16 on: February 23, 2012, 10:45:08 am »

jimates,

It looks like one person's problem is another person's feature request.
Logged

Owner of the 1st OBi110/100 units in service in Canada & South America. 1st OBi202 on my street.
jimates
OBi110 Beta Testers
***
Posts: 1613


« Reply #17 on: February 23, 2012, 01:16:26 pm »

and just where have you been lurkin' lately
Logged
MichiganTelephone
OBi110 Beta Testers
***
Posts: 484


« Reply #18 on: February 24, 2012, 03:55:20 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.

There's nothing "H" about your opinions.  You are trying to ram them down our throats, and trying to sell us bullshit and call it shinola.  The point is that we already HAVE the OBiTALK network — it's not like we'd need to add another provider that isn't there already.

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.

And how the hell would YOU know that?  You're just pulling "facts" out of your ass, with NOTHING to substantiate them.  You have NO WAY to know what the uptime of any particular provider has been, and when you try to tell me that someone's had 100% uptime, your credibility flies right out the window.  NOBODY has 100% uptime.  Servers crash, need to be rebooted, need to be pulled offline for maintenence… but hey, you'll just quote any old statistic that pops into your pea brain as long as it "proves" your point, won't you?

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.

How many users?  2? 5? 10? Just YOU that you know of?  I could as easily say that some users have had trouble with SIP and have found the OBiTALK network to be more reliable, and my guess is that might actually be true in some areas of the world where governments actually attempt to block the use of VoIP.  Maybe the OBiTALK network had not worked as well as YOU would like, but don't pretend that there number of people who have given up on the OBiTALK network unless you have some actual data in hand.  If you don't, then once again you're just pulling stuff out of your ass.

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.)

And in your world, what you believe = reality.  I will actually accept that there might be some truth to this but you're not in any position to say, and neither am I.  I'd at least like the chance to try it and see how well it works, before I say that it's going to be a major issue.  Again, keep in mind that we all have the OBiTALK network on our devices, so it's not as though we'd need an additional provider to be added.

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.

And I'll bet it really ticks you off when people don't want to follow your "advice."  Guess what — there are many people, particularly in today's economic climate, that DO want to make their money go as far as possible, and they would be perfectly within their rights to tell you to "fuck off" when you offer your unsolicited and unwanted advice.  You are not the ruler of the world, nor even an Obihai employee, so I don't know where you get off thinking that your opinion counts for any more than anyone else's.  Use your Obihai devices the way you want to, but don't expect everyone else to do as you do — your priorities and theirs may be quite different.  And when you tell other people what to do, they probably view you as some kind of buttinsky asshole, which would be the same opinion I've had of you since practically the start of this thread!

(I WARNED him, people — see my previous message!)
Logged

Inactive, no longer posting or responding to messages.  Goodbye and good luck.  Some of my old Obihai-related blog posts have been moved to http://tech.iprock.com - note this in NOT my blog; I have simply given the owner permission to repost some of my old stuff.
MichiganTelephone
OBi110 Beta Testers
***
Posts: 484


« Reply #19 on: February 24, 2012, 04:07:20 pm »

MT,
See txcas' post about sip calls coming in on the Obitalk network.
http://www.obitalk.com/forum/index.php?topic=2588.0

I think the thing that tickles me most about that thread is that the other person that this forum would be better off without was once again proven wrong, after acting so certain that he knew what he was talking about!

I'm guessing that whatever is happening there is something that the Obihai folks need to look into, but at the same time, if those calls really are originating outside the OBiTALK network and then being carried on the OBiTALK network, I'd love to know how they are doing it, so we could use it to our advantage (and also so that if there is a security hole of some kind, the Obihai developers could close it).  I hate it when some hacker can do to my advice what I want to be able to do, and he's not telling how he does it! (Hopefully that's not actually the case here).
Logged

Inactive, no longer posting or responding to messages.  Goodbye and good luck.  Some of my old Obihai-related blog posts have been moved to http://tech.iprock.com - note this in NOT my blog; I have simply given the owner permission to repost some of my old stuff.
Pages: [1] 2
  Print  
 
Jump to:  

Powered by SMF 1.1.11 | SMF © 2006-2009, Simple Machines LLC