Please give users a SIP address to receive calls via ObiTALK network
MichiganTelephone:
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.
Stewart:
Quote from: MichiganTelephone 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.
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.
MichiganTelephone:
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... >:(
Stewart:
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.
Quote from: MichiganTelephone on February 19, 2012, 03:15:22 pm
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.
Quote from: MichiganTelephone on February 19, 2012, 03:15:22 pm
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.
MichiganTelephone:
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.
Navigation
[0] Message Index
[#] Next page