Defective Obihai?

[johnny.medellin]

Hello, I have a pair of Obi110 units. One unit I have in the USA and the other one in South America-Colombia.
I don't have them "linked" I just keep them independent of each other. The one that's overseas has been giving me some problems, I have it connected to a landline and when it rings it's suposed to call my GVoice number. It does sometimes, sometimes it doesn't. When I call the GV # associated with it, it picks up sometimes, and sometimes not. When I manage its web portal (through a PC that's on its network and to which I VNC from the US) it works ok simetimes , but then sometimes I get a "cannot connect" error (its random when it works or doesn't). FYI I set a static IP address for it.
Also, to test it out, I saved its config file and loaded it onto my other unit (here in the US) and everything works just fine. I know that being overseas might be the problem, but then why would it work only sometimes?
FYI, people in my house overseas can use their own GV numbers to call me through either Sipgate or Gchat without using proxies. Also, I used to have a PIAF system on that same network that managed those same GV numbers and always worked. I'm thinking this unit can be defective, but wanted to see if you have any other opinions or hints before I send another one.
Also, these on-off problems happen regardless of whether the internet is being used by someone else or not, again, I managed all my calls with a PIAF system for years before. Another piece if info: when the calls do get through, often the voice cuts off, I can hear them fine, but they cannot hear me there
Thank you.
John M

[QBZappy]

johnny.medellin,

Hi, since you are managing both units why don't you put both units in the Circle of trust (COT). The COT uses the OBi servers to overcome NAT issues, if this is indeed the problem you are experiencing. You can call them using the OBi tel #.

It sounds like you are only using GV accts. Is that correct, no SIP SP? I assume you have separate GV accounts on each OBI.

Something came up recently in the call behavior of my Granstream PBX. I could receive calls, however my outgoing calls were not passing over my SP. For some reason ougoing calls started going out using a different codec not supported by the SP. Make certain that the same codec is being used on both sides. Start trouble shooting by setting codec only to G711U on each OBi.

By the way, it is more efficient to go directly into the OBi unit web page directly instead of going throught the other computer via VNC. Change the web port number on the OBi unit from 80 to say 90, and change the port forwarding on the router to point to the static IP of the OBi unit. Any reason you do not use the Expert Configuration method on the OBiTALk web site?

If you have a fixed ip or dyndns service you can consider direct ATA to ATA connection strategy as proposed by Oleg in this post. This too will resolve NAT issues. (if that is the issue)
http://www.obitalk.com/forum/index.php?topic=954.msg0;topicseen#new

When I call the GV # associated with it, it picks up sometimes, and sometimes not. When I manage its web portal (through a PC that's on its network and to which I VNC from the US) it works ok simetimes , but then sometimes I get a "cannot connect" error (its random when it works or doesn't).

"cannot connect" error. This is a VNC error message? You lost internet connection to the PC?

Another piece if info: when the calls do get through, often the voice cuts off, I can hear them fine, but they cannot hear me there

Can you make good 2 way calls sometimes?

____________
Since you can VNC into the other computer, you might consider installing a vpn service called Hamachi on each end. When both computers have proper internet connection you can see green light on the Hamachi panel indicating your VPN connection status. Next time you see that you can not make call or something unusual happens have a look at the green light. You will be able to confirm that the internet connection on the other end was interupted. This might give you some clues.

[RonR]

The COT uses the OBi servers to overcome NAT issues, if this is indeed the problem you are experiencing.

QBZappy,

Are you sure about this?  All OBiTALK calls (and only OBiTALK calls) go through the OBiTALK server regardless of whether any COT is in effect or not.  None of this is documented, but I suspect the servers are used only for call establishment via SIP and the audio is peer-to-peer RTP.  It's always been my understanding that COT is strictly CallerID matching in the OBi's OBiTALK Service InboundCallRoute and that's the extent of COT.  Do you have some information or evidence otherwise?

[QBZappy]

RonR,
Hi,

This was lifted from the OBI FAQ:
"OBiTALK is a web portal and OBi configuration utility which helps OBi users configure devices and access applications. OBiTALK is also where users set-up Circles of Trust which provide a means to network groups of individuals so that calls can be made as inexpensively as possible."

