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

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

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