DID Issues with SMS

[RHopkinson]

We have SMS configured and working for selected extensions. SMS works fine when we add the user's DID to their extension in e164 format (e.g., +13205551212), but that does not allow inbound calls to ring to their extension (the inbound rule apparently doesn't match the e164 formatted version). If we use a wildcard DID (e.g., *3205551212), then inbound calls get routed fine, and SMS texts can be received and replied to, but SMS messages cannot be initiated from the 3CX app; we get the below message in the event log:

Failed to send message(s) to the provider 'generic' from '*3205551212' to '+13205551234'. Exception: {"detail":"Your account or DID are not up for Messaging"}

If we add the DID to the extension in both formats, then everything works, but the user is prompted to select between the e164 and wildcard-formatted DIDs when sending for the first time.

Is there a way to configure things so inbound calls route to the extension and SMS messages can be initiated without having the user select the e164 format from multiple DIDs?

Thanks,
Russell

 

[Charles_3CX]

Regarding your question, First, check the guide for setting up the DIDs and the requirements: https://www.3cx.com/docs/sip-trunk/bandwidth-usa/

Then, Ensure the trunk settings within the 3CX system have not been modified and are set as per the default template. Add another bandwidth template in 3CX to check for any differences.

The DID numbers need to be in E164 format for SMS to work, and if using the default values for the trunks settings, particularly the inbound parameters, you should not have any issues.

 

[RHopkinson]

Thanks for the reply, @Charles_3CX. The link you provided seems to be specific to Bandwidth configuration, and it mentions nothing about DIDs. We're using SIPTrunk.com (Flowroute), and their documentation advises changing the inbound parameters: https://support.siptrunk.com/hc/en-us/articles/15073951631899-3CX-V18-and-SMS.

If I can distill this issue down to one question, how do we get voice call routing to go to the extension using an e164 format instead of a wildcard format? If that can be answered, I believe that would address all of the concerns.

 

[Charles_3CX]

You would need to check the inbound parameters of the SIP trunks settings to ensure they match the screenshot below and ensure that flowroute sends the number in the 'To user part' of the invite header in E164 format. You can check under the flowroute portal for this part.

 

[RHopkinson]

But that contradicts what they have in the document link I posted:

 

[Charles_3CX]

The default settings are as per the screenshot in my last reply, the guide you are checking from in not a 3CX guide and is from a siptrunk.com and not flowroute even, which is also incorrect.

 

[RHopkinson]

Changing the "CalledNum" value in the trunk from Request Line URI: User Part to To: User Part resolved the issue.

 

[Charles_3CX]

Glad to be of assistance.