Hi,
Faced similar issues with 2 major operators in India. But the question raised is that can it be made available as response message. DLR is more of an offline; inline would help the apps. Regards sandesh k On Sat, 05 Dec 2009 00:11:07 +0530 wrote >Hi, If it happens it doesn't go through dlr_add or dlr_find. Do you know which part of the code generates a "fake" DLR out of a NACK'd submit_sm_resp? This happens also with SMPPbox (NACK'd submit_sm_resp instead of DLR 016). Thanks, Nikos ----- Original Message ----- From: To: "Arne K. Haaje" ; "us...@kannel. us...@kannel. Org" Sent: Friday, December 04, 2009 5:03 PM Subject: Re: Capturing submit_sm_resp NACK (command_status: 8) > This works fine on latest cvs for sure. Dlr-mask 24 should give you ack > and nack, and also extra meta-data (error code, message I'd, etc). > > Regards, > > Alex > BlackBerry de movistar, allν donde estιs estα tu oficin@ > > -----Original Message----- > From: "Arne K. Haaje" > Date: Fri, 4 Dec 2009 15:40:16 > To: > Cc: Kyriacos Sakkas; Alejandro > Guerrieri > Subject: Re: Capturing submit_sm_resp NACK (command_status: 8) > > 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 >> > 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 >> > 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 >> > ** >> > > -- > -------------------------------- > Arne K. Haaje | www.drx.no > T: 69 51 15 52 | M: 92 88 44 66 > -------------------------------- >
