Hello Alejandro,
I haven't found any entries in my log files with the parameter you
mentioned.
Also, I have no kannel.log file. Does it correspond to any of the following?
log-file = "/home/smsgtw/logs/smsgatewaydev.log"
log-level = 0
store-file = "/home/smsgtw/logs/smsgatewaydev.store"
access-log = "/home/smsgtw/logs/smsgatewayaccessdev.log"
log-file = "/home/smsgtw/logs/smsboxdev.log"
access-log = "/home/smsgtw/logs/smsboxaccessdev.log"
The dlr-mask my applications are sending is 18 (16 + 2). According to
kannel's source code file /gateway-1.4.1/gw/smsc/smsc_emi.c (lines 549-556),
if I'm asking for a delivery report (regardless of the mask being 1 or 2),
kannel will always use the mask 3.
/* 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 */
if (DLR_IS_ENABLED_DEVICE(msg->sms.dlr_mask)) {
emimsg->fields[E50_NRQ] = octstr_create("1");
emimsg->fields[E50_NT] = octstr_create("");
octstr_append_decimal(emimsg->fields[E50_NT], 3 +
(DLR_IS_BUFFERED(msg->sms.dlr_mask) ? 4 : 0));
Therefore, I think the only way to have the "right" behaviour is to change
this last line. Am I missing something?
Best regards,
Richard
On Wed, Dec 3, 2008 at 1:38 PM, Alejandro Guerrieri <
[EMAIL PROTECTED]> wrote:
> 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
>>
>>
>>
>
