You are right. Not relevant == irrelevant. Which means simply don't use it.
Stronger word than optional, I would think.
Anyway, I think that the consensus is for patching. Let's focus on that.
Nikos
----- Original Message -----
From: Alejandro Guerrieri
To: Nikos Balkanas
Cc: Latitude Test ; users
Sent: Monday, October 19, 2009 6:16 PM
Subject: Re: getting delivery report: delivery failure
not relevant !== optional. Where did you read "optional" or "can be removed"?
Again, this is NOT a standard, and it's documented by example, which it's
imho a flaw on the spec's strictness, but it is what it is.
The fact that most smsc's uses that format makes a strong point for kannel to
use it as well. For the small fraction of smscs that don't use it the only
alternative right now is to patch the source code, I'm afraid.
Regards,
Alejandro
2009/10/19 Nikos Balkanas <n...@amdtelecom.net>
Sorry, Alej,
You are in the wrong here. In the spec some of these fields are declared as
optional, and others as not:
msgid: The message ID allocated to the message by the SMSC when originally
submitted.
sub: Number of short messages originally submitted. This is only relevant
when the original message was submitted to a distribution list.The value is
padded with leading zeros if necessary.
dlvr: Number of short messages delivered. This is only relevant where the
original message was submitted to a distribution list.The value ispadded with
leading zeros if necessary.
err: Where appropriate this may hold a Network specific error code or an
SMSC error code for the attempted delivery of the message. These errors are
Network or SMSC specific and are not included here.
These can be omitted according to the spec. Furthermore, kannel doesn't
rely exclusively in sscanf , but also falls back in the old way, as stated in
the warning, where it manually scans for the variables it needs. In the old way
it is much more flexible.
@Test: I have provided you with a patch, please test and let's take it from
there.
Let's stop the spam, until it's needed.
BR,
Nikos
----- Original Message -----
From: Alejandro Guerrieri
To: Latitude Test
Cc: Nikos Balkanas ; users
Sent: Monday, October 19, 2009 5:50 PM
Subject: Re: getting delivery report: delivery failure
Sorry, what optional fields are you talking about? sub: and dlvrd: are
_not_ optional parameters but part of the "de facto standard" for DLR format.
The only "optional" parameter honored by kannel on DLR's is
"network_error_code" but it's not mandatory: if present, Kannel will use it to
determine if a DLR was successful, otherwise it'll rely solely on the DLR text
field.
Regards,
Alejandro
On Mon, Oct 19, 2009 at 4:42 PM, Latitude Test
<latitude...@googlemail.com> wrote:
I have SMPP 3.4 specs but it doesn't give any info on
mandatory/optional fields when it comes to DLR format.
2009/10/19 Nikos Balkanas <n...@amdtelecom.net>
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 <latitude...@googlemail.com>
Date: Mon, Oct 19, 2009 at 3:29 PM
Subject: Re: getting delivery report: delivery failure
To: Nikos Balkanas <n...@amdtelecom.net>
Cc: users <users@kannel.org>
Are you saying "dlvrd" and "sub" are mandatory for Kannel?
2009/10/19 Nikos Balkanas <n...@amdtelecom.net>
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 <latitude...@googlemail.com>
Date: Mon, Oct 19, 2009 at 1:31 PM
Subject: Re: getting delivery report: delivery failure
To: users <users@kannel.org>, Nikos Balkanas
<nbalka...@gmail.com>
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 <n...@amdtelecom.net>
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 <nbalka...@gmail.com>
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 <nbalka...@gmail.com>
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.
