| Delivery Recipts and CallBack |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - SMS Issues ⬆ Archive through October 19, 2005 ⬆ |
◄ ► |
| Author | Message | |||||
| Nuno Souto New member Username: Nsouto Post Number: 6 Registered: 08-2005 |
Hello, I have managed to get the delivery recipts working, and using the two way system, I get them sent to a script for processing. My problem now is how to know what receipt belongs to whom? I have a database with a record of all the messages and numbers that were sent, and have a uniqueID for every number, now when a message is sent using HTTP, NowSMS responds with the uniqueIDs it associated to each number/message, and I parse the received html to associate each number to the NowSMS uniqueID. Up to now all good, the problem is when I receive the delivery receipt it only contains the SMSC issued ID, which I have no idea to what message does it belong to. When NowSMS makes the callback it sends: SMSSend Accounting Callback Type=SMSSend From=DefinedSMSUserAccount To=RecipientPhoneNumber MessageID=SystemSpecificMessageID Size=##### (size of message in bytes, may vary slightly with header changes in-transit) As per http://www.nowsms.com/support/bulletins/tb-nowsms-001.htm Is it possible to have NowSMS send the SMSC ID along this callback when the option TrackSMPPReceipts=Yes is activated in the smsgw.ini, so that I may know to which number the delivery receipt belongs to ? In the logs there is an entry such as: 2005-08-06 10:46:47,42F4CD57.req,IP.IP.IP.IP,XXNUMBERXX,OK -- SMPP - SMPPSERVER.NET:PORT,SubmitUser=user;Sender=AlphaSender;SMSCMsgId=14754;Text="Bla BlaBla" Will I have to go through the logs to check what each message SMSCID corresponds to its NowSMSID ? And one last thing is, is there any way to query the status of a message sent either using SMPP or HTTP, or will I have to parse and check the Q dir for any messages remaining to be sent, or that remained there with a .ERR extension ? Hope everything makes sense  Thanks Nuno Souto | |||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 4765 Registered: 10-2002 |
Hi Nuno, When you have TrackSMPPReceipts=Yes in the SMSGW.INI ... NowSMS should automatically be converting from the upstream SMSCMsgId into the NowSMS assigned message id before the receipt gets passed to a 2-way command (or saved to the SMS-IN directory). Unfortunately, we don't have any way to query. But in the example of Q files that get renamed to a ".ERR" extension because of message rejection at submission time ... you don't need to parse the "Q" directory. If you requested delivery notification when submitting the message, we would generate a delivery receipt back indicating non-delivery. -bn | |||||
| Nuno Souto New member Username: Nsouto Post Number: 7 Registered: 08-2005 |
Hi Bryce, I have the TrackSMPPReceipts=Yes under the [SMSGW] section in smsgw.ini, but the message I get back does not contain the NowSMS assigned ID: id:21 sub:001 dlvrd:001 submit date:050816093254000+ done date:050816093254000+ stat:DELIVRD err:000 Text:Testing TrackSMPPReceipts... I tried this using an HTTP connection to NowSMS and Now using an SMPP connection to SMPPSim. I will try it as well using a SMPP Connection to Now, but I haven't gotten into activating the delivery receipts with that connection just yet... Thanks Nuno Souto | |||||
| Nuno Souto New member Username: Nsouto Post Number: 8 Registered: 08-2005 |
One side note.. I'm using the latest version v5.51d Thanks Nuno Souto | |||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 4777 Registered: 10-2002 |
Hi Nuno, The problem is that the SMPP simulator does not include the "receipted_message_id" parameter in its delivery notification. We're looking for that value to be present in order to perform the translation. There is some more discussion of this issue here: http://support.nowsms.com/discus/messages/1/10644.html We will be making some changes where we will go ahead and parse the id out of the text of the message, if the receipted_message_id parameter is not present. From what I've seen, actual SMSCs seem to be good about generating this receipted_message_id parameter, but not so with simulators. -bn | |||||
| Nuno Souto New member Username: Nsouto Post Number: 9 Registered: 08-2005 |
Hello Bryce, I have been testing with a real SMSC, and I still can't find a way to match the delivery receipt with the message saved on our database, when I check the logs, namely SMSOUT-YYYMMDD.LOG I have the following line: 2005-08-19 11:44:42,4305FE69.req,IP.IP.IP.IP,+XXXXXXXXXX,OK -- SMPP - SMPPADDRESS.NET:PORT,SubmitUser=USERNAME;Sender=ALHPASENDER;SMSCMsgId=bbde687b03 c9d126b364bf1b82d1c0b0;Text="BlaBla" So in that line I have the NowSMS ID and the SMSC ID together, but when I get the delivery receipt I get: id:bbde687b03c9d126b364bf1b82d1c0b0 sub:001 dlvrd:1 submit date:0508191735 done date:0508191735 stat:DELIVRD err:0 text:BlaBla This is an example using a real SMSC. I tried using the &message_id=@@MESSAGEID@@ in the script call, but that message_id is another ID attributed to incoming messages, I was hoping it would be the same as the outgoing. I could trace the message using the number and text, but then if the same message gets sent twice (not supposed to happen, but it could) the database would update both messages with the latest delivery receipt. I can't think of any way to do this. The only thing that comes to mind is parsing the log file once a day, but that would make the delivery receipt confirmation not work in real time. Thank You Nuno Souto | |||||
| Nuno Souto New member Username: Nsouto Post Number: 10 Registered: 08-2005 |
After all this, the question that remains is: If the SMSC ID and NowSMS ID are both together in the log file, all that is needed is for NowSMS to send the SMSC ID together with the NowSMS ID in a callback script, at the same time it writes to the log. Is this possible ? This way even if the SMSC does not return a receipt_message_id, NowSMS does not need to parse the delivery receipt text, but it could be done in an external application. For what I understood, when the SMSC does return the receipt_message_id, it gets replaced by the NowSMS ID in the delivery receipt "id:", but this would make it that an external application would never have access to the SMSC ID which might be necessary in some cases, namely my own ;). Thanks Nuno Souto | |||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 4815 Registered: 10-2002 |
Hi Nuno, Sorry for taking so long to get back to you on this. We've been working on this, and related issues, trying to determine the best way to address these requirements. Basically, what we want to do is let NowSMS track the upstream assigned message id's, so that a submitting application does not have to track them. We need to do this for configurations where NowSMS is used as an SMPP server, routing messages to upsteam SMPP connections. When an SMPP client submits a message to NowSMS, NowSMS is going to assign a message id. When that message gets routed to an upstream SMPP provider, the upstream provider is going to assign a new message id. We need to ensure that when a delivery notification comes back, we route the delivery notification to the SMPP client that submitted the original message, and with the receipt message id being the one that was originally assigned by NowSMS (because that is the only id that the submitting SMPP client knows about). So it is only logical that we apply this same tracking for submitting HTTP clients as well. 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. (You could also use accounting callbacks, like has been discussed earlier in this thread. However I think that is a more complex way of doing it.) Now the question comes for how to handle delivery notification receipts and match them up. We've decided that the best way to handle this is by extending the 2-way command facility. If your SMSC starts the message text of delivery receipts with "id:", then you can 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, we are adding support for a new parameter @@RECEIPTMESSAGEID@@, which will contain the receipted message id. This is going to require another update, which we're planning to upload within the next 24 hours. I will post details here when the update is available. 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, then the receipt will get routed to the 2-way command facility. I hope this explanation makes sense. I'll post a follow-up here as soon as the update with this support is posted for download. -bn | |||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 4820 Registered: 10-2002 |
Follow-up: An update has been posted which addresses the issue described above. Download link for update (v5.51e): http://www.nowsms.com/download/latestpatch.zip Related threads: http://support.nowsms.com/discus/messages/1/10862.html http://support.nowsms.com/discus/messages/1/10644.html http://support.nowsms.com/discus/messages/1/10806.html | |||||
| Nuno Souto New member Username: Nsouto Post Number: 11 Registered: 08-2005 |
Hello Bryce, No problems for the delayed reply, sometimes it happens, and that sometimes is a lot of times. I've updated to the latest Patch, but the new @@RECEIPTMESSAGEID@@ returns empty, I tried both with a simulator and real SMSC. My current string to return the DeliveryReceipt is set as: sender=@@SENDER@@&smsPrefix=@@SMSPREFIX@@&sms=@@SMS@@&fullSMS=@@FULLSMS@@&recip= @@RECIP@@&message_id=@@MESSAGEID@@&nowMsgId=@@RECEIPTMESSAGEID@@ Thank You Nuno Souto | |||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 4857 Registered: 10-2002 |
Hi Nuno, If it's empty, then we're not recognising the message as a delivery receipt. I suspect we need to look at the debug files, both SMSDEBUG.LOG and SMPPDEBUG.LOG. Enable those logs (easiest to do this on the "Serial #" page of the config). Then send a message with delivery receipt requested, and let's look at one comes back. -bn | |||||
| Dani Riera New member Username: Drieran Post Number: 7 Registered: 05-2005 |
Hi, I'm in the same situation than Nuno. The RECEIPTMESSAGEID is in blank. I attach the SMSDEBUG.LOG and SMPPDEBUG.LOG.
| |||||
| Sam Unregistered guest |
Hi Get the DRs in the SMS-IN folder. If we need it to pass it to the respective clients need to enable "route received messages to the receipient". Here the problem is that need to define the recepient address. Now I tried for all alphabatecal characters but there seems to be a limit on number of address that can be define. Viz it works only for the following addresses q*,w*,e*,r*,t*,y*,u*,i*,o*,p*,a*,s*,d*,f*,g*,h*,j*,k*,l*,z*,x*,c* Doesnt take in values ,v*,b*,n*,m*. Also numeric recepient senders are yet to come. Can this limiation of defining the recepient sender address be done away with? I mean just have the option of route revieved messages to user via SMPP and then DONT define the specific recepient address. Regards Sam | |||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 4868 Registered: 10-2002 |
Hi Dani & Nuno, Thanks for posting the logs Dani. I can see what's going on here. The problem is with the parsing of the message id out of the text of the message. Our regular SMS service providers does provide the "receipted_message_id" field in receipts. But your provider is not, so we needed to do a better job testing this parsing from the text. We've setup a test environment where we could experiment with some format variations, and I think it should now handle your setup. Download the update at http://www.nowsms.com/download/latestpatch.zip, and I expect that will finally handle these crazy receipts. -bn | |||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 4869 Registered: 10-2002 |
Hi Sam, I want to make sure that I understand you correctly. You are checking "Route received messages to user via SMPP" purely to support delivery notifications, is that correct? You don't actually intend to perform any routing based upon these masks, is that correct? Instead, you want to route the receipts to the appropriate submitting account via the TrackSMPPReceipts=Yes setting. Still correct? It is NOT necessary to check "Route received messages to user via SMPP" for this purpose. (As you have found, that option will uncheck itself if the address field is blank.) It is only necessary to check "Enable SMPP Login for this user". If SMPP login is enabled, we route the receipts to the user's SMPP Q (or USERS\username\Q directory). If SMPP login is not enabled, then the message goes to the SMS-IN directory for 2-way processing. Does that explain the logic? Let me know if you still have concerns or need further clarification. -bn | |||||
| Dani Riera New member Username: Drieran Post Number: 8 Registered: 05-2005 |
Hi Bryce, I tested the new release and runs fine except for second Receipt. Some providers givme two receipts for every sms sent, the first one with ACK and the second with DELIVERED. The first receipt is linked well with NowSMS ID, but the second no. An example of this is: id:1476984394 sub:001 dlvrd:001 submit date:0509101125 done date:0509101125 stat:ACKED err:003 text: @ id:4322C2C8 sub:001 dlvrd:001 submit date:0509101225 done date:0509101125 stat:DELIVRD err:000 text: @ Can you implement more that one receipt? Thanks | |||||
| sam Unregistered guest |
Hi Bryce, Regarding my queries: You are checking "Route received messages to user via SMPP" purely to support delivery notifications, is that correct? Yes. Precisely You don't actually intend to perform any routing based upon these masks, is that correct? Yes. Precisely Instead, you want to route the receipts to the appropriate submitting account via the TrackSMPPReceipts=Yes setting. Still correct? Yes. Precisely It is NOT necessary to check "Route received messages to user via SMPP" for this purpose. (As you have found, that option will uncheck itself if the address field is blank.) If i dont check it then no DRs come back to the respective client. Instead they get stored in the SMSIN folder. I think you require the option to enable user to get routed sms messages in this case the DRs. It is only necessary to check "Enable SMPP Login for this user". If SMPP login is enabled, we route the receipts to the user's SMPP Q (or USERS\username\Q directory). As my previous responce. Messages dont get routed to the client. They get stored in the SMS IN FOlder. If SMPP login is not enabled, then the message goes to the SMS-IN directory for 2-way processing. SMPP login is enabled and even afer that it goes in the SMSIN folder. Thanks for your responce. Sam | |||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 4875 Registered: 10-2002 |
Hi Dani, Getting 2 receipts back is quite common. Oftentimes, providers can't return actual delivery receipts for some networks. So frequently they'll return an initial receipt to confirm that the message has been routed to the SMSC responsible for delivery. Then later, if it is supported, you'll get a second receipt for the actual delivery. I've seen this a fair bit, and it's not a problem. There's not a limit of only one getting processed. I suspect in your case that there is something different about the receipt that is not getting processed correctly. I took another look at your previous log, and I think I see the problem. It looks like you are connecting to the service provider simultaneously with the same account on separate servers at the service provider. If the receipt comes back from the same server as it was submitted to, then it gets handled properly. If the receipt comes back from the the other server, we don't recognise it. We've already dealt with this issue for multiple connections to the same server, but this will take some additional thought. Basically, the problem here is that you're submitting the message to smpp3.mblox.com ... the first receipt comes back from that server, but the second one comes back from smpp4.mblox.com. And as I think about it, this is a very common configuration...as for fault tolerance reasons, some providers will allow you to simultaneously connect with the same user account to more than one of their servers. The problem is that don't know that the multiple SMSC entries are connecting to the same SMS service provider. We can't assume that each server has a globally unique pool of message IDs, so we need to have a configuration option that allows us to group the servers together into a shared message ID pool. I'm not sure that there's any real good clean way for us to do this. So after much debate here, this is what we're going to do... I've posted another update to http://www.nowsms.com/download/latestpatch.zip, the version number hasn't changed, only one of the DLLs is updated. In this version, 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. So, in your case, if you edit SMSGW.INI, and under each [SMPP - host:port] section, added TrackSMPPReceipts=mblox, then all of the id's for these connections would be tracked in a single grouping, instead of a "per SMSC" grouping. Or, since grouping them all together might not be the best idea, a better idea would be to group them by the account names. For example, for each account that logs in to both smpp3.mblox.com and smpp4.mblox.com, you would place TrackSMPPReceipts=mblox####, where #### is a unique id (such as the account name) under which the message IDs will be tracked gor that group of SMPP connections. I hope this explanation makes sense, as it's definitely been a struggle for me to try to find the words to describe this type of configuration. Please note that this configuration step is only required when you have a situation where you are logging in under the same user account to multiple servers at the same SMS service provider. -bn | |||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 4876 Registered: 10-2002 |
Hi Sam, Make sure that you're using v5.51g from the other links referenced on this thread, as we have made a number of changes in all of this logic as we work out the issues of different providers and configurations. But if you're still seeing the delivery receipts going to SMS-IN, instead of getting routed to user accounts, then I would like to see debug logs so that I can understand the message flow and configuration. To enable the debug logs, check the options on the "Serial #" page of the configuration dialog. Then submit a message with delivery receipt requested ... and wait for the delivery receipts to come back in. I'd like to see the resulting debug logs, specifically the SMSDEBUG.LOG and SMPPDEBUG.LOG files. You can either post them here, or e-mail them to nowsms@now.co.uk (if you e-mail them, put "Attention: Bryce" in the subject line, and reference this thread, so that I know what I'm looking for.) -bn | |||||
| Dani Riera New member Username: Drieran Post Number: 9 Registered: 05-2005 |
Hi Brice, I updated the changed DLL and I configured in SMSGW.INI every [SMPP] entry grouping as you described. I have two connections for every country and I grouped countries. The first tests are right. Good job. Thanks, Dani | |||||
| Sam Unregistered guest |
Hi Bryce, It works Great :-). Hats off to you and your team. Tested yesterday and worked great. My trial period of NowSMS got expired today on my desktop and would test from another PC extensively and update you. Greaj Job.. Sam | |||||
| Sam Unregistered guest |
Hi Bryce, Works wonderfully well with the DRs. There is one issue on the routing. The perfered SMSC connection for tab works only for 100 connections. I had made changes in the SMSGW file for more then 100 and it never worked and the 101th routing failed to show up in the properties of the SMSC connection. Kindly do haev a look at this. Rest if perfect!!!!! Sam | |||||
| Sam Unregistered guest |
Hi Bryce, Even the SMS Debug log shows uptil the 100th routing details. 101 is not displayed: 17:14:19:807 [0] main: preferred routing = 447958*,SMPP - 127.0.0.1:5872 17:14:19:807 [0] main: preferred routing = 447959*,SMPP - 127.0.0.1:5872 I tried doing it manually via the properties tab and got the following error that maximum enteries in the list error and it didnt take in the 101th value.  Sam | |||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 4928 Registered: 10-2002 |
Hi Sam, I thought we had removed that limitation awhile back, but apparently not. There is an update to fix this, it is at http://www.nowsms.com/download/nowsmsasync.zip. This is a different link than before, I just want to make sure that the changes discussed in the following thread: http://support.nowsms.com/discus/messages/1/10862.html ... are good and stable, before we make this the official current patch version. -bn | |||||
| Sam Unregistered guest |
Hello Bryce, Tested it out and the routing issue is resolved. Thanks a lot for your efforts. Sam | |||||
SMSDEBUG.LOG
