Hi Stripe,

 

Thanks for committing these important fixes that we all need.

 

Kind Regards

 

Hillel Bilman

Manager eCommunicate

mailto:  <mailto:hbil...@ecommunicate.co.za> hbil...@ecommunicate.co.za

Cell: 083-2300002

Landline: 011-443-6164

Fax: 088-011-443-6164

 

Social Media marketing campaigns (Facebook, Google+, Twitter, LinkedIn etc)
–  Interactive Websites - .mobi Sites – Mobile Apps(Android, iPhone,
Blackberry, Nokia) -  Premium Rated SMSs and short codes - SMS competitions
and campaigns – Lead Generation - opt-in subscription Billing – MMS
campaigns - USSD campaigns - WAP - Outlook SMS – Bulk SMS and Bulk Email –
Email 2 SMS 2 Email - Developer Kit for Mobile Services integration - Voice
Over IP services

 

From: Juan Nin [mailto:jua...@gmail.com] 
Sent: 10 March 2014 06:53 PM
To: Hillel
Cc: Stipe Tolj; Kannel Devel
Subject: Re: bug in redmine

 

Hi guys!

 

Sorry, I was wrong, Stipe did commit the fixes (on January 6th), please see:

 

https://redmine.kannel.org/projects/kannel/repository/revisions/5075

https://redmine.kannel.org/projects/kannel/repository/revisions/5076

 

Regards.

 

 

On Tue, Feb 18, 2014 at 12:08 PM, <hbil...@ecommunicate.biz> wrote:

Hi Stipe,

 

I think we have now clarified it, the bug is
https://redmine.kannel.org/issues/658

Is Juan correct that you fixed this last year Dec but have not had the time
to commit to SVN?

Or is this bug still not fixed?

 

Kind Regards

 

Hillel Bilman

Manager eCommunicate

mailto:  <mailto:hbil...@ecommunicate.co.za> hbil...@ecommunicate.co.za

Cell: 083-2300002

Landline: 011-443-6164

Fax: 088-011-443-6164

 

Social Media marketing campaigns (Facebook, Google+, Twitter, LinkedIn etc)
–  Interactive Websites - .mobi Sites – Mobile Apps(Android, iPhone,
Blackberry, Nokia) -  Premium Rated SMSs and short codes - SMS competitions
and campaigns – Lead Generation - opt-in subscription Billing – MMS
campaigns - USSD campaigns - WAP - Outlook SMS – Bulk SMS and Bulk Email –
Email 2 SMS 2 Email - Developer Kit for Mobile Services integration 

 

From: Juan Nin [mailto:jua...@gmail.com] 
Sent: 14 February 2014 06:12 AM
To: marc.bazi...@orange.com
Cc: Hillel; Alexander Malysh; Kannel Devel; Stipe Tolj
Subject: Re: bug reporting about the retry of message when smpp gateway
receive error code from smsc

 

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, <marc.bazi...@orange.com> 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:hbil...@ecommunicate.co.za] De la part de
hbil...@ecommunicate.biz
Envoyé : mardi 11 février 2014 22:44
À : 'Alexander Malysh'
Cc : devel@kannel.org; 'Stipe Tolj'; jua...@gmail.com;
marc.bazi...@orange.com
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: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 <tel:%28%2B262%29%2002%2062%2023%2016%2014> 
>> mob. (+262) 06 92 08 03 92 <tel:%28%2B262%29%2006%2092%2008%2003%2092> 
>> 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>
>>
>>
>>
>
>




____________________________________________________________________________
_____________________________________________


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.

 

 

Reply via email to