RCS delivery improved; fallback timing adjusted

<p>Twilio recently made improvements to our platform to increase RCS delivery and improve fallback consistency.</p> <p>The time for a recipient’s device to confirm delivery before an RCS message’s status is updated to &quot;undelivered&quot; 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.</p> <p>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 &quot;undelivered&quot; 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.</p> <p>No code changes are needed to take advantage of these optimizations. However, you may guide this behavior by ensuring you are using the &quot;ValidityPeriod&quot; parameter. Though the &quot;ValidityPeriod&quot; 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 &quot;undelivered&quot; when it is no longer likely to be delivered, rather than waiting hours (or days) for it to inevitably expire.</p> <p>&nbsp;</p>