I did a full inspection in every 0x00000045 error I've received and I guess you are right. It seems to be related to invalid prefixes (although they are well-formed phonenumbers) which were rejected by SMSC. So, I do not suggest anybody to consider 0x00000045 as a temporary error, for now. For malformed phonenumbers I receive error 0x0000000b.
> -----Original Message----- > From: Dima Milentiev [mailto:[EMAIL PROTECTED]] > Sent: ter�a-feira, 3 de setembro de 2002 04:09 > 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 > > > > > >
