One last suggestion -- sometimes the DLR is coming back, but it is coming
back in HEX and your internal DLR's are in OCTAL or DECIMAL.

msg-id-type should be set in your SMSC group for the SMPP connection.  For
me it is 0x01 == deliver_sm in DECIMAL and subint_sm_response in HEX.

If you see delivery reciepts in your logs (turn on log level 0) but it
"can't find that message" take a look at the ID of the message and see if
in the logs you can translate your message and the response together.

IE.  When I submit a message to the SMSC, I get a response (found this in
bearerbox.log):

2005-05-01 00:00:30 [12345] [1] DEBUG: SMPP[mysmsc]: Got PDU:
2005-05-01 00:00:30 [12345] [1] DEBUG: SMPP PDU 0x80f9500 dump:
2005-05-01 00:00:30 [12345] [1] DEBUG:   type_name: submit_sm_resp
2005-05-01 00:00:30 [12345] [1] DEBUG:   command_id: 2147483652 = 0x80000004
2005-05-01 00:00:30 [12345] [1] DEBUG:   command_status: 0 = 0x00000000
2005-05-01 00:00:30 [12345] [1] DEBUG:   sequence_number: 114815 = 0x0001c07f
2005-05-01 00:00:30 [12345] [1] DEBUG:   message_id: "1d903a5c"
2005-05-01 00:00:30 [12345] [1] DEBUG: SMPP PDU dump ends.

See the message_id?  It's in Hex (clearly).  1d903a5c == 495991388

Then, I get this DLR back:

2005-05-01 00:00:30 [12345] [1] DEBUG: SMPP[mysmsc]: Got PDU:
2005-05-01 00:00:30 [12345] [1] DEBUG: SMPP PDU 0x80f9600 dump:
2005-05-01 00:00:30 [12345] [1] DEBUG:   type_name: deliver_sm
2005-05-01 00:00:30 [12345] [1] DEBUG:   command_id: 5 = 0x00000005
2005-05-01 00:00:30 [12345] [1] DEBUG:   command_status: 0 = 0x00000000
2005-05-01 00:00:30 [12345] [1] DEBUG:   sequence_number: 127408 = 0x0001f1b0
2005-05-01 00:00:30 [12345] [1] DEBUG:   service_type: NULL
2005-05-01 00:00:30 [12345] [1] DEBUG:   source_addr_ton: 0 = 0x00000000
2005-05-01 00:00:30 [12345] [1] DEBUG:   source_addr_npi: 0 = 0x00000000
2005-05-01 00:00:30 [12345] [1] DEBUG:   source_addr: "13109184248"
2005-05-01 00:00:30 [12345] [1] DEBUG:   dest_addr_ton: 0 = 0x00000000
2005-05-01 00:00:30 [12345] [1] DEBUG:   dest_addr_npi: 0 = 0x00000000
2005-05-01 00:00:30 [12345] [1] DEBUG:   destination_addr: NULL
2005-05-01 00:00:30 [12345] [1] DEBUG:   esm_class: 4 = 0x00000004
2005-05-01 00:00:30 [12345] [1] DEBUG:   protocol_id: 0 = 0x00000000
2005-05-01 00:00:30 [12345] [1] DEBUG:   priority_flag: 0 = 0x00000000
2005-05-01 00:00:30 [12345] [1] DEBUG:   schedule_delivery_time: NULL
2005-05-01 00:00:30 [12345] [1] DEBUG:   validity_period: NULL
2005-05-01 00:00:30 [12345] [1] DEBUG:   registered_delivery: 0 = 0x00000000
2005-05-01 00:00:30 [12345] [1] DEBUG:   replace_if_present_flag: 0 = 0x00000000
2005-05-01 00:00:30 [12345] [1] DEBUG:   data_coding: 0 = 0x00000000
2005-05-01 00:00:30 [12345] [1] DEBUG:   sm_default_msg_id: 0 = 0x00000000
2005-05-01 00:00:30 [12345] [1] DEBUG:   sm_length: 103 = 0x00000067
2005-05-01 00:00:30 [12345] [1] DEBUG:   short_message:
2005-05-01 00:00:30 [12345] [1] DEBUG:    Octet string at 0x15ad3de0:
2005-05-01 00:00:30 [12345] [1] DEBUG:      len:  103
2005-05-01 00:00:30 [12345] [1] DEBUG:      size: 104
2005-05-01 00:00:30 [12345] [1] DEBUG:      immutable: 0
2005-05-01 00:00:30 [12345] [1] DEBUG:      data: 69 64 3a 35 30 34 33 37 39 32 
36 30 20 73 75 62   id:495991388 sub
2005-05-01 00:00:30 [12345] [1] DEBUG:      data: 3a 30 30 31 20 64 6c 76 72 64 
3a 30 30 31 20 73   :001 dlvrd:001 s
2005-05-01 00:00:30 [12345] [1] DEBUG:      data: 75 62 6d 69 74 20 64 61 74 65 
3a 30 35 31 31 31   ubmit date:05111
2005-05-01 00:00:30 [12345] [1] DEBUG:      data: 30 30 35 30 30 20 64 6f 6e 65 
20 64 61 74 65 3a   00500 done date:
2005-05-01 00:00:30 [12345] [1] DEBUG:      data: 30 35 31 31 31 30 30 35 30 30 
20 73 74 61 74 3a   0511100500 stat:
2005-05-01 00:00:30 [12345] [1] DEBUG:      data: 41 43 4b 45 44 20 20 20 65 72 
72 3a 30 30 33 20   ACKED   err:003
2005-05-01 00:00:30 [12345] [1] DEBUG:      data: 74 65 78 74 3a 20 00          
                    text: .
