SIP Trunk Errors on SIP 404 and 486

[matp]

Under notifications, I have enabled notifications on SIP Trunk errors. This is because if there is a problem communicating between 3CX and the Trunk, I want to know about it so I can fix it.

However 3CX is notifying me on every 404 (not found) and 486 (busy). I've confirmed with the SIP Trunk provider (Twilio) that these status codes occur during regular dialing activities:

404 (not found)

Twilio tried sending this particular call out via our three different carrier partners, but we received "404 not found" response with Reason: Q.850;cause=1;text="User not Found". This confirms that dialled number +4420<redacted> is not active or not assigned to any user. So the issue is with dialled number. Are you able to reach the same number outside of Twilio?

i.e. the user mis-dialed or just has a number that is no longer in service. In USA telephony you would usually get a: "We're sorry, the number you have dialed is not in service...please check the number and try your call again."

486 (busy here)

This response is created called number is already on a call and gets a second call, their system generates this "486 busy here" response. Twilio receives it from our partner, and we send it back to your PBX. This is expected behaviour, there are no services down when these responses are received.

i.e. the number being called is currently busy (in a call and without call waiting service, etc and no voicemail setup to handle the call). In USA telephony you would usually get a busy tone.

So I would not consider these "real" trunk errors. In the same way that if a user contacts my webserver with a made up URL https://example.com/foo/bar/does/not/exist and I give them a 404 not found...I don't want any alerts to go off...but if there is a server-side error (5xx) or timeout/reachability issues I definitely want to know about it. I guess if every call was a 404 (ie over some percentage threshold of calls through the trunk) that might indicate something is broken in the integration (e.g. numbers not formatted in E.164 by PBX).

This creates a lot of alert fatigue. I can setup an email filter but I risk missing actual Trunk errors. Is there a reason for this? If some people actually want notifications on these types of errors, maybe the alert notification setting could be more granular in 3CX to disable alerting on this class of "errors"?

 

[matp]

A couple other errors that come up regularly as well are:

403 forbidden (usually due to geo restrictions)
484 request incomplete (when the dialed number is obviously too short)

It would be great to surface these to the users dialing since 4xx errors are client/user errors generally.
And would also be great to exclude these types of notifications that are not trunk problems but rather client/user errors.

 

[OlegR_3CX]

Hi there.
Indeed, as you have already noticed, we don't have a filter on the errors for the trunk, and we simply send all of them.
If you can find a way via one of the partners with Gold and above status to post your idea here, feel free to do so.
Have a great day

 

[matp]

Thanks for confirming there isn't a supported way to differentiate/filter routine user/client dialing error conditions from errors that indicate "real" technical problems in the integration/connection between 3CX and the trunk.

I'm tempted to just turn off the notifications and wait for users to report problems since the emails currently get ignored anyway (because usually 100% of them are not real errors and can be ignored) but that wouldn't be very professional if/when the trunk breaks. So I guess we will try to limp along with email filters...but that also isn't ideal.

 

[OlegR_3CX]

You are welcome.
I would also check if your Trunk provider has such a setting and notifications on their side, and could inform you if something is wrong there.
Feel free to let us know

 

[matp]

Yes we have rich monitoring (prometheus exporter) on the trunk provider side which alerts us about various error conditions they observe in their role in the telephony system. However it doesn't help us with errors that are problems from the 3CX perspective (e.g. connectivity issues from 3CX to the trunk).

 

[OlegR_3CX]

I see, thank you for the update but anyway, there is nothing else to advise here.
Have a nice day