Ah, you didn't mention you were using EMI I think? I was talking about SMPP
(which is the "default" for many of us because its ubiquity).
I'd need to check on the EMI code to be able to tell you anything worth it
(I've never used it), but you may consider taking a shot at CVS instead of
1.4.1. It's just as stable (or better) than 1.4.1 and a lot of bugs were
fixed since 1.4.1 was out.
Regards,
Alejandro
On Fri, Dec 5, 2008 at 10:12 PM, Richard Spencer <[EMAIL PROTECTED]>wrote:
> 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
>>>
>>>
>>>
>>
>
