Hi Nathan-
I mean, _maybe_ if you are aggregating audio transmissions into
150ms+ sized frames, but...that seems like a bad idea?
It's not a good idea for real-time delivery, but that doesn't stop
some audio use-cases from doing it, for example speech recognition /
translation, where some delay is ok, and/or audio quality is ultra
important. Maybe that's better termed near-real-time.
-Jeff
Quoting Nathan Anderson via VoiceOps <voiceops@voiceops.org>:
"Only if it was encapsulated over some form of TCP"
Even so, what narrow-band voice codec with frames transmitted at
regular intervals is going to be sending individual IP packets
approaching anywhere near 1500 bytes in size? I mean, _maybe_ if
you are aggregating audio transmissions into 150ms+ sized frames,
but...that seems like a bad idea?
I'm also not really sure what TCP's got to do with anything,
frankly. The only thing it has that UDP does not in the context of
influencing packet size is MSS. Which arguably _increases_ the
chance of success, since at least MSS negotiation is something that
you have _some_ semblance of control over in order to override bad
behavior, unlike PMTUd which, if your ICMP "packet too big" messages
are getting sent to /dev/null ...good luck with that.
But, again, that's rather a non-issue if your individual audio
frame IP packets are, like, 200ish bytes in size each on average for
20ms-worth of audio. Even if some WAN link between you and the
other endpoint had some _absurdly_ low MTU like ~500 _and_ your
PMTUd messages are getting eaten by a grue somewhere in the middle,
you _still_ aren't going to be running into that. So the whole TCP
encap thing strikes me as a /non sequitur/?
(Not to mention that TCP's guaranteed delivery feature is rather
undesirable in the context of real-time anything, though that's
another whole subject entirely.)
-- Nathan
FROM: Jeff Brower [mailto:jbro...@signalogic.com]
SENT: Monday, March 11, 2024 10:19 AM
TO: Nathan Anderson
CC: voiceops@voiceops.org
SUBJECT: Re: [VoiceOps] One Way Audio - Frontier Comm (Los Angeles area)
Hi Nathan-
In short, I have a hard time believing that MTU issues are the underlying
cause for many (or even any) VoIP audio delivery problems
Only if it was encapsulated over some form of TCP.
VoIP audio streams other than PCMU-encoded ones, so perhaps it's
possible other codecs are different
It might be worth checking for EVS, which has a lot of SDP options.
We've seen some endpoints (handsets) that stop encoding because they
didn't understand SDP asks from the receiver. Basically bugs, they
get fixed over time, but since EVS is newer and still in adoption
phase, that time is stretched out.
-Jeff
Quoting Nathan Anderson via VoiceOps <voiceops@voiceops.org>:
Yes, hosts or routers-in-the-middle that don't send ICMP type 3
code 4, or which drop such a message sent by another host instead
of forwarding it, do make me upset.
But...
In this case we're talking about relatively narrow-band,
widely-compressed RTP audio. Admittedly I rarely deal with any
VoIP audio streams other than PCMU-encoded ones, so perhaps it's
possible other codecs are different (though I'd be
surprised...timeliness of delivery in a real-time application like
this is far more important than efficiency of packing the data into
as few frames as possible), but I personally have never seen an RTP
frame that comes close to approaching standard Ethernet MTU. The
packets are typically more like a couple hundred bytes large.
And of course being UDP, TCP MSS doesn't enter into the
picture, either.
In short, I have a hard time believing that MTU issues are the
underlying cause for many (or even any) VoIP audio delivery
problems...but, as the meme goes, "change my mind"; heh.
-- Nathan
FROM: VoiceOps [mailto:voiceops-boun...@voiceops.org] ON
BEHALF OF Pinchas Neiman via VoiceOps
SENT: Sunday, March 10, 2024 7:29 AM
TO: Alex Balashov
CC: VoiceOps
SUBJECT: Re: [VoiceOps] One Way Audio - Frontier Comm (Los Angeles area)
I have (on a rural area DSL line) a desk phone registered
directly on line 1, and line 2 over the VPN, whenever someone on
line 1 tells me I couldn't hear you well, I am saying calling you
back with another line, every time they will respond immediately
Ah. Now your voice is much better.
TCP connections are also much more reliable over the VPN than direct.
I am using WG over UDP with MTU 80 bytes lower than the
worst case general MTU.
I digged through my issue, and found that some hops in my
long list of local hops (last mile/s) are very unreliable, and not
responding when they drop (crime #1) a big packet even if DF was
set (crime #2), so best for me was to have wireguard do the
fragmentation on my side, as well as signal to the TCP connections
to lower their MSS automatically.
In other cases a VPN will also be able to patch TCP issues
related to asymmetric routing, or firewall timeouts.
To be noted,
#1 VPN device CPU should be fast enough to do the packaging,
as there is usually no hardware assistance for the VPN
prepackaging.. a good gigabit router could easily become a source
of latency when it involves something more than passing/nating
packets between ports
#2 having a VPN without adjusting the MTU (either manually
or automatically) will increase packet loss, this is the source of
the myth that VPN is a overhead for VOIP
My understanding in networking may be flawed but this is my
practical experience accumulated so far.
On Sat, Mar 9, 2024 at 4:00 PM Alex Balashov via VoiceOps
<voiceops@voiceops.org> wrote:
No, it's true, consider me appropriately humbled. I
underappreciated the nuance of this issue. I thought we were
talking about something closer to the physicality of networks, not
packet inspection/filtering/etc.
-- Alex
On 9 Mar 2024, at 08:11, James Cloos <cl...@jhcloos.com> wrote:
"AB" == Alex Balashov writes:
I don't trust last mile networks to reliably deliver SIP calls.
I usually end up putting them into VPNs, TLS, etc.
AB> VPNs and TLS make last-mile networks more reliable? :-)
on the vpn side, wireguard (which runs over udp) certainly does.
I imagine ipsec sometimes can, too. but wg is easier.
-JimC
--
James Cloos <cl...@jhcloos.com>
OpenPGP: https://jhcloos.com/0x997A9F17ED7DAEA6.asc
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800
_______________________________________________
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops
PINCHAS S. NEIMAN
Software Engineer At ESEQ Technology Corp.
845.213.1229 #2
_______________________________________________
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops
