Hi! Sorry, what you're saying might be related, but seems to be something different. The bug I'm saying that Stipe fixed during December is this:
https://redmine.kannel.org/issues/658 Regards. On Thu, Feb 13, 2014 at 7:23 AM, <[email protected]> wrote: > Hi Both > > setting up the two parameter sms-resend-freq and sms-resend-retry, > decrease > the risk of crashing the smsc in case of huge traffic coming from the smpp > gateway and also ( and it is not the least ) it allow to keep the message > instead of reject it and loose it. > The fact is that SMSC do some mapping of maximum queue full by a throttling > error , but again by setting up this two parameter , we have a workaround > that is correct. > > Br > Marc > > -----Message d'origine----- > De : Hillel Bilman [mailto:[email protected]] De la part de > [email protected] > Envoyé : mardi 11 février 2014 22:44 > À : 'Alexander Malysh' > Cc : [email protected]; 'Stipe Tolj'; [email protected]; > [email protected] > Objet : RE: bug reporting about the retry of message when smpp gateway > receive error code from smsc > > 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:[email protected]] On Behalf Of Alexander > Malysh > Sent: Tuesday, February 11, 2014 6:49 PM > To: Hillel > Cc: [email protected] org; Stipe Tolj; [email protected] > 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 <[email protected]> > <[email protected]>: > > > 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 <[email protected]> > > To: Alexander Malysh <[email protected]> > > Cc: "[email protected] org" <[email protected]> > > Subject: Re: bug reporting about the retry of message when smpp > > gateway receive error code from smsc > > Message-ID: > > <CAL52o-1XMQ6+VJtHioFCsjexbTANSu24Vfw2mPF+YehQCi== > [email protected]> > > 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 > <[email protected]>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 <[email protected]> < > >> [email protected]>: > >> > >> 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 > >> [email protected] > >> > >> > >> _____________________________________________________________________ > >> _ ___________________________________________________ > >> > >> 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> > >> > >> > >> > > > > > > > > > > _________________________________________________________________________________________________________________________ > > 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. > >
