<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 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@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;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.apple-converted-space
{mso-style-name:apple-converted-space;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.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" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">My concern right now is this issue has only been reported happening twice… to the same person, coming (most likely) off the same cell site (we think he was stationary). One call right after the other.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">My wholesale partner that complained about it made a stink (as it was his boss that it happened to)… and pretty much knee-jerked in their reaction.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I’ve requested they try to replicate… and hear nothing back.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">So I don’t want to knee-jerk myself to something that may simply be a one-off situation. But all the replies and comments seem valid for consideration and chats with Metaswitch… I mean Microsoft, if it happens again.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Any thoughts why maybe it would happen on one cell site?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> VoiceOps <voiceops-bounces@voiceops.org> <b>On Behalf Of
</b>Paul Timmins<br>
<b>Sent:</b> Thursday, June 10, 2021 10:33 PM<br>
<b>To:</b> Matthew Crocker <matthew@corp.crocker.com><br>
<b>Cc:</b> VoiceOps <voiceops@voiceops.org><br>
<b>Subject:</b> Re: [VoiceOps] "Timeout" on VoIP call traversing Verizon data<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The metaswitch way is that it will do it automatically for you if it thinks you're behind a NAT. So if you force nat, it will do the fast registration automatically. It's one line of config on the sip adjacency for the MaxUC application.<o:p></o:p></p>
<div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On Jun 10, 2021, at 5:33 PM, Matthew Crocker <<a href="mailto:matthew@corp.crocker.com">matthew@corp.crocker.com</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">The acme/oracle way of doing Hosted NAT Traversal is to set the expire time down to 30 seconds and have the phones REGISTER every 30 seconds. The SBC eats the registration so it doesn’t overload the switch. If the CGN NAT drops the
entry it gets recreated with the new registration in 30 seconds.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">We have had very good results with the acme/oracle approach<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <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="margin-bottom:12.0pt"><b><span style="font-size:12.0pt">From:<span class="apple-converted-space"> </span></span></b><span style="font-size:12.0pt">VoiceOps <<a href="mailto:voiceops-bounces@voiceops.org">voiceops-bounces@voiceops.org</a>>
on behalf of Pete Mundy <<a href="mailto:pete@mac.geek.nz">pete@mac.geek.nz</a>><br>
<b>Date:<span class="apple-converted-space"> </span></b>Thursday, June 10, 2021 at 5:11 PM<br>
<b>To:<span class="apple-converted-space"> </span></b>VoiceOps <<a href="mailto:voiceops@voiceops.org">voiceops@voiceops.org</a>><br>
<b>Subject:<span class="apple-converted-space"> </span></b>Re: [VoiceOps] "Timeout" on VoIP call traversing Verizon data</span><o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal">CAUTION: This email originated from outside of Crocker. Do not click links or open attachments unless you recognize the sender and know the content is safe.<br>
<br>
<br>
Precisely. And those "NAT table entries" eventually time out. On CG-NAT they often time out aggressively; <60 seconds. Hence sending OPTIONS over SIP over UDP regularly keeps the NAT table entries refreshed and active and therefore the UDP 'connection' open.
I've come across firewalls with 30 second timeouts, so we use 25 second keepalives (OPTIONS).<br>
<br>
Pete<br>
<br>
>> On 11/06/2021, at 8:24 AM, Alex Balashov <<a href="mailto:abalashov@evaristesys.com">abalashov@evaristesys.com</a>> wrote:<br>
>><br>
>> Not to muddy the waters here with needless pedantry, but:<br>
>><br>
>> While UDP may be "connectionless", the only way UDP, and in particular, symmetric SIP signalling, can work through NAT is if a stateful firewall + NAT gateway has some awareness (that is, state) of UDP "flows", or groups of packets flowing between ports
consistently in some kind of temporary logical association--one might say, the endpoints have a "connection" of sorts...<br>
>><br>
>> -- Alex<br>
>><br>
> On 6/10/21 4:07 PM, Peter Beckman wrote:<br>
> uhhhh.... SIP here is UDP, no?<br>
> There's no connection to close for UDP.<br>
> The source port for UDP doesn't matter. It's not part of the whole<br>
> conversation, unless your switch cares that all communications continue to<br>
> come from the source port. It's connectionless.<br>
> TCP 5060 isn't even listening on our switches.<br>
> So, maybe you're doing SIP over TCP?<br>
> On Thu, 10 Jun 2021, Mark Wiles wrote:<br>
_______________________________________________<br>
VoiceOps mailing list<br>
<a href="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</a><br>
<a href="https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fpuck.nether.net%2fmailman%2flistinfo%2fvoiceops&c=E,1,kvVaS9pSziMPuDe30EPcCHGNL6NIIJPndV3CtkyMITGNN_cGCOPJ3AUW9BY-HNqhC5s3LiGgqgJZgwUxdGUxpDfu0pHj3iG3NYMCaKn8wA_83b-IWu8,&typo=1">https://puck.nether.net/mailman/listinfo/voiceops</a><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">_______________________________________________<br>
VoiceOps mailing list<br>
</span><a href="mailto:VoiceOps@voiceops.org"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">VoiceOps@voiceops.org</span></a><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><br>
</span><a href="https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fpuck.nether.net%2fmailman%2flistinfo%2fvoiceops&c=E,1,ltLSR8uOxno5EmVwUpGymJ9ggTdhEg824ShElI2GvkfI2yaycXvNm5o7FVRNbXCaqKzdhziKfdH676nufSvtSiFOTXmaqw8FufmlN17fy3ZX8Rsd7QSiL0X_&typo=1"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">https://puck.nether.net/mailman/listinfo/voiceops</span></a><o:p></o:p></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</body>
</html>