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