Solved Incoming calls started failing 3 days ago, and no audio from external callers

[ITSteve]

Hi,

on Friday the 27th, about 1:15 CST, incoming calls to DID's started dropping, and we cannot hear the audio from external phones - it does not matter if they are inbound or outbound.

I can call the SIP Trunk main number from my cell, the reception's phone will ring, but she cannot hear me.

Internal calls or calls using the Android app work fine.

The call log shows calls from PBX to EndCall.

The Activity log shows several messages:

12/30/2019 11:37:48 AM - Source identification failed: Caller is not identified

12/30/2019 11:37:48 AM - Failed to identify source: several trunks matched by DID only. .... (redacted full info - I am not sure what is 'sensitive' in this so I deleted the details..)

12/30/2019 11:37:48 AM - More than one line have matched by DID only

12/30/2019 11:37:48 AM - The SIP request source identification procedure matches several trunks by DID only.....

12/30/2019 11:37:48 AM - More than one line have matched by DID only

12/30/2019 11:37:46 AM - Source identification failed: Caller is not identified

12/30/2019 11:37:46 AM - Failed to identify source: several trunks matched by DID only. SI-Err Recv Req INVITE from

I have 2 Centurylink trunks that were set up 10 months or so ago. They have matching DID lists. I did update to the latest version of 3CX, 16.0.4.493, last week, but it was earlier in the week.

 

[ITSteve]

Nevermind - rebooting the firewall fixed everything...

 

[eddv123]

There maybe still a fundamental issue with the firewall so I would monitor and see how it performs going forward.

I would check your NAT/port forwarding and SIP ALG/Helper settings comply with what 3CX outline for configuration.

The Android App uses port 5090 which masks VoIP traffic through the firewall including RTP. In this case your standard RTP ports were the issue, so potentially rebooting the firewall freed up some ports possibly.

 

[ITSteve]

you were correct to monitor - it is failing again. It seems to be in the firewall. I made some changes to it (to policies unrelated to the 3cx rules - I thought) about the same time the phones starting having issues.

I have tried several things, including blowing out the 3cx firewall rule and recreating it, but no change. The firewall test is failing with:

• • detecting SIP ALG... detected (sent e6e05736 ≠ 926d532f, received 9b2fe749 ≠ dae8653f) (How to resolve?)
  • testing port 5060... full cone test failed (How to resolve?)
  • starting service... done
• testing 3CX Tunneling Proxy... done
  • stopping service... done
  • testing port 5090... done
  • starting service... done
• testing 3CX Media Server... failed (How to resolve?)
  • stopping service... done
  • testing ports [9000..9398]... failed (How to resolve?)
    • testing port 9000... full cone test failed (How to resolve?)
    • testing port 9002... done

the rest of the ports passed.

I don't have a SIP ALG rule on the watchguard, so I created one but got the same results in the firewall check.

I am using the ports found here: https://www.3cx.com/docs/ports/
and the guide here: https://www.3cx.com/docs/watchguard-xtm-firewall/

I am running v12.4.1 software on the firewall, and 3cx v16.0.4.493.

I am not sure what to test next... Thanks.

 

[ITSteve]

Found it. I was updating some of the packet filter policies to proxy based policies. One of them is a catch all rule allowing most outgoing traffic that does not otherwise have a policy. The proxy was applying the SIP proxy rules and mangling some of the data, causing the SIP ALG to fail.

I set the rule back to the packet filter version and the firewall check is green, and hopefully calls will be flowing.

 

[eddv123]

Great that's really good to hear things are working now. The firewall checker must always pass.

I've installed before with Watchguards (managed by 3rd party IT) and they have been a bit of a pain for me before also.

SIP ALG on would have been altering the SIP message headers which could of been having an effect on where the RTP was either being sent or ports used.