subject:"Re\: DLR"

2014-11-05 15:23 GMT+01:00 Christopher Burke christopher.bu...@simulity.com:
 Do I need to implement a web service to be linked with the dlr-url
 parameter, of should I simply enable an SQL based dlr-storage?

 I use a web service for this. The GET-URL is called, which allows me to 
 process the content of the message and store / forward etc as needed.

Isn't there a way to do the same by means of a SQL dlr-storage?
If I implemented thay web service it would be to update some SQL table ...

Re: DLR handling

2014-11-05 Thread Christopher Burke

Yeah, I believe that DLR storage can be achieved using the Kannel SQLBox 
project. I think GET-URL is possibly less complex. Depends if you’re only 
storing DLRs or acting on them I guess.
Christopher Burke
http://simulity.com
Office: +44 (0) 1248 679 281
Fax: +44 (0) 1248 660 323
Skype:krslynx



UK
Unit 8, Ash Court,
Parc Menai, Bangor,
Gwynedd, LL57 4DF,
Wales, UK

Malaysia
Level 30,
The Gardens North Tower,
Mid Valley City,
Lingkaran Syed Putra,
59200, Kuala Lumpur,
Malaysia

NOTICE: This message contains privileged  confidential information intended 
only for the use of the addressee named above. If you are not the intended 
recipient of this message, you are hereby notified that you must not 
disseminate, copy or take any action in reliance on it. If you have received 
this message in error, please notify Simulity Labs immediately. Any views 
expressed in this message are those of the individual sender except where the 
sender specifically states them to be the view of Simulity Labs


On 5 November 2014 at 14:58:20, Vincenzo Romano (vincenzo.rom...@notorand.it) 
wrote:

2014-11-05 15:23 GMT+01:00 Christopher Burke christopher.bu...@simulity.com:  
 Do I need to implement a web service to be linked with the dlr-url  
 parameter, of should I simply enable an SQL based dlr-storage?  
  
 I use a web service for this. The GET-URL is called, which allows me to 
 process the content of the message and store / forward etc as needed.  

Isn't there a way to do the same by means of a SQL dlr-storage?  
If I implemented thay web service it would be to update some SQL table ...

Re: DLR handling

2014-11-05 16:01 GMT+01:00 Christopher Burke christopher.bu...@simulity.com:
 Yeah, I believe that DLR storage can be achieved using the Kannel SQLBox
 project. I think GET-URL is possibly less complex. Depends if you’re only
 storing DLRs or acting on them I guess.

I don't want to write another program when all other bits seems to be
already there!
From the source code I can see a set of functions to update the DLR
storage, one for each different SQL backend.
But what I see in the reality is that the DLR storage gets only
INSERTs (upon submission) and DELETEs (upon delivery).
No UPDATE at all, even if I asked for a dlr-mask=31.
Isn't there a way to trigger those updates?

Re: DLR handling

2014-11-05 Thread Christopher Burke

I'm not too sure, I saw the sqlbox as a bit overkill / heavy for my needs.
I guess they're using insert instead of update as they're not updating a
record but adding a new record (I.e. Dlrs mean different things, so an
update is misleading).

If you want to just store dlr, sqlbox is probably fine, but I still think
it's a bit overkill. I have a nodejs script which is parsing my dlr at over
2.5k a second, and adding a db shouldn't be more than a few lines but will
probably bring it down lower although I expect it's easier to scale node
than it is to scale kannel
On 5 Nov 2014 15:11, Vincenzo Romano vincenzo.rom...@notorand.it wrote:

 2014-11-05 16:01 GMT+01:00 Christopher Burke 
 christopher.bu...@simulity.com:
  Yeah, I believe that DLR storage can be achieved using the Kannel SQLBox
  project. I think GET-URL is possibly less complex. Depends if you’re only
  storing DLRs or acting on them I guess.

 I don't want to write another program when all other bits seems to be
 already there!
 From the source code I can see a set of functions to update the DLR
 storage, one for each different SQL backend.
 But what I see in the reality is that the DLR storage gets only
 INSERTs (upon submission) and DELETEs (upon delivery).
 No UPDATE at all, even if I asked for a dlr-mask=31.
 Isn't there a way to trigger those updates?

Re: DLR handling

2014-11-05 Thread Alvaro Cornejo

Hi

Those sql commands are for kannel internal queue management only. That is
why there is no UPDATE.

You have 3 options:

- do your own dlr handler. It can be as simple as a php script that
receives the call and insert info in a database. You use dlr-url to call it.
- use sqlbox.
- hack kannel code to handle dlr as needed.

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.com

On Wed, Nov 5, 2014 at 10:10 AM, Vincenzo Romano 
vincenzo.rom...@notorand.it wrote:

 2014-11-05 16:01 GMT+01:00 Christopher Burke 
 christopher.bu...@simulity.com:
  Yeah, I believe that DLR storage can be achieved using the Kannel SQLBox
  project. I think GET-URL is possibly less complex. Depends if you're only
  storing DLRs or acting on them I guess.

 I don't want to write another program when all other bits seems to be
 already there!
 From the source code I can see a set of functions to update the DLR
 storage, one for each different SQL backend.
 But what I see in the reality is that the DLR storage gets only
 INSERTs (upon submission) and DELETEs (upon delivery).
 No UPDATE at all, even if I asked for a dlr-mask=31.
 Isn't there a way to trigger those updates?

Re: DLR handling

2014-11-05 17:54 GMT+01:00 Alvaro Cornejo cornejo.alv...@gmail.com:
 Hi

 Those sql commands are for kannel internal queue management only. That is
 why there is no UPDATE.

 You have 3 options:

 - do your own dlr handler. It can be as simple as a php script that receives
 the call and insert info in a database. You use dlr-url to call it.

For a number of non-technical reasons I cannot do this.

 - use sqlbox.

What's that?

 - hack kannel code to handle dlr as needed.

This is what I have done with a three line patch: replace the
sql_remove with an sql_update.
In my opinion, an SQL table like the one for DLRs should only get
INSERTs and SELECTs and never UPDATEs and DELETEs. Also for the sake
of scalability.

 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.com

 On Wed, Nov 5, 2014 at 10:10 AM, Vincenzo Romano
 vincenzo.rom...@notorand.it wrote:

 2014-11-05 16:01 GMT+01:00 Christopher Burke
 christopher.bu...@simulity.com:
  Yeah, I believe that DLR storage can be achieved using the Kannel SQLBox
  project. I think GET-URL is possibly less complex. Depends if you’re
  only
  storing DLRs or acting on them I guess.

 I don't want to write another program when all other bits seems to be
 already there!
 From the source code I can see a set of functions to update the DLR
 storage, one for each different SQL backend.
 But what I see in the reality is that the DLR storage gets only
 INSERTs (upon submission) and DELETEs (upon delivery).
 No UPDATE at all, even if I asked for a dlr-mask=31.
 Isn't there a way to trigger those updates?

Re: DLR handling

2014-11-05 Thread Alvaro Cornejo

  - use sqlbox.

 What's that?

Is an additional module that allows you to send/receive sms through a
database. Instead of calling smsbox for sending an sms, just do an insert
on a specific table and sqlbox will take care of everything.



  - hack kannel code to handle dlr as needed.

 This is what I have done with a three line patch: replace the
 sql_remove with an sql_update.
 In my opinion, an SQL table like the one for DLRs should only get
 INSERTs and SELECTs and never UPDATEs and DELETEs. Also for the sake
 of scalability.

Not sure what you have done is right. As far as I understand, the table you
define in kannel config handles kannel queue to smscs. If you disable
deletes, your message queue will grow infinitly? You might want to
duplicate inserts into a second table and updated that new table instead of
poking with kannels queue table.

Regards

Alvaro

Re: DLR handling

2014-11-05 17:49 GMT+01:00 Christopher Burke christopher.bu...@simulity.com:
 I'm not too sure, I saw the sqlbox as a bit overkill / heavy for my needs. I
 guess they're using insert instead of update as they're not updating a
 record but adding a new record (I.e. Dlrs mean different things, so an
 update is misleading).

 If you want to just store dlr, sqlbox is probably fine, but I still think
 it's a bit overkill. I have a nodejs script which is parsing my dlr at over
 2.5k a second, and adding a db shouldn't be more than a few lines but will
 probably bring it down lower although I expect it's easier to scale node
 than it is to scale kannel

 On 5 Nov 2014 15:11, Vincenzo Romano vincenzo.rom...@notorand.it wrote:

 2014-11-05 16:01 GMT+01:00 Christopher Burke
 christopher.bu...@simulity.com:
  Yeah, I believe that DLR storage can be achieved using the Kannel SQLBox
  project. I think GET-URL is possibly less complex. Depends if you’re
  only
  storing DLRs or acting on them I guess.

 I don't want to write another program when all other bits seems to be
 already there!
 From the source code I can see a set of functions to update the DLR
 storage, one for each different SQL backend.
 But what I see in the reality is that the DLR storage gets only
 INSERTs (upon submission) and DELETEs (upon delivery).
 No UPDATE at all, even if I asked for a dlr-mask=31.
 Isn't there a way to trigger those updates?

In my case, Kannel would act as just a ... SMS gateway.
All DLR processing on SMSs would happen through the database.
Kannel can scale-up quite easily as you can have multiple instances on
multiple network nodes.
My RDBMS is PostgreSQL which can also scale-up quite easily.
The actual SMS processing would happen through the database.

Re: dlr-url routing failure

Hi Alejandro

Change %26type%3D%25ddlr-mask=31 with %26type%3D25%26dlr-mask%3D31

Note that what you request as dlr is not necessarily what you will receive.
Carriers define which dlr status will they forward. Some disable
intermediate status, some allow all of them.

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.com


On Thu, Aug 21, 2014 at 11:22 AM, Alejandro Mussi alemu...@gmail.com
wrote:

 Hi guys,

 My kannel is not sending my dlr-url when type=1. I get it when type=16 and
 type=8.

 Here is what log saids:

 2014-08-21 12:33:22 [2202] [7] DEBUG: DLR[internal]: Looking for DLR
 smsc=tigo, ts=11e22675ee6, dst=595981414913, type=1

 2014-08-21 12:33:22 [2202] [7] WARNING: DLR[internal]: DLR from SMSCtigo
 for DST595981414913 not found.

 2014-08-21 12:33:22 [2202] [7] ERROR: SMPP[tigo]: got DLR but could not
 find message or was not interested in it id11e22675ee6 dst595981414913,
 type1


 Here is my config files


 # SMS USER GROUP


 group = sendsms-user

 username = xxx

 password = yyy

 concatenation = true

 max-messages = 3

 max-messages = 10


 Here is the call to kannel


 http://localhost:13013/cgi-bin/sendsms?username=xxxpassword=yyyto=+595981414913from=1244binfo=CCHURtext=Prueba+de+envio+sms+2smsc=tigodlr-url=http%3A%2F%2Flocalhost%2Fsms%2Fapi%2Fdlr.php%3FmyId%3D1212%26type%3D%25ddlr-mask=31
 Thanks for the help

 Alejandro
 --
 -
 Alejandro Mussi Campos Cervera

Re: dlr-url routing failure

2014-08-21 Thread Alejandro Mussi

Hi Alvaro,

If i replace, it does not send dlr at all. According to the manual the
dlr-mask is not an param in the dlr-url.

Best






On Thu, Aug 21, 2014 at 1:37 PM, Alvaro Cornejo cornejo.alv...@gmail.com
wrote:

 Hi Alejandro

 Change %26type%3D%25ddlr-mask=31 with %26type%3D25%26dlr-mask%3D31

 Note that what you request as dlr is not necessarily what you will
 receive. Carriers define which dlr status will they forward. Some disable
 intermediate status, some allow all of them.

 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.com


 On Thu, Aug 21, 2014 at 11:22 AM, Alejandro Mussi alemu...@gmail.com
 wrote:

 Hi guys,

 My kannel is not sending my dlr-url when type=1. I get it when type=16
 and type=8.

 Here is what log saids:

 2014-08-21 12:33:22 [2202] [7] DEBUG: DLR[internal]: Looking for DLR
 smsc=tigo, ts=11e22675ee6, dst=595981414913, type=1

 2014-08-21 12:33:22 [2202] [7] WARNING: DLR[internal]: DLR from
 SMSCtigo for DST595981414913 not found.

 2014-08-21 12:33:22 [2202] [7] ERROR: SMPP[tigo]: got DLR but could not
 find message or was not interested in it id11e22675ee6 dst595981414913,
 type1


 Here is my config files


 # SMS USER GROUP


 group = sendsms-user

 username = xxx

 password = yyy

 concatenation = true

 max-messages = 3

 max-messages = 10


 Here is the call to kannel


 http://localhost:13013/cgi-bin/sendsms?username=xxxpassword=yyyto=+595981414913from=1244binfo=CCHURtext=Prueba+de+envio+sms+2smsc=tigodlr-url=http%3A%2F%2Flocalhost%2Fsms%2Fapi%2Fdlr.php%3FmyId%3D1212%26type%3D%25ddlr-mask=31
 Thanks for the help

 Alejandro
 --
 -
 Alejandro Mussi Campos Cervera





-- 
-
Alejandro Mussi Campos Cervera

Re: dlr-url routing failure

2014-08-21 Thread spameden

2014-08-21 23:03 GMT+04:00 Alejandro Mussi alemu...@gmail.com:

 Hi Alvaro,

 If i replace, it does not send dlr at all. According to the manual the
 dlr-mask is not an param in the dlr-url.

 Best


You're correct.

Problem is with your SMSC provider. As long as you see only 8 and 16, first
status means ACK and sent by kannel itself, 16 means sms was forbidden by
your SMSC provider, so contact them and resolve with them.






 On Thu, Aug 21, 2014 at 1:37 PM, Alvaro Cornejo cornejo.alv...@gmail.com
 wrote:

 Hi Alejandro

 Change %26type%3D%25ddlr-mask=31 with %26type%3D25%26dlr-mask%3D31

 Note that what you request as dlr is not necessarily what you will
 receive. Carriers define which dlr status will they forward. Some disable
 intermediate status, some allow all of them.

 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.com


 On Thu, Aug 21, 2014 at 11:22 AM, Alejandro Mussi alemu...@gmail.com
 wrote:

 Hi guys,

 My kannel is not sending my dlr-url when type=1. I get it when type=16
 and type=8.

 Here is what log saids:

 2014-08-21 12:33:22 [2202] [7] DEBUG: DLR[internal]: Looking for DLR
 smsc=tigo, ts=11e22675ee6, dst=595981414913, type=1

 2014-08-21 12:33:22 [2202] [7] WARNING: DLR[internal]: DLR from
 SMSCtigo for DST595981414913 not found.

 2014-08-21 12:33:22 [2202] [7] ERROR: SMPP[tigo]: got DLR but could not
 find message or was not interested in it id11e22675ee6 dst595981414913,
 type1


 Here is my config files


 # SMS USER GROUP


 group = sendsms-user

 username = xxx

 password = yyy

 concatenation = true

 max-messages = 3

 max-messages = 10


 Here is the call to kannel


 http://localhost:13013/cgi-bin/sendsms?username=xxxpassword=yyyto=+595981414913from=1244binfo=CCHURtext=Prueba+de+envio+sms+2smsc=tigodlr-url=http%3A%2F%2Flocalhost%2Fsms%2Fapi%2Fdlr.php%3FmyId%3D1212%26type%3D%25ddlr-mask=31
 Thanks for the help

 Alejandro
 --
 -
 Alejandro Mussi Campos Cervera





 --
 -
 Alejandro Mussi Campos Cervera

Re: dlr-url routing failure

Hi

Sorry you are right. Can you test this:

dlr-mask=31dlr-url=
http://localhost/sms/api/dlr.php?myId=1212%26type%3D%25d





Basically type should


|-|
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.com


On Thu, Aug 21, 2014 at 2:34 PM, spameden spame...@gmail.com wrote:




 2014-08-21 23:03 GMT+04:00 Alejandro Mussi alemu...@gmail.com:

  Hi Alvaro,

 If i replace, it does not send dlr at all. According to the manual the
 dlr-mask is not an param in the dlr-url.

 Best


 You're correct.

 Problem is with your SMSC provider. As long as you see only 8 and 16,
 first status means ACK and sent by kannel itself, 16 means sms was
 forbidden by your SMSC provider, so contact them and resolve with them.






 On Thu, Aug 21, 2014 at 1:37 PM, Alvaro Cornejo cornejo.alv...@gmail.com
  wrote:

 Hi Alejandro

 Change %26type%3D%25ddlr-mask=31 with %26type%3D25%26dlr-mask%3D31

 Note that what you request as dlr is not necessarily what you will
 receive. Carriers define which dlr status will they forward. Some disable
 intermediate status, some allow all of them.

 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.com


 On Thu, Aug 21, 2014 at 11:22 AM, Alejandro Mussi alemu...@gmail.com
 wrote:

 Hi guys,

 My kannel is not sending my dlr-url when type=1. I get it when type=16
 and type=8.

 Here is what log saids:

 2014-08-21 12:33:22 [2202] [7] DEBUG: DLR[internal]: Looking for DLR
 smsc=tigo, ts=11e22675ee6, dst=595981414913, type=1

 2014-08-21 12:33:22 [2202] [7] WARNING: DLR[internal]: DLR from
 SMSCtigo for DST595981414913 not found.

 2014-08-21 12:33:22 [2202] [7] ERROR: SMPP[tigo]: got DLR but could not
 find message or was not interested in it id11e22675ee6 dst595981414913,
 type1


 Here is my config files


 # SMS USER GROUP


 group = sendsms-user

 username = xxx

 password = yyy

 concatenation = true

 max-messages = 3

 max-messages = 10


 Here is the call to kannel


 http://localhost:13013/cgi-bin/sendsms?username=xxxpassword=yyyto=+595981414913from=1244binfo=CCHURtext=Prueba+de+envio+sms+2smsc=tigodlr-url=http%3A%2F%2Flocalhost%2Fsms%2Fapi%2Fdlr.php%3FmyId%3D1212%26type%3D%25ddlr-mask=31
 Thanks for the help

 Alejandro
 --
 -
 Alejandro Mussi Campos Cervera





 --
 -
 Alejandro Mussi Campos Cervera

