Re: DLRs

[Sayed Hadi Rastgou Haghi]

Dear Antony,

May be this helps.

The Kannel DLR mechanism works as follows:

   1. Kannel sends your message in submit_sm packet to smsc.
   2. SMSC replies with submit_sm_resp, witch have a *ID* in it.
   3. if SMSC accepts the message, there will be an *ID *and kannel sends
   status=8 , kannel tries to extracts *ID* ( known as foreign_id or fid )
   and keeps message info with smsc_id in kannel configuration *,*
   otherwise there will be error code and kannel sends status=16 (message
   rejected by smsc).
   4. For Accepted messages, SMSC sends a deliver_sm packet with same *ID * to
   tell kannel the final status of message, witch will be delivered (status=1)
   or undelivered/expired (status=2).
   5. kannel extract *ID*, and tries to find dlr config from dlr-storage.
   if it does'nt find  you will see
   6.

*2019-08-17 12:19:53 [11506] [6] ERROR: SMPP[Carrier]: got DLR but could
   not find message or was not interested in it
   id<4057323ed63f402595dde997f8f55d60> dst<447799112233>, type<1>*

P.S. The 6 sometimes happen because of your kannel config for
*msg-id-type.* kannel
deals with *ID*s as numbers and some SMSCs send HEXADECIMAL ids. so you
should tell kannel with type of message id will be returned.

You can find SMSC behavior with packet capture tools like wireshark.

On Sat, Aug 17, 2019 at 7:55 PM Antony Stone <
antony.st...@kannel.open.source.it> wrote:

