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.

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 

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: <users@kannel.org>
> **>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.
> 




*****************************************************************************

This e-mail and any files transmitted with it are for the sole use
of the intended recipient(s) and may contain confidential and privileged
information. If you are not the intended recipient, please contact the 
sender by reply e-mail and destroy all copies of the original message.
 
Any unauthorized review, use, disclosure, dissemination, forwarding, 
printing or copying of this email or any action taken in reliance on 
this e-mail is strictly prohibited and may be unlawful.

*****************************************************************************

Reply via email to