<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">Perimeta's fast register causes it to
      refresh faster than once a minute. It doesn't log this in the SAS,
      but there's a way to verify at the perimeta CLI it's occurring.
      You might want to have your SE verify that the subscriber is being
      detected properly as NAT when on the verizon towers, and if not,
      possibly just force nat all the time on max-uc (since it's really
      rare there will be a max-uc session that's NOT behind a nat)<br>
    </div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">On 6/10/21 2:30 PM, Mark Wiles wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:BN0PR13MB4711958EA09F450B82019B2EAF359@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;}
@font-face
        {font-family:Consolas;
        panose-1:2 11 6 9 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;}
pre
        {mso-style-priority:99;
        mso-style-link:"HTML Preformatted Char";
        margin:0in;
        font-size:10.0pt;
        font-family:"Courier New";}
span.HTMLPreformattedChar
        {mso-style-name:"HTML Preformatted Char";
        mso-style-priority:99;
        mso-style-link:"HTML Preformatted";
        font-family:Consolas;}
span.EmailStyle22
        {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]-->
      <div class="WordSection1">
        <p class="MsoNormal">Since I’m as dumb as a bag of hammers when
          it comes to cellular data… what do you think the NAT timeout
          might standardly be, before the pin-hole goes away?<o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">Strange we’ve not run into this before.<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
              <a class="moz-txt-link-rfc2396E" href="mailto:voiceops-bounces@voiceops.org"><voiceops-bounces@voiceops.org></a> <b>On Behalf Of
              </b>Paul Timmins<br>
              <b>Sent:</b> Thursday, June 10, 2021 11:12 AM<br>
              <b>To:</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>
        </div>
        <p class="MsoNormal"><o:p> </o:p></p>
        <div>
          <p class="MsoNormal">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.<o:p></o:p></p>
        </div>
        <div>
          <p class="MsoNormal"><o:p> </o:p></p>
        </div>
        <div>
          <p class="MsoNormal"><a
href="https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fcommunity.metaswitch.com%2fsupport%2fsolutions%2farticles%2f76000007855-product-advisory-perimeta-and-sip-application-level-gateways-algs&c=E,1,y0GVFh4InJbiGA_p7LsIOQ53DOKFu20uC7tzS2O0aprTQyEoSEYfcuCoPnEPgoDIKx6FG9ffmXeQPB5RVGEhzUKd-y_ZSrmXJR4DmkX-uw,,&typo=1"
              moz-do-not-send="true">https://community.metaswitch.com/support/solutions/articles/76000007855-product-advisory-perimeta-and-sip-application-level-gateways-algs</a>-<o:p></o:p></p>
        </div>
        <div>
          <p class="MsoNormal"><o:p> </o:p></p>
        </div>
        <div>
          <p class="MsoNormal">On 6/10/21 9:18 AM, Mark Wiles wrote:<o:p></o:p></p>
        </div>
        <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
          <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
                href="mailto:dovid@telecurve.com" moz-do-not-send="true">
                <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"
                moz-do-not-send="true"><mwiles@akabis.com></a><br>
              <b>Cc:</b> <a href="mailto:voiceops@voiceops.org"
                moz-do-not-send="true">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-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
              <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>
          <p class="MsoNormal"><br>
            <br>
            <o:p></o:p></p>
          <pre>_______________________________________________<o:p></o:p></pre>
          <pre>VoiceOps mailing list<o:p></o:p></pre>
          <pre><a href="mailto:VoiceOps@voiceops.org" moz-do-not-send="true">VoiceOps@voiceops.org</a><o:p></o:p></pre>
          <pre><a href="https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fpuck.nether.net%2fmailman%2flistinfo%2fvoiceops&c=E,1,0lTU2lUISJDD-BWIAh8i9ZNV1BctI_e5WRnndWjRKbK_rEeyPJoCaenESpkFzMagsVgQ7r72U2yHhnNS9A_s1dlCqzaL7VhDCRip3ENcLKU,&typo=1" moz-do-not-send="true">https://puck.nether.net/mailman/listinfo/voiceops</a><o:p></o:p></pre>
        </blockquote>
        <p><o:p> </o:p></p>
        <pre>-- <o:p></o:p></pre>
        <pre>Paul Timmins<o:p></o:p></pre>
        <pre>Clear Rate Communications<o:p></o:p></pre>
        <pre>Direct: (248) 556-4532<o:p></o:p></pre>
        <pre>Customer Support: (877) 877-4799<o:p></o:p></pre>
        <pre>24 Hour Repair: (866) 366-4665<o:p></o:p></pre>
        <pre>Network Operations: (877) 877-1250<o:p></o:p></pre>
        <pre><a href="https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fwww.clearrate.com&c=E,1,CEUPfZwlMKW9wQAjpa_2W9xFYA6jNImU4RshYfM1wiicejlpOmXseOr4XrC4L63Oh-mJOhufubZeYiHVzvfK2Ox5eQkcDSGYqlcSp_DV-Y3tWK_qYxc4V9OJ&typo=1" moz-do-not-send="true">www.clearrate.com</a><o:p></o:p></pre>
        <pre><o:p> </o:p></pre>
        <pre>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.<o:p></o:p></pre>
        <pre><o:p> </o:p></pre>
        <pre>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.<o:p></o:p></pre>
        <pre><o:p> </o:p></pre>
        <pre>Clear Rate Communications, Inc. 2600 W Big Beaver, Suite 450, Troy, MI 48034.<o:p></o:p></pre>
      </div>
    </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>