> Replying to myself in case it helps others looking for this information in
> future.
>
> On Saturday 17 August 2019 at 15:42:38, Antony Stone wrote:
>
> > It looks like I'm going to have to look into using a database for my DLR
> > storage.  I do happen to have a MariaDB Galera cluster available, but
> I've
> > read https://stackoverflow.com/questions/45486238/kannel-sqlbox that the
> > Debian packaged installation of kannel doesn't work with MySQL, only if
> > you build kannel from source.
> >
> > Does anyone know whether this is still true (kannel 1.4.4, kannel-sqlbox
> > 0.7.2) for the Debian 9 Stretch packages?
>
> Yes, this is still true :(
>
> The Debian Stretch package has not been updated with whatever bug fix
> comes
> from building kannel yourself from source.
>
> It makes me wonder slightly how the Debian package got built...
>
> But anyway, if you want kannel working with MySQL, don't start from the
> Debian
> Stretch package.
>
> I do notice that there's a packaged version of kannel 1.4.5 in the new
> (since
> 6th July) Debian Stable (version 10, Buster), but I don't have the
> facility to
> try that out yet - trying to install that package into Stretch involves
> too
> many incompatibilities, and I can't upgrade the entire machine to Buster
> because that would also upgrade my Asterisk 13 to Asterisk 16, which I'm
> not
> ready for yet.
>
>
> If I do find any reasonable way of getting kannel to work with MySQL
> storage
> under Debian Stretch, I'll reply again here to let people know how.
>
>
> In the meantime I hope someone can point me at the final bit of my
> delivery
> reports problem - how do I tell kannel to send a DLR status=1 to notify a
> sender that their message has been delivered?
>
>
> Thanks,
>
>
> Antony.
>
>
> --
> A user interface is like a joke.
> If you have to explain it, it means it doesn't work.
>
>Please reply to the
> list;
>  please *don't* CC
> me.
>
>

-- 
Sincerely,

Sayed Hadi Rastgou Haghi

RE: DLRs

[Davor Spasoski]

I doubt there is such a granularity in MO->AT direction. I doubt the mobile 
handset can set any of the registered_delivery parameters other than SMSC 
originated. (final state delivered or not delivered issued by the SMSC)
As regards kannel, I can't test right now, but I expect that either kannel 
responds positivelly with a final state delivered once bearerbox accepts the 
message and stores it for further delivery to the smsbox or that happens after 
the service is resolved on the smsbox and delivered.
You will have to test. Just keep the smsbox down and observe when will bearebox 
reply to the SMSC.

Davor
-Original Message-
From: users  On Behalf Of Antony Stone
Sent: Saturday, August 17, 2019 3:54 PM
To: users@kannel.org
Subject: Re: DLRs

On Saturday 17 August 2019 at 15:48:19, Antony Stone wrote:

> Indeed - if I turn off one of my kannel instances, so there is only
> one running to either send or receive message to/from my SMSC
> provider, I get DLR status=8 when the message is sent (with the phone
> turned off), and I then get DLR status=1 once the phone is turned on
> and the message is delivered.

So, this now brings me back to my original question:

How do I tell kannel to send DLR with status=1 once my application has 
delivered an incoming message to the user?

I'll rephrase that to be completely clear:

1. Someone with a mobile phone sends an SMS to a number hosted by my SMPP 
provider

2. The provider sends that message to my kannel instance

3. kannel responds with a DLR status=8 to say it's being processed

4. kannel sends the message on to my application, which delivers it to the user

How does my application then tell kannel to send DLR status=1 so that the 
original sender knows it's been delivered?


Thanks,


Antony.

--
"Remember: the S in IoT stands for Security."

 - Jan-Piet Mens

   Please reply to the list;
 please *don't* CC me.




Disclaimer: one.Vip DOOEL Skopje
This e-mail (including any attachments) is confidential and may be protected by 
legal privilege. If you are not the intended recipient, you should not copy it, 
re-transmit it, use it or disclose its contents, but should return it to the 
sender immediately and delete your copy from your system. Any unauthorized use 
or dissemination of this message in whole or in part is strictly prohibited. 
Please note that e-mails are susceptible to change. one.Vip DOOEL Skopje shall 
not be liable for the improper or incomplete transmission of the information 
contained in this communication nor for any delay in its receipt or damage to 
your system.
Please, do not print this e-mail unless it is necessary! Think about saving the 
environment!

Напомена: оне.Вип ДООЕЛ Скопје
Оваа електронска порака (вклучувајќи ги и прилозите) е доверлива и може да биде 
заштитена со правни привилегии. Доколку не сте лицето на кое таа му е наменета 
пораката, не треба да ја копирате, дистрибуирате или да ја откривате нејзината 
содржина, туку веднаш да ја препратите до испраќачот и да ја избришете 
оригиналната порака и сите нејзини копии од Вашиот компјутерски систем. Секое 
неовластено користење на оваа порака во целост или делови од истата е строго 
забрането. Ве молиме да забележите дека електронските пораки се подложни на 
промени. оне.Вип ДООЕЛ Скопје не презема одговорност за несоодветно или 
нецелосно пренесување на информациите содржани во оваа комуникација, ниту пак 
за било какво задоцнување на приемот или оштетувања на вашиот систем.
Ве молиме не ја печатете оваа порака освен ако не е неопходно! Зачувајте ја 
природата!

Re: DLRs

[Antony Stone]

Replying to myself in case it helps others looking for this information in 
future.

On Saturday 17 August 2019 at 15:42:38, Antony Stone wrote:

> It looks like I'm going to have to look into using a database for my DLR
> storage.  I do happen to have a MariaDB Galera cluster available, but I've
> read https://stackoverflow.com/questions/45486238/kannel-sqlbox that the
> Debian packaged installation of kannel doesn't work with MySQL, only if
> you build kannel from source.
> 
> Does anyone know whether this is still true (kannel 1.4.4, kannel-sqlbox
> 0.7.2) for the Debian 9 Stretch packages?

Yes, this is still true :(

The Debian Stretch package has not been updated with whatever bug fix comes 
from building kannel yourself from source.

It makes me wonder slightly how the Debian package got built...

But anyway, if you want kannel working with MySQL, don't start from the Debian 
Stretch package.

I do notice that there's a packaged version of kannel 1.4.5 in the new (since 
6th July) Debian Stable (version 10, Buster), but I don't have the facility to 
try that out yet - trying to install that package into Stretch involves too 
many incompatibilities, and I can't upgrade the entire machine to Buster 
because that would also upgrade my Asterisk 13 to Asterisk 16, which I'm not 
ready for yet.


If I do find any reasonable way of getting kannel to work with MySQL storage 
under Debian Stretch, I'll reply again here to let people know how.


In the meantime I hope someone can point me at the final bit of my delivery 
reports problem - how do I tell kannel to send a DLR status=1 to notify a 
sender that their message has been delivered?


Thanks,


Antony.


-- 
A user interface is like a joke.
If you have to explain it, it means it doesn't work.

   Please reply to the list;
 please *don't* CC me.

Re: DLRs

[Antony Stone]

On Saturday 17 August 2019 at 15:48:19, Antony Stone wrote:

> Indeed - if I turn off one of my kannel instances, so there is only one
> running to either send or receive message to/from my SMSC provider, I get
> DLR status=8 when the message is sent (with the phone turned off), and I
> then get DLR status=1 once the phone is turned on and the message is
> delivered.

So, this now brings me back to my original question:

How do I tell kannel to send DLR with status=1 once my application has 
delivered an incoming message to the user?

I'll rephrase that to be completely clear:

1. Someone with a mobile phone sends an SMS to a number hosted by my SMPP 
provider

2. The provider sends that message to my kannel instance

3. kannel responds with a DLR status=8 to say it's being processed

4. kannel sends the message on to my application, which delivers it to the 
user

How does my application then tell kannel to send DLR status=1 so that the 
original sender knows it's been delivered?


Thanks,


Antony.

-- 
"Remember: the S in IoT stands for Security."

 - Jan-Piet Mens

   Please reply to the list;
 please *don't* CC me.

Re: DLRs

[Antony Stone]

On Saturday 17 August 2019 at 15:42:38, Antony Stone wrote:

> So, it seems that kannel did receive a DLR with type=1, but then said "got
> DLR but could not find message or was not interested in it".
> 
> I've found https://www.kannel.org/pipermail/users/2011-July/016176.html
> which addresses this, and it looks like suggestion 1 is my problem.  I do
> have two machines running kannel, each with a connection to my upstream
> carrier (for load balancing / high availability), and I have no control
> over which connection that carrier will use to send me messages or DLRs.

Indeed - if I turn off one of my kannel instances, so there is only one running 
to either send or receive message to/from my SMSC provider, I get DLR status=8 
when the message is sent (with the phone turned off), and I then get DLR 
status=1 once the phone is turned on and the message is delivered.

> It looks like I'm going to have to look into using a database for my DLR
> storage.  I do happen to have a MariaDB Galera cluster available, but I've
> read https://stackoverflow.com/questions/45486238/kannel-sqlbox that the
> Debian packaged installation of kannel doesn't work with MySQL, only if
> you build kannel from source.
> 
> Does anyone know whether this is still true (kannel 1.4.4, kannel-sqlbox
> 0.7.2) for the Debian 9 Stretch packages?


Antony.

-- 
I want to build a machine that will be proud of me.

 - Danny Hillis, creator of The Connection Machine

   Please reply to the list;
 please *don't* CC me.

Re: DLRs

[Antony Stone]

On Saturday 17 August 2019 at 14:20:36, Davor Spasoski wrote:

> The smsc should send back DLR (deliver_sm pdu) on succesful delivery after
> you turn on the phone. Try with a different handset and watch for the
> deliver_sm pdu. Run bearerbox in debug level.
> 
> Davor

It happens that I'm running bearerbox with debug logging already, so I checked 
the logs for the message I sent earlier.

I see the following:

2019-08-17 12:19:53 [11506] [6] DEBUG: SMPP[Carrier] handle_pdu, got DLR
2019-08-17 12:19:53 [11506] [6] DEBUG: DLR[internal]: Looking for DLR 
smsc=Carrier, ts=4057323ed63f402595dde997f8f55d60, dst=447799112233, type=1
2019-08-17 12:19:53 [11506] [6] WARNING: DLR[internal]: DLR from SMSC 
for DST<447799112233> not found.
2019-08-17 12:19:53 [11506] [6] ERROR: SMPP[Carrier]: got DLR but could not 
find message or was not interested in it id<4057323ed63f402595dde997f8f55d60> 
dst<447799112233>, type<1>
2019-08-17 12:19:53 [11506] [6] DEBUG: SMPP[Carrier]: Sending PDU:
2019-08-17 12:19:53 [11506] [6] DEBUG: SMPP PDU 0x7fe9a0006910 dump:
2019-08-17 12:19:53 [11506] [6] DEBUG:   type_name: deliver_sm_resp
2019-08-17 12:19:53 [11506] [6] DEBUG:   command_id: 2147483653 = 0x8005
2019-08-17 12:19:53 [11506] [6] DEBUG:   command_status: 0 = 0x
2019-08-17 12:19:53 [11506] [6] DEBUG:   sequence_number: 16027465 = 
0x00f48f49
2019-08-17 12:19:53 [11506] [6] DEBUG:   message_id: NULL
2019-08-17 12:19:53 [11506] [6] DEBUG: SMPP PDU dump ends.

So, it seems that kannel did receive a DLR with type=1, but then said "got DLR 
but could not find message or was not interested in it".

I've found https://www.kannel.org/pipermail/users/2011-July/016176.html which 
addresses this, and it looks like suggestion 1 is my problem.  I do have two 
machines running kannel, each with a connection to my upstream carrier (for 
load balancing / high availability), and I have no control over which 
connection that carrier will use to send me messages or DLRs.

It looks like I'm going to have to look into using a database for my DLR 
storage.  I do happen to have a MariaDB Galera cluster available, but I've 
read https://stackoverflow.com/questions/45486238/kannel-sqlbox that the Debian 
packaged installation of kannel doesn't work with MySQL, only if you build 
kannel from source.

Does anyone know whether this is still true (kannel 1.4.4, kannel-sqlbox 
0.7.2) for the Debian 9 Stretch packages?

> >> On Aug 17, 2019, at 1:45 PM, Antony Stone wrote:
> >> 
> >> Hi.
> >> 
> >> I'm now wondering whether I've misunderstood how DLRs actually work.
> >> 
> >> I just tried the following:
> >> 
> >> 1. Make sure my mobile phone is turned on and has good signal.
> >> 
> >> 2. Send a message via kannel to my mobile phone, with dlr_mask=31,
> >> indicating that I want to get all status reports possible.
> >> 
> >> 3. I immediately get back a DLR with status=8, which I interpret to mean
> >> that the message has been received by the upstream SMSC and is being
> >> processed.
> >> 
> >> 4. I then immediately afterwards get a DLR with status=1, which I
> >> interpret to mean that the message has been delivered to my phone.
> >> 
> >> 5. Sure enough, the message has arrived on my phone.
> >> 
> >> 
> >> 6. Turn the phone off.
> >> 
> >> 7. Repeat step 2 above.
> >> 
> >> 8. I immediately get back a DLR with status=8, just as in step 3 above.
> >> 
> >> 9. Nothing further happens - no surprise there.
> >> 
> >> 10. I turn my phone back on again and wait until it has signal.
> >> 
> >> 11. The second message arrives on my phone.
> >> 
> >> 12. The bit which surprises me is that I do *not* now get a DLR through
> >> kannel with status=1, so my application has no way of knowing that the
> >> message has now been delivered.
> >> 
> >> 
> >> Am I misunderstanding the meaning of status codes 8 and 1, or maybe
> >> misunderstanding how DLRs are supposed to work with SMS?
> >> 
> >> I'd be grateful for any comments helping me to understand why I do not
> >> get a DLR status=1 after the second message has arrived on my phone.
> >> 
> >> 
> >> Thanks,
> >> 
> >> Antony.

-- 
"Life is just a lot better if you feel you're having 10 [small] wins a day 
rather than a [big] win every 10 years or so."

 - Chris Hadfield, former skiing (and ski racing) instructor

   Please reply to the list;
 please *don't* CC me.

Re: DLRs

[Davor Spasoski]

Sorry, points 10-12 were not visible on my phone.
The smsc should send back DLR (deliver_sm pdu) on succesful delivery after you 
turn on the phone.
Try with a different handset and watch for the deliver_sm pdu. Run bearerbox in 
debug level.

Davor

> On Aug 17, 2019, at 2:13 PM, Davor Spasoski  wrote:
>
> And what is wrong with that?
> Kannel will report every change in state as soon as the smsc reports back. 
> The non delivery notification will be received upon expiration of the sms 
> which depends on the validity period on the smsc or the expiration you might 
> have set, whatever comes first.
>
> Davor
>
>> On Aug 17, 2019, at 1:45 PM, Antony Stone 
>>  wrote:
>>
>> Hi.
>>
>> I'm now wondering whether I've misunderstood how DLRs actually work.
>>
>> I just tried the following:
>>
>> 1. Make sure my mobile phone is turned on and has good signal.
>>
>> 2. Send a message via kannel to my mobile phone, with dlr_mask=31, indicating
>> that I want to get all status reports possible.
>>
>> 3. I immediately get back a DLR with status=8, which I interpret to mean that
>> the message has been received by the upstream SMSC and is being processed.
>>
>> 4. I then immediately afterwards get a DLR with status=1, which I interpret 
>> to
>> mean that the message has been delivered to my phone.
>>
>> 5. Sure enough, the message has arrived on my phone.
>>
>>
>> 6. Turn the phone off.
>>
>> 7. Repeat step 2 above.
>>
>> 8. I immediately get back a DLR with status=8, just as in step 3 above.
>>
>> 9. Nothing further happens - no surprise there.
>>
>> 10. I turn my phone back on again and wait until it has signal.
>>
>> 11. The second message arrives on my phone.
>>
>> 12. The bit which surprises me is that I do *not* now get a DLR through 
>> kannel
>> with status=1, so my application has no way of knowing that the message has
>> now been delivered.
>>
>>
>> Am I misunderstanding the meaning of status codes 8 and 1, or maybe
>> misunderstanding how DLRs are supposed to work with SMS?
>>
>> I'd be grateful for any comments helping me to understand why I do not get a
>> DLR status=1 after the second message has arrived on my phone.
>>
>>
>> Thanks,
>>
>> Antony.
>>
>> --
>> "The future is already here.   It's just not evenly distributed yet."
>>
>> - William Gibson
>>
>>  Please reply to the list;
>>please *don't* CC me.
>>
>
> 
>
> Disclaimer: one.Vip DOOEL Skopje
> This e-mail (including any attachments) is confidential and may be protected 
> by legal privilege. If you are not the intended recipient, you should not 
> copy it, re-transmit it, use it or disclose its contents, but should return 
> it to the sender immediately and delete your copy from your system. Any 
> unauthorized use or dissemination of this message in whole or in part is 
> strictly prohibited. Please note that e-mails are susceptible to change. 
> one.Vip DOOEL Skopje shall not be liable for the improper or incomplete 
> transmission of the information contained in this communication nor for any 
> delay in its receipt or damage to your system.
> Please, do not print this e-mail unless it is necessary! Think about saving 
> the environment!
>
> Напомена: оне.Вип ДООЕЛ Скопје
> Оваа електронска порака (вклучувајќи ги и прилозите) е доверлива и може да 
> биде заштитена со правни привилегии. Доколку не сте лицето на кое таа му е 
> наменета пораката, не треба да ја копирате, дистрибуирате или да ја откривате 
> нејзината содржина, туку веднаш да ја препратите до испраќачот и да ја 
> избришете оригиналната порака и сите нејзини копии од Вашиот компјутерски 
> систем. Секое неовластено користење на оваа порака во целост или делови од 
> истата е строго забрането. Ве молиме да забележите дека електронските пораки 
> се подложни на промени. оне.Вип ДООЕЛ Скопје не презема одговорност за 
> несоодветно или нецелосно пренесување на информациите содржани во оваа 
> комуникација, ниту пак за било какво задоцнување на приемот или оштетувања на 
> вашиот систем.
> Ве молиме не ја печатете оваа порака освен ако не е неопходно! Зачувајте ја 
> природата!



Disclaimer: one.Vip DOOEL Skopje
This e-mail (including any attachments) is confidential and may be protected by 
legal privilege. If you are not the intended recipient, you should not copy it, 
re-transmit it, use it or disclose its contents, but should return it to the 
sender immediately and delete your copy from your system. Any unauthorized use 
or dissemination of this message in whole or in part is strictly prohibited. 
Please note that e-mails are susceptible to change. one.Vip DOOEL Skopje shall 
not be liable for the improper or incomplete transmission of the information 
contained in this communication nor for any delay in its receipt or damage to 
your system.
Please, do not print this e-mail unless it is necessary! Think about 

Re: DLRs

[Davor Spasoski]

And what is wrong with that?
Kannel will report every change in state as soon as the smsc reports back. The 
non delivery notification will be received upon expiration of the sms which 
depends on the validity period on the smsc or the expiration you might have 
set, whatever comes first.

Davor

> On Aug 17, 2019, at 1:45 PM, Antony Stone 
>  wrote:
>
> Hi.
>
> I'm now wondering whether I've misunderstood how DLRs actually work.
>
> I just tried the following:
>
> 1. Make sure my mobile phone is turned on and has good signal.
>
> 2. Send a message via kannel to my mobile phone, with dlr_mask=31, indicating
> that I want to get all status reports possible.
>
> 3. I immediately get back a DLR with status=8, which I interpret to mean that
> the message has been received by the upstream SMSC and is being processed.
>
> 4. I then immediately afterwards get a DLR with status=1, which I interpret to
> mean that the message has been delivered to my phone.
>
> 5. Sure enough, the message has arrived on my phone.
>
>
> 6. Turn the phone off.
>
> 7. Repeat step 2 above.
>
> 8. I immediately get back a DLR with status=8, just as in step 3 above.
>
> 9. Nothing further happens - no surprise there.
>
> 10. I turn my phone back on again and wait until it has signal.
>
> 11. The second message arrives on my phone.
>
> 12. The bit which surprises me is that I do *not* now get a DLR through kannel
> with status=1, so my application has no way of knowing that the message has
> now been delivered.
>
>
> Am I misunderstanding the meaning of status codes 8 and 1, or maybe
> misunderstanding how DLRs are supposed to work with SMS?
>
> I'd be grateful for any comments helping me to understand why I do not get a
> DLR status=1 after the second message has arrived on my phone.
>
>
> Thanks,
>
> Antony.
>
> --
> "The future is already here.   It's just not evenly distributed yet."
>
> - William Gibson
>
>   Please reply to the list;
> please *don't* CC me.
>



Disclaimer: one.Vip DOOEL Skopje
This e-mail (including any attachments) is confidential and may be protected by 
legal privilege. If you are not the intended recipient, you should not copy it, 
re-transmit it, use it or disclose its contents, but should return it to the 
sender immediately and delete your copy from your system. Any unauthorized use 
or dissemination of this message in whole or in part is strictly prohibited. 
Please note that e-mails are susceptible to change. one.Vip DOOEL Skopje shall 
not be liable for the improper or incomplete transmission of the information 
contained in this communication nor for any delay in its receipt or damage to 
your system.
Please, do not print this e-mail unless it is necessary! Think about saving the 
environment!

Напомена: оне.Вип ДООЕЛ Скопје
Оваа електронска порака (вклучувајќи ги и прилозите) е доверлива и може да биде 
заштитена со правни привилегии. Доколку не сте лицето на кое таа му е наменета 
пораката, не треба да ја копирате, дистрибуирате или да ја откривате нејзината 
содржина, туку веднаш да ја препратите до испраќачот и да ја избришете 
оригиналната порака и сите нејзини копии од Вашиот компјутерски систем. Секое 
неовластено користење на оваа порака во целост или делови од истата е строго 
забрането. Ве молиме да забележите дека електронските пораки се подложни на 
промени. оне.Вип ДООЕЛ Скопје не презема одговорност за несоодветно или 
нецелосно пренесување на информациите содржани во оваа комуникација, ниту пак 
за било какво задоцнување на приемот или оштетувања на вашиот систем.
Ве молиме не ја печатете оваа порака освен ако не е неопходно! Зачувајте ја 
природата!

Re: DLRs getting deleted from Msql

[vinayak mv]

use sqlbox for logging MO,MT,DLR

On Tue, Dec 11, 2018 at 8:42 PM Web Min  wrote:

> It delete from dlr table if you are passing dlr_url to update your
> original database
>
> in my case, I have queue table contain the status, sender_id, msg, etc...
> this table is used by my portal, when I send an sms it insert into
> dlr table for while and once I received the DLR status pushed from the
> SMSC, I'm updating my queue table and Kannel delete the record from the dlr
>
> On Tue, Dec 11, 2018 at 6:07 PM christopher kamutumwa <
> chriskamutu...@gmail.com> wrote:
>
>> I have kannel v1.4.4 running properly am able to sending messages and
>> receive dlrs as per access log.
>>
>> but I cant see it getting saved to msql as table dlr in temp_dlr is
>> empty. I have checked bearerbox.log and am getting below action that dlr is
>> getting deleted. How do I resolve this?
>>
>> Bearerbox.log below
>> ….
>> removing DLR from database
>> 2018-12-11 14:34:08 [16289] [7] DEBUG: sql: DELETE FROM `dlr` WHERE
>> `smsc`=? AND `ts`=?  LIMIT 1
>>
>> ………
>>
>> Thanks in advance
>> Chris
>>
>

-- 
Thanks & Regards,
Vinayak

==

*Confucius* once said,
"*Life is really simple, but we insist on making it complicated.*"

*Leonardo da Vinci* once said,
"*Simplicity is the ultimate sophistication.*"

*Albert Einstein* once said,
"*Everything should be made as simple as possible, but not simpler.*"

Re: DLRs getting deleted from Msql

[Web Min]

It delete from dlr table if you are passing dlr_url to update your original
database

in my case, I have queue table contain the status, sender_id, msg, etc...
this table is used by my portal, when I send an sms it insert into
dlr table for while and once I received the DLR status pushed from the
SMSC, I'm updating my queue table and Kannel delete the record from the dlr

On Tue, Dec 11, 2018 at 6:07 PM christopher kamutumwa <
chriskamutu...@gmail.com> wrote:

> I have kannel v1.4.4 running properly am able to sending messages and
> receive dlrs as per access log.
>
> but I cant see it getting saved to msql as table dlr in temp_dlr is empty.
> I have checked bearerbox.log and am getting below action that dlr is
> getting deleted. How do I resolve this?
>
> Bearerbox.log below
> ….
> removing DLR from database
> 2018-12-11 14:34:08 [16289] [7] DEBUG: sql: DELETE FROM `dlr` WHERE
> `smsc`=? AND `ts`=?  LIMIT 1
>
> ………
>
> Thanks in advance
> Chris
>

Re: DLRs Routing

[ha...@aeon.pk]

Check if routing delay is from telecom side (SMSC often sends DLR pretty
late). It should be visible in bearerbox logs. Logically, bbox should not
be delaying DLRs.

On Wed, Oct 21, 2015 at 8:51 AM, Amelye Chatila  wrote:

> I experience a delay in DLRs routing. I have couple of smsboxes and couple
> of SMSC connections. What is causing this? What adjustments can I make?
>
> Thanks in advance!
>

Re: DLRs - decoding PDU problem

[Tomasz]

I've solved the problem myself.

In at2_pdu_decode function those DLRs have type 1 (AT_SUBMIT_SM)
instead of 2 (AT_STATUS_REPORT_SM).

Probably operator make some modifications in DLR PDUs he sends.

After adding support for AT_SUBMIT_SM type there all DLRs are processed
correctly again.

Tomasz

W Twoim liście datowanym 30 sierpnia 2012 (12:36:59) można przeczytać:

 Hello,

 I'm using Kannel since few years as a core for gateway based on GSM
 modems (AT). Since few days I've got a problem with DLRs. I'm
 receiving only DLRs for some messages (before DLRs for all SMS were
 delivered correctly). No configuration changes were made from that
 time on my side. I've looked into logs and have seen that when
 receiving DLRs sometimes all is ok and sometimes there is could not
 decode PDU to a message message.

 2012-08-28 09:22:01 [3626] [42] DEBUG: AT2[modem_032]: -- +CDSI: SM,0
 2012-08-28 09:22:01 [3626] [42] DEBUG: AT2[modem_032]: +CMTI
 incoming SMS indication: +CDSI: SM,0
 2012-08-28 09:22:01 [3626] [42] DEBUG: AT2[modem_032]: -- ^MODE:3,3
 2012-08-28 09:22:02 [3626] [42] DEBUG: AT2[modem_032]: -- AT+CMGR=0^M
 2012-08-28 09:22:02 [3626] [42] DEBUG: AT2[modem_032]: -- +CMGR: 0,,25
 2012-08-28 09:22:02 [3626] [42] DEBUG: AT2[modem_032]: --
 07918405210077F79EC00B918405566182F6218082900332802180829003828000
 2012-08-28 09:22:02 [3626] [42] DEBUG: AT2[modem_032]: received message from 
 SMSC: +48501200777
 2012-08-28 09:22:02 [3626] [42] ERROR: AT2[modem_032]: could not decode PDU 
 to a message.
 2012-08-28 09:22:02 [3626] [42] DEBUG: AT2[modem_032]: -- OK


 ...but some DLRs are processed correctly:


 2012-08-28 08:48:54 [3626] [42] DEBUG: AT2[modem_032]: -- +CDSI: SM,0
 2012-08-28 08:48:54 [3626] [42] DEBUG: AT2[modem_032]: +CMTI
 incoming SMS indication: +CDSI: SM,0
 2012-08-28 08:48:54 [3626] [42] DEBUG: AT2[modem_032]: -- ^MODE:3,3
 2012-08-28 08:48:56 [3626] [42] DEBUG: AT2[modem_032]: -- AT+CMGR=0^M
 2012-08-28 08:48:56 [3626] [42] DEBUG: AT2[modem_032]: -- +CMGR: 0,,25
 2012-08-28 08:48:56 [3626] [42] DEBUG: AT2[modem_032]: --
 07918405210077F706B90B918405693009F2218082807541802180828075918000
 2012-08-28 08:48:56 [3626] [42] DEBUG: AT2[modem_032]: received message from 
 SMSC: +48501200777
 2012-08-28 08:48:56 [3626] [42] DEBUG: AT2[modem_032]: got STATUS-REPORT for 
 message 185:
 2012-08-28 08:48:56 [3626] [42] DEBUG: AT2[modem_032]: Numeric
 receiver (international) +48509603XXX

 I've decoded both PDUs using a tool from
 http://www.diafaan.com/sms-tutorials/gsm-modem-tutorial/online-sms-pdu-decoder/
 and both could be decoded properly (as SMS-STATUS-REPORT).

 The one difference between those PDUs is that
 07918405210077F706B90B918405693009F2218082807541802180828075918000 has
 PDU header: 06 and
 07918405210077F79EC00B918405566182F6218082900332802180829003828000 has
 PDU header: 9E. I've made more tests and have seen that all DLRs with PDU
 header: 06 are decoded by kannel and processed correctly, but when PDU
 header: 9E than DLR isn't decoded properly and in logs there is could
 not decode PDU to a message message.

 Probably my GSM operator made some modifications and it delivers DLRs
 with 9E and 06 headers. I've looked into kannel source code but I
 can't find a place where to make modifications to have kannel decode
 PDU with 9E header correctly. Could you help me?

 Tomasz





-- 
Pozdrowienia,
 Tomasz

Re: DLRs - decoding PDU problem

[Alvaro Cornejo]

Would you post your patch so it might get included in sources?

Thanks

Alvaro


|-|
Envíe y Reciba Datos y mensajes de Texto (SMS) hacia y desde cualquier
celular y Nextel
en el Perú, México y en mas de 180 paises. Use aplicaciones 2 vias via
SMS y GPRS online
  Visitenos en www.perusms.NET www.smsglobal.com.mx y
www.pravcom.com


On Sun, Sep 2, 2012 at 4:38 AM, Tomasz ad...@impexrur.pl wrote:
 I've solved the problem myself.

 In at2_pdu_decode function those DLRs have type 1 (AT_SUBMIT_SM)
 instead of 2 (AT_STATUS_REPORT_SM).

 Probably operator make some modifications in DLR PDUs he sends.

 After adding support for AT_SUBMIT_SM type there all DLRs are processed
 correctly again.

 Tomasz

 W Twoim liście datowanym 30 sierpnia 2012 (12:36:59) można przeczytać:

 Hello,

 I'm using Kannel since few years as a core for gateway based on GSM
 modems (AT). Since few days I've got a problem with DLRs. I'm
 receiving only DLRs for some messages (before DLRs for all SMS were
 delivered correctly). No configuration changes were made from that
 time on my side. I've looked into logs and have seen that when
 receiving DLRs sometimes all is ok and sometimes there is could not
 decode PDU to a message message.

 2012-08-28 09:22:01 [3626] [42] DEBUG: AT2[modem_032]: -- +CDSI: SM,0
 2012-08-28 09:22:01 [3626] [42] DEBUG: AT2[modem_032]: +CMTI
 incoming SMS indication: +CDSI: SM,0
 2012-08-28 09:22:01 [3626] [42] DEBUG: AT2[modem_032]: -- ^MODE:3,3
 2012-08-28 09:22:02 [3626] [42] DEBUG: AT2[modem_032]: -- AT+CMGR=0^M
 2012-08-28 09:22:02 [3626] [42] DEBUG: AT2[modem_032]: -- +CMGR: 0,,25
 2012-08-28 09:22:02 [3626] [42] DEBUG: AT2[modem_032]: --
 07918405210077F79EC00B918405566182F6218082900332802180829003828000
 2012-08-28 09:22:02 [3626] [42] DEBUG: AT2[modem_032]: received message from 
 SMSC: +48501200777
 2012-08-28 09:22:02 [3626] [42] ERROR: AT2[modem_032]: could not decode PDU 
 to a message.
 2012-08-28 09:22:02 [3626] [42] DEBUG: AT2[modem_032]: -- OK


 ...but some DLRs are processed correctly:


 2012-08-28 08:48:54 [3626] [42] DEBUG: AT2[modem_032]: -- +CDSI: SM,0
 2012-08-28 08:48:54 [3626] [42] DEBUG: AT2[modem_032]: +CMTI
 incoming SMS indication: +CDSI: SM,0
 2012-08-28 08:48:54 [3626] [42] DEBUG: AT2[modem_032]: -- ^MODE:3,3
 2012-08-28 08:48:56 [3626] [42] DEBUG: AT2[modem_032]: -- AT+CMGR=0^M
 2012-08-28 08:48:56 [3626] [42] DEBUG: AT2[modem_032]: -- +CMGR: 0,,25
 2012-08-28 08:48:56 [3626] [42] DEBUG: AT2[modem_032]: --
 07918405210077F706B90B918405693009F2218082807541802180828075918000
 2012-08-28 08:48:56 [3626] [42] DEBUG: AT2[modem_032]: received message from 
 SMSC: +48501200777
 2012-08-28 08:48:56 [3626] [42] DEBUG: AT2[modem_032]: got STATUS-REPORT for 
 message 185:
 2012-08-28 08:48:56 [3626] [42] DEBUG: AT2[modem_032]: Numeric
 receiver (international) +48509603XXX

 I've decoded both PDUs using a tool from
 http://www.diafaan.com/sms-tutorials/gsm-modem-tutorial/online-sms-pdu-decoder/
 and both could be decoded properly (as SMS-STATUS-REPORT).

 The one difference between those PDUs is that
 07918405210077F706B90B918405693009F2218082807541802180828075918000 has
 PDU header: 06 and
 07918405210077F79EC00B918405566182F6218082900332802180829003828000 has
 PDU header: 9E. I've made more tests and have seen that all DLRs with PDU
 header: 06 are decoded by kannel and processed correctly, but when PDU
 header: 9E than DLR isn't decoded properly and in logs there is could
 not decode PDU to a message message.

 Probably my GSM operator made some modifications and it delivers DLRs
 with 9E and 06 headers. I've looked into kannel source code but I
 can't find a place where to make modifications to have kannel decode
 PDU with 9E header correctly. Could you help me?

 Tomasz





 --
 Pozdrowienia,
  Tomasz

Re: DLRs - decoding PDU problem

[Tomasz]

Hi,

I'll offer 50 EUR for the first person who will help me modify kannel
sources to solve the described problem with DLRs.

Tomasz

W Twoim liście datowanym 30 sierpnia 2012 (12:36:59) można przeczytać:

 Hello,

 I'm using Kannel since few years as a core for gateway based on GSM
 modems (AT). Since few days I've got a problem with DLRs. I'm
 receiving only DLRs for some messages (before DLRs for all SMS were
 delivered correctly). No configuration changes were made from that
 time on my side. I've looked into logs and have seen that when
 receiving DLRs sometimes all is ok and sometimes there is could not
 decode PDU to a message message.

 2012-08-28 09:22:01 [3626] [42] DEBUG: AT2[modem_032]: -- +CDSI: SM,0
 2012-08-28 09:22:01 [3626] [42] DEBUG: AT2[modem_032]: +CMTI
 incoming SMS indication: +CDSI: SM,0
 2012-08-28 09:22:01 [3626] [42] DEBUG: AT2[modem_032]: -- ^MODE:3,3
 2012-08-28 09:22:02 [3626] [42] DEBUG: AT2[modem_032]: -- AT+CMGR=0^M
 2012-08-28 09:22:02 [3626] [42] DEBUG: AT2[modem_032]: -- +CMGR: 0,,25
 2012-08-28 09:22:02 [3626] [42] DEBUG: AT2[modem_032]: --
 07918405210077F79EC00B918405566182F6218082900332802180829003828000
 2012-08-28 09:22:02 [3626] [42] DEBUG: AT2[modem_032]: received message from 
 SMSC: +48501200777
 2012-08-28 09:22:02 [3626] [42] ERROR: AT2[modem_032]: could not decode PDU 
 to a message.
 2012-08-28 09:22:02 [3626] [42] DEBUG: AT2[modem_032]: -- OK


 ...but some DLRs are processed correctly:


 2012-08-28 08:48:54 [3626] [42] DEBUG: AT2[modem_032]: -- +CDSI: SM,0
 2012-08-28 08:48:54 [3626] [42] DEBUG: AT2[modem_032]: +CMTI
 incoming SMS indication: +CDSI: SM,0
 2012-08-28 08:48:54 [3626] [42] DEBUG: AT2[modem_032]: -- ^MODE:3,3
 2012-08-28 08:48:56 [3626] [42] DEBUG: AT2[modem_032]: -- AT+CMGR=0^M
 2012-08-28 08:48:56 [3626] [42] DEBUG: AT2[modem_032]: -- +CMGR: 0,,25
 2012-08-28 08:48:56 [3626] [42] DEBUG: AT2[modem_032]: --
 07918405210077F706B90B918405693009F2218082807541802180828075918000
 2012-08-28 08:48:56 [3626] [42] DEBUG: AT2[modem_032]: received message from 
 SMSC: +48501200777
 2012-08-28 08:48:56 [3626] [42] DEBUG: AT2[modem_032]: got STATUS-REPORT for 
 message 185:
 2012-08-28 08:48:56 [3626] [42] DEBUG: AT2[modem_032]: Numeric
 receiver (international) +48509603XXX

 I've decoded both PDUs using a tool from
 http://www.diafaan.com/sms-tutorials/gsm-modem-tutorial/online-sms-pdu-decoder/
 and both could be decoded properly (as SMS-STATUS-REPORT).

 The one difference between those PDUs is that
 07918405210077F706B90B918405693009F2218082807541802180828075918000 has
 PDU header: 06 and
 07918405210077F79EC00B918405566182F6218082900332802180829003828000 has
 PDU header: 9E. I've made more tests and have seen that all DLRs with PDU
 header: 06 are decoded by kannel and processed correctly, but when PDU
 header: 9E than DLR isn't decoded properly and in logs there is could
 not decode PDU to a message message.

 Probably my GSM operator made some modifications and it delivers DLRs
 with 9E and 06 headers. I've looked into kannel source code but I
 can't find a place where to make modifications to have kannel decode
 PDU with 9E header correctly. Could you help me?

 Tomasz





-- 
Pozdrowienia,
 Tomasz Konopka

RE: DLRs and the http smsc

[James Caradoc-Davies (Strike Media)]

Hi Gabor,

If you examine smsc_http.c you will see that status-success-regex is used
only by 'system-type = generic', not by 'kannel'.

Regards,

James

-Original Message-
From: users-boun...@kannel.org [mailto:users-boun...@kannel.org] On Behalf
Of Gabor Szucs
Sent: 10 May 2011 13:52
To: users@kannel.org
Subject: DLRs and the http smsc

Dear Nikos, Rene, Alexander and everyone else,

I'm sorry to bother this list and particularly the maintainers with this
question, but I'm puzzled about kannel's behavior (or my
ignorance) regarding DLRs and the http smsc.

I'm trying to set up kannel with opensmppbox  to route messages coming from
opensmppbox to an external script. I've accomplished this task and I also
moved on to DLRs.
Believe me I've RTFM and I've seen the list archives, e.g. the esme and
http smsc delivery report and generic http smsc statuses
threads.
However, I've noticed that due to my lack of experience I cannot set up the
http smsc with neither (generic or kannel) system-type to generate simple
[accept|reject] DLRs based on the text returned by my script.

DLRs for _rejected_ messages get through nicely (awesome job with Kannel
BTW), but those that actually match the 'status-success-regex'
are also marked as UNDELIV

the relevant section of my kannel.conf:

smsc = http
smsc-id = 
system-type = kannel
# or generic
smsc-username = whatever
smsc-password = ditto
# or without these
port = n
send-url =
http://host.name.tld/receive_sms_from_kannel.scr?from=%Pto=%ptext=%bdlr-
url=%R
# or without the query part
log-level = 0
reroute-dlr = true
generic-param-dlr-mask = 24
# 28? 63?
status-success-regex = queued


the bearerbox output of a successfully queued (accepted) session:

2011-05-10 11:29:44 [23906] [13] DEBUG:   data: 2e 34 2e 32 38 0d 0a
0d 0a 71 75 65 75 65 64  .4.28queued
2011-05-10 11:29:44 [23906] [13] DEBUG: Octet string dump ends.
# end of HTTP transcript
2011-05-10 11:29:44 [23906] [8] DEBUG: SMSC[]: creating DLR message
2011-05-10 11:29:44 [23906] [8] DEBUG: SMSC[]: DLR = 578769f2
2011-05-10 11:29:44 [23906] [32] DEBUG: send_msg: sending msg to boxc:

2011-05-10 11:29:44 [23906] [32] DEBUG: boxc_sender: sent message to
188.65.177.89
2011-05-10 11:29:45 [23906] [31] DEBUG: boxc_receiver: got ack

the relevant output from opensmppbox:

2011-05-10 11:29:44 [11423] [15] DEBUG:  data: 69 64 3a 35 37 38
37 36 39 66 32 20 73 75 62 3a   id:578769f2 sub:
2011-05-10 11:29:44 [11423] [15] DEBUG:  data: 30 30 31 20 64 6c
76 72 64 3a 30 30 30 20 73 75   001 dlvrd:000 su
2011-05-10 11:29:44 [11423] [15] DEBUG:  data: 62 6d 69 74 20 64
61 74 65 3a 31 31 30 35 31 30   bmit date:110510
2011-05-10 11:29:44 [11423] [15] DEBUG:  data: 31 31 32 39 20 64
6f 6e 65 20 64 61 74 65 3a 31   1129 done date:1
2011-05-10 11:29:44 [11423] [15] DEBUG:  data: 31 30 35 31 30 31
31 32 39 20 73 74 61 74 3a 55   105101129 stat:U
2011-05-10 11:29:44 [11423] [15] DEBUG:  data: 4e 44 45 4c 49 56
20 65 72 72 3a 30 30 30 20 74   NDELIV err:000 t
2011-05-10 11:29:44 [11423] [15] DEBUG:  data: 65 78 74 3a 20 4e
41 43 4b 2f 71 75 65 75 65 64   ext: NACK/queued

I realize that I myself might have induced this behavior by not setting a
proper dlr-mask override somewhere, or it could be just normal, but it looks
quite similar to the negative reply (which has the same UNDELIV status), the
only difference being the appended 'queued' or 'noqueue' reply from my
application. Also it would by nicer to get a REJECTD status for these, too,
but I have no idea how to configure Kannel to achieve this result.
I expected a status update with the status set to 'ACCEPTD' - am I wrong? Or
- in other words - ho can I get Kannel to transmit a deliver_sm PDU with an
ACCEPTD status? I might have to brush up my skills in ANSI C. :)

