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.
Yes, I am educating you on how 10DLC works because it can impact what you want to do and it seems you are unaware as to how it can impact you. One of those things is providers not allowing messaging until it is done. Since messaging seems to be a huge deal for you, understanding how 10DLC impacts that is very important.
As for your original question, it’s been answered in various ways. Different carriers use different methods in which to handling messaging. Some might not even offer an API but offer a portal in which you manage it. Some might offer APIs but not off webhook methods meaning you would have to make an API call to receive messages instead of just listening for them. Some require very basic things like from/to/message. Others require additional information to be sent. Then you have actual business needs. Some just want email based, some want a portal, some want both. There’s also the issue of storage as most carriers will only hold the message on their end for so long (while some don’t hold it at all).
There is also the case that many of these vendors have changed how they’ve done messaging over the years. Meaning that someone that wrote a connector for X vendor 5 years ago might not be applicable today because of changes made.
People have been asking for years for something like this and the answer has always been the same. There are too many vendors that require different ways to do the same thing. The development behind it along with the continual support of it would require working with N amount of vendors. Following all the changes the vendors make, making sure it is compliant with things. Using Flowroute as the example here, they have services all over the world. Messaging is different all over the world such as other places don’t have 10DLC like the US. So working on a Flowroute SMS module, is it only for the US? How will it comply to other messaging rules/laws in other places?
In other words, not only do the various vendors have different methods various countries have different rules that have to be followed. Developing a Flowroute module would require that it work with Flowroute regardless of where the user is located in the world. As I said before, you find a PBX vendor that is doing something like this it will be a commercial solution much like phone provisioning.
And to your point about 10DLC, how does 3CX or Google Voice handle things? They are essentially the same thing as a FreePBX server.
Well 3CX is comparable but with Google Voice you need to be a little more specific. Are you referring to the “I can associate a free GV number to a mobile number” or actual Google Voice business? GV is a bit murky to deal as they could have P2P exemptions due to the nature of them pairing a number with a mobile number. Based on some rumbling from the ITExpo this year, I wouldn’t be basing business needs around the free Google Voice service.
As for 3CX, it gives you some ability to configure with the provider and process messages in the PBX but then again 3CX entire business model doesn’t have OSS in it. In fact, they actively market against OSS. The free licenses are pretty much a joke for a business of any size and 3CX famously takes a commission from all of their partner providers on MRCs, etc. This is why Telnyx and Twilio are no longer partner providers but 3rd party providers that have support. Because they were partners but then decided that 30% per month commission to 3CX was a bit too much. All in all 3CX is a commercial product.
So you have 3CX that sucks money from the users and their partners. Then there is Google Voice, free but as-is including the fact it could go away tomorrow and there would be no legal recourse for any users.