Hi, yes, my first email was incorrect.
Alex Am 11.02.2014 um 19:44 schrieb <hbil...@ecommunicate.biz> <hbil...@ecommunicate.biz>: > Hi Alex, > > So you are saying that the issue Marc was having is based on these two > issues and your previous email to Marc that Kannel needs to be fixed, which > is placed below, is incorrect? > 1) sms-resend-frequency is set and is very low > 2) SMSC drops connection after throttling error > > Your email to Marc: >>> Hi Marc, >>> >>> the issue is due to fact that SMSC returns wrong error code to kannel. >>> 0x58 is throttling error and not queue full (which would be 0x14). >>> Therefore kannel will retry any temporarily errors. I know that there >>> was/is bug in the retry handling and I'm going to fix it in the near >>> future but if you want that also the old kannel clients don't have >>> any problem, please use appropriate errorcode in the SMSC. >>> >>> Thanks, >>> Alex > > Rgds > > -----Original Message----- > From: Alexander Malysh [mailto:malys...@gmail.com] On Behalf Of Alexander > Malysh > Sent: Tuesday, February 11, 2014 6:49 PM > To: Hillel > Cc: devel@kannel.org org; Stipe Tolj; jua...@gmail.com > Subject: Re: bug reporting about the retry of message when smpp gateway > receive error code from smsc > > Hi, > > as far as I see in the source code it should not happened. Even if we > receive throttling error AND SMSC link is still open, we put message into > retry queue which will be retried after sms-resend-frequency passed. > > Therefore I see in this case only 2 options how this can happen: > 1) sms-resend-frequency is set and is very low > 2) SMSC drops connection after throttling error > > Alex > > > Am 11.02.2014 um 16:00 schrieb <hbil...@ecommunicate.biz> > <hbil...@ecommunicate.biz>: > >> Hi, >> >> Any idea when the patch for retry handling will be submitted, as >> otherwise kannel will keep retrying if the SMSC returns the wrong >> error code to kannel? >> I'm concerned this patch will not be submitted and we will all move on >> to the next issue. >> >> Thanks >> Hillel >> >> ---------------------------------------------------------------------- >> >> Date: Wed, 5 Feb 2014 21:56:30 -0200 >> From: Juan Nin <jua...@gmail.com> >> To: Alexander Malysh <amal...@kannel.org> >> Cc: "devel@kannel.org org" <devel@kannel.org> >> Subject: Re: bug reporting about the retry of message when smpp >> gateway receive error code from smsc >> Message-ID: >> <CAL52o-1XMQ6+VJtHioFCsjexbTANSu24Vfw2mPF+YehQCi==m...@mail.gmail.com> >> Content-Type: text/plain; charset="iso-8859-1" >> >> Hi Alex! >> >> Stipe already fixed the retry logic during December, I guess he still >> has not commited his code. >> >> Regards. >> >> >> On Fri, Jan 24, 2014 at 2:09 PM, Alexander Malysh > <amal...@kannel.org>wrote: >> >>> Hi Marc, >>> >>> the issue is due to fact that SMSC returns wrong error code to kannel. >>> 0x58 is throttling error and not queue full (which would be 0x14). >>> Therefore kannel will retry any temporarily errors. I know that there >>> was/is bug in the retry handling and I'm going to fix it in the near >>> future but if you want that also the old kannel clients don't have >>> any problem, please use appropriate errorcode in the SMSC. >>> >>> Thanks, >>> Alex >>> >>> Am 24.01.2014 um 14:17 schrieb <marc.bazi...@orange.com> < >>> marc.bazi...@orange.com>: >>> >>> Hi >>> We faced to some trouble with application that use kannel. >>> A subscriber has got a limited number of message on the smsc queue >>> when he is unreachable. By example if a subscriber turned off his >>> mobile and someone or something send him message , the sms will be >>> placed on the inetrnal db from SMSC in order to send him when he will >>> be reachable again on the network. This db is called SFE "store and >>> forward engine" but the number of messages stored are limited . on >>> ournetwork the maximum message that is kept is 10. I f a susbcriber >>> has got his queue full and a application try to send him a new >>> message , the smsc will respond with a >>> 0x00000058 error code message to the smpp gateway. this error is in >>> fact a mapping of the error 0x00000014 "messag equeue full". >>> >>> The trouble we faced to is that kannel will try to send the message >>> back until the subscriber will receive it ( until he will turned on >>> the mobile ).Some of VAS service we used has got an huge traffic and >>> in some affiliate ( often in Africa country ) as one message generate >>> 6 retry per sec , it filled the capacity of the smsc and often it >>> make crash the smsc. Some workaround has been found in order to avoid >>> this crash but all the sms are loosed. This could be problematic when >>> we talk about sms that dealt with money exchange service. >>> >>> is there any way to manage the message that has not being taking by >>> the smsc due to some error , to keep the message into the smpp >>> gateway DB and do some retry rule to not loose the message. As far >>> as i can understand from the behaviour of kannel , there's a db used >>> for dlr , but is it foressen to do this kind of thing? >>> >>> I can send you any pcap trace , log , etc.... you want. >>> tell me if it is clear or not >>> >>> Thx by advance for your help and advice , Br Marc >>> >>> >>> <http://www.orange.com/> >>> *Marc Bazimon* >>> Expert skill center SMSC Comverse >>> Orange/OF/DO/DORM/DSI/DSM >>> t?l. (+262) 02 62 23 16 14 >>> mob. (+262) 06 92 08 03 92 >>> marc.bazi...@orange.com >>> >>> >>> _____________________________________________________________________ >>> _ ___________________________________________________ >>> >>> Ce message et ses pieces jointes peuvent contenir des informations >>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >>> exploites ou copies sans autorisation. Si vous avez recu ce message >>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi >>> que >> les pieces jointes. Les messages electroniques etant susceptibles >> d'alteration, Orange decline toute responsabilite si ce message a ete >> altere, deforme ou falsifie. Merci. >>> >>> This message and its attachments may contain confidential or >>> privileged information that may be protected by law; they should not >>> be >> distributed, used or copied without authorisation. >>> If you have received this email in error, please notify the sender >>> and >> delete this message and its attachments. >>> As emails may be altered, Orange is not liable for messages that have >>> been >> modified, changed or falsified. >>> Thank you. >>> >>> <orange_logo.gif> >>> >>> >>> >> >> >
