| Data_sm in NowSMS and Various Message/Receipt Flow Scenarios |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - SMS Issues ⬆ Archive through April 12, 2010 ⬆ |
◄ ► |
| Author | Message | |||
| ashot shahbazian Frequent Contributor Username: Animatele Post Number: 73 Registered: 06-2004 |
Bryce, Des: This discussion was started in http://www.nowsms.com/cgi-bin/discus/show.cgi?1/42106 Below are preliminary notes on the functionality which, when implemented, would allow NowSMS to seamlessly connect to most MNO SMSC-s for SMS Hubbing: When interacting with other SMSC-s by means of submit_sm and deliver_sm, if the session is initiated by NowSMS (ESME) and messages are generated and routed to NowSMS by the other SME (the most common scenario when connecting to retrieve subscriber traffic from an MNO SMSC,) transmitting delivery receipts from NowSMS to the SME is impossible. This is a general problem, which can be split into three separate problems: 1. SME is sending messages by deliver_sm command and NowSMS responds with a deliver_sm_resp. According to the SMPP v.3.4. spec, message_id field is not used in a deliver_sm PDU and should be set to empty_string. However, in this case the SME is missing the information it needs to be able to match the sent message with the receipt that is then sent by NowSMS. This makes it impossible for the MNO-s subscriber to fetch the status of his message. In such connection scenarios, the problem is commonly addressed by using data_sm and data_sm_resp, since the SMPP spec allows using the message_id field in the data_sm_resp command. But if the SMSC interacts with NowSMS by data_sm/data_sm_resp commands, the data_sm_resp packet from NowSMS does not contain the message_id either. This should be fixed. We have seen carrier implementations where the message_id field is included in the deliver_sm_resp PDU, which allows the operator and the hub to do without switching to data_sm/data_sm_resp. This is however outside of the SMPP specification and should be activated by a special configuration parameter only. 2. In order to send a proper message_id to the SME, the message_id should be known at the time of sending of the deliver_sm_resp or the data_sm_resp. Since this would commonly occur when using the RerouteReceived=routexxx feature, we are not sure if the current logic of message processing in NowSMS supports it, and if it doesn’t the logic should be changed accordingly. 3. Current implementation of the receipt transmission by a simple “reversing” of the receipt from deliver_sm to submit_sm in NowSMS is not done according to the SMPP spec: Firstly, the esm_class field when sending the receipt from the SME to the ESME should have a value of 0x04. A lot of the operators’ SMSC-s are refusing to accept such PDU and are returning an “Invalid esm_class” error. When sending the receipt in the other direction (ESME->SME) this field should have a value of 0x08, which is clearly stated in the SMPP v.3.4. specification. Secondly, we have been observing that most operator SMSC-s are strict in that they don’t want the “extra” optional fields in the PDU. The problem in particular is with the optional receipt_message_id field in the submit_sm PDU. There should be a configuration parameter allowing to disable it. There is a number or other issues to address in this regard, plus the part that'd deal with Transaction Mode (message submit/ack/failover) implementation witn a common type of Logica/Cisco FDA (First Delivery Attempt) gateway. Can you please comment on whether you would be willing to undertake such extra development. If you think you would we would prepare a detailed spec in a form of recommendation with highlights on missing features, proposed configuration options, noticed inconsistencies etc. Kind regards, Ashot | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 1592 Registered: 08-2008 |
Hi Ashot, Let me see if I can sort through this. 1.) Are we strictly talking about a scenario where deliver_sm (or actually data_sm received from an outbind connection in place of deliver_sm) gets rerouted with the "ReRouteReceived" scenario? In this scenario, it would be technically feasible for us to include a message_id in the data_sm_resp. Other scenarios would not be so clean. I'm thinking of a scenario where 2 user accounts are connected to NowSMS (inbind), and NowSMS is effectively hubbing between them. There would need to be a configuration parameter that tells us to use data_sm instead of deliver_sm for the user account, and we would need to add receipt id tracking for these messages. This may be possible, but is considerably more complex than the first scenario. 2.) For the "ReRouteReceived" scenario, I think the message processing logic could support this, the sm_resp is not generated until after a message id has been assigned. 3.) I agree that this is wrong. Changing 4 to 8 is something that we should do immediately. Until the "ReRouteReceived" there was not a scenario where a receipt would be in this queue, and we are clearly using the wrong encoding when this happens. Leaving out the extra TLV parameters could probably be accomplished by a simple configuration setting. 4.) Transaction mode and first delivery attempt gateway is a very interesting idea that requires considerably more thought. I can see the logic, but it would take more thought on our end for how to implement. --- Here's what I could see happening in short order: A1.) Stop using esm_class = 4 for receipts in submit_sm, as it should be 8. A2.) Add per-SMSC configuration option to suppress TLV in receipts transmitted via submit_sm. A3.) Add message_id to data_sm_resp when message received from outbind SMSC connection and message rerouted to another outbind SMSC connection because of "ReRouteReceived" setting. Medium term: B1.) "SMS Users" account attribute to use data_sm instead of deliver_sm for receipts (configurable esm_class of 4 or 8). B2.) "SMS Users" account attribute to use data_sm instead of deliver_sm for all messages, and to enable receipt tracking for messages/receipts. Longer term: C1.) Support for first delivery attempt gateway. More details to be defined. -- Am I over-simplifying or missing anything? -- Des NowSMS Support | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 1593 Registered: 08-2008 |
B3.) Add per-SMSC configuration to use data_sm instead of submit_sm for delivery receipts. | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 1687 Registered: 08-2008 |
Hi Ashot, I thought I had followed up on this prior to the holidays. All of the "A" issues were addressed. We are currently working on the "B" issues, and are awaiting further thoughts from you regarding "C" issues. We do have a thought that we have been discussin internally, that it would be interesting for us to have a first delivery attempt routing implementation where we would try first to route a message in memory entirely without writing it out to disk. It would be difficult to implement in complex routing scenarios, but could offer a significant performance improvement, especially when used in conjunction with first delivery attempt gateways. The latest update that includes the "A" changes is http://www.nowsms.com/download/nowsms20100119.zip. -- Des NowSMS Support | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 1688 Registered: 08-2008 |
Follow-up. I notice that A1 and A3 changes are referenced in the update text file, but A2 is not. There is an SMSC specific configuration option to address A3 which is not referenced in the text. Under the [SMPP - server:port] header of SMSGW.INI, if you want to suppress the receipt TLV parameters for messages routed to this server, add IgnoreReceiptTLV=Yes. -- Des NowSMS Support | |||
| jahangeer ali New member Username: Jahangeer Post Number: 1 Registered: 03-2010 |
sallam dear ] | |||