Re: dlr-url routing failure

Hi

Re-reading your original question I saw that, in fact, you do receive the
dlr.

2014-08-21 12:33:22 [2202] [7] DEBUG: DLR[internal]: Looking for DLR
smsc=tigo, ts=11e22675ee6, dst=595981414913, type=1


However kannel is unable to track it back to original message:

2014-08-21 12:33:22 [2202] [7] WARNING: DLR[internal]: DLR from SMSCtigo
for DST595981414913 not found.

2014-08-21 12:33:22 [2202] [7] ERROR: SMPP[tigo]: got DLR but could not
find message or was not interested in it id11e22675ee6 dst595981414913,
type1


This usually means that the the message id type is wrong.

Check variable msg-id-type in user guide and set it accordingly.

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.com


On Thu, Aug 21, 2014 at 3:03 PM, Alvaro Cornejo cornejo.alv...@gmail.com
wrote:

 Hi

 Sorry you are right. Can you test this:

 dlr-mask=31dlr-url=
 http://localhost/sms/api/dlr.php?myId=1212%26type%3D%25d





 Basically type should



 |-|
 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.com


 On Thu, Aug 21, 2014 at 2:34 PM, spameden spame...@gmail.com wrote:




 2014-08-21 23:03 GMT+04:00 Alejandro Mussi alemu...@gmail.com:

  Hi Alvaro,

 If i replace, it does not send dlr at all. According to the manual the
 dlr-mask is not an param in the dlr-url.

 Best


 You're correct.

 Problem is with your SMSC provider. As long as you see only 8 and 16,
 first status means ACK and sent by kannel itself, 16 means sms was
 forbidden by your SMSC provider, so contact them and resolve with them.






 On Thu, Aug 21, 2014 at 1:37 PM, Alvaro Cornejo 
 cornejo.alv...@gmail.com wrote:

 Hi Alejandro

 Change %26type%3D%25ddlr-mask=31 with %26type%3D25%26dlr-mask%3D31

 Note that what you request as dlr is not necessarily what you will
 receive. Carriers define which dlr status will they forward. Some disable
 intermediate status, some allow all of them.

 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.com


 On Thu, Aug 21, 2014 at 11:22 AM, Alejandro Mussi alemu...@gmail.com
 wrote:

 Hi guys,

 My kannel is not sending my dlr-url when type=1. I get it when type=16
 and type=8.

 Here is what log saids:

 2014-08-21 12:33:22 [2202] [7] DEBUG: DLR[internal]: Looking for DLR
 smsc=tigo, ts=11e22675ee6, dst=595981414913, type=1

 2014-08-21 12:33:22 [2202] [7] WARNING: DLR[internal]: DLR from
 SMSCtigo for DST595981414913 not found.

 2014-08-21 12:33:22 [2202] [7] ERROR: SMPP[tigo]: got DLR but could
 not find message or was not interested in it id11e22675ee6
 dst595981414913, type1


 Here is my config files


 # SMS USER GROUP


 group = sendsms-user

 username = xxx

 password = yyy

 concatenation = true

 max-messages = 3

 max-messages = 10


 Here is the call to kannel


 http://localhost:13013/cgi-bin/sendsms?username=xxxpassword=yyyto=+595981414913from=1244binfo=CCHURtext=Prueba+de+envio+sms+2smsc=tigodlr-url=http%3A%2F%2Flocalhost%2Fsms%2Fapi%2Fdlr.php%3FmyId%3D1212%26type%3D%25ddlr-mask=31
 Thanks for the help

 Alejandro
 --
 -
 Alejandro Mussi Campos Cervera





 --
 -
 Alejandro Mussi Campos Cervera

Re: dlr-url routing failure

2014-08-21 Thread Alejandro Mussi

Still not working. Tried msg-id-type = 0x01 and still not working. Also
putting dlr-mask before dlr-url on the param sequence.

The thing is that i do receive the dlr when type=8 and type=16 but kannel
does not send me dlr with type=1.

If the message has been delivered to the phone.. should i have to receive 2
dlr-url? for example type 8 and type 1 or just type 1?

Best




On Thu, Aug 21, 2014 at 4:13 PM, Alvaro Cornejo cornejo.alv...@gmail.com
wrote:

 Hi

 Re-reading your original question I saw that, in fact, you do receive the
 dlr.

 2014-08-21 12:33:22 [2202] [7] DEBUG: DLR[internal]: Looking for DLR
 smsc=tigo, ts=11e22675ee6, dst=595981414913, type=1


 However kannel is unable to track it back to original message:

 2014-08-21 12:33:22 [2202] [7] WARNING: DLR[internal]: DLR from SMSCtigo
 for DST595981414913 not found.

 2014-08-21 12:33:22 [2202] [7] ERROR: SMPP[tigo]: got DLR but could not
 find message or was not interested in it id11e22675ee6 dst595981414913,
 type1


 This usually means that the the message id type is wrong.

 Check variable msg-id-type in user guide and set it accordingly.

 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.com


 On Thu, Aug 21, 2014 at 3:03 PM, Alvaro Cornejo cornejo.alv...@gmail.com
 wrote:

 Hi

 Sorry you are right. Can you test this:

 dlr-mask=31dlr-url=
 http://localhost/sms/api/dlr.php?myId=1212%26type%3D%25d





 Basically type should



 |-|
 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.com


 On Thu, Aug 21, 2014 at 2:34 PM, spameden spame...@gmail.com wrote:




 2014-08-21 23:03 GMT+04:00 Alejandro Mussi alemu...@gmail.com:

  Hi Alvaro,

 If i replace, it does not send dlr at all. According to the manual the
 dlr-mask is not an param in the dlr-url.

 Best


 You're correct.

 Problem is with your SMSC provider. As long as you see only 8 and 16,
 first status means ACK and sent by kannel itself, 16 means sms was
 forbidden by your SMSC provider, so contact them and resolve with them.






 On Thu, Aug 21, 2014 at 1:37 PM, Alvaro Cornejo 
 cornejo.alv...@gmail.com wrote:

 Hi Alejandro

 Change %26type%3D%25ddlr-mask=31 with %26type%3D25%26dlr-mask%3D31

 Note that what you request as dlr is not necessarily what you will
 receive. Carriers define which dlr status will they forward. Some disable
 intermediate status, some allow all of them.

 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.com


 On Thu, Aug 21, 2014 at 11:22 AM, Alejandro Mussi alemu...@gmail.com
 wrote:

 Hi guys,

 My kannel is not sending my dlr-url when type=1. I get it when
 type=16 and type=8.

 Here is what log saids:

 2014-08-21 12:33:22 [2202] [7] DEBUG: DLR[internal]: Looking for DLR
 smsc=tigo, ts=11e22675ee6, dst=595981414913, type=1

 2014-08-21 12:33:22 [2202] [7] WARNING: DLR[internal]: DLR from
 SMSCtigo for DST595981414913 not found.

 2014-08-21 12:33:22 [2202] [7] ERROR: SMPP[tigo]: got DLR but could
 not find message or was not interested in it id11e22675ee6
 dst595981414913, type1


 Here is my config files


 # SMS USER GROUP


 group = sendsms-user

 username = xxx

 password = yyy

 concatenation = true

 max-messages = 3

 max-messages = 10


 Here is the call to kannel


 http://localhost:13013/cgi-bin/sendsms?username=xxxpassword=yyyto=+595981414913from=1244binfo=CCHURtext=Prueba+de+envio+sms+2smsc=tigodlr-url=http%3A%2F%2Flocalhost%2Fsms%2Fapi%2Fdlr.php%3FmyId%3D1212%26type%3D%25ddlr-mask=31
 Thanks for the help

 Alejandro
 --
 -
 Alejandro Mussi Campos Cervera





 --
 -
 Alejandro Mussi Campos Cervera







-- 
-
Alejandro Mussi Campos Cervera

Re: dlr-url routing failure

Hi

dlr 8 means message has been submitted to smsc (and accepted by it)
dlr 1 means message has been delivered to phone (and stored either in SIM
or phone memory)

Also; some operators does not provide all dlr status; however as stated on
my previous mail. kannel is in fact receiving the dlr with type=1 as seen
in your smsc log.

The issue is that it does not find a match in its dlr table to track it
back.

Can you post a full log of a transaction from submitting to kannel to last
dlr ? not only the log from smsc but smsbox log. In this last log you
should see kannel calig dlr-url and dlr matching.

It might be that kannel is deleting record when receiving dlr 8 thus when
receiving dlr 1 the record for that message is gone.

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.com


On Thu, Aug 21, 2014 at 4:27 PM, Alejandro Mussi alemu...@gmail.com wrote:

 Still not working. Tried msg-id-type = 0x01 and still not working. Also
 putting dlr-mask before dlr-url on the param sequence.

 The thing is that i do receive the dlr when type=8 and type=16 but kannel
 does not send me dlr with type=1.

 If the message has been delivered to the phone.. should i have to receive
 2 dlr-url? for example type 8 and type 1 or just type 1?

 Best




 On Thu, Aug 21, 2014 at 4:13 PM, Alvaro Cornejo cornejo.alv...@gmail.com
 wrote:

 Hi

 Re-reading your original question I saw that, in fact, you do receive the
 dlr.

 2014-08-21 12:33:22 [2202] [7] DEBUG: DLR[internal]: Looking for DLR
 smsc=tigo, ts=11e22675ee6, dst=595981414913, type=1


 However kannel is unable to track it back to original message:

 2014-08-21 12:33:22 [2202] [7] WARNING: DLR[internal]: DLR from
 SMSCtigo for DST595981414913 not found.

 2014-08-21 12:33:22 [2202] [7] ERROR: SMPP[tigo]: got DLR but could not
 find message or was not interested in it id11e22675ee6 dst595981414913,
 type1


 This usually means that the the message id type is wrong.

 Check variable msg-id-type in user guide and set it accordingly.

 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.com


 On Thu, Aug 21, 2014 at 3:03 PM, Alvaro Cornejo cornejo.alv...@gmail.com
  wrote:

 Hi

 Sorry you are right. Can you test this:

 dlr-mask=31dlr-url=
 http://localhost/sms/api/dlr.php?myId=1212%26type%3D%25d





 Basically type should



 |-|
 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.com


 On Thu, Aug 21, 2014 at 2:34 PM, spameden spame...@gmail.com wrote:




 2014-08-21 23:03 GMT+04:00 Alejandro Mussi alemu...@gmail.com:

  Hi Alvaro,

 If i replace, it does not send dlr at all. According to the manual the
 dlr-mask is not an param in the dlr-url.

 Best


 You're correct.

 Problem is with your SMSC provider. As long as you see only 8 and 16,
 first status means ACK and sent by kannel itself, 16 means sms was
 forbidden by your SMSC provider, so contact them and resolve with them.






 On Thu, Aug 21, 2014 at 1:37 PM, Alvaro Cornejo 
 cornejo.alv...@gmail.com wrote:

 Hi Alejandro

 Change %26type%3D%25ddlr-mask=31 with %26type%3D25%26dlr-mask%3D31

 Note that what you request as dlr is not necessarily what you will
 receive. Carriers define which dlr status will they forward. Some disable
 intermediate status, some allow all of them.

 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.com


 On Thu, Aug 21, 2014 at 11:22 AM, Alejandro Mussi alemu...@gmail.com
  wrote:

 Hi guys,

 My kannel is not sending my dlr-url when type=1. I get it when
 type=16 and type=8.

 Here is what log saids:

 2014-08-21 12:33:22 [2202] [7] DEBUG: DLR[internal]: Looking for DLR
 smsc=tigo, ts=11e22675ee6, dst=595981414913, type=1

 2014-08-21 12:33:22 [2202] [7] WARNING: DLR[internal]: DLR from
 SMSCtigo for DST595981414913 not found.

 2014-08-21 12:33:22 [2202] [7] ERROR: SMPP[tigo]: got DLR but could
 not find

Re: dlr-url routing failure

2014-08-21 Thread Alejandro Mussi

Here goes the logs (tested with dlr-mask=3):

http://localhost:13013/cgi-bin/sendsms?username=xxxpassword=yyyto=+595981414913from=1244binfo=CMBEGtext=Prueba+de+serviciosmsc=tigodlr-mask=3dlr-url=http%3A%2F%2Flocalhost%2Fsms%2Fapi%2Fdlr.php%3FmyId%3D1212%26type%3D%25d

bearerbox.log

2014-08-21 18:47:08 [1629] [6] DEBUG: DLR[internal]: Adding DLR smsc=tigo,
ts=5400874, src=1244, dst=595981414913, mask=3, boxc=

2014-08-21 18:47:10 [1629] [7] DEBUG: Optional parameter tag (0x001e)

2014-08-21 18:47:10 [1629] [7] DEBUG: Optional parameter length read as 12

2014-08-21 18:47:10 [1629] [7] DEBUG: Optional parameter tag (0x0427)

2014-08-21 18:47:10 [1629] [7] DEBUG: Optional parameter length read as 1

2014-08-21 18:47:10 [1629] [7] DEBUG: SMPP[tigo]: Got PDU:

2014-08-21 18:47:10 [1629] [7] DEBUG: SMPP PDU 0x7f0058001560 dump:

2014-08-21 18:47:10 [1629] [7] DEBUG:   type_name: deliver_sm

2014-08-21 18:47:10 [1629] [7] DEBUG:   command_id: 5 = 0x0005

2014-08-21 18:47:10 [1629] [7] DEBUG:   command_status: 0 = 0x

2014-08-21 18:47:10 [1629] [7] DEBUG:   sequence_number: 0 = 0x

2014-08-21 18:47:10 [1629] [7] DEBUG:   service_type: NULL

2014-08-21 18:47:10 [1629] [7] DEBUG:   source_addr_ton: 1 = 0x0001

2014-08-21 18:47:10 [1629] [7] DEBUG:   source_addr_npi: 1 = 0x0001

2014-08-21 18:47:10 [1629] [7] DEBUG:   source_addr: 595981414913

2014-08-21 18:47:10 [1629] [7] DEBUG:   dest_addr_ton: 0 = 0x

2014-08-21 18:47:10 [1629] [7] DEBUG:   dest_addr_npi: 1 = 0x0001

2014-08-21 18:47:10 [1629] [7] DEBUG:   destination_addr: 1244

2014-08-21 18:47:10 [1629] [7] DEBUG:   esm_class: 4 = 0x0004

2014-08-21 18:47:10 [1629] [7] DEBUG:   protocol_id: 0 = 0x

2014-08-21 18:47:10 [1629] [7] DEBUG:   priority_flag: 0 = 0x

2014-08-21 18:47:10 [1629] [7] DEBUG:   schedule_delivery_time: NULL

2014-08-21 18:47:10 [1629] [7] DEBUG:   validity_period: NULL

2014-08-21 18:47:10 [1629] [7] DEBUG:   registered_delivery: 1 = 0x0001

2014-08-21 18:47:10 [1629] [7] DEBUG:   replace_if_present_flag: 0 =
0x

2014-08-21 18:47:10 [1629] [7] DEBUG:   data_coding: 0 = 0x

2014-08-21 18:47:10 [1629] [7] DEBUG:   sm_default_msg_id: 0 = 0x

2014-08-21 18:47:10 [1629] [7] DEBUG:   sm_length: 105 = 0x0069

2014-08-21 18:47:10 [1629] [7] DEBUG:   short_message:

2014-08-21 18:47:10 [1629] [7] DEBUG:Octet string at 0x7f0058001730:

2014-08-21 18:47:10 [1629] [7] DEBUG:  len:  105

2014-08-21 18:47:10 [1629] [7] DEBUG:  size: 106

2014-08-21 18:47:10 [1629] [7] DEBUG:  immutable: 0

2014-08-21 18:47:10 [1629] [7] DEBUG:  data: 69 64 3a 35 32 36 39 32 61
20 73 75 62 3a 30 30   id:52692a sub:00

