Any chance someone on this list is affiliated with Comcast who could contact me off-list? I have an employee in Virginia who works from home using, in part, a VOIP desk telephone tied into our office phone system back in Nebraska. She's had nothing but problems maintaining a stable connection and I'm at my wit's end to diagnose and fix whatever is causing her problems.
I've got this exact setup with several employees around the country, but this one person is the only one who, 1 - has problems and 2 - has Comcast.
Much appreciated!
Have you monitored your user's home Comcast connection with regards to
packet loss or latency, preferably from network-near the SIP
termination point?
Make sure the remote phone is using a low bandwidth codec too. In a previous life changing a remote (home) user's phone from G.711 to G.729 made all the difference in the world to their call quality.
Matthew Shaw – Sr. Network Administrator
FairPoint Communications | mshaw@fairpoint.com
www.FairPoint.com
If you run something like a pingplotter or MTR from pbx side towards the Remote,
and do similar from remote towards the pbx side...
Let it run for a bit, and compare / analyse the results.. you will spot your problem very quickly.
I have found Comcast rate shapes or resets long running encrypted
sessions such as https. At $DAYJOB I had to set our SSL VPN system to
re-key via new-tunnels every 5 minutes to keep it under their threshold
of what looks like seven minutes for a tcp session. After that the
sessions appeared to rate shape down to 128kbps. It may also only kick
in during local POP congestion. I am assuming this is DPI trying to do
peer-2-peer mitigation.
"Shaw, Matthew" <mshaw@fairpoint.com> writes:
Make sure the remote phone is using a low bandwidth codec too. In a
previous life changing a remote (home) user's phone from G.711 to
G.729 made all the difference in the world to their call quality.
i think you've got that backwards. 80 kbit/sec on the wire is not a
lot these days, and in a world where we're conditioned to accept gsm
or worse, un-transcoded g.711u sounds startlingly good. if you're so
short on bandwidth that moving to a 24 kbit/sec on the wire codec
makes a difference, you're on the ragged edge of being hosed.
-r
I have found Comcast rate shapes or resets long running encrypted
sessions such as https. At $DAYJOB I had to set our SSL VPN system to
re-key via new-tunnels every 5 minutes to keep it under their threshold
of what looks like seven minutes for a tcp session. After that the
sessions appeared to rate shape down to 128kbps. It may also only kick
in during local POP congestion. I am assuming this is DPI trying to do
peer-2-peer mitigation.
We don't have such network practices and are required not to under Open
Internet rules. I have no idea what was causing your VPN issue - I can use
my corporate VPN for hours or days at a time with no issues. Happy to
assist off list if you like.
Jason
agreed this isn't the case based on what I've seen based on my latest
former employer(s). Comcast is playing by the (generally agreed upon)
rules. what I have been seeing is a lot of other route optimizations
changing as other providers consolidate routing among latest acquisitions.
And of course, there's always the defensive changes also based said
changes. constant maintenance and optimizations in recognition of the
contracts. it'll sort out, the questions are what's needed to force the
issue and, of course, where the standouts end up.
-R>
I agree it's not a lot of bandwidth, but I was grasping at straws at that point finding out about the cross country VoIP arrangement after the fact. For whatever reason, the 711 calls were full of voice clipping and call drops, 729, (with to your point, the lower MOS) worked better as despite not sounding as good, the calls stopped dropping and people's voices were no longer dropping out.
Matt