No. SMS is asynchronous. It works with queues within kannel and you don't know when it will be sent. You cannot keep the HTTP response to sendsms open that long.
BR, Nikos ----- Original Message ----- From: Sandesh K To: n...@amdtelecom.net Cc: alejandro.guerri...@gmail.com ; users@kannel.org Sent: Friday, December 04, 2009 8:46 PM Subject: Re: Re: Capturing submit_sm_resp NACK (command_status: 8) 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 > -------------------------------- >