2014-08-21 18:47:10 [1629] [7] DEBUG:  data: 31 20 64 6c 76 72 64 3a 30
30 31 20 73 75 62 6d   1 dlvrd:001 subm

2014-08-21 18:47:10 [1629] [7] DEBUG:  data: 69 74 20 64 61 74 65 3a 31
34 30 38 32 31 31 38   it date:14082118

2014-08-21 18:47:10 [1629] [7] DEBUG:  data: 31 37 20 64 6f 6e 65 20 64
61 74 65 3a 31 34 30   17 done date:140

2014-08-21 18:47:10 [1629] [7] DEBUG:  data: 38 32 31 31 38 31 38 20 73
74 61 74 3a 44 45 4c   8211818 stat:DEL

2014-08-21 18:47:10 [1629] [7] DEBUG:  data: 49 56 52 44 20 65 72 72 3a
30 30 30 20 74 65 78   IVRD err:000 tex

2014-08-21 18:47:10 [1629] [7] DEBUG:  data: 74 3a 6d 65 73 73 61 67
65t:message

2014-08-21 18:47:10 [1629] [7] DEBUG:Octet string dump ends.

2014-08-21 18:47:10 [1629] [7] DEBUG:   message_state: 2 = 0x0002

2014-08-21 18:47:10 [1629] [7] DEBUG:   receipted_message_id: 11e127be1d6

2014-08-21 18:47:10 [1629] [7] DEBUG: SMPP PDU dump ends.

2014-08-21 18:47:10 [1629] [7] DEBUG: SMPP[tigo] handle_pdu, got DLR

2014-08-21 18:47:10 [1629] [7] DEBUG: DLR[internal]: Looking for DLR
smsc=tigo, ts=1228670755286, dst=595981414913, type=1

2014-08-21 18:47:10 [1629] [7] WARNING: DLR[internal]: DLR from SMSCtigo
for DST595981414913 not found.

2014-08-21 18:47:10 [1629] [7] ERROR: SMPP[tigo]: got DLR but could not
find message or was not interested in it id1228670755286
dst595981414913, type1

2014-08-21 18:47:10 [1629] [7] DEBUG: SMPP[tigo]: Sending PDU:

2014-08-21 18:47:10 [1629] [7] DEBUG: SMPP PDU 0x7f0058000e50 dump:

2014-08-21 18:47:10 [1629] [7] DEBUG:   type_name: deliver_sm_resp

2014-08-21 18:47:10 [1629] [7] DEBUG:   command_id: 2147483653 = 0x8005

2014-08-21 18:47:10 [1629] [7] DEBUG:   command_status: 0 = 0x

2014-08-21 18:47:10 [1629] [7] DEBUG:   sequence_number: 0 = 0x

2014-08-21 18:47:10 [1629] [7] DEBUG:   message_id: NULL

2014-08-21 18:47:10 [1629] [7] DEBUG: SMPP PDU dump ends.



SMSBOX.LOG


