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

Mon Mar 11 21:38:38 EDT 2024

  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
>>
>>                      
>>
>>                     
>>
>>                     
>>
>>                     
>
>
>
>  
>
>     
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20240312/04cc9952/attachment-0001.htm>