2005-05-01 00:00:30 [12345] [1] DEBUG:    Octet string dump ends.
2005-05-01 00:00:30 [12345] [1] DEBUG: SMPP PDU dump ends.
2005-05-01 00:00:30 [12345] [1] DEBUG: SMPP[mysmsc] handle_pdu, got DLR
2005-05-01 00:00:30 [12345] [1] DEBUG: DLR[internal]: Looking for DLR 
smsc=mysmsc, ts=495991388, dst=(null), type=4
2005-05-01 00:00:30 [12345] [1] DEBUG: DLR[internal]: created DLR message for URL 
<http://myurl/dlr.cgi?time=%t&to=%P&type=%d&smscr=%A&msgno=%I&billing=%B&resp=%a>

Note that ts=495991388 -- that equals 1d903a5c.  Now you know the messages are
the same.

Beckman

On Thu, 10 Nov 2005, Andi Taslim wrote:

Dear all,

Thank you so much to you both for the very helpful explanation. I've tried Mr. Tjatur suggestion by using timestamp, as well as by using the internal storage instead of mysql. Unfortunately, I'm still unable to get the DLR working, but now I'm pretty convinced that the problem is not Kannel's because I didn't even get the DLR message that Mr. Beckman pointed out from the log file (mine is named access.log in /logs folder). It could be on the SMSC side not being able to send me back the DLR... or there's a problem with my configuration.

I'll do further investigation on this and hopefully can figure this out soon. If anyone has any suggestion on what might be wrong with kannel configuration whatsoever that leads to this problem, please feel free to jump on in and share your thoughts. Again, thank you all.

Best regards,
-Andi

From: Peter Beckman <[EMAIL PROTECTED]>
To: Andi Taslim <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED], users@kannel.org
Subject: Re: [Kannel-Users] Re: Question about DLR
Date: Wed, 9 Nov 2005 10:28:58 -0500 (EST)
MIME-Version: 1.0
Received: from thermonuclear.org ([209.31.146.80]) by mc10-f20.hotmail.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 9 Nov 2005 07:28:46 -0800 Received: from thermonuclear.org ([EMAIL PROTECTED] [127.0.0.1])by thermonuclear.org (8.12.9/8.12.6) with ESMTP id jA9FT0cs034866;Wed, 9 Nov 2005 10:29:00 -0500 (EST)(envelope-from [EMAIL PROTECTED]) Received: from localhost ([EMAIL PROTECTED])by thermonuclear.org (8.12.9/8.12.6/Submit) with ESMTP id jA9FSxtL034863;Wed, 9 Nov 2005 10:28:59 -0500 (EST)(envelope-from [EMAIL PROTECTED])
X-Message-Info: JGTYoYF78jEHjJx36Oi8+Z3TmmkSEdPtfpLB7P/ybN8=
X-Authentication-Warning: thermonuclear.org: beckman owned process doing -bs
X-X-Sender: [EMAIL PROTECTED]
References: <[EMAIL PROTECTED]>
Return-Path: [EMAIL PROTECTED]
X-OriginalArrivalTime: 09 Nov 2005 15:28:46.0605 (UTC) FILETIME=[46A99BD0:01C5E542]

DLR = 31 means you'll get all the delivery receipts.

Here's the process:

You hand kannel an sms via sendsms -- now kannel has the message.
Kannel gives the sms to the SMSC successfully (8) or fails (16) -- You get
a DLR from KANNEL for this success or failure.

All other DLRs come as a specially formatted SMS to kannel which kannel
recognizes as a DLR sms and calls your dlr-url.

If your SMSC does not hand back Delivery Receipts for sms messages, this is
why you never see dlr-url called again.

In kannel you would see messages like this that would indicate that kannel
is receiving DLR messages in the bearer-access.log:

2005-05-03 00:02:15 DLR SMS [SMSC:smsc1] [SVC:smsc1] [ACT:] [BINF:] [from:12345] [to:15555551212] [flags:-1:-1:-1:-1:4] [msg:103:id:703041200 sub:001 dlvrd:001 submit date:0505030502 done date:0505030502 stat:ACKED err:003 text: ] [udh:0:]

That's a nice DLR SMS.

Beckman

---------------------------------------------------------------------------
Peter Beckman                                                  Internet Guy
[EMAIL PROTECTED]                             http://www.purplecow.com/
---------------------------------------------------------------------------



---------------------------------------------------------------------------
Peter Beckman                                                  Internet Guy
[EMAIL PROTECTED]                             http://www.purplecow.com/
---------------------------------------------------------------------------

Reply via email to