Where do I find info on setting up Flowroute/FreePBX with SMS? I can’t seem to find any information anywhere regarding it. Thanks!
From flowroute or Google. Freepbx doesn’t support flowroute sms out of box that I am aware of, just their own offering, sipstation.
It’s going to be all custom, likely to your specific setup, so you’ll have to find the pieces, organize them and implement them to create the workflow you are looking for.
Eeks. Maybe FPBX isn’t the best choice for us then. We really need sms and mms to just work and don’t want to write custom code to make that happen.
It’s crazy to me that there isn’t out of the box support for texting in FPBX or a 3rd party connector by now.
I love everything else about FBX but need texting to work. Argh.
There’s different APIs and ways to do it. Flowroute can do it one way, voip.ms another, another provider another, on and on. One connector won’t work for everything. You need provider specific logic for everyone.
Ohh I get that completely but the fact that nobody has built connectors for some of the main SIP providers is what baffles me. I can’t justify coding them up from scratch, so we have to consider another PBX that offers it natively which is a bummer cause I really like FPBX. Texting is a non-negotiable in todays world which is why I’m so floored this isn’t figured out already.
That would mean you need to find a PBX vendor that has a Flowroute messaging add-on. As it was explained, each vendor does this differently. If you find a vendor that actually does this on their PBX, I highly doubt it will be free. So there is that to consider.
Also, while you say texting is non-negotiable then the question becomes are you in the US? Because if you are then the follow up would be, have you done all the proper 10DLC registration for the company that has this PBX?
- Yeah we’re willing to pay but not having any option other than building ourself from scratch is my point.
- Yes they are in the US but I’m not talking about marketing and promotional spam texts, I’m talking about the ability for an employee to receive a text message from their client, and reply. The non-negotiable is the ability to reply to customers incoming text messages. It’s a convenience to the customer and not having it as an option is our non-negotiable.
I think one could equally argue that Flowroute should be providing the FreePBX code to support their proprietary messages submission protocol.
That doesn’t matter. VoIP falls under Application-to-Person and Flowroute is very forthcoming about that fact with their messaging. Due to that, it means anyone using Flowroute (or VoIP really) needs to follow the 10DLC registration rules. More and more VoIP providers are pulling messaging services as a ‘use-as-you-go’ service and requiring proper registration for sending messages.
Even if a provider allows you to send messaging without being registered it means that those messages are treated completely different, they could be subject to filters and blocking and they cost extra money as carriers like ATT and T-Mobile charge higher surcharges when the number sending the messages isn’t associated to a registered Brand/Campaign.
10DLC campaigns also require automatic responses and actions. 10DLC users need to support things like hastag commands such as #STOP, #UNSUBSCRIBE, #REMOVE, etc that will automatically stop the requestor from receiving any messages in the future. There also needs to be support for commands like #HELP or #INFO, etc. which will, once again, automatically reply with valid contact information about the Brand and the Campaign.
The OP only seems to want P2P, not A2P.
This.
Yeah I am pointing at both sides. Flowroute has a great documented API but it makes sense to me that the FPBX server should be doing the processing (webhooks in and out). As is you’d need to provide a 3rd server to process incoming and outgoing messages between the pbx and the sip trunk.
It doesnt matter what the OP wants. VoIP falls under Application-to-Person. You cannot do P2P with VoIP unless the carrier got the exemption, which Flowroute does not have.
This is how regulations work. Did I want to do all the work for Kari’s Law? No. Did I want to do all the work for STIR/SHAKEN? No. Did I want to do all the work for 10DLC? No. Did I want to do all the work for Robocall mitigation? No.
Despite not wanting to do any of those things, I still had to do them to be in compliance and continue operating.
So again, in the land of messaging VoIP falls under A2P not P2P. The mere fact you need to use an API and create an application to send messages makes it A2P. Flowroute very much says they are 10DLC and all their documentation says this. They even have a timeline that documents all these changes and when each stage happens.
Bottom line, businesses using VoIP and want messaging require 10DLC registration.
Fortunately I’m not in a position where I have to track US legislation in detail, but it seems to me that this definition makes SMS sent from a normal mobile phone A2P, and even voice calls sent from a mobile phone (dialler application and messaging application). I would have assumed that the spirit of the law was intended to cover cases where a machine either made the decision to send, or iterated through a list of destinations, but the letter could well be more nebulous.
Although it is probably only an informal summary, section 10 of https://docs.fcc.gov/public/attachments/DOC-355214A1.pdf seems to suggest that A2P implies large numbers of destinations and excludes cases constitute “typical human operation”. Interestingly it puts them in the same class as email; do you have to register with the FCC to send (non-bulk) email, as a business?
It refers to https://api.ctia.org/docs/default-source/default-document-library/170119-ctia-messaging-principles-and-best-practices.pdf, which in section 4.1.1 gives characteristics which typically indicate human traffic, and therefore P2P (flow route seem to implement a 15 messages a minute limit, which seems to be intended to tick one of the boxes). 4.3 does confuse the issue, though, by explicitly mentioning consumers in the P2P side, and by mentioning call centre traffic in the A2P side, although 4.1 seems to say that consumer to business traffic can be P2P.
The definitions don’t seem to be based on the use of an “application”.
It is possible that providers are using nebulous definitions of A2P because they don’t want to get into the details of enforcing the distinction.
It sounds like you just want to educate on 10DLC which I didn’t even ask ask about. I’ll handle that part. My original question still stands.
Exactly
To a large extent I think it is for the same reason that they don’t provide flowroute and a voip.ms module trunk module.
Of all the SIP providers that support SMS, I’m aware of exactly zero that share the same method(s) for sending and receiving SMS/MMS.
FreePBX supports SMS/MMS natively from SipStation and VoIP Innovations.
Of the few interpretations I have seen re: 10DLC campaign registration, all of them interpret the regulations similarly, and that is that SMS/MMS sent via VoIP are considered A2P regardless of how the send is initiated.
Yes, but isn’t that the point of a connector? By connector I’m talking about an implementation to accomplish similar things with different interfaces.