The above statement kind of implies that COT can facilitate a connection between 2 or more Obi's without having to worry about NAT issues. The OBi servers are there to offer this service. Without it, there is no COT ability.

The COT uses the OBi servers to overcome NAT issues, if this is indeed the problem you are experiencing.

COT+ OBi server = NAT traversal solution, is a fair comment to make. "COT is strictly CallerID matching",  is also a fair comment to make.

None of this is documented, but I suspect the servers are used only for call establishment via SIP and the audio is peer-to-peer RTP.

Are you sure about this? I think there is much more that the OBi servers can do. I think you might be correct in that the OBi servers are making a peer to peer connection. The Hamachi VPN service comes to mind as another example of how a relay server is used in order to facilitate the connection between two endpoints, then removes itself from the connection. Ultra VNC also has a relay server application which provides similar service with several VNC servers installed on PCs scattered over the internet.

I think the grand design of the OBi is for massive build outs for use by big voice SPs. The OBi has a control infrastructure that has never really been brought up in this forum. I think it has never been brought up because there has been no need for discussing it. Here and there we can find a reference in their marketing blurbs referencing the OBi having the ability to mass provision the units. On this forum we are only seeing individual cases because of the initial appeal to early adopters of the OBi. If you look here: http://www.obihai.com/partner/partner.html , you will see Obihai soliciting SP's. What we are seeing on this forum is only the tip of the iceberg. The OBi servers must have abilities to service the OBi units in ways which would make it efficient for a major SP to handle their customer accounts.

At the moment Obihai is selling one unit at a time. In the near future Obihai will land a contract for hundreds/thousands of units. We will be seeing SPs offering SIP accounts using OBi ATA's with locked/unlocked units. I am using a Freephoneline DID. At the moment they only officially support Grandstream ATA's with their offering. Once the OBi is accepted in the VOIP community it will make it easier to displace the competing ATA's simply because OBihai has built the better mouse trap.

[RonR]

This was lifted from the OBI FAQ:
"OBiTALK is a web portal and OBi configuration utility which helps OBi users configure devices and access applications. OBiTALK is also where users set-up Circles of Trust which provide a means to network groups of individuals so that calls can be made as inexpensively as possible."

The above statement kind of implies that COT can facilitate a connection between 2 or more Obi's without having to worry about NAT issues. The OBi servers are there to offer this service. Without it, there is no COT ability.

I think you're reading way too much into that statement.  The OBiTALK web portal is an OBi configuration utility which helps OBi users configure devices and access applications (OBiON apps).  When you set up Circles of Trust, just like setting up Google Voice or a VoIP provider through the OBiTALK web portal, it simply provisions (configures) your OBi or OBiON app for you.  Circles of Trust configuration is done in the OBi's InboundCallRoute, not through additional support in the (separate) OBiTALK Service communications server.  Circles of Trust can be set up manually, without using the OBiTALK web portal, and if done so on SP1, SP2, and the LINE Port, works equally effectively on those trunks which have no need for and don't use the OBiTALK Service communications server.  The OBiTALK Service communications server, like a SIP server, is necessary to allow OBi's and OBiON apps to establish calls to each other, but I don't believe Circles of Trust come into play anywhere but at the OBi itself and is done simply by restricting access using CallerID matching in the InboundCallRoute(s).  I don't believe Circles of Trust have anything to do with the OBiTALK Service communications protocol and therefore have nothing to do with NAT traversal or any other aspect of the transmission mechanism.  I hope someone with actual knowledge of this will correct me if I'm wrong.

None of this is documented, but I suspect the servers are used only for call establishment via SIP and the audio is peer-to-peer RTP.

Are you sure about this? I think there is much more that the OBi servers can do.

That was said in the context of calls between OBi's and OBiON apps and whether Circles of Trust improve NAT traversal.  Yes, there is a server that is involved in the provisioning, firmware updates, and debugging aspects of the OBi.  Whether it's an integral part of the OBiTALK Service communications server or is a separate entity is known only to the Obihai folks.

