Its a "bug" then, i think it should be old sql issue in the source related to 
initiating the dlr db connection
it should be executed once right after the startup

an idea for debugging :
wait for the unsent messages to appear, stop the kannel
dump the table , drop/recreate it, the start the kannel
send single sms, then inject the dump
the results should point there to search .. ?

have to say i have similar issues with sqlbox and some chinese/dont know the 
brand smpp smsc
time to time messages are stuck in the dlr table, and i need to restart kannel,
i see routing error in the kannel logs when this issue appears.
so its related to non usual for kannel responce from the smsc by my opinion.

my work arround : i stop the kannel daemon, run a script to regenerate the 
messages from the db
i truncate the table and then i start the kannel and execute the resulting 
script created before hand ...

fgrep kannel logs for errors ..

wish you luck with this

Alvaro Cornejo wrote:
> No, I'm using mysql for dlr storage since otherwise dlr are lost on
> kannel restart
> 
> |-----------------------------------------------------------------------------------------------------------------|
> 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
> 
> 
> 
> On Tue, Mar 10, 2009 at 8:15 PM, seikath <[email protected]> wrote:
>> Hi,
>>
>> I am not aware of the store_tools.
>> Anyway, I assume you use default kannel store file
>> instead of db dlr storage, correct ?
>>
>>
>>
>> Alvaro Cornejo wrote:
>>> Hi List
>>>
>>>
>>> I've found the following 2 isues:
>>>
>>> 1) I have several modems for the same operators 10 for op1 and 5 for
>>> op2. For some reason, some messages get stuck into kannel queue and
>>> are not sent to smsc without restarting kannel. I've used Alex
>>> store_tools and verify messages are in queue. All messages are sent
>>> using the same code and use AT-SMSCs.
>>>
>>> 2) When I restart kannel QUEUED messages are sent  through only one
>>> at-smsc even if messages have a destination smsc-id specified in
>>> sendsms url call
>>>
>>> This is an snippet of the config I have:
>>>
>>> smsc-id = id1
>>> allowed-smsc = id1,id_op1
>>>
>>> smsc-id = id2
>>> allowed-smsc = id2,id_op1
>>>
>>> smsc-id = id3
>>> allowed-smsc = id3,id_op1
>>>
>>> smsc-id = id4
>>> allowed-smsc = id4,id_op2
>>>
>>> smsc-id = id5
>>> allowed-smsc = id5,id_op2
>>>
>>> etc...
>>>
>>> Note there is no smsc defined with smsc-id=id_op1 nor id_op2 in config file.
>>>
>>> When sending the messages I use &smsc-id=id_op1 or id_op2 into url so
>>> kannel load-balance through the smsc of corresponding operator and
>>> send the message. This works fine until I restart kannel.
>>>
>>> After kannel reset, All QUEUED messages are sent through ONLY ONE  of
>>> the smsc without load-balancing between smsc even though there are
>>> hundreds of queued messages; however if, at the same time, I send
>>> messages to any of the id_op1 or id_op2, this new messages are
>>> correctly load-balanced between smsc-at
>>>
>>> I use:
>>>
>>> Kannel bearerbox version `1.4.3'. Build `Feb 13 2009 17:32:59',
>>> compiler `4.1.2 20070626 (Red Hat 4.1.2-13)'. System Linux, release
>>> 2.6.20-1.2962.fc6, version #1 SMP Tue Jun 19 19:27:14 EDT 2007,
>>> machine i686.  IP 10.10.5.2. Libxml version 2.6.29. Using OpenSSL
>>> 0.9.8b 04 May 2006. Compiled with MySQL 5.0.27, using MySQL 5.0.27.
>>> Using native malloc.
>>>
>>>
>>> Any ideas?
>>>
>>>
>>> Regards
>>>
>>> Alvaro
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> |-----------------------------------------------------------------------------------------------------------------|
>>> 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