Re: [STATUS] Kannel 1.4.1 stable release
On Fri, Sep 29, 2006 at 12:06:03AM +0200, Stipe Tolj wrote: Milan P. Stanic wrote: I made packages for Debian stable (Sarge) with smpp-throttle.patch. which patch exactly please? Can you reference this via mail subject, date and sender? Patch is posted to devel list by [EMAIL PROTECTED] 01 Aug 2006. http://www.mail-archive.com/devel@kannel.org/msg06082.html Best regards
Re: [Fwd: [PATCH] smpp smsc throttling]
All,
I was performing some checks on smpp throttling and found the same
behaviour as vincent found below but this time in smsc_smpp.c.
Specific behaviour I found was that I could dump a load of messages into
the queue and while there was no further activity the queue would drain
at the required throttling rate, however the moment extra activity
started, e.g receiving more messages, the throttling behaviour went out
the window and messages started draining at a much faster rate due to
the gwthread_sleep poll function exiting short of the required timeout.
I made a similar change to the code which appears to now provide correct
throttling behaviour.
Just wondering if there is a better place to put this as I suspect the
gwthread_sleep problem will be seen in all smsc adapters.
I've attached a patch for the code change.
The code base is the CVS code set from July 27.
Stuart.
anyone reviewed and voted for this patch?
Stipe
---
Kölner Landstrasse 419
40589 Düsseldorf, NRW, Germany
tolj.org system architecture Kannel Software Foundation (KSF)
http://www.tolj.org/ http://www.kannel.org/
mailto:st_{at}_tolj.org mailto:stolj_{at}_kannel.org
---
Re: [Fwd: [PATCH] smpp smsc throttling]
I need that we have to think about a global resolution of this issue.
The patch i've submited for emi/ucp smsc need to be implemented
in a higher level than inside the smsc driver.
Vincent.
- Original Message -
From: Stipe Tolj [EMAIL PROTECTED]
Cc: Kannel Development list devel@kannel.org
Sent: Friday, September 29, 2006 3:17 PM
Subject: Re: [Fwd: [PATCH] smpp smsc throttling]
All,
I was performing some checks on smpp throttling and found the same
behaviour as vincent found below but this time in smsc_smpp.c.
Specific behaviour I found was that I could dump a load of messages into
the queue and while there was no further activity the queue would drain
at the required throttling rate, however the moment extra activity
started, e.g receiving more messages, the throttling behaviour went out
the window and messages started draining at a much faster rate due to the
gwthread_sleep poll function exiting short of the required timeout.
I made a similar change to the code which appears to now provide correct
throttling behaviour.
Just wondering if there is a better place to put this as I suspect the
gwthread_sleep problem will be seen in all smsc adapters.
I've attached a patch for the code change.
The code base is the CVS code set from July 27.
Stuart.
anyone reviewed and voted for this patch?
Stipe
---
Kölner Landstrasse 419
40589 Düsseldorf, NRW, Germany
tolj.org system architecture Kannel Software Foundation (KSF)
http://www.tolj.org/ http://www.kannel.org/
mailto:st_{at}_tolj.org mailto:stolj_{at}_kannel.org
---
Re: [PATCH] Service routing based on the account field
Alejandro Guerrieri wrote:
Stipe, Rene,
We work with aggregators from around the world, and we are using many
flavors of the HTTP smsc modules (we even made a couple of modules to
support specific cases).
The scenario is exactly as you described it: The account field is used
to encode the real operator's smsc id, since the aggregator appears
to kannel as a single smsc.
Regarding architectural assumptions, I'll quote the user guide:
%o account identifier/information of incoming message. The value
depends on the SMSC module and has been introduced to allow the
forwarding of an operator ID from aggregator SMSCs to the application
layer, hence the smsbox HTTP calling instance.
So it seems that this was one of the purposes for the account field.
It looked logic to me to be able to do some routing on it, so that's
why I've made that patch.
It works for us, maybe it's useful for other people. I don't think it
hurts to have this feature available, but I'm not the one deciding
here :)
Regarding criticism, don't be afraid, I won't get mad at it, all the
contrary!
I don't pretend for you guys to include this patch in the core kannel at
all.
I've just feel that it's a nice feature to have and maybe other people
are having similar scenarios as I do, so making it public could help
other kannel users.
YOU (meaning core kannel developers in general) have all the rights in
the world to decide what's right and what's not regarding kannel.
I think maybe other kannel users may benefit from this patch, and
maybe if you consider it's worth having it on the core could be
applied to CVS, but as I've said before, that wasn't the reason why
I've send it.
Hi Alejandro,
ok, since this is a generic feature-add and no behaviour change, I'd be +0 on
getting this now to CVS.
Could you please resubmit the patch against current CVS and also include in the
patch section for the user's guide explaining the logic arround it.
Simply send it again to devel@ list as new thread and I'll glance over it and
commit.
Thanks.
Stipe
---
Kölner Landstrasse 419
40589 Düsseldorf, NRW, Germany
tolj.org system architecture Kannel Software Foundation (KSF)
http://www.tolj.org/ http://www.kannel.org/
mailto:st_{at}_tolj.org mailto:stolj_{at}_kannel.org
---
Re: [Fwd: [PATCH] smpp smsc throttling]
Vincent CHAVANIS wrote:
I need that we have to think about a global resolution of this issue.
The patch i've submited for emi/ucp smsc need to be implemented
in a higher level than inside the smsc driver.
yep, agree'ing here.
Stipe
---
Kölner Landstrasse 419
40589 Düsseldorf, NRW, Germany
tolj.org system architecture Kannel Software Foundation (KSF)
http://www.tolj.org/ http://www.kannel.org/
mailto:st_{at}_tolj.org mailto:stolj_{at}_kannel.org
---
Re: [PATCH] Service routing based on account field
Alejandro Guerrieri wrote:
Seems like the list server rejected my last email because of the
attachment, here goes again with the patch inline.
I've noticed there were no way for Kannel to do service routing based
on the account field. This is specially handy when you use an HTTP
module to receive messages and the smsc gets encoded on the account
field, so you get a single smsc with different accounts depending on
the carrier.
I'm attaching a patch that adds two new sms-service parameters:
accepted-account and accepted-account-regex. Their functionality it's
exactly as their smsc counterparts (accepted-smsc and
accepted-smsc-regex) only that they do their logic on the account
field.
The patch can also be downloaded from:
http://www.magicom-bcn.net/kannel/account-routing.patch
+0, Hillel voted +0 also (interpreting his answer ;)... so commited to cvs:
2006-09-29 Stipe Tolj stolj at kannel.org
* doc/userguide/userguide.xml: section on new 'accepted-account' and
'accepted-account-regex' config directives for sms-service group.
* gwlib/cfg.def: adding 'accepted-account' and 'accepted-account-regex'
config directives for sms-service group.
* gw/smsbox.c, gw/urltrans.[ch]: adding service routing based on account
field. This allows routing of MO messages depending on the account set
by an aggregative SMSC provider.
Patchset submited by Alejandro Guerrieri [EMAIL PROTECTED]
[Msg-Id: [EMAIL PROTECTED]]
[Msg-Id: [EMAIL PROTECTED]]
Thanks a lot for submitting!
Stipe
---
Kölner Landstrasse 419
40589 Düsseldorf, NRW, Germany
tolj.org system architecture Kannel Software Foundation (KSF)
http://www.tolj.org/ http://www.kannel.org/
mailto:st_{at}_tolj.org mailto:stolj_{at}_kannel.org
---
Re: [STATUS] Kannel 1.4.1 stable release
Please remove me from the mailing list I have unsubscribed 10 to 15 times over the last six months. From: Milan P. Stanic [EMAIL PROTECTED] To: Kannel Development list devel@kannel.org Subject: Re: [STATUS] Kannel 1.4.1 stable release Date: Fri, 29 Sep 2006 12:28:36 +0200 On Fri, Sep 29, 2006 at 12:06:03AM +0200, Stipe Tolj wrote: Milan P. Stanic wrote: I made packages for Debian stable (Sarge) with smpp-throttle.patch. which patch exactly please? Can you reference this via mail subject, date and sender? Patch is posted to devel list by [EMAIL PROTECTED] 01 Aug 2006. http://www.mail-archive.com/devel@kannel.org/msg06082.html Best regards
Re: [PATCH] Service routing based on the account field
Please unsubcribe me from this mailing list.
From: Stipe Tolj [EMAIL PROTECTED]
To: Alejandro Guerrieri [EMAIL PROTECTED]
CC: devel@kannel.org devel@kannel.org
Subject: Re: [PATCH] Service routing based on the account field
Date: Fri, 29 Sep 2006 15:27:13 +0200
Alejandro Guerrieri wrote:
Stipe, Rene,
We work with aggregators from around the world, and we are using many
flavors of the HTTP smsc modules (we even made a couple of modules to
support specific cases).
The scenario is exactly as you described it: The account field is used
to encode the real operator's smsc id, since the aggregator appears
to kannel as a single smsc.
Regarding architectural assumptions, I'll quote the user guide:
%o account identifier/information of incoming message. The value
depends on the SMSC module and has been introduced to allow the
forwarding of an operator ID from aggregator SMSCs to the application
layer, hence the smsbox HTTP calling instance.
So it seems that this was one of the purposes for the account field.
It looked logic to me to be able to do some routing on it, so that's
why I've made that patch.
It works for us, maybe it's useful for other people. I don't think it
hurts to have this feature available, but I'm not the one deciding
here :)
Regarding criticism, don't be afraid, I won't get mad at it, all the
contrary!
I don't pretend for you guys to include this patch in the core kannel at
all.
I've just feel that it's a nice feature to have and maybe other people
are having similar scenarios as I do, so making it public could help
other kannel users.
YOU (meaning core kannel developers in general) have all the rights in
the world to decide what's right and what's not regarding kannel.
I think maybe other kannel users may benefit from this patch, and
maybe if you consider it's worth having it on the core could be
applied to CVS, but as I've said before, that wasn't the reason why
I've send it.
Hi Alejandro,
ok, since this is a generic feature-add and no behaviour change, I'd be
+0 on getting this now to CVS.
Could you please resubmit the patch against current CVS and also include in
the patch section for the user's guide explaining the logic arround it.
Simply send it again to devel@ list as new thread and I'll glance over it
and commit.
Thanks.
Stipe
---
Kölner Landstrasse 419
40589 Düsseldorf, NRW, Germany
tolj.org system architecture Kannel Software Foundation (KSF)
http://www.tolj.org/ http://www.kannel.org/
mailto:st_{at}_tolj.org mailto:stolj_{at}_kannel.org
---
