You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current algo for routing is the following. We have two steps:
1 step - selecting ESME cluster for delivering. Each cluster can contain one or more ESME. The idea of cluster usage is to have load sharing between nodes (ESMEs) inside a cluster and/or if some cluster node are unbound then SMSC GW will send messages to another cluster.
SMSC GW selects the first cluster that ESME fits to the conditions:
bindType==transiever or receiver (for SERVER type) or transmitter (for CLIENT type)
the ESME is not the ESME from which the message has come to SMSC GW
networkID of a message == networkID of an ESME
dest address, ton and npi of a message fit to routing address, ton and npi of ESME
The fact if this ESME is bound or not is not taken into account at this step
2 step - selecting of ESME in the cluster
selecting of ESME in the cluster that is bound (and not stopped) now. If all ESMEs are not bound in the culster then the message will be dropped
https://telestax.zendesk.com/agent/tickets/33019 :
1 step - selecting ESME cluster for delivering. Each cluster can contain one or more ESME. The idea of cluster usage is to have load sharing between nodes (ESMEs) inside a cluster and/or if some cluster node are unbound then SMSC GW will send messages to another cluster.
SMSC GW selects the first cluster that ESME fits to the conditions:
The fact if this ESME is bound or not is not taken into account at this step
2 step - selecting of ESME in the cluster
See also: Restriction in ESME creation / updating time: routing-address, ton and npi must be the same in the cluster #48