BTW - speaking of new drivers. as some of you may remember, at m-Wise we implemented a
driver for Omnitel Vodafone Italy's proprietary SMSC protocol - MAM. unfortunately, we
never got permission from them to release it to the public (have no clue why), but we
did get permission to release it on a commercial basis.
So currently our offer to the Kannel community it as follows : if you want it, you can
have it for free ;-)
--
Oded Arbel
m-Wise mobile solutions
[EMAIL PROTECTED]
+972-9-9581711 (116)
+972-67-340014
::..
Real questions asked by lawyers in real courts :
9)Q: I show you exhibit 3 and ask you if you recognize that picture.
A: That's me.
Q: Were you present when that picture was taken?
> -----Original Message-----
> From: Oded Arbel
> Sent: Tuesday, September 03, 2002 9:04 PM
> To: Alex Judd; Dima Milentiev
> Cc: [EMAIL PROTECTED]
> 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
> > > > > >
> > > > >
> > > >
> >
> >
> >
>
>
