On Sun, Mar 27, 2022 at 10:32:05PM -0400, Peter Beckman wrote:
My first evidence that UTF-8 was supported was January 13, 2017.
Using which of the methods that Vitelity provides (XMPP, email, other?)?
There are weird issues with Vitelity, such as odd length limits to SMS messages, but we worked around them. SMS is reliable enough,
I'm not sure what your metrics are for "reliable enough", but given the below chart, I don't think it would meet my bar. :)
When did you last test SMS with Vitelity? I have several years of SMS metric data on Vitelity SMS:
+------+----------+---------+----------+ | yr | success% | failed% | delayed% | +------+----------+---------+----------+ | 2015 | 98.42% | 1.58% | 3.17% | | 2016 | 96.31% | 3.69% | 5.30% | | 2017 | 96.68% | 3.32% | 2.79% | | 2018 | 92.22% | 7.78% | 6.24% | | 2019 | 94.46% | 5.54% | 1.50% | | 2020 | 98.41% | 1.59% | 0.71% | | 2021 | 97.75% | 2.25% | 2.51% | | 2022 | 98.61% | 1.39% | 0.24% | +------+----------+---------+----------+
2018-2019 sucked!
This is based on a baseline of sending an SMS once every 10 minutes to one of our active DIDs that has least recently received an Inbound SMS message. [...] Both are acceptable.
** NOTE these numbers may be attributable to outages by the sending carrier. They are not easily excluded, and so the numbers may be higher.
This also is only Inbound, not Outbound.
Given the lack of proper delivery receipts with most North American carriers, my assumption then would be that these "failed%" messages are all silent failures (i.e. the sender (on some random network) never knew that your Vitelity number didn't get their SMS). I can see how Vitelity's cost for SMS might encourage some use cases where reliability requirements are low, but especially since many (most?) carriers of this nature provide $0 incoming SMS, it's hard for me to see a good reason to use Vitelity for inbound. Perhaps your use case involves a lot of outbound too, though. Denver https://jmp.chat/