No POST request being sent to API endpoint

[iaindooley]

Hi there,

I'm trying to develop an integration with the SMS API.

I have a 3CX Pro Trial set up, so I can add a generic Trunk Provider, and I can enable SMS.

I have connected the system to my VoIP trunk, and calls in and out are working.

I created a DID and assigned it to a user:



I enabled SMS on the SIP trunk and put the URL in for my server:



When I send messages, a little red "x" appears immediately, and no POST request is being sent to my URL:



If I hit the URL from my web browser, I can see the request come through and it gets logged. When I send these messages from 3CX, nothing is logged, no request is arriving at my server.

From this documentation:

https://www.3cx.com/docs/supported-sip-trunk-requirements/#h.w02k8u3rrerk

There doesn't appear to be anything else I'm supposed to do in order to set up messaging.

Can anyone see what I've missed?

 

[TheodorosG_3CX]

Have you followed the guideline below?
• https://www.3cx.com/docs/supported-sip-trunk-requirements/#h.z7xet9uflkmo

 

[iaindooley]

I'm not up to that bit yet, because I'm not even seeing the POST request reach my server.

So yes, I am aware of those guidelines, and when I can get a POST request sent to my server, then I can develop against those requirements.

But the first step is to have the POST sent to my server when I attempt to send a message, and that is not happening.

 

[TheodorosG_3CX]

I would suggest that you set the PBX in verbose, close any open conversation that you have tested, then make some more tests and check the management console log.

 

[iaindooley]

Okay, I was looking for how to set to verbose mode, and I saw "Event Log".
I clicked on that and I saw the error:

Failed to send message(s) to the provider 'generic' from '0000' to '+614xxxxxxx'. Exception: Cannot find provider for number 0000

0000 is the "Main Trunk Number" of the SIP Trunk.

I have created a DID and assigned it to the user from which I am attempting to send the messages:



What else do I need to do in order to prevent messages from sending from the "Main Trunk Number"?

 

[TheodorosG_3CX]

This is exactly the case, the main trunk number must be in E164 format.

 

[iaindooley]

But I don't want to send from the main trunk number, I want to send from the DID I have assigned to the user.

For example, there might be dozens of users each with their own DID assigned.

 

[TheodorosG_3CX]

This is also documented:



Even the main trunk number must be in E164 format.

 

[iaindooley]

Sure, but what does that matter if I don't want to send from the main trunk number?

I have a DID assigned that is in the correct format, as I have shown you in my screenshot.

The trouble is not that the main trunk number is incorrectly formatted, the trouble is that the system is attempting to send from the main trunk number.

 

[TheodorosG_3CX]

Correct because the SMS is enabled for the main trunk number and the webhook is for that number.

 

[iaindooley]

Okay thanks so in my screenshot I showed you I have added multiple DID numbers. I have assigned a DID number to a user.

How does that user then send from that DID number, instead of sending from the main trunk number?

 

[TheodorosG_3CX]

Multiple DID's can be used for inbound SMS and route directly to an extension or group. External SMS will always use the main trunk number.

 

[iaindooley]

So you're saying that if I want to add, say, 30 different users, each with their own unique mobile number in the system from which they should be able to send messages, then I need to add 30 different trunks, because outbound SMS will only ever go from the main trunk number? And then for each trunk I just put in the same SMS endpoint configuration?

That really doesn't seem right.

 

[iaindooley]

I found that if you click on the SMS icon on the right, each DID assigned to the user shows up as a different "Provider". There you can select from which sender the message should originate.

As per a different thread I have found that replies to inbound messages will automatically go out from the correct DID on which the message was originally received, but that you can't see in the interface any distinction that indicates which DID is being used.

Anyway this one at least is fixed!