[VoiceOps] One Way Audio - Frontier Comm (Los Angeles area)
Nathan Anderson
nathana at fsr.com
Mon Mar 11 21:53:00 EDT 2024
Sure. I guess I just assumed, given both the thread in question and the
general audience of this list, that the context was understood to be
SIP-signalled, interconnected-to-the-PSTN, real-time VoIP sessions.
-- Nathan
From: Jeff Brower [mailto:jbrower at signalogic.com]
Sent: Monday, March 11, 2024 6:39 PM
To: Nathan Anderson
Cc: voiceops at voiceops.org
Subject: Re: [VoiceOps] One Way Audio - Frontier Comm (Los Angeles area)
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 at 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:jbrower at signalogic.com]
Sent: Monday, March 11, 2024 10:19 AM
To: Nathan Anderson
Cc: voiceops at 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 at 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-bounces at 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 at 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 <cloos at 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 <cloos at 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 at voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops
Pinchas S. Neiman
Software Engineer At ESEQ Technology Corp.
845.213.1229 #2
[AIorK4z1Lx063u893FlkIV1C3aJ]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20240311/1fbf4729/attachment-0001.htm>
More information about the VoiceOps
mailing list