Question on use of TTL in conversation API for MMS messages

[lmartella]

In reading the docs on using TTL in the conversation API, I'm curious to understand some details of how it works.
 
If I include a TTL in the payload for the message...

if we've received a QUEUED_ON_CHANNEL and a DELIVERED response before the TTL time has passed, no action is taken
if we've received a QUEUED_ON_CHANNEL but no DELIVERED status by the time the TTL time has passed, will the message be cancelled and NOT send to the end user / handset?
if we have not received any status in the delivery report yet by the time the TTL time has passed, will the message be cancelled and NOT send to the end user / handset?

[Tauben_Tenty · Accepted solution]

Hello,

The TTL relates to processing within the ConvAPI Core.  ie.  It doesnt get proxied to the channel itself.

If you have received a QUEUED_ON_CHANNEL followed by DELIVERED then the message has already reached the recipient successfully.  

If you have received a QUEUED_ON_CHANNEL but not yet DELIVERED then it is still pending for delivery (in the case of MMS by the MMSC) Processing has already left the ConvAPI and is with the channel. This message will still be delivered when/if the handset becomes available upto the TTL set on the MMSC(Typically 48hrs).  There is currently no support of a channel "EXPIRE_AT" through the conversation API

If QUEUED_ON_CHANNEL has not yet been received by the time of the TTL then the message expires in the Conversation API Queue.  It is discarded and not passed to the underlying channel for processing.