Hi Mauricio, we have the same error if we're sending malformed message (with wrong destination address e.g.) And n this case it's not a temporary error i need resend after some time. I know that we sometime have problems to get appropriate information from provider but the best way properly to configure bind timeout get this information from him :-). May be we need to check enquire_link_resp return code and not continue to send messages untill it returns ESME_RBINDFAIL error code?
cheers, Dima Milentiev m-Wise Mobile Solutions [EMAIL PROTECTED] Mobile: +972 (55) 679229 Tel: +972 (9) 9581711 (ext: 116 or 120) -----Original Message----- From: Mauricio Ramos [mailto:[EMAIL PROTECTED]] Sent: Friday, August 30, 2002 10:28 PM To: Oded Arbel Cc: [EMAIL PROTECTED] Subject: [RFC] New temporary nack for Kannel SMPP module Importance: High Hi Oded, In accordance to my tests I found out and suggest you a new temporary nack for SMPP. I've seen this in smsc_smpp.c: ------------------------------------------ /* * Some SMPP error messages we come across */ enum { SMPP_ESME_RMSGQFUL = 0x00000014, SMPP_ESME_RTHROTTLED = 0x00000058 } SMPP_ERROR_MESSAGES; ------------------------------------------ The new temporary that should be enumerated is 0x00000045 (form SMPP3.4 espec: ESME_RSUBMITFAIL - submit_sm or submit_multi failed). It could be named "SMPP_ESME_RSUBMITFAIL" Why? This error happens when ESME does submit_sm a well-formed message but for some reason the bind has been timed out by the SMSC. Usually, SMPP_ENQUIRE_LINK_INTERVAL (defaulted to 30 seconds) only prevent this situation when SMSC is configured to timeout the connection in a period greater than SMPP_ENQUIRE_LINK_INTERVAL. I know I could increase SMPP_ENQUIRE_LINK_INTERVAL but I wouldn't allways know "bind timeout period" of the target SMSC. Unfortunatelly I'm still not able to write a patch (and do prefer not to be yet) but I'm very pleased to contribute suggesting and testing. what do you think about this? Regards. > -----Original Message----- > From: Oded Arbel [mailto:[EMAIL PROTECTED]] > > > -----Original Message----- > > From: Mauricio Ramos [mailto:[EMAIL PROTECTED]] > > > but I > > got a little bit confused how Kannel DOES behave CURRENTLY. > > Please confirm > > these statements: > > > > 1) Current Kannel CVS ALLWAYS removes message from store when > > he got ANY > > NACK from a SMPP SMSC, either temporary failure (ex. > > Throttling) or not (ex. > > Message Lenght). > > No. assuming current CVS, Kannel only removes messages from > store (and send DLR_SMSC_FAIL) for a non-temporary error. > > > 2) Current Kannel CVS NEVER resend messages when ANY failure > > occurs, either > > temporary failure or not. > > No. Kannel will resend messages if receiving a NACK of a type > which is defined as "termporary". there is a very simple > switch case, almost at the top of the SMPP module code which > sorts the NACK reasons to 'temporary' or 'malformed'. check it out. > > -- > Oded Arbel >
