[RFC] Enhanced cascading SMSC routing

Stipe Tolj <[email protected]>
Newsgroups gmane.comp.mobile.kannel.devel
Organization tolj.org system architecture
Message-ID <[email protected]>
Hi list,

Gottfried from Siemens ask me if Kannel is capable of acting in the way to 
"failback" to alternative routes (SMSC connections obviously) when the primary 
route is not "working".

Of course we can do this for the case the SMSC is generally not available in the 
term that it is in the state offline or re-connecting. If we hard-wire a smsc 
group with allowed-smsc-id and address a MT to that smsc-id, and the connection 
is online, bearerbox picks that "queue" and drops it to the protocol module layer.

After that we get either a ACK or NACK from the SMSC we interpret the MT as 
"Sent SMS" in access-log (hence success) or "FAILED SMS" (hence failure).

Now, I'd like to throw some thoughts into list's space in how to handle 
cascading routing. What does this mean?

This means re-routing decissions based on protocol specific ACK or (better) NACK 
states. Think of a SMPP server that responds with a negative submit_sm_resp PDU 
due to the fact that the destination MSISDN can't be reached, hence Kannel would 
know that that specific SMSC has been considered as "pimary" route, but fails 
and we consider a cascade of follow-up SMSCs to try.

Obviously this would need re-consideration of our routing logic at bearerbox 
layer. We need state control and state management on each MT (which is impacting 
performance in some sense), etc. etc.

Constructive thoughts on this please. (and not only: "yeah, we wanna have it, 
please code it. When is it gonna be available? Yesterday please." ;)

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
-------------------------------------------------------------------
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.