Solved Twilio inbound — all calls unanswered, "terminated by rule"

[fl_tech]

I'm testing a hosted 3CX Pro instance as a replacement for self-supported Elastix.

I have what I believe to be the correct setup in place for a Twilio 'elastic trunk.'

Calls are reaching 3CX successfully (and the trunk shows as registered using IP authentication only) but are then unanswered.

This happens whether I try to send all calls from the Trunk/DID to an IVR, to a queue, to a ring group or directly to a voicemail box.

I have added the phones I'm calling from to the 'verified numbers' (due to trial restrictions).

The call log shows:

Unanswered

0.00

Terminated by rule

On the phone I hear "you have reached a non-working number. Announcement 909."

I can't find any settings that would explain this behavior across all possible destinations. In particular, you'd expect sending calls directly to voicemail would just work unless something else is wrong. Is there some built-in test destination I can use to rule out trunk config issues? A talking clock?

 

[fl_tech]

On the Twilio side the call is failing with 410 GONE (which is not a status I've encountered in SIP before, I promise I'm right here), and there are no RTP statistics or codec shown.

Does the trunk require user/pw registration? It's refusing to register with the creds configured in Twilio, if so. But other threads here suggest otherwise (like https://www.3cx.com/community/threads/cant-get-twilio-to-register-its-sip-trunk.69718/ )

Per refs:

• 410 Gone = The user existed once, but is not available here any more.

Twilio sees the call dropped while 'ringing:'

2024-02-18 08:36:10	connection: initiated
2024-02-18 08:36:10	connection: ringing

 

[fl_tech]

OK, the destination set on the Trunk page itself (End Call) was overriding the rule set in Call Handling (binding that Trunk to a destination).

Which is not the behavior I expected, but at least it's working now.

Does this always have to be manually set in both locations to the same thing? I don't get it.

 

[YiannisH_3CX]

You probably have your DIDs added in the wrong number format so calls end up in the catch all destination. If you haven't already add your DIDs in the E164 format (with the leading +) and try again.

 

[fl_tech]

Close! There was a space between the +1 and the rest of the number. I copied it directly from Twilio's status page without thinking about the whitespace. And then looked right past it.

Is there logging somewhere that would have tipped me off to this? I tried setting a higher log level and didn't see anything, but maybe I'm looking in the wrong place for the equivalent of Asterisk core and SIP debug messages that would show me the call progress and dialplan matching.