search

simontelephonics / smsconnector

SMS Connector module for FreePBX 16 and 17
https://simon.tel/open-source/
GNU General Public License v3.0
43 stars 16 forks source link

Support for 10DLC Keywords #61

Open MatthewLJensen opened 1 month ago

MatthewLJensen commented 1 month ago

Hi @billsimon, thanks again for your work on this module. I know you've mentioned in the FreePBX Community Forums that you don't believe this module is the best place to implement 10DLC compliance features. I'm wondering if you still feel that way, and if so, what you and others are doing to handle 10DLC codes and features like autoreplies (for HELP, STOP, START, etc), and opt-in/opt-out lists. I know that some providers enable these features on their end, but unfortunately mine (and I suspect others) does not. I figured I'd lay out some early thoughts I had on the various ways this could work to see if you had any helpful input or were willing to reconsider allowing the 10DLC logic to reside in the connector.

Desired Features:

Possible Solutions:

  1. A proxy service that sits in front of the smsconnector receives all of the incoming and outgoing requests.

I see the downside of this to be that the proxy will need to either have it's own sms sending logic for the auto replies, or it will need to somehow hook into the connector to send a message. The latter would be preferable so that there would be a record of the auto-replies in the chat history.

  1. Adding this functionality to the SMS connector.

Downside is that the SMS Connector is no longer just a 'connecter.' But it would enable the auto reply logic to be able to easily hook into existing API credentials in the module and the autoreplies would be in the chat history by default.

  1. Take the 10 DLC logic out of the loop and tie it in via the SMS Webhook module

This could work, however there would be no way to block outbound messages, so I would need to throw out the feature requirements regarding blocking outbound messages to opted-out numbers. We could still perform the text matching and either hook in to the connector or send the auto-replies another way.

Maybe there's an easy way to tie into the outbound piece of the connector, in which case I'll just hack something together with a proxy or webhooks. However, I feel like I'm not the only one running up against this problem and I believe there's an argument to keeping this logic somewhere others are already coming for their opensource SMS needs. What do you, or others monitoring this project, think?

Dagnabit99 commented 1 month ago

Seems to me it should not be too difficult to implement a blacklist for outbound sms. It needs to be manually editable so that you can add or remove numbers from the list as needed. And it needs to be automated so that if someone replies with STOP, they get a reply that they have been removed from the campaign and their number is then put into this blacklist which is checked when sending outbound messages. If they reply with START, their number gets removed from the blacklist and they rejoin the campaign. If they reply INFO, they get instructions to reply with START to add them back into the campaign. That should satisfy 10DLC requirements and make SMS Connector a very powerful tool.

