Not to muddy the waters here with needless pedantry, but:
While UDP may be "connectionless", the only way UDP, and in particular,
symmetric SIP signalling, can work through NAT is if a stateful firewall
+ NAT gateway has some awareness (that is, state) of UDP "flows", or
groups of packets flowing between ports consistently in some kind of
temporary logical association--one might say, the endpoints have a
"connection" of sorts...
-- Alex
On 6/10/21 4:07 PM, Peter Beckman wrote:
uhhhh.... SIP here is UDP, no?
There's no connection to close for UDP.
The source port for UDP doesn't matter. It's not part of the whole
conversation, unless your switch cares that all communications continue to
come from the source port. It's connectionless.
TCP 5060 isn't even listening on our switches.
So, maybe you're doing SIP over TCP?
On Thu, 10 Jun 2021, 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>
Sent: Thursday, June 10, 2021 8:47 AM
To: Mark Wiles <mwi...@akabis.com>
Cc: 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>
---------------------------------------------------------------------------
Peter Beckman Internet Guy
beck...@angryox.com http://www.angryox.com/
---------------------------------------------------------------------------
_______________________________________________
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops
--
Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
_______________________________________________
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops