71–80 of 141 posts
I think your complaint is about VoIP over the internet. And that's simple, the internet is best effort. Packets get dropped and that's expected. Also, packets can take a long time to reach their destination and there are no guarantees for jitter. This absolutely sucks for voice quality and there's nothing anyone can do about it.
Earlier quoted context omitted.
So what you're saying is: VOIP will never match PSTN? Because that's the mood music I get from the sysadmins at work too.
VOIP is considerably better than PSTN if configured correctly. There's no comparison. Your sysadmins don't understand VOIP.
Edit: "canbe"
Earlier quoted context omitted.
VOIP is considerably better than PSTN if configured correctly. There's no comparison. Your sysadmins don't understand VOIP.
just want to point out: vast knowledge of telephony/VOIP is not something every sysadmin should be expected to know. If you don't have telephony expertise on staff I hesitate to suggest someone build out a VOIP infrastructure on their own. It can be extremely time consuming to learn and it is definitely painful to troubleshoot.
I think your complaint is about VoIP over the internet. And that's simple, the internet is best effort. Packets get dropped and that's expected. Also, packets can take a long time to reach their destination and there are no guarantees for jitter. This absolutely sucks for voice quality and there's nothing anyone can do about it.
I'm surprised that no one has mentioned bufferbloat yet. In most home routers, people can see seconds of delay when there's significant other traffic on the link. (And remember, "other traffic" can be ordinary web browsing, where pages average 2 mbytes these days...) The latency (and jitter) caused by bufferbloat has been a solved problem for almost five years: fq_codel, and the newer cake qdisc's are are in the Linu…
> Add new "smart queue" feature providing FQ-CoDel + HTB function and this can be configured in the Web UI to provide better QoS experience for the WAN connection.
I'm surprised that no one has mentioned bufferbloat yet. In most home routers, people can see seconds of delay when there's significant other traffic on the link. (And remember, "other traffic" can be ordinary web browsing, where pages average 2 mbytes these days...) The latency (and jitter) caused by bufferbloat has been a solved problem for almost five years: fq_codel, and the newer cake qdisc's are are in the Linu…
Bufferbloat is a side affect of congestion or microbursts, and not the primary cause of poor voice calls. Either packets get dropped (shallow buffer) or queued (enough buffer), and in both cases the quality of the call will suffer. Mitigation: Don't congest. If you need to, mark VOIP traffic with a DSCP value that has queues that are serviced prior to all others (e.g., EF, DSCP46).
So that you use it and not competition.
Net neutrality would be the antidote.
I'm surprised that no one has mentioned bufferbloat yet. In most home routers, people can see seconds of delay when there's significant other traffic on the link. (And remember, "other traffic" can be ordinary web browsing, where pages average 2 mbytes these days...) The latency (and jitter) caused by bufferbloat has been a solved problem for almost five years: fq_codel, and the newer cake qdisc's are are in the Linu…
Earlier quoted context omitted.
QoS depends on tagging (DSCP), and if one of the routers along the way doesn't support it or isn't configured for it, those tags are often dropped - or at least that's what I've seen in our company's network.
Like so many other things in tech, "it depends". Network gear can be configured to treat frames/packets in various ways -- leave the ToS/DSCP bits alone, strip them out, or remark them. At the edge of a network, it's common to mark them. In the core of a network, you'll usually leave them alone (but honor them). On connections to third-parties (such as ISPs), it's not unusual for them to strip your QoS markings -- un…
It actually can hurt the Internet performance as a whole, as the tiny VoIP packets prevent Jumbo throughput ones from working really well.
It takes just one bad hop to ruin latency.
Secondly, good codecs make a world of difference. This is where I'll add the disclaimer that I'm in the collab side at Cisco. But I have the opposite experience using systems on my phone, my mac and with big telepresence units: the quality in all 3 settings far surpasses what's on PSTN, and if you're using good speakers or headsets, you can really appreciate the good quality.
In your case, it sounds like you might benefit from a better network access point at home.
Shameless plug #1: check out Cisco Spark. We still have some rough edges but I think the call quality is what you're looking for. I'm able to carry on a call and switch from wifi to LTE without dropping, or turn on VPN in the middle of a call and just get a few seconds pause before it recovers.
Shameless plug #2: check out the new Sparkboard. It's got 12 microphones and does beamforming in order to filter our room noise away from whoever is speaking.
http://www.cisco.com/c/en/us/products/collateral/collaborati...
Earlier quoted context omitted.
Never is a long time. What if some day the technology exists to interpolate dropped packets (e.g., using ML) fast and cheaply enough to fill in the distortion? That doesn't seem too outlandish in the next 20, or even 10 years.
That sounds fine, except for the timeline. What I'd like is an affordable, ubiquitous solution next week :)
Remember, the codec has to handle less than 20 ms latency. Running a sizable ANN (fast) or HMM in that time is not easy or even possible. A small one will be no good for various speakers.
Instead the codecs use various specialised error hiding tricks and adaptive strategies.
Heck, Codec2, one of the strongest voice codecs around could be used if all else fails. It is beginning to be used in SDR and amateur radio - optimised for availability and intelligibility not quality. It would be nice to have a variant integrated with CELT for higher quality.