Thanks in advance,
Gabor

Re: DLRs and the http smsc

[Gabor Szucs]

Hi James (and list),

Thanks for your comment
.
I realize that, and I tried the same with the 'generic' system-type,
as I wrote last time - I moved on to the 'kannel' system-type based on
one of the developers' reply to an earlier, similar question (I've
also quoted its subject line). I also saw a full opensmppbox config
attached to another post to this list where this option was used
inside a http smsc with system-type set to 'kannel'. Since I wrote my
last message to this list I realized that the DLRs he was referring to
work only in the opposite direction (an external application sending
messages through kannel to an SMSC and expecting delivery reports from
kannel).

In my case, a message arrives on an SMPP channel to opensmppbox -
bearerbox - http smsc - my script that actually sends the message
using an appliance, then status updates (accepted/rejected) should
propagate back to opensmppbox and finally, to the client.

In the meantime, I temporarily resolved this issue by adding an
strpos() check where the evaluation of DLR messages happens in
gw/opensmppbox.c for the string (queued/noqueue) that comes back from
my script in the HTTP response. I'm pretty sure you don't wanna know
the details of how I handled this and I surely wanna forget it soon,
but was also very tired and I needed a quick fix, too, so I didn't
have much of a choice. If you actually do care, here's what I did and
I don't even know how many ways I've broken opensmppbox by doing so:

dlvrd = octstr_imm(000);
switch (dlrtype) {
case DLR_UNDEFINED:
case DLR_NOTHING:
dlr_state = 8;
dlr_status = octstr_imm(REJECTD);
break;
case DLR_SUCCESS:
dlr_state = 2;
dlr_status = octstr_imm(DELIVRD);
dlvrd = octstr_imm(001);
break;
case DLR_BUFFERED:
dlr_state = 6;
dlr_status = octstr_imm(ACCEPTD);
break;
case DLR_SMSC_SUCCESS:
/* please note that this state does not quite conform
to the SMMP v3.4 spec */
dlr_state = 0;
dlr_status = octstr_imm(BUFFRED);
break;
case DLR_FAIL:
case DLR_SMSC_FAIL:
dlr_state = 5;
dlr_status = octstr_imm(UNDELIV);
break;
}

text = octstr_get_cstr(msg-sms.msgdata);

// here's what I added in a hurry
if (strstr(text, NACK/queued)) {
dlr_state = 6;
dlr_status = octstr_imm(ACCEPTD);
} else {
dlr_state = 8;
dlr_status = octstr_imm(REJECTD);
}

The point is that the backend allows for these two status updates
only; these are the only responses I can get from the gateway that
sends the messages, there's no DELIVRD or UNDELIV status or anything I
could map these to. I should handle temporary or permanent failures of
the environment later when I figure out how to do so.

Thanks again,
Gabor

On Wed, May 11, 2011 at 11:56 AM, James Caradoc-Davies (Strike Media)
ja...@strikemedia.co.za wrote:
 Hi Gabor,

 If you examine smsc_http.c you will see that status-success-regex is used
 only by 'system-type = generic', not by 'kannel'.

 Regards,

 James

 -Original Message-
 From: users-boun...@kannel.org [mailto:users-boun...@kannel.org] On Behalf
 Of Gabor Szucs
 Sent: 10 May 2011 13:52
 To: users@kannel.org
 Subject: DLRs and the http smsc

 Dear Nikos, Rene, Alexander and everyone else,

 I'm sorry to bother this list and particularly the maintainers with this
 question, but I'm puzzled about kannel's behavior (or my
 ignorance) regarding DLRs and the http smsc.

 I'm trying to set up kannel with opensmppbox  to route messages coming from
 opensmppbox to an external script. I've accomplished this task and I also
 moved on to DLRs.
 Believe me I've RTFM and I've seen the list archives, e.g. the esme and
 http smsc delivery report and generic http smsc statuses
 threads.
 However, I've noticed that due to my lack of experience I cannot set up the
 http smsc with neither (generic or kannel) system-type to generate simple
 [accept|reject] DLRs based on the text returned by my script.

 DLRs for _rejected_ messages get through nicely (awesome job with Kannel
 BTW), but those that actually match the 'status-success-regex'
 are also marked as UNDELIV

 the relevant section of my kannel.conf:

 smsc = http
 smsc-id = 
 system-type = kannel
 # or generic
 smsc-username = whatever
 smsc-password = ditto
 # or without these
 port = n
 send-url =
 http://host.name.tld/receive_sms_from_kannel.scr?from=%Pto=%ptext=%bdlr-
 url=%R
 # or without the query part
 log-level = 0
 reroute-dlr = true
 generic-param-dlr-mask = 24
 # 28? 63?
 status-success-regex = queued


 the bearerbox output of a successfully queued (accepted) session:

 2011-05-10 11:29:44 [23906] [13] DEBUG:   data: 2e 34 2e 32 38 0d 0a
 0d 0a 71 75 65 75 65 64      .4.28queued
 

Re: DLRs for concatenated messages

[Alvaro Cornejo]

Hi

That is the way kannel handles dlr for concatenated messages. There
has been several threads regarding how to improve this but nothing has
been done.


|-|
Envíe y Reciba Datos y mensajes de Texto (SMS) hacia y desde cualquier
celular y Nextel
en el Perú, México y en mas de 180 paises. Use aplicaciones 2 vias via
SMS y GPRS online
              Visitenos en www.perusms.NET www.smsglobal.com.mx y
www.pravcom.com



On Thu, Mar 24, 2011 at 1:29 PM, Toby Phipps
toby.phi...@nexmedia.com.sg wrote:
 Hi all,

 I'm seeing some strangeness with DLR handling of concatenated messages sent
 via SMPP in Kannel 1.5.0.

 I'm using MySQL for DLR storage and only the first message of the set
 generates a DLR in the database.  My provider, however, follows the specs
 and returns a DLR for each part. Kannel recognizes the first DLR and updates
 the database. When the DLRs for the remaining parts arrive, Kannel tries to
 find them in the database and fails, spitting out an error (see below).

 Specifically:

 1. When the submit_sm_resp PDU for the first message part arrives, Kannel
 happily creates the DLR in the database:

 2011-03-25 02:03:37 [5106] [10] DEBUG: SMPP PDU 0xc8ad960 dump:
 2011-03-25 02:03:37 [5106] [10] DEBUG:   type_name: submit_sm_resp
 2011-03-25 02:03:37 [5106] [10] DEBUG:   command_id: 2147483652 = 0x8004
 2011-03-25 02:03:37 [5106] [10] DEBUG:   command_status: 0 = 0x
 2011-03-25 02:03:37 [5106] [10] DEBUG:   sequence_number: 17 = 0x0011
 2011-03-25 02:03:37 [5106] [10] DEBUG:   message_id:
 2011-03-25 02:03:37 [5106] [10] DEBUG:    Octet string at 0xc8cbc50:
 2011-03-25 02:03:37 [5106] [10] DEBUG:      len:  20
 2011-03-25 02:03:37 [5106] [10] DEBUG:      size: 21
 2011-03-25 02:03:37 [5106] [10] DEBUG:      immutable: 0
 2011-03-25 02:03:37 [5106] [10] DEBUG:      data: 31 33 30 30 39 38 39 38 31
 37 36 36 36 31 38 33   1300989817666183
 2011-03-25 02:03:37 [5106] [10] DEBUG:      data: 30 34 30 32
 0402
 2011-03-25 02:03:37 [5106] [10] DEBUG:    Octet string dump ends.
 2011-03-25 02:03:37 [5106] [10] DEBUG: SMPP PDU dump ends.
 2011-03-25 02:03:37 [5106] [10] DEBUG: DLR[mysql]: Adding DLR
 smsc=MY-SMPP-CONNECTION, ts=13009898176661830402, src=test, dst=9,
 mask=31, boxc=smsbox
 2011-03-25 02:03:37 [5106] [10] DEBUG: adding DLR entry into database
 2011-03-25 02:03:37 [5106] [10] DEBUG: sql: INSERT INTO
 `smsgw_kannel_sms_dlr` (`smsc`, `timestamp`, `source`, `destination`,
 `service`, `url`, `mask`, `boxc_id`, `status`) VALUES (?, ?, ?, ?, ?, ?, ?,
 ?, 0)

 2. When the submit_sm_resp PDU for the subsequent message parts arrive,
 Kannel doesn't create a database DLR but instead appears to create one in
 memory (note the missing SQL):

 2011-03-25 02:03:38 [5106] [10] DEBUG: SMPP PDU 0xc8ad960 dump:
 2011-03-25 02:03:38 [5106] [10] DEBUG:   type_name: submit_sm_resp
 2011-03-25 02:03:38 [5106] [10] DEBUG:   command_id: 2147483652 = 0x8004
 2011-03-25 02:03:38 [5106] [10] DEBUG:   command_status: 0 = 0x
 2011-03-25 02:03:38 [5106] [10] DEBUG:   sequence_number: 18 = 0x0012
 2011-03-25 02:03:38 [5106] [10] DEBUG:   message_id:
 2011-03-25 02:03:38 [5106] [10] DEBUG:    Octet string at 0xc8d1d80:
 2011-03-25 02:03:38 [5106] [10] DEBUG:      len:  20
 2011-03-25 02:03:38 [5106] [10] DEBUG:      size: 21
 2011-03-25 02:03:38 [5106] [10] DEBUG:      immutable: 0
 2011-03-25 02:03:38 [5106] [10] DEBUG:      data: 31 33 30 30 39 38 39 38 31
 37 39 33 34 31 38 34   1300989817934184
 2011-03-25 02:03:38 [5106] [10] DEBUG:      data: 30 34 30 32
 0402
 2011-03-25 02:03:38 [5106] [10] DEBUG:    Octet string dump ends.
 2011-03-25 02:03:38 [5106] [10] DEBUG: SMPP PDU dump ends.
 2011-03-25 02:03:38 [5106] [10] DEBUG: SMSC[MY-SMPP-CONNECTION]: creating
 DLR message
 2011-03-25 02:03:38 [5106] [10] DEBUG: SMSC[MY-SMPP-CONNECTION]: DLR =

 3. When the deliver_sm PDU arrives for the first message part, it's
 correctly matched against the database, processed and deleted:

 2011-03-25 02:03:48 [5106] [10] DEBUG: SMPP PDU 0xc8ad960 dump:
 2011-03-25 02:03:48 [5106] [10] DEBUG:   type_name: deliver_sm
 2011-03-25 02:03:48 [5106] [10] DEBUG:   command_id: 5 = 0x0005
 2011-03-25 02:03:48 [5106] [10] DEBUG:   command_status: 0 = 0x
 2011-03-25 02:03:48 [5106] [10] DEBUG:   sequence_number: 8 = 0x0008
 2011-03-25 02:03:48 [5106] [10] DEBUG:   service_type: NULL
 2011-03-25 02:03:48 [5106] [10] DEBUG:   source_addr_ton: 0 = 0x
 2011-03-25 02:03:48 [5106] [10] DEBUG:   source_addr_npi: 0 = 0x
 2011-03-25 02:03:48 [5106] [10] DEBUG:   source_addr: 9
 2011-03-25 02:03:48 [5106] [10] DEBUG:   dest_addr_ton: 0 = 0x
 2011-03-25 02:03:48 [5106] [10] DEBUG:   dest_addr_npi: 0 = 0x
 2011-03-25 02:03:48 [5106] [10] DEBUG:   destination_addr: test
 2011-03-25 02:03:48 [5106] [10] DEBUG:   esm_class: 4 = 0x0004
 2011-03-25 

RE: DLRs for concatenated messages

[Toby Phipps]

Hi Alvaro,

Thanks for the feedback. Any insight into why it was implemented this way?
i.e. is there reason why each of the submit_sm_resp PDUs shouldn't generate
a separate DLR in the DB? The only reason I can come up with offhand is that
the current way probably handles misbehaving SMPP servers better - servers
that send one DLR per concatenated message rather than per part. However,
the current (broken, IMHO) behaviour could easily be maintained with a
config parameter.

Before I scope a patch to address this, any comments or disagreements?

Also, I haven't tried this with memory-only DLRs - is this an issue limited
to SQL DLR storage? From looking at my logs, it seems that a DLR is indeed
created in memory for the second and subsequent message parts, just not
written to the DB. 

Thanks,
Toby

-Original Message-
From: Alvaro Cornejo [mailto:cornejo.alv...@gmail.com] 
Sent: Friday, March 25, 2011 1:47 AM
To: Toby Phipps
Cc: users@kannel.org
Subject: Re: DLRs for concatenated messages

Hi

That is the way kannel handles dlr for concatenated messages. There has been
several threads regarding how to improve this but nothing has been done.


|---
--|
Envíe y Reciba Datos y mensajes de Texto (SMS) hacia y desde cualquier
celular y Nextel en el Perú, México y en mas de 180 paises. Use aplicaciones
2 vias via SMS y GPRS online
              Visitenos en www.perusms.NET www.smsglobal.com.mx y
www.pravcom.com



On Thu, Mar 24, 2011 at 1:29 PM, Toby Phipps toby.phi...@nexmedia.com.sg
wrote:
 Hi all,

 I'm seeing some strangeness with DLR handling of concatenated messages 
 sent via SMPP in Kannel 1.5.0.

 I'm using MySQL for DLR storage and only the first message of the set 
 generates a DLR in the database.  My provider, however, follows the 
 specs and returns a DLR for each part. Kannel recognizes the first DLR 
 and updates the database. When the DLRs for the remaining parts 
 arrive, Kannel tries to find them in the database and fails, spitting out
an error (see below).

 Specifically:

 1. When the submit_sm_resp PDU for the first message part arrives, 
 Kannel happily creates the DLR in the database:

 2011-03-25 02:03:37 [5106] [10] DEBUG: SMPP PDU 0xc8ad960 dump:
 2011-03-25 02:03:37 [5106] [10] DEBUG:   type_name: submit_sm_resp
 2011-03-25 02:03:37 [5106] [10] DEBUG:   command_id: 2147483652 = 
 0x8004
 2011-03-25 02:03:37 [5106] [10] DEBUG:   command_status: 0 = 
 0x
 2011-03-25 02:03:37 [5106] [10] DEBUG:   sequence_number: 17 = 
 0x0011
 2011-03-25 02:03:37 [5106] [10] DEBUG:   message_id:
 2011-03-25 02:03:37 [5106] [10] DEBUG:    Octet string at 0xc8cbc50:
 2011-03-25 02:03:37 [5106] [10] DEBUG:      len:  20
 2011-03-25 02:03:37 [5106] [10] DEBUG:      size: 21
 2011-03-25 02:03:37 [5106] [10] DEBUG:      immutable: 0
 2011-03-25 02:03:37 [5106] [10] DEBUG:      data: 31 33 30 30 39 38 39 
 38 31
 37 36 36 36 31 38 33   1300989817666183
 2011-03-25 02:03:37 [5106] [10] DEBUG:      data: 30 34 30 32
 0402
 2011-03-25 02:03:37 [5106] [10] DEBUG:    Octet string dump ends.
 2011-03-25 02:03:37 [5106] [10] DEBUG: SMPP PDU dump ends.
 2011-03-25 02:03:37 [5106] [10] DEBUG: DLR[mysql]: Adding DLR 
 smsc=MY-SMPP-CONNECTION, ts=13009898176661830402, src=test, 
 dst=9, mask=31, boxc=smsbox
 2011-03-25 02:03:37 [5106] [10] DEBUG: adding DLR entry into database
 2011-03-25 02:03:37 [5106] [10] DEBUG: sql: INSERT INTO 
 `smsgw_kannel_sms_dlr` (`smsc`, `timestamp`, `source`, `destination`, 
 `service`, `url`, `mask`, `boxc_id`, `status`) VALUES (?, ?, ?, ?, ?, 
 ?, ?, ?, 0)

 2. When the submit_sm_resp PDU for the subsequent message parts 
 arrive, Kannel doesn't create a database DLR but instead appears to 
 create one in memory (note the missing SQL):

 2011-03-25 02:03:38 [5106] [10] DEBUG: SMPP PDU 0xc8ad960 dump:
 2011-03-25 02:03:38 [5106] [10] DEBUG:   type_name: submit_sm_resp
 2011-03-25 02:03:38 [5106] [10] DEBUG:   command_id: 2147483652 = 
 0x8004
 2011-03-25 02:03:38 [5106] [10] DEBUG:   command_status: 0 = 
 0x
 2011-03-25 02:03:38 [5106] [10] DEBUG:   sequence_number: 18 = 
 0x0012
 2011-03-25 02:03:38 [5106] [10] DEBUG:   message_id:
 2011-03-25 02:03:38 [5106] [10] DEBUG:    Octet string at 0xc8d1d80:
 2011-03-25 02:03:38 [5106] [10] DEBUG:      len:  20
 2011-03-25 02:03:38 [5106] [10] DEBUG:      size: 21
 2011-03-25 02:03:38 [5106] [10] DEBUG:      immutable: 0
 2011-03-25 02:03:38 [5106] [10] DEBUG:      data: 31 33 30 30 39 38 39 
 38 31
 37 39 33 34 31 38 34   1300989817934184
 2011-03-25 02:03:38 [5106] [10] DEBUG:      data: 30 34 30 32
 0402
 2011-03-25 02:03:38 [5106] [10] DEBUG:    Octet string dump ends.
 2011-03-25 02:03:38 [5106] [10] DEBUG: SMPP PDU dump ends.
 2011-03-25 02:03:38 [5106] [10] DEBUG: SMSC[MY-SMPP-CONNECTION]: 
 creating DLR message
 2011-03-25 02:03:38 [5106] [10] DEBUG: SMSC[MY-SMPP-CONNECTION]: DLR =

 3

Re: DLRs for concatenated messages

[Alvaro Cornejo]

Hi

From my understanting - I'm not a developper- the issue is what to do
when only one part of the concatenated fails -resend the whole/failed
part- and how/when to validate the original full initial message. it
seems that type of messafe handling will require to have a separate
queue/buffer for concatenated messages in order to be able to track
the whole message.

Maybe you can do a search on the mailing list for concatenated
messages and will find the threads between devs people.

Regards

Alvaro



|-|
Envíe y Reciba Datos y mensajes de Texto (SMS) hacia y desde cualquier
celular y Nextel
en el Perú, México y en mas de 180 paises. Use aplicaciones 2 vias via
SMS y GPRS online
              Visitenos en www.perusms.NET www.smsglobal.com.mx y
www.pravcom.com



On Thu, Mar 24, 2011 at 2:00 PM, Toby Phipps
toby.phi...@nexmedia.com.sg wrote:
 Hi Alvaro,

 Thanks for the feedback. Any insight into why it was implemented this way?
 i.e. is there reason why each of the submit_sm_resp PDUs shouldn't generate
 a separate DLR in the DB? The only reason I can come up with offhand is that
 the current way probably handles misbehaving SMPP servers better - servers
 that send one DLR per concatenated message rather than per part. However,
 the current (broken, IMHO) behaviour could easily be maintained with a
 config parameter.

 Before I scope a patch to address this, any comments or disagreements?

 Also, I haven't tried this with memory-only DLRs - is this an issue limited
 to SQL DLR storage? From looking at my logs, it seems that a DLR is indeed
 created in memory for the second and subsequent message parts, just not
 written to the DB.

 Thanks,
 Toby

 -Original Message-
 From: Alvaro Cornejo [mailto:cornejo.alv...@gmail.com]
 Sent: Friday, March 25, 2011 1:47 AM
 To: Toby Phipps
 Cc: users@kannel.org
 Subject: Re: DLRs for concatenated messages

 Hi

 That is the way kannel handles dlr for concatenated messages. There has been
 several threads regarding how to improve this but nothing has been done.


 |---
 --|
 Envíe y Reciba Datos y mensajes de Texto (SMS) hacia y desde cualquier
 celular y Nextel en el Perú, México y en mas de 180 paises. Use aplicaciones
 2 vias via SMS y GPRS online
               Visitenos en www.perusms.NET www.smsglobal.com.mx y
 www.pravcom.com



 On Thu, Mar 24, 2011 at 1:29 PM, Toby Phipps toby.phi...@nexmedia.com.sg
 wrote:
 Hi all,

 I'm seeing some strangeness with DLR handling of concatenated messages
 sent via SMPP in Kannel 1.5.0.

 I'm using MySQL for DLR storage and only the first message of the set
 generates a DLR in the database.  My provider, however, follows the
 specs and returns a DLR for each part. Kannel recognizes the first DLR
 and updates the database. When the DLRs for the remaining parts
 arrive, Kannel tries to find them in the database and fails, spitting out
 an error (see below).

 Specifically:

 1. When the submit_sm_resp PDU for the first message part arrives,
 Kannel happily creates the DLR in the database:

 2011-03-25 02:03:37 [5106] [10] DEBUG: SMPP PDU 0xc8ad960 dump:
 2011-03-25 02:03:37 [5106] [10] DEBUG:   type_name: submit_sm_resp
 2011-03-25 02:03:37 [5106] [10] DEBUG:   command_id: 2147483652 =
 0x8004
 2011-03-25 02:03:37 [5106] [10] DEBUG:   command_status: 0 =
 0x
 2011-03-25 02:03:37 [5106] [10] DEBUG:   sequence_number: 17 =
 0x0011
 2011-03-25 02:03:37 [5106] [10] DEBUG:   message_id:
 2011-03-25 02:03:37 [5106] [10] DEBUG:    Octet string at 0xc8cbc50:
 2011-03-25 02:03:37 [5106] [10] DEBUG:      len:  20
 2011-03-25 02:03:37 [5106] [10] DEBUG:      size: 21
 2011-03-25 02:03:37 [5106] [10] DEBUG:      immutable: 0
 2011-03-25 02:03:37 [5106] [10] DEBUG:      data: 31 33 30 30 39 38 39
 38 31
 37 36 36 36 31 38 33   1300989817666183
 2011-03-25 02:03:37 [5106] [10] DEBUG:      data: 30 34 30 32
 0402
 2011-03-25 02:03:37 [5106] [10] DEBUG:    Octet string dump ends.
 2011-03-25 02:03:37 [5106] [10] DEBUG: SMPP PDU dump ends.
 2011-03-25 02:03:37 [5106] [10] DEBUG: DLR[mysql]: Adding DLR
 smsc=MY-SMPP-CONNECTION, ts=13009898176661830402, src=test,
 dst=9, mask=31, boxc=smsbox
 2011-03-25 02:03:37 [5106] [10] DEBUG: adding DLR entry into database
 2011-03-25 02:03:37 [5106] [10] DEBUG: sql: INSERT INTO
 `smsgw_kannel_sms_dlr` (`smsc`, `timestamp`, `source`, `destination`,
 `service`, `url`, `mask`, `boxc_id`, `status`) VALUES (?, ?, ?, ?, ?,
 ?, ?, ?, 0)

 2. When the submit_sm_resp PDU for the subsequent message parts
 arrive, Kannel doesn't create a database DLR but instead appears to
 create one in memory (note the missing SQL):

 2011-03-25 02:03:38 [5106] [10] DEBUG: SMPP PDU 0xc8ad960 dump:
 2011-03-25 02:03:38 [5106] [10] DEBUG:   type_name: submit_sm_resp
 2011-03-25 02:03:38

Re: DLRs using the generic HTTP content gateway

[Nikos Balkanas]

Hi,

Not with system-type generic. It doesn't provide a receive endpoint. You 
should use system-type kannel for that.


BR,
Nikos
- Original Message - 
From: Garth Patil garthpa...@gmail.com

To: Users mailing list users@kannel.org
Sent: Sunday, January 09, 2011 2:52 AM
Subject: DLRs using the generic HTTP content gateway



Hi,
I'm trying to use the generic system type with the HTTP content
gateway (smsc = http, system-type = generic). The content gateway I am
using provides a delivery report that is posted back to a specified
URL. Is it possible for Kannel to be the endpoint for this delivery
report, so that it can then forward the DLR to my application as it
normally would? I understand that I can have the endpoint in my
application, but I wanted to keep my DLR handling consistent, and make
sure everything is coming through Kannel.
Thanks,
Garth

Re: DLRs SMPP 5.0 compatibility

[Alejandro Guerrieri]

I think you're misreading the code. The mask values are not passed to the
SMPP driver as-is, but are just a way to tell the driver what to
send/request. In this case, the 0x20 value means that kannel should ask for
intermediate dlrs. This is not necessarily only for SMPP, other drivers
might implement it as well, using their respective values.

Check on gw/smsc/smsc_smpp.c, 16 (0x10) is used over the SMPP bind if the
mask has 0x20 in it:

if (DLR_IS_INTERMEDIATE(msg-sms.dlr_mask))
pdu-u.submit_sm.registered_delivery += 16;

