Solved Patton M-ATA Calls Drop at Exactly 15 Minutes

Status
Not open for further replies.

mr_michael

SOHO User
Joined
Nov 14, 2020
Messages
3
Reaction score
2
Hi all,

I'm brand new to this. I've seen other posts suggest this problem is due to the "SIP Session Timer" timeout, but I am not sure how or why this would be happening, or how to fix that type of issue yet...

When I place a call to an extension that uses one of these Patton M-ATA gateways, the 3CX log shows the following entry immediately after the handset is picked up:

11/15/2020 4:33:25 PM - [CM503003]: Call(C:7): Call to <sip:[email protected]:0> has failed; Cause: 487 Request Terminated/INVITE from 127.0.0.1:5483

In this case, I'm calling extension 000 (a smartphone that runs the 3CX app) from an extension that uses one of the Patton M-ATA gateway devices.

But the call has not "failed" yet though. All audio works, and call quality is excellent. Then exactly 15 minutes into the call, the connection drops.

The network router does not have any SIP features enabled, no proxy, nothing like that. The firewall tool on the 3CX dashboard shows that everything looks good in that regard.

Over on the Patton M-ATA, it has none of the SIP Extensions checked, and SIP Parameters are all default, set to SIP T1: 500, SIP T2: 4000, and SIP T4: 5000. It is configured with the SIP Registration Server Address of the 3CX server, port 5060, and SIP Domain is also set to the IP of the 3CX server. Only the "Send Registration with Expire Time: 3600" is checked and set. NAT Traversal is set to NONE, and we're not using a VoIP VLAN Configuration at this time.

We also have a Patton 4114 which connects to our POTS lines, and I'm not seeing any problems. There are no 15 minute or 30 minute timeouts as would be expected if there were a similar problem. I registered a pair of smartphones that use the 3CX app and have been able to make calls longer than 15 minutes via the trunk lines on the 4114 without a problem. For this reason, I suspect it is a configuration issue with the M-ATA, but I haven't been able to identify it yet.

Any help in identifying the issue is greatly appreciated. I can provide more info as needed. Thanks!
 
As is usually the case when giving up and posting to a forum, I solved the problem myself shortly afterward. :)

I didn't think to look in the extensions configuration before this, but when I disabled the "re-invite" option in troubleshooting on 3CX for the extensions assigned to the M-ATAs, and I no longer see the error in the log, and calls no longer drop after 15 minutes.

I've been on the same call now for over 30 minutes and no issue anymore. I can still flash the call to activate features like hold, so nothing is broken either.

This is solved, and I hope this helps someone else who faces this rather ambiguous but seemingly very common problem. I realize there may be many reasons for this issue that are sometimes more complicated to solve, but I haven't seen this recommended in the solutions I've read.

Thanks for reading through this in any case.
 
Perhaps my last posting was premature- the problem returned unexpectedly later on, so it was apparently intermittent. I ran a capture with the built-in tcpdump tool, which revealed the M-ATA was receiving a BYE at 15 minutes which terminated the call. There was clearly a timeout occurring, but with no time for me to dig into this any further, my ultimate solution was to buy a pair of Grandstream GS-HT802s to replace the M-ATAs, as these devices are officially supported by 3CX's integrated configuration generation tool and cost 1/3 the price.

I deployed them today and they work perfectly.

This is the final solution.

Thanks.
 
  • Like
Reactions: JohnS_3CX and N_G
Status
Not open for further replies.

Forum statistics

Threads
111,974
Messages
590,081
Members
164,899
Latest member
mazet