Re: SMSC Rejected DLR shouldn't be saved in the DLR storage

Mohammed Saleem <[email protected]>
Newsgroups gmane.comp.mobile.kannel.devel
Message-ID <[email protected]>
I user dlr-mask = 31 ( kannel stable release 64-bits 1.4.3)

Hello people, thanks so much for your great answers, but my problem is not
with understanding the DLR mechanism in Kannel, I already know that, but my
question is: Why kannel stores DLRs in the DLR table for the SMS-Rejected
MTs (status = 16)? When the SMSC rejects an MT then it will forget about it
and it won't send any DLR for for that MT in the future, so Kannel shouldn't
insert a record into the DLR table? right?


Thanks



Best Regards,
Mohammed M I Sleem
http://www.abusleem.net

http://www.freakle.com - The Search Freak

http://www.colorle.com - color your Google search



On Thu, Nov 18, 2010 at 7:15 PM, Alexander Malysh <[email protected]>wrote:

> Hi,
>
> kannel doesn't insert DLRs into DB when message rejected on submit_sm.
> Debug statement creating DLR message coming from here:
>
> Msg* create_dlr_from_msg(const Octstr *smsc, const Msg *msg, const Octstr
> *reply, long stat)
> {
>     Msg *dlrmsg;
>
>     if (msg == NULL)
>         return NULL;
>
>     /* generate DLR */
>     debug("dlr.dlr", 0,"SMSC[%s]: creating DLR message",
>                 (smsc ? octstr_get_cstr(smsc) : "UNKNOWN"));
> ...
>
> This function called from bb_smscconn_failed to create DLR for you because
> you requested DLRs for failed messages.
> But message doesn't go into DB.
>
> Thanks,
> Alexander Malysh
>
> P.S. Seems you missing DLRs therefore you see some messages in DB.
>
> Am 18.11.2010 um 16:29 schrieb Mohammed Saleem:
>
> Hi Alejandro, thanks for your reply,
>
>
> It gets rejected at delivery time, please check the atached log, I copid
> the message and the error log
>
>
> Notice that the messages got rejected first
>
> 2010-11-18 05:14:04 [16269] [10] ERROR: SMPP[SDZAIN00]: SMSC returned error
> code 0x00000045 (Submit failed) in response to submit_sm.
>
>
> After that kannel inserted the DLR in the DB where it shouldn't do this for
> SMSC-Rejected (status=16) MTs
>
>
> 2010-11-18 05:14:04 [16269] [10] DEBUG: SMSC[SDZAIN00]: creating DLR
> message
> 2010-11-18 05:14:04 [16269] [10] DEBUG: SMSC[SDZAIN00]: DLR =
> http://localhost:13016/d?d=%d&F=%F&t=%t&i=%i&A=%A&B=%B&q=%q&Q=%Q&L=3945138&b=&s=27&ST=1290057244566
> 2010-11-18 05:14:05 [16269] [10] DEBUG: SMPP[SDZAIN00]: Got PDU:
>
>
>
>
> Does this make sense? or is there something I don't understand or not
> mentioned in the UG?
>
>
> Thanks
>
> Best Regards,
> Mohammed M I Sleem
> http://www.abusleem.net
>
> http://www.freakle.com - The Search Freak
>
> http://www.colorle.com - color your Google search
>
>
>
> On Thu, Nov 18, 2010 at 5:07 PM, Alejandro Guerrieri <
> [email protected]> wrote:
>
>> Mohammed,
>>
>> It's rejected at delivery time (submit_sm_resp) or afterwards
>> (deliver_sm)?
>>
>> It's definitely an issue with your dlr-mask setting. Please post log
>> entries showing the rejects and the dlr-mask you're using.
>>
>> Regards,
>>  --
>> Alejandro Guerrieri
>> [email protected]
>>
>>
>>
>> On 18/11/2010, at 15:44, Mohammed Saleem wrote:
>>
>>
>> Hi Nikos
>>
>> There is nothing useful in the UG in this case, maybe I didn't explain
>> enough:
>>
>> When the bearerbox sends a message it inserts a record in the DLR
>> storages, lets say a MySQL table, this recor will be used as a reference
>> when a DLR is received later and then the bearerbox will call the url and
>> then remove that record
>>
>> This case applies on Delievered (status=1), Failed(stats=2) and buffered
>> (status=4) and it works fine with these DLR statuses, but when the MT gets
>> rejected by the SMSC at the submit time, why the bearerbox inserts a record
>> for that MT?!! since the SMSC will forget that mesage and there will be no
>> later DLR reply for that messages because it is already rejected, this
>> causes the DLR record to be saved forever in the MySQL table !!
>>
>>
>> I have solved this by creating a program that cleans each record that has
>> passed at least the validity-period (I set it to 24 hours) but this wont
>> solve my issue, since sometimes there are DLRs that takes this long and they
>> are already submitted (not rejected) which corrupts my stats and I can't
>> report lost DLRs to the carrier for investigation
>>
>>
>> I hope I explained the problem well enough
>>
>> Thanks
>>
>> Best Regards,
>> Mohammed M I Sleem
>> http://www.abusleem.net
>>
>> http://www.freakle.com - The Search Freak
>>
>> http://www.colorle.com - color your Google search
>>
>>
>>
>> 2010/11/18 Nikos Balkanas <[email protected]>
>>
>>> Hi,
>>>
>>> Read UG about dlr-mask.
>>>
>>> BR,
>>> Nikos
>>> ----- Original Message ----- From: Mohammed Saleem
>>> To: kannel_dev_mailinglist
>>> Sent: Thursday, November 18, 2010 3:24 PM
>>> Subject: Re: SMSC Rejected DLR shouldn't be saved in the DLR storage
>>>
>>>
>>>
>>>
>>>
>>> Hello Kanelers,
>>>
>>> Any idea?
>>>
>>> please advise on this, I couldn't find the place where to modify the
>>> source to disable this !!
>>>
>>>
>>> Any reply would be highly appreciated
>>>
>>> Thanks
>>>
>>>
>>>
>>> Best Regards,
>>> Mohammed M I Sleem
>>> http://www.abusleem.net
>>>
>>> http://www.freakle.com - The Search Freak
>>>
>>> http://www.colorle.com - color your Google search
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Nov 16, 2010 at 6:29 PM, Mohammed Saleem <
>>> [email protected]> wrote:
>>>
>>> When the SMS is rejected by the SMSC, why it gets saved into the DLR
>>> storage? (eg. dlr table)? since it is already rejected by the SMSC it
>>> shouldn't be saved in the DLR storage or it will kept in the storage forever
>>>
>>> is this a bug or is there a case that the SMSC may report DLR on rejected
>>> messages?
>>>
>>> Thanks
>>>
>>>
>>>
>>> Best Regards,
>>> Mohammed M I Sleem
>>> http://www.abusleem.net
>>>
>>> http://www.freakle.com - The Search Freak
>>>
>>> http://www.colorle.com - color your Google search
>>>
>>
>>
>>
> <smsc_connection.log>
>
>
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.