<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>"Only if it was encapsulated over some form of TCP"<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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, <u>maybe</u> if you are aggregating audio transmissions into 150ms+ sized frames, but...that seems like a bad idea?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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 <u>increases</u> the chance of success, since at least MSS negotiation is something that you have <u>some</u> 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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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 <u>absurdly</u> low MTU like ~500 <u>and</u> your PMTUd messages are getting eaten by a grue somewhere in the middle, you <u>still</u> aren't going to be running into that. So the whole TCP encap thing strikes me as a <i>non sequitur</i>?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>(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.)<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>-- Nathan<o:p></o:p></span></p><p class=MsoNormal><a name="_MailEndCompose"><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></a></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Jeff Brower [mailto:jbrower@signalogic.com] <br><b>Sent:</b> Monday, March 11, 2024 10:19 AM<br><b>To:</b> Nathan Anderson<br><b>Cc:</b> voiceops@voiceops.org<br><b>Subject:</b> Re: [VoiceOps] One Way Audio - Frontier Comm (Los Angeles area)<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p><span style='font-size:5.5pt;font-family:"Arial","sans-serif"'>Hi Nathan-<br><br>> </span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>In short, I have a hard time believing that MTU issues are the underlying<br>> cause for many (or even any) VoIP audio delivery problems</span><span style='font-size:5.5pt;font-family:"Arial","sans-serif"'><br><br>Only if it was encapsulated over some form of TCP.<br><br></span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>> VoIP audio streams other than PCMU-encoded ones, so perhaps it's<br>> possible other codecs are different</span><span style='font-size:5.5pt;font-family:"Arial","sans-serif"'><br><br></span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>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.<br><br>-Jeff</span><span style='font-size:5.5pt;font-family:"Arial","sans-serif"'><br><br>Quoting Nathan Anderson via VoiceOps <<a href="mailto:voiceops@voiceops.org">voiceops@voiceops.org</a>>:<o:p></o:p></span></p><blockquote style='border:none;border-left:solid blue 1.0pt;padding:0in 0in 0in 5.0pt;margin-left:.75pt;margin-top:5.0pt;margin-bottom:5.0pt'><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>But...</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>And of course being UDP, TCP MSS doesn't enter into the picture, either.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>-- Nathan</span><o:p></o:p></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b> <span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>VoiceOps [<a href="mailto:voiceops-bounces@voiceops.org">mailto:voiceops-bounces@voiceops.org</a>] <b>On Behalf Of</b> Pinchas Neiman via VoiceOps<br><b>Sent:</b> Sunday, March 10, 2024 7:29 AM<br><b>To:</b> Alex Balashov<br><b>Cc:</b> VoiceOps<br><b>Subject:</b> Re: [VoiceOps] One Way Audio - Frontier Comm (Los Angeles area)</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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.<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>TCP connections are also much more reliable over the VPN than direct.<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>I am using WG over UDP with MTU 80 bytes lower than the worst case general MTU.<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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.<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>In other cases a VPN will also be able to patch TCP issues related to asymmetric routing, or firewall timeouts.<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>To be noted, <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>#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<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>#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<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>My understanding in networking may be flawed but this is my practical experience accumulated so far.<o:p></o:p></p></div></div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>On Sat, Mar 9, 2024 at 4:00 PM Alex Balashov via VoiceOps <<a href="mailto:voiceops@voiceops.org">voiceops@voiceops.org</a>> wrote:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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.<br><br>-- Alex<br><br>> On 9 Mar 2024, at 08:11, James Cloos <<a href="mailto:cloos@jhcloos.com" target="_blank">cloos@jhcloos.com</a>> wrote:<br>><br>>>>>>> "AB" == Alex Balashov writes:<br>><br>>>> I don't trust last mile networks to reliably deliver SIP calls. I usually end up putting them into VPNs, TLS, etc.<br>><br>> AB> VPNs and TLS make last-mile networks more reliable? :-)<br>><br>> on the vpn side, wireguard (which runs over udp) certainly does.<br>><br>> I imagine ipsec sometimes can, too. but wg is easier.<br>><br>> -JimC<br>> --<br>> James Cloos <<a href="mailto:cloos@jhcloos.com" target="_blank">cloos@jhcloos.com</a>><br>> OpenPGP: <a href="https://jhcloos.com/0x997A9F17ED7DAEA6.asc" target="_blank">https://jhcloos.com/0x997A9F17ED7DAEA6.asc</a><br><br>--<br>Alex Balashov<br>Principal Consultant<br>Evariste Systems LLC<br>Web: <a href="https://evaristesys.com" target="_blank">https://evaristesys.com</a><br>Tel: +1-706-510-6800<br><br>_______________________________________________<br>VoiceOps mailing list<br><a href="mailto:VoiceOps@voiceops.org" target="_blank">VoiceOps@voiceops.org</a><br><a href="https://puck.nether.net/mailman/listinfo/voiceops" target="_blank">https://puck.nether.net/mailman/listinfo/voiceops</a><o:p></o:p></p></blockquote></div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b>Pinchas S. Neiman</b><br>Software Engineer At ESEQ Technology Corp.<br>845.213.1229 #2<o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><img border=0 width=200 height=68 id="_x0000_i1030" src="https://ci3.googleusercontent.com/mail-sig/AIorK4z1Lx063u893FlkIV1C3aJbVPjgKnaA2Xu8q_iPdyFOnK_JX05usgghpAIwmPqB-1t-3fdaShNHoCPf7fFwa1twYZt-xjsBZheqmsCQrg"><o:p></o:p></p><p><span style='font-size:5.5pt;font-family:"Arial","sans-serif"'> <o:p></o:p></span></p></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></blockquote><p><span style='font-size:5.5pt;font-family:"Arial","sans-serif"'><br><br><br><o:p></o:p></span></p></div></body></html>