Our calls are hanging up after exactly 17 minutes 28 seconds (that 1048 seconds).
The problem could be:
An asterix configuration
A sip trunk limitation (we use voipvoip)
An ATA configuration (we use Grandstream HT-286)
A firewall issue.
With some more experimentation, the hangup only occurs when the call is initiated from the Grandstream. If the Grandstream answers a call no hangup at 17:28.
I turned on the debugging on the Grandstream and I see an entry from the GS to the asterix server with:
CSeq: 23696 BYE Server: Asterisk PBX 18.104.22.168 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO Supported: replaces, timer C
there is nothing obvious initiating it.
On the server side there is nothing related in the log. I’m using what ever the default logging is.
Does it happen on both, incoming and outgoing calls ?
Are you using a static or dynamic IP ?
Are you only using ATA’s or IP phones as well ?
If so try a soft phone and see what happens, you could try that directly with your provider and cut the Asterisk out of the way and see if that is working.
Or try it on the inside as an extension as well and see if your ATA’s are the problem.
Just a few thoughts to find out what is causing the problem.
I have done more testing. First I determined that it wasn’t the sip trunk, because it occurred from ATA to ATA that didn’t go off the lan with our asterisk server. Then I determined it is related to the ATA’s since softphone to softphone didn’t show the problem.
So its something tied into the Grandstream HT-286’s that is doing it. I don’t see anything relevant in their configuration.
Are your timers turned on in the Grandstream’s ?
One thing to look at.
Another thing to try would be that you put the call on hold before the get hungup on.
Then pick it up again and see if the timer resets.
If it only happens between the ATA’s I would think its something they have negotiated.
Did you try some SIP Debug on the CLI level ?
That should show you the cause for the hang-ups.
Changing the following on the ATA, seems to have fixed this issue:
UAC Specify Refresher: UAS
UAS Specify Refresher: UAS
Force INVITE: YES