News:

On Tuesday September 6th the forum will be down for maintenance from 9:30 PM to 11:59 PM PDT

Main Menu

Obi202 testing quirks

Started by tns1, March 13, 2015, 12:13:05 PM

Previous topic - Next topic

tns1

Obi202, fw 3.0.1 (Build: 4581), setup behind router, Location: Southern Calif.
Anveo 'Free!' plan, Proxy location: Texas

I've only been using the 202 for a few days, but here are some 'quirks' I've experienced so far:

For most or all incoming calls, the caller will hear one ring, then a 4sec delay, then more rings. On my end, the phone rings normally. Callers might get the impression that this is a forwarding delay when it really isn't. I don't consider this a problem.

I made an outgoing call to an answering machine in the next room. From the next room I could hear that phone ring, and hear that machine pick up and the greeting start, but on my phone call it was still ringing. A few seconds later my call was connected, and via the Obi I heard the entire greeting so apparently the few seconds of audio had been buffered somewhere. Those few seconds were played back to me faster than normal, with tiny bits of audio skipped. Noticeably degraded but legible. Once it caught up/re-synced/emptied the buffer, the rest of the greeting played normally. A later repeat of this call connected with no apparent delay or buffering.

I made an outgoing call to an answering machine across town. When it connected I had completely missed the first 3 seconds of the greeting, which is usually the important part where the recipient identifies themselves. A later repeat of this call played the entire greeting at high quality.
 
Are the experiences/inconsistencies I've described above something I just have to live with, or do they indicate a problem that could be remedied?

This buffering that I describe, is it happening at the Obi, or the Anveo proxy? Part of G.711 maybe?

Are there any sort of learning algorithms in place at the ITSP or in the Obi that might result in better call quality over time, or faster call processing for repeat calls?

I see that voip.ms has a proxy in Los Angeles which is much closer to me than Texas. Would this tend to improve call quality, or do I just need to try it out to know?

I have set the Obi to 100mbps full duplex, which made no difference in voip quality tests. My MOS score is always 4.0 or better. I know these tests are not using Anveo servers, but is this enough to remove suspicion from my router/modem/settings as a cause for the issues above?

thanks


202Owner

#1
A brief search suggests this may have to do with a delay in call setup by Anveo due to network response issues.  What ISP, modem, and router are you using?

The goal of VoIP is to encode voice into data packets and transport them asap.  I do not believe there is a buffering or learning algorithm consideration to this trouble.  It sounds more like a signaling issue... that I have no experience with.

This trouble is not normal VoIP quality and is something to be fixed.

tns1

#2
I have the following setup:
Cox cable 50Mbps service -> Mot SB6120 -> Linksys wrt54G #1 -> 1 isolated client + Linksys wrt54G #2 -> several wired/wireless clients + Obi

I only get ~26Mbps throughput due to the HW limitations of these older routers.

Update - I moved the Obi to the 1st router and enabled mac-based QOS, to see if anything improves.

---------------------------------------------------------------------------------------------
Update 3/19 - the above change did seem to improve call quality overall.

QuoteFor most or all incoming calls, the caller will hear one ring, then a 4sec delay, then more rings.

This is actually something that is part of the default call flow, and can be changed. "It's a feature, not a bug." For now, I want to let my answering machine still take care of my calls, so:

To completely disable Anveo VM, go to Phone Numbers->Manage->Edit->Call Options, and select 'SIP/ATA device' instead of 'Use Call Flow'. The land line phone/answering machine now behave as before with no ring delays or 'race conditions' between machine and VM.