BB doesn't loose any SMS in queue (except maybe the 1 processing when you
shutdown - shutdown when low traffic). You can reroute to any smsc you
desire. But you will have to restart bb to reload config.
BR,
Nikos
----- Original Message -----
From: brett skinner
To: Users
Sent: Monday, October 11, 2010 11:13 AM
Subject: Re: Rerouting SMSs
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,
