Use the same smsc-id on all of them, but different allowed-smsc-id on each.
That way the DLRs will all use the smsc-id, but you use the allowed-smsc-id
to route your MTs.
Also use smsc-admin-id so that you can start/stop/whatever each bind
individually
Regards
On Thu, Apr 24, 2014 at 10:49 AM,
Hi Juan,
That is an interesting approach. Are you saying that if a bind has an
smsc-id of bind-a but I add allowed-smsc-id with a value of bind-b then
only messages that have the smsc=bind-b in the sendsms URL will get
routed to that bind? It doesn't seem like that should work. Am I
understanding
Yes, you're understanding it correctly.
So you can use bind-a as smsc-id for all the binds, and then use
allowed-smsc-id like bind-b, bind-c, bind-d, etc on each and use
those as smsc parameter for sending the MTs.
DLRs will all use bind-a.
Regards.
On Sat, Apr 26, 2014 at 11:40 AM, Jeff
2014-04-24 1:20 GMT+04:00 Jeff Thorn j...@thorntechnologies.com:
I've searched the user groups for this issue and everyone says to use the
same smsc-id. We specifically need different smsc-ids so our interactive
messages can be delivered in real time and not get queued with our bulk
messages.
Thanks for the response spamden. That is very unfortunate. We have a
legitimate need to have different smsc-ids but have only one account. How
feasible would it be to use meta data or some other way to match the
sending smsc-id instead of the receiving smsc-id? If all else fails, what
is the risk
We are seeing an increased number of error messages like the following:
ERROR: SMPP[bind-b]: got DLR but could not find message or was not
interested in it idxx dstxxx, type1
We have a number of binds setup to handle bulk messaging (which may queue
in kannel) or interactive messaging
I've searched the user groups for this issue and everyone says to use the
same smsc-id. We specifically need different smsc-ids so our interactive
messages can be delivered in real time.
On Wed, Apr 23, 2014 at 4:45 PM, Jeff Thorn j...@thorntechnologies.comwrote:
We are seeing an increased
I've searched the user groups for this issue and everyone says to use the
same smsc-id. We specifically need different smsc-ids so our interactive
messages can be delivered in real time and not get queued with our bulk
messages.
Is there anyway to ensure that Delivery Reports come back on the