2014-08-21 18:47:08 [1652] [2] DEBUG: HTTP: Creating HTTPClient for
`190.104.157.112'.

2014-08-21 18:47:08 [1652] [2] DEBUG: HTTP: Created HTTPClient area
0x7fb408000a90.

2014-08-21 18:47:08 [1652] [3] INFO: smsbox: Got HTTP request
/cgi-bin/sendsms from 190.104.157.112

2014-08-21 18:47:08 [1652] [3] INFO:

Re: DLR Reports

2014-07-27 Thread ha...@aeon.pk

Mask 63 works for most of the message states.


On Thu, Jun 26, 2014 at 11:31 PM, [Digital^Dude] ® millennium@gmail.com
 wrote:

 What's your dlr-mask?
 And this may be an operator specific issue as they might only have allowed
 one retry per submit_sm from the ESME hence not allowing any messages from
 your end to be buffered.
 On Jun 26, 2014 3:32 PM, Michael Stevens michael.stev...@mcmcas.co.za
 wrote:

 Hi..

 OS: Linux
 Kannel Version: 1.50

 I use a gsm modem with dlr reports. I receive the ACK, Ack Failed,
 Success dlr.'s but not the buffered dlr when the phone where I am sending
 the message is offline.
 Any ideas?

Re: DLR Reports

2014-07-27 Thread ha...@aeon.pk

Problem is with your operator. Check with it.


On Tue, Jul 1, 2014 at 7:25 PM, Michael Stevens 
michael.stev...@mcmcas.co.za wrote:

 Hi….

 I have installed Kannel 1.50 and is using dlr for ams status reports. The
 mask I am using is 31.
 Everything works fine. I get the ACK/NAC report and  the successful
 delivery report. (if the device is online).

 However, when I send a sms to a device that is offline, I only get the
 ACK/NAC report. When I switch the device back on again, the sms is
 delivered, but I do not get
 the success report.

 Any ideas?

Re: DLR does not match message id

2014-07-18 Thread Niel Smith

Hi Mario,

Would it be possible to supply the full submit_sm, submit_sm_resp, and
deliver_sm PDU dumps?


On 18 July 2014 22:12, Mario Noboa mnobo...@gmail.com wrote:


 Hi list,

 I got a DLR problem with an operator.

 When sent a submit_sm, kannel receipt a message id:

 *message_id: 1e13a15*
 *DLR[internal]: Adding DLR smsc=SMSC1, ts=31537685, src=30100,
 dst=XXX, mask=31, boxc=*


 But its DLR arrives with another id:

 *2014-07-17 12:45:16 [32271] [35] DEBUG: DLR[internal]: Looking for DLR
 smsc=SMSC1, ts=613852054, dst=975647918, type=1*
 *2014-07-17 12:45:16 [32271] [35] WARNING: DLR[internal]: DLR from
 SMSCSMSC1 for DST975647918 not found.*
 *2014-07-17 12:45:16 [32271] [35] ERROR: SMPP[SMSC1]: got DLR but could
 not find message or was not interested in it id613852054 dstX,
 type1*


 if you notice both are in decimal and they are different. *31537685 and *
 *613852054*

 I tried to configure version 33 to use Timestamp, but they don't let me
 connect in that way.  There is any way to use timestamp instead of message
 id?

 Thanks for your answers!

 Mario

Re: DLR does not match message id

2014-07-18 Thread Mario Noboa

Of course Niel, thanks!!!




2014-07-18 15:30 GMT-05:00 Niel Smith daniel.alfred.sm...@gmail.com:

 Hi Mario,

 Would it be possible to supply the full submit_sm, submit_sm_resp, and
 deliver_sm PDU dumps?


 On 18 July 2014 22:12, Mario Noboa mnobo...@gmail.com wrote:


 Hi list,

 I got a DLR problem with an operator.

 When sent a submit_sm, kannel receipt a message id:

 *message_id: 1e13a15*
 *DLR[internal]: Adding DLR smsc=SMSC1, ts=31537685, src=30100,
 dst=XXX, mask=31, boxc=*


 But its DLR arrives with another id:

 *2014-07-17 12:45:16 [32271] [35] DEBUG: DLR[internal]: Looking for DLR
 smsc=SMSC1, ts=613852054, dst=975647918, type=1*
 *2014-07-17 12:45:16 [32271] [35] WARNING: DLR[internal]: DLR from
 SMSCSMSC1 for DST975647918 not found.*
 *2014-07-17 12:45:16 [32271] [35] ERROR: SMPP[SMSC1]: got DLR but could
 not find message or was not interested in it id613852054 dstX,
 type1*


 if you notice both are in decimal and they are different. *31537685 and *
 *613852054*

 I tried to configure version 33 to use Timestamp, but they don't let me
 connect in that way.  There is any way to use timestamp instead of message
 id?

 Thanks for your answers!

 Mario



2014-07-17 12:45:12 [32271] [36] DEBUG: SMPP[SMSC1]: throughput (0.00,20.00)
2014-07-17 12:45:12 [32271] [36] DEBUG: SMPP[SMSC1]: Manually forced source 
addr ton = 0, source add npi = 0
2014-07-17 12:45:12 [32271] [36] DEBUG: SMPP[SMSC1]: Manually forced dest addr 
ton = 1, dest add npi = 1
2014-07-17 12:45:12 [32271] [36] DEBUG: SMPP[SMSC1]: Sending PDU:
2014-07-17 12:45:12 [32271] [36] DEBUG: SMPP PDU 0x11f4cb80 dump:
2014-07-17 12:45:12 [32271] [36] DEBUG:   type_name: submit_sm
2014-07-17 12:45:12 [32271] [36] DEBUG:   command_id: 4 = 0x0004
2014-07-17 12:45:12 [32271] [36] DEBUG:   command_status: 0 = 0x
2014-07-17 12:45:12 [32271] [36] DEBUG:   sequence_number: 5579 = 0x15cb
2014-07-17 12:45:12 [32271] [36] DEBUG:   service_type: NULL
2014-07-17 12:45:12 [32271] [36] DEBUG:   source_addr_ton: 0 = 0x
2014-07-17 12:45:12 [32271] [36] DEBUG:   source_addr_npi: 0 = 0x
2014-07-17 12:45:12 [32271] [36] DEBUG:   source_addr: 30100
2014-07-17 12:45:12 [32271] [36] DEBUG:   dest_addr_ton: 1 = 0x0001
2014-07-17 12:45:12 [32271] [36] DEBUG:   dest_addr_npi: 1 = 0x0001
2014-07-17 12:45:12 [32271] [36] DEBUG:   destination_addr: XXX
2014-07-17 12:45:12 [32271] [36] DEBUG:   esm_class: 3 = 0x0003
2014-07-17 12:45:12 [32271] [36] DEBUG:   protocol_id: 0 = 0x
2014-07-17 12:45:12 [32271] [36] DEBUG:   priority_flag: 0 = 0x
2014-07-17 12:45:12 [32271] [36] DEBUG:   schedule_delivery_time: NULL
2014-07-17 12:45:12 [32271] [36] DEBUG:   validity_period: NULL
2014-07-17 12:45:12 [32271] [36] DEBUG:   registered_delivery: 1 = 0x0001
2014-07-17 12:45:12 [32271] [36] DEBUG:   replace_if_present_flag: 0 = 
0x
2014-07-17 12:45:12 [32271] [36] DEBUG:   data_coding: 0 = 0x
2014-07-17 12:45:12 [32271] [36] DEBUG:   sm_default_msg_id: 0 = 0x
2014-07-17 12:45:12 [32271] [36] DEBUG:   sm_length: 17 = 0x0011
2014-07-17 12:45:12 [32271] [36] DEBUG:   short_message: test message 
2014-07-17 12:45:12 [32271] [36] DEBUG: SMPP PDU dump ends.
2014-07-17 12:45:12 [32271] [36] DEBUG: SMPP[SMSC1]: throughput (1.00,20.00)
2014-07-17 12:45:12 [32271] [36] DEBUG: SMPP[SMSC1]: throughput (1.00,20.00)
2014-07-17 12:45:12 [32271] [36] DEBUG: SMPP[SMSC1]: Got PDU:
2014-07-17 12:45:12 [32271] [36] DEBUG: SMPP PDU 0x11f4cb80 dump:
2014-07-17 12:45:12 [32271] [36] DEBUG:   type_name: submit_sm_resp
2014-07-17 12:45:12 [32271] [36] DEBUG:   command_id: 2147483652 = 0x8004
2014-07-17 12:45:12 [32271] [36] DEBUG:   command_status: 0 = 0x
2014-07-17 12:45:12 [32271] [36] DEBUG:   sequence_number: 5579 = 0x15cb
2014-07-17 12:45:12 [32271] [36] DEBUG:   message_id: 1e13a15
2014-07-17 12:45:12 [32271] [36] DEBUG: SMPP PDU dump ends.
2014-07-17 12:45:12 [32271] [36] DEBUG: DLR[internal]: Adding DLR smsc=SMSC1, 
ts=31537685, src=30100, dst=XXX, mask=31, boxc=
2014-07-17 12:45:12 [32271] [36] DEBUG: SMSC[SMSC1]: creating DLR message
2014-07-17 12:45:12 [32271] [36] DEBUG: SMSC[SMSC1]: DLR = 
http://10.239.0.37/esme/dlrbulk.php?idt=46246228prioridad=4tiempo=%ttype=%dtelefono=%pshort=%Pmsgid=%Fsmscid=%itype2=%Destado=%A
2014-07-17 12:45:12 [32271] [36] DEBUG: SMPP[SMSC1]: throughput (1.00,20.00)


2014-07-17 12:45:16 [32271] [35] DEBUG: SMPP[SMSC1]: Got PDU:
2014-07-17 12:45:16 [32271] [35] DEBUG: SMPP PDU 0x11da4330 dump:
2014-07-17 12:45:16 [32271] [35] DEBUG:   type_name: deliver_sm
2014-07-17 12:45:16 [32271] [35] DEBUG:   command_id: 5 = 0x0005
2014-07-17 12:45:16 [32271] [35] DEBUG:   command_status: 0 = 0x
2014-07-17 12:45:16 [32271] [35] DEBUG:   sequence_number: 219 = 0x00db
2014-07-17 12:45:16 [32271] [35] DEBUG:   service_type: NULL
2014-07-17 12:45:16 [32271] [35] DEBUG:   source_addr_ton: 0 = 0x
2014-07-17 12:45:16

Re: DLR does not match message id

It looks like your SMSC operator gives hex number in submit_sm packet and
hex number in deliver_sm, so you need to add this in smsc group
configuration:

msg-id-type = 0x02



2014-07-19 0:40 GMT+04:00 Mario Noboa mnobo...@gmail.com:

 Of course Niel, thanks!!!




 2014-07-18 15:30 GMT-05:00 Niel Smith daniel.alfred.sm...@gmail.com:

 Hi Mario,

 Would it be possible to supply the full submit_sm, submit_sm_resp, and
 deliver_sm PDU dumps?


 On 18 July 2014 22:12, Mario Noboa mnobo...@gmail.com wrote:


 Hi list,

 I got a DLR problem with an operator.

 When sent a submit_sm, kannel receipt a message id:

 *message_id: 1e13a15*
 *DLR[internal]: Adding DLR smsc=SMSC1, ts=31537685, src=30100,
 dst=XXX, mask=31, boxc=*


 But its DLR arrives with another id:

 *2014-07-17 12:45:16 [32271] [35] DEBUG: DLR[internal]: Looking for DLR
 smsc=SMSC1, ts=613852054, dst=975647918, type=1*
 *2014-07-17 12:45:16 [32271] [35] WARNING: DLR[internal]: DLR from
 SMSCSMSC1 for DST975647918 not found.*
 *2014-07-17 12:45:16 [32271] [35] ERROR: SMPP[SMSC1]: got DLR but could
 not find message or was not interested in it id613852054 dstX,
 type1*


 if you notice both are in decimal and they are different. *31537685
 and **613852054*

 I tried to configure version 33 to use Timestamp, but they don't let me
 connect in that way.  There is any way to use timestamp instead of message
 id?

 Thanks for your answers!

 Mario

Re: DLR does not match message id

err, I meant hex in submit_sm and decimal in deliver_sm packets.


2014-07-19 1:04 GMT+04:00 spameden spame...@gmail.com:

 It looks like your SMSC operator gives hex number in submit_sm packet and
 hex number in deliver_sm, so you need to add this in smsc group
 configuration:

 msg-id-type = 0x02



 2014-07-19 0:40 GMT+04:00 Mario Noboa mnobo...@gmail.com:

 Of course Niel, thanks!!!




 2014-07-18 15:30 GMT-05:00 Niel Smith daniel.alfred.sm...@gmail.com:

 Hi Mario,

 Would it be possible to supply the full submit_sm, submit_sm_resp, and
 deliver_sm PDU dumps?


 On 18 July 2014 22:12, Mario Noboa mnobo...@gmail.com wrote:


 Hi list,

 I got a DLR problem with an operator.

 When sent a submit_sm, kannel receipt a message id:

 *message_id: 1e13a15*
 *DLR[internal]: Adding DLR smsc=SMSC1, ts=31537685, src=30100,
 dst=XXX, mask=31, boxc=*


 But its DLR arrives with another id:

 *2014-07-17 12:45:16 [32271] [35] DEBUG: DLR[internal]: Looking for DLR
 smsc=SMSC1, ts=613852054, dst=975647918, type=1*
 *2014-07-17 12:45:16 [32271] [35] WARNING: DLR[internal]: DLR from
 SMSCSMSC1 for DST975647918 not found.*
 *2014-07-17 12:45:16 [32271] [35] ERROR: SMPP[SMSC1]: got DLR but could
 not find message or was not interested in it id613852054 dstX,
 type1*


 if you notice both are in decimal and they are different. *31537685
 and **613852054*

 I tried to configure version 33 to use Timestamp, but they don't let me
 connect in that way.  There is any way to use timestamp instead of message
 id?

 Thanks for your answers!

 Mario

Re: DLR does not match message id

2014-07-18 Thread Mario Noboa

Thanks your answer Spameden. I thought the same thing, but the message ids
are complete different:

if you see the log:

submit_sm_resp: message_id: 31537685   (decimal)
deliver_sm:   ts=613852054   (decimal)

regards,



2014-07-18 16:04 GMT-05:00 spameden spame...@gmail.com:

 err, I meant hex in submit_sm and decimal in deliver_sm packets.


 2014-07-19 1:04 GMT+04:00 spameden spame...@gmail.com:

 It looks like your SMSC operator gives hex number in submit_sm packet and
 hex number in deliver_sm, so you need to add this in smsc group
 configuration:

 msg-id-type = 0x02



 2014-07-19 0:40 GMT+04:00 Mario Noboa mnobo...@gmail.com:

 Of course Niel, thanks!!!




 2014-07-18 15:30 GMT-05:00 Niel Smith daniel.alfred.sm...@gmail.com:

 Hi Mario,

 Would it be possible to supply the full submit_sm, submit_sm_resp, and
 deliver_sm PDU dumps?


 On 18 July 2014 22:12, Mario Noboa mnobo...@gmail.com wrote:


 Hi list,

 I got a DLR problem with an operator.

 When sent a submit_sm, kannel receipt a message id:

 *message_id: 1e13a15*
 *DLR[internal]: Adding DLR smsc=SMSC1, ts=31537685, src=30100,
 dst=XXX, mask=31, boxc=*


 But its DLR arrives with another id:

 *2014-07-17 12:45:16 [32271] [35] DEBUG: DLR[internal]: Looking for
 DLR smsc=SMSC1, ts=613852054, dst=975647918, type=1*
 *2014-07-17 12:45:16 [32271] [35] WARNING: DLR[internal]: DLR from
 SMSCSMSC1 for DST975647918 not found.*
 *2014-07-17 12:45:16 [32271] [35] ERROR: SMPP[SMSC1]: got DLR but
 could not find message or was not interested in it id613852054
 dstX, type1*


 if you notice both are in decimal and they are different. *31537685
 and **613852054*

 I tried to configure version 33 to use Timestamp, but they don't let
 me connect in that way.  There is any way to use timestamp instead of
 message id?

 Thanks for your answers!

 Mario

Re: DLR does not match message id

Actually, I've just looked at your logs again:

2014-07-17 12:45:12 [32271] [36] DEBUG: SMPP[SMSC1]: Got PDU:
2014-07-17 12:45:12 [32271] [36] DEBUG: SMPP PDU 0x11f4cb80 dump:
2014-07-17 12:45:12 [32271] [36] DEBUG:   type_name: submit_sm_resp
2014-07-17 12:45:12 [32271] [36] DEBUG:   command_id: 2147483652 =
0x8004
2014-07-17 12:45:12 [32271] [36] DEBUG:   command_status: 0 = 0x
2014-07-17 12:45:12 [32271] [36] DEBUG:   sequence_number: 5579 = 0x15cb
2014-07-17 12:45:12 [32271] [36] DEBUG:   message_id: 1e13a15
2014-07-17 12:45:12 [32271] [36] DEBUG: SMPP PDU dump ends.
2014-07-17 12:45:12 [32271] [36] DEBUG: DLR[internal]: Adding DLR
smsc=SMSC1, ts=31537685, src=30100, dst=XXX, mask=31, boxc=
2014-07-17 12:45:12 [32271] [36] DEBUG: SMSC[SMSC1]: creating DLR message

Message ID is 31537685 in submit_sm.

In deliver_sm it's:
2014-07-17 12:45:16 [32271] [35] DEBUG:   short_message:
2014-07-17 12:45:16 [32271] [35] DEBUG:Octet string at 0x11f4cf80:
2014-07-17 12:45:16 [32271] [35] DEBUG:  len:  119
2014-07-17 12:45:16 [32271] [35] DEBUG:  size: 120
2014-07-17 12:45:16 [32271] [35] DEBUG:  immutable: 0
2014-07-17 12:45:16 [32271] [35] DEBUG:  data: 69 64 3a 30 30 33 31 35
33 37 36 38 35 20 73 75   id:0031537685 su
2014-07-17 12:45:16 [32271] [35] DEBUG:  data: 62 3a 30 30 31 20 64 6c
76 72 64 3a 30 30 31 20   b:001 dlvrd:001
2014-07-17 12:45:16 [32271] [35] DEBUG:  data: 73 75 62 6d 69 74 20 64
61 74 65 3a 31 34 30 37   submit date:1407
2014-07-17 12:45:16 [32271] [35] DEBUG:  data: 31 37 31 32 34 35 20 64
6f 6e 65 20 64 61 74 65   171245 done date
2014-07-17 12:45:16 [32271] [35] DEBUG:  data: 3a 31 34 30 37 31 37 31
32 34 35 20 73 74 61 74   :1407171245 stat
2014-07-17 12:45:16 [32271] [35] DEBUG:  data: 3a 44 45 4c 49 56 52 44
20 65 72 72 3a 30 30 30   :DELIVRD err:000
2014-07-17 12:45:16 [32271] [35] DEBUG:  data: 20 74 65 78 74 3a 6d 65
6e 73 61 6a 65 20 64 65text:test messa
2014-07-17 12:45:16 [32271] [35] DEBUG:  data: 20 70 72 75 65 62 61
  ge 000
2014-07-17 12:45:16 [32271] [35] DEBUG:Octet string dump ends.
2014-07-17 12:45:16 [32271] [35] DEBUG:   message_state: 2 = 0x0002
2014-07-17 12:45:16 [32271] [35] DEBUG:   receipted_message_id: 2496a396

In msg-log it says:  id:0031537685 so it must be either kannel converting
it to hex for some reason or maybe some SMSC bug.
I can't seem to be able to get hex number from source id so it must be
something either at your operator side or something.

What is the kannel version you're using? And show your configuration.


2014-07-19 1:16 GMT+04:00 Mario Noboa mnobo...@gmail.com:

 Thanks your answer Spameden. I thought the same thing, but the message ids
 are complete different:

 if you see the log:

 submit_sm_resp: message_id: 31537685   (decimal)
 deliver_sm:   ts=613852054   (decimal)

 regards,



 2014-07-18 16:04 GMT-05:00 spameden spame...@gmail.com:

 err, I meant hex in submit_sm and decimal in deliver_sm packets.


 2014-07-19 1:04 GMT+04:00 spameden spame...@gmail.com:

 It looks like your SMSC operator gives hex number in submit_sm packet and
 hex number in deliver_sm, so you need to add this in smsc group
 configuration:

 msg-id-type = 0x02



 2014-07-19 0:40 GMT+04:00 Mario Noboa mnobo...@gmail.com:

 Of course Niel, thanks!!!




 2014-07-18 15:30 GMT-05:00 Niel Smith daniel.alfred.sm...@gmail.com:

 Hi Mario,

 Would it be possible to supply the full submit_sm, submit_sm_resp, and
 deliver_sm PDU dumps?


 On 18 July 2014 22:12, Mario Noboa mnobo...@gmail.com wrote:


 Hi list,

 I got a DLR problem with an operator.

 When sent a submit_sm, kannel receipt a message id:

 *message_id: 1e13a15*
 *DLR[internal]: Adding DLR smsc=SMSC1, ts=31537685, src=30100,
 dst=XXX, mask=31, boxc=*


 But its DLR arrives with another id:

 *2014-07-17 12:45:16 [32271] [35] DEBUG: DLR[internal]: Looking for
 DLR smsc=SMSC1, ts=613852054, dst=975647918, type=1*
 *2014-07-17 12:45:16 [32271] [35] WARNING: DLR[internal]: DLR from
 SMSCSMSC1 for DST975647918 not found.*
 *2014-07-17 12:45:16 [32271] [35] ERROR: SMPP[SMSC1]: got DLR but
 could not find message or was not interested in it id613852054
 dstX, type1*


 if you notice both are in decimal and they are different. *31537685
 and **613852054*

 I tried to configure version 33 to use Timestamp, but they don't let
 me connect in that way.  There is any way to use timestamp instead of
 message id?

 Thanks for your answers!

 Mario

Re: DLR does not match message id

2014-07-18 Thread Mario Noboa

You're right the message id is in short_message but it should be in
receipted_message_id. It's a bug of the operator, but they told me that
they can't do any change.

That's why I asked to use the timestamp  :)

Here is my config (it tried msg-id-type = 2 but didn't work):

#Rx SMSC1
group = smsc
smsc = smpp
smsc-id = SMSC1
host = X.X.X.X
port = 0
receive-port = 1
smsc-username = esystem
smsc-password = psystem
system-type =
interface-version = 34
throughput=20
msg-id-type = 1
allowed-smsc-id = SMSC1


#Tx SMSC1
group = smsc
smsc = smpp
smsc-id = SMSC1
host = X.X.X.X
port = 1
receive-port = 0
smsc-username = esystem
smsc-password = psystem
system-type =
interface-version = 34
throughput=20
msg-id-type = 1
log-level = 0
allowed-smsc-id = SMSC1

Thanks!


2014-07-18 16:35 GMT-05:00 spameden spame...@gmail.com:

 Actually, I've just looked at your logs again:

 2014-07-17 12:45:12 [32271] [36] DEBUG: SMPP[SMSC1]: Got PDU:
 2014-07-17 12:45:12 [32271] [36] DEBUG: SMPP PDU 0x11f4cb80 dump:
 2014-07-17 12:45:12 [32271] [36] DEBUG:   type_name: submit_sm_resp
 2014-07-17 12:45:12 [32271] [36] DEBUG:   command_id: 2147483652 =
 0x8004
 2014-07-17 12:45:12 [32271] [36] DEBUG:   command_status: 0 = 0x
 2014-07-17 12:45:12 [32271] [36] DEBUG:   sequence_number: 5579 =
 0x15cb
 2014-07-17 12:45:12 [32271] [36] DEBUG:   message_id: 1e13a15
 2014-07-17 12:45:12 [32271] [36] DEBUG: SMPP PDU dump ends.
 2014-07-17 12:45:12 [32271] [36] DEBUG: DLR[internal]: Adding DLR
 smsc=SMSC1, ts=31537685, src=30100, dst=XXX, mask=31, boxc=
 2014-07-17 12:45:12 [32271] [36] DEBUG: SMSC[SMSC1]: creating DLR message

 Message ID is 31537685 in submit_sm.

 In deliver_sm it's:
 2014-07-17 12:45:16 [32271] [35] DEBUG:   short_message:
 2014-07-17 12:45:16 [32271] [35] DEBUG:Octet string at 0x11f4cf80:
 2014-07-17 12:45:16 [32271] [35] DEBUG:  len:  119
 2014-07-17 12:45:16 [32271] [35] DEBUG:  size: 120
 2014-07-17 12:45:16 [32271] [35] DEBUG:  immutable: 0
 2014-07-17 12:45:16 [32271] [35] DEBUG:  data: 69 64 3a 30 30 33 31 35
 33 37 36 38 35 20 73 75   id:0031537685 su
 2014-07-17 12:45:16 [32271] [35] DEBUG:  data: 62 3a 30 30 31 20 64 6c
 76 72 64 3a 30 30 31 20   b:001 dlvrd:001
 2014-07-17 12:45:16 [32271] [35] DEBUG:  data: 73 75 62 6d 69 74 20 64
 61 74 65 3a 31 34 30 37   submit date:1407
 2014-07-17 12:45:16 [32271] [35] DEBUG:  data: 31 37 31 32 34 35 20 64
 6f 6e 65 20 64 61 74 65   171245 done date
 2014-07-17 12:45:16 [32271] [35] DEBUG:  data: 3a 31 34 30 37 31 37 31
 32 34 35 20 73 74 61 74   :1407171245 stat
 2014-07-17 12:45:16 [32271] [35] DEBUG:  data: 3a 44 45 4c 49 56 52 44
 20 65 72 72 3a 30 30 30   :DELIVRD err:000
 2014-07-17 12:45:16 [32271] [35] DEBUG:  data: 20 74 65 78 74 3a 6d 65
 6e 73 61 6a 65 20 64 65text:test messa
 2014-07-17 12:45:16 [32271] [35] DEBUG:  data: 20 70 72 75 65 62 61
 ge 000
 2014-07-17 12:45:16 [32271] [35] DEBUG:Octet string dump ends.
 2014-07-17 12:45:16 [32271] [35] DEBUG:   message_state: 2 = 0x0002
 2014-07-17 12:45:16 [32271] [35] DEBUG:   receipted_message_id: 2496a396

 In msg-log it says:  id:0031537685 so it must be either kannel converting
 it to hex for some reason or maybe some SMSC bug.
 I can't seem to be able to get hex number from source id so it must be
 something either at your operator side or something.

 What is the kannel version you're using? And show your configuration.


 2014-07-19 1:16 GMT+04:00 Mario Noboa mnobo...@gmail.com:

 Thanks your answer Spameden. I thought the same thing, but the message ids
 are complete different:

 if you see the log:

 submit_sm_resp: message_id: 31537685   (decimal)
 deliver_sm:   ts=613852054   (decimal)

 regards,



 2014-07-18 16:04 GMT-05:00 spameden spame...@gmail.com:

 err, I meant hex in submit_sm and decimal in deliver_sm packets.


  2014-07-19 1:04 GMT+04:00 spameden spame...@gmail.com:

 It looks like your SMSC operator gives hex number in submit_sm packet
 and hex number in deliver_sm, so you need to add this in smsc group
 configuration:

 msg-id-type = 0x02



 2014-07-19 0:40 GMT+04:00 Mario Noboa mnobo...@gmail.com:

 Of course Niel, thanks!!!




 2014-07-18 15:30 GMT-05:00 Niel Smith daniel.alfred.sm...@gmail.com:

 Hi Mario,

 Would it be possible to supply the full submit_sm, submit_sm_resp,
 and deliver_sm PDU dumps?


 On 18 July 2014 22:12, Mario Noboa mnobo...@gmail.com wrote:


 Hi list,

 I got a DLR problem with an operator.

 When sent a submit_sm, kannel receipt a message id:

 *message_id: 1e13a15*
 *DLR[internal]: Adding DLR smsc=SMSC1, ts=31537685, src=30100,
 dst=XXX, mask=31, boxc=*


 But its DLR arrives with another id:

 *2014-07-17 12:45:16 [32271] [35] DEBUG: DLR[internal]: Looking for
 DLR smsc=SMSC1, ts=613852054, dst=975647918, type=1*
 *2014-07-17 12:45:16 [32271] [35] WARNING: DLR[internal]: DLR from
 SMSCSMSC1 for DST975647918 not found.*
 *2014-07-17

Re: DLR does not match message id

Try commenting out completely msg-id-type if it would be the same means its
something you need to settle down with your SMSC operator.


2014-07-19 2:13 GMT+04:00 Mario Noboa mnobo...@gmail.com:

 You're right the message id is in short_message but it should be in
 receipted_message_id. It's a bug of the operator, but they told me that
 they can't do any change.

 That's why I asked to use the timestamp  :)

 Here is my config (it tried msg-id-type = 2 but didn't work):

 #Rx SMSC1
 group = smsc
 smsc = smpp
 smsc-id = SMSC1
 host = X.X.X.X
 port = 0
 receive-port = 1
 smsc-username = esystem
 smsc-password = psystem
 system-type =
 interface-version = 34
 throughput=20
 msg-id-type = 1
 allowed-smsc-id = SMSC1


 #Tx SMSC1
 group = smsc
 smsc = smpp
 smsc-id = SMSC1
 host = X.X.X.X
 port = 1
 receive-port = 0
 smsc-username = esystem
 smsc-password = psystem
 system-type =
 interface-version = 34
 throughput=20
 msg-id-type = 1
 log-level = 0
 allowed-smsc-id = SMSC1

 Thanks!


 2014-07-18 16:35 GMT-05:00 spameden spame...@gmail.com:

 Actually, I've just looked at your logs again:

 2014-07-17 12:45:12 [32271] [36] DEBUG: SMPP[SMSC1]: Got PDU:
 2014-07-17 12:45:12 [32271] [36] DEBUG: SMPP PDU 0x11f4cb80 dump:
 2014-07-17 12:45:12 [32271] [36] DEBUG:   type_name: submit_sm_resp
 2014-07-17 12:45:12 [32271] [36] DEBUG:   command_id: 2147483652 =
 0x8004
 2014-07-17 12:45:12 [32271] [36] DEBUG:   command_status: 0 = 0x
 2014-07-17 12:45:12 [32271] [36] DEBUG:   sequence_number: 5579 =
 0x15cb
 2014-07-17 12:45:12 [32271] [36] DEBUG:   message_id: 1e13a15
 2014-07-17 12:45:12 [32271] [36] DEBUG: SMPP PDU dump ends.
 2014-07-17 12:45:12 [32271] [36] DEBUG: DLR[internal]: Adding DLR
 smsc=SMSC1, ts=31537685, src=30100, dst=XXX, mask=31, boxc=
 2014-07-17 12:45:12 [32271] [36] DEBUG: SMSC[SMSC1]: creating DLR message

 Message ID is 31537685 in submit_sm.

 In deliver_sm it's:
 2014-07-17 12:45:16 [32271] [35] DEBUG:   short_message:
 2014-07-17 12:45:16 [32271] [35] DEBUG:Octet string at 0x11f4cf80:
 2014-07-17 12:45:16 [32271] [35] DEBUG:  len:  119
 2014-07-17 12:45:16 [32271] [35] DEBUG:  size: 120
 2014-07-17 12:45:16 [32271] [35] DEBUG:  immutable: 0
 2014-07-17 12:45:16 [32271] [35] DEBUG:  data: 69 64 3a 30 30 33 31
 35 33 37 36 38 35 20 73 75   id:0031537685 su
 2014-07-17 12:45:16 [32271] [35] DEBUG:  data: 62 3a 30 30 31 20 64
 6c 76 72 64 3a 30 30 31 20   b:001 dlvrd:001
 2014-07-17 12:45:16 [32271] [35] DEBUG:  data: 73 75 62 6d 69 74 20
 64 61 74 65 3a 31 34 30 37   submit date:1407
 2014-07-17 12:45:16 [32271] [35] DEBUG:  data: 31 37 31 32 34 35 20
 64 6f 6e 65 20 64 61 74 65   171245 done date
 2014-07-17 12:45:16 [32271] [35] DEBUG:  data: 3a 31 34 30 37 31 37
 31 32 34 35 20 73 74 61 74   :1407171245 stat
 2014-07-17 12:45:16 [32271] [35] DEBUG:  data: 3a 44 45 4c 49 56 52
 44 20 65 72 72 3a 30 30 30   :DELIVRD err:000
 2014-07-17 12:45:16 [32271] [35] DEBUG:  data: 20 74 65 78 74 3a 6d
 65 6e 73 61 6a 65 20 64 65text:test messa
 2014-07-17 12:45:16 [32271] [35] DEBUG:  data: 20 70 72 75 65 62 61
 ge 000
 2014-07-17 12:45:16 [32271] [35] DEBUG:Octet string dump ends.
 2014-07-17 12:45:16 [32271] [35] DEBUG:   message_state: 2 = 0x0002
 2014-07-17 12:45:16 [32271] [35] DEBUG:   receipted_message_id: 2496a396

 In msg-log it says:  id:0031537685 so it must be either kannel
 converting it to hex for some reason or maybe some SMSC bug.
 I can't seem to be able to get hex number from source id so it must be
 something either at your operator side or something.

 What is the kannel version you're using? And show your configuration.


 2014-07-19 1:16 GMT+04:00 Mario Noboa mnobo...@gmail.com:

 Thanks your answer Spameden. I thought the same thing, but the message
 ids are complete different:

 if you see the log:

 submit_sm_resp: message_id: 31537685   (decimal)
 deliver_sm:   ts=613852054   (decimal)

 regards,



 2014-07-18 16:04 GMT-05:00 spameden spame...@gmail.com:

 err, I meant hex in submit_sm and decimal in deliver_sm packets.


  2014-07-19 1:04 GMT+04:00 spameden spame...@gmail.com:

 It looks like your SMSC operator gives hex number in submit_sm packet
 and hex number in deliver_sm, so you need to add this in smsc group
 configuration:

 msg-id-type = 0x02



 2014-07-19 0:40 GMT+04:00 Mario Noboa mnobo...@gmail.com:

 Of course Niel, thanks!!!




 2014-07-18 15:30 GMT-05:00 Niel Smith daniel.alfred.sm...@gmail.com
 :

 Hi Mario,

 Would it be possible to supply the full submit_sm, submit_sm_resp,
 and deliver_sm PDU dumps?


 On 18 July 2014 22:12, Mario Noboa mnobo...@gmail.com wrote:


 Hi list,

 I got a DLR problem with an operator.

 When sent a submit_sm, kannel receipt a message id:

 *message_id: 1e13a15*
 *DLR[internal]: Adding DLR smsc=SMSC1, ts=31537685, src=30100,
 dst=XXX, mask=31, boxc=*


 But its DLR arrives with another id:

 *2014-07-17

Re: dlr-mask not on the url

2014-07-08 Thread bhavya

Hi,

There are one more question regarding DLR, i.e its not working while sending
ota means not work with 
cgi-bin/sendota URL.

Please tell me the solution !!!


Regards,
Bhavya



--
View this message in context: 
http://kannel.6189.n7.nabble.com/dlr-mask-not-on-the-url-tp13529p30315.html
Sent from the Kannel - User mailing list archive at Nabble.com.

Re: DLR injected by http smsc are stucked in kannel's queue

2014-07-07 Thread sharkov...@gmail.com

Hi guys,

Can anyone give any hints on how to resolve this problem.
I'm trying to implement a solution but DLR are crucial and don't seem to
work ok.

Is there maybe a way to inject the dlrs directly to SQLBox instead of
sending them to http smsc?




On Thu, Jul 3, 2014 at 2:33 PM, sharkov...@gmail.com sharkov...@gmail.com
wrote:

 Hi all,

 I have the following setup:

 SMPP Client = OpenSMPPBox = SQLBox = BearerBox = http smsc

 so i'm sending messages from the SMPP client to OpenSMPPbox and those
 messages are routed to http smsc (generic) to my php scripts.
 I am then injecting the DLR to the http smsc and the DLR comes back to
 SMPP client.

 If i don't sent to many messages, it's working great.
 If i sent 1000 messages then at least half of them are stucked in Kannel's
 Queue and in opensmpp's mysql table.
 If i restart openSMPPbox then almost all (but not all) are then being
 rerouted back to the smpp client.

 I'm running the latest versions from the svn repository.

 Can anyone give me some help?

RE: DLR with SendOTA

2014-07-05 Thread bhavya

Hi,Its very much important to me for receiving delivery report while
sending OTA.I have tried with dlr-url and dlr-mask defined with sendsms
url , and its working finebut not working in case of send ota.If
this is a bug then please resolve it as soon as possible. or any other way
to retrieve delivery reportusing sendota url.Thanks in advance
Regards,Bhavya  



--
View this message in context: 
http://kannel.6189.n7.nabble.com/Fwd-DLR-with-SendOTA-tp27933p30306.html
Sent from the Kannel - User mailing list archive at Nabble.com.

Re: DLR Reports

2014-06-26 Thread [Digital^Dude] ®

What's your dlr-mask?
And this may be an operator specific issue as they might only have allowed
one retry per submit_sm from the ESME hence not allowing any messages from
your end to be buffered.
On Jun 26, 2014 3:32 PM, Michael Stevens michael.stev...@mcmcas.co.za
wrote:

 Hi..

 OS: Linux
 Kannel Version: 1.50

 I use a gsm modem with dlr reports. I receive the ACK, Ack Failed, Success
 dlr.'s but not the buffered dlr when the phone where I am sending the
 message is offline.
 Any ideas?

Re: DLR ERROR

2014-05-22 Thread Alvaro Cornejo

Hi

dlr-url must be an url. why did you declare it as an integer?

should be something like:

...dlr-url=urlencode(http://myhost/mypath/myscript.php?x)...

dlr-url is the url kannel calls for delivering the message status
notifications (dlr)

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.com


On Thu, May 22, 2014 at 6:45 AM, خان ابو زید khan.abuz...@gmail.com wrote:
 Hi,

 dlr-url = integer value

 http://127.0.0.1:12013/cgi-bin/sendsms?username=abuzaiddlr-url=1245charset=utf-8from=UPDATEto=9664541886dlr-mask=31text=test+smssmsc=smsc001password=TESTcoding=0

 Getting Error:

 Status: 400 Answer: DLR-URL field misformed, rejected

 --
 Regards

 Khan Abuzaid
 Mob# :09664541886/9594092200
 Mumbai

Re: DLR ERROR

2014-05-22 Thread خان ابو زید

Using sqlbox no error, but in smsbox getting error.

i want to update message status in other table map with id(integer)  that
why using integer not url.


On Thu, May 22, 2014 at 7:14 AM, Alvaro Cornejo cornejo.alv...@gmail.comwrote:

 Hi

 dlr-url must be an url. why did you declare it as an integer?

 should be something like:

 ...dlr-url=urlencode(http://myhost/mypath/myscript.php?x)...

 dlr-url is the url kannel calls for delivering the message status
 notifications (dlr)

 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.com


 On Thu, May 22, 2014 at 6:45 AM, خان ابو زید khan.abuz...@gmail.com
 wrote:
  Hi,
 
  dlr-url = integer value
 
 
 http://127.0.0.1:12013/cgi-bin/sendsms?username=abuzaiddlr-url=1245charset=utf-8from=UPDATEto=9664541886dlr-mask=31text=test+smssmsc=smsc001password=TESTcoding=0
 
  Getting Error:
 
  Status: 400 Answer: DLR-URL field misformed, rejected
 
  --
  Regards
 
  Khan Abuzaid
  Mob# :09664541886/9594092200
  Mumbai




-- 
Regards

Khan Abuzaid
Mob# :09664541886/9594092200
Mumbai

Re: DLR ERROR

2014-05-22 Thread Alvaro Cornejo

Then you need to use your own app to do that.

dlr-ulr, by definition --and validated by smsbox-- is an url. that is
why you get the malformed error. An integer in not a url.

What you need to do is create a script you can call by http and pass
your id like

...dlr-url=urlencode(http://myhost/mypath/mydlrscript.php?myid=12345)...

Then your mydlrscript.php will update the required table as needed.
BTW you might want to add some of the parameters available so you get
more detailed info.

Don't know sqlbox but I assume it does not validate that the dlr-url
field is actually an url

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.com

On Thu, May 22, 2014 at 2:23 PM, خان ابو زید khan.abuz...@gmail.com wrote:
Using sqlbox no error, but in smsbox getting error.

i want to update message status in other table map with id(integer) that
why using integer not url.

On Thu, May 22, 2014 at 7:14 AM, Alvaro Cornejo cornejo.alv...@gmail.com
wrote:

dlr-url must be an url. why did you declare it as an integer?

should be something like:

...dlr-url=urlencode(http://myhost/mypath/myscript.php?x)...

dlr-url is the url kannel calls for delivering the message status
notifications (dlr)

Regards

Alvaro

On Thu, May 22, 2014 at 6:45 AM, خان ابو زید khan.abuz...@gmail.com
wrote:
Hi,

dlr-url = integer value

http://127.0.0.1:12013/cgi-bin/sendsms?username=abuzaiddlr-url=1245charset=utf-8from=UPDATEto=9664541886dlr-mask=31text=test+smssmsc=smsc001password=TESTcoding=0

Getting Error:

Status: 400 Answer: DLR-URL field misformed, rejected

--
Regards

Khan Abuzaid
Mob# :09664541886/9594092200
Mumbai

--
Regards

Khan Abuzaid
Mob# :09664541886/9594092200
Mumbai

RE: DLR-URL debugging

2014-04-30 Thread Rene Kluwen

opensmppbox doesn’t trigger any dlr-url’s. You need smsbox for that.

From: users [mailto:users-boun...@kannel.org] On Behalf Of Saurabh Pandey
Sent: woensdag 30 april 2014 8:26
To: users@kannel.org
Subject: DLR-URL debugging

Hi,

I need to debug and check the dlr-url function of Kannel. Here is my situation:

1) When I submit sms through Kannel, dlr-url appended in sendsms request, it 
works fine

2) Earlier I was pushing sms via opensmppbox, there was some issues with 
deliver_sm so smpp client was not getting the DLR but the DLR url defined in 
opensmppbox-dlr-table was working fine

3) Now deliver_sm issue is fixed but dlr-url is not working anymore. I need to 
check why is that happening.

Can somebody guide me how to debug this feature? What file to look at?

Thanks in advance

-Sam

Re: DLR-URL debugging

2014-04-30 Thread Saurabh Pandey

Okay, that's odd, because the URL i defined was being fired. May be it was
a mixup. Here is my setup:

SMSC --- Kannel [Bearerbox+smsbox]  Sqlbox Opensmppbox ---
smpp client

Now I submit SMS via sendsms cgi to smsbox. Sqlbox is just for logging of
messages sent via opensmppbox. Now opensmppbox has its own dlr-table and
that table has a dlr_url field (which stored msgid earlier but now its
storing custom urls). Earlier these URLs were being fired and they were
carrying out the tasks they were supposed to do. But now they stopped.

Anyways, I guess getting into that doesn't seem like a good idea since you
just said that opensmppbox doesn't trigger urls. But I need them triggered
so I'm gonna have to write it myself. So Rene can you help me find where
the code which does this url-translation and trigger dlr-url exists? So I
can take a reference.

Thanks in advance


On Wed, Apr 30, 2014 at 4:34 PM, Rene Kluwen rene.klu...@chimit.nl wrote:

 opensmppbox doesn’t trigger any dlr-url’s. You need smsbox for that.



 *From:* users [mailto:users-boun...@kannel.org] *On Behalf Of *Saurabh
 Pandey
 *Sent:* woensdag 30 april 2014 8:26
 *To:* users@kannel.org
 *Subject:* DLR-URL debugging



 Hi,

 I need to debug and check the dlr-url function of Kannel. Here is my
 situation:

 1) When I submit sms through Kannel, dlr-url appended in sendsms request,
 it works fine

 2) Earlier I was pushing sms via opensmppbox, there was some issues with
 deliver_sm so smpp client was not getting the DLR but the DLR url defined
 in opensmppbox-dlr-table was working fine

 3) Now deliver_sm issue is fixed but dlr-url is not working anymore. I
 need to check why is that happening.

 Can somebody guide me how to debug this feature? What file to look at?

 Thanks in advance

 -Sam

Re: DLR-URL debugging

2014-04-30 Thread Saurabh Pandey

Hi Rene,

I have a very simple question. How do I execute a URL. I have did
everything but if I use Kannel functions (from gwlib/http.h) it results in
panic which I can't seem to trace. I guess I could use libCurl but I don't
want to include anything. When Kannel is already using its functions to
trigger URL, I think I should utilize it.
So my final question is: how do I execute a URL?

My Hints: I think http_get_real(), http_start_request() are the way to go
but they have so many parameters and all those pointers and pointer to
pointers really confuse me. I want a simple URL trigger. Can you please
guide me.

Thanks for all your help.


On Wed, Apr 30, 2014 at 5:00 PM, Saurabh Pandey
sam.it.develo...@gmail.comwrote:

 Okay, that's odd, because the URL i defined was being fired. May be it was
 a mixup. Here is my setup:

 SMSC --- Kannel [Bearerbox+smsbox]  Sqlbox Opensmppbox ---
 smpp client

 Now I submit SMS via sendsms cgi to smsbox. Sqlbox is just for logging of
 messages sent via opensmppbox. Now opensmppbox has its own dlr-table and
 that table has a dlr_url field (which stored msgid earlier but now its
 storing custom urls). Earlier these URLs were being fired and they were
 carrying out the tasks they were supposed to do. But now they stopped.

 Anyways, I guess getting into that doesn't seem like a good idea since you
 just said that opensmppbox doesn't trigger urls. But I need them triggered
 so I'm gonna have to write it myself. So Rene can you help me find where
 the code which does this url-translation and trigger dlr-url exists? So I
 can take a reference.

 Thanks in advance


 On Wed, Apr 30, 2014 at 4:34 PM, Rene Kluwen rene.klu...@chimit.nlwrote:

 opensmppbox doesn’t trigger any dlr-url’s. You need smsbox for that.



 *From:* users [mailto:users-boun...@kannel.org] *On Behalf Of *Saurabh
 Pandey
 *Sent:* woensdag 30 april 2014 8:26
 *To:* users@kannel.org
 *Subject:* DLR-URL debugging



 Hi,

 I need to debug and check the dlr-url function of Kannel. Here is my
 situation:

 1) When I submit sms through Kannel, dlr-url appended in sendsms request,
 it works fine

 2) Earlier I was pushing sms via opensmppbox, there was some issues with
 deliver_sm so smpp client was not getting the DLR but the DLR url defined
 in opensmppbox-dlr-table was working fine

 3) Now deliver_sm issue is fixed but dlr-url is not working anymore. I
 need to check why is that happening.

 Can somebody guide me how to debug this feature? What file to look at?

 Thanks in advance

 -Sam

Re: DLR Only returns status 8 - Please assist

2014-02-20 Thread MOSES KARIUKI

Come on guys, this is not the hardest question ever asked. Is it? Somebody
please assist me!.

Thanks,
Moses


On Wed, Feb 19, 2014 at 12:10 PM, Murgor Bendon bendonmur...@gmail.comwrote:

 He is using fakesms, not yet bound to any SMSC provider yet.




 Best Regards,
 *Bendon Murgor *: Systems Engineer/IT Systems Auditor.
 *Phone*: Kenya:  +254-720529868
 Twitter: @bendonmurgor http://twitter.com/bendonmurgor


 On Wed, Feb 19, 2014 at 12:05 PM, Otandeka Simon Peter 
 sotand...@gmail.com wrote:


 Consult your SMSC provider. They should sort you out on that. It is not a
 kannel issue.


 @sotandeka
 +256 716 801 124
 Senior Programmer in VAS Mobile services, ERP, Health and Web-based
 Systems.
 Experienced Linux System Administrator and Open Source Developer.



 On Wed, Feb 19, 2014 at 12:01 PM, MOSES KARIUKI kariuk...@gmail.comwrote:

 Hi Guys,

 Any help on this request? Please assist.

 Moses


 On Tue, Feb 18, 2014 at 12:11 PM, MOSES KARIUKI kariuk...@gmail.comwrote:

 Hi All,

 I have set up Kannel on Ubuntu. I am testing functionality using
 fakesmsc. Below is the configuration.

 group = core
 admin-port = 13000
 admin-password = bar
 admin-deny-ip = *.*.*.*
 admin-allow-ip = 127.0.0.1
 #wapbox-port = 13002
 smsbox-port = 13001
 wdp-interface-name = *
 log-file = /var/log/kannel/bearerbox.log
 log-level = 0
 box-deny-ip = *.*.*.*
 box-allow-ip = 127.0.0.1
 #dlr-storage = pgsql

 group = smsbox
 bearerbox-host = localhost
 sendsms-port = 13013
 global-sender = 13013
 smsbox-id = box1
 log-file = /var/log/kannel/smsbox.log
 log-level = 0

 group = sendsms-user
 username =
 password =
 dlr-url = 
 http://localhost/kannel/dlr_status.php?d=%pmask=%dmessage_id=%F;

 group = sms-service
 keyword = default
 #get-url = 
 http://localhost/kannel/receivesms.php?sender=%pamp;text=%b;
 accept-x-kannel-headers = true
 concatenation = true
 catch-all = true

 #group = wapbox
 #bearerbox-host = localhost
 #log-file = /var/log/kannel/wapbox.log

 group = smsc
 smsc = fake
 smsc-id = FAKE
 port = 1
 connect-allow-ip = 127.0.0.1
 #msg-id-type = 0x00

 group = pgsql-connection
 id = mydlr
 host = localhost
 port = 5439
 username = kannel_admin
 password = RFID_dev12??
 database = postgres
 max-connections = 1

 group = dlr-db
 id = mydlr
 table = tbl_dlr
 field-smsc = smsc
 field-timestamp = _timstamp
 field-destination = destination
 field-source = source
 field-service = _service
 field-url = url
 field-mask = mask
 field-status = status
 field-boxc-id = boxc_id

 This is the url I am calling to test:

 http://localhost:13013/cgi-bin/sendsms?username=password=to=125345text=testssmsc=FAKEdlr-mask=31

 However, in the table for delivery reports, I am only getting dlr
 report 8. But the message is being sent. it displays 0: Accepted for
 delivery after I call the above url.

 What Im I doing wrong? Please assist.

 Thanks
 Moses

Re: DLR Only returns status 8 - Please assist

2014-02-20 Thread Alejandro Guerrieri

I don't think you'd get any other dlrs from fake smsc. Status 8 is delivered to 
smsc, it's as far s you can get there. Try using an smppbox connection (eg 
against opensmppbox or an smsc simulator).

--
Alex Guerrieri

 On Feb 21, 2014, at 0:39, MOSES KARIUKI kariuk...@gmail.com wrote:
 
 Come on guys, this is not the hardest question ever asked. Is it? Somebody 
 please assist me!.
 
 Thanks,
 Moses
 
 
 On Wed, Feb 19, 2014 at 12:10 PM, Murgor Bendon bendonmur...@gmail.com 
 wrote:
 He is using fakesms, not yet bound to any SMSC provider yet.
 
 
 
 
 Best Regards,
 Bendon Murgor : Systems Engineer/IT Systems Auditor.
 Phone: Kenya:  +254-720529868
 Twitter: @bendonmurgor
 
 
 On Wed, Feb 19, 2014 at 12:05 PM, Otandeka Simon Peter 
 sotand...@gmail.com wrote:
 
 Consult your SMSC provider. They should sort you out on that. It is not a 
 kannel issue. 
 
 
 @sotandeka
 +256 716 801 124
 Senior Programmer in VAS Mobile services, ERP, Health and Web-based Systems.
 Experienced Linux System Administrator and Open Source Developer. 
 
 
 
 On Wed, Feb 19, 2014 at 12:01 PM, MOSES KARIUKI kariuk...@gmail.com 
 wrote:
 Hi Guys,
 
 Any help on this request? Please assist.
 
 Moses
 
 
 On Tue, Feb 18, 2014 at 12:11 PM, MOSES KARIUKI kariuk...@gmail.com 
 wrote:
 Hi All,
 
 I have set up Kannel on Ubuntu. I am testing functionality using 
 fakesmsc. Below is the configuration.
 
 group = core
 admin-port = 13000
 admin-password = bar
 admin-deny-ip = *.*.*.*
 admin-allow-ip = 127.0.0.1
 #wapbox-port = 13002
 smsbox-port = 13001
 wdp-interface-name = *
 log-file = /var/log/kannel/bearerbox.log
 log-level = 0
 box-deny-ip = *.*.*.*
 box-allow-ip = 127.0.0.1
 #dlr-storage = pgsql
 
 group = smsbox
 bearerbox-host = localhost
 sendsms-port = 13013
 global-sender = 13013
 smsbox-id = box1
 log-file = /var/log/kannel/smsbox.log
 log-level = 0
 
 group = sendsms-user
 username =
 password =
 dlr-url = 
 http://localhost/kannel/dlr_status.php?d=%pmask=%dmessage_id=%F;
 
 group = sms-service
 keyword = default
 #get-url = http://localhost/kannel/receivesms.php?sender=%pamp;text=%b;
 accept-x-kannel-headers = true
 concatenation = true
 catch-all = true
 
 #group = wapbox
 #bearerbox-host = localhost
 #log-file = /var/log/kannel/wapbox.log
 
 group = smsc
 smsc = fake
 smsc-id = FAKE
 port = 1
 connect-allow-ip = 127.0.0.1
 #msg-id-type = 0x00
 
 group = pgsql-connection
 id = mydlr
 host = localhost
 port = 5439
 username = kannel_admin
 password = RFID_dev12??
 database = postgres
 max-connections = 1
 
 group = dlr-db
 id = mydlr
 table = tbl_dlr
 field-smsc = smsc
 field-timestamp = _timstamp
 field-destination = destination
 field-source = source
 field-service = _service
 field-url = url
 field-mask = mask
 field-status = status
 field-boxc-id = boxc_id
 
 This is the url I am calling to test:
 http://localhost:13013/cgi-bin/sendsms?username=password=to=125345text=testssmsc=FAKEdlr-mask=31
 
 However, in the table for delivery reports, I am only getting dlr report 
 8. But the message is being sent. it displays 0: Accepted for delivery 
 after I call the above url.
 
 What Im I doing wrong? Please assist.
 
 Thanks
 Moses

Re: DLR Only returns status 8 - Please assist

2014-02-19 Thread MOSES KARIUKI

Hi Guys,

Any help on this request? Please assist.

Moses


On Tue, Feb 18, 2014 at 12:11 PM, MOSES KARIUKI kariuk...@gmail.com wrote:

 Hi All,

 I have set up Kannel on Ubuntu. I am testing functionality using fakesmsc.
 Below is the configuration.

 group = core
 admin-port = 13000
 admin-password = bar
 admin-deny-ip = *.*.*.*
 admin-allow-ip = 127.0.0.1
 #wapbox-port = 13002
 smsbox-port = 13001
 wdp-interface-name = *
 log-file = /var/log/kannel/bearerbox.log
 log-level = 0
 box-deny-ip = *.*.*.*
 box-allow-ip = 127.0.0.1
 #dlr-storage = pgsql

 group = smsbox
 bearerbox-host = localhost
 sendsms-port = 13013
 global-sender = 13013
 smsbox-id = box1
 log-file = /var/log/kannel/smsbox.log
 log-level = 0

 group = sendsms-user
 username =
 password =
 dlr-url = 
 http://localhost/kannel/dlr_status.php?d=%pmask=%dmessage_id=%F;

 group = sms-service
 keyword = default
 #get-url = http://localhost/kannel/receivesms.php?sender=%pamp;text=%b;
 accept-x-kannel-headers = true
 concatenation = true
 catch-all = true

 #group = wapbox
 #bearerbox-host = localhost
 #log-file = /var/log/kannel/wapbox.log

 group = smsc
 smsc = fake
 smsc-id = FAKE
 port = 1
 connect-allow-ip = 127.0.0.1
 #msg-id-type = 0x00

 group = pgsql-connection
 id = mydlr
 host = localhost
 port = 5439
 username = kannel_admin
 password = RFID_dev12??
 database = postgres
 max-connections = 1

 group = dlr-db
 id = mydlr
 table = tbl_dlr
 field-smsc = smsc
 field-timestamp = _timstamp
 field-destination = destination
 field-source = source
 field-service = _service
 field-url = url
 field-mask = mask
 field-status = status
 field-boxc-id = boxc_id

 This is the url I am calling to test:

 http://localhost:13013/cgi-bin/sendsms?username=password=to=125345text=testssmsc=FAKEdlr-mask=31

 However, in the table for delivery reports, I am only getting dlr report
 8. But the message is being sent. it displays 0: Accepted for delivery
 after I call the above url.

 What Im I doing wrong? Please assist.

 Thanks
 Moses

Re: DLR Only returns status 8 - Please assist

2014-02-19 Thread Otandeka Simon Peter

Consult your SMSC provider. They should sort you out on that. It is not a
kannel issue.


@sotandeka
+256 716 801 124
Senior Programmer in VAS Mobile services, ERP, Health and Web-based Systems.
Experienced Linux System Administrator and Open Source Developer.



On Wed, Feb 19, 2014 at 12:01 PM, MOSES KARIUKI kariuk...@gmail.com wrote:

 Hi Guys,

 Any help on this request? Please assist.

 Moses


 On Tue, Feb 18, 2014 at 12:11 PM, MOSES KARIUKI kariuk...@gmail.comwrote:

 Hi All,

 I have set up Kannel on Ubuntu. I am testing functionality using
 fakesmsc. Below is the configuration.

 group = core
 admin-port = 13000
 admin-password = bar
 admin-deny-ip = *.*.*.*
 admin-allow-ip = 127.0.0.1
 #wapbox-port = 13002
 smsbox-port = 13001
 wdp-interface-name = *
 log-file = /var/log/kannel/bearerbox.log
 log-level = 0
 box-deny-ip = *.*.*.*
 box-allow-ip = 127.0.0.1
 #dlr-storage = pgsql

 group = smsbox
 bearerbox-host = localhost
 sendsms-port = 13013
 global-sender = 13013
 smsbox-id = box1
 log-file = /var/log/kannel/smsbox.log
 log-level = 0

 group = sendsms-user
 username =
 password =
 dlr-url = 
 http://localhost/kannel/dlr_status.php?d=%pmask=%dmessage_id=%F;

 group = sms-service
 keyword = default
 #get-url = http://localhost/kannel/receivesms.php?sender=%pamp;text=%b;
 accept-x-kannel-headers = true
 concatenation = true
 catch-all = true

 #group = wapbox
 #bearerbox-host = localhost
 #log-file = /var/log/kannel/wapbox.log

 group = smsc
 smsc = fake
 smsc-id = FAKE
 port = 1
 connect-allow-ip = 127.0.0.1
 #msg-id-type = 0x00

 group = pgsql-connection
 id = mydlr
 host = localhost
 port = 5439
 username = kannel_admin
 password = RFID_dev12??
 database = postgres
 max-connections = 1

 group = dlr-db
 id = mydlr
 table = tbl_dlr
 field-smsc = smsc
 field-timestamp = _timstamp
 field-destination = destination
 field-source = source
 field-service = _service
 field-url = url
 field-mask = mask
 field-status = status
 field-boxc-id = boxc_id

 This is the url I am calling to test:

 http://localhost:13013/cgi-bin/sendsms?username=password=to=125345text=testssmsc=FAKEdlr-mask=31

 However, in the table for delivery reports, I am only getting dlr report
 8. But the message is being sent. it displays 0: Accepted for delivery
 after I call the above url.

 What Im I doing wrong? Please assist.

 Thanks
 Moses

Re: DLR: received showing 0 in kannel status page

Hi all,

Any one faced this issue before?

Sorry just curious to know .

Thanks,
KRNRDB

On Thursday, January 23, 2014, krnrd b krn...@gmail.com wrote:

 Hi all,

 I am using kannel 1.5.0 devel version. When i use Tx and Rx separated
 while connecting SMSC now problem is when submit_sm happening message
 delivered to handset and sms sent as 1 on kannel status page and showing
 properly for Tx connection but when i receiving DLR on Rx connection it's
 showing DLR: received 0 on kannel status page but dlr's coming properly on
 kannel logs.

 Please suggest me why dlr's showing on kannel log but not showing on
 kannel status page.

 Please find the attached kannel status page.

Kannel bearerbox version `1.5.0'. Build `Jan 15 2014 15:56:30',
 compiler `4.1.2 20070626 (Red Hat 4.1.2-14)'. System Linux, release
 2.6.18-53.el5, version
#1 SMP Wed Oct 10 16:34:19 EDT 2007, machine x86_64. Hostname Blade1,
 IP 172.16.8.206. Libxml version 2.6.26. Using OpenSSL 0.9.8b 04 May 2006.
 Compiled
with MySQL 5.1.35, using MySQL 5.1.35. Using native malloc.

Status: running, uptime 0d 0h 1m 15s

WDP: received 0 (0 queued), sent 0 (0 queued)

SMS: received 0 (0 queued), sent 1 (0 queued), store size 0
SMS: inbound (0.00,0.00,0.00) msg/sec, outbound (0.02,0.01,0.01) msg/sec

DLR: received 0, sent 0
DLR: inbound (0.00,0.00,0.00) msg/sec, outbound (0.00,0.00,0.00) msg/sec
DLR: 19 queued, using mysql storage

Box connections:
smsbox:(none), IP 127.0.0.1 (0 queued), (on-line 0d 0h 1m 4s)

SMSC connections:
RND-1[RND-1]SMPP:xxx.xxx.xxx.xxx:2161/0:TestAT:SMPP_RND (online
 72s, rcvd: sms 0 / dlr 0, sent: sms 1 / dlr 0, failed 0, queued 0 msgs)
RND-1-Rx[RND-1-Rx]SMPP:xxx.xxx.xxx.xxx:0/2161:TestAT:SMPP_RND
 (online 73s, rcvd: sms 0 / dlr 0, sent: sms 0 / dlr 0, failed 0, queued 0
 msgs)


 PDU :

 Tx
 -

 2014-01-23 11:12:17 [20558] [6] DEBUG: SMPP[RND-1]: throughput (0.00,1.00)
 2014-01-23 11:12:17 [20558] [6] DEBUG: SMPP[RND-1]: Sending PDU:
 2014-01-23 11:12:17 [20558] [6] DEBUG: SMPP PDU 0x2c000a80 dump:
 2014-01-23 11:12:17 [20558] [6] DEBUG:   type_name: submit_sm
 2014-01-23 11:12:17 [20558] [6] DEBUG:   command_id: 4 = 0x0004
 2014-01-23 11:12:17 [20558] [6] DEBUG:   command_status: 0 = 0x
 2014-01-23 11:12:17 [20558] [6] DEBUG:   sequence_number: 2 = 0x0002
 2014-01-23 11:12:17 [20558] [6] DEBUG:   service_type: NULL
 2014-01-23 11:12:17 [20558] [6] DEBUG:   source_addr_ton: 5 = 0x0005
 2014-01-23 11:12:17 [20558] [6] DEBUG:   source_addr_npi: 0 = 0x
 2014-01-23 11:12:17 [20558] [6] DEBUG:   source_addr: 
 2014-01-23 11:12:17 [20558] [6] DEBUG:   dest_addr_ton: 2 = 0x0002
 2014-01-23 11:12:17 [20558] [6] DEBUG:   dest_addr_npi: 1 = 0x0001
 2014-01-23 11:12:17 [20558] [6] DEBUG:   destination_addr: 
 2014-01-23 11:12:17 [20558] [6] DEBUG:   esm_class: 3 = 0x0003
 2014-01-23 11:12:17 [20558] [6] DEBUG:   protocol_id: 0 = 0x
 2014-01-23 11:12:17 [20558] [6] DEBUG:   priority_flag: 0 = 0x
 2014-01-23 11:12:17 [20558] [6] DEBUG:   schedule_delivery_time: NULL
 2014-01-23 11:12:17 [20558] [6] DEBUG:   validity_period: NULL
 2014-01-23 11:12:17 [20558] [6] DEBUG:   registered_delivery: 1 =
 0x0001
 2014-01-23 11:12:17 [20558] [6] DEBUG:   replace_if_present_flag: 0 =
 0x
 2014-01-23 11:12:17 [20558] [6] DEBUG:   data_coding: 0 = 0x
 2014-01-23 11:12:17 [20558] [6] DEBUG:   sm_default_msg_id: 0 = 0x
 2014-01-23 11:12:17 [20558] [6] DEBUG:   sm_length: 16 = 0x0010
 2014-01-23 11:12:17 [20558] [6] DEBUG:   short_message: Testing from RnD
 2014-01-23 11:12:17 [20558] [6] DEBUG: SMPP PDU dump ends.


 Rx
 
 2014-01-23 11:12:59 [20558] [7] DEBUG: SMPP[RND-1-Rx]: Got PDU:
 2014-01-23 11:12:59 [20558] [7] DEBUG: SMPP PDU 0x1e909800 dump:
 2014-01-23 11:12:59 [20558] [7] DEBUG:   type_name: deliver_sm
 2014-01-23 11:12:59 [20558] [7] DEBUG:   command_id: 5 = 0x0005
 2014-01-23 11:12:59 [20558] [7] DEBUG:   command_status: 0 = 0x
 2014-01-23 11:12:59 [20558] [7] DEBUG:   sequence_number: 647515690 =
 0x26984e2a
 2014-01-23 11:12:59 [20558] [7] DEBUG:   service_type: NULL
 2014-01-23 11:12:59 [20558] [7] DEBUG:   source_addr_ton: 0 = 0x
 2014-01-23 11:12:59 [20558] [7] DEBUG:   source_addr_npi: 0 = 0x
 2014-01-23 11:12:59 [20558] [7] DEBUG:   source_addr: 
 2014-01-23 11:12:59 [20558] [7] DEBUG:   dest_addr_ton: 0 = 0x
 2014-01-23 11:12:59 [20558] [7] DEBUG:   dest_addr_npi: 0 = 0x
 2014-01-23 11:12:59 [20558] [7] DEBUG:   destination_addr: 
 2014-01-23 11:12:59 [20558] [7] DEBUG:   esm_class: 4 = 0x0004
 2014-01-23 11:12:59 [20558] [7] DEBUG:   protocol_id: 0 = 0x
 2014-01-23 11:12:59 [20558] [7] DEBUG:   priority_flag: 0 = 0x
 2014-01-23 11:12:59 [20558] [7] DEBUG:   schedule_delivery_time: NULL
 2014-01-23 11:12:59 [20558] [7] DEBUG:   validity_period: NULL

RE: DLR: received showing 0 in kannel status page

2014-01-23 Thread Ciaran Scolard

Currently the Tx and Rx binds are named RND-1 and RND-1-Rx.
Wouldn't the SMPP binds have to be named the same for the DLR/ID matching to 
work?

From: users [mailto:users-boun...@kannel.org] On Behalf Of krnrd b
Sent: 23 January 2014 12:22
To: users
Subject: Re: DLR: received showing 0 in kannel status page

Hi all,

Any one faced this issue before?

Sorry just curious to know .

Thanks,
KRNRDB

On Thursday, January 23, 2014, krnrd b 
krn...@gmail.commailto:krn...@gmail.com wrote:
Hi all,

I am using kannel 1.5.0 devel version. When i use Tx and Rx separated while 
connecting SMSC now problem is when submit_sm happening message delivered to 
handset and sms sent as 1 on kannel status page and showing properly for Tx 
connection but when i receiving DLR on Rx connection it's showing DLR: received 
0 on kannel status page but dlr's coming properly on kannel logs.

Please suggest me why dlr's showing on kannel log but not showing on kannel 
status page.

Please find the attached kannel status page.

   Kannel bearerbox version `1.5.0'. Build `Jan 15 2014 15:56:30', compiler 
