First things first, I've retyped that SMPP error code document and made it
available on our very minimalist website (http://www.skywire.co.uk) - it's a
great thing to have at your fingertips.

(slightly off topic) Let me look back at the list and find the changes that
were submitted for One2One/T-Motion. I'd obviously appreciate a diff.
against CVS ( :-) ) but if you're time is short don't worry. FYI O2
Interactive (not the SMSC part of O2 but their Internet division) have
created a propriatary XML interface that is similar to the One2One/T-Motion
one and we have to implement that for a client.

I'm pretty sure I can post this one back when we've done it :-)

Alex


----- Original Message -----
From: "Oded Arbel" <[EMAIL PROTECTED]>
To: "Alex Judd" <[EMAIL PROTECTED]>; "Dima Milentiev" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, September 03, 2002 8:03 PM
Subject: RE: [RFC] New temporary nack for Kannel SMPP module


>
> Oh, but we did :-) it was posted on the Kannel-devel list a couple of
weeks ago. unfortunatly, it requires some major modifications to Kannel
infrastructure, and since it never got good testing, it didn't make it into
the CVS.
> There was a good suggestion by Nisan Bloch on how to improve it, and when
we'll have the time we'll implement it and try again, but it the mean time -
if you want, I can generate it again against latest CVS and resubmit.
>
> --
> Oded Arbel
> m-Wise mobile solutions
> [EMAIL PROTECTED]
>
> +972-9-9581711 (116)
> +972-67-340014
>
> ::..
> To learn is to remember things that you know,
> to do is to demonstrate that you know them,
> to teach is to remind other people that they also know them.
> We are all learners, doers and teachers.
> -- Richard Bach
>
>
>
>
> > -----Original Message-----
> > From: Alex Judd [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, September 03, 2002 7:07 PM
> > To: Dima Milentiev
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: [RFC] New temporary nack for Kannel SMPP module
> >
> >
> > 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
> > > > > >
> > > > >
> > > >
> >
> >
> >


Reply via email to