Richard, Kannel sets the registered_delivery parameter looking into your dlr-mask, and then filters the dlr received according to it.
I'd look into: 1. What's the dlr-mask you're using. Try with "2". 2. Set the log level to 0 and look at kannel.log for some MT PDU's. You should see the registered_delivery value there. It should be "2" as well. Hope it helps, Alejandro On Wed, Dec 3, 2008 at 8:08 AM, Richard Spencer <[EMAIL PROTECTED]>wrote: > Dear community, > > We have many web applications using Kannel to send and receive SMS. We are > using MySQL as a Delivery Report (DLR) external storage. > > Some of our applications use mass SMS sending (sometimes more than 30 > thousand SMS are sent at one time). > > Our SMS operator has alerted us to the fact that there is too much traffic > being processed in our connections, both outbound and inbound. > The outbound part is obviously our applications, but the inbound part is > what caught us by surprise. > Although our applications are requesting only DLR's in case of delivery > failure (notification type = 2), Kannel is requesting also DLR's for > delivery success (notification type = 3 (2 + 1)). This is documented in the > source code as: > /* if delivery reports are asked, lets ask for them too */ > /* even the sender might not be interested in delivery or non delivery > */ > /* we still need them back to clear out the memory after the message */ > /* has been delivered or non delivery has been confirmed */ > > We think that this behavior is only required when using internal DLR > storage. > We are thinking of changing Kannel's source code to use the same > notification type what our applications are requesting. This will result in > DLR's records of delivered SMS being kept in the database forever. We then > can use an SQL script to delete these records. > This way we are reducing inbound traffic in about 80 to 90%, that will > result in an huge increase on delivery speed. > Has anyone had this problem before? Is there already a solution to this > issue? > Is this solution the right approach to solve this issue? > > Thank you for your help. > > Best regards, > Richard Spencer > > >
