Updates to optimize RCS delivery and fallback

Twilio recently made improvements to our platform to increase RCS delivery and improve fallback consistency.

The time for a recipient’s device to confirm delivery before an RCS message’s status is updated to "undelivered" or a fallback SMS / MMS is sent, no longer depends on how long a message is queued within Twilio. Consequently, when messages queue within Twilio (as expected when sending large marketing campaigns) Twilio’s native fallback-to-SMS feature now ensures messages to RCS-capable devices are always attempted to be delivered on RCS, and no longer will fall back prematurely.

In addition, to optimize our platform by balancing successful RCS delivery with timely message resolution (whether that results in a native SMS / MMS fallback or a timely "undelivered" status), the amount of time given to devices to confirm delivery has been updated. As a result, you may notice messages falling back to SMS / MMS or an RCS message’s status updating to undelivered faster or slower than before.

No code changes are needed to take advantage of these optimizations. However, you may guide this behavior by ensuring you are using the "ValidityPeriod" parameter. Though the "ValidityPeriod" parameter continues to only apply to messages queued within Twilio’s platform, it is used to inform Twilio of how time-sensitive the message is and when a faster fallback or failure signal is needed. For time-sensitive messages, like OTPs or appointment reminders, it’s recommended to use a shorter value than the 10-hour default, like 30 seconds or 15 minutes. For customers sending RCS without Twilio's native fallback feature, these optimizations also ensure the message’s status moves to "undelivered" when it is no longer likely to be delivered, rather than waiting hours (or days) for it to inevitably expire.