Hi Dima I have the document pinned to my wall infront of me all the time as it's the best summary of error codes I've found, however it no longer looks like they have it available on their site so I'll put it into a quick word document. Shouldn't take more than 5 minutes.
As a trade, are you planning on releasing back your XML driver for connecting to One2One/TMobile in the UK?? :-) Regards Alex ----- Original Message ----- From: "Dima Milentiev" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, September 03, 2002 5:29 PM Subject: RE: [RFC] New temporary nack for Kannel SMPP module > Hi Alex, > > i've found that you once wrote: "There is a really good error message summary in a document I got from the > Geeks Co site for their smartSMPP product which has them all summarised in > Appendix B. I can probably dig it up if you can't find it." > Could you please try to find and send it? It will be very helpful for all working with SMPP. > > thanks for advanse, > > > 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: Tuesday, September 03, 2002 5:23 PM > To: Dima Milentiev; Oded Arbel > Cc: [EMAIL PROTECTED] > Subject: RE: [RFC] New temporary nack for Kannel SMPP module > > > 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 > > > > > > > > >
