Twilio Programmable Voice over SIP

[voxclear]

I use Hosted by 3CX, V20 Update 9, AI Edition. Two Twilio Elastic SIP trunks already work. I need a dedicated inbound trunk to receive calls directly from Twilio Programmable Voice over SIP, preserving the inbound caller's phone number as Caller ID and routing to extension ###.

What supported trunk template, peer/server address, authentication and source-identification settings should we use? Can this use TLS/SRTP alongside the existing Elastic trunks without changing them?

 

[KyriacosS_3CX]

Hello,

I would address this question first to Twilio - they would be to the ones to know if there are special requirements for bringing this calls into 3CX, and what the trunk setup should look like.

 

[voxclear]

Hello,

I would address this question first to Twilio - they would be to the ones to know if there are special requirements for bringing this calls into 3CX, and what the trunk setup should look like.

Thanks—I’ll confirm the sending-side requirements with Twilio. My question for 3CX is specifically about the supported receiving-side authentication and security configuration.

On Hosted by 3CX V20 Update 9, what is the supported method for accepting inbound SIP INVITEs from an external application’s SIP provider?

Can 3CX challenge these inbound calls using SIP digest authentication? If not, what supported source-IP restrictions or other access controls should be used?

How should the calls be uniquely matched to a dedicated inbound trunk alongside existing Twilio Elastic trunks, while allowing the SIP From user to vary with the caller’s number? Can that connection require TLS and SRTP?

I noticed that “Incoming – inbound only” authentication is documented as deprecated, so I’m seeking the supported approach for this setup.

 

[YiannisH_3CX]

3CX does not support Twilio's Programmable Voice trunks so we cannot offer much assistance on this. What I can tell you is that you can have multiple Twilio trunks on the same PBX and that the PBX will accept inbound calls if it's able to match the calls to a trunk.
The PBX should not challenge inbound calls ever unless there is an issue with call source identification. If a parameter is matched then the PBX will accept the call. Have a look at this for more info.

You may also need to create a custom template as the supported Twilio templates are for the Elastic trunks so they may not match.

In theory you can make everything work since these are SIP calls but it might take some tinkering.

 

[voxclear]

3CX does not support Twilio's Programmable Voice trunks so we cannot offer much assistance on this. What I can tell you is that you can have multiple Twilio trunks on the same PBX and that the PBX will accept inbound calls if it's able to match the calls to a trunk.
The PBX should not challenge inbound calls ever unless there is an issue with call source identification. If a parameter is matched then the PBX will accept the call. Have a look at this for more info.

You may also need to create a custom template as the supported Twilio templates are for the Elastic trunks so they may not match.

In theory you can make everything work since these are SIP calls but it might take some tinkering.Thanks

3CX does not support Twilio's Programmable Voice trunks so we cannot offer much assistance on this. What I can tell you is that you can have multiple Twilio trunks on the same PBX and that the PBX will accept inbound calls if it's able to match the calls to a trunk.
The PBX should not challenge inbound calls ever unless there is an issue with call source identification. If a parameter is matched then the PBX will accept the call. Have a look at this for more info.

You may also need to create a custom template as the supported Twilio templates are for the Elastic trunks so they may not match.

In theory you can make everything work since these are SIP calls but it might take some tinkering.

Thanks. I do have it functioning but not with TLS and waiting on Twilio for guidance on the wildcard issue. Progress but not quite in the endzone.

 

[voxclear]

Update after Twilio support investigated the TLS registration failure:

Twilio confirms that account-specific Programmable Voice SIP registration domains use wildcard certificates. They do not offer dedicated exact-name certificates for these domains, and there is no supported generic-registrar or SNI/peer-name override that preserves account-specific registration while satisfying an exact-name certificate check. They advise against bypassing certificate validation.

Our isolated inbound pilot works over TCP/RTP, with the original caller's number displayed and two-way audio. Outbound calling on the test trunk remains disabled, and the two existing Elastic SIP trunks are unchanged. TLS/SRTP remains unresolved.

I understand from your reply that Programmable Voice trunks are outside 3CX's supported integrations, and that the published TLS requirements exclude wildcard certificates. Given Twilio's confirmation, is there a supported architecture for delivering application-originated calls securely to Hosted by 3CX V20, preserving the original caller's number? For example, would this require a supported provider/trunk service or an independently managed SIP gateway presenting an exact-name certificate, and would either be supported with Hosted by 3CX?

If there is no supported secure path for this design, confirmation of that boundary would help us choose an alternative. We are not seeking a certificate-validation bypass.