| RerouteReceived and Delivery Receipts |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - SMS Issues ⬆ Archive through September 26, 2009 ⬆ |
◄ ► |
| Author | Message | |||
| ashot shahbazian New member Username: Animatele Post Number: 29 Registered: 06-2004 |
In a common SMS Hubbing scenario, the hub is connecting to an MNO to retrieve their subscriber messages via a reverse SMPP bind. In other words, the messages are submitted by the operator’s SMSC as deliver_sm in the RX or TRX bind initiated by the hub. Once the operator’s message is fetched, it needs to be “flipped” and forwarded to an appropriate SMSC connection as a submit_sm (or a data_sm) packet. NowSMS does this graciously by means of a RerouteReceived setting. However, there is one obstacle: the hub would always request a Delivery Receipt, and most SMSC-s would return it. The following is an example of such “back-to-back” configuration with comments: 1st connection ####### reverse uplink to operator sending messages to hub [SMPP – operator_1:1111] RouteName=oper1 ####### to flip the received messages to the 3d uplink ReRouteReceived= hubmt1 SMPPVersion=v3.4 UserName=oper1 Password=1111 RoutePrefOnly=yes ####### prefix or prefixes of the operator, unique across the server Route1=+oper1prefix* AllowedUserOnly=Yes #######for traffic destined to the operator from normal “user binds”, as opposed to in-reverse AllowedUser1=mt_operA ReceiveSingleConnection=Yes SenderAddressOverride=Yes Receive=No WindowSize=20 2nd reverse connection to operator 2, similar to 1st connection [SMPP – operator_2:2222] RouteName=oper2 ReRouteReceived=hubmt1 SMPPVersion=v3.4 UserName=oper2 Password=2222 RoutePrefOnly=yes Route1=+oper2prefix* AllowedUserOnly=Yes AllowedUser1=mt_oper2 ReceiveSingleConnection=Yes SenderAddressOverride=Yes Receive=No WindowSize=20 3rd connection ###### uplink for the operator 1 to a server which has SMSC uplinks for “straight” message forwarding [SMPP – hubforward1_mt:3333] RouteName=hubmt1 ###### to flip and forward the reply messages and DLR to operator 1 ReRouteReceived=oper1 SMPPVersion=v3.4 UserName=hubmt1 Password=3333 AllowedUserOnly=Yes ReceiveSingleConnection=Yes SenderAddressOverride=Yes Receive=No WindowSize=20 The main problem is that as configured, the system cannot properly handle Delivery Receipts. When the message fetched from the operator 1 terminates through the server upstream the server sends a DLR (or a text reply is received from the recipient,) which flips and forwards to the operator 1 uplink. Most operator SMSC-s would in turn send a DLR on the submitted DLR, which flips on the operator 1 uplink and forwards to the hub uplink, thus creating an endless loop of Delivery Receipts. To make matters worse, if the forward receiving operator is not a directly connected one but through an MT transit facility these “DLR on DLR” can be charged as MT messages. We use DisableDeliveryReceipt=Yes to avoid it, thus degrading the service quality. A logically simple fix would be to implement a DisableReceiptRerouting=Yes setting, applicable in our example to the operator 1 definition. It deletes the DLR, but selectively - only those destined to the uplink which is used to send the fetched messages upstream (and it should not write relevant files in any queue folders, as that slows down the server.) But if the message triggering the DLR came from an mt_operA “user account”, the corresponding DLR should route to that client normally. In other words, you first check if a message ID in the DLR is present in the DLR matching table and only delete it if it’s not. Currently, NowSMS does not like forwarding the flipped DLR to an uplink, especially if that uplink is another NowSMS server. The .req file often gets stuck in the \q folder showing “smsc timeout” errors and severely degrading the sending speed on that uplink for normal messages. We couldn’t figure what’s causing some DLR submit upstream and others not, perhaps this was indeed a precautionary feature to prevent charging for DLR. With the DisableReceiptRerouting feature though it’d become quite safe to let the DLR go upstream. In our example, we would use the setting on the operator 1 uplink, but would not on the hubmt1, so that the operator 1 can receive the DLR for terminated messages. If this sounds like a reasonable feature, would you be able to implement it? Things can be more complicated though: If we wanted messages and DLR to travel between two or more directly “in-reverse” connected operators (i.e. "operator 2" connection) within the same server (assuming that there’s a RerouteReceived=* possibility and the fetched messages flip and then route across different uplinks by means of source and/or dest address routing rules) it’d be more of a brainteaser. You would need to tell a real DLR from a “DLR on DLR” and discard the bad ones to prevent them looping. Tricky but possible if you retain the message class after flipping the DLR. Then you track both the message ID and the message class of every submitted message, delete those DLR which returned for DLR but skip those for normal messages. Kind regards, Ashot | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 1033 Registered: 08-2008 |
Hi Ashot, Yes, that is tricky. I've read it several times, and each time I seem to understand a little better ... but it is slow to sink in. Let me make sure I understand what you're proposing. You're suggesting that in conjunction with the "ReRouteReceived" setting, you'd like to see a "DisableReceiptRerouting=Yes" setting. This additional setting would silently discard any receipts that are received, yet apply the re-routing to all other messages. Correct? What I'm not clear on is what causes the DLR on DLR scenario. esm_class has a bit setting to indicate that a message is a receipt. A DLR should only be issued if the registered_delivery flag is set. I can only figure that you have some operators that are returning a DLR for every message? If possible, it might be interesting to see the message flow of such a message, and what flags are set in the messages at each stage. Blocking all of the receipts from the re-routing sounds relatively easy. I know in the 2009 release we added a hook to all an accounting callback to block/discard a message being processed by "ReRouteReceived". A setting that discarded re-routing of any receipts would likely just follow that same path. The other I'm still trying to understand ... -- Des NowSMS Support | |||
| ashot shahbazian New member Username: Animatele Post Number: 31 Registered: 06-2004 |
Hi Des, You're suggesting that in conjunction with the "ReRouteReceived" setting, you'd like to see a "DisableReceiptRerouting=Yes" setting. This additional setting would silently discard any receipts that are received, yet apply the re-routing to all other messages. Correct? Yes, EXCEPT for the DLR for the messages which submitted normally, i.e. from a "user account" (as opposed to a message from another uplink with RerouteReceived.) In a normal (not reversed) message flow scenario, NowSMS checks for the submitted message ID and when a DLR is received for it it checks the Message ID in the DLR and if a match is found in the table (database) it would route the DLR to an appropriate user account. That part SHOULD NOT be affected by the DisableReceiptRerouting=Yes setting. What I'm not clear on is what causes the DLR on DLR scenario. esm_class has a bit setting to indicate that a message is a receipt. A DLR should only be issued if the registered_delivery flag is set. I can only figure that you have some operators that are returning a DLR for every message? That's us who request DLR for every message - we have to because we need to bill the operators per delivered messages, by GSMA guidelines. A DLR is also requested by default by any other SMS Hub, some of which we have peering with via SMPP. As for the last paragraph, I'm actually talking about 2 distinct features: 1. Currently, we must specify a routename in a RerouteReceived setting, which means that you are forcing the flipped message to route via a specified uplink only (I assume that your are adding SMSCRoute=xxxx in the .req file, which makes for the highest routing priority.) Imagine now that we have 100 operators connected in this fashion, each with ReouteReceived, on the same server. Each operator has its own defined subscriber number ranges specified by RouteN=+abcdef* - s. Message arriving from an operator 1 could be destined to any one of the 99 other operators. However, as the RerouteReceived works now, the message from the operator 1 can only be sent over one uplink and regardless what routes are specified on that uplink, which would be wrong. If you modified the setting so that you could indicate "Any" or "*" which would just place the flipped message in that server's outbound queue, the message would route through an appropriate uplink which has the closest MSISDN match for the destination (or source) number in that message. Hence, instead of a static routing to a single uplink specified in the RerouteReceived command, the routing becomes dynamic. 2. The second issue, if the 1st one is implemented, is that we must request DLR for all messages. On NowSMS servers we do it by means of DefaultDelReceipt=Yes setting. Not sure if that is the reason, but when when a flipped DLR is submitted upstream (in-reverse) the operators' SMSC-s would return a DLR on a submitted DLR causing them looping back-and-forth, unless we use a DisableDeliveryReceipts on that operator's uplink. The solutions would be to suppress the registered delivery flag in the DLR if it is indeed set in these circumstances (which I cannot confirm now, but I remember seeing it in the past,) and given that it's a potential double-charging danger, to also track (e.g. by ESM class) if the message submitted upstream was a DLR but not a normal message and discard a DLR that may return for it. I hope I could make it clear. Before you attempt to make any changes let's make sure that we're on the same page. Kind regards, Asht | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 1040 Registered: 08-2008 |
Hi Ashot, I think I understand a lot better now. Let me clarify my thoughts on the first issue, as I think it is very simple. The "DisableReceiptRerouting=Yes" setting could only be paired with a "ReRouteReceived=" setting. It would mean that "ReRouteReceived=" would never be applied to a delivery receipt received from this connection. I see your point though. If a local user account submitted the message, it should still receive the receipt. That should be ok. I know the accounting callback that allows the reroute to be blocked/discarded does not get called if the receipt was determined to be destined for a local user account. That said, I think I've got a better understanding of the second issue, and by addressing that, we may eliminate the need to do anything about the first issue. The culprit is that DefaultDelReceipt=Yes setting. We should make sure that this never gets applied for a delivery receipt. I cannot think of any valid reason to ever request a delivery receipt for a delivery receipt, can you? -- Des NowSMS Support | |||
