Unsupported SMS?

[Bswenson]

Ok with the current version 18.0 build 5 the only place SMS now shows up is under the SIP trunk and only if a "Supported" option is selected. There is no SMS option if "Generic" trunk is selected. Of course I can select a "Supported" option and simply enter the url/ip and make calls work without any issues thus far. I am testing the inbound functionality with the web hook, however, How/Has/Can you "hack" or edit the settings of the outbound get/post url that is coded in to that provider selection so I can point it to the proper gateway I need. I can plug in the API key but that obviously isnt going to work since the outbound URL would be incorrect.
Note. Using a Dedicated Enterprise Version of 3CX

 

[YiannisH_3CX]

Hi @Bswenson

I would recommend using a Preferred /Supported provider for SMS and not hack the template to you can use an untested provider.
Ability to test unsupported providers using the Generic template will be delivered down the line, probably in Update 7.

 

[Bswenson]

Hi @Bswenson

I would recommend using a Preferred /Supported provider for SMS and not hack the template to you can use an untested provider.
Ability to test unsupported providers using the Generic template will be delivered down the line, probably in Update 7.

I totally get the encouragement to use the supported options.....But we have our own SIP trunks and provide service to customers already. Not looking for a retail solution or other provider as we are ultimately the provider but not the SIP trunk provider. The cost we have in our current arrangement simply cant be matched or beat by anyone else out there....I have looked repeatedly. So is there a way I can edit the post/get url from a current supported selection?

 

[YiannisH_3CX]

So is there a way I can edit the post/get url from a current supported selection?

Not that I know of. You will need to wait for Update 7

 

[Bswenson]

Not that I know of. You will need to wait for Update 7

When is that update planned?

 

[Sparky Bear]

There is the Twillo and Telnex under worldwide in the main admin portal (MC portal)
that might be what you are after

 

[YiannisH_3CX]

When is that update planned?

There is no ETA yet but its for sure a few months away. We are just about to release update 6 so it will take a while.

 

[Bswenson]

Ok so now release 7 Alpha is out. I have used the generic sip trunk profile and added the SMS url and api key. I have updated provider webhook url for incoming messages. It doesn't work. I believe the syntax 3cx is using is different. Where is the file that formats the message? Looking at the file /var/lib/3cxpbx/Instance1/Data/Http/Templates/provider/GenericSIPTrunk.pv.xml does not give me any way to better specify the variables needed. Seems perhaps "APIKEY" needs renamed to "token" and to ensure the arguments 3cx is sending are "source", "destination", and "message".

The provider SMS api needs the following format:

URL:

https://api.teleapi.net/sms/send?token=XXXXXXX

Argument	Required	Type
source	yes	int
destination	yes	int
message	yes	string

curl -v -X POST "https://api.teleapi.net/sms/send?token=XXXX" \
-d "source=13035551212&destination=13038884444&message=hello+there"

 

[Evolute IT]

You'll likely need a proxy script that can handle the conversion between your provider's format and 3CX Generic expected format.

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

 

[Bswenson]

So there is no editing of the default 3cx sms properties. With this release, well since the removal of the SMS proxy method, how/where should the proxy be created?

 

[Evolute IT]

A simple PHP script can do the work easily to just grab the request, reformat the JSON and forward it to the provider's API.

 

[Guillaume Bourgeois]

So there is no editing of the default 3cx sms properties. With this release, well since the removal of the SMS proxy method, how/where should the proxy be created?

Hi @Bswenson ,

Without wanting to discourage you, what ConceptsWeb explains to you is that it will be necessary to have a server which will receive SMS from your supplier and which will retransmit the values in a format accepted by 3CX.. and the same for SMS sent from 3CX to your supplier. .

This server will serve no more or less as a value "mapping".


Example..
Let's imagine that your provider transmits SMS in this format :

{
    "event_type": "message.received",
    "id": "6e966990-9eac-9090-bf25-99888-521cf",
    "occurred_at": "2023-01-20T22:48:28.662+00:00",
    "cc": [],
    "completed_at": null,
    "cost": null,
    "direction": "inbound",
    "encoding": "GSM-7",
    "errors": [],
    "from": {
        "carrier": "Telus",
        "line_type": "Wireless",
        "number": "+17001234567"
      },
      "id": "105b5ad4-1566-4fb2-0101-e36affe802b6",
      "media": [],
      "messaging_profile_id": "400185d1-34ad-22a1-9621-a77592a546a3",
      "organization_id": "2426a8ca-0482-40e4-99w4-670007abf32e",
      "parts": 1,
      "received_at": "2023-01-20T22:48:28.637+00:00",
      "record_type": "message",
      "sent_at": null,
      "subject": "",
      "tags": [
        "VOICEMEUP",
        "BEEVOX"
      ],
      "text": "Test for demo",
      "to": [
        {
          "carrier": "SPECIAL",
          "line_type": "Wireless",
          "number": "+17009986565",
          "status": "sms_delivered"
        }
      ],
      "type": "SMS",
      "valid_until": null,
      "webhook_failover_url": null,
      "webhook_url": "https://sms.provider.special",
    "record_type": "event"

  },
  "meta": {
    "attempt": 1,
    "delivered_to": "https://sms.provider.special"
  }

but 3CX needs to receive it in this format :

{
  "data": {
    "event_type": "message.received",
    "id": "b301ed3f-1490-491f-995f-6e64e69674d4",
    "occurred_at": "2019-12-09T20:16:07.588+00:00",
    "payload": {
      "completed_at": null,
      "cost": null,
      "direction": "inbound",
      "encoding": "GSM-7",
      "errors": [],
      "from": {
        "carrier": "T-Mobile USA",
        "line_type": "long_code",
        "phone_number": "+1312500000",
        "status": "webhook_delivered"
      },
      "id": "84cca175-9755-4859-b67f-4730d7f58aa3",
      "media": [],
      "messaging_profile_id": "740572b6-099c-44a1-89b9-6c92163bc68d",
      "organization_id": "47a530f8-4362-4526-829b-bcee17fd9f7a",
      "parts": 1,
      "received_at": "2019-12-09T20:16:07.503+00:00",
      "record_type": "message",
      "sent_at": null,
      "tags": [],
      "text": "Hello from Generic!",
      "to": [
        {
          "carrier": "Generic",
          "line_type": "Wireless",
          "phone_number": "+1773005000",
          "status": "webhook_delivered"
        }
      ],
      "type": "SMS",
      "valid_until": null,
      "webhook_failover_url": null,
      "webhook_url": "http://webhook.site/04bbd2e3-09b5-4c9e-95de-a1debeb9e675"
    },
    "record_type": "event"
  },
  "meta": {
    "attempt": 1,
    "delivered_to": "http://webhook.site/04bbd2e3-09b5-4c9e-95de-a1debeb9e675"
  }
}

Your application must take care of formatting the payloads in the expected format
The logic applies on the other side too

Believe me, it's no easy job if you don't have the expertise to do it.




Sincerely,