| Proper Setup of Routing SMS Responses to Client Application |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - SMS Issues ⬆ Archive through April 13, 2018 ⬆ |
◄ ► |
| Author | Message | |||
| Maximilian Freund New member Username: Maxfr Post Number: 1 Registered: 11-2017 |
Hi, We are basically using nowSMS as a gateway to our SMSC server. There are several client applications that connect to nowSMS through SMPP v3.4 using the credentials of users managed by nowSMS. The client applications are sending only binary messages (OTA messages) that should through nowSMS go to the SMSC, reach a mobile and finally a specific SIM card that processes the OTA messages and usually answers with a so-called Proof of Receipt (PoR) that will be sent back via the SMSC to nowSMS where it should get routed to the proper client application. This works currently only correctly if we check in the SMSC Configuration dialogue 'Route SMS to Local User' where we can specify only a single user. However, as soon as we have several applications connected or even several instances of the same application we run into a problem as the response messages are only routed to one user, while the other users / applications are waiting for the response until the eventually time out. As 'phone number' we are using the short code of our SMSC large account number while the actual MSISDN of the SIM card targeted appears as 'Sender'. What are we missing here? How do we have to setup nowSMS to handle multiple users with response messages that need to get routed properly to the corresponding user? | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 5876 Registered: 08-2008 |
Hi, Apologies for the delay in response. The short answer is that there is no configuration option for this. If each application used a separate short code sender, you could route based on that (which I realize may not be practical). The longer answer is that I asked our engineering team to evaluate ways to handle this. We do currently provide this type of routing for delivery reports, but those contain a unique message id to facilitate routing. To support your scenario, we would need to track each destination a client sends to, and force any subsequent messages from that number back to the appropriate client account. That type of solution is imperfect...but we do currently support it for email to SMS, routing SMS replies back to email. I am asking our team if something similar could be implemented for routing replies back to local user accounts. -- Des NowSMS Support | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 5880 Registered: 08-2008 |
Follow-up... Our engineering team took a closer look at this scenario, and is implementing a config setting to enable reply routing like I described. A test version is expected next week or the following week...advise if you would like to try this test version. -- Des NowSMS Support | |||
| Maximilian Freund New member Username: Maxfr Post Number: 2 Registered: 11-2017 |
Wow, I am really impressed about your team. Yes, I would like to download and test this test version as soon as it is available. Maximilian | |||
| Maximilian Freund New member Username: Maxfr Post Number: 3 Registered: 11-2017 |
Can I have an update on the status of the test version? | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 5885 Registered: 08-2008 |
Hi Maximilian, We had some testing issues related to another change in this update, but it is now ready for testing. The beta (can be used for a fresh install or to update an existing installation) is available at https://www.nowsms.com/download/nowsms20171201.zip Add one of the following settings to the [SMSGW] section of SMSGW.INI to enable the functionality you want: ReplyTrack=Yes ReplyTrackSimple=Yes Both settings track outbound messages sent by different NowSMS user accounts. ReplyTrackSimple=Yes tracks only the destination address of the outbound message. If an inbound message has a matching source address, the message is routed to the user account that most recently sent to that address. ReplyTrack=Yes tracks both source and destination of outbound messages. For an inbound message to be considered a reply match, the inbound source/destination must match the outbound destination/source. -- Des NowSMS Support | |||
| Maximilian Freund New member Username: Maxfr Post Number: 4 Registered: 11-2017 |
I wish you a Happy New Year. We downloaded and installed the new version. Alas, to no avail, i.e. we tried both settings (ReplyTrack=Yes and ReplyTrackSimple=Yes), but neither of them led to the desired result, meaning the PoR was NOT sent back to the client, unless we specify 'Route SMS to local user' with the corresponding user name. Find below the entry of the corresponding SMS Debug logs (with ReplyTrack=Yes): SMSIN: 2018-01-09 14:41:57:515,00491742500106,UCP - 139.7.144.128:8000,Binary=1;DCS=F6;UDH=027100;Data=00180AB0000100000000000000029 00098940281610760817112;SMSCRouteName=VFDE Live SMSC;Recip=70812 SMSOUT: 2018-01-09 14:41:52:031,58C2F57F,10.2.151.189,+491742500106,OK -- UCP - 139.7.144.128:8000,SubmitUser=OTT3;SMSCRouteName=VFDE Live SMSC;Sender=70812;Binary=1;PID=7F;DCS=F6;UDH=027000;Data=00281516211919B00001EA9 1C9373F2AC27DD46121A1CEFD1217BCC7DA568943A100846EF39F0A3A4661 2018-01-09 14:41:57:515,58C2F580,,70812,OK -- LocalUser:OTT3,SubmitUser=UCP - 139.7.144.128:8000;Sender=00491742500106;Binary=1;DCS=F6;UDH=027100;Data=00180AB 000010000000000000002900098940281610760817112 Please note that there seems to be a mismatch in the format of the MSISDN between SMSIN and SMSOUT (00491742500106 vs. +491742500106). It's unclear to us though whether this causes that ReplyTrack is not working. The corresponding log in SMSDebug looks like: 14:41:51:390 [21] SMPPServerReceiveMessageCallback: inbound message: sender=70812, recip=+491742500106, pid=7F, dcs=F6, msgFlags=0, udh=027000, msg=00281516211919B00001EA91C9373F2AC27DD46121A1CEFD1217BCC7DA568943A100846EF39F 0A3A4661 14:41:51:390 [21] CheckBlackList: +491742500106 14:41:51:390 [21] SMPPServerReceiveMessageCallback: C:\PROGRA~1\NowSMS\Q\OTT3\ 14:41:51:390 [21] VerifySudirsExist: C:\PROGRA~1\NowSMS\Q\OTT3 14:41:51:390 [21] VerifySudirsExist: Created directory 14:41:51:390 [21] SMPPServerReceiveMessageCallback: C:\PROGRA~1\NowSMS\Q\OTT3\58C2F57F.REQ 14:41:51:390 [21] CheckPreferredSender: Preferred Sender Match 14:41:51:390 [21] CheckPreferredSender: UCP - 139.7.144.128:8000 14:41:51:390 [21] CheckPreferredRoute: Preferred Sender Match / Available Route 14:41:51:390 [21] CheckPreferredRoute: UCP - 139.7.144.128:8000 14:41:51:390 [21] CheckPreferredRoute: Preferred Sender&Recip Match 14:41:51:390 [21] CheckPreferredRoute: UCP - 139.7.144.128:8000 14:41:51:390 [21] CheckPreferredRouteMulti: Preferred Sender Match 14:41:51:390 [21] CheckPreferredRouteMulti: UCP - 139.7.144.128:8000 14:41:51:390 [21] MessageRoutesAdd: OTT3\58C2F57F.REQ 14:41:51:390 [21] MessageRoutesAdd: UCP - 139.7.144.128:8000 14:41:51:500 [20] ThreadProcessModem: Processing 58C2F57F.REQ... 14:41:54:515 [5] ThreadListenForSMPPConnections: Before accept 14:41:54:515 [5] ThreadListenForSMPPConnections: After accept 14:41:54:515 [22] ThreadProcessSMPPConnection: Processing SMPP connection from 10.208.64.109... 14:41:54:515 [22] ThreadProcessSMPPConnection: Releasing SMPP connection from 10.208.64.109 14:41:54:515 [22] WaitForSocketClose: WinSock reported ioctlsocket complete 14:41:55:843 [5] ThreadListenForSMPPConnections: Before accept 14:41:55:843 [5] ThreadListenForSMPPConnections: After accept 14:41:55:843 [22] ThreadProcessSMPPConnection: Processing SMPP connection from 10.208.64.108... 14:41:55:843 [22] ThreadProcessSMPPConnection: Releasing SMPP connection from 10.208.64.108 14:41:55:843 [22] WaitForSocketClose: WinSock reported ioctlsocket complete 14:41:57:515 [20] UCPReceiveMessageCallback: inbound message: sender=00491742500106, recip=70812, pid=0, dcs=F6, msgFlags=0, udh=027100, msg=00180AB000010000000000000002900098940281610760817112 14:41:57:531 [20] Debug: Duplicating message (a) 14:41:57:531 [20] Debug: OTT3 14:41:57:531 [9] ThreadProcessInboundSMS: Processing 58C2F581.IN... 14:41:57:531 [9] ThreadProcessInboundSMS: UDH Dest Port = 0 14:41:57:531 [9] ThreadProcessInboundSMS: Processing complete 58C2F581.IN... | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 8242 Registered: 10-2002 |
Hi Maximilian, Happy New Year! I do believe that it is not working because of the 0049 vs. +49 mismatch. I'd suggest the following setting to apply automatic conversion so that the numbers will match. Edit the SMSGW.INI file and under the [SMSGW] section add: GlobalRecipPrefixConvert=00:+ GlobalSenderPrefixConvert=00:+ This will automatically convert 00 at the start of any numbers to + For more options related to this, see https://www.nowsms.com/international-prefix-conversion-for-sms -bn Bryce Norwood Now SMS/MMS Support | |||
| Maximilian Freund New member Username: Maxfr Post Number: 5 Registered: 11-2017 |
Hi Bryce, Thank you for the superfast response. Unfortunately, it still doesn't work, i.e. the PoR gets only forwarded if 'Route to local user' is set. Unfortunately, there is nothing visible for us in nowSMS that helps us to explain why the messages are not sent back. So, we are wondering how we could proceed from here. If it would make sense to share with you the entire configuration of nowSMS, please let me know. Kind regards, Maximilian | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 8245 Registered: 10-2002 |
Hi Maximilian, We must be overlooking something...possibly in how we implemented this setting...so, yes, sharing the entire configuration would expedite resolution. Unfortunately, the current debugging only logs information if a reply match routes the message. Can you do the following? Remove the 'Route to local user' setting. Send several test messages with replies. ZIP or RAR the following files: SMSGW.INI SMSDEBUG.LOG SMSOUT-yyyymmdd.LOG SMSIN-yyyymmdd.LOG SMPPDATA\REPTRACK.DB Send files to nowsms@nowsms.com with Attention: Bryce on the subject line. -bn Bryce Norwood Now SMS/MMS Support | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 8253 Registered: 10-2002 |
Hi Maximilian, There's a problem in the settings to remap 00 to + "Global", apparently is not being applied to all messages. Under [UCP - 139.7.144.128:8000] add: InRecipPrefixConvert=00:+ InSenderPrefixConvert=00:+ Those settings will apply the conversion, which should then enable the reply track routing to work. -bn Bryce Norwood Now SMS/MMS Support | |||
| Maximilian Freund New member Username: Maxfr Post Number: 6 Registered: 11-2017 |
Hi Bryce, I tried the two settings you sent us, and it didn't work. In the smsout file, however, I noticed that the message was apparently routed to the wrong user. That's why I checked the SMS User settings again and found that 'Accept received messages for this user' has been set where the short code 70812 was assigned. When I removed this setting for all users except my test user 'OTT3', the PoR was routed to the application in question. Unfortunately, that seems to work only if that user is connected once. As soon as 'OTT3' is connected several time, the message is routed only to the most recent instance of the connection. So, we have basically 2 questions: 1. How can messages (PoR) send to the actually requesting user instance? 2. How can different users use the same short code to send and receive messages. If you require more information about the entire settings please let me know. Kind regards, Maximilian | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 8262 Registered: 10-2002 |
Hi Maximilian, Do you still see an originator number of 0049xxxxxxxxx on the reply? As long as there is a mismatch in the number format between the original send and the reply, the system will not correctly route the reply. We've done some testing...and it appears that we are testing for a reply address match before the 00 => + conversion occurs. We're going to update the logic to apply the conversion first, which should resolve the issue. For now...however, I have an idea that should work...instead of converting 00 to + for the inbound messages, let's try converting + to 00 when routing the messages outbound. Remove all of the RecipPrefixConvert and SenderPrefixConvert settings that were recommended previously. Under the [SMSGW] section add: GlobalRecipPrefixConvert=+ :00 GlobalSenderPrefixConvert=+:00
When this setting for reply tracking is working properly, 'Accept received messages for this user' should be set. However, the recipient addresses should be blank...except for one account that should receive messages that are not a reply match. Reply tracking will handle routing for actual replies and override that setting.
Routing is user account based, not connection based. If a user account has multiple receiver and/or transceiver connections, replies could be routed to any of the connections. To accomplish what you want, each client would need a separate user account. -bn Bryce Norwood Now SMS/MMS Support | |||
| Maximilian Freund New member Username: Maxfr Post Number: 7 Registered: 11-2017 |
Hi Bryce, We tried your suggestions, alas to no avail. Without the specific recipient set in the SMS User, the PoR is not routed back to the user. We also tried to add OutRecipPrefixConvert=+ :00 OutSenderPrefixConvert=+:00 under [UCP - 139.7.144.128:8000], again with no success. I will add some details after my meeting somewhere this afternoon. Kind regards, Maximilian | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 8263 Registered: 10-2002 |
Apologies again, Maximilian. After all this time, I finally set up a similar environment to test. The prefix conversions are all occurring after the reply tracking logic. So the reply tracking does not see a match. We changed the sequence, and it is now working in my tests. Try the version at https://www.nowsms.com/download/nowsms20180125.zip with [SMSGW] GlobalRecipPrefixConvert=00:+ GlobalSenderPrefixConvert=00:+ -bn Bryce Norwood Now SMS/MMS Support | |||
| Maxime Chevry New member Username: Maximechevry Post Number: 1 Registered: 01-2018 |
Hi All, How did the testing go? Is this now working? I have the same use case and would be happy to support further testing if required. Cheers, Max | |||
