[VoiceOps] One Way Audio - Frontier Comm (Los Angeles area)

[Nathan Anderson]

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/9fc4bf1e/attachment.htm>