At the moment Obihai is selling one unit at a time. In the near future Obihai will land a contract for hundreds/thousands of units. We will be seeing SPs offering SIP accounts using OBi ATA's with locked/unlocked units.

I hope you're right, because if Obihai doesn't succeed and goes under, all OBiTALK Service communications (OBi-to-OBi and OBiON-to-OBi) will stop working when Obihai closes the door and turns off the lights.  Having so much stuff undocumented and being totally reliant on a small start-up company that's playing everything very close to the vest really scares me.

[johnny.medellin]

I'm not using the COT method because eventually someone else will be using the OBI unit I have in the US. That's why I want to keep them independent. I currently have both because I'm in "Testing" mode. I currently have only GV #s, no SIP SPs, and yes, I do have separate GVs on each box (I'm no expert, but I've been dealing with SIP/Asterisk for a few years so I kinda know my way around). I'll check my codecs, although I haven't touched them since I got the units. Remember also that I copied the configuration on the "suspect" OBI (the one in Colombia) and loaded it onto my US unit, and it works perfectly in my known good unit. Also remember that my calls are random, sometimes they'll go through, and sometimes not.. both incoming and outgoing.

I used VNC, but I'll try to connect to the Obi directly tonight, I guess with all the problems I didn't think of that. Thanks for the advice. BTW, for whatever reason, the Expert configuration portal through OBI is giving me problems too. I access it just fine and can make whatever changes, but for whatever reason those changes do not get reflected in my actual unit; that's one oif the reasons why I just started VNCing to it. That and also because I like to monitor my phone calls while troubleshooting and because I want to be able to save configuration files while testing (I didn't see a way to do those two things through the Obi website)

Regarding the "cannot connect" blank page I get, I get this error message on the Obi page only, meaning while trying to access 192.168.1.xxx on the PC I connect to. My actual VNC connection to the PC is always active and alive! By the way, You might be thinking, "well, maybe he gets that message after just rebooting the unit" to which I say, nope, it happens all the time, and at random, sometime I would be able to see one OBI page (i.e. SIP1) but when I try to go to SIP2, I would get the "cannot connect" message. To continue answering your questions, Yes, I've been able to have 2-way calls. But everytime except once, they stop hearing me. I can always hear them. Only once was I able to talk for more than an hour without interruptions. Oddly enough that happened after several other "cutoff" incidents and without me making any changes. Later that day the cutoff incidents came back... That's why I keep saying Random, and that's why I think I got a defective unit, which is just screwing with my head Sorry about the long message, I just wanted to answer your questions and post as much info as possible to help in troubleshooting

[QBZappy]

johnny.medellin,

Hi, I've seen a few posts here with people having the OBi randomly rebooting. Can you ask someone in Colombia to confirm if the unit is indeed rebooting by itself? You can also see the up time on the unit. That will give you an indication and a code specifying a reboot reason. If that is the case you might want to review some posts with OBi randomly rebooting. I think RonR has has responded to a few questions related to that issue. He might want to chime in on that.

BTW, testing copies of the config on your local OBi would not absolve codec being an issue between the units, since I presume you were testing local unit with local calls.

For the Expert configuration portal changes to stick you need to enable auto provisioning:
System Management>Auto Provisioning>Method = Periodically/system start

The Expert configuration portal is not as complete as the OBi web page. It allows for configuration but lacks in the ability to verify the call history, as you observed, in order to troubleshoot an issue. This has been brought up before. If you set up the autoprovisioning you will need to configure only from the Expert configuration portal . That setting forces you to choose one configuration strategy over the other. You can not use both methods at the same time. At the moment the OBi web page method via port forwarding  offers more troubleshooting options.

A while back there was some mention about some browsers not working properly with the OBi web page. I have not seen any recent mention about this. Anyways if you want to connect to the OBi web page, a direct connection via port forwarding will answer that question quickly enough. I have never had any problems with Firefox connecting to the OBi web page.

Have another go at it. You can send OBi support an email with a link to your thread. I've seen some good comments about their efforts in resolving client issues. In the end it might just be that you have a defective unit.

Good luck. Keep us posted.