Hi, I think it is not flexible enough to rely on smsc-id to manage the pending DLRs. We use already the status endpoint provided by Kannel to monitor the binds and trigger alerts. But we want to know which path (bind) a MO-SMS took and store this in our database. Then we can use this info to draw charts with the throughput of each bind on different time periods and to detect issues.
Another solution to keep this flexibility would be to add an optional config parameter (something like pending-dlr-id). If it is not defined then smsc-id would be used as a fallback (to be compatible with current behavior). What do you think? Regards, Franck From: Alexander Malysh <malys...@gmail.com> On Behalf Of Alexander Malysh Sent: vendredi 28 juin 2019 09:43 To: Alejandro Guerrieri <alejandro.guerri...@gmail.com> Cc: Lamasuta, Franck, Vodafone Automotive <franck.lamas...@vodafone.com>; devel@kannel.org Subject: Re: [PATCH] SMSC cluster Hi, I’m agree with Alejandro. For SMPP we don’t need such patch but for the CIMD2 we have to fix it to conn->id if it’s not used there. Thanks, Alex Am 26.06.2019 um 15:13 schrieb Alejandro Guerrieri <alejandro.guerri...@gmail.com<mailto:alejandro.guerri...@gmail.com>>: Franck, Thank you for clarifying. Regarding SMPP, you are using your application to indirectly diagnose problem with your binds. Kannel has a status endpoint that you can use to monitor the bind status directly instead of "bubbling-up" the problem to your application layer. You have a point on CIMD2, though iMHO that is a "bug" in Kannel: all connectors should use the same naming strategy. I don't know how likely is the scenario of having multi-protocol binds sharing SMS traffic, but in Kannel's current state it is the only case where this patch would make a difference. In my opinion, the right answer is to make the naming convention consistent so DLR's can be resolved across different protocols. Regards, Alejandro On Wed, Jun 26, 2019 at 4:11 AM Lamasuta, Franck, Vodafone Automotive <franck.lamas...@vodafone.com<mailto:franck.lamas...@vodafone.com>> wrote: Hi Alejandro, I know we could use identical smsc-ids but… 1) It does not work for CIMD2 because dlr_add() and dlr_find() are called with conn->name which is built with the IP and port. 2) It could work with SMPP (because dlr_add() and dlr_find() are called with conn->id) but… When a MO-SMS is received, the smsc-id is assigned to the message and forwarded to our back-end by smsbox. We use this id to monitor the incoming traffic on each bind and detect issues (e.g. when the MO-SMS rate is below a threshold). With identical smsc-ids, we could have an issue on one of the binds (with the bind still up) and not be able to detect it. Therefore we do prefer to have different smsc-ids. The patch only uses smsc-username which is (AFAIK) always the same with multiple binds. It is more flexible in my opinion. Regards, Franck From: Alejandro Guerrieri <alejandro.guerri...@gmail.com<mailto:alejandro.guerri...@gmail.com>> Sent: mercredi 26 juin 2019 00:27 To: Lamasuta, Franck, Vodafone Automotive <franck.lamas...@vodafone.com<mailto:franck.lamas...@vodafone.com>> Cc: devel@kannel.org<mailto:devel@kannel.org> Subject: Re: [PATCH] SMSC cluster I'm curious why do you even need this patch? You could use the same smsc-id on both and assign different smsc-admin-id values to manage each bind separately (e.g. start/stop). If by any reason you'd want to send over a specific bind, you could use different allowed-smsc-id's as well. Regards, Alejandro On Tue, Jun 25, 2019 at 12:20 PM Lamasuta, Franck, Vodafone Automotive <franck.lamas...@vodafone.com<mailto:franck.lamas...@vodafone.com>> wrote: Hi list, We have implemented many patches along the way and I can finally take some time to submit them. They are running on our staging and production platforms since years for the oldest ones. I will submit them one by one in the next days/weeks. Let’s start with the first one… ☺ This patch allows Kannel to retrieve a pending DLRs in its database when 2 (or more) SMSC binds are established (with different IPs and/or ports). It is required when a MT-SMS is submitted to SMSC A and its DLR is sent back by SMSC B. Done for CIMD2 and SMPP. Example of configuration where the patch is required: # # Primary server # group = smsc smsc = cimd2 smsc-id = SMSC-A host = 123.1.2.3 port = 6001 smsc-username = user smsc-password = xxxxxxxx allowed-smsc-id = id1 preferred-smsc-id = id1 # # Secondary server # group = smsc smsc = cimd2 smsc-id = SMSC-B host = 123.1.2.3 port = 6002 smsc-username = user smsc-password = xxxxxxxx allowed-smsc-id = id1 Regards, Franck
