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 > <[email protected]>: > > 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 > <[email protected] <mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]>> > Sent: mercredi 26 juin 2019 00:27 > To: Lamasuta, Franck, Vodafone Automotive <[email protected] > <mailto:[email protected]>> > Cc: [email protected] <mailto:[email protected]> > 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 > <[email protected] <mailto:[email protected]>> 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… J > > > > 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 >
