Is there any significance to the fact that all the other messages in the thread appear to arrive instantly (same time stamp) while the message in question has a 1 min delay (the sender’s time shows 14:45, the recipient shows 14:46)?
MMS for sending image needs to transfer more data, so that could be why the message with the image had a noticeable delay while SMS text messages arrived fast enough to have same time.
But also it could have just been sent very close to the next minute. For example it could have been sent 14:45:58 and delivered 14:46:03.
Or the provider could have just had an issue and sent it later. You never had issues getting sms or mms delivered instantly? In Romania at some point it was so common across carriers that I was really happy when delivery receipts happened.
In the old times all sms were transport of the tcap layer in ss7 stack. Tcap was reliable non flow controlled protocol with no way to handle the extra traffic(carriers just used 64kb trunk line) by all the new kids sending sms. Then somebody in the vendor community had the idea let’s drop sms if the trunk are too busy.
The problem the protocol had no way to notify the sender of the drop message. You can imagine the path of the following hacks to solve that new problem
Comments
Is there any significance to the fact that all the other messages in the thread appear to arrive instantly (same time stamp) while the message in question has a 1 min delay (the sender’s time shows 14:45, the recipient shows 14:46)?
MMS for sending image needs to transfer more data, so that could be why the message with the image had a noticeable delay while SMS text messages arrived fast enough to have same time.
But also it could have just been sent very close to the next minute. For example it could have been sent 14:45:58 and delivered 14:46:03.
Or the provider could have just had an issue and sent it later. You never had issues getting sms or mms delivered instantly? In Romania at some point it was so common across carriers that I was really happy when delivery receipts happened.
In the old times all sms were transport of the tcap layer in ss7 stack. Tcap was reliable non flow controlled protocol with no way to handle the extra traffic(carriers just used 64kb trunk line) by all the new kids sending sms. Then somebody in the vendor community had the idea let’s drop sms if the trunk are too busy. The problem the protocol had no way to notify the sender of the drop message. You can imagine the path of the following hacks to solve that new problem
Just a guess but my assumption is that this is based around them having different OSs; even the messaging apps.