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)
On 6/10/21 2:30 PM, Mark Wiles wrote:
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?
Strange we’ve not run into this before.
*From:* VoiceOps <voiceops-boun...@voiceops.org> *On Behalf Of *Paul
Timmins
*Sent:* Thursday, June 10, 2021 11:12 AM
*To:* voiceops@voiceops.org
*Subject:* Re: [VoiceOps] "Timeout" on VoIP call traversing Verizon data
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
<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>-
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 <do...@telecurve.com>
<mailto:do...@telecurve.com>
*Sent:* Thursday, June 10, 2021 8:47 AM
*To:* Mark Wiles <mwi...@akabis.com> <mailto:mwi...@akabis.com>
*Cc:* voiceops@voiceops.org <mailto:voiceops@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 <mwi...@akabis.com
<mailto:mwi...@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@voiceops.org <mailto:VoiceOps@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@voiceops.org <mailto:VoiceOps@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,0lTU2lUISJDD-BWIAh8i9ZNV1BctI_e5WRnndWjRKbK_rEeyPJoCaenESpkFzMagsVgQ7r72U2yHhnNS9A_s1dlCqzaL7VhDCRip3ENcLKU,&typo=1>
--
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
<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fwww.clearrate.com&c=E,1,CEUPfZwlMKW9wQAjpa_2W9xFYA6jNImU4RshYfM1wiicejlpOmXseOr4XrC4L63Oh-mJOhufubZeYiHVzvfK2Ox5eQkcDSGYqlcSp_DV-Y3tWK_qYxc4V9OJ&typo=1>
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.
--
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.
_______________________________________________
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops
