Hi,
You seem to have the spec. Just read which fields are mandatory from there.
Kannel requires mandatory fields. Kannel will use optional fields, if they
exist, but it doesn't reuire them. Optional fields are: sub, dlvrd & err. Read
the spec.
Nikos
----- Original Message -----
From: Latitude Test
To: users ; Nikos Balkanas
Sent: Monday, October 19, 2009 4:59 PM
Subject: Fwd: getting delivery report: delivery failure
I will contact my SMSC but I need to know exactly which fields are really
being used by Kannel to return the DLR status?. Seems to me that Kannel is
using optional fields like "sub" and "dlvrd". If thats true, then isn't is a
bug?
Quoting Nokos
Hi,
It seems that your SMSc is sending out the wrong DLR format. According to
SMPP 3.4 specs:
“
id:IIIIIIIIII sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done
date:YYMMDDhhmm stat:DDDDDDD err:E Text: . . . . . . . . .”
Several optional fields (sub, dlvrd, err) are missing, but also a required
field: "Text". Without it kannel cannot understand the DLR.
Contact your SMSc about it. They should comply to the SMPP spec.
BR,
Nikos
---------- Forwarded message ----------
From: Latitude Test <[email protected]>
Date: Mon, Oct 19, 2009 at 3:29 PM
Subject: Re: getting delivery report: delivery failure
To: Nikos Balkanas <[email protected]>
Cc: users <[email protected]>
Are you saying "dlvrd" and "sub" are mandatory for Kannel?
2009/10/19 Nikos Balkanas <[email protected]>
Yes, but it is required to be there. I am not making the spec.
Nikos
----- Original Message -----
From: Latitude Test
To: users ; Nikos Balkanas
Sent: Monday, October 19, 2009 2:49 PM
Subject: Fwd: getting delivery report: delivery failure
Adding to it, I saw Kannel sending me correct DLRs with another SMSC and
in the logs I saw the following:
dlvrd:001
sub:001
Text:.
The mendatory field Text does not contain any useful info here. How
kannel knows the status of the message then? Seems it uses the optional fields
which are "sub" and "dlvrd".
Please confirm.
Thanks.
---------- Forwarded message ----------
From: Latitude Test <[email protected]>
Date: Mon, Oct 19, 2009 at 1:31 PM
Subject: Re: getting delivery report: delivery failure
To: users <[email protected]>, Nikos Balkanas <[email protected]>
Thanks Nikos. But I do get "stat" field which contains some useful info.
Also I felt that the format is vendor specific and the missing fields are not
mandatory.
Quote from
http://www.nowsms.com/discus/messages/1/SMPP_v3_4_Issue1_2-24857.pdf:
The informational content of an SMSC Delivery Receipt may be inserted
into the
short_message parameter of the deliver_sm operation. The format for
this Delivery Receipt
message is SMSC vendor specific but following is a typical example of
Delivery Receipt report.
“id:IIIIIIIIII sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done
date:YYMMDDhhmm stat:DDDDDDD err:E Text: . . . . . . . . .”
Regards.
2009/10/19 Nikos Balkanas <[email protected]>
Hi,
It seems that your SMSc is sending out the wrong DLR format. According
to SMPP 3.4 specs:
“
id:IIIIIIIIII sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done
date:YYMMDDhhmm stat:DDDDDDD err:E Text: . . . . . . . . .”
Several optional fields (sub, dlvrd, err) are missing, but also a
required field: "Text". Without it kannel cannot understand the DLR.
Contact your SMSc about it. They should comply to the SMPP spec.
BR,
Nikos
----- Original Message -----
From: Latitude Test
To: users ; Nikos Balkanas
Sent: Monday, October 19, 2009 12:26 PM
Subject: Re: getting delivery report: delivery failure
Apologies for not sending the complete PDU before. Kindly review the
complete PDU and guide.
Thanks.
...
[7] DEBUG: SMPP[abc1]: Got PDU:
[7] DEBUG: SMPP PDU 8174bc0 dump:
[7] DEBUG: type_name: enquire_link_resp
[7] DEBUG: command_id: 2147483669 = 0x80000015
[7] DEBUG: command_status: 0 = 0x00000000
[7] DEBUG: sequence_number: 201551 = 0x0003134f
[7] DEBUG: SMPP PDU dump ends.
[11] DEBUG: SMPP[abc3]: Sending enquire link:
[11] DEBUG: SMPP PDU 8174bc0 dump:
[11] DEBUG: type_name: enquire_link
[11] DEBUG: command_id: 21 = 0x00000015
[11] DEBUG: command_status: 0 = 0x00000000
[11] DEBUG: sequence_number: 201628 = 0x0003139c
[11] DEBUG: SMPP PDU dump ends.
[11] DEBUG: SMPP[abc3]: Got PDU:
[11] DEBUG: SMPP PDU 8174bc0 dump:
[11] DEBUG: type_name: enquire_link_resp
[11] DEBUG: command_id: 2147483669 = 0x80000015
[11] DEBUG: command_status: 0 = 0x00000000
[11] DEBUG: sequence_number: 201628 = 0x0003139c
[11] DEBUG: SMPP PDU dump ends.
[11] DEBUG: SMPP[abc3]: Got PDU:
[11] DEBUG: SMPP PDU 8174bc0 dump:
[11] DEBUG: type_name: deliver_sm
[11] DEBUG: command_id: 5 = 0x00000005
[11] DEBUG: command_status: 0 = 0x00000000
[11] DEBUG: sequence_number: 2453831019 = 0x92427d6b
[11] DEBUG: service_type: NULL
[11] DEBUG: source_addr_ton: 1 = 0x00000001
[11] DEBUG: source_addr_npi: 1 = 0x00000001
[11] DEBUG: source_addr: "989352034309"
[11] DEBUG: dest_addr_ton: 0 = 0x00000000
[11] DEBUG: dest_addr_npi: 1 = 0x00000001
[11] DEBUG: destination_addr: "8601001"
[11] DEBUG: esm_class: 4 = 0x00000004
[11] DEBUG: protocol_id: 0 = 0x00000000
[11] DEBUG: priority_flag: 0 = 0x00000000
[11] DEBUG: schedule_delivery_time: NULL
[11] DEBUG: validity_period: NULL
[11] DEBUG: registered_delivery: 0 = 0x00000000
[11] DEBUG: replace_if_present_flag: 0 = 0x00000000
[11] DEBUG: data_coding: 0 = 0x00000000
[11] DEBUG: sm_default_msg_id: 0 = 0x00000000
[11] DEBUG: sm_length: 70 = 0x00000046
[11] DEBUG: short_message:
[11] DEBUG: Octet string at 8129850:
[11] DEBUG: len: 70
[11] DEBUG: size: 71
[11] DEBUG: immutable: 0
[11] DEBUG: data: 69 64 3a 32 34 35 31 37 33 33 31 33 34 20 73
75 id:2451733134 su
[11] DEBUG: data: 62 6d 69 74 20 64 61 74 65 3a 30 39 31 30 31
33 bmit date:091013
[11] DEBUG: data: 30 37 30 34 20 64 6f 6e 65 20 64 61 74 65 3a
30 0704 done date:0
[11] DEBUG: data: 39 31 30 31 33 30 39 35 31 20 73 74 61 74 3a
44 910130951 stat:D
[11] DEBUG: data: 45 4c 49 56 52 44
ELIVRD
[11] DEBUG: Octet string dump ends.
[11] DEBUG: SMPP PDU dump ends.
[11] DEBUG: SMPP[abc3] handle_pdu, got DLR
[11] DEBUG: SMPP[abc3]: Couldnot parse DLR string sscanf way,fallback
to old way. Please report!
[11] DEBUG: DLR[internal]: Looking for DLR smsc=abc3, ts=2451733134,
dst=491733114042, type=2
[11] DEBUG: DLR[internal]: created DLR message for URL
<http://192.xxx.xxx.xxx:80/DServlet?dlrStatus=%d&dlrData=%A>
[11] DEBUG: SMPP[abc3]: Sending PDU:
[11] DEBUG: SMPP PDU 81772b8 dump:
[11] DEBUG: type_name: deliver_sm_resp
[11] DEBUG: command_id: 2147483653 = 0x80000005
[11] DEBUG: command_status: 0 = 0x00000000
[11] DEBUG: sequence_number: 2453831019 = 0x92427d6b
[11] DEBUG: message_id: NULL
[11] DEBUG: SMPP PDU dump ends.
...
2009/10/16 Nikos Balkanas <[email protected]>
Hmm. Interesting. I misspelled "DLR" to "DKR" and I think this
caused the problem. When asking for detailed DLR excerpt from bb logs, I didn't
have half a PDU in mind! Are you trying to save lines on copy and paste? Please
resubmit the whole PDU entry from bb logs.
Nikos
----- Original Message -----
From: Latitude Test
To: users
Sent: Friday, October 16, 2009 11:21 AM
Subject: getting delivery report: delivery failure
This is what I see in the log:
DEBUG: data: 69 64 3a 32 34 35 31 37 33 33 31 33 34 20 73 75
id:2451733134 su
DEBUG: data: 62 6d 69 74 20 64 61 74 65 3a 30 39 31 30 31 33 bmit
date:091013
DEBUG: data: 30 37 30 34 20 64 6f 6e 65 20 64 61 74 65 3a 30 0704
done date:0
DEBUG: data: 39 31 30 31 33 30 39 35 31 20 73 74 61 74 3a 44
910130951 stat:D
DEBUG: data: 45 4c 49 56 52 44 ELIVRD
DEBUG: Octet string dump ends.
DEBUG: SMPP PDU dump ends.
DEBUG: SMPP[abc3] handle_pdu, got DLR
DEBUG: SMPP[abc3]: Couldnot parse DLR string sscanf way,fallback
to old way. Please report!
DEBUG: DLR[internal]: Looking for DLR smsc=abc3, ts=2451733134,
dst=491733114042, type=2
DEBUG: DLR[internal]: created DLR message for URL
<http://192.xxx.xxx.xxx:80/DServlet?dlrStatus=%d&dlrData=%A>
2009/10/13 Nikos Balkanas <[email protected]>
Hi,
Please post detailed bb logs with the respond_sm PDU from your
SMSc. I suspect that your SMSc is sending the wrong DKR.
BR,
Nikos
----- Original Message -----
From: Latitude Test
To: users
Sent: Tuesday, October 13, 2009 2:15 PM
Subject: getting delivery report: delivery failure
Hi all,
My kannel is configured to send me delivery reports for the
SMS messages:
?dlrStatus=%d&dlrData=%A&dlr-mask=7
From Kannel docs:
1: delivery success
2: delivery failure
4: message buffered
8: smsc submit
16: smsc reject
I was getting the correct response codes from Kannel but as
soon as I switched to another SMSC (SMPP), I am always getting status 2
(failure)
?dlrStatus=2... even though the message gets delivered to the
device.
What could be the problem here? How Kannel maps the return
codes from SMSC to the standard codes?
Thanks a lot.
