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

Thu Jun 10 16:24:48 EDT 2021

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 <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> 
>>
>>
> 
> ---------------------------------------------------------------------------
> Peter Beckman                                                  Internet Guy
> beckman at angryox.com                                 http://www.angryox.com/
> ---------------------------------------------------------------------------
> 
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
> 
> 
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at 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/