Messaging flows

Messaging is heavily relying on an AMQP broker using topics to queue messages for routing, delivering and acking back.

The AMQP broker is providing a strong store & forward queuing mechanism, through the following illustration you can see how every messaging component is asynchronously connected to the broker.

AMQP Messaging flows

AMQP Messaging flows

Six main actors are messaging through the “messaging” topic, their business logic are explained in the below paragraphs.

SMPPClientManagerPB

This is a PerspectiveBroker (PB) responsible of managing SMPP Client connectors (list, add, remove, start, stop, send SMS, etc …), we’ll be only covering the latter (Send SMS).

When the perspective_submit_sm() is called with a SubmitSm PDU and destination connector ID, it will build an AMQP Content message and publish it to a queue named submit.sm.CID where CID is the destination connector ID.

Note

perspective_submit_sm() is called from HTTP API and SMPP Server API after they check with RouterPB for the right connector to send a SubmitSM to.

Every SMPP Connector have a consumer waiting for these messages, once published as explained above, it will be consumed by the destination connector’s submit_sm_callback() method (c.f. SMPPClientSMListener).

DLRLookup

This is a consumer on the dlr.* AMQP route, added in v0.9, it’s main role is DLR map fetching from Redis database and publishing the dlr to the right thrower (http or smpp).

RouterPB

This is another PerspectiveBroker (PB) responsible of routing DeliverSm messages, these are received through the SMPP client connector’s deliver_sm_event_interceptor() method (c.f. SMPPClientSMListener) which publish to deliver.sm.CID, the RouterPB main role is to decide whether to route DeliverSm messages to:

  • deliver_sm_thrower.smpps: if the message is to be delivered through SMPP Server API.
  • deliver_sm_thrower.http: if the message is to be delivered through a HTTP connector.

SMPPClientSMListener

Every SMPP Client connector have one attached SMPPClientSMListener instance, it is responsible for handling messages exchanged through the SMPP Client connector using the following event catchers:

deliver_sm_event_interceptor

Every received DeliverSm PDU is published directly to the broker with the following assumptions:

  • If it’s a SMS-MO message it will get published as an AMQP Content message to deliver_sm.CID where CID is the source connector ID, this message will be handled by the RouterPB.
  • If it’s a delivery receipt and if it were requested when sending the SubmitSm, it will get published as an AMQP Content message to dlr_thrower.http or dlr_thrower.smpps (depends on the used channel for sending initial SubmitSM) for later delivery by DLRThrower’s dlr_throwing_callback() method.

Note

deliver_sm_event_interceptor() will check for interception rules before proceding to routing, c.f. Interception for more details.

submit_sm_callback

It is a simple consumer of submit.sm.CID where CID is its connector ID, it will send every message received through SMPP connection.

submit_sm_resp_event

It is called for every received SubmitSmResp PDU, will check if the related SubmitSm was requiring a delivery receipt and will publish it (or not) to dlr_thrower.http or dlr_thrower.smpps (depends on the used channel for sending initial SubmitSM).

Note

There’s no actual reason why messages are published to submit.sm.resp.CID, this may change in future.

deliverSmThrower

This is will through any received message from deliver_sm_thrower.http to its final http connector, c.f. Receiving SMS-MO for details and from deliver_sm_thrower.smpps to its final SMPP Server binding.

DLRThrower

This is will through any received delivery receipt from dlr_thrower.http to its final http connector, c.f. Receiving DLR for details and from dlr_thrower.smpps to its final SMPP Server binding.