Do you mean Invalid Destination ? In our scenario, we would get that, if we sent the sms to the wrong carrier, In Australia there is number portability, and we look up another db (which we subscribe to for updates) to find out the carrier for a msisdn - the db is not exactly upto date. Anyway if the suggestion is to have the one kannel to connect to different carrier smsc, and then allow kannel to route the message as described by Stipe, the problem would be for our Application to know where it got sent - this is important for reconciling billing with each of the carriers.
So in our case, we would prefer this to be a application problem, rather than a Kannel problem, and we have already discussed in team meetings about the application doing just that. If its connections to the same carrier, it is not unlike the current load balancing ? but with a primary route, or priority based routing? This idea may be interesting in light of what i discovered about some of our binds. Fred ----- Original Message ----- From: "Stipe Tolj" <[EMAIL PROTECTED]> To: "Kannel Development list" <[email protected]> Sent: Wednesday, December 20, 2006 11:56 AM Subject: [RFC] Enhanced cascading SMSC routing > 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 > ------------------------------------------------------------------- > >
