I mean.... when was the last time you made a call that was full analog/PRI? Did you notice that cell phones had higher latency than landlines?
30-40 ms latency is probably the lower bound on a VoIP call [1]; most calls will be a lot more. But you might not notice it if that's all you have access to, or if all of your calls are long distance that it would never be good anyway. On long distance, you probably have a better transmission delay now over internet than you would have had over telephone networks, as cable routes have improved and routing is often more direct; that will probably offset some of the packetization delay.
[1] You can do better, but it involves having great connectivity and sending lots of very small packets, and mainstream calling isn't willing to send 200 packets per second of 5 ms of samples when most people don't notice/complain about the latency when sending 50 packets per second with 20 ms of samples.
> when was the last time you made a call that was full analog/PRI?
Probably 15-20 years ago? That would have most likely been over DECT, though, which adds 10 or so ms by itself (our wired landline phone was in a slightly awkward location :)
> Did you notice that cell phones had higher latency than landlines?
Compared to landlines, the most noticeable aspect of GSM wasn't the latency (unless the person on the other line was right next to me, in which case there was an echo), but rather the absolute potato quality compared to both G.711 landlines and modern VoIP codecs.
> mainstream calling isn't willing to send 200 packets per second of 5 ms of samples
Yeah, that would probably be too much overhead for most applications. But now you got me wondering: Do video calls have lower latency audio (assuming the codec can do better than 20ms in the first place), given that there's probably much more data available to send at any given time?
> Do video calls have lower latency audio (assuming the codec can do better than 20ms in the first place), given that there's probably much more data available to send at any given time?
At least for WebRTC, no. The audio and video streams are separate, there's no mechanism in WebRTC to piggyback audio onto video packets. If the receiver is synchronizing audio with video, there's potential for additional delay (but when A/V sync works, it's probably worth it)
I don't know details about WhatsApp calling (although I worked there, I didn't touch the realtime calling stack), I think it does use RTP which isn't really built around piggybacking, but since it's a closed service, they can do whatever. No idea about Apple's calling either.
30-40 ms latency is probably the lower bound on a VoIP call [1]; most calls will be a lot more. But you might not notice it if that's all you have access to, or if all of your calls are long distance that it would never be good anyway. On long distance, you probably have a better transmission delay now over internet than you would have had over telephone networks, as cable routes have improved and routing is often more direct; that will probably offset some of the packetization delay.
[1] You can do better, but it involves having great connectivity and sending lots of very small packets, and mainstream calling isn't willing to send 200 packets per second of 5 ms of samples when most people don't notice/complain about the latency when sending 50 packets per second with 20 ms of samples.