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