Intermittent call drops at 15, 30 minutes

[badbet]

Howdy all, recently we've been having some trouble with outgoing calls getting dropped at the 15 and 30 minute mark, intermittently. I've gone through our call history for the last 90 days and identified 8 calls dropping at exactly 00:15:00. Additionally, I've identified 2 calls dropping at exactly 00:30:00. One of my users reported two dropped calls yesterday, confusingly at 00:15:15 and 00:15:23. More confusingly, I've identified 58 other calls that ended at 00:15 and change, though I don't know if they were dropped or not. I've identified another 14 potentials ending at around 00:30 and change.

We're on 16.0.2.910 (hosted in AWS) using a mix of Yealink T48Gs and T28Ps on an unsupported provider (I know, I know). All the phone's firmware is up to date, as well.

Unfortunately, I'm unable to reproduce the behavior. The running theory is an issue with re-invites but I'm a little in the weeds on that, to be honest. Looking at the traces on the test call, I do see re-invites (I think?) that get acknowledged. On the traces for the dropped calls I see Request: INVITE, followed by Status: 100 Giving a try or Trying, followed by 488 Not Acceptable Here. It looks like 3cx then terminates the call (request: BYE).

Am I missing something obvious? Any thoughts? Thanks in advance.

 

[AWS2P]

if you call internal between 2 extensions is ti possible to call more than 15 or 30 minutes without having call dropped? if so problem is not on 3cx side but with trunk provider. Ask your sip provider if they have set a session timer, if so ask them to remove it , do an outgoing call to test if it solves.

It's most probably related to session expiry or refresh. A common value is 1800 (30 minutes) and the refresh happens at half of that 900 (15 minutes).
There is a signaling error or a failure to negotiate the refresh value.
You may try to change the refresh value to refresh faster than the other side and avoid the issue altogether.

on previous posts with same behavior provider explain why cut calls.
The sip provider sends a "INVITE" command every 15 minutes and the technician said the provider doesn't get an "ACK" on that. Well he switched the "INVITE" after 15 minutes off and now the calls work fine in both directions.

 

[badbet]

if you call internal between 2 extensions is ti possible to call more than 15 or 30 minutes without having call dropped? if so problem is not on 3cx side but with trunk provider. Ask your sip provider if they have set a session timer, if so ask them to remove it , do an outgoing call to test if it solves.

on previous posts with same behavior provider explain why cut calls.
The sip provider sends a "INVITE" command every 15 minutes and the technician said the provider doesn't get an "ACK" on that. Well he switched the "INVITE" after 15 minutes off and now the calls work fine in both directions.

In answer to your first question: I have not been able to reproduce this behavior in any setting. I can't even reproduce it under the same circumstances as the users bringing this issue to my attention. I placed an external test call this morning for 30 minutes without issue.

In answer to your second question: I think this may be culprit but I don't have a compelling argument to support it yet. The traces show re-invites, but then a 488 and 487 after 'trying'.

Were your calls getting dropped consistently at the 15 minute mark?

Thanks for replying, btw!

 

[AWS2P]

on my supported trunk value is set to 300.

I placed an external test call this morning for 30 minutes without issue.

Was it an outgoing call? this problem normally occurs only on outgoing calls

 

[AWS2P]

Which codec do you use on provider side ? perhaps this sip error comes from codec incompatibilities
this this explaination on same code on other system than 3CX
https://www.pbxdom.com/how-to-fix-error-sip-488-not-acceptable-in-cisco-call-manager

 

[badbet]

on my supported trunk value is set to 300.

Was it an outgoing call? this problem normally occurs only on outgoing calls

It was, yes. As far as I know, they've all been outgoing calls.

 

[badbet]

Which codec do you use on provider side ? perhaps this sip error comes from codec incompatibilities
this this explaination on same code on other system than 3CX
https://www.pbxdom.com/how-to-fix-error-sip-488-not-acceptable-in-cisco-call-manager

Both the known-good trunk and the potentially-misbehaving trunk are using the same codecs (G.711 U-law and G729). Before just a second ago their priority was set differently, but for testing purposes I mirrored them both and am on a test call now.

 

[AWS2P]

See also codec on extensions side; apply the same as your sip provider prefer, don't forget to provision phones after change otherwise it's not applied

 

[badbet]

See also codec on extensions side; apply the same as your sip provider prefer, don't forget to provision phones after change otherwise it's not applied

I'll check that too, thanks so much : )

 

[badbet]

So, in looking over the codecs currently in use I'm seeing that the trunk itself uses G.711 U-law and G729. However, in looking over a number of extensions, I'm seeing PCMU, PCMA, G722 and G729. Could this possibly be contributing to the intermittent call drops?

 

[JohnS_3CX]

Hi badbet,

Does your trunk have PBX Delivers audio?

The PBX should transcode in case the phone tries to use a codec that is not supported by trunk in this case.

 

[badbet]

Hi badbet,

Does your trunk have PBX Delivers audio?

The PBX should transcode in case the phone tries to use a codec that is not supported by trunk in this case.

It does, yeah.

 

[AWS2P]

PCMU = G711U-law

 

[bigdessert]

Is your unsupported provider THINQ by chance? I just was testing them out and looking at switching and found an issue. They do a round robin load balance on their A name record. What happens is the call gets setup with IP 1 and then at 15 minutes they send a keepalive re-register request and 3CX does an A lookup again and the reply goes to IP 2 so therefor the call is dropped. The only way around this was to use their SRV record instead of A record. This re-register request would happen right at 15 minutes.