<div dir="ltr"><div dir="ltr">Mark,<div><br></div><div>We are not using MetaSwitch. What I am saying is because we ran into this issue in the past the only thing we found to get around it was to send OPTIONS every 60 seconds. In the past we have used TCP and we actually had a lot more problems with TCP then UDP (I never dug too much into it to see why, simply moving to UDP fixed it). Does meta have an option to use an alternate port? A lot of carriers have "issues" with 5060.</div><div><br></div><div><br></div><div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 10, 2021 at 9:21 AM Mark Wiles <<a href="mailto:mwiles@akabis.com">mwiles@akabis.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div lang="EN-US" style="overflow-wrap: break-word;">
<div class="gmail-m_-8866493012700775176WordSection1">
<p class="MsoNormal">Hi Dovid,<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></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?<u></u><u></u></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)<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></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?<u></u><u></u></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.<u></u><u></u></p>
<p class="MsoNormal">I’ll bounce your thoughts off of them.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Thanks!<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Mark<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in">
<p class="MsoNormal"><b>From:</b> Dovid Bender <<a href="mailto:dovid@telecurve.com" target="_blank">dovid@telecurve.com</a>> <br>
<b>Sent:</b> Thursday, June 10, 2021 8:47 AM<br>
<b>To:</b> Mark Wiles <<a href="mailto:mwiles@akabis.com" target="_blank">mwiles@akabis.com</a>><br>
<b>Cc:</b> <a href="mailto:voiceops@voiceops.org" target="_blank">voiceops@voiceops.org</a><br>
<b>Subject:</b> Re: [VoiceOps] "Timeout" on VoIP call traversing Verizon data<u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></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.<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Wed, Jun 9, 2021 at 3:27 PM Mark Wiles <<a href="mailto:mwiles@akabis.com" target="_blank">mwiles@akabis.com</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal">If there’s a Verizon cellular data guru monitoring here, I’d love to get your insight!<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">Otherwise, let me toss this out to the group for thoughts and opinions please…<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">We’re a Metaswitch shop, and use their MaX UC mobile softphone client (iPhone/Android).<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">We had a customer using the MaX UC client on a long call… they were using Verizon cellular data (confirmed by IP address).<u></u><u></u></p>
<p class="MsoNormal">At thirty (30) minutes into the call, the call “dropped”. The call was re-established, and again, after thirty minutes, the call dropped.<u></u><u></u></p>
<p class="MsoNormal">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).<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">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">1.2.3.4:9876</a>.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">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.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">Metaswitch also looked at the bug/crash logs on the softphone, and confirmed neither was the case.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">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><u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">Has anyone had experience with such an occurrence… or any thoughts?<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">Thank you!<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">Mark<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
<p class="MsoNormal">_______________________________________________<br>
VoiceOps mailing list<br>
<a href="mailto:VoiceOps@voiceops.org" target="_blank">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">https://puck.nether.net/mailman/listinfo/voiceops</a><u></u><u></u></p>
</blockquote>
</div>
</div>
</div>
</blockquote></div></div>