| Delivery receipts, message ids and TrackSMPPReceipts |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - SMS Issues ⬆ Archive through October 19, 2005 ⬆ |
◄ ► |
| Author | Message | ||||
| Max Unregistered guest |
Hi, I've been evaluating NowSMS and everything's working great, except handling of SMS delivery receipts. Message ids from delivery receipts are different from those returned by NowSMS (because they are generated by SMSC) and also receipts are not routed properly. I added "TrackSMPPReceipts=Yes" parameter to the SMSGW.INI as instructed in this forum, which should enable message ids rewriting and proper routing of delivery receipts, but the problem remains. Not to mention that I'm using the latest version of NowSMS - 5.51f, which should also be able to handle delivery receipts that don't have optional "receipted_message_id" PDU parameter defined (which is the case with my SMSC). I basically tried everything, but with no success. So, I decided to do some more research locally using the simulator instead. I first connected NowSMS to the SMPP simulator that doesn't return "receipted_message_id" parameter in delivery receipts and the result was the same - it didn't work. After that, I used a modified version of the simulator that does return "receipted_message_id" parameter - and voila, everything worked properly. So, it appears that even in the latest version, NowSMS still requires "receipted_message_id" parameter to be present instead of parsing id from the message text, and therefore makes it not working with my SMSC (real SMSC). I've attached debug logs that illustrate what's said above. In the first case, delivery receipt was simply put in the SMS-IN folder, while in the second case it was properly routed through internal SMPP server to the user that sent original message. Is there a solution for this problem with delivery receipts? Best regards, Max
| ||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 4870 Registered: 10-2002 |
Hi Max, Yes, we were still not parsing message id's from the message text if receipted_message_id was not present. I posted some more details in the following thread, and a link to yet another update that should hopefully resolve this issue: http://support.nowsms.com/discus/messages/1/10825.html Do note that we won't do any parsing of the message text for a message id, unless the esm_class field has one or both of the following bits set: Short Message contains ESME Delivery Acknowledgement; Short Message contains ESME Manual/User Acknowledgement. According to your logs (and the logs in the other referenced thread), that is not a problem. But I post it here, because I anticipate it could be an issue for us with some provider that fails to set these flags. -bn | ||||
| Max Unregistered guest |
Hi Bryce, Thanks for the reply. I've just tried the latest patch - 5.51g and it's working "almost right" now. Message ids are properly rewritten when "receipted_message_id" parameter is missing, but delivery receipts are not routed properly (via internal SMPP server) to the original sender of the message, instead they end up in SMS-IN folder. Only way to route them to the appropriate location is to enable "Route received messages to the user via SMPP" option and then explicatively define recipient address for the incoming messages. This limitation is not present when delivery receipts contain "receipted_message_id" parameter in which case they are routed properly. I attached new debug logs and you can see (in lines from SMSDEBUG.LOG) that in case when "receipted_message_id" parameter is present, there's an additional "extraParms=RouteToLocalUser=..." parameter in the line that's related to the receipt that contains "receipted_message_id", but it's not present on the line that's related to the receipt that doesn't contains "receipted_message_id" parameter. So, my guess is that you're still not handling in the exact same way delivery receipts with and without "receipted_message_id" parameter. Best regards, Max
| ||||
| Max Unregistered guest |
Any update on the routing issue that I described above? Max | ||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 4883 Registered: 10-2002 |
Hi Max, Ok, you're right. We are not treating the "id:" parsed from the message text in the same way as receiving the "receipted_message_id" parameter. Specifically, we were not setting the flag to indicate that the receipt needed to be routed to a specific user account. Another update to address this is now at http://www.nowsms.com/download/latestpatch.zip. -bn | ||||
| Max Unregistered guest |
Hi Bryce, Thanks for the update. Everything's working fine according to my tests so far. However, I've stumbled upon a problem with one SMSC, whose delivery receipts weren't routed properly. Attached you'll find debug logs. In delivery receipt from SMSC everything seems to be fine, even the "receipted_message_id" parameter is present, but receipt still isn't routed properly. My guess is that the problem is probably related to the fact that SMSC returned hex number as message id in response PDU, while in delivery receipt message id is written as decimal number and that probably confuses NowSMS. Also, note that while delivery receipt wasn't properly recognized, NowSMS did rewrote text of the message - leading and trailing zeros from "id:123..." part of the message were removed. Removing leading zeros is fine, but removing trailing zeros is not, because they are part of the number. Best regards, Max
| ||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 5105 Registered: 10-2002 |
Hi Max, I see what the problem is. It actually has nothing to do with hex vs. decimal, or leading or trailing zeroes. The issue is that the receipted_message_id is not null terminated. The specs call for this parameter to be of the format "C Octet string", which is null terminated. But this particular SMSC is using "Octet string" encoding, which is not null terminated. This discrepancy is what is causing us to lose the last character of the receipt_message_id parameter (the fact that it is a "0" is just a coincidence). That is a relatively minor issue that we should be able to put together an update for within the week. -bn | ||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 5135 Registered: 10-2002 |
Hi Max, Give the update at http://www.nowsms.com/download/latestpatch.zip (v5.51k) a try. It should resolve this problem with losing the last character of the receipted_message_id if it is encoding using "Octet String" encoding instead of "C Octet String" encoding. -bn | ||||
Debug logs
