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 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 > >> -------------------------------- > >> > > > > > >
