I've had the same experience, and there is a dirty work around for this; It should work setting dlr-mask=24 to give you a call to your url for rejected and acked, but it does not seem to work.
However, if you set dlr-mask=31 a dlr will get created, and your url will be called for both status 8 and 16. Keep in mind though that as a final 1 or 2 will never get sent from yoru operator, you will need to flush out your delivery reports now and then. Fredag 04 desember 2009 15:08:12 skrev Kyriacos Sakkas : > Hmm, I am using an oldish version, need to check if meta-data is there... > > Still the DLR returns nothing, not doubting you but at least on the > version I am running a DLR record does not even get created when its > NACked, so that something can be returned. > > > Kyriacos > > Alejandro Guerrieri wrote: > > Enabling dlr-mask and dlr-url will get you the NACK message as a DLR. > > If you're using latest CVS you'll get some extra values as meta-data > > as well. > > > > Regards, > > > > Alex > > > > On Fri, Dec 4, 2009 at 2:35 PM, Kyriacos Sakkas > > <kyria...@netsmart.com.cy <mailto:kyria...@netsmart.com.cy>> wrote: > > > > Firstly apologies to all if this is documented somewhere already, > > please > > point me there. > > > > I have a connection (SMPP3.4) where the operator decided not to > > use DLRs > > but reject submit_sm on Premium MT messages when an MSISDN does > > not have > > enough credit to receive. > > > > I need to pass this information to my application. Up to know, and on > > other connections, I would recieve on a similar situation a DLR 8 > > from kannel and then a 2/16 from the operator. > > > > Since this messages are now NACKed, nothing is returned. Other than > > treating messages with no DLR status after X minutes as failed, is > > there > > any way to pass this response out of kannel? > > Can this be made to include some message ID? > > > > Sample: > > 2009-12-03 12:53:45 [31692] [23] DEBUG: SMPP[conID]: Sending PDU: > > 2009-12-03 12:53:45 [31692] [23] DEBUG: SMPP PDU 0xb49152b8 dump: > > 2009-12-03 12:53:45 [31692] [23] DEBUG: type_name: submit_sm > > 2009-12-03 12:53:45 [31692] [23] DEBUG: command_id: 4 = 0x00000004 > > 2009-12-03 12:53:45 [31692] [23] DEBUG: command_status: 0 = > > 0x00000000 > > 2009-12-03 12:53:45 [31692] [23] DEBUG: sequence_number: 111 = > > 0x0000006f > > 2009-12-03 12:53:45 [31692] [23] DEBUG: service_type: NULL > > 2009-12-03 12:53:45 [31692] [23] DEBUG: source_addr_ton: 3 = > > 0x00000003 > > 2009-12-03 12:53:45 [31692] [23] DEBUG: source_addr_npi: 9 = > > 0x00000009 > > 2009-12-03 12:53:45 [31692] [23] DEBUG: source_addr: "xxxx" > > 2009-12-03 12:53:45 [31692] [23] DEBUG: dest_addr_ton: 1 = > > 0x00000001 > > 2009-12-03 12:53:45 [31692] [23] DEBUG: dest_addr_npi: 1 = > > 0x00000001 > > 2009-12-03 12:53:45 [31692] [23] DEBUG: destination_addr: > > "xxxxxxxx" 2009-12-03 12:53:45 [31692] [23] DEBUG: esm_class: 3 = > > 0x00000003 2009-12-03 12:53:45 [31692] [23] DEBUG: protocol_id: 0 = > > 0x00000000 2009-12-03 12:53:45 [31692] [23] DEBUG: priority_flag: 0 = > > 0x00000000 > > 2009-12-03 12:53:45 [31692] [23] DEBUG: schedule_delivery_time: > > NULL 2009-12-03 12:53:45 [31692] [23] DEBUG: validity_period: NULL > > 2009-12-03 12:53:45 [31692] [23] DEBUG: registered_delivery: 1 = > > 0x00000001 > > 2009-12-03 12:53:45 [31692] [23] DEBUG: replace_if_present_flag: 0 > > = 0x00000000 > > 2009-12-03 12:53:45 [31692] [23] DEBUG: data_coding: 0 = 0x00000000 > > 2009-12-03 12:53:45 [31692] [23] DEBUG: sm_default_msg_id: 0 = > > 0x00000000 > > 2009-12-03 12:53:45 [31692] [23] DEBUG: sm_length: 32 = 0x00000020 > > 2009-12-03 12:53:45 [31692] [23] DEBUG: short_message: > > 2009-12-03 12:53:45 [31692] [23] DEBUG: Octet string at > > 0xb49156c0: 2009-12-03 12:53:45 [31692] [23] DEBUG: len: 32 > > 2009-12-03 12:53:45 [31692] [23] DEBUG: size: 36 > > 2009-12-03 12:53:45 [31692] [23] DEBUG: immutable: 0 > > 2009-12-03 12:53:45 [31692] [23] DEBUG: data: 54 45 18 54 20 > > 41 16 > > 4f 3a 20 35 34 36 30 30 20 TE.T A.O: xxxxx > > 2009-12-03 12:53:45 [31692] [23] DEBUG: data: 18 54 4f 20 33 > > 30 36 > > 39 34 34 39 35 35 37 32 39 .TO xxxxxxxxxx > > 2009-12-03 12:53:45 [31692] [23] DEBUG: Octet string dump ends. > > 2009-12-03 12:53:45 [31692] [23] DEBUG: SMPP PDU dump ends. > > 2009-12-03 12:53:46 [31692] [23] WARNING: SMPP: PDU NULL terminated > > string (message_id) has no NULL. > > 2009-12-03 12:53:46 [31692] [23] DEBUG: SMPP[conID]: Got PDU: > > 2009-12-03 12:53:46 [31692] [23] DEBUG: SMPP PDU 0xb49152b8 dump: > > 2009-12-03 12:53:46 [31692] [23] DEBUG: type_name: submit_sm_resp > > 2009-12-03 12:53:46 [31692] [23] DEBUG: command_id: 2147483652 = > > 0x80000004 > > 2009-12-03 12:53:46 [31692] [23] DEBUG: command_status: 8 = > > 0x00000008 > > 2009-12-03 12:53:46 [31692] [23] DEBUG: sequence_number: 111 = > > 0x0000006f > > 2009-12-03 12:53:46 [31692] [23] DEBUG: message_id: NULL > > 2009-12-03 12:53:46 [31692] [23] DEBUG: SMPP PDU dump ends. > > 2009-12-03 12:53:46 [31692] [23] ERROR: SMPP[conID]: SMSC returned > > error > > code 0x00000008 (System Error) in response to submit_sm. > > > > > > thanks to all in advance, > > > > Kyriacos > > > > > > -- > > Kyriacos Sakkas > > Development Team > > Netsmart > > Tel: + 357 22 452565 > > Fax: + 357 22 452566 > > Email: kyria...@netsmart.com.cy <mailto:kyria...@netsmart.com.cy> > > http://www.netsmart.com.cy > > > > Taking Business to a New Level! > > > > ** Confidentiality Notice: The information contained in this email > > message may be privileged, confidential and protected from > > disclosure. If you are not the intended recipient, any dissemination, > > distribution, > > or copying of this email message is strictly prohibited. > > If you think that you have received this email message in error, > > please > > email the sender at kyria...@netsmart.com.cy > > <mailto:kyria...@netsmart.com.cy> ** > -- -------------------------------- Arne K. Haaje | www.drx.no T: 69 51 15 52 | M: 92 88 44 66 --------------------------------