Hi, here is an answer from BTC:
"Error code 0x45 usually means that there is a problem with the Source address you are submitting from . This could mean that your Aim is not set up to allow a message to be mobile terminated with this source address . " Dima. -----Original Message----- From: Dima Milentiev Sent: Tuesday, September 03, 2002 10:09 AM To: 'Mauricio Ramos'; Oded Arbel Cc: [EMAIL PROTECTED] Subject: RE: [RFC] New temporary nack for Kannel SMPP module Hi, yes, standarts are following, but i've tested now all our SMPP providers with wrong destination address and only one return 0x0b, others take that without problem either. I have in my notes reference about 0x45 as i described earlier but i don't remember where it was and can't recreate now. I'll add that as TMP error but before that i would like to ask people (SMSC providers) for additional information. And what about some reaction when received 0x0D (bind failed)? May be somebody from developers have had SMPP error codes with detailed description and donate it? I remember somebody from the list said about well described error codes from Greece (???) provider. sanks a lot, 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: Monday, September 02, 2002 8:38 PM To: Dima Milentiev; Oded Arbel Cc: [EMAIL PROTECTED] Subject: RE: [RFC] New temporary nack for Kannel SMPP module 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 > > >
