Generic SMS clarification

[mmeier]

Hi there,

Trying to figure out SMS delivery reports back to 3cx from our SMSC to get the extra checkmark. I've followed:

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

And am able to send/receive messages perfectly, but would like to implement dlr as well. I might be misinterpreting the wording. Do I:

1) Respond with message.received or message.sent as the 200 response json body to the incoming message and
2) Send message.finalized once delivered back to the 3cx Generic API?

More importantly:

- What is the appropriate response to a message sent by 3cx using Generic SMS?
- What follow-up will show delivery checkmark?

Sorry if I'm misinterpreting the URL above. The wording seems like it's 3cx sending the delivery report, but I think that means it's expecting these.

Clarification is appreciated,

 

[YiannisH_3CX]

Hi @mmeier

More importantly:

- What is the appropriate response to a message sent by 3cx using Generic SMS?
- What follow-up will show delivery checkmark?

I am not an expert by any stretch of the imagination but I believe the appropriate response should be "message.finalised".
Try sending the "message.finalised" message back to 3CX and see if you get the double checkmark.

 

[Evolute IT]

That's for the delivery notification webhook.

 

[mmeier]

Hi @mmeier



I am not an expert by any stretch of the imagination but I believe the appropriate response should be "message.finalised".
Try sending the "message.finalised" message back to 3CX and see if you get the double checkmark.

Thanks, Yiannis. I tried this but 3cx does not appear to be doing anything with delivery receipts.

Here's the full play-through:

The following comes from 3cx to our API:
{ "from": "+1780668xxxx", "to": "+1780916xxxx", "text": "test message" }
(with proper Bearer authorization, etc.)

From here I've attempted to provide DLR either as a json body result to the message, and/or as a reply to the webhook:
{ "data": { "event_type": "message.finalized", "id": "150", "occurred_at": "2023-03-24T15:50:26-06:00", "payload": { "completed_at": "2023-03-24T15:50:26-06:00", "cost": null, "direction": "outbound", "errors": [], "from": { "phone_number": "+1780668xxxx", "status": "webhook_delivered" }, "id": "150", "received_at": "2023-03-24T15:50:26-06:00", "record_type": "message", "sent_at": "2023-03-24T15:50:26-06:00", "text": "next dlr test", "to": [ { "phone_number": "+1780916xxxx", "status": "delivered" } ], "type": "SMS", "webhook_url": "xxx" }, "record_type": "event" }, "meta": { "attempt": "1", "delivered_to": "xxx" } }

I've tried message.sent/finalized/received, and status webhook_delivered/sent/delivered in every combination I could come up with (including multiple options).

Return response is always http code 204 from the 3cx api endpoint so I'm guessing it sees the messages.

I'm at a bit of a loss here. SMS works and I can send/receive no problem to our smsc, but I would like to get delivery confirmation working since we already receive DLR from peers and I can do this asynchronously once I know the recipe.

Maybe this is a bug or DLR isn't working yet? I'm happy to provide access to our pbx and make changes to our api to troubleshoot.

 

[YiannisH_3CX]

Maybe this is a bug or DLR isn't working yet? I'm happy to provide access to our pbx and make changes to our api to troubleshoot.

As I mentioned I am not an expert on this so I cannot tell you exactly what the PBX is expecting but I can confirm DLR is working if set up correctly as we tested with a different custom solution and it worked.

 

[mmeier]

As I mentioned I am not an expert on this so I cannot tell you exactly what the PBX is expecting but I can confirm DLR is working if set up correctly as we tested with a different custom solution and it worked.

From the working custom solution can you share the process for DLR? ie: request/responses, and when? Specifically:

1) Expected response from provider API when outgoing SMS initiated by 3cx? Is it 200 or 204, what's in the response body (if anything)?

2) Any follow-up messages from provider to the 3cx generic API?

I've tried every combination of messages using what's provided in the documentation and something seems to be missing. I agree it's likely working, but the steps and values to provide dlr is what I'm missing. Sending/receiving works fine.

If there's a better avenue for a technical question like a ticket please let me know.

 

[Goga]

From the working custom solution can you share the process for DLR? ie: request/responses, and when? Specifically:

1) Expected response from provider API when outgoing SMS initiated by 3cx? Is it 200 or 204, what's in the response body (if anything)?

2) Any follow-up messages from provider to the 3cx generic API?

I've tried every combination of messages using what's provided in the documentation and something seems to be missing. I agree it's likely working, but the steps and values to provide dlr is what I'm missing. Sending/receiving works fine.

If there's a better avenue for a technical question like a ticket please let me know.

Did you get answer for this I am facing same problem.

 

[mmeier]

Did you get answer for this I am facing same problem.

No, unfortunately. As a carrier we have all this information, but there's currently no documented way to inject this into 3cx. I expect the functionality exists (it's a common feature I know some "supported" providers implement), but I've not been able to connect with the right person to answer this on the forums or through our account manager.

Some things I've tried that might interest you:

• Injecting our UID into the message stream using the provided payloads for MMS
• Variations of delivery based-on timings, message responses, etc.
• Placing DLR messages throughout

Nothing seems to work. SMS messages do work, but DLR for that second checkmark would be ideal.

I'm guessing if you're here you've gotten SMS working like we did. I'm happy to compare notes. Drop me an email at [email protected] and we can discuss. This became an in-demand feature for customers and is something I'm eager to get perfect, second only to getting on the supported provider list so we can sell hosted to smaller clients!