From: Matthew Jensen @.> Sent: Monday, October 21, 2024 10:05 PM To: simontelephonics/smsconnector @.> Cc: Subscribed @.***> Subject: [simontelephonics/smsconnector] Support for 10DLC Keywords (Issue #61)

Hi @billsimonhttps://github.com/billsimon, thanks again for your work on this module. I know you've mentioned in the FreePBX Community Forums that you don't believe this module is the best place to implement 10DLC compliance features. I'm wondering if you still feel that way, and if so, what you and others are doing to handle 10DLC codes and features like autoreplies (for HELP, STOP, START, etc), and opt-in/opt-out lists. I know that some providers enable these features on their end, but unfortunately mine (and I suspect others) does not. I figured I'd lay out some early thoughts I had on the various ways this could work to see if you had any helpful input or were willing to reconsider allowing the 10DLC logic to reside in the connector.

Desired Features:

Possible Solutions:

  1. A proxy service that sits in front of the smsconnector receives all of the incoming and outgoing requests.

I see the downside of this to be that the proxy will need to either have it's own sms sending logic for the auto replies, or it will need to somehow hook into the connector to send a message. The latter would be preferable so that there would be a record of the auto-replies in the chat history.

  1. Adding this functionality to the SMS connector.

Downside is that the SMS Connector is no longer just a 'connecter.' But it would enable the auto reply logic to be able to easily hook into existing API credentials in the module and the autoreplies would be in the chat history by default.

  1. Take the 10 DLC logic out of the loop and tie it in via the SMS Webhook module

This could work, however there would be no way to block outbound messages, so I would need to throw out the feature requirements regarding blocking outbound messages to opted-out numbers. We could still perform the text matching and either hook in to the connector or send the auto-replies another way.

Maybe there's an easy way to tie into the outbound piece of the connector, in which case I'll just hack something together with a proxy or webhooks. However, I feel like I'm not the only one running up against this problem and I believe there's an argument to keeping this logic somewhere others are already coming for their opensource SMS needs. What do you, or others monitoring this project, think?

— Reply to this email directly, view it on GitHubhttps://github.com/simontelephonics/smsconnector/issues/61, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BMHVMPAB55WSAD3YRMGWUGDZ4XFGFAVCNFSM6AAAAABQLQ7PQ2VHI2DSMVQWIX3LMV43ASLTON2WKOZSGYYDIMJXGM4TKOI. You are receiving this because you are subscribed to this thread.Message ID: @.**@.>>

billsimon commented 1 month ago

SMS Connector, and the SMS module in FreePBX upon which it relies, are very much oriented to 1-to-1 messaging. Users send and receive text from UCP, softphones and SIP devices, and it's not automated. The concepts discussed here - STOP, INFO, etc. - are suited to automated messaging.

Can you tell me how you are using FreePBX SMS in an automated way such that this 10DLC logic is appropriate?

And yes I understand that 10DLC requirements seem to put all VoIP-connected messaging in this same A2P category. But there's a difference between that and what is actually happening through FreePBX, which is P2P.

We could connect SMS Connector with the Blacklist module easily enough. But as for automated replies for STOP, INFO, etc., I think that's out of scope. If someone sends you a STOP message, then send them back a polite reply and add them to the blacklist. :) After all it's person to person here.

Dagnabit99 commented 1 month ago

I agree that the module is not designed for automated use. But to be compliant with 10DLC you need the functionality of at least those three keywords and a corresponding reply message. When you register a number for 10DLC they even want to know the actual messages you are using when recipients reply with the keywords. So while the automated features will rarely get used in a 1-1 messaging system, compliance is still required to get numbers approved.

SMS texting from FreePBX or any other VOIP server is is considered A2P even if the behavior is P2P, and therefore discriminated against by the Telcos, so you have to create a “Brand” and valid “Campaign” and jump through hoops (like having opt out and opt in keywords) to get registered. Otherwise, good luck sending SMS messages to cell phones unless you fib during registration about having opt-out solution in place.

On Oct 22, 2024, at 1:48 PM, billsimon @.***> wrote:



SMS Connector, and the SMS module in FreePBX upon which it relies, are very much oriented to 1-to-1 messaging. Users send and receive text from UCP, softphones and SIP devices, and it's not automated. The concepts discussed here - STOP, INFO, etc. - are suited to automated messaging.

Can you tell me how you are using FreePBX SMS in an automated way such that this 10DLC logic is appropriate?

And yes I understand that 10DLC requirements seem to put all VoIP-connected messaging in this same A2P category. But there's a difference between that and what is actually happening through FreePBX, which is P2P.

We could connect SMS Connector with the Blacklist module easily enough. But as for automated replies for STOP, INFO, etc., I think that's out of scope. If someone sends you a STOP message, then send them back a polite reply and add them to the blacklist. :) After all it's person to person here.

— Reply to this email directly, view it on GitHubhttps://github.com/simontelephonics/smsconnector/issues/61#issuecomment-2430118281, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BMHVMPEX3LMQRMK2SB6YZQTZ42TZFAVCNFSM6AAAAABQLQ7PQ2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMZQGEYTQMRYGE. You are receiving this because you commented.Message ID: @.***>

MatthewLJensen commented 1 month ago

I think we can all agree that the 10dlc requirements don't make sense for the p2p texting that most users of FreePBX perform. I had perhaps incorrectly assumed that the responses to these keywords needed to be quick/automatic. This problem could be solved by educating SMS users and having them copy paste verbiage into their chat, and manually adding external parties to a blocked list.

While this is a big use case, I wouldn't be surprised if there are others would like the ability to programmatically send messages to people as well. For example, I often set up an IVR option for people to press to receive website information, or perhaps a google maps link to their office location, or if they want information about applying for a job. As long as you tell them they're opting in to receive those messages when they press the option, you're good to go. It wouldn't be uncommon for this to be the first message in a conversation that continues on later as p2p. It would both be nice to be able to send the messages out through the FreePBX SMS (smsconnector) logic so that it shows up in the conversation history. Of course, this still doesn't require the automated keyword responses, but at some point, especially when you start muddying the waters with p2p and a2p, it just makes sense to add to avoid the hassle of training users to properly respond.

In my case, I send SMS as an alert out to users when certain types of calls come in. It may not make sense for this scenario to tie in with the sms connector except that I'm using the same number for p2p messages and these automated messages. I want the automated messages, which will never have a person on the sending side from the system, to abide by the 10dlc policies. Perhaps my problem is solved by using 2 different numbers, one of p2p and no auto-replies, and another for a2p with 10dlc autoreplies. But I think I would still seek for a way to use the 10dlc logic across both.

Dagnabit99 commented 2 weeks ago

I'm thinking again about this feature after applying for 10DLC verification and getting rejected the first time around because they wanted more explicit details on how recipients are opting in and out. I resolved concerns by creating a web form where potential recipients can opt in, which will be managed manually, but it would be nice to be automated. However, if a fully automated solution is beyond the scope of the smsconnector, maybe something more limited would be helpful such as an automated disclaimer response when someone sends the keyword START for the first time (e.g. Message & data rates may apply. Reply STOP to opt out), or the keyword STOP ("You have opted out of receiving SMS messages from this number"). The original STOP/START message will still be delivered so that we can update the master SMS number list manually.