Hi Alexander Thx for advice , i agree with you , the smsc ( Comverse supplier ) do some mapping of the queue full and replace it with a throttle error code. but this is not cleaver due to the fact that if the error code are throttling error , this means that the smsc has reach his limit capacity . therefore if kannel do retry on it , it will happen a snowball effect because smsc is already full and kannel will do lot of attempt of retry ( i count about 6 by sec ). This behaviour could make the thing worst. This is exactly what we can check on real network. On smsc side, there's some retry mechanism depending the nature of error and error group. by example , on permanent error ( like unknow subscriber )( this kind of error will cause the message to be rejected because no improvement could be happen ) and some temporaly error ( mobile not reachable , memory capacity exceeded ) for this type of error , the retry mechanism will have several step ( log , short ) until the end of life of the message will be reached. this behaviour avoid to load the network. Even if this type of mechanism are hard to be deploy because it use a db to store and forward the message, it could be gracefull to make a retry , let say, every 15 mns instead of 6 per sec. is it a way to configure this on kannel gateway? we can set a number of retry on the request but this will cause the message to be not received because , on absent subscriber cause , the subscriber has got his phone turned off ( for night by example ). The reason of smsc crash is that kannel will do retry but in a bulk. Thx by advance for advice Br Marc
_____ De : Alexander Malysh [mailto:[email protected]] De la part de Alexander Malysh Envoyé : vendredi 24 janvier 2014 20:09 À : [email protected] Cc : [email protected] org Objet : Re: bug reporting about the retry of message when smpp gateway receive error code from smsc 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.
