<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">The perimeta should auto-detect the NAT
and start a "fast register" in their parlance. You might want to
look into this and possibly force nat on your MaXUC instead of
using nat autodetect, and make sure fast register is configured.
It will handle keeping the signaling portion open for you.<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><a class="moz-txt-link-freetext" href="https://community.metaswitch.com/support/solutions/articles/76000007855-product-advisory-perimeta-and-sip-application-level-gateways-algs">https://community.metaswitch.com/support/solutions/articles/76000007855-product-advisory-perimeta-and-sip-application-level-gateways-algs</a>-<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 6/10/21 9:18 AM, Mark Wiles wrote:<br>
</div>
<blockquote type="cite"
cite="mid:BN0PR13MB4711D0F6DFA9A72060C18D19AF359@BN0PR13MB4711.namprd13.prod.outlook.com">
<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:"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:"Segoe UI Emoji";
panose-1:2 11 5 2 4 2 4 2 2 3;}
/* 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.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@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]-->
<div class="WordSection1">
<p class="MsoNormal">Hi Dovid,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">So just thinking about this… granted, there
wasn’t SIP traffic for “X” amount of time… but there would
have been RTP… so wouldn’t that have been seen as traffic?<o:p></o:p></p>
<p class="MsoNormal">Hmmm… but as soon as I typed that, SIP
traffic’s on one port… RTP traffic’s on another port… so even
with the RTP flowing along and happy… the SIP’s another
matter… right? Duh! (I’ve not had my coffee yet)<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Are you saying that you’re using Metaswitch
MaX UC and you’re doing a SIP OPTIONS message every 49
seconds?<o:p></o:p></p>
<p class="MsoNormal">I totally agree it does sound like a NAT
pinhole is closing. It would seem that if that’s the case,
Meta would have run into this before and had “recommendations”
to address this.<o:p></o:p></p>
<p class="MsoNormal">I’ll bounce your thoughts off of them.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks!<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Mark<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>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-top:solid #E1E1E1
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Dovid Bender
<a class="moz-txt-link-rfc2396E" href="mailto:dovid@telecurve.com"><dovid@telecurve.com></a> <br>
<b>Sent:</b> Thursday, June 10, 2021 8:47 AM<br>
<b>To:</b> Mark Wiles <a class="moz-txt-link-rfc2396E" href="mailto:mwiles@akabis.com"><mwiles@akabis.com></a><br>
<b>Cc:</b> <a class="moz-txt-link-abbreviated" href="mailto:voiceops@voiceops.org">voiceops@voiceops.org</a><br>
<b>Subject:</b> Re: [VoiceOps] "Timeout" on VoIP call
traversing Verizon data<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">If I had to guess Verizon is using CGNAT
and since there is no traffic for X amount of time the NAT
hole for the SIP traffic is closed. When you send a
re-invite at the 30 minute mark that session as far as
Verizon's CGNAT devices are concerned have been closed a
long time ago. You would need to send a packet to the phone
or have the phone send to your switch some sort of traffic
(we send SIP OPTIONS every 49 seconds) to ensure that the
session stays alive.<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"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Wed, Jun 9, 2021 at 3:27 PM Mark
Wiles <<a href="mailto:mwiles@akabis.com"
moz-do-not-send="true">mwiles@akabis.com</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-right:0in">
<div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">If
there’s a Verizon cellular data guru monitoring here,
I’d love to get your insight!<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Otherwise,
let me toss this out to the group for thoughts and
opinions please…<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">We’re
a Metaswitch shop, and use their MaX UC mobile
softphone client (iPhone/Android).<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">We
had a customer using the MaX UC client on a long call…
they were using Verizon cellular data (confirmed by IP
address).<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">At
thirty (30) minutes into the call, the call
“dropped”. The call was re-established, and again,
after thirty minutes, the call dropped.<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">We’re
pretty sure the user was in a static position
(non-mobile)… and logically
<u>assume</u> they were on the same cell tower for
both calls that dropped (the Verizon IP was the same).<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Looking
at Metaswitch SAS (their diagnostics tool), at the
thirty minute mark, we send out a re-INVITE message to
the softphone client… and we receive no reply… so
after ten seconds, we breakdown the call assuming
they’re gone. Then about eight seconds later, we see
an INVITE message from the softphone’s same IP address
(with the same Call ID)… however, it’s coming from a
different port. So to be clear, the original call
setup and connection was using 1.2.3.4:6789… then
eight seconds after we ended the call with a BYE
(assuming they were gone due to lack of reply), we get
an INVITE (with the same Call ID) from
<a href="http://1.2.3.4:9876" target="_blank"
moz-do-not-send="true">1.2.3.4:9876</a>.<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Metaswitch
looked at the diags from the softphone (we downloaded
them), and they’re confirming that the softphone never
received our re-INVITE at the 30 minute mark.<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Metaswitch
also looked at the bug/crash logs on the softphone,
and confirmed neither was the case.<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">It
almost sounds like a NAT thing going on… but I’m
pretty ignorant when it comes to cellular data. It
looks to me as if the Verizon side simply changed port
numbers, and assumed we’d know maybe via mental
telepathy? <span style="font-family:"Segoe UI
Emoji",sans-serif">
😊</span><o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Has
anyone had experience with such an occurrence… or any
thoughts?<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Thank
you!<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Mark<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
</div>
<p class="MsoNormal">_______________________________________________<br>
VoiceOps mailing list<br>
<a href="mailto:VoiceOps@voiceops.org" target="_blank"
moz-do-not-send="true">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,lh_KPqz2X9PUlHuKPJ5xHOv6u61RFEXqn0IsKcXIj8NwnKlOz0fW5zqT3A9VPfn4xZipprpMy9tXkVyIfmOS7R3SB2CeIgsA5IPv6mEk65Mh92RokKDZDpu9AsXm&typo=1"
target="_blank" moz-do-not-send="true">https://puck.nether.net/mailman/listinfo/voiceops</a><o:p></o:p></p>
</blockquote>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
VoiceOps mailing list
<a class="moz-txt-link-abbreviated" href="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</a>
<a class="moz-txt-link-freetext" href="https://puck.nether.net/mailman/listinfo/voiceops">https://puck.nether.net/mailman/listinfo/voiceops</a>
</pre>
</blockquote>
<p><br>
</p>
<pre class="moz-signature" cols="72">--
Paul Timmins
Clear Rate Communications
Direct: (248) 556-4532
Customer Support: (877) 877-4799
24 Hour Repair: (866) 366-4665
Network Operations: (877) 877-1250
<a class="moz-txt-link-abbreviated" href="http://www.clearrate.com">www.clearrate.com</a>
This message contains confidential information intended only for the use of the intended recipient(s) and may contain information that is privileged. If you are not the intended recipient, or the person responsible for delivering it to the intended recipient, you are hereby notified that reading, disseminating or copying this message is strictly prohibited.
If you have received this message by mistake, please immediately send notification by replying to the message, indicate the message was received by mistake, and then delete the original message immediately thereafter. Thank you.
Clear Rate Communications, Inc. 2600 W Big Beaver, Suite 450, Troy, MI 48034.</pre>
</body>
</html>