Hi all and many thanks to all that tried to assist. In the end this was a case of not reading the manual....
I had not explicitly set "sms-resend-retry" in the core group, and so kannel (as it should) was putting this messages in an infinite time cue and retrying them, since the operator response was a "System error - 8", and not a message specific error. I have set "sms-resend-retry" and now after the set number of attempts, the messages are considered dead, and a DLR 16 returned to my applications. Hope this helps somebody else with a similar problem, although the thread in the forum has drifted to more general considerations. Thanks again, Kyriacos Sakkas Sandesh K wrote: > very much acceptable that we queue; its asynchronous. > > But if some vendor gives you sufficient capacity; you are ready with > options of time-wait in apache or api levels which calls kannel > sendsms url to wait or handle this lengthy responses; whats wrong in it. > > this question do arise whereby we have seperate smpp connectivity with > o/p exclusively for MT billing. > > Complete revenue cycle gets disturbed whereby the content partners > pushes the content; but mt rejection eats up the revenue. > > I do agree dlr url is an options; but synchronous http response is > highly desirable in certain typical conditions. > > Regards > sandesh k > > On Sat, 05 Dec 2009 00:36:33 +0530 wrote > > > 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 > > </prism/writemail?mode=mail_to_individual&email=sandyk...@rediffmail.com&output=web&els=9f7d1dbec44c47f17b204f700a401c51> > > *To:* n...@amdtelecom.net > > </prism/writemail?mode=mail_to_individual&email=n...@amdtelecom.net&output=web&els=9f7d1dbec44c47f17b204f700a401c51> > > *Cc:* alejandro.guerri...@gmail.com > > </prism/writemail?mode=mail_to_individual&email=alejandro.guerri...@gmail.com&output=web&els=9f7d1dbec44c47f17b204f700a401c51> > ; users@kannel.org > > </prism/writemail?mode=mail_to_individual&email=us...@kannel.org&output=web&els=9f7d1dbec44c47f17b204f700a401c51> > > *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 > > > >> -------------------------------- > > > >> > > > > > > > > > > > > > -- 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 **
