Answers are inline ...
**>Subject: Re: bearerbox errormessage 1.3.2
**>From: shyam kumar <[EMAIL PROTECTED]>
**>Reply-To: [EMAIL PROTECTED]
**>To: Davy Chan <[EMAIL PROTECTED]>
**>Cc: [email protected]
**>In-Reply-To: <[EMAIL PROTECTED]>
**>References: <[EMAIL PROTECTED]>
**> <[EMAIL PROTECTED]>
**>Message-Id: <[EMAIL PROTECTED]>
**>Date: Wed, 05 Jan 2005 10:36:21 +0530
**>
**>Hi DC
**> The type = 2 means i suppose it is the Submit_SM being used by the SMPP
**>Server, and if type = 1 means it is the Deliver_SM used by the SMPP
**>Server.
No. Type 2 and Type 1 refer to the Delivery report type as represented
by Kannel. The different SMSC protocols might represent the DLR
status types differently.
BTW, an SMPP server cannot generate an submit_sm and send it to one
of it's clients. submit_sm are only for clients to use when sending
an MT SMS to the SMPP server for delivery (Section 4.4 of SMPP Protocol
Specfication v3.4).
The SMPP server uses deliver_sm to send a message to the
client (Section 4.6) or it can use data_sm (Section 4.7).
**>Here is the bearer log
**>
**>2005-01-05 10:21:07 [2218] [7] DEBUG: SMPP PDU dump ends.
**>2005-01-05 10:21:07 [2218] [7] DEBUG: SMPP[SMPP]: Got PDU:
**>2005-01-05 10:21:07 [2218] [7] DEBUG: SMPP PDU 0x819d698 dump:
**>2005-01-05 10:21:07 [2218] [7] DEBUG: type_name: submit_sm_resp
**>2005-01-05 10:21:07 [2218] [7] DEBUG: command_id: 2147483652 =
**>0x80000004
**>2005-01-05 10:21:07 [2218] [7] DEBUG: command_status: 0 = 0x00000000
**>2005-01-05 10:21:07 [2218] [7] DEBUG: sequence_number: 5 = 0x00000005
**>2005-01-05 10:21:07 [2218] [7] DEBUG: message_id: "772010500"
**>2005-01-05 10:21:07 [2218] [7] DEBUG: SMPP PDU dump ends.
**>2005-01-05 10:21:07 [2218] [7] DEBUG: DLR[mysql]: Adding DLR smsc=SMPP,
**>ts=772010500, src=Tanla, dst=919849339091, mask=7, boxc=
**>2005-01-05 10:21:07 [2218] [7] DEBUG: sql: INSERT INTO dlr (smsc, ts,
**>source, destination, service, url, mask, boxc, status) VALUES ('SMPP',
**>'772010500', 'xxxxx', 'xxxxxxxxxxxx', 'tester', '', '7', '', '0');
**>2005-01-05 10:21:07 [2218] [1] DEBUG: Dumping 0 messages and 0 acks to
**>store
**>2005-01-05 10:22:24 [2218] [7] DEBUG: SMPP[SMPP]: Got PDU:
**>2005-01-05 10:22:24 [2218] [7] DEBUG: SMPP PDU 0x819d698 dump:
**>2005-01-05 10:22:24 [2218] [7] DEBUG: type_name: deliver_sm
**>2005-01-05 10:22:24 [2218] [7] DEBUG: command_id: 5 = 0x00000005
**>2005-01-05 10:22:24 [2218] [7] DEBUG: command_status: 0 = 0x00000000
**>2005-01-05 10:22:24 [2218] [7] DEBUG: sequence_number: 16777216 =
**>0x01000000
**>2005-01-05 10:22:24 [2218] [7] DEBUG: service_type: NULL
**>2005-01-05 10:22:24 [2218] [7] DEBUG: source_addr_ton: 5 = 0x00000005
**>2005-01-05 10:22:24 [2218] [7] DEBUG: source_addr_npi: 1 = 0x00000001
**>2005-01-05 10:22:24 [2218] [7] DEBUG: source_addr: "xxxxx"
**>2005-01-05 10:22:24 [2218] [7] DEBUG: dest_addr_ton: 1 = 0x00000001
**>2005-01-05 10:22:24 [2218] [7] DEBUG: dest_addr_npi: 1 = 0x00000001
**>2005-01-05 10:22:24 [2218] [7] DEBUG: destination_addr: "919849339091"
**>2005-01-05 10:22:24 [2218] [7] DEBUG: esm_class: 4 = 0x00000004
**>2005-01-05 10:22:24 [2218] [7] DEBUG: protocol_id: 0 = 0x00000000
**>2005-01-05 10:22:24 [2218] [7] DEBUG: priority_flag: 3 = 0x00000003
**>2005-01-05 10:22:24 [2218] [7] DEBUG: schedule_delivery_time: NULL
**>2005-01-05 10:22:24 [2218] [7] DEBUG: validity_period: NULL
**>2005-01-05 10:22:24 [2218] [7] DEBUG: registered_delivery: 0 =
**>0x00000000
**>2005-01-05 10:22:24 [2218] [7] DEBUG: replace_if_present_flag: 0 =
**>0x00000000
**>2005-01-05 10:22:24 [2218] [7] DEBUG: data_coding: 0 = 0x00000000
**>2005-01-05 10:22:24 [2218] [7] DEBUG: sm_default_msg_id: 0 =
**>0x00000000
**>2005-01-05 10:22:24 [2218] [7] DEBUG: sm_length: 81 = 0x00000051
**>2005-01-05 10:22:24 [2218] [7] DEBUG: short_message:
**>2005-01-05 10:22:24 [2218] [7] DEBUG: Octet string at 0x819d450:
**>2005-01-05 10:22:24 [2218] [7] DEBUG: len: 81
**>2005-01-05 10:22:24 [2218] [7] DEBUG: size: 82
**>2005-01-05 10:22:24 [2218] [7] DEBUG: immutable: 0
**>2005-01-05 10:22:24 [2218] [7] DEBUG: data: 69 64 3a 20 73 75 62 3a
**>31 20 64 6c 76 72 64 3a id: sub:1 dlvrd:
**>2005-01-05 10:22:24 [2218] [7] DEBUG: data: 31 20 73 75 62 6d 69 74
**>20 64 61 74 65 3a 30 35 1 submit date:05
**>2005-01-05 10:22:24 [2218] [7] DEBUG: data: 30 31 30 35 31 30 30 39
**>20 64 6f 6e 65 20 64 61 01051009 done da
**>2005-01-05 10:22:24 [2218] [7] DEBUG: data: 74 65 3a 30 35 30 31 30
**>35 31 30 31 30 20 73 74 te:0501051010 st
**>2005-01-05 10:22:24 [2218] [7] DEBUG: data: 61 74 3a 44 45 4c 49 56
**>52 44 20 65 72 72 3a 20 at:DELIVRD err:
**>2005-01-05 10:22:24 [2218] [7] DEBUG: data: 20
**>2005-01-05 10:22:24 [2218] [7] DEBUG: Octet string dump ends.
**>2005-01-05 10:22:24 [2218] [7] DEBUG: SMPP PDU dump ends.
**>2005-01-05 10:22:24 [2218] [7] DEBUG: SMPP[SMPP] handle_pdu, got DLR
**>2005-01-05 10:22:24 [2218] [7] DEBUG: DLR[mysql]: Looking for DLR
**>smsc=SMPP, ts=, dst=919849339091, type=1
**>2005-01-05 10:22:24 [2218] [7] DEBUG: sql: SELECT mask, service, url,
**>source, destination, boxc FROM dlr WHERE smsc='SMPP' AND ts='';
**>2005-01-05 10:22:24 [2218] [7] DEBUG: no rows found
**>2005-01-05 10:22:24 [2218] [7] WARNING: DLR[mysql]: DLR for
**>DST<xxxxxxx339091> not found.
**>2005-01-05 10:22:24 [2218] [7] ERROR: SMPP[SMPP]: got DLR but could not
**>find message or was not interestedin it ts<> dst<xxxxxx339091>, type<1>
**>2005-01-05 10:22:24 [2218] [7] DEBUG: SMPP[SMPP]: Sending PDU:
**>2005-01-05 10:22:24 [2218] [7] DEBUG: SMPP PDU 0x819d378 dump:
**>2005-01-05 10:22:24 [2218] [7] DEBUG: type_name: deliver_sm_resp
**>2005-01-05 10:22:24 [2218] [7] DEBUG: command_id: 2147483653 =
**>0x80000005
**>2005-01-05 10:22:24 [2218] [7] DEBUG: command_status: 0 = 0x00000000
**>2005-01-05 10:22:24 [2218] [7] DEBUG: sequence_number: 16777216 =
**>0x01000000
**>2005-01-05 10:22:24 [2218] [7] DEBUG: message_id: NULL
**>2005-01-05 10:22:24 [2218] [7] DEBUG: SMPP PDU dump ends.
**>
**>may be the problem with the record being deleted as the limit = 1 that
**>comes and after that only the dlr report is sent from bearerbox to the
**>smsbox and as such there is no record the smsbox is saying
The problem in this DLR lookup is that the deliver_sm does not
carry any information pointing to which SMS this DLR represents.
This DLR did not have the message-id of the SMS the DLR was referring to.
The ASCII payload of the deliver_sm also reflects the fact
that the message-id this DLR represents was empty:
id: sub:1 dlvrd:
1 submit date:05
01051009 done da
te:0501051010 st
at:DELIVRD err:
As you can see, the message-id (id:) is blank. As a result,
Kannel has no value to use for the TS column (hence the
"SELECT mask, service, url, source, destination, boxc FROM dlr WHERE
smsc='SMPP' and ts='';"
SQL).
But, the DLR entry was added into the table with a ts='772010500'.
As a result, the select fails and you get the message:
ERROR: SMPP[SMPP]: got DLR but could not find message or was not interestedin
it ts<> dst<xxxxxx339091>, type<1>
**>
**>2005-01-05 10:07:25 [2191] [4] INFO: Starting delivery report <tester>
**>from <xxxxx>
**>2005-01-05 10:07:25 [2191] [9] ERROR: URL <> doesn't start with
**>`http://' nor `https://'
**>2005-01-05 10:07:25 [2191] [9] ERROR: Couldn't send request to <>
**>
**>May this information could find a place in your analyses.
**>Thanks in advance
**>
**>Shyam Kumar.
**>
**>
**>
**>
**>On Wed, 2005-01-05 at 10:05, Davy Chan wrote:
**>> **>From: "Willy Mularto" <[EMAIL PROTECTED]>
**>> **>To: <[email protected]>
**>> **>Subject: bearerbox errormessage 1.3.2
**>> **>Date: Wed, 5 Jan 2005 11:05:52 +0700
**>> **>
**>> **>Guys,
**>> **>I got these error messages in bearerbox.log:
**>> **>2005-01-05 11:06:25 [20155] [8] WARNING: DLR[internal]: DLR for
DST<3665>
**>> **>not found.
**>> **>2005-01-05 11:06:25 [20155] [8] ERROR: SMPP[3665]: got DLR but could
not
**>> **>find message or was not interestedin it ts<2032285895> dst<3665>,
type<2>
**>> **>
**>> **>What does it means? And why I almost always get status 2 (delivery
**>> **>failure), my GSM operator claim it doesn't their fault because the
other
**>> **>partners doesn't have problem with this issue.
**>>
**>> I get delivery failures (type=2) when the destination mobile phone
**>> runs out of space to store SMS.
**>>
**>> The warning ....
**>>
**>> I've had situations where I would issue a submit_sm with DLR
**>> requested and the SMPP server would immediately send me the DLR
**>> via a deliver_sm before sending me the submit_sm_resp. As
**>> a result, Kannel didn't have the DLR lookup table entry
**>> setup yet. I would get that message "... got DLR but could not
**>> find message or was not interested in it ...".
**>>
**>> What might be happening is that the SMSC is rejecting the submit_sm
**>> because the destination is refusing to accept more SMS and the
**>> SMSC no longer has any more space on it's queue to store the
**>> SMS.
**>>
**>> I would suggest you contact your operator and ask them to check
**>> if their queue is full for that particular destination address.
**>>
**>> See ya...
**>>
**>> d.c.
**>>
See ya...
d.c.
