| SMPP Message ID Tracking |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - SMS Issues ⬆ Archive through October 19, 2005 ⬆ |
◄ ► |
| Author | Message | |||
| Anonymous |
Is there a way to track a request across NowSMS's lifespan -- the responses I'm receiving back to our HTTP system don't seem to have any sort of relation to the initial message ID that's created, other than they happen to be (at the moment) sequential. I've read some bits in the forum that indicate there's some kind of tracking available, but it's hard to follow the threads. I'm connecting to mBlox with SMPP. | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 4935 Registered: 10-2002 |
Hi, As you've seen from other posts, we've been working hard on delivery receipt tracking, focusing on SMPP environments. Originally it was planned to be part of the next major release. But the complexity of dealing with receipt formats from different providers meant that we had to do a lot more "live testing". So we snuck in a feature, left it out of any release notes ... but leaked details here on the discussion board to facilitate more of a live beta. It has been a grueling process, apparently because the specifications are not as clear as they could be, and different software implementations have interpreted things in different ways. So that does make some of the threads a bit confusing to follow as we work through issues that may be specific to a particular provider. Then there is also the complexity of some configurations ... for example, message id's are not globally unique. You might have multiple connections to one provider, or multiple connections to multiple providers, and we need to be able to track this. Originally, this was more of an issue for customers who are using NowSMS as what I'd call an "SMPP Multiplexer". They have multiple SMPP clients connecting in to NowSMS, and route messages upstream to another SMPP server. The problem that they encountered is that when NowSMS accepts the message over SMPP, NowSMS assigns a message id. But then when the message gets submitted upstream, that server assigns another message id. So when a delivery receipt comes back, the message id referenced in the delivery receipt is the upstream id, but the original submitting client does not know this id, it only knows the NowSMS assigned id. There was also an issue that we could not reliably track which of the submitting accounts defined to NowSMS should receive the delivery receipt. If you're only working with SMPP client connections connecting to the NowSMS server (no HTTP clients), then all you need to know is that to enable this support, currently you must edit SMSGW.INI, and under the [SMSGW] header, add TrackSMPPReceipts=Yes. If receipts do not seem to be getting translated correctly, and not routed back to the original submitting SMPP client correctly, then you need to enable the debug logs so that we can view the SMSDEBUG.LOG and SMPPDEBUG.LOG files. It is possible that your SMS provider is not handling message id's correctly, but we can determine this based upon a study of those log files. As this solution evolved, we also realised that it would be of benefit to HTTP clients, and some of the more recent discussions on our discussion board have centered on HTTP. Basically, the way that it works, is that if you put TrackSMPPReceipts=Yes under the [SMSGW] header in SMSGW.INI, then whenever a message is submitted with a receipt requested, we will track the upstream message id, so that when a receipt comes back, we can match it up with our originally assigned id, as well as the user account that originally submitted the message. (The user account being primarily of use with SMPP connections at this point.) To submit a message with a delivery receipt requested, an SMPP client sets the appropriate flag in the request. An HTTP client includes "&receiptrequested=yes" in the URL request. (Alternatively, there is a setting to force a delivery receipt to be requested for all message submissions via HTTP, this is "ReceiptRequested=Yes" under the [SMSGW] header of SMSGW.INI.) For SMPP clients, this whole process is rather transparent. When a delivery receipt comes back, they will receive it via SMPP with the orignally assigned message id in the "receipted_message_id" field. For HTTP clients, it is a bit more complex. NowSMS will report its assigned message id when a message is submitted via HTTP. When a message is submitted via HTTP, the HTTP 200 OK response includes text such as the following: MessageID=54321098.req, Recipient=+xxxxxxxxxx If the message was posted to multiple recipients, this will be repeated for each recipient. You can parse the text from this HTTP response to determine the Message id that NowSMS has assigned to the message. When a receipt comes back, the convention in SMPP is that the text of the delivery receipt starts with "id:", followed by the message id. So to route these delivery receipts back to an HTTP application, you need to use the 2-way command facility, where you define a 2-way command with an "SMS Command Prefix" of "id:*". Leave "Receive Phone Number(s)" blank (or in the context of receipts, it would be the sender address of the originally sent message, so you could define different scripts to process receipts for different sender phone numbers). Then in the "Command to Execute" field, you include your HTTP link. In addition to the other supported parameters, we also support a parameter @@RECEIPTMESSAGEID@@, which will contain the receipted message id. Note that if you want the 2-way command to process the receipt, it is very important that if you are submitting messages through an "SMS Users" account, you must have "Enable SMPP Login for this user" unchecked. When processnig receipts, NowSMS tracks which user account submitted the original message for which a receipt is being received. If "Enable SMPP Login for this user" is checked, then the receipt will be routed to a queue for the user to pick up via SMPP. If it is not checked, or "SMS Users" accounts are not being used, then the receipt will get routed to the 2-way command facility. The following thread probably has the most information on this: http://support.nowsms.com/discus/messages/1/10825.html (And it contains a link to the latest version with this functionality.) Also, if you search the discussion board on a keyword of "TrackSMPPReceipts", you will find other discussions about this setting. For example, one other issue that is worth mentioning is that in some configurations, for fault tolerance reasons, you might have multiple SMSC connections defined for connecting to different SMSC servers at your service provider. In this situation, you might submit a message via one of the SMSC servers, but a delivery report might get routed back to you via one of the service provider's other servers. This causes a problem because by default, NowSMS tracks message id's on a per SMSC server basis (because message id's are not globally unique). So, if you have a situation where you are connecting with the same user account to multiple SMSC servers at the same service provider, you need to configure NowSMS to use a shared message ID pool for the grouped servers. To do this, you can manually edit each [SMPP - host:port] section of SMSGW.INI, and under the section header, define TrackSMPPReceipts=xxxxxxxx. When this entry is present, message ids pertaining to delivery receipts will be grouped under the "xxxxxxxx" name instead of the SMSC name. That's pretty much an information dump of all of the information that I have on this facility at present. I'm certain that it will continue to evolve as we learn about the idiosyncracies of dealing with different providers. -bn | |||
