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: [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
---
Re: [PATCH] Service routing based on the account field
Alejandro Guerrieri wrote:
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.
Hi Alejandro,
we have pretty hot temperatures currently in central europe, maybe it's because
of that... but I didn't get the point for this one :)
This sounds to me like you use a HTTP SMSC module (maybe even own API?) and then
use the passed 'account' field to 'represent' the smsc-id ?
So it seems to me that you have one inbound (MO) HTTP SMSC that passes you MOs
from several operators, and provides you an 'account id' whole passing the MO.
You put the MO into account and would like to route on smsbox level via account.
Right?
If this is the case, then Kannel does not know about that multi-plexing of
operators behing the logical _ONE_ HTTP SMSC. I'm not quite sure if we should
support this behaviour, since it does not corelate with generical architecture
assuptions of Kannel.
I'm currently between -0 and +0 for this, until none of you guys can explain why
this is the super-fancy-we-have-to-have-it-feature ;)
A GENERAL NOTE:
We, and I really think I can talk to others that contribute to Kannel and mostly
to those that have cvs write permission and those that shortly may have (we have
some candidates on the list ;) _appritiate_ any patch that people submit and
they feel it's a benefit to Kannel. So please don't get upsad, if we have our
critisicm on it. We try to deal with all corners of the perspective. Some
contributers do not, they see their own need and usually have a more subjective
way in seeing the need of a 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
I agree with Stipe on this one (for a change ;]).
Why don't you just use smsc-id for what you want to accomplish?
Or otherwise: Please explain more.
Rene Kluwen
Chimit
-Original Message-
From: Stipe Tolj [mailto:[EMAIL PROTECTED]
Sent: zaterdag 22 juli 2006 14:14
To: Alejandro Guerrieri
Cc: devel@kannel.org
Subject: Re: [PATCH] Service routing based on the account field
Alejandro Guerrieri wrote:
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.
Hi Alejandro,
we have pretty hot temperatures currently in central europe, maybe it's
because
of that... but I didn't get the point for this one :)
This sounds to me like you use a HTTP SMSC module (maybe even own API?) and
then
use the passed 'account' field to 'represent' the smsc-id ?
So it seems to me that you have one inbound (MO) HTTP SMSC that passes you
MOs
from several operators, and provides you an 'account id' whole passing the
MO.
You put the MO into account and would like to route on smsbox level via
account.
Right?
If this is the case, then Kannel does not know about that multi-plexing of
operators behing the logical _ONE_ HTTP SMSC. I'm not quite sure if we
should
support this behaviour, since it does not corelate with generical
architecture
assuptions of Kannel.
I'm currently between -0 and +0 for this, until none of you guys can explain
why
this is the super-fancy-we-have-to-have-it-feature ;)
A GENERAL NOTE:
We, and I really think I can talk to others that contribute to Kannel and
mostly
to those that have cvs write permission and those that shortly may have (we
have
some candidates on the list ;) _appritiate_ any patch that people submit and
they feel it's a benefit to Kannel. So please don't get upsad, if we have
our
critisicm on it. We try to deal with all corners of the perspective. Some
contributers do not, they see their own need and usually have a more
subjective
way in seeing the need of a 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
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.
Best regards,
Alejandro.
On 7/22/06, Stipe Tolj [EMAIL PROTECTED] wrote:
Alejandro Guerrieri wrote:
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.
Hi Alejandro,
we have pretty hot temperatures currently in central europe, maybe it's because
of that... but I didn't get the point for this one :)
This sounds to me like you use a HTTP SMSC module (maybe even own API?) and then
use the passed 'account' field to 'represent' the smsc-id ?
So it seems to me that you have one inbound (MO) HTTP SMSC that passes you MOs
from several operators, and provides you an 'account id' whole passing the MO.
You put the MO into account and would like to route on smsbox level via account.
Right?
If this is the case, then Kannel does not know about that multi-plexing of
operators behing the logical _ONE_ HTTP SMSC. I'm not quite sure if we should
support this behaviour, since it does not corelate with generical architecture
assuptions of Kannel.
I'm currently between -0 and +0 for this, until none of you guys can explain why
this is the super-fancy-we-have-to-have-it-feature ;)
A GENERAL NOTE:
We, and I really think I can talk to others that contribute to Kannel and mostly
to those that have cvs write permission and those that shortly may have (we have
some candidates on the list ;) _appritiate_ any patch that people submit and
they feel it's a benefit to Kannel. So please don't get upsad, if we have our
critisicm on it. We try to deal with all corners of the perspective. Some
contributers do not, they see their own need and usually have a more subjective
way in seeing the need of a 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
---
--
Alejandro Guerrieri
Magicom
http://www.magicom-bcn.net/
LinkedIn: http://www.linkedin.com/in/aguerrieri
[PATCH] Service routing based on the account field
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.
Hope it helps,
--
Alejandro Guerrieri
Magicom
http://www.magicom-bcn.net/
LinkedIn: http://www.linkedin.com/in/aguerrieri
Index: gw/smsbox.c
===
RCS file: /home/cvs/gateway/gw/smsbox.c,v
retrieving revision 1.267
diff -u -r1.267 smsbox.c
--- gw/smsbox.c 12 Jul 2006 18:44:55 - 1.267
+++ gw/smsbox.c 22 Jul 2006 02:27:17 -
@@ -1743,7 +1743,7 @@
} else {
trans = urltrans_find(translations, msg-sms.msgdata,
- msg-sms.smsc_id, msg-sms.sender,
msg-sms.receiver);
+ msg-sms.smsc_id, msg-sms.sender,
msg-sms.receiver, msg-sms.account);
if (trans == NULL) {
warning(0, No translation found for %s from %s to %s,
octstr_get_cstr(msg-sms.msgdata),
Index: gw/urltrans.c
===
RCS file: /home/cvs/gateway/gw/urltrans.c,v
retrieving revision 1.101
diff -u -r1.101 urltrans.c
--- gw/urltrans.c 24 Apr 2006 21:32:01 - 1.101
+++ gw/urltrans.c 22 Jul 2006 02:27:24 -
@@ -102,6 +102,8 @@
Octstr *footer;/* string to be appended to each SMS */
List *accepted_smsc; /* smsc id's allowed to use this service. If not set,
all messages can use this service */
+List *accepted_account; /* account id's allowed to use this service. If
not set,
+ all messages can use this service */
Octstr *name; /* Translation name */
Octstr *username; /* send sms username */
@@ -130,6 +132,7 @@
regex_t *keyword_regex; /* the compiled regular expression for the
keyword*/
regex_t *accepted_smsc_regex;
+regex_t *accepted_account_regex;
regex_t *allowed_prefix_regex;
regex_t *denied_prefix_regex;
regex_t *allowed_receiver_prefix_regex;
@@ -159,12 +162,12 @@
static void destroy_onetrans(void *ot);
static URLTranslation *find_translation(URLTranslationList *trans,
List *words, Octstr *smsc,
- Octstr *sender, Octstr *receiver, int
*reject);
+ Octstr *sender, Octstr *receiver, int
*reject, Octstr *account);
static URLTranslation *find_default_translation(URLTranslationList *trans,
Octstr *smsc, Octstr *sender,
Octstr *receiver,
- int *reject);
+ int *reject, Octstr *account);
static URLTranslation *find_black_list_translation(URLTranslationList *trans,
- Octstr *smsc);
+ Octstr *smsc, Octstr *account);
/***
@@ -273,7 +276,7 @@
URLTranslation *urltrans_find(URLTranslationList *trans, Octstr *text,
- Octstr *smsc, Octstr *sender, Octstr *receiver)
+ Octstr *smsc, Octstr *sender, Octstr *receiver,
Octstr *account)
{
List *words;
URLTranslation *t = NULL;
@@ -282,16 +285,16 @@
/* do not panic if text == NULL */
if (text != NULL) {
words = octstr_split_words(text);
-t = find_translation(trans, words, smsc, sender, receiver, reject);
+t = find_translation(trans, words, smsc, sender, receiver, reject,
account);
gwlist_destroy(words, octstr_destroy_item);
}
if (reject)
- t = find_black_list_translation(trans, smsc);
+ t = find_black_list_translation(trans, smsc, account);
if (t == NULL) {
- t = find_default_translation(trans, smsc, sender, receiver, reject);
+ t = find_default_translation(trans, smsc, sender, receiver, reject,
account);
if (reject)
- t = find_black_list_translation(trans, smsc);
+ t = find_black_list_translation(trans, smsc, account);
}
return t;
}
@@ -874,10 +877,11 @@
{
URLTranslation *ot;
Octstr *aliases, *url, *post_url, *post_xml, *text, *file, *exec;
-Octstr *accepted_smsc, *forced_smsc, *default_smsc;
+Octstr *accepted_smsc, *accepted_account, *forced_smsc, *default_smsc;
Octstr *grpname, *sendsms_user, *sms_service;
int is_sms_service;
