| This SMS will self-destruct ... |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - SMS Issues ⬆ Archive through February 02, 2006 ⬆ |
◄ ► |
| Author | Message | |||
| Steve Napp New member Username: Snapp Post Number: 1 Registered: 01-2006 |
A few months back I read something about someone who was sending SMS messages that would self-destruct after some period of time. Is this possible with NowSMS? How does it work? Does it use the validity period setting? Cheers, Steve | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 5445 Registered: 10-2002 |
Hi Steve, Yeah, it's a somewhat simple concept ... someone just trying to give it a marketing spin with the "self-destruct" angle. So, let me explain how this works. It has nothing to do with the "validity period" setting. But before I get into the explanation, I might explain what the "validity period" setting is in the first place. When you submit a message to an SMSC, it is sometimes possible to specify a "validity period" for the message. This setting is an instruction to the SMSC, which essentially says, if the message cannot be delivered to the recipient within the next x minutes/hours/days, then it should be automatically discarded. To further clarify, this would mean that if the recipient's mobile phone is turned off, or out of coverage for x minutes/hours/days after the message is submitted, the SMSC should not perform further delivery retry and should discard the message. Of course, there is no guarantee that the operator SMSC will respect this setting, so it needs to be tested with a particular operator first to determine if it can be used reliably. Currently, NowSMS only supports the "validity period" setting when messages are submitted via a GSM modem. There is more discussion of this particular feature in the following thread: http://support.nowsms.com/discus/messages/1/10824.html Note that in NowSMS 2006, we will also be supporting this parameter for SMPP connections. Currently there is some very limited support for this parameter in SMPP environments, as referenced in the above thread. I should also caution, however, that this parameter is not universally supported, so if you are going to use it for some purpose, you need to test to see if it works with your SMSC interface. But this "validity period" setting has nothing to do with so-called self-destructing SMS messages. After all, this setting only affects message delivery by the SMSC ... when the handset receives the message from the SMSC, this parameter is not present. (The validity period parameter is defined in the SMS-SUBMIT TPDU, but not in the SMS-DELIVER TPDU.) So, let's get back on topic with a discussion of the so-called self-destructing SMS. This technique uses "replacement type" messages. The idea of a "replacement type" message is that when you send a message, you can set a "replacement type" number between 1 and 7. When the recipient phone receives a message with a "replacement type" value set, it works like this ... the phone checks to see if it already has another message from the same sender with the same "replacement type" value. If it does, the new message replaces the existing message. If the existing message has already been read, the user sees a new message ... and the existing message disapears. If the existing message has not yet been read, the user usually sees only a single message, that being the last message received (although I have seen a few phones that incorrectly display both messages). Unfortunately, the use of "replacement type" settings is also not perfect. When the phone receives one of these messages, it keeps only the last message received ... which may or may not be the last message sent. Because of network errors, retries, or queueing issues, messages may not always be sent in the order received. If you want to experiment with "replacement type" messages, there is a checkbox setting on our "Send Text Message" web form that allows the "Replacement Type" value to be set. If submitting via URL, add "&PID=41" to the URL. (41 = replacement type value 1, 42 = rt value 2, ..., 47 = rt value 7) So how would you use "replacement type" messaging to create a self-destructing SMS? Using "replacement type" messages, you can see how you could easily send a "now you see it, now you don't" message. But if you think about the 007 scenario, you want to make sure that the recipient receives the message before it self destructs. The last piece of the puzzle is delivery receipts. You'd need to be using an SMSC interface that supports delivery receipts (such as SMPP, although NowSMS 2006 will also do a decent job with delivery receipts using GSM modems). For more info on delivery receipts, see http://support.nowsms.com/discus/messages/1/10825.html. So you send the original message out with a replacement type value set, requesting a delivery receipt. When you get a delivery receipt message back, you wait some period of time according to your application logic ... and then you send a new message out (perhaps one that says "This message has self-destructed"), with the same replacement type value set. The original message is then updated and replaced with the new message. The only glitch in all of this is that a delivery receipt only tells you that the message has been delivered to the mobile. It does not tell you that the recipient has actually read the message. Unfortunately, there is no standard for being able to send an SMS where you get a read receipt. -bn | |||
