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.

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