Hmmm... standards aren't being followed? In my tests with Logica's SMSC wrong destination addresses are being notified with error ESME_RINVDSTADR 0x000000000b. Probably either you have a different configuration of TON/NPI or SMSC's behaviours are different or I might be precipitated to suggest such thing based on my environment.
I'll further try with a CMG's SMSC. Cheers > -----Original Message----- > From: Dima Milentiev [mailto:[EMAIL PROTECTED]] > Sent: domingo, 1 de setembro de 2002 08:01 > To: Mauricio Ramos; Oded Arbel > Cc: [EMAIL PROTECTED] > Subject: RE: [RFC] New temporary nack for Kannel SMPP module > > > 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 > > >
