----- Original Message ----- From: "Stipe Tolj" <[EMAIL PROTECTED]> To: "fred" <[EMAIL PROTECTED]> Cc: "devel" <[email protected]> Sent: Wednesday, December 20, 2006 11:29 PM Subject: Re: [RFC] Enhanced cascading SMSC routing
> Hi Fred, > > fred wrote: > > > Do you mean Invalid Destination ? > > not only. Actually and kind of NACK that hits us from the SMSC. Generally if > there is no structural error in the PDU, then the SMSC would obviously NACK > because of some invalid number range, yes. > > > 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. > > yep, that's the pre-route determination for MNP cases. That can still be made in > "front" of the "send via primary route". But what (ie.) if that route is blocked > due to heavy load, and you get "throttling" SMPP errors? Do you really want to > "wait"? or wouldn't it be good to pick the next "possible" route. > > > 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. > > agree here. We have CDR records (in access-log), but backend applications will > have a hard life in associating these. We could log the msg UUID to access-log, > but this would require to pass the UUID at HTTP response time of smsbox. Which > makes sense to me. Why don't we do that? We could add it simple in a HTTP header. Actually, if the DLR service returns the smscid, that should be enough ? > > > 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. > > ok, this means you want to "backport" the routing and re-routing logic to the > application. Is a legal concept. But I think this is the "base" of the > decissions we need to take care: will the app hand over the MT and kannel does > the routing magic and then inform the app about state and route? IMO this was > the core design of Kannel acting as SMS gateway. This smsc routing capability discussed here would be really useful to have before!! you start building your application. In our case the application has all the routing, for all our numbers/carriers in db and xml files, and is designed to command where a msg gets sent, it would barf if our kannel implementation tried to tell the app where the message really went - too much ingrained history in the app. But i'm not discouraging this idea, i thinks it is definitely worthwhile. > > > 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. > > aha? what is that? ;) > Normally,a carrier binds our source number to a particular bind (smpp username) For one of our carriers we can use any of our assigned numbers to send MT on any bind we have with them, so we could load balance, but preferably I think in a priority fashion, The MO still is bound to the primary bind its assigned to. > 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 > -------------------------------------------------------------------
