Obi and GV calls blank out after a while

<< < (3/5) > >>

drgeoff:
At least for a test period, take Yate, VMPlayer and Win 10 out of the system and have the OBi talking directly to GV.  If the dropouts disappear you will know there is nothing wrong with your OBi, your internet connection and GV.

The outgoing ports could be an issue in some business networks which restrict the applications which can access the internet but I've never come across a residential gateway that has user control of outgoing ports.  Port 10000 is only used by the Obitalk network.  Forwarding that will do nothing for GV.

sjmyst:
Well, I wrote some scripts to set my VMPlayer to be High Priority and gave it an Affinity of one of my 4 CPUs to try and make it more stable.  But, I couldn't get the voice problems to stop.

I've currently disabled my Yate Server to verify that it is indeed the problem (or most of the problem).

I'll be looking into other ways to get CallerId if my Obi202 works well in this mode.  Or, I may just live without CID.  My wife is "so done" with this phone, if I get ANY configuration that doesn't "blank out" her voice or the other person's voice, then I may just have to leave it that way for a while.

Other things I plan to look up for CID is to possibly upgrade the Yate Server software (it probably has updates).  Or, the version of Ubuntu.  I'm not sure right now which one of these does the RTP that is having problems.  I'm guessing Ubuntu.  Even if there are later versions, it still could be just that Windows 10 won't provide a stable CPU environment for my Yate Server under VMPlayer to run.  I started to look into maybe a Rasberry Pi solution to run my Yate Server.  But, that seemed to be something I would have to put into my Windows PC.  That assumption could be completely off.  I haven't researched enough about how that works.  If it does require to be in my Windows PC, I dont' have a big enough power supply to support adding that.  Ideally, I'd like just a standalone Linux device that I can install Ubuntu on, and put the Yate Server on it.  That way when I have power outages (happens occasionally where I live), it can automatically boot back up and provide service again.

If I figure something else out that works, I'll share it here.

Regards,
sjmyst

SteveInWA:
Quote from: sjmyst on January 07, 2019, 11:26:57 am

My wife is "so done" with this phone


I would be, too, if I was her.  You have turned a simple appliance into a massive spaghetti pile of unnecessary gear, adding layers of points of failure.

Just use the OBiTALK device as designed.  Delete it off of the OBiTALK web portal.  Restore it to factory defaults.  Add it back to the portal.  Configure just Google Voice. Don't make any custom/expert mode changes.  Test it for a week.  IF it works, tell your wife to hit you in the head with a cast iron skillet if you mess with it further.

You'll get numeric caller ID for inbound calls, and, if the caller's name and number are in the Google account's contacts, you'll get the name.

sjmyst:
I didn't completely do a factory reset.  But, I did delete the SP1 (GV) and SP4 (Yate Server) from the configuration on ObiTalk.  I re-added GV using the GV Setup button under the device.  I left the 911 configuration under SP2.

I also had already gone back and tried to "undo" all of my "expert mode" changes.  But, it's possible I missed one.

First call saw zero improvement.  Call stats showed 3 packets lost, 314 overrun packets, and 452 underrun packets.  All stats were for only SP1.  So, no Windows 10 "spaghetti" in the middle.

I'll go back and do the factory reset and delete from ObiTalk and see what that yields.  I'll leave the Anveo 911 stuff out for now as well.

Thanks for the input about using Google Voice Contacts to provide CID.  Knowing that years ago would have saved me a ton of headaches (from cast iron skillets).

sjmyst

SteveInWA:
Quote

...knowing that years ago...


Actually, don't feel bad; this behavior changed last year, as part of Google's overhaul of the service.  It's been discussed elsewhere in this forum, but good luck finding my post, so, this is the new/current behavior of name/number display for Google Voice inbound calls:
If a calling number is found in your Google account's contacts, then the name stored in Contacts will be displayed (regardless of whether it is correct/current).If a calling number belongs to a business that is known to Google (i.e. you can find that business on Google Maps, and Maps shows their telephone number), then that business' name will be displayed.Otherwise, only the numeric caller ID will be displayed, or, if it's an anonymous call, GV honors the "suppress CID" flag and doesn't display the number.
In conjunction with the name behavior above, if you have Google Voice's call screening feature turned on, then the new behavior is:
If the calling party's name is in your Contacts or it is a known business, a synth voice will speak that name to you, during the call screening.  The caller will not be asked for their name.If the calling party's name isn't known, then they will be asked to speak their name, on every call, until/unless you add their name and number to your Contacts.  You will hear whatever the caller says.There is no way to turn off name presentation if call screening is enabled.

Navigation

[0] Message Index

[#] Next page

[*] Previous page