Obi and GV calls blank out after a while
sjmyst:
SteveInWA,
Thanks for the tip. I used to know about that site and had forgotten.
I ran the VOIP test 12 times choosing various sites. Twice the test failed. But, both times it was for the Staten Island location in New York. The errors implied the site was down so I feel confident that this wasn't an issue on my side.
I did 5 tests using my HTPC that is wired to my provider's router. I did 5 tests using a MAC wireless. I placed the MAC behind a chair to simulate the same obstruction I have for the Obihai. The MAC was within 3 feet of the Obihai.
All 10 tests to sites that worked gave a MOS score of 4.2. I use Verizon FIOS as my service provider. I've used them on two occasions with Time Warner in the middle for a year. The Verizon FIOS is MUCH better than Time Warner in terms of consistency and quality. I feel like Verizon FIOS is the best internet I've ever had in terms of quality. Of course, like you said before, I'm really not looking at it from a RTP VOIP perspective. However, I was using the Obihai about a year ago when Google Voice announced the discontinuation of the XMPP. This made me go out and buy a GVMate product as an alternative. It works with GV in a very similar way (just not using XMPP). I say similar from the standpoint of the GVMate providing the "bridge" between my home phones and GV. When I saw that the Obihai was going to work again, I wanted to go back and try again. But, now I'm thinking about going back to the GVMate.
The GVMate used this same Vzw FIOS internet for the past half a year or so. And, before that worked with Time Warner. I never had issues like this where chunks of between 5 seconds and 15 seconds of voice was being "dropped". I say "dropped" because my perception is that the RTP stream just stopped for that period of time. I don't know that for sure. But, the stats above seem to imply this.
If it's the internet, it has to be from the Obihai to the FIOS router that is the issue. The GVMate was in my HTPC (windows 7 PC with HDMI video card that plugs into a TV) that was directly plugged into the FIOS router. So, there is still the possibility that the problem could be the wireless connection.
I've only had the Obihai reconnected for the last couple of days. So, whatever the issue is, it has shown itself VERY quickly compared to the 6 months prior where nothing similar to this ever happened with the GVMate.
FYI, I chose to go away from the GVMate because it is hosted on my HTPC, and if I'm doing too much on the HTPC, the GVMate can get confused and need to be restarted. Also, I can get 911 again with the Obihai using Anveo.
Still hoping to have a solution for this.
Regards,
sjmyst
SteveInWA:
Thanks for all the diagnostics and additional information.
One thing caught my eye: you said: "So, there is still the possibility that the problem could be the wireless connection."
Are you using the OBi with a ObiWiFi adapter? If so, I'd suspect the WiFi connection, and use Ethernet instead.
As for comparison to the "GVMate", the better comparison would be to using a USB headset attached to a PC, running Google Hangouts. If Hangouts works reliably, then that would point suspicion at the OBi.
As for FiOS, yes, I also have FiOS, and it's fantastic. However, Verizon sold their business here in the Pacific Northwest to Frontier, and Frontier's backbone connections aren't as robust or outage-free as Verizon's, so we do have some occasional glitches.
sjmyst:
Well, it's been YEARs. And, I'm still fighting this issue. It has been better from time to time. But, it has never completely gone away.
It seems to have gotten worse over the last several months. I suspect it's a firmware update that has made things worse. My current firmware is now:
HardwareVersion 1.4
SoftwareVersion 3.2.2 (Build: 5921EX)
Up above, SteveInWA posted a link where I could test my VOIP capabilities. But, that link is now dead. Anyone have suggestions for a new place to test? I'm hoping there is something really good that can help me here. The old link was "http://myspeed.visualware.com/index.php".
I see with the firmware updates that I've lost some of my packet statistics. [UPDATE]: I think I just forgot where I was looking. I found the stats I thought I was missing.
The frustrating thing about this issue is that calls will work great for 30 minutes at a time. Then, there is some sort of change and the sound starts cutting out for 5 and sometimes 10 seconds. That happens multiple times over maybe a 2 minute period. Then, the call continues to work ok for a while before it happens again.
One of the things that had helped before was a couple of settings in the PHONE LINE areas. To get to them from the ObiTALK dashboard:
- Click on your device name (for me Obi202),
- Scroll to the bottom and click on the blue button "OBI Expert Configuration" (Click "Ok" on popup)
- At top, click on blue button "Enter OBI Expert"
- On left, click on the "[+]" next to "Physical Interfaces"
- Click on "PHONE 1"
The settings I changed are in the "Port Settings" section. The value I change them to that helped me are below:
ChannelTxGain: -2
ChannelRxGain: -1
SilenceDetectSensitivity: Low
I changed them for both the "PHONE 1" and "PHONE 2" sections (since I have my phone connected to PHONE2 and my wall connected to PHONE1).
Anyway, I've played with these setting again with not a lot of luck this time.
It seems like the SilenceDetectSensitivity might have been most of my problem. But, now it's not helping to have it set to Low. I've tried the following without much luck:
ChannelTxGain:ChannelRxGain:SilenceDetectSensitivity
-2:-1:Low = Voice cutting out from remote side (I can't hear them;worked "ok" for years)
6:6:Low = Cutting out in both directions
-12:-12:Low = Voice cutting out from remote side (I can't hear them)
-12:-1:Low = Voice cutting out from remote side (I can't hear them)
-1:-12:Low = Voice cutting out from remote side (I can't hear them)
-5:-4:Low = Voice cutting out in both directions (worse). One time VERY bad at start of a call. Wife gave up and moved to cell phone.
-1:0:High = Voice cutting out from remote side (I can't hear them) once every 30 minutes or so. Very good for 30 minutes. Very bad when it goes bad (I can't hear them). When goes bad, minor cutting out from me (they can't hear me)
-1:0:Medium = Voice cutting out from remote side (I can't hear them) once every 30 minutes or so. Very good for 30 minutes. Very bad when it goes bad (I can't hear them).
I believe I've tried testing using an Ethernet cable instead of the ObiHai Wifi USB plug. But, it's been many years. So, I'm currently trying without that. My telephone lines and Wifi router aren't really close to each other and aren't really conducive to having the ObiHai hard wired via Ethernet cables. To test, I have a Ethernet repeater and have removed the ObiHai Wifi USB device and am now connecting the ObiHai 202 via it's "Internet" port to the Wifi Repeater with an Ethernet cable. And, have configured the WAN on the ObiHai202 with a fixed IP into my home LAN.
Regards,
sjmyst
sjmyst:
Calling from home using my Obi202 to my cell phone, I can refresh the SP Service Stats on the "Status" sub-menu over and over and see those stats change during a call.
When I hear the "blanking" or break up of my voice, I see "PacketsLost" and/or "Underruns" numbers increase. While the call is doing fine, those numbers don't increase. Usually when things go "bad", both numbers increase.
I also have my e911 service set up via Anveo. I can dial '933' to test that service and I see packets being sent/received on SP2 (where Anveo is configured). I have yet to see any "PacketsLost" or "Underruns" numbers (always 0) on SP2 while in a call to test e911.
However, I can sometimes go for several minutes without seeing the "blanking" on SP1 via GV. So, I'm not 100% sure that the Anveo is always perfect. But, so far, it has been perfect.
I would think if I swapped SP1 and SP2, that it wouldn't matter. But, maybe that's not true? Anyone know if something like "dropped" or "underrun" packets could be restricted to SP1?
I'll have to do some more testing to see if Anveo on SP2 ever shows "dropped" or "underun" packets.
Regards,
sjmyst
sjmyst:
So, I broke down and paid $10 for Obihai support for this issue. So far, not much help.
They did update my firmware from the above values to:
HardwareVersion 1.4
SoftwareVersion 3.2.2 (Build: 5932EX)
It didn't help. My first call seemed to provide some improvement. I was getting the same number of "blank outs". But, the length of the "blank outs" was shorter (all < 1 second). But, I had a later call and the number of "blank outs" was 4 or 5 within the first minute. And, most were more than 3 seconds with the longest being at least 5 seconds.
Support also suggested that I open up the recommended ports (both inbound and outbound).
This didn't make any sense to me. I suspect they were just following a script. Or, providing a more "general" answer without really reading or understanding my issue.
I really don't see how blocked ports could cause an intermittent issue like this where voice packets are being dropped or having underruns AFTER the RTP connection (the part where I believe the ports matter) has already successfully occurred. Maybe I'm just not understanding something here. But, my 30+ years of working in an industry doing network programming and support tells me that this isn't the issue.
I went ahead and port forwarded port 10000 to the Obihai 202 device just to make sure I'm not the one that's confused. I don't believe any ports are blocked outbound. I'm not sure why Obihai specifies that. But, I supposed they are covering some case somewhere where this has happened.
Well, I finally had a break through of sort with this.
I have configured a Yate Server to provide caller id for my Obihai. The Yate Server runs on a PC I have. When calls come inbound to my Obihai 202, I was under the mistaken assumption that the CallerId query occurred out of band and the RTP voice connection was done directly between GV and my Obi202 device.
I finally took a closer look at the Statistics on the Obi under Status=>CallStatus. I had looked at that screen before. But, was so focused on error statistics, that I neglected to notice that this screen was showing me that there were RTP connections on the inbound side between GV to the Obi202 (SP1), then from SP1 to my Yate Server, then from my Yate Server back to my Obi202 to SP4. I was also able to "prove" to myself that there is an RTP stream happening with an active inbound call by running tshark on my Windows 10 PC and filtering for my Obi202 IP.
I have always had the impression that my voice breakup problem was more inbound than outbound. But, I didn't have any hints that it was mostly for calls coming into my Obi202 (only inbound calls to the house use the Yate Server).
So far, I haven't been able to prove this for sure. I have been looking into giving my VMPlayer running that Yate Server more priority on my Windows 10 PC. But, so far, Windows 10 isn't cooperating. Still more investigation to do there. But, I feel like I'm on the right track. Looking at the process priority of my VMPlayer that runs my Yate Server on my Windows 10 PC, I can see that Windows 10 downgrades the priority to "Low" when the VMPlayer is iconified. So, this seems like a very likely culprit.
Having said all of this, I still have a feeling if I can fix this, that this will only fix some of my "blanking out" problems. I suspect it might improve things enough so the problems are tolerable. I have definitely had reports from callers that my voice is breaking up to them (which is the RTP path that I don't believe goes through my Windows 10 PC). But, I wonder if an inbound problem could affect the outbound steam somehow. I wouldn't think so. But, I know that when callers report that I'm "blanking out", it at least sometimes coincides with me also hearing "blanking out" of their voice.
Hopefully, I can somehow get my VMPlayer running at a higher priority and can eliminate it has a source for this problem. I may just disable CallerId for a bit to test that this is my issue.
Regards,
sjmyst
Navigation
[0] Message Index
[#] Next page
[*] Previous page