juliangut
commented
3 years ago Hi
the answer you've received is correct, there is nothing in the protocol that states deliver_sm messages should be sent back to the same bind that sent the submit_sm. This is logical once you realise the connection can be lost and recovered (effectively a new bind)
This is the reason why you have three bind modes, transmitter in which you do not care about deliver_sm, receiver in which you only care about those deliver_sm, and transceiver for both situations. You could have a bind to send and another different to receive which is a very common setup
This said, I've seen some providers that effectively transmit deliver_sm packets to the same bind submit_sm was sent through in case it is still up (if in transceiver mode that is), but that is their implementation not specified anywhere in the protocol
telecomsxchange
@juliangut a question for you say there is two instances of node-smpp running on same server (instance A and instance B) both receiving traffic from client and sending it to carrier using using same system_id and password (both instances bound to carrier smsc using same credentials)
Say the submit_sm was sent through instance A. When the SMSC sends a deliver_sm back, what's the best way to differentiate which instance it should land to. In some cases we see that carrier smsc sends back the deliver_sm to instance B instead of A. They say its common that the SMSC to send to another random port as long as it's connected to it.
Looking for second opinion on this as there isn't a hard evidence that their smsc should it not use the same tcp socket that the submit_sm was sent from originally.