Re: [RFC] enhancing SMSC routing - Re: routing from smsbox

----- Original Message ----- 
From: "Stipe Tolj" <[email protected]>
To: "fred" <[email protected]>
Cc: "devel" <[email protected]>
Sent: Saturday, January 13, 2007 1:33 AM
Subject: [RFC] enhancing SMSC routing - Re: routing from smsbox


> fred wrote:
>
> > not sure if this has come up before, but say if you want to route based
on the source number.
> >
> >
> > I think the best way may be to code a routing group for smsbox, to
convert source number to smsc-id,
> > and then rely on the already routing using smsc-id in bearerbox.
> >
> > I guess it would be too much recoding to have smsbox capable of
connecting to multiple bearerboxes though,
> > so each smsc-id bind used for this will be in the same bearerbox
instance
> >
> > any thoughts?
>
> Hi Fred,
>
> now... this implies even a more generic approach for routing.
>
> Currently we do mainly routing in bearerbox level. That's ok, when we use
the
> msg struct values to decide which wa to go. smsbox's user are out of scope
then.
>   Why do you want to hook the routing to smsbox? Because of user
(sendsms-user)
> management?

Yes, and because we mostly tend to use a bearerbox instance per bind,  but
its not that important,
in this case we will use multiple bind to the bearerbox instance, the binds
are like "testing"
and "production"

>
> In fact "setting" the smsc-id in the smsbox scope is ok to me, as far as
the
> user is aware how to "hard-wire" the smsc groups at bearerbox level (using
> allowed-smsc-id).

well, to keep things consistent, the code can still go in the bearerbox,
setting the smsc-id would
just preceed routing the message....?
eg in bb_box.c: deliver_sms_to_queue
   before the call to rc = smsc2_rout(msg);


long term is it worth thinking about capable routing from smsbox to multiple
bearerboxes ?
There is much ability currently the other way for MO/DLR.
It would involve horrendous changes to config description and smsbox code I
would guess.
But for environments like ours where there is mostly "bearerbox instance per
bind",
currently the application has a routing to decide which smsbox port (sendsms
url) is used,
it would be nice to have.

>
> I'm having a similar in terms of setting smsc-id in msg struct, but more
generic
> idea of doing routing for Kannel: using regex, or even better PCRE,
allowing
> matches on any of the msg fields, in && and/or || style.
>
> First approach:
>
>    group = route
>    regex = <msg->sms.<field>> == <regex> && <msg->sms.<field>> == <regex>
>    smsc-id = A
>
> Semanticcal this means:
>
> Set the smsc-id flag to A if the regex/PCRE match the msg struct fields,
so, ie:
>
>    group = route
>    regex = "sender == /^\d{5}/ && receiver == /^49|+49/ && service ==
/^foobar$/"
>    smsc-id = A
>
> any message that has a 5 digit source addr as has a german (49) MSISDN
> destination and is from customer 'foobar' should be set to flag A.
>
> The same mechanism could be used for denying (ie. SPAM protection):
>
>    group = route
>    regex = "sender == /^\d{5}/ && msgdata == /sex/"
>    smsc-id = DEAD
>
> where there is no SMSC route for smsc-id DEAD and hence bearerbox reports
NACK.
>
> A extention to this is chaining. Means we interpret the "route" group as
> "virtual smsc". Don't know exactly how to do this. Especially we would
need to
> "re-name" the ID fields, to make clear what we mean.
>
> Chaining would benefit in order not to "loop" the whole route group bunch
for
> every MT going to routing. So we end up faster in a final smsc-id
assignment.
>
> So.. some thoughts on this.
>
> 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
> -------------------------------------------------------------------

Hey, i really like that regex configurable idea,thats some good
thinking,,lol,when can we get it!
Fred