| 2 Way SMS and Delivery Reports returned to Original Sender |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - SMS Issues ⬆ Archive through May 20, 2013 ⬆ |
◄ ► |
| Author | Message | |||
| Tim Williams New member Username: Timw Post Number: 16 Registered: 09-2010 |
Hi, We have the Delivery reports up and running ok and having looked through the forums and documentation (and previous questions I have asked) it isn't possible via the 2 Way SMS to find out if the user requested a delivery receipt and/or then send back a delivery receipt via the HTTP interface (using a SMS User) and have this forwarded to the originating SMPP SMSC. The current process is: Multiple SMPP SMSC connections in -> 2Way SMS -> Back to NowSMS (sent in by HTTP SMS User after processing/choosing route dynamically) to delivery via alternate SMPP SMSC specified in the HTTP request -> Delivery Report comes in (maybe) -> 2Way SMS -> Can't send back to original SMPP SMSC. It appears there is functionality in place for this to work if we were submitting to a HTTP SMSC but not with the 2Way SMS? We really do need to be able to send the delivery reports back to the originating sender when requested. | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 4308 Registered: 08-2008 |
Hi Tim, I'm having a little difficulty trying to follow your configuration. Let me try to explain it back to you as a test to see if I understand. You are initiating outbound SMPP connections to a variety of different servers defined in the SMSC table. When messages come in from those connections, they get routed to 2-way SMS. Your 2-way SMS command chooses an outbound route and resubmits the message to NowSMS via HTTP. Resubmitted messages get sent out via one of the other defined SMPP servers defined in the SMSC table. If a delivery receipt was requested, when a delivery receipt is requested it gets routed to 2-way SMS ... but you cannot figure out how to generate a delivery receipt that will be routed back out via an SMPP SMSC connection. Is my understanding correct? If so, I'm not sure that 2-way SMS is the right way to handle this. But I see different issues with alternate configurations that come to mind. Unfortunately I don't see any easy answers, but I need to think about it some more and discuss with my colleagues for additional thoughts. Can you confirm that I am understanding the scenario correctly? -- Des NowSMS Support | |||
| Tim Williams New member Username: Timw Post Number: 17 Registered: 09-2010 |
Hi Des, Your understanding is correct, the only difference is we have to request the delivery receipt when submitting via HTTP regardless as we have no way of knowing if the sender requested one using 2Way SMS. Regards Tim | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 4309 Registered: 08-2008 |
Hi Tim, OK ... we are reviewing this. I think it would resolve your problem if we did not attempt to validate ReceiptMessageId as being associated with an HTTP SMSC connection. Right now if you submit a message with parameters ReceiptDelivered=Yes (or ReceiptFailed=Yes) and ReceiptMessageID= ... we attempt to validate that the message ID was assigned for a message routed to an upstream SMSC connection. If we removed that validation, then I think what you are trying to do would work. (Assuming that the servers would accept the delivery receipts. There have been some recent threads about receipts and esm_class issues when attempting to deliver receipts to an outbind SMPP connection. SMPP protocol sort of assumes that delivery receipts would only get routed from server to client. I'm reviewing my notes on those issues in anticipation of follow-up questions should we be able to get this first issue resolved.) -- Des NowSMS Support | |||
| Tim Williams New member Username: Timw Post Number: 18 Registered: 09-2010 |
Hi Des, Is this suggesting that once we receive a delivery report we could then send a http request back to NowSMS (as it's described in the HTTP SMSC submit delivery reports threads) where we pass a ReceiptDelivered=Yes/No to say if it was delivered or not along with the sending number etc? If we need to send a ReceiptMessageID as well we can do that as we log the original message id when it comes in via 2WaySMS, and also get the message id when we send it back out - so could return the original ID of the inbound SMS. | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 4310 Registered: 08-2008 |
Hi Tim, Yes. Presently if you try to submit &ReceiptDelivered=Yes&ReceiptMessageID=xxxxx, we are validating ReceiptMessageID as being associated with an upstream HTTP SMSC. I don't see why that validation should be required, so I am pursuing getting this changed. Note that at present, the options for specifying status are ReceiptDelivered=Yes or ReceiptFailed=Yes or ReceiptIntransit=Yes. Hopefully we can get this change implemented by the end of this week, if not early next. -- Des NowSMS Support | |||
| Tim Williams New member Username: Timw Post Number: 19 Registered: 09-2010 |
Hi Des, That sounds like great news, I look forward to helping test. | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 4313 Registered: 08-2008 |
Hi Tim, I just wanted to provide some follow-up. We are still working on this ... the change I mentioned in this thread is a relatively small piece. However, we are taking a larger view of delivery report handling in SMS hubbing environments, and attempting to address a number of related issues at the same time. It won't be too much longer, but I don't have a firm ETA yet. -- Des NowSMS Support | |||
| Tim Williams New member Username: Timw Post Number: 20 Registered: 09-2010 |
Hi Des, Thanks for the update, please keep me updated. | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 4334 Registered: 08-2008 |
Hi Tim, Unfortunately based upon our current schedule, I am not going to be able to post this update until April 1 or 2 ... so a week from next Monday or Tuesday. In this update, we have added better support for SMS hubbing. In the type of scenario that you describe, our intent is to support that configuration using routing based upon accounting callbacks. There are some other threads that discuss the existing ReRouteReceived=Any setting. When this setting is applied to an SMSC connection, it means that any SMS messages received over this connection should be re-routed for outbound delivery (and not routed to 2-way command processing). Accounting callbacks are used to establish which outbound route should be used. This configuration works well today. However, NowSMS relies on accounting callbacks to route delivery reports back to the correct connection. (Our next update will track and route delivery reports to the correct connection automatically, just like we already do for messages submitted from SMPP client connections.) There is a problem, however. When NowSMS initiates an SMPP connection, it takes the role of client, and the other side is the server. Clients are expected to use submit_sm to transfer SMS messages, and messages are received by the client using the deliver_sm format. Servers are expected to use deliver_sm to transfer SMS messages to a client, and messages received by the client from the server use the submit_sm format. Here's the problem ... SMPP Message IDs are not global. Each SMPP server that a message is transferred to assigns its own message ID to it and has no knowledge of IDs assigned by other servers that the message has been routed through. When an SMPP client uses submit_sm to transfer a message to a server, the submit_sm response reports the message ID assigned by the upstream server. So when a receipt is later returned, the client can see the receipt message ID and translate it back to the ID that it had originally assigned. When deliver_sm is used, there is no support for returning a message ID. So if the message has a delivery receipt requested, there is no way to track its message ID. Let me attempt to explain with your configuration scenario: As you are initiating both connections, your NowSMS is an SMPP client to both SMSC1 and SMSC2. Let's follow the path of a message from a subscriber of SMSC1 to a subscriber of SMSC2. SMSC1 assigns a message ID of SMSC1xxxx and uses deliver_sm to route the message to NowSMS. NowSMS assigns a message ID of NowSMSxxxx, but it has no way to tell SMSC1 of this ID assignment, and it has no knowledge of any message ID previously used by SMSC1. NowSMS uses submit_sm to transmit the message to SMSC2. SMSC2 assigns a new message ID of SMSC2xxxx and reports that new message ID to NowSMS in the submit_sm response. Later, a delivery report is generated. SMSC2 uses deliver_sm to transmit the message to NowSMS. The delivery report references message ID SMSC2xxxx. NowSMS recognizes that it previously saw this message ID, and translates it back to NowSMSxxxx. It is possible to route the message back to SMSC1, but there is no way possible to translate the receipt message ID back to SMSC1xxxx. SMSC1 sees a receipt message ID of NowSMSxxxx and cannot correlate this receipt with the original message. There are two possible solutions to this issue. Solution #1 - Use data_sm instead of submit_sm and deliver_sm. When data_sm is used, an upstream message ID can be reported back regardless of which end of the connection initiated the connection. The two sides of the connection are seen as peers instead of in client or server roles. The problem is that both SMPP servers must use data_sm and understand the peer relationship in order to properly support delivery receipts. This is because when a message goes from one SMPP system to another, the receiving system must always assign a new message ID and has no knowledge of previously assigned message IDs. They can only handle delivery receipts properly if they track the upstream assigned message ID and translate it back. Currently, NowSMS can receive messages transferred with data_sm, but it never uses data_sm. As such, it can only translate upstream message IDs when it uses submit_sm (NowSMS is the client). You're probably figuring that you should be ok because NowSMS is the client for both of your connections. The problem is that the other SMSC is using deliver_sm to transfer the message to NowSMS. At that point, that other SMSC loses all ability to further track the message. So it is imperative that the other SMSC always use data_sm (or submit_sm) to allow it to track delivery reports. NowSMS cannot do it alone. Current versions of NowSMS can support data_sm on the receiving side, but not on the transmitting side. This means that if the other SMSCs use data_sm, and can properly correlate receipt message IDs, all is well. The next version of NowSMS will allow data_sm to be configured for any client or SMSC connection for full hubbing support. All that said, considering how much effort we've gone through, what are the chances that the SMSC to which you are connecting understands data_sm and this hubbing concept. Slim at best, which brings us to... Solution #2 - If data_sm cannot be supported, each interconnected SMSC must have both a client and server connection to the other system. In other words, NowSMS has two SMSC connections defined, and two SMS User accounts defined. One each for both of the SMSCs. I'll try to explain by labeling the connections. SMSC1-NowSMS - SMSC1 initiates as client (NowSMS is server). SMSC2-NowSMS - SMSC2 initiates as client (NowSMS is server). NowSMS-SMSC1 - NowSMS initiates as client. NowSMS-SMSC2 - NowSMS initiates as client. Path of message from SMSC1 to SMSC2. submit_sm used => SMSC1-NowSMS submit_sm used => NowSMS-SMSC2 deliver_sm for receipt <= NowSMS-SMSC2 deliver_sm for receipt <= SMSC1-NowSMS Path of message from SMSC2 to SMSC1. submit_sm used => SMSC2-NowSMS submit_sm used => NowSMS-SMSC1 deliver_sm for receipt <= NowSMS-SMSC1 deliver_sm for receipt <= SMSC2-NowSMS In other words: SMSCx-NowSMS channel handles outbound messages from that SMSC and routes back associated delivery reports. NowSMS-SMSC channel handles inbound messages from other SMSC(s) and routes back associated delivery reports. I'm probably doing a horrible job of explaining it, but it is difficult to explain. Bottom line is that unless data_sm is fully implemented for hubbing, both sides of a connection must fill both client and server roles for delivery receipts to have any hope of working. How does this apply to your scenario where you're routing the messages with 2-way messaging? Well, unless you go the dual client server connection route, or your partners support data_sm, there is likely to be considerable confusion over delivery reports. It is important that you carefully map out transaction flow to understand message ID re-assignment issues. These issues are partly why we currently don't allow HTTP submission of delivery reports except in HTTP SMSC scenarios. As promised, the next update will add this support, but you need to carefully think through your message and delivery receipt flow to determine whether or not it will work for your scenario. I believe it will work if your partners can support SMS hubbing with data_sm, or the dual client server connection scenario. In other words, even with this update coming soon, there is a lot to think about. And to be honest, because of these complexities, delivery reports are often suppressed in these scenarios. -- Des NowSMS Support | |||
| Tim Williams New member Username: Timw Post Number: 21 Registered: 09-2010 |
Hi Des, Thanks for the update, I will have to check on the possibilities of our SMSC connections supporting and/or allowing us to create 2 connections - I assume that using 2Way SMS we can specify a SMSUser to send the SMS to instead of the normal SMSC? | |||
| Tim Williams New member Username: Timw Post Number: 22 Registered: 09-2010 |
Hi Des, Thanks for the update, I will have to check on the possibilities of our SMSC connections supporting and/or allowing us to create 2 connections - I assume that using 2Way SMS we can specify a SMSUser to send the SMS to instead of the normal SMSC? | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 4337 Registered: 08-2008 |
Hi Tim, Yes. For HTTP submission to a SMSUser, use the parameter &LocalUser=xxxx If routing with accounting callbacks, return SMSCRoute=localuser:xxxx I believe for consistency, we now also support &SMSCRoute=localuser:xxxx in the HTTP URL submission as well. -- Des NowSMS Support | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 4348 Registered: 08-2008 |
Hi Tim, We have posted an update at http://www.nowsms.com/download/nowsms20130401.zip. This update includes improved SMS hubbing support and options to use data_sm as I mentioned in my earlier post. To directly address what you want to accomplish with delivery receipts via 2-way SMS, the following changes were made: * 2-Way SMS Support: Supported added for additional parameters related to delivery report processing. Include &@@RECEIPTVARS@@ as the final 2-way command URL parameter and NowSMS will include zero or more of the following variables in the URL (depending on message properties): ReceiptMessageId=xxx specifies that this is a delivery report for the originally submitted message with Message ID xxx. ReceiptDelivered=Yes indicates that the delivery report was successful. ReceiptIntransit=Yes is a delivery report indication that the message was accepted but actual status is not known. ReceiptFailed=Yes is a non-delivery report indicating failure. ReceiptRequested=Yes indicates that the sender is requesting a delivery report for this message. * HTTP Delivery Report submission: Previously it was only possible for HTTP based SMSCs to generate delivery reports. NowSMS will now accept delivery reports more generally (allowing HTTP 2-way commands to generate or forward delivery reports, for example), supporting the HTTP URL parameters ReceiptMessageId=xxx, and a status indication using one of the following: ReceiptDelivered=Yes, ReceiptIntransit=Yes or ReceiptFailed=Yes. Just be aware that as I mentioned, if you receive a message from an SMSC connection via deliver_sm (NowSMS in the server role), that other SMSC will be unable to resolve the delivery receipt message ID. The only solutions for this dilemma are: 1.) Two SMPP connections per interconnect, one in server role, one in client role. Messages must always be transmitted using submit_sm (client to server), and delivery reports will be transmitted using deliver_sm. 2.) Use data_sm for more of a peer-to-peer connection. NowSMS now includes options to configure both outbind and inbind connections to use data_sm. In the end, delivery receipts tend to be complicated in these scenarios, so also refer to our changes.txt file in the updated release for information on how to block them. (Also at http://www.nowsms.com/download/changes.txt) -- Des NowSMS Support | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 4373 Registered: 08-2008 |
Additional follow-up ... we posted an article that attempts to do a better job of explaining the issues with delivery receipts in a hubbing environment: http://www.nowsms.com/sms-hubbing-considerations | |||
| Tim Williams New member Username: Timw Post Number: 23 Registered: 09-2010 |
Thanks Des, I was away last week and now back and digesting all this and hoping to get the latest version installed and in testing shortly. | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 4378 Registered: 08-2008 |
Hi Tim, For your scenario, the 2-way command approach should be fine. The additional parameter support should give you what you need. We are just also trying to address similar issues for configurations where the message flow occurs without the use of 2-way SMS command involvement. -- Des NowSMS Support | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 4379 Registered: 08-2008 |
Follow-up ... while the 2-way command approach is fine, I forgot that you still have the delivery receipt issue where message ID tracking breaks down if at any time deliver_sm (SMSC to ESME) is used to transfer any message other than a delivery receipt. So, yes, there is still digestion required. -- Des NowSMS Support | |||
| Tim Williams New member Username: Timw Post Number: 24 Registered: 09-2010 |
Hi Des, We are in the process of upgrading and also testing, please can you confirm the following: HTTP Delivery Report submission: Previously it was only possible for HTTP based SMSCs to generate delivery reports. NowSMS will now accept delivery reports more generally (allowing HTTP 2-way commands to generate or forward delivery reports, for example), supporting the HTTP URL parameters ReceiptMessageId=xxx, and a status indication using one of the following: ReceiptDelivered=Yes, ReceiptIntransit=Yes or ReceiptFailed=Yes. Are any other parameters required for sending (for example Phone=x) or will it be able to get all the data from ReceiptMessageId=x so we would just send ?ReceiptMessageId=x&ReceiptDelivered=Yes and it will then send the correct receipt via the original connection for that message? Regards Tim | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 4426 Registered: 08-2008 |
Hi Tim, In this scenario, NowSMS does not remember the message details associated with the SMS. You would want to also provide PhoneNumber= and Sender= parameters with the submission. This has me thinking through the process, however. And although you will be able to generate a delivery receipt in this manner, I do not think the ReceiptMessageId will be known by the other SMSC. The issue is an SMPP protocol issue. If deliver_sm is ever used to transfer a message, the SMPP messageID chain is broken. (It is ok to use deliver_sm to transfer a delivery receipt, but not an actual message.) If you initiate the SMPP connection (appears in your SMSC list), then submit_sm is used to transfer messages from your system to the SMSC. However, by default the other system is going to use deliver_sm to transfer messages to you. When they use deliver_sm, the messageID tracking chain is broken, and receipt messageIDs will no longer match up to the original message. If the other system can use data_sm instead of deliver_sm (and understand that it is a hub connection where it must track upstream messageIDs), then it can work. Otherwise you need two connections, one initiated from each side. In the dual connection scenario, regular SMS messages must flow ESME to SMSC (sumbit_sm). Delivery reports should flow SMSC to ESME (deliver_sm). Sorry this is so confusing...but there are SMPP protocol limitations that get in the way. Maybe we should go back to square 1. You'd probably be better off using accounting callbacks to route messages instead of 2-way SMS. (And use the ReRouteReceived setting to force messages received from an SMSC to the outbound queue instead of 2-way SMS.) However, there is still the issue that regular SMS messages cannot be transferred using deliver_sm (SMSC to ESME direction). deliver_sm breaks the messageID tracking chain. -- Des NowSMS Support | |||
| Tim Williams New member Username: Timw Post Number: 25 Registered: 09-2010 |
Hi Des, How it will work with the connections is the sender will connect to us as the SMSC and we will connect to the terminating partner as an ESME so the message should be submit_sm in and we should send submit_sm onwards, then the deliver_sm will come back in to us. | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 4432 Registered: 08-2008 |
Hi Tim, OK ... I think I understand. We have taken a long winding path, but we can now simplify. If the scenario is this: Sender (ESME) -> NowSMS (SMSC) NowSMS (ESME) -> Terminating Partner (SMSC) Then everything will work transparently for messages from Sender to Terminating Partner. Regular SMS messages will follow the path using submit_sm. Delivery reports will follow the reverse path using deliver_sm. 2-way SMS is not involved. 2-way SMS is normally triggered when a message is received on a connection where NowSMS is the ESME. However, in this scenario, when a delivery report is received from the terminating partner, NowSMS would see the receipt message ID and recognise it from an earlier submission to the terminating partner, and remember that it originated with the sender and use deliver_sm to route the report back to the sender. If this is not happening, and instead the reports are being routed to 2-way SMS, then this suggests that the terminating partner is having problems maintaining the message ID on their network. Here's what you want to check ... The SMSOUT-yyyymmdd.LOG will record the upstream message ID assigned by the terminating partner for each message. Compare this with the delivery reports in the SMSIN-yyyymmdd.LOG (although in fairness, if NowSMS sees a match from a previous upstream message ID it translates it before writing to the SMSIN LOG). For further verification of message IDs in the SMPP packets, use Wireshark to capture the packets. When submit_sm is used to submit a message upstream, the submit_sm response will contain the message ID assigned by the upstream server. When a deliver_sm comes back with a delivery report, the receipt message ID in the report should match a message ID from an earlier submit_sm response. I'm guessing that your original issue is that everything should have just worked. But if your terminating partner is having a problem with message IDs, this will result in delivery reports getting routed to 2-way SMS. This update will allow you to resubmit those delivery reports and deliver them to the sender ... but the sender will also face a mismatch message ID issue. -- Des NowSMS Support | |||
| Tim Williams New member Username: Timw Post Number: 26 Registered: 09-2010 |
Hi Des, Slight issue, currently our connections have always been SMPP and us as the SMSC but after previous messages have been setting up 2 connections per connection as discussed. We need all the inbound messages (regardless of how they come in) to go via the 2 Way SMS for billing purposes and routing options. If it is not possible for SMS From a SMSUser to goto 2Way SMS is this still possible? Regards Tim | |||
| Tim Williams New member Username: Timw Post Number: 27 Registered: 09-2010 |
Hi Des, After reading through your previous messages as well and reading up on the accounting callbacks it appears these may be able to do just what we want in the case of the flow of messages how you described - and we wouldn't have to worry about resubmitting the delivery reports unless there were issues? If this was enabled we should be able to use this instead of 2 way SMS for all the SMS? (regardless of how they come in - as some connections we cannot have both types) Regards | |||
| Tim Williams New member Username: Timw Post Number: 28 Registered: 09-2010 |
Sorry, Reading through the Accounting callbacks, it appears these are only used on messages that come "in" when we are operating as the SMSC and SMSUsers send them to us? in which case our current 2WaySMS would still be used for any messages that come in from our ESME connections to SMSC? If so - how does this work for Delivery Reports as wouldn't the 2Way SMS intercept them? I just need to get a path / solution in place to deal with all types of scenario. | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 4434 Registered: 08-2008 |
Hi Tim, There are different types of accounting callbacks depending on the message flow. For SMSC to ESME flow, Type=SMSIN is used. This callback has more limited control compared to the SMSSend and SMSSend/PreAuth callback that are used for ESME to SMSC flow. It can block a message, but it can't specify routing. For SMSC to ESME messages, the normal route is to the 2-way command processor, *unless* the message is a delivery report where the receipt message ID matches a previously submitted message. If a match is found, the message is routed automatically to the ESME that submitted it. This is why I indicated that delivery reports should only end up at the 2-way command processor if there is an upstream message ID problem. Continuing the focus on SMSC to ESME message flow, there is also a configuration setting that can be applied to the SMPP connection. Historically the setting is ReRouteReceived=Any, but in the new version we have added it to the configuration settings under SMPP Advanced Settings as "Re-Route Received Messages for Outbound Delivery". When this setting is enabled, after the Type=SMSIN callback, the message is then switched for "to SMSC" routing and the Type=SMSSend callbacks are triggered. (However, if the SMSC that delivered the message to us used deliver_sm instead of data_sm, the message ID tracking chain will be broken.) If you are using two connections so that each partner can be both SMSC and ESME, then you do not need to worry about ReRouteReceived. I mention it only for completeness. Bottom line is that accounting callbacks are designed to do what you need. And delivery reports should only end up at the 2-way command processor if there is an upstream message ID problem. It concerns me that the delivery reports are currently arriving in the 2-way command processor. You could use the ReRouteReceived setting and accounting callbacks to route them back to the correct partner, but I am concerned that since NowSMS did not see a match on the message ID to allow the delivery report to be routed automatically, your partner will face similar issues. It is best to figure out first why the delivery reports are not being processed automatically. (deliver_sm and the SMSC to ESME path used for routing the original message is often the culprit.) -- Des NowSMS Support | |||
| Tim Williams New member Username: Timw Post Number: 29 Registered: 09-2010 |
Hi Des, Thanks for that - We originally used the 2Way SMS command as have been using NowSMS for a number of years and until reading up on Accounting Callbacks I don't think some of the functionality required was in place until 2012. As all of our older connections where ESME -> SMSC all inbound messages would have been deliver_sm and then sent onwards (after 2Way Processing) as submit_sm, and the 2Way SMS is setup for all messages and the adidtional command to process delivery reports as well - this may well be why we currently see them hit the 2WaySMS as there is no route back to the sender. Using Accounting callbacks and new connections (where possible) so that our customers connect to us as via SMSUsers the delivery reports should be reouted back correctly as there will be no intercepting of the message. We do still require the 2Way SMS active for the older ESME -> SMSC connections for inbound SMS where they come in as deliver_sm though. It does look promising though and I will start working on this basis. | |||
| Tim Williams New member Username: Timw Post Number: 30 Registered: 09-2010 |
Last quesiton for now (I hope), just to confirm that the existing 2Way SMS will still process ok for messages that are received from the SMSC connections - will they also initiate the SMSIN callback or will one take precedence over the other? There is quite a lot of development going into this so I need to get it right. | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 4435 Registered: 08-2008 |
The SMSIN callback will take place before the existing 2-way SMS. Both will occur. (Unless a match on a receipt message ID is found in which the message is routed to ESME. In that case, the SMSIN callback still occurs, but the 2-way command is not triggered. (That said, there is also a configuration option to duplicate the message so it is also routed to the 2-way command, an option added for a customer tracking delivery reports using 2-way commands.)) | |||
| Tim Williams New member Username: Timw Post Number: 31 Registered: 09-2010 |
Hi Des, I now am in testing with this and have noticed some issues - in a lot of instances the UserData is not returned for subsequent SMSSend transactions after the PreAuth is allowed as the URL sent appears to append this data after everything else and when the SMS content is long although the message itself is all there the SMSCRoute and UserData are not passed as well? For example: I respond with: SMSCRoute=SMPP - xxx.xxx.xxx.xxx:xxxx UserData=xx The SMSSend (not PreAuth) comes in @ 239 character length (SMS Text length 123 characters) and contains all of the SMS but no UserData or SMSCRoute info, yet another response that is the same (apart from the userdata) returns everything ok (196 character length, SMS Text length 27 characters). Due to this we are unable to match up the pre auth with the SMSSend that comes in. Although when it is passed through correctly it does come through on all (inc the SMSOut - which comes in @ a character length of 289). The only difference I can see that may cause this is the message length itself? | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 4456 Registered: 08-2008 |
Hi Tim, I'd probably need to see an SMSDEBUG.LOG to understand. You do have either SMSAccountingPreAuthPerRecip=Yes or SMSAccountingMustSetRoute=Yes set in SMSGW.INI, correct? For messages submitted via HTTP, the UserData= and SMSCRoute= responses are only supported if one or both of these settings are configured. I ran some quick tests with messages of varying lengths (including long messages that NowSMS had to segment), and if UserData was returned in the PreAuth response, it was always passed back to SMSSend and SMSOut callbacks, regardless of message length. -- Des NowSMS Support | |||
| Tim Williams New member Username: Timw Post Number: 32 Registered: 09-2010 |
Hi Des, Yes both are set - ( I realise they both sort of do the same thing but I set them both anyway). I will have to enable the debug and re-enable the config change - please can you let me have your email to send the log to when done? | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 4457 Registered: 08-2008 |
Hi Tim, Send to nowsms@nowsms.com, put Attention: Des on the subject line. Unfortunately, I think current versions do not include the accounting callback response in the SMSDEBUG.LOG (unless it is a local PHP script). So you might also want to doublecheck with a Wireshark trace to verify that the response is being set in the callback like you expect. -- Des NowSMS Support | |||
