[VoiceOps] "Timeout" on VoIP call traversing Verizon data

Thu Jun 10 11:12:13 EDT 2021

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.

https://community.metaswitch.com/support/solutions/articles/76000007855-product-advisory-perimeta-and-sip-application-level-gateways-algs-

On 6/10/21 9:18 AM, Mark Wiles wrote:
>
> Hi Dovid,
>
> 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?
>
> 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)
>
> Are you saying that you’re using Metaswitch MaX UC and you’re doing a 
> SIP OPTIONS message every 49 seconds?
>
> 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.
>
> I’ll bounce your thoughts off of them.
>
> Thanks!
>
> Mark
>
> *From:* Dovid Bender <dovid at telecurve.com>
> *Sent:* Thursday, June 10, 2021 8:47 AM
> *To:* Mark Wiles <mwiles at akabis.com>
> *Cc:* voiceops at voiceops.org
> *Subject:* Re: [VoiceOps] "Timeout" on VoIP call traversing Verizon data
>
> 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.
>
> On Wed, Jun 9, 2021 at 3:27 PM Mark Wiles <mwiles at akabis.com 
> <mailto:mwiles at akabis.com>> wrote:
>
>     If there’s a Verizon cellular data guru monitoring here, I’d love
>     to get your insight!
>
>     Otherwise, let me toss this out to the group for thoughts and
>     opinions please…
>
>     We’re a Metaswitch shop, and use their MaX UC mobile softphone
>     client (iPhone/Android).
>
>     We had a customer using the MaX UC client on a long call… they
>     were using Verizon cellular data (confirmed by IP address).
>
>     At thirty (30) minutes into the call, the call “dropped”.  The
>     call was re-established, and again, after thirty minutes, the call
>     dropped.
>
>     We’re pretty sure the user was in a static position (non-mobile)…
>     and logically _assume_ they were on the same cell tower for both
>     calls that dropped (the Verizon IP was the same).
>
>     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 1.2.3.4:9876
>     <http://1.2.3.4:9876>.
>
>     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.
>
>     Metaswitch also looked at the bug/crash logs on the softphone, and
>     confirmed neither was the case.
>
>     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? 😊
>
>     Has anyone had experience with such an occurrence… or any thoughts?
>
>     Thank you!
>
>     Mark
>
>     _______________________________________________
>     VoiceOps mailing list
>     VoiceOps at voiceops.org <mailto:VoiceOps at voiceops.org>
>     https://puck.nether.net/mailman/listinfo/voiceops
>     <https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fpuck.nether.net%2fmailman%2flistinfo%2fvoiceops&c=E,1,lh_KPqz2X9PUlHuKPJ5xHOv6u61RFEXqn0IsKcXIj8NwnKlOz0fW5zqT3A9VPfn4xZipprpMy9tXkVyIfmOS7R3SB2CeIgsA5IPv6mEk65Mh92RokKDZDpu9AsXm&typo=1>
>
>
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops

-- 
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
www.clearrate.com

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20210610/e917447a/attachment-0001.htm>