Hi Nikos Yes, you are correct. Terribly sorry for leaving out that vital piece of information.
Would this also work if we had the following situation: Bind to SMSC A goes down. Queue builds up to SMSC A. We stop processing. Reroute all SMSC A traffic to SMSC B only. We are quite specific about which SMSCs we want to use due to the fact of volume limitations and pricing. Lastly, is the Queue to the bearerbox file backed? So restarting the bearerbox will not lose all the SMS in the queue? Regards, 2010/10/11 Nikos Balkanas <nbalka...@gmail.com> > Hi, > > I imagine you specify the SMSc in your sendsms URL and force routing by > allowed-smsc-id and denied-smsc-id. You can change these configuration > variables to preferred-smsc-id instead of allowed (skip denied altogether), > restart bb to reload configuration and bb will load-balance queue to > remaining SMScs. > > BR, > Nikos > ----- Original Message ----- From: brett skinner > To: Users > Sent: Monday, October 11, 2010 10:45 AM > Subject: Rerouting SMSs > > > > Hi > > > We have had a couple of scenarios where a smsc that we are sending to > suddenly goes offline. We don't want to flood our bearerbox with SMS so we > only give it up to 400. When the smsc goes down we continue to try send to > that bind until the bearerbox queue is at about 400 then it stops and we no > longer send smss. At this point we get a notification that something is > stuck. We then go online and usually see that one of the binds have gone > down and its status is reconnecting. If the SMSC manages to sort out their > problems the bind is restored and we continue processing. The problem occurs > when the SMSC can't sort out their problem quickly. We stop sending SMSs > down that bind but there are still 400 odd waiting to go to that SMSC. > > > Is there a way to "re-route" all the queued sms that are waiting for the > disconnected bind to another bind that is functioning? We don't want to > loose the 400 and we don't want to wait until the connection is restored. > Some of the SMS are time sensitive. Not critically time sensitive just > within working hours etc. I read the UG but everything there seems to be > about setting up a reroute that is meant to a more permanent thing. We just > want to take what is in the queue and give it to another bind. We don't want > to make a permanent configuration change. > > > Regards, >
