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
-------------------------------------------------------------------