> Usually, everything is OK but yesterday, I saw a push request from
> operator_A routed to B SMSC account. Is it due to to the fact I didn't put
> "denied-smsc-id" directives in smsc groups ?
Was SMSC A available at that time - can you determine this from the
bearerbox log? Or see below.
> If true, is there another way to do that specific routing since I am going
> to have a lot of smsc accounts, and I don't want to specify all of them in
a
> "denied-smsc-id" directive.
If all you need to do is push out through either SMSC A or B per message,
then you should set preferred-smsc-id like so:
group = smsc
smsc-id = A
preferred-smsc-id = A
...
group = smsc
smsc-id = B
preferred-smsc-id = B
...
group = sendsms-user
username = operator_A
password = foo
forced-smsc = A
group = sendsms-user
username = operator_B
password = bar
forced-smsc = B
This should work fine. I ran a quick test with two fakesmscs and
preferred-smsc-id set and saw the messages go to the intended SMSC, but
without preferred-smsc-id set it seemed to be fairly random.
If you plan to receive messages and process them with an sms-service through
the same SMSC, then set denied-smsc-id to take care of the reply message, or
if you're using a back-end app, set max-messages = 0 and get the app to
generate a new sendsms request.
Ian