`4.1.2 20070626 (Red Hat 4.1.2-14)'. System Linux, release 2.6.18-53.el5, 
version
   #1 SMP Wed Oct 10 16:34:19 EDT 2007, machine x86_64. Hostname Blade1, IP 
172.16.8.206. Libxml version 2.6.26. Using OpenSSL 0.9.8b 04 May 2006. Compiled
   with MySQL 5.1.35, using MySQL 5.1.35. Using native malloc.

   Status: running, uptime 0d 0h 1m 15s

   WDP: received 0 (0 queued), sent 0 (0 queued)

   SMS: received 0 (0 queued), sent 1 (0 queued), store size 0
   SMS: inbound (0.00,0.00,0.00) msg/sec, outbound (0.02,0.01,0.01) msg/sec

   DLR: received 0, sent 0
   DLR: inbound (0.00,0.00,0.00) msg/sec, outbound (0.00,0.00,0.00) msg/sec
   DLR: 19 queued, using mysql storage

   Box connections:
   smsbox:(none), IP 127.0.0.1 (0 queued), (on-line 0d 0h 1m 4s)

   SMSC connections:
   RND-1[RND-1]SMPP:xxx.xxx.xxx.xxx:2161/0:TestAT:SMPP_RND (online 72s, 
rcvd: sms 0 / dlr 0, sent: sms 1 / dlr 0, failed 0, queued 0 msgs)
   RND-1-Rx[RND-1-Rx]SMPP:xxx.xxx.xxx.xxx:0/2161:TestAT:SMPP_RND 
(online 73s, rcvd: sms 0 / dlr 0, sent: sms 0 / dlr 0, failed 0, queued 0 msgs)


PDU :

Tx
-

2014-01-23 11:12:17 [20558] [6] DEBUG: SMPP[RND-1]: throughput (0.00,1.00)
2014-01-23 11:12:17 [20558] [6] DEBUG: SMPP[RND-1]: Sending PDU:
2014-01-23 11:12:17 [20558] [6] DEBUG: SMPP PDU 0x2c000a80 dump:
2014-01-23 11:12:17 [20558] [6] DEBUG:   type_name: submit_sm
2014-01-23 11:12:17 [20558] [6] DEBUG:   command_id: 4 = 0x0004
2014-01-23 11:12:17 [20558] [6] DEBUG:   command_status: 0 = 0x
2014-01-23 11:12:17 [20558] [6] DEBUG:   sequence_number: 2 = 0x0002
2014-01-23 11:12:17 [20558] [6] DEBUG:   service_type: NULL
2014-01-23 11:12:17 [20558] [6] DEBUG:   source_addr_ton: 5 = 0x0005
2014-01-23 11:12:17 [20558] [6] DEBUG:   source_addr_npi: 0 = 0x
2014-01-23 11:12:17 [20558] [6] DEBUG:   source_addr: 
2014-01-23 11:12:17 [20558] [6] DEBUG:   dest_addr_ton: 2 = 0x0002
2014-01-23 11:12:17 [20558] [6] DEBUG:   dest_addr_npi: 1 = 0x0001
2014-01-23 11:12:17 [20558] [6] DEBUG:   destination_addr: 
2014-01-23 11:12:17 [20558] [6] DEBUG:   esm_class: 3 = 0x0003
2014-01-23 11:12:17 [20558] [6] DEBUG:   protocol_id: 0 = 0x
2014-01-23 11:12:17 [20558] [6] DEBUG:   priority_flag: 0 = 0x
2014-01-23 11:12:17 [20558] [6] DEBUG:   schedule_delivery_time: NULL
2014-01-23 11:12:17 [20558] [6] DEBUG:   validity_period: NULL
2014-01-23 11:12:17 [20558] [6] DEBUG:   registered_delivery: 1 = 0x0001
2014-01-23 11:12:17 [20558] [6] DEBUG:   replace_if_present_flag: 0 = 0x
2014-01-23 11:12:17 [20558] [6] DEBUG:   data_coding: 0 = 0x
2014-01-23 11:12:17 [20558] [6] DEBUG:   sm_default_msg_id: 0 = 0x
2014-01-23 11:12:17 [20558] [6] DEBUG:   sm_length: 16 = 0x0010
2014-01-23 11:12:17 [20558] [6] DEBUG:   short_message: Testing from RnD
2014-01-23 11:12:17 [20558] [6] DEBUG: SMPP PDU dump ends.


Rx

2014-01-23 11:12:59 [20558] [7] DEBUG: SMPP[RND-1-Rx]: Got PDU:
2014-01-23 11:12:59 [20558] [7] DEBUG: SMPP PDU 0x1e909800 dump:
2014-01-23 11:12:59 [20558] [7] DEBUG:   type_name: deliver_sm
2014-01-23 11:12:59 [20558] [7] DEBUG:   command_id: 5 = 0x0005
2014-01-23 11:12:59 [20558] [7] DEBUG:   command_status: 0 = 0x
2014-01-23 11:12:59 [20558] [7] DEBUG:   sequence_number: 647515690 = 0x26984e2a
2014-01-23 11:12:59 [20558] [7] DEBUG:   service_type: NULL
2014-01-23 11:12:59 [20558] [7] DEBUG:   source_addr_ton: 0 = 0x
2014-01-23 11:12:59 [20558] [7] DEBUG:   source_addr_npi: 0 = 0x
2014-01-23 11:12:59 [20558] [7] DEBUG:   source_addr: 
2014-01-23 11:12:59 [20558] [7] DEBUG:   dest_addr_ton: 0 = 0x
2014-01-23 11:12:59 [20558] [7] DEBUG:   dest_addr_npi: 0 = 0x
2014-01-23 11:12:59 [20558] [7] DEBUG:   destination_addr: 
2014-01-23 11:12:59 [20558] [7] DEBUG:   esm_class: 4 = 0x0004
2014-01-23 11

Re: DLR: received showing 0 in kannel status page

How would I match DLR/ID ?

for Kannel 1.4.3 I use same configuration incoming and outgoing shows
properly.

Thanks,
KRNRDB


On Thu, Jan 23, 2014 at 7:22 PM, Ciaran Scolard cia...@phonovation.comwrote:

  Currently the Tx and Rx binds are named RND-1 and RND-1-Rx.

 Wouldn’t the SMPP binds have to be named the same for the DLR/ID matching
 to work?



 *From:* users [mailto:users-boun...@kannel.org] *On Behalf Of *krnrd b
 *Sent:* 23 January 2014 12:22
 *To:* users
 *Subject:* Re: DLR: received showing 0 in kannel status page



 Hi all,



 Any one faced this issue before?



 Sorry just curious to know .



 Thanks,

 KRNRDB

 On Thursday, January 23, 2014, krnrd b krn...@gmail.com wrote:

  Hi all,



 I am using kannel 1.5.0 devel version. When i use Tx and Rx separated
 while connecting SMSC now problem is when submit_sm happening message
 delivered to handset and sms sent as 1 on kannel status page and showing
 properly for Tx connection but when i receiving DLR on Rx connection it's
 showing DLR: received 0 on kannel status page but dlr's coming properly on
 kannel logs.



 Please suggest me why dlr's showing on kannel log but not showing on
 kannel status page.



 Please find the attached kannel status page.



Kannel bearerbox version `1.5.0'. Build `Jan 15 2014 15:56:30',
 compiler `4.1.2 20070626 (Red Hat 4.1.2-14)'. System Linux, release
 2.6.18-53.el5, version

#1 SMP Wed Oct 10 16:34:19 EDT 2007, machine x86_64. Hostname Blade1,
 IP 172.16.8.206. Libxml version 2.6.26. Using OpenSSL 0.9.8b 04 May 2006.
 Compiled

with MySQL 5.1.35, using MySQL 5.1.35. Using native malloc.



Status: running, uptime 0d 0h 1m 15s



WDP: received 0 (0 queued), sent 0 (0 queued)



SMS: received 0 (0 queued), sent 1 (0 queued), store size 0

SMS: inbound (0.00,0.00,0.00) msg/sec, outbound (0.02,0.01,0.01) msg/sec



DLR: received 0, sent 0

DLR: inbound (0.00,0.00,0.00) msg/sec, outbound (0.00,0.00,0.00) msg/sec

DLR: 19 queued, using mysql storage



Box connections:

smsbox:(none), IP 127.0.0.1 (0 queued), (on-line 0d 0h 1m 4s)



SMSC connections:

RND-1[RND-1]SMPP:xxx.xxx.xxx.xxx:2161/0:TestAT:SMPP_RND (online
 72s, rcvd: sms 0 / dlr 0, sent: sms 1 / dlr 0, failed 0, queued 0 msgs)

RND-1-Rx[RND-1-Rx]SMPP:xxx.xxx.xxx.xxx:0/2161:TestAT:SMPP_RND
 (online 73s, rcvd: sms 0 / dlr 0, sent: sms 0 / dlr 0, failed 0, queued 0
 msgs)





 PDU :



 Tx

 -



 2014-01-23 11:12:17 [20558] [6] DEBUG: SMPP[RND-1]: throughput (0.00,1.00)

 2014-01-23 11:12:17 [20558] [6] DEBUG: SMPP[RND-1]: Sending PDU:

 2014-01-23 11:12:17 [20558] [6] DEBUG: SMPP PDU 0x2c000a80 dump:

 2014-01-23 11:12:17 [20558] [6] DEBUG:   type_name: submit_sm

 2014-01-23 11:12:17 [20558] [6] DEBUG:   command_id: 4 = 0x0004

 2014-01-23 11:12:17 [20558] [6] DEBUG:   command_status: 0 = 0x

 2014-01-23 11:12:17 [20558] [6] DEBUG:   sequence_number: 2 = 0x0002

 2014-01-23 11:12:17 [20558] [6] DEBUG:   service_type: NULL

 2014-01-23 11:12:17 [20558] [6] DEBUG:   source_addr_ton: 5 = 0x0005

 2014-01-23 11:12:17 [20558] [6] DEBUG:   source_addr_npi: 0 = 0x

 2014-01-23 11:12:17 [20558] [6] DEBUG:   source_addr: 

 2014-01-23 11:12:17 [20558] [6] DEBUG:   dest_addr_ton: 2 = 0x0002

 2014-01-23 11:12:17 [20558] [6] DEBUG:   dest_addr_npi: 1 = 0x0001

 2014-01-23 11:12:17 [20558] [6] DEBUG:   destination_addr: 

 2014-01-23 11:12:17 [20558] [6] DEBUG:   esm_class: 3 = 0x0003

 2014-01-23 11:12:17 [20558] [6] DEBUG:   protocol_id: 0 = 0x

 2014-01-23 11:12:17 [20558] [6] DEBUG:   priority_flag: 0 = 0x

 2014-01-23 11:12:17 [20558] [6] DEBUG:   schedule_delivery_time: NULL

 2014-01-23 11:12:17 [20558] [6] DEBUG:   validity_period: NULL

 2014-01-23 11:12:17 [20558] [6] DEBUG:   registered_delivery: 1 =
 0x0001

 2014-01-23 11:12:17 [20558] [6] DEBUG:   replace_if_present_flag: 0 =
 0x

 2014-01-23 11:12:17 [20558] [6] DEBUG:   data_coding: 0 = 0x

 2014-01-23 11:12:17 [20558] [6] DEBUG:   sm_default_msg_id: 0 = 0x

 2014-01-23 11:12:17 [20558] [6] DEBUG:   sm_length: 16 = 0x0010

 2014-01-23 11:12:17 [20558] [6] DEBUG:   short_message: Testing from RnD

 2014-01-23 11:12:17 [20558] [6] DEBUG: SMPP PDU dump ends.





 Rx

 

 2014-01-23 11:12:59 [20558] [7] DEBUG: SMPP[RND-1-Rx]: Got PDU:

 2014-01-23 11:12:59 [20558] [7] DEBUG: SMPP PDU 0x1e909800 dump:

 2014-01-23 11:12:59 [20558] [7] DEBUG:   type_name: deliver_sm

 2014-01-23 11:12:59 [20558] [7] DEBUG:   command_id: 5 = 0x0005

 2014-01-23 11:12:59 [20558] [7] DEBUG:   command_status: 0 = 0x

 2014-01-23 11:12:59 [20558] [7] DEBUG:   sequence_number: 647515690 =
 0x26984e2a

 2014-01-23 11:12:59 [20558] [7] DEBUG:   service_type: NULL

 2014-01-23 11:12:59 [20558] [7] DEBUG:   source_addr_ton: 0 = 0x

 2014-01-23 11:12:59 [20558] [7] DEBUG:   source_addr_npi: 0

Re: DLR: received showing 0 in kannel status page

I have try to rename RND-1-Rx bind to RND-1 same then dlr received showing
on kannel status page but the serious problem is the dlr's which i am
receiving, kannel sending the same dlr in submit_sm that means on Tx
connection the same delivery report submitted as submit_sm.

But when i use TRx mode kannel performing normally also submit and delivery
repots showing on kannel status page.

separate Tx and Rx binds use to work perfectly on kannel 1.4.3 but on
kannel 1.5.0 the same separate Tx and Rx connections not working properly
for same SMSC provider.

My be i am missing some configuration parameters or this is the behavior of
kannel 1.5.0.

Configuration which is working fine with kannel 1.4.3 and which not working
with kannel 1.5.0

# GROUP SMSC Tx
group = smsc
smsc = smpp
smsc-id = RND-1
throughput = 1
#transceiver-mode = yes
host = xxx.xxx.xxx.xxx
port = 
system-type = RND
smsc-username = x
smsc-password = x
address-range =  
reconnect-delay = 2
alt-charset = ASCII
enquire-link-interval = 30

# Rx connection
group = smsc
smsc = smpp
smsc-id = RND-1-Rx
throughput = 1
host = xxx.xxx.xxx.xxx
port = 
system-type = RND
smsc-username = x
smsc-password = x
address-range =  
reconnect-delay = 2
enquire-link-interval = 30





On Thu, Jan 23, 2014 at 10:17 PM, Ciaran Scolard cia...@phonovation.comwrote:

  It should happen automatically.

 I’m a bit new to kannel so I could be wrong but I think you just have to
 have the binds named the same.

 Try renaming your RND-1-Rx bind to RND-1 and see if that works.





 *From:* krnrd b [mailto:krn...@gmail.com]
 *Sent:* 23 January 2014 15:46
 *To:* Ciaran Scolard
 *Cc:* users

 *Subject:* Re: DLR: received showing 0 in kannel status page



 How would I match DLR/ID ?



 for Kannel 1.4.3 I use same configuration incoming and outgoing shows
 properly.



 Thanks,

 KRNRDB



 On Thu, Jan 23, 2014 at 7:22 PM, Ciaran Scolard cia...@phonovation.com
 wrote:

  Currently the Tx and Rx binds are named RND-1 and RND-1-Rx.

 Wouldn’t the SMPP binds have to be named the same for the DLR/ID matching
 to work?



 *From:* users [mailto:users-boun...@kannel.org] *On Behalf Of *krnrd b
 *Sent:* 23 January 2014 12:22
 *To:* users
 *Subject:* Re: DLR: received showing 0 in kannel status page



 Hi all,



 Any one faced this issue before?



 Sorry just curious to know .



 Thanks,

 KRNRDB

 On Thursday, January 23, 2014, krnrd b krn...@gmail.com wrote:

  Hi all,



 I am using kannel 1.5.0 devel version. When i use Tx and Rx separated
 while connecting SMSC now problem is when submit_sm happening message
 delivered to handset and sms sent as 1 on kannel status page and showing
 properly for Tx connection but when i receiving DLR on Rx connection it's
 showing DLR: received 0 on kannel status page but dlr's coming properly on
 kannel logs.



 Please suggest me why dlr's showing on kannel log but not showing on
 kannel status page.



 Please find the attached kannel status page.



Kannel bearerbox version `1.5.0'. Build `Jan 15 2014 15:56:30',
 compiler `4.1.2 20070626 (Red Hat 4.1.2-14)'. System Linux, release
 2.6.18-53.el5, version

#1 SMP Wed Oct 10 16:34:19 EDT 2007, machine x86_64. Hostname Blade1,
 IP 172.16.8.206. Libxml version 2.6.26. Using OpenSSL 0.9.8b 04 May 2006.
 Compiled

with MySQL 5.1.35, using MySQL 5.1.35. Using native malloc.



Status: running, uptime 0d 0h 1m 15s



WDP: received 0 (0 queued), sent 0 (0 queued)



SMS: received 0 (0 queued), sent 1 (0 queued), store size 0

SMS: inbound (0.00,0.00,0.00) msg/sec, outbound (0.02,0.01,0.01) msg/sec



DLR: received 0, sent 0

DLR: inbound (0.00,0.00,0.00) msg/sec, outbound (0.00,0.00,0.00) msg/sec

DLR: 19 queued, using mysql storage



Box connections:

smsbox:(none), IP 127.0.0.1 (0 queued), (on-line 0d 0h 1m 4s)



SMSC connections:

RND-1[RND-1]SMPP:xxx.xxx.xxx.xxx:2161/0:TestAT:SMPP_RND (online
 72s, rcvd: sms 0 / dlr 0, sent: sms 1 / dlr 0, failed 0, queued 0 msgs)

RND-1-Rx[RND-1-Rx]SMPP:xxx.xxx.xxx.xxx:0/2161:TestAT:SMPP_RND
 (online 73s, rcvd: sms 0 / dlr 0, sent: sms 0 / dlr 0, failed 0, queued 0
 msgs)





 PDU :



 Tx

 -



 2014-01-23 11:12:17 [20558] [6] DEBUG: SMPP[RND-1]: throughput (0.00,1.00)

 2014-01-23 11:12:17 [20558] [6] DEBUG: SMPP[RND-1]: Sending PDU:

 2014-01-23 11:12:17 [20558] [6] DEBUG: SMPP PDU 0x2c000a80 dump:

 2014-01-23 11:12:17 [20558] [6] DEBUG:   type_name: submit_sm

 2014-01-23 11:12:17 [20558] [6] DEBUG:   command_id: 4 = 0x0004

 2014-01-23 11:12:17 [20558] [6] DEBUG:   command_status: 0 = 0x

 2014-01-23 11:12:17 [20558] [6] DEBUG:   sequence_number: 2 = 0x0002

 2014-01-23 11:12:17 [20558] [6] DEBUG:   service_type: NULL

 2014-01-23 11:12:17 [20558] [6] DEBUG:   source_addr_ton: 5 = 0x0005

 2014-01-23 11:12:17 [20558] [6] DEBUG:   source_addr_npi: 0 = 0x

 2014-01-23 11:12:17 [20558] [6] DEBUG:   source_addr

Re: DLR: received showing 0 in kannel status page

Hi All,

Any inputs for the issue I am facing.

Please point me in right direction if I am doing any mistake.

Thanks,
KRNRDB


On Thu, Jan 23, 2014 at 10:47 PM, krnrd b krn...@gmail.com wrote:

 I have try to rename RND-1-Rx bind to RND-1 same then dlr received showing
 on kannel status page but the serious problem is the dlr's which i am
 receiving, kannel sending the same dlr in submit_sm that means on Tx
 connection the same delivery report submitted as submit_sm.

 But when i use TRx mode kannel performing normally also submit and
 delivery repots showing on kannel status page.

 separate Tx and Rx binds use to work perfectly on kannel 1.4.3 but on
 kannel 1.5.0 the same separate Tx and Rx connections not working properly
 for same SMSC provider.

 My be i am missing some configuration parameters or this is the behavior
 of kannel 1.5.0.

 Configuration which is working fine with kannel 1.4.3 and which not
 working with kannel 1.5.0

 # GROUP SMSC Tx
 group = smsc
 smsc = smpp
 smsc-id = RND-1
 throughput = 1
 #transceiver-mode = yes
 host = xxx.xxx.xxx.xxx
 port = 
 system-type = RND
 smsc-username = x
 smsc-password = x
 address-range =  
 reconnect-delay = 2
 alt-charset = ASCII
 enquire-link-interval = 30

 # Rx connection
 group = smsc
 smsc = smpp
 smsc-id = RND-1-Rx
 throughput = 1
 host = xxx.xxx.xxx.xxx
 port = 
 system-type = RND
 smsc-username = x
 smsc-password = x
 address-range =  
 reconnect-delay = 2
 enquire-link-interval = 30





 On Thu, Jan 23, 2014 at 10:17 PM, Ciaran Scolard 
 cia...@phonovation.comwrote:

  It should happen automatically.

 I’m a bit new to kannel so I could be wrong but I think you just have to
 have the binds named the same.

 Try renaming your RND-1-Rx bind to RND-1 and see if that works.





 *From:* krnrd b [mailto:krn...@gmail.com]
 *Sent:* 23 January 2014 15:46
 *To:* Ciaran Scolard
 *Cc:* users

 *Subject:* Re: DLR: received showing 0 in kannel status page



 How would I match DLR/ID ?



 for Kannel 1.4.3 I use same configuration incoming and outgoing shows
 properly.



 Thanks,

 KRNRDB



 On Thu, Jan 23, 2014 at 7:22 PM, Ciaran Scolard cia...@phonovation.com
 wrote:

  Currently the Tx and Rx binds are named RND-1 and RND-1-Rx.

 Wouldn’t the SMPP binds have to be named the same for the DLR/ID matching
 to work?



 *From:* users [mailto:users-boun...@kannel.org] *On Behalf Of *krnrd b
 *Sent:* 23 January 2014 12:22
 *To:* users
 *Subject:* Re: DLR: received showing 0 in kannel status page



 Hi all,



 Any one faced this issue before?



 Sorry just curious to know .



 Thanks,

 KRNRDB

 On Thursday, January 23, 2014, krnrd b krn...@gmail.com wrote:

  Hi all,



 I am using kannel 1.5.0 devel version. When i use Tx and Rx separated
 while connecting SMSC now problem is when submit_sm happening message
 delivered to handset and sms sent as 1 on kannel status page and showing
 properly for Tx connection but when i receiving DLR on Rx connection it's
 showing DLR: received 0 on kannel status page but dlr's coming properly on
 kannel logs.



 Please suggest me why dlr's showing on kannel log but not showing on
 kannel status page.



 Please find the attached kannel status page.



Kannel bearerbox version `1.5.0'. Build `Jan 15 2014 15:56:30',
 compiler `4.1.2 20070626 (Red Hat 4.1.2-14)'. System Linux, release
 2.6.18-53.el5, version

#1 SMP Wed Oct 10 16:34:19 EDT 2007, machine x86_64. Hostname Blade1,
 IP 172.16.8.206. Libxml version 2.6.26. Using OpenSSL 0.9.8b 04 May 2006.
 Compiled

with MySQL 5.1.35, using MySQL 5.1.35. Using native malloc.



Status: running, uptime 0d 0h 1m 15s



WDP: received 0 (0 queued), sent 0 (0 queued)



SMS: received 0 (0 queued), sent 1 (0 queued), store size 0

SMS: inbound (0.00,0.00,0.00) msg/sec, outbound (0.02,0.01,0.01)
 msg/sec



DLR: received 0, sent 0

DLR: inbound (0.00,0.00,0.00) msg/sec, outbound (0.00,0.00,0.00)
 msg/sec

DLR: 19 queued, using mysql storage



Box connections:

smsbox:(none), IP 127.0.0.1 (0 queued), (on-line 0d 0h 1m 4s)



SMSC connections:

RND-1[RND-1]SMPP:xxx.xxx.xxx.xxx:2161/0:TestAT:SMPP_RND
 (online 72s, rcvd: sms 0 / dlr 0, sent: sms 1 / dlr 0, failed 0, queued 0
 msgs)

RND-1-Rx[RND-1-Rx]SMPP:xxx.xxx.xxx.xxx:0/2161:TestAT:SMPP_RND
 (online 73s, rcvd: sms 0 / dlr 0, sent: sms 0 / dlr 0, failed 0, queued 0
 msgs)





 PDU :



 Tx

 -



 2014-01-23 11:12:17 [20558] [6] DEBUG: SMPP[RND-1]: throughput (0.00,1.00)

 2014-01-23 11:12:17 [20558] [6] DEBUG: SMPP[RND-1]: Sending PDU:

 2014-01-23 11:12:17 [20558] [6] DEBUG: SMPP PDU 0x2c000a80 dump:

 2014-01-23 11:12:17 [20558] [6] DEBUG:   type_name: submit_sm

 2014-01-23 11:12:17 [20558] [6] DEBUG:   command_id: 4 = 0x0004

 2014-01-23 11:12:17 [20558] [6] DEBUG:   command_status: 0 = 0x

 2014-01-23 11:12:17 [20558] [6] DEBUG:   sequence_number: 2 = 0x0002

 2014-01-23 11:12:17 [20558

Re: DLR: received showing 0 in kannel status page

2014-01-23 Thread John alero

Dear Krnrd,


Please use same smsc-id name for TX as well as RX session (RND-1).


Kindly find the sample example in given below.

SMSC connections:
   RND-1[RND-1]SMPP:xxx.xxx.xxx.xxx:2161/0:TestAT:SMPP_RND (online
72s, rcvd: sms 0 / dlr 0, sent: sms 1 / dlr 0, failed 0, queued 0 msgs)
   RND-1[RND-1]SMPP:xxx.xxx.xxx.xxx:0/2161:TestAT:SMPP_RND (online
73s, rcvd: sms 0 / dlr 0, sent: sms 0 / dlr 0, failed 0, queued 0 msgs)




On Fri, Jan 24, 2014 at 11:35 AM, krnrd b krn...@gmail.com wrote:

 Hi All,

 Any inputs for the issue I am facing.

 Please point me in right direction if I am doing any mistake.

 Thanks,
 KRNRDB


 On Thu, Jan 23, 2014 at 10:47 PM, krnrd b krn...@gmail.com wrote:

 I have try to rename RND-1-Rx bind to RND-1 same then dlr received
 showing on kannel status page but the serious problem is the dlr's which i
 am receiving, kannel sending the same dlr in submit_sm that means on Tx
 connection the same delivery report submitted as submit_sm.

 But when i use TRx mode kannel performing normally also submit and
 delivery repots showing on kannel status page.

 separate Tx and Rx binds use to work perfectly on kannel 1.4.3 but on
 kannel 1.5.0 the same separate Tx and Rx connections not working properly
 for same SMSC provider.

 My be i am missing some configuration parameters or this is the behavior
 of kannel 1.5.0.

 Configuration which is working fine with kannel 1.4.3 and which not
 working with kannel 1.5.0

 # GROUP SMSC Tx
 group = smsc
 smsc = smpp
 smsc-id = RND-1
 throughput = 1
 #transceiver-mode = yes
 host = xxx.xxx.xxx.xxx
 port = 
 system-type = RND
 smsc-username = x
 smsc-password = x
 address-range =  
 reconnect-delay = 2
 alt-charset = ASCII
 enquire-link-interval = 30

 # Rx connection
 group = smsc
 smsc = smpp
 smsc-id = RND-1-Rx
 throughput = 1
 host = xxx.xxx.xxx.xxx
 port = 
 system-type = RND
 smsc-username = x
 smsc-password = x
 address-range =  
 reconnect-delay = 2
 enquire-link-interval = 30





 On Thu, Jan 23, 2014 at 10:17 PM, Ciaran Scolard 
 cia...@phonovation.comwrote:

  It should happen automatically.

 I’m a bit new to kannel so I could be wrong but I think you just have to
 have the binds named the same.

 Try renaming your RND-1-Rx bind to RND-1 and see if that works.





 *From:* krnrd b [mailto:krn...@gmail.com]
 *Sent:* 23 January 2014 15:46
 *To:* Ciaran Scolard
 *Cc:* users

 *Subject:* Re: DLR: received showing 0 in kannel status page



 How would I match DLR/ID ?



 for Kannel 1.4.3 I use same configuration incoming and outgoing shows
 properly.



 Thanks,

 KRNRDB



 On Thu, Jan 23, 2014 at 7:22 PM, Ciaran Scolard cia...@phonovation.com
 wrote:

  Currently the Tx and Rx binds are named RND-1 and RND-1-Rx.

 Wouldn’t the SMPP binds have to be named the same for the DLR/ID
 matching to work?



 *From:* users [mailto:users-boun...@kannel.org] *On Behalf Of *krnrd b
 *Sent:* 23 January 2014 12:22
 *To:* users
 *Subject:* Re: DLR: received showing 0 in kannel status page



 Hi all,



 Any one faced this issue before?



 Sorry just curious to know .



 Thanks,

 KRNRDB

 On Thursday, January 23, 2014, krnrd b krn...@gmail.com wrote:

  Hi all,



 I am using kannel 1.5.0 devel version. When i use Tx and Rx separated
 while connecting SMSC now problem is when submit_sm happening message
 delivered to handset and sms sent as 1 on kannel status page and showing
 properly for Tx connection but when i receiving DLR on Rx connection it's
 showing DLR: received 0 on kannel status page but dlr's coming properly on
 kannel logs.



 Please suggest me why dlr's showing on kannel log but not showing on
 kannel status page.



 Please find the attached kannel status page.



Kannel bearerbox version `1.5.0'. Build `Jan 15 2014 15:56:30',
 compiler `4.1.2 20070626 (Red Hat 4.1.2-14)'. System Linux, release
 2.6.18-53.el5, version

#1 SMP Wed Oct 10 16:34:19 EDT 2007, machine x86_64. Hostname Blade1,
 IP 172.16.8.206. Libxml version 2.6.26. Using OpenSSL 0.9.8b 04 May 2006.
 Compiled

with MySQL 5.1.35, using MySQL 5.1.35. Using native malloc.



Status: running, uptime 0d 0h 1m 15s



WDP: received 0 (0 queued), sent 0 (0 queued)



SMS: received 0 (0 queued), sent 1 (0 queued), store size 0

SMS: inbound (0.00,0.00,0.00) msg/sec, outbound (0.02,0.01,0.01)
 msg/sec



DLR: received 0, sent 0

DLR: inbound (0.00,0.00,0.00) msg/sec, outbound (0.00,0.00,0.00)
 msg/sec

DLR: 19 queued, using mysql storage



Box connections:

smsbox:(none), IP 127.0.0.1 (0 queued), (on-line 0d 0h 1m 4s)



SMSC connections:

RND-1[RND-1]SMPP:xxx.xxx.xxx.xxx:2161/0:TestAT:SMPP_RND
 (online 72s, rcvd: sms 0 / dlr 0, sent: sms 1 / dlr 0, failed 0, queued 0
 msgs)

RND-1-Rx[RND-1-Rx]SMPP:xxx.xxx.xxx.xxx:0/2161:TestAT:SMPP_RND
 (online 73s, rcvd: sms 0 / dlr 0, sent: sms 0 / dlr 0, failed 0, queued 0
 msgs)





 PDU :



 Tx

 -



 2014

Re: DLR: received showing 0 in kannel status page