Creating a dummy route to nowhere

[Julie Montoya]

I think I need to create a "dummy" route for MO SMS messages; that will simply swallow anything fed into it, and look as though the message was successfully delivered.

This looks as though it ought to be easy, but I can't see anywhere in the documentation how to do it.  (It's also possible it could be just one sentence, and I missed it.)

Before I go to any crazy lengths like implementing a dummy HTTP connector, is there an easier way?

Julie Montoya

tuxtattoot...@gmail.com

[Julie Montoya]

On Mon, Dec 8, 2025 at 3:59 PM Rajesh Chopra <rch...@terragonltd.com> wrote:

Hi Jukie,

Please follow the below steps to resolve your issue.

Let me know in case you need more details.

Method 1: Use /dev/null as an HTTP Endpoint (Most Common Workaround)

Create an MO route to an HTTP connector pointing to a non-consuming endpoint that returns 200 OK automatically.

 [stuff deleted]

Jasmin requires ALL MO messages to be routed somewhere if MO routing is enabled.

There is no built-in “discard” function, so the above dummy HTTP connector is the standard industry approach.

So my understanding wasn't too far in error, then; and I guess, given the potential for harm if it were misused as a built-in thing versus the ease of implementing it, a "memory hole" route straight to nowhere is hardly an unreasonable omission.

I don't think it will be too difficult to write a little script to listen for a connection on a port, eat the whole of STDIN and send a 200 OK response.

Thanks for your help!

Julie Montoya

tuxtattoot...@gmail.com

[Julie Montoya]

Well, I successfully created a fake HTTP connector.  And a route with an EvalPyFilter that does nothing but write to a log file, and always sets result=True .  

Now I have the problem that nothing seems to be getting as far as my dummy route .....

Our setup is a bit unusual.  We get sent an MO message via SMPP, but then we don't normally route it onwards to its destination; instead, we have to use an MOInterceptor. This does all the necessary business logic, and then sets smpp_status to ESME_RDELIVERYFAILURE if the message actually should be delivered and the sender told the delivery succeeded, or ESME_RX_P_APPN if it should not be delivered and the sender should be told the delivery failed.

It's therefore not impossible that some misconfiguration is preventing any onward MO routing altogether, and needs fixing before I can expect anyting to get routed anywhere -- even to my dummy route.

Is there a way to inject a message directly into a specific route to test it?

 

Julie Montoya
tuxtattoot...@gmail.com

[alamin sheikh]

Can you please share the sms flow to understand what you really want to achieve? 

Mo sms -->jasmin-->? --->?--->?

Thanks in advance.

Al Amin

[Julie Montoya]

On Sat, Dec 13, 2025 at 7:03 PM alamin sheikh <linux...@gmail.com> wrote:

Can you please share the sms flow to understand what you really want to achieve? 

Mo sms -->jasmin-->? --->?--->?

Thanks in advance.

Al Amin

Our setup is such that we never normally need actually to route a message.  We get sent a copy of the message as an MO SMS via SMPP, and feed it to some business logic in an MOInterceptor.

If the MOInterceptor logic determines that the message should be delivered to the recipient, we respond with ESME_RDELIVERYFAILURE.  The upstream service then routes it to the recipient.

If the MOInterceptor logic determines that the message should NOT be delivered to the recipient, we respond with ESME_RX_P_APPN.  The upstream service then tells the sender that the delivery was unsuccessful.

There is also a third case, where the message is actually an instruction to us; we can tell from the PDU content exactly what needs to be done, and for which user.  If we can process this successfully, we do not want the sender to be told that message sending was unsuccessful; but neither do we want the message, now it has been dealt with, actually to be sent anywhere.  Leaving smpp_status unset in the MOInterceptor script causes jasmin to want to route the message.

I have an MO route to my dummy HTTP connector  (which logs in syslog the fact it was called; and if I use curl at the bash prompt, I can see this)  at order 20, with a "log only" EvalPyFilter attached to it.  This filter appears to be firing correctly, based on router.log:

2025-12-15 09:57:29 DEBUG    625849 Callbacked a deliver_sm with a DeliverSmPDU[8cc9d600-1c09-4529-ab3b-35efafbdd1c2] (?): PDU [command: CommandId.deliver_sm, sequence_number: 88, command_status: CommandStatus.ESME_ROK
...stuff omitted...
]
2025-12-15 09:57:29 DEBUG    625849 ** This is jm-log_only_filter.py **
2025-12-15 09:57:29 DEBUG    625849 routable has tags: ['12345']
2025-12-15 09:57:29 DEBUG    625849 Nothing more to do here, returning True
2025-12-15 09:57:29 DEBUG    625849 RouterPB selected StaticMORoute to http(http-dummy) NOT RATED for this SubmitSmPDU
2025-12-15 09:57:29 DEBUG    625849 Connector 'http-dummy'(http) is set to be a route for this DeliverSmPDU
2025-12-15 09:57:29 DEBUG    625849 Publishing RoutedDeliverSmContent [msgid:8cc9d600-1c09-4529-ab3b-35efafbdd1c2] in deliver_sm_thrower.http

(the second, third and fourth lines are my log-only filter announcing itself, reporting that tag 12345 has been added by the intercept logic and reporting successful completion),  and it's even possible to see things happening with the rabbitmq queues, but the dummy http connector still never seems to get called.

I feel sure I'm quite close to getting this working, and there is just one small piece I must be missing. 

--

Julie Montoya. 

[Julie Montoya]

And I have it working!

This probably is a schoolgirl error, but deliversmd.py was not running.  This was causing no deliver_sm messages to be thrown.

How to fix it:

Create /usr/lib/systemd/system/jasmin-deliversmd.service with the following content:

[Unit]
Description=Jasmin SMS Gateway deliver_sm throwing daemon
Requires=network.target jasmind.service
After=network.target jasmind.service

[Service]
SyslogIdentifier=jasmin-deliversmd
PIDFile=/run/jasmin-deliversmd.pid
User=jasmin
Group=jasmin
ExecStart=/usr/local/bin/deliversmd.py

[Install]
WantedBy=multi-user.target

Execute

# service jasmin-deliversmd start

Now when you run # ps aux , there should be a deliversmd.py process owned by the user jasmin .  And your MO routes should work  :)