Short answer
Find the call in Cloud Voice > Calls in the Enfonica Console, and open its SIP trace. No reply from your PBX points to the number's call handler, your firewall, or the PBX's IP blacklist. An error from your PBX points to its inbound settings. A call that isn't listed never reached Enfonica.
- Applies to
- Phone Numbers, Cloud SIP
- Works with
- Any SIP PBX or SBC
- Who can do this
- Whoever manages your PBX and your Enfonica project
Check for a known incident first. If there is one, we're already working on it, and there's nothing to change on your side.
Checking Enfonica system status…
Status pageOn this page
What are you seeing?
- Calls to your number never reach your PBX
-
Your PBX receives the call but rejects it
404 Not Found, 486 Busy Here, 603 Decline, or 407 Proxy Authentication Required from your PBX - Calls from some networks never arrive
Calls to your number never reach your PBX
Your PBX (phone system) shows no sign of the call, and callers might hear a busy tone. Start in the Enfonica Console:
- Go to Cloud Voice > Calls, and find the call by the number called and the time. To learn how, see Find a call and read its SIP trace.
- The call appears as two rows: the caller's call to your number (direction Incoming, transport PSTN), and Enfonica's call on to your PBX (direction Outgoing, transport SIP). Open the SIP row.
- Under SIP Insights, select View SIP trace.
- Work through the following causes in order.
If the call isn't in the Console at all, go to Calls from some networks never arrive.
The number's call handler sends calls somewhere else
Each number sends its calls wherever its incoming call handler says. A typo, an old IP address, the wrong port, or a load balancer that has since been deleted sends calls away from your PBX.
Check
Look at the To address of the SIP call, and the INVITE in its SIP trace. This is the cause if they show an address that isn't your PBX's.
Fix
Check the handler and what it points to:
- In the Console, go to Phone Numbers > My numbers, and open the number.
- Under Call settings, look at the SIP handler in Incoming call handlers. It's set to either Load balancer, with a load balancer such as
pbx@example.sip.enfonica.com, or SIP URI, with an address such assip:pbx.example.com. - If it points to a load balancer, go to Cloud SIP, and open your SIP domain. Make sure that the load balancer is listed under Load balancers, and that its Endpoint URI is your PBX's address. If the load balancer isn't listed, it was deleted. Edit the number's handler, and select a load balancer that exists.
- If it's a SIP URI, make sure that the host is your PBX's public hostname or IPv4 address. The URI uses port 5060 unless you add another port, or 5061 if you add
;transport=tls. - Select Save Changes.
The number has no call handler
Check
Look at the call's rows. This is the cause if there's only the caller's row, with no SIP call after it, and it shows the Error code CONFIGURATION and the Error message No incoming call handlers configured.
Fix
- Go to Phone Numbers > My numbers, and open the number.
- In Incoming call handlers, select Add.
- Select SIP, and then select your load balancer or enter your PBX's SIP URI.
- Select Save Changes.
The account has no credit available
Check
Look at the call's rows. This is the cause if there's only the caller's row, and it shows the Error code NO_CREDIT. Outgoing calls fail too.
Fix
Restore service. To learn how, see Why have my services stopped?
Your firewall isn't letting Enfonica's signaling through
Your firewall must accept SIP from both of Enfonica's signaling addresses and let your PBX reply to them.
Check
Open the SIP trace. This is the cause if Enfonica sends the INVITE to the right address several times, with no reply from your PBX.
Fix
Allow these addresses through the firewall in front of your PBX, in both directions. This is a change in your own network.
| Traffic | IP addresses | Ports |
|---|---|---|
| Signaling | 34.87.239.19734.87.254.143 | 5060 (UDP), 5061 (TLS over TCP) |
| Media (call audio) | 35.189.19.10635.189.6.179 | All UDP ports |
If you use UDP on port 5060, also allow fragmented UDP packets, if your firewall can. Long SIP messages are split into fragments, and only the first fragment carries the port number. A rule based on ports alone can drop the rest.
Only one of Enfonica's signaling addresses gets through
Enfonica sends calls from either signaling address. A firewall or port forward that allows only one of them lets some calls through and drops the rest.
Check
Compare the calls that fail with the calls that work. This is the cause if some calls arrive and others don't, and the SIP trace shows that the failed calls all come from one address and the working calls from the other. Another sign is that calls get through only for a short while after your PBX makes an outgoing call. That means your router is letting replies in rather than forwarding new calls.
Fix
Allow both signaling addresses. If your PBX is behind a router, forward UDP port 5060 (or TCP port 5061 for TLS) from both addresses to the PBX.
Your PBX has blocked Enfonica's addresses
Some PBXs, such as 3CX, automatically add an address to an IP blacklist when they see a lot of SIP traffic or failed sign-ins from it. If Enfonica's signaling addresses are on the list, the PBX ignores every call from them.
Check
Look at when calls stopped. This is the cause if calls worked and then stopped with no firewall change, and the SIP trace shows no reply to the INVITE.
Fix
Remove both signaling addresses from your PBX's IP blacklist. Then add them to its IP whitelist so that they aren't blocked again.
Your PBX's public IP address has changed
Cloud SIP doesn't use SIP registration, so it can't learn a new address for your PBX. It sends calls to the address in your load balancer or handler.
Check
Compare the address in the SIP trace with your PBX's address. This is the cause if calls stopped after a change to your internet connection, and the address in the trace is your PBX's old one.
Fix
Update the address in your load balancer or handler. If your PBX's address changes from time to time, give it a dynamic DNS hostname, and use that hostname in the load balancer's Endpoint URI.
Your PBX expects TCP or IPv6
Cloud SIP sends calls over UDP on port 5060 or TLS on port 5061, to a hostname or an IPv4 address. It doesn't use plain TCP or IPv6, so a PBX that listens only for those never sees the call.
Fix
Set your PBX's trunk to UDP, or to TLS with ;transport=tls on the SIP URI. Use a hostname or IPv4 address.
Your PBX receives the call but rejects it
404 Not Found, 486 Busy Here, 603 Decline, or 407 Proxy Authentication Required from your PBX
If the SIP trace shows your PBX answering Enfonica's INVITE with an error, the call reached your PBX, and the PBX turned it away. Callers often hear a busy tone. The fix is in your PBX's inbound settings. To find which setting, look at the response and any Warning header that your PBX adds:
| What your PBX sends | What it usually means |
|---|---|
404 Not Found | The number isn't set up on the PBX in the format Enfonica sends. |
407 Proxy Authentication Required, 403 Forbidden, or a Warning such as 499 "Caller is not identified" (3CX) | The PBX doesn't recognize the call as coming from your Enfonica trunk, or the number isn't set up on it. |
486 Busy Here with Warning: 499 "Disabled by Forwarding Rule" (3CX) | A forwarding or routing rule on the PBX is turning the call away. |
603 Decline from a PBX that hosts several customers | The PBX can't tell which trunk the call belongs to. |
The number isn't set up in the format Enfonica sends
Enfonica sends the number that was called in full international format (E.164), with a plus sign, for example +61255501234. If your PBX's inbound rule or DID (direct inward dialing number) is set up as 0255501234 or 61255501234, it doesn't match, and the PBX rejects the call.
Check
Compare the number in Enfonica's INVITE with your PBX's inbound rules. This is the cause if the number doesn't appear there in exactly the same format, or doesn't appear at all.
Fix
Add the number to your PBX's inbound rules in full international format, with the plus sign. If your PBX needs another format, you can change the number that Enfonica sends. To do this, add a to header to the SIP URI or load balancer address in the number's handler, for example sip:pbx.example.com?to=0255501234.
Your PBX doesn't recognize Enfonica as the trunk
Cloud SIP is an IP-based trunk, so most PBXs are set to accept incoming calls from Enfonica's two signaling addresses as coming from the trunk. When the PBX can't match a call to the trunk, it challenges or rejects it.
Check
Look at your PBX's reply in the SIP trace. This is the cause if your PBX answers the INVITE with 407 Proxy Authentication Required or 403 Forbidden, or if 3CX adds Warning: 499 "Caller is not identified".
Fix
- In your PBX's trunk settings, allow incoming calls from both
34.87.239.197and34.87.254.143, as single addresses (/32). - Make sure that the number is set up in E.164, as described in the previous cause.
- If your PBX must authenticate incoming calls, add its username and password to the load balancer's Endpoint URI. To learn how, see SIP URIs.
A forwarding or routing rule on your PBX turns the call away
Check
Look at your PBX's reply in the SIP trace. This is the cause if your PBX answers 486 Busy Here, and 3CX adds Warning: 499 "Disabled by Forwarding Rule".
Fix
Check where the number's inbound rule in your PBX sends calls. Then check the forwarding rules and office hours of that extension, queue, or ring group.
A shared PBX can't tell which trunk the call is for
When one PBX server hosts several customers, each with its own Enfonica trunk, calls from Enfonica all come from the same two addresses. Some PBXs can't tell from the address alone which customer the call belongs to.
Check
Look at your PBX's reply and its other trunks. This is the cause if your PBX answers 603 Decline, and another trunk on the same server points at the same IP address.
Fix
Give each customer's trunk its own port on the PBX, if your PBX offers that option. Then put the port in the load balancer's Endpoint URI, for example sip:203.0.113.10:5070.
Calls from some networks never arrive
If a call isn't in Cloud Voice > Calls at all, it never reached Enfonica. Nothing in your PBX or your Console settings can change it. The fault is in the caller's network or between carriers, and we raise it for you.
A network fault between the caller and Enfonica
Check
Test with mobiles on two different networks. This is the cause if calls from one network fail, for example from one mobile network, while calls from other networks ring normally.
Fix
Send us a few example calls, with the caller's number, the number they called, and the time. Include the details in What to send us. We'll check the fault and raise it with the carrier responsible. In the meantime, forwarding your number elsewhere in the Console doesn't help, because these calls aren't reaching Enfonica to be forwarded.
The number is new, or has recently ported to Enfonica
Check
Look at when the number was activated or ported. This is the cause if that was recent, and calls from some networks don't arrive.
What if calls arrive but there's no audio?
If calls arrive with no audio, the call's signaling got through, but its audio didn't. Call audio travels separately, from Enfonica's media addresses, so it has its own causes and fixes. For more information, see Calls connect but there's no audio, or audio only one way.
What to send us
Include these and we can find the call straight away.
- The number that made the call and the number it called, in full international format (for example +61255501234).
- The date and time of the call, with your timezone.
- Whether the call was inbound or outbound.
- The call ID, if the Console shows the call.
- What happened: an error message, silence, a busy tone or a dropped call.
Our support team are telco specialists, backed by the engineers who run the network.
Related
Was this helpful?
What was the problem?
Thanks for telling us.