Hi Juan Thanks. I am using MySQL storage. After reading the UG again I see that this is what I should be doing. No matter how many times I read the thing I always find something new.
Regards, On Wed, Aug 25, 2010 at 11:23 PM, Juan Nin <[email protected]> wrote: > Also, both binds will need to use the same smsc-id, since the SQL > queries that search for the DLR info use the smsc-id on its WHERE > conditions. > > Use smsc-admin-id to control each bind individually (start/stop/etc), > but specify the same smsc-id on both > > > > On Wed, Aug 25, 2010 at 6:18 PM, Juan Nin <[email protected]> wrote: > > You need to use an external DLR storage (DB). > > > > If you use internal DLR storage, which is in memory, each Kannel > > server will store the info from the DLRs originated via that server, > > so if the SMSC send the DLR via the other server, it won't find it. > > > > See the external DB DLR storage options here: > > > http://www.kannel.org/download/kannel-userguide-snapshot/userguide.html#AEN3170 > > > > > > On Wed, Aug 25, 2010 at 5:09 PM, brett skinner > > <[email protected]> wrote: > >> Hi > >> > >> In an effort to increase through put our SMSC suggested that we created > >> another bind to them with the exact same details. I.e. username, > password, > >> IP address and port. In our configuration file I have created a second > bind > >> with a different ID but have set both SMPP connections to use the same > >> allowed-smsc-id. The SMSC did mention that they would load balance the > DLRs > >> across the binds and feed to which ever bind had the least traffic. > >> > >> Looking through the bearerbox logs I don't not see any rejected DLRs. > But we > >> are missing an unusally large number of DLRs. > >> > >> Were we incorrect in our assumption that Kannel would be able to match > the > >> DLRs even if the original sms went out on one bind and came back in on > >> another bind? > >> > >> Regards, > >> > >> > >> > > > >