Kannel's dlr-mask values doesn't necessarily match the values being sent
over the wire. In fact, values may differ from driver to driver, so even if
it could match for SMPP, might not for other drivers anyway.

Regards,

Alex

2010/1/15 Nikos Balkanas n...@amdtelecom.net

  Hi,

 There seems to be an incompatibility between kannel's DLR implementation
 and SMPP 5.0 spec. For example in the spec, Intermediate DLRs are defined as
 0x10 (p 130), whereas in kannel Intermediate DLRs have the value 0x20, and
 so forth. Why this discrepancy? Some SMScs claim that it is out of spec to
 use dlr-mask 63 and don't send DLRs in such cases.

 BR,
 Nikos

Re: DLRs with sqlbox

[seik]

works for me, but i use unique dlr-url set in sendsms request




-Original Message-
From: Juan Nin [EMAIL PROTECTED]
Sent: 14 ??? 2007 ?.
To: seik
Subject:DLRs with sqlbox 

 do DLRs work while using sqlbox?

 I see them getting inserted in sent_sms table, but the dlr_url is not
 being called

 thanks in advance,

 Juan

Re: DLRs

[Stipe Tolj]

Alejandro Guerrieri wrote:
Hi All,
I am having problems with the DLRs. One of my providers adds a 7_ before
the real message_id, so when the DLR finally arrives the number doesn´t
match, so Kannel ignores it.
ie: I submit a message with submit_sm and receives a submit_sm_response
with:
message_id: 7_0004EEC4
Then, when the DLR arrives, it says:
id:323268
323268 decimal is 4EEC4.
I've checked my MySQL DLRs and it stores the 7_0004EEC4, so when it comes
back looking for the DLR it doesn´t match anything.
I suppose I'll have to patch the DLR code to make it work (To ignore the
7_ part) In fact, I was told that I should ignore anything before the _
because that 7 might change in the near future for 107 or any other
number.
Any hints? My C skills are not top of the line, but I can manage a few lines
of code anyway.
now, as this is definetly unusual behavior from your SMSC provider, 
I'd say, yes, you'll have to patch Kannel here specifically for this 
scrappy SMPP dialect.

Another option would be to change the SELECT statement in the 
dlr_mysql code to parse out the after _ part and let that be the 
comparison part.

I guess it's up to you. Either patch the C code or the MySQL SQL 
statements ;)

Stipe
mailto:stolj_{at}_wapme.de
---
Wapme Systems AG
Vogelsanger Weg 80
40470 Düsseldorf, NRW, Germany
phone: +49.211.74845.0
fax: +49.211.74845.299
mailto:info_{at}_wapme-systems.de
http://www.wapme-systems.de/
---
-BEGIN PGP PUBLIC KEY BLOCK-
Version: GnuPG v1.2.2 (Cygwin)
mIsEP6mcYwEEAMDnUiUwrbb+xwTFWN6TxF2+XZu7/alwJMeCwMBRvXtPZqfjpPhS
OkBpU0F4TrVuugz1HINTSaJTYq10AzDQXp5NkyWgckqW79nPAWuOX0dicbJk+cN2
nM2TI4KaxUDe6u8hghNEnH/i2lXsUu9apnP/iixzV81VC2je3uc9hZpnAAYptEVT
dGlwZSBUb2xqIChUZWNobm9sb2d5IENlbnRlciAmIFJlc2VhcmNoIExhYikgPHRv
bGpAd2FwbWUtc3lzdGVtcy5kZT6ItAQTAQIAHgUCP6mcYwIbAwYLCQgHAwIDFQID
AxYCAQIeAQIXgAAKCRABV0w1BqPYRuSqA/wPzsQxao2YePENCtgRTrO86U6zg3sl
OcS6CJFI4FZP5h/xD3GRsNH1+MPSvZlomDdpFnr547DGz/Kq9MXuQwVvlVig5yWZ
K5dtKp1r5YLhxJQBhfirZbRFFnYmf19f18J8OoS28tuFVftDl1AIwJS3HLyBTv6H
g2HyLAEKQIp30Q==
=aYCI
-END PGP PUBLIC KEY BLOCK-

Re: DLRs

[Stipe Tolj]

Alejandro Guerrieri wrote:
Stipe,
You bet is unusual! Is madness!! :)))
I've tried changing the select statement (I started with the lazy way
since it´s a lot simpler to change a single sql statement thant to write
real C code). But I soon found out that not only it added the 7_ stuff,
but also changed the encoding base, so the submit_sm got encoded as HEX (ie:
7_00FF) and the deliver_sm got encoded in DECIMAL (ie: 255).
thats not a problem to Kannel. Refer to the user's guide to see how 
you configure the DLR ID mapping.

Stipe
mailto:stolj_{at}_wapme.de
---
Wapme Systems AG
Vogelsanger Weg 80
40470 Düsseldorf, NRW, Germany
phone: +49.211.74845.0
fax: +49.211.74845.299
mailto:info_{at}_wapme-systems.de
http://www.wapme-systems.de/
---
-BEGIN PGP PUBLIC KEY BLOCK-
Version: GnuPG v1.2.2 (Cygwin)
mIsEP6mcYwEEAMDnUiUwrbb+xwTFWN6TxF2+XZu7/alwJMeCwMBRvXtPZqfjpPhS
OkBpU0F4TrVuugz1HINTSaJTYq10AzDQXp5NkyWgckqW79nPAWuOX0dicbJk+cN2
nM2TI4KaxUDe6u8hghNEnH/i2lXsUu9apnP/iixzV81VC2je3uc9hZpnAAYptEVT
dGlwZSBUb2xqIChUZWNobm9sb2d5IENlbnRlciAmIFJlc2VhcmNoIExhYikgPHRv
bGpAd2FwbWUtc3lzdGVtcy5kZT6ItAQTAQIAHgUCP6mcYwIbAwYLCQgHAwIDFQID
AxYCAQIeAQIXgAAKCRABV0w1BqPYRuSqA/wPzsQxao2YePENCtgRTrO86U6zg3sl
OcS6CJFI4FZP5h/xD3GRsNH1+MPSvZlomDdpFnr547DGz/Kq9MXuQwVvlVig5yWZ
K5dtKp1r5YLhxJQBhfirZbRFFnYmf19f18J8OoS28tuFVftDl1AIwJS3HLyBTv6H
g2HyLAEKQIp30Q==
=aYCI
-END PGP PUBLIC KEY BLOCK-

Re: DLRs

[Alejandro Guerrieri]

Ops, I should have RTFM then...

I've read the guide many times but never noticed that (maybe because I've
never thought that was possible to do that).

I already did the function that cleans the 7_ and translates from binary
to hex on gw/dlr.c

At the beggining of dlr.c (line 64) I added:

static char * clean_ts ( char* ts ) {
   char * pos;
   char buf[10];
   int n;

   pos = strchr( ts, '_' );
   if ( pos != NULL ) {
 ts = strchr( ts, '_' );
ts++;
 n = sprintf( buf, %010d, strtol( ts, NULL, 16 ) );
 ts = buf;
   }
   return ts;
}

Then about line 490 also on gw/dlr.c, just after the dlr_add header:

void dlr_add(char *smsc, char *ts, char *src, char *dst,
 char *keyword, char *id, int mask)
{
//I ADDED THE FOLLOWING LINE
  ts = clean_ts ( ts );

That should fix it I think... I hope.

PS: I'm not precisely a C Language gurú :)

- Original Message - 
From: Stipe Tolj [EMAIL PROTECTED]
To: Alejandro Guerrieri [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Thursday, August 12, 2004 7:26 PM
Subject: Re: DLRs


 Alejandro Guerrieri wrote:

  Stipe,
 
  You bet is unusual! Is madness!! :)))
 
  I've tried changing the select statement (I started with the lazy way
  since it´s a lot simpler to change a single sql statement thant to write
  real C code). But I soon found out that not only it added the 7_
stuff,
  but also changed the encoding base, so the submit_sm got encoded as HEX
(ie:
  7_00FF) and the deliver_sm got encoded in DECIMAL (ie: 255).

 thats not a problem to Kannel. Refer to the user's guide to see how
 you configure the DLR ID mapping.

 Stipe

 mailto:stolj_{at}_wapme.de
 ---
 Wapme Systems AG

 Vogelsanger Weg 80
 40470 Düsseldorf, NRW, Germany

 phone: +49.211.74845.0
 fax: +49.211.74845.299

 mailto:info_{at}_wapme-systems.de
 http://www.wapme-systems.de/
 ---

 -BEGIN PGP PUBLIC KEY BLOCK-
 Version: GnuPG v1.2.2 (Cygwin)

 mIsEP6mcYwEEAMDnUiUwrbb+xwTFWN6TxF2+XZu7/alwJMeCwMBRvXtPZqfjpPhS
 OkBpU0F4TrVuugz1HINTSaJTYq10AzDQXp5NkyWgckqW79nPAWuOX0dicbJk+cN2
 nM2TI4KaxUDe6u8hghNEnH/i2lXsUu9apnP/iixzV81VC2je3uc9hZpnAAYptEVT
 dGlwZSBUb2xqIChUZWNobm9sb2d5IENlbnRlciAmIFJlc2VhcmNoIExhYikgPHRv
 bGpAd2FwbWUtc3lzdGVtcy5kZT6ItAQTAQIAHgUCP6mcYwIbAwYLCQgHAwIDFQID
 AxYCAQIeAQIXgAAKCRABV0w1BqPYRuSqA/wPzsQxao2YePENCtgRTrO86U6zg3sl
 OcS6CJFI4FZP5h/xD3GRsNH1+MPSvZlomDdpFnr547DGz/Kq9MXuQwVvlVig5yWZ
 K5dtKp1r5YLhxJQBhfirZbRFFnYmf19f18J8OoS28tuFVftDl1AIwJS3HLyBTv6H
 g2HyLAEKQIp30Q==
 =aYCI
 -END PGP PUBLIC KEY BLOCK-