We had that very same problem. It happened to us with some aggregators: on
some cases, they've sent the DLR _before_ the submit_sm_resp arrived, so
when the DLR hits kannel the record is not yet created on the DB and it's
ignored.

When the submit_sm_resp finally arrives and the DLR record is created (only
a few milliseconds later usually) it remains there forever.

I've made a simple patch time ago to deal with this problem (posted it to
the list as well).

Check here:

http://www.blogalex.com/archives/132

I've been using it since then with no issues at all.

Regards,

Alejandro

2009/10/24 Nikos Balkanas <[email protected]>

> Hi,
>
> This is rather a question for Mysql administration. If inserts (same server
> or LAN) delay more than WAN tcp/ip + delivery from your SMSc, then you have
> some serious MySQL issues.
>
> However, you are only guessing about the cause. It could be something
> entirely different, i.e. Mysql downtime when inserting, dropped connections,
> etc. To verify your hypothesis, do a query after a few minutes and if the
> insert is slow, mismatched DLRs should still be in the database (status 0).
> If you also add a column with a timestamp, you could compare timestamp with
> DLR delivery from logs.
>
> I have just submitted a patch that increases database warning logging,
> which might be helpful.
>
> To benchmark your mysql installation, run the same 20K SMS over fakesmsc.
> It is expeted to loose a few there, since DLRs are instantaneous, but it
> should give you an idea of your handling capacity.
>
> BR,
> Nikos
> ----- Original Message ----- From: "Alvaro Cornejo" <
> [email protected]>
> To: "Nicolas Dagnet" <[email protected]>
> Cc: <[email protected]>
> Sent: Saturday, October 24, 2009 5:11 PM
> Subject: Re: Strange behaviour handling DLR
>
>
>
> It is/(was?) a known issue. Some time ago there were a thread about it
> but could΄nt remember the final.
>
> Search the mailing list.
>
> It might be a issue with an overloaded mysql also.
>
> In any case, post your configs/version/logs
>
> Regards
>
> Alvaro
>
> On Sat, Oct 24, 2009 at 9:00 AM, Nicolas Dagnet <[email protected]> wrote:
>
>> Hello,
>>
>> I have a very strange behavior when dealing with sending a 20k SMS
>> campaign
>> (for example).
>> Sometimes, DLR are stuck in MySQL, even if these DLR are really sent by my
>> operator (Mblox).
>>
>> In fact, it seems that the DLR are incoming before kannel has enough time
>> to
>> insert the DLR in MySQL (see log below).
>>
>> I tried with dlr-storage = internal, but the situation is equal.
>> Number of SMS concerned : about 0.3 to 0.6% in the few tests I made.
>>
>> Does anyone had to deal with such a problem ?
>>
>> Thanks
>>
>> Log :
>> Here is a dump for a DLR stuck in DB :
>>
>> 2009-10-23 13:29:04 [2399] [7] DEBUG: data: 69 64 3a 32 32 34 30 34 32
>> 33 36 36 35 20 73 75 id:2240423665 su
>> 2009-10-23 13:29:04 [2399] [7] DEBUG: DLR[mysql]: Looking for DLR
>> smsc=smppft, ts=2240423665, dst=33679261445, type=4
>> 2009-10-23 13:29:04 [2399] [7] ERROR: SMPP[smppft]: got DLR but could not
>> find message or was not interested in it id<2240423665> dst<33679261445>,
>> type<4>
>> 2009-10-23 13:29:05 [2399] [7] DEBUG: data: 69 64 3a 32 32 34 30 34 32
>> 33 36 36 35 20 73 75 id:2240423665 su
>> 2009-10-23 13:29:05 [2399] [7] DEBUG: DLR[mysql]: Looking for DLR
>> smsc=smppft, ts=2240423665, dst=33679261445, type=1
>> 2009-10-23 13:29:05 [2399] [7] ERROR: SMPP[smppft]: got DLR but could not
>> find message or was not interested in it id<2240423665> dst<33679261445>,
>> type<1>
>> 2009-10-23 13:29:06 [2399] [8] DEBUG: DLR[mysql]: Adding DLR smsc=smppft,
>> ts=2240423665, src=13579, dst=33679261445, mask=31, boxc=
>>
>>
>>
>>
>>
>>
>>
>
>
> --
>
> |-----------------------------------------------------------------------------------------------------------------|
> Envνe y Reciba Datos y mensajes de Texto (SMS) hacia y desde cualquier
> celular y Nextel
> en el Perϊ, Mιxico y en mas de 180 paises. Use aplicaciones 2 vias via
>
> SMS y GPRS online
>             Visitenos en www.perusms.NET www.smsglobal.com.mx y
> www.pravcom.com
>
>

Reply via email to