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

Mon Mar 11 19:54:40 EDT 2024

"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, you still aren't going to be running into that.  So the whole TCP 
encap thing seems like a non sequitur to me?

(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/353902ca/attachment.htm>