Management CLI Modules

As shown in the architecture figure Architecture, jCli is mainly composed of management modules interfacing two Perspective brokers (SMPPClientManagerPB and RouterPB), each module is identified as a manager of a defined scope:

• User management
• Group management
• etc ..

Note

filter and httpccm modules are not interfacing any Perspective broker, they are facilitating the reuse of created filters and HTTP Client connectors in MO and MT routers, e.g. a HTTP Client connector may be created once and used many times in MO Routes.

User manager

The User manager module is accessible through the user command and is providing the following features:

user command line options

Command	Description
-l, –list	List all users or a group users when provided with GID
-a, –add	Add user
-e, –enable	Enable user
-d, –disable	Disable user
-u UID, –update=UID	Update user using it’s UID
-r UID, –remove=UID	Remove user using it’s UID
-s UID, –show=UID	Show user using it’s UID
–smpp-unbind=UID	Unbind user from smpp server using it’s UID
–smpp-ban=UID	Unbind and ban user from smpp server using it’s UID

A User object is required for:

• SMPP Server API authentication to send a SMS (c.f. Sending SMS-MT)
• HTTP API authentication to send a SMS (c.f. Sending SMS-MT)
• Creating a UserFilter using the filter manager (c.f. Filter manager)

Every User must be a member of a Group, so before adding a new User, there must be at least one Group available, Groups are identified by GID (Group ID).

When adding a User, the following parameters are required:

• username: A unique username used for authentication
• password
• uid: A unique identifier, can be same as username
• gid: Group Identfier
• mt_messaging_cred (optional): MT Messaging credentials (c.f. User credentials)

Here’s an example of adding a new User to the marketing group:

jcli : user -a
Adding a new User: (ok: save, ko: exit)
> username foo
> password bar
> gid marketing
> uid foo
> ok
Successfully added User [foo] to Group [marketing]

All the above parameters can be displayed after User creation, except the password:

jcli : user -s foo
username foo
mt_messaging_cred defaultvalue src_addr None
mt_messaging_cred quota http_throughput ND
mt_messaging_cred quota balance ND
mt_messaging_cred quota smpps_throughput ND
mt_messaging_cred quota sms_count ND
mt_messaging_cred quota early_percent ND
mt_messaging_cred valuefilter priority ^[0-3]$
mt_messaging_cred valuefilter content .*
mt_messaging_cred valuefilter src_addr .*
mt_messaging_cred valuefilter dst_addr .*
mt_messaging_cred valuefilter validity_period ^\d+$
mt_messaging_cred authorization http_send True
mt_messaging_cred authorization http_dlr_method True
mt_messaging_cred authorization http_balance True
mt_messaging_cred authorization smpps_send True
mt_messaging_cred authorization priority True
mt_messaging_cred authorization http_long_content True
mt_messaging_cred authorization src_addr True
mt_messaging_cred authorization dlr_level True
mt_messaging_cred authorization http_rate True
mt_messaging_cred authorization validity_period True
mt_messaging_cred authorization http_bulk False
mt_messaging_cred authorization hex_content True
uid foo
smpps_cred quota max_bindings ND
smpps_cred authorization bind True
gid marketing

Listing Users will show currently added Users with their UID, GID and Username:

jcli : user -l
#User id          Group id         Username         Balance MT SMS Throughput
#foo              1                foo              ND      ND     ND/ND
Total Users: 1

Note

When listing a disabled user, his User id will be prefixed by !, same thing apply to group.

User credentials

MT Messaging section

As seen above, User have an optional mt_messaging_cred parameter which define a set of sections:

• Authorizations: Privileges to send messages and set some defined parameters,
• Value filters: Restrictions on some parameter values (such as source address),
• Default values: Default parameter values to be set by Jasmin when not manually set by User,
• Quotas: Everything about Billing,

For each section of the above, there’s keys to be defined when adding/updating a user, the example below show how to set a source address value filter, a balance of 44.2, unlimited sms_count and limit SMS throughput in smpp server to 2 messages per second:

jcli : user -a
Adding a new User: (ok: save, ko: exit)
> username foo
> password bar
> gid marketing
> uid foo
> mt_messaging_cred valuefilter src_addr ^JASMIN$
> mt_messaging_cred quota balance 44.2
> mt_messaging_cred quota sms_count none
> mt_messaging_cred quota smpps_throughput 2
> ok
Successfully added User [foo] to Group [marketing]

Note

Setting none value to a user quota will set it as unlimited quota.

In the below tables, you can find exhaustive list of keys for each mt_messaging_cred section:

authorization section keys

Key	Default	Description
http_send	True	Privilege to send SMS through Sending SMS-MT (default is True)
http_balance	True	Privilege to check balance through Checking account balance (default is True)
http_rate	True	Privilege to check a message rate through Checking rate price (default is True)
http_bulk	False	Privilege to send bulks through http api (Deprecated and will be removed)
smpps_send	True	Privilege to send SMS through SMPP Server API (default is True)
http_long_content	True	Privilege to send long content SMS through Sending SMS-MT (default is True)
dlr_level	True	Privilege to set dlr-level parameter (default is True)
http_dlr_method	True	Privilege to set dlr-method HTTP parameter (default is True)
src_addr	True	Privilege to define source address of SMS-MT (default is True)
priority	True	Privilege to define priority of SMS-MT (default is True)
validity_period	True	Privilege to define validity_period of SMS-MT (default is True)
hex_content	True	Privilege to send binary message using the hex-content parameter (default is NOT SET)

Note

Authorizations keys prefixed by http_ or smpps_ are only applicable for their respective channels.

valuefilter section keys

Key	Default	Description
src_addr	.*	Regex pattern to validate source address of SMS-MT
dst_addr	.*	Regex pattern to validate destination address of SMS-MT
content	.*	Regex pattern to validate content of SMS-MT
priority	^[0-3]$	Regex pattern to validate priority of SMS-MT
validity_period	^d+$	Regex pattern to validate validity_period of SMS-MT

defaultvalue section keys

Key	Default	Description
src_addr	None	Default source address of SMS-MT

quota section keys

Key	Default	Description
balance	ND	c.f. 1. Balance quota
sms_count	ND	c.f. 2. sms_count quota
early_percent	ND	c.f. Asynchronous billing
http_throughput	ND	Max. number of messages per second to accept through HTTP API
smpps_throughput	ND	Max. number of messages per second to accept through SMPP Server

Note

It is possible to increment a quota by indicating a sign, ex: +10 will increment a quota value by 10, -22.4 will decrease a quota value by 22.4.

SMPP Server section

User have an other optional smpps_cred parameter which define a specialized set of sections for defining his credentials for using the SMPP Server API:

• Authorizations: Privileges to bind,
• Quotas: Maximum bound connections at a time (multi binding),

For each section of the above, there’s keys to be defined when adding/updating a user, the example below show how to authorize binding and set max_bindings to 2:

jcli : user -a
Adding a new User: (ok: save, ko: exit)
> username foo
> password bar
> gid marketing
> uid foo
> smpps_cred authorization bind yes
> smpps_cred quota max_bindings 2
> ok
Successfully added User [foo] to Group [marketing]

In the below tables, you can find exhaustive list of keys for each smpps_cred section:

authorization section keys

Key	Default	Description
bind	True	Privilege to bind to SMPP Server API

quota section keys

Key	Default	Description
max_bindings	ND	Maximum bound connections at a time (multi binding)

Note

It is possible to increment a quota by indicating a sign, ex: +10 will increment a quota value by 10, -2 will decrease a quota value by 2.

Group manager

The Group manager module is accessible through the group command and is providing the following features:

group command line options

Command	Description
-l, –list	List groups
-a, –add	Add group
-e, –enable	Enable group
-d, –disable	Disable group
-r GID, –remove=GID	Remove group using it’s GID

A Group object is required for:

• Creating a User using the user manager (c.f. User manager)
• Creating a GroupFilter using the filter manager (c.f. Filter manager)

When adding a Group, only one parameter is required:

• gid: Group Identfier

Here’s an example of adding a new Group:

jcli : group -a
Adding a new Group: (ok: save, ko: exit)
> gid marketing
> ok
Successfully added Group [marketing]

Listing Groups will show currently added Groups with their GID:

jcli : group  -l
#Group id
#marketing
Total Groups: 1

Note

When listing a disabled group, its group id will be prefixed by !.

MO router manager

The MO Router manager module is accessible through the morouter command and is providing the following features:

morouter command line options

Command	Description
-l, –list	List MO routes
-a, –add	Add a new MO route
-r ORDER, –remove=ORDER	Remove MO route using it’s ORDER
-s ORDER, –show=ORDER	Show MO route using it’s ORDER
-f, –flush	Flush MO routing table

Note

MO Route is used to route inbound messages (SMS MO) through two possible channels: http and smpps (SMPP Server).

MO Router helps managing Jasmin’s MORoutingTable, which is responsible of providing routes to received SMS MO, here are the basics of Jasmin MO routing mechanism:

1. MORoutingTable holds ordered MORoute objects (each MORoute has a unique order)

2. A MORoute is composed of:

   • Filters: One or many filters (c.f. Filter manager)
   • Connector: One connector (can be many in some situations)

3. There’s many objects inheriting MORoute to provide flexible ways to route messages:

   • DefaultRoute: A route without a filter, this one can only set with the lowest order to be a default/fallback route
   • StaticMORoute: A basic route with Filters and one Connector
   • RandomRoundrobinMORoute: A route with Filters and many Connectors, will return a random Connector if its Filters are matched, can be used as a load balancer route
   • FailoverMORoute: A route with Filters and many Connectors, will return an available (connected) Connector if its Filters are matched

4. When a SMS MO is received, Jasmin will ask for the right MORoute to consider, all routes are checked in descendant order for their respective Filters (when a MORoute have many filters, they are checked with an AND boolean operator)

5. When a MORoute is considered (its Filters are matching a received SMS MO), Jasmin will use its Connector to send the SMS MO.

Check The message router for more details about Jasmin’s routing.

When adding a MO Route, the following parameters are required:

• type: One of the supported MO Routes: DefaultRoute, StaticMORoute, RandomRoundrobinMORoute
• order: MO Route order

When choosing the MO Route type, additional parameters may be added to the above required parameters.

Here’s an example of adding a DefaultRoute to a HTTP Client Connector (http_default):

jcli : morouter -a
Adding a new MO Route: (ok: save, ko: exit)
> type DefaultRoute
jasmin.routing.Routes.DefaultRoute arguments:
connector
> connector http(http_default)
> ok
Successfully added MORoute [DefaultRoute] with order:0

Note

You don’t have to set order parameter when the MO Route type is DefaultRoute, it will be automatically set to 0

Here’s an example of adding a StaticMORoute to a HTTP Client Connector (http_1):

jcli : morouter -a
Adding a new MO Route: (ok: save, ko: exit)
> type StaticMORoute
jasmin.routing.Routes.StaticMORoute arguments:
filters, connector
> order 10
> filters filter_1
> connector http(http_1)
> ok
Successfully added MORoute [StaticMORoute] with order:10

Here’s an example of adding a StaticMORoute to a SMPP Server user (user_1):

jcli : morouter -a
Adding a new MO Route: (ok: save, ko: exit)
> type StaticMORoute
jasmin.routing.Routes.StaticMORoute arguments:
filters, connector
> order 15
> filters filter_2
> connector smpps(user_1)
> ok
Successfully added MORoute [StaticMORoute] with order:15

Note

When routing to a smpps connector like the above example the user_1 designates the username of the concerned user, if he’s already bound to Jasmin’s SMPP Server API routed messages will be delivered to him, if not, queuing will take care of delivery.

Here’s an example of adding a RandomRoundrobinMORoute to two HTTP Client Connectors (http_2 and http_3):

jcli : morouter -a
Adding a new MO Route: (ok: save, ko: exit)
> type RandomRoundrobinMORoute
jasmin.routing.Routes.RandomRoundrobinMORoute arguments:
filters, connectors
> filters filter_3;filter_1
> connectors http(http_2);http(http_3)
> order 20
> ok
Successfully added MORoute [RandomRoundrobinMORoute] with order:20

Note

It is possible to use a RoundRobinMORoute with a mix of connectors, example: connectors smpps(user_1);http(http_1);http(http_3).

Here’s an example of adding a FailoverMORoute to two HTTP Client Connectors (http_4 and http_5):

jcli : morouter -a
Adding a new MO Route: (ok: save, ko: exit)
> type FailoverMORoute
jasmin.routing.Routes.FailoverMORoute arguments:
filters, connectors
> filters filter_4
> connectors http(http_4);http(http_5)
> order 30
> ok
Successfully added MORoute [FailoverMORoute] with order:20

Note

It is not possible to use a FailoverMORoute with a mix of connectors, example: connectors smpps(user_1);http(http_1);http(http_3).

Once the above MO Routes are added to MORoutingTable, it is possible to list these routes:

jcli : morouter -l
#Order Type                    Connector ID(s)                  Filter(s)
#30    FailoverMORoute         http(http_4), http(http_5)       <T>, <T>
#20    RandomRoundrobinMORoute http(http_2), http(http_3)       <T>, <T>
#15    StaticMORoute           smpps(user_1)                    <T>
#10    StaticMORoute           http(http_1)                     <T>
#0     DefaultRoute            http(http_default)
Total MO Routes: 3

Note

Filters and Connectors were created before creating these routes, please check Filter manager and HTTP Client connector manager for further details

It is possible to obtain more information of a defined route by typing moroute -s <order>:

jcli : morouter -s 20
RandomRoundrobinMORoute to 2 connectors:
   - http(http_2)
   - http(http_3)

jcli : morouter -s 10
StaticMORoute to http(http_1)

jcli : morouter -s 0
DefaultRoute to http(http_default)

More control commands:

• morouter -r <order>: Remove route at defined order
• morouter -f: Flush MORoutingTable (unrecoverable)

MT router manager

The MT Router manager module is accessible through the mtrouter command and is providing the following features:

mtrouter command line options

Command	Description
-l, –list	List MT routes
-a, –add	Add a new MT route
-r ORDER, –remove=ORDER	Remove MT route using it’s ORDER
-s ORDER, –show=ORDER	Show MT route using it’s ORDER
-f, –flush	Flush MT routing table

Note

MT Route is used to route outbound messages (SMS MT) through one channel: smppc (SMPP Client).

MT Router helps managing Jasmin’s MTRoutingTable, which is responsible of providing routes to outgoing SMS MT, here are the basics of Jasmin MT routing mechanism:

1. MTRoutingTable holds ordered MTRoute objects (each MTRoute has a unique order)

2. A MTRoute is composed of:

   • Filters: One or many filters (c.f. Filter manager)
   • Connector: One connector (can be many in some situations)
   • Rate: For billing purpose, the rate of sending one message through this route; it can be zero to mark the route as FREE (NOT RATED) (c.f. Billing)

3. There’s many objects inheriting MTRoute to provide flexible ways to route messages:

   • DefaultRoute: A route without a filter, this one can only set with the lowest order to be a default/fallback route
   • StaticMTRoute: A basic route with Filters and one Connector
   • RandomRoundrobinMTRoute: A route with Filters and many Connectors, will return a random Connector if its Filters are matching, can be used as a load balancer route
   • FailoverMTRoute: A route with Filters and many Connectors, will return an available (connected) Connector if its Filters are matched

4. When a SMS MT is to be sent, Jasmin will ask for the right MTRoute to consider, all routes are checked in descendant order for their respective Filters (when a MTRoute have many filters, they are checked with an AND boolean operator)

5. When a MTRoute is considered (its Filters are matching an outgoing SMS MT), Jasmin will use its Connector to send the SMS MT.

Check The message router for more details about Jasmin’s routing.

When adding a MT Route, the following parameters are required:

• type: One of the supported MT Routes: DefaultRoute, StaticMTRoute, RandomRoundrobinMTRoute
• order: MO Route order
• rate: The route rate, can be zero

When choosing the MT Route type, additional parameters may be added to the above required parameters.

Here’s an example of adding a DefaultRoute to a SMPP Client Connector (smppcc_default):

jcli : mtrouter -a
Adding a new MT Route: (ok: save, ko: exit)
> type DefaultRoute
jasmin.routing.Routes.DefaultRoute arguments:
connector
> connector smppc(smppcc_default)
> rate 0.0
> ok
Successfully added MTRoute [DefaultRoute] with order:0

Note

You don’t have to set order parameter when the MT Route type is DefaultRoute, it will be automatically set to 0

Here’s an example of adding a StaticMTRoute to a SMPP Client Connector (smppcc_1):

jcli : mtrouter -a
Adding a new MT Route: (ok: save, ko: exit)
> type StaticMTRoute
jasmin.routing.Routes.StaticMTRoute arguments:
filters, connector
> filters filter_1;filter_2
> order 10
> connector smppc(smppcc_1)
> rate 0.0
> ok
Successfully added MTRoute [StaticMTRoute] with order:10

Here’s an example of adding a RandomRoundrobinMTRoute to two SMPP Client Connectors (smppcc_2 and smppcc_3):

jcli : mtrouter -a
Adding a new MT Route: (ok: save, ko: exit)
> order 20
> type RandomRoundrobinMTRoute
jasmin.routing.Routes.RandomRoundrobinMTRoute arguments:
filters, connectors
> filters filter_3
> connectors smppc(smppcc_2);smppc(smppcc_3)
> rate 0.0
> ok
Successfully added MTRoute [RandomRoundrobinMTRoute] with order:20

Here’s an example of adding a FailoverMTRoute to two SMPP Client Connectors (smppcc_4 and smppcc_5):

jcli : mtrouter -a
Adding a new MT Route: (ok: save, ko: exit)
> order 30
> type FailoverMTRoute
jasmin.routing.Routes.FailoverMTRoute arguments:
filters, connectors
> filters filter_4
> connectors smppc(smppcc_4);smppc(smppcc_5)
> rate 0.0
> ok
Successfully added MTRoute [FailoverMTRoute] with order:20

Once the above MT Routes are added to MTRoutingTable, it is possible to list these routes:

jcli : mtrouter -l
#Order Type                    Rate    Connector ID(s)                     Filter(s)
#20    FailoverMTRoute         0 (!)   smppc(smppcc_3), smppc(smppcc_4)    <T>
#20    RandomRoundrobinMTRoute 0 (!)   smppc(smppcc_2), smppc(smppcc_3)    <T>
#10    StaticMTRoute           0 (!)   smppc(smppcc_1)                     <T>, <T>
#0     DefaultRoute            0 (!)   smppc(smppcc_default)
Total MT Routes: 3

Note

Filters and Connectors were created before creating these routes, please check Filter manager and HTTP Client connector manager for further details

It is possible to obtain more information of a defined route by typing mtroute -s <order>:

jcli : mtrouter -s 20
RandomRoundrobinMTRoute to 2 connectors:
   - smppc(smppcc_2)
   - smppc(smppcc_3)
NOT RATED

jcli : mtrouter -s 10
StaticMTRoute to smppc(smppcc_1) NOT RATED

jcli : mtrouter -s 0
DefaultRoute to smppc(smppcc_default) NOT RATED

More control commands:

• mtrouter -r <order>: Remove route at defined order
• mtrouter -f: Flush MTRoutingTable (unrecoverable)

MO interceptor manager

The MO Interceptor manager module is accessible through the mointerceptor command and is providing the following features:

mointerceptor command line options

Command	Description
-l, –list	List MO interceptors
-a, –add	Add a new MO interceptors
-r ORDER, –remove=ORDER	Remove MO interceptor using it’s ORDER
-s ORDER, –show=ORDER	Show MO interceptor using it’s ORDER
-f, –flush	Flush MO interception table

Note

MO Interceptor is used to hand inbound messages (SMS MO) to a user defined script, check Interception for more details.

MO Interceptor helps managing Jasmin’s MOInterceptionTable, which is responsible of intercepting SMS MO before routing is made, here are the basics of Jasmin MO interception mechanism:

1. MOInterceptionTable holds ordered MOInterceptor objects (each MOInterceptor has a unique order)

2. A MOInterceptor is composed of:

   • Filters: One or many filters (c.f. Filter manager)
   • Script: Path to python script

3. There’s many objects inheriting MOInterceptor to provide flexible ways to route messages:

   • DefaultInterceptor: An interceptor without a filter, this one can only set with the lowest order to be a default/fallback interceptor
   • StaticMOInterceptor: A basic interceptor with Filters and one Script

4. When a SMS MO is received, Jasmin will ask for the right MOInterceptor to consider, all interceptors are checked in descendant order for their respective Filters (when a MOInterceptor have many filters, they are checked with an AND boolean operator)

5. When a MOInterceptor is considered (its Filters are matching a received SMS MO), Jasmin will call its Script with the Routable argument.

Check Interception for more details about Jasmin’s interceptor.

When adding a MO Interceptor, the following parameters are required:

• type: One of the supported MO Interceptors: DefaultInterceptor, StaticMOInterceptor
• order: MO Interceptor order

When choosing the MO Interceptor type, additional parameters may be added to the above required parameters.

Here’s an example of adding a DefaultInterceptor to a python script:

jcli : mointerceptor -a
Adding a new MO Interceptor: (ok: save, ko: exit)
> type DefaultInterceptor
<class 'jasmin.routing.Interceptors.DefaultInterceptor'> arguments:
script
> script python3(/opt/jasmin-scripts/interception/mo-interceptor.py)
> ok
Successfully added MOInterceptor [DefaultInterceptor] with order:0

Note

As of now, only python3 script is permitted.

Note

Pay attention that the given script is copied to Jasmin core, do not expect Jasmin to refresh the script code when you update it, you’ll need to redefine the mointerceptor rule again so Jasmin will refresh the script.

Note

You don’t have to set order parameter when the MO Interceptor type is DefaultInterceptor, it will be automatically set to 0

Here’s an example of adding a StaticMOInterceptor to a python script:

jcli : mointerceptor -a
Adding a new MO Interceptor: (ok: save, ko: exit)
> type StaticMOInterceptor
<class 'jasmin.routing.Interceptors.StaticMOInterceptor'> arguments:
filters, script
> order 10
> filters filter_1
> script python3(/opt/jasmin-scripts/interception/mo-interceptor.py)
> ok
Successfully added MOInterceptor [StaticMOInterceptor] with order:10

Once the above MO Interceptors are added to MOInterceptionTable, it is possible to list these interceptors:

jcli : mointerceptor -l
#Order    Type                    Script                    Filter(s)
#10       StaticMOInterceptor     <MOIS (pyCode= ..)>       <T>
#0        DefaultInterceptor      <MOIS (pyCode= ..)>
Total MO Interceptors: 2

Note

Filters were created before creating these interceptors, please check Filter manager for further details

It is possible to obtain more information of a defined interceptor by typing mointerceptor -s <order>:

jcli : mointerceptor -s 10
StaticMOInterceptor/<MOIS (pyCode= ..)>

jcli : mointerceptor -s 0
DefaultInterceptor/<MOIS (pyCode= ..)>

More control commands:

• mointerceptor -r <order>: Remove interceptor at defined order
• mointerceptor -f: Flush MOInterceptionTable (unrecoverable)

MT interceptor manager

The MT Interceptor manager module is accessible through the mtinterceptor command and is providing the following features:

mtinterceptor command line options

Command	Description
-l, –list	List MT interceptors
-a, –add	Add a new MT interceptors
-r ORDER, –remove=ORDER	Remove MT interceptor using it’s ORDER
-s ORDER, –show=ORDER	Show MT interceptor using it’s ORDER
-f, –flush	Flush MT interception table

Note

MT Interceptor is used to hand outbound messages (SMS MT) to a user defined script, check Interception for more details.

MT Interceptor helps managing Jasmin’s MTInterceptionTable, which is responsible of intercepting SMS MT before routing is made, here are the basics of Jasmin MT interception mechanism:

1. MTInterceptionTable holds ordered MTInterceptor objects (each MTInterceptor has a unique order)

2. A MTInterceptor is composed of:

   • Filters: One or many filters (c.f. Filter manager)
   • Script: Path to python script

3. There’s many objects inheriting MTInterceptor to provide flexible ways to route messages:

   • DefaultInterceptor: An interceptor without a filter, this one can only set with the lowest order to be a default/fallback interceptor
   • StaticMTInterceptor: A basic interceptor with Filters and one Script

4. When a SMS MT is received, Jasmin will ask for the right MTInterceptor to consider, all interceptors are checked in descendant order for their respective Filters (when a MTInterceptor have many filters, they are checked with an AND boolean operator)

5. When a MTInterceptor is considered (its Filters are matching a received SMS MT), Jasmin will call its Script with the Routable argument.

Check Interception for more details about Jasmin’s interceptor.

When adding a MT Interceptor, the following parameters are required:

• type: One of the supported MT Interceptors: DefaultInterceptor, StaticMTInterceptor
• order: MT Interceptor order

When choosing the MT Interceptor type, additional parameters may be added to the above required parameters.

Here’s an example of adding a DefaultInterceptor to a python script:

jcli : mtinterceptor -a
Adding a new MT Interceptor: (ok: save, ko: exit)
> type DefaultInterceptor
<class 'jasmin.routing.Interceptors.DefaultInterceptor'> arguments:
script
> script python3(/opt/jasmin-scripts/interception/mt-interceptor.py)
> ok
Successfully added MTInterceptor [DefaultInterceptor] with order:0

Note

As of now, only python3 script is permitted.

Note

Pay attention that the given script is copied to Jasmin core, do not expect Jasmin to refresh the script code when you update it, you’ll need to redefine the mtinterceptor rule again so Jasmin will refresh the script.

Note

You don’t have to set order parameter when the MT Interceptor type is DefaultInterceptor, it will be automatically set to 0

Here’s an example of adding a StaticMTInterceptor to a python script:

jcli : mtinterceptor -a
Adding a new MT Interceptor: (ok: save, ko: exit)
> type StaticMTInterceptor
<class 'jasmin.routing.Interceptors.StaticMTInterceptor'> arguments:
filters, script
> order 10
> filters filter_1
> script python3(/opt/jasmin-scripts/interception/mt-interceptor.py)
> ok
Successfully added MTInterceptor [StaticMTInterceptor] with order:10

Once the above MT Interceptors are added to MTInterceptionTable, it is possible to list these interceptors:

jcli : mtinterceptor -l
#Order    Type                    Script                    Filter(s)
#10       StaticMTInterceptor     <MTIS (pyCode= ..)>       <T>
#0        DefaultInterceptor      <MTIS (pyCode= ..)>
Total MT Interceptors: 2

Note

Filters were created before creating these interceptors, please check Filter manager for further details

It is possible to obtain more information of a defined interceptor by typing mtinterceptor -s <order>:

jcli : mtinterceptor -s 10
StaticMTInterceptor/<MTIS (pyCode= ..)>

jcli : mtinterceptor -s 0
DefaultInterceptor/<MTIS (pyCode= ..)>

More control commands:

• mtinterceptor -r <order>: Remove interceptor at defined order
• mtinterceptor -f: Flush MTInterceptionTable (unrecoverable)

SMPP Client connector manager

The SMPP Client connector manager module is accessible through the smppccm command and is providing the following features:

smppccm command line options

Command	Description
-l, –list	List SMPP connectors
-a, –add	Add SMPP connector
-u CID, –update=CID	Update SMPP connector configuration using it’s CID
-r CID, –remove=CID	Remove SMPP connector using it’s CID
-s CID, –show=CID	Show SMPP connector using it’s CID
-1 CID, –start=CID	Start SMPP connector using it’s CID
-0 CID, –stop=CID	Stop SMPP connector using it’s CID

A SMPP Client connector is used to send/receive SMS through SMPP v3.4 protocol, it is directly connected to MO and MT routers to provide end-to-end message delivery.

Adding a new SMPP Client connector requires knowledge of the parameters detailed in the listing below:

SMPP Client connector parameters

Parameter	Description	Default
cid	Connector ID (must be unique)
logfile		/var/log/jasmin/default-<cid>.log
logrotate	When to rotate the log file, possible values: S=Seconds, M=Minutes, H=Hours, D=Days, W0-W6=Weekday (0=Monday) and midnight=Roll over at midnight	midnight
loglevel	Logging numeric level: 10=DEBUG, 20=INFO, 30=WARNING, 40=ERROR, 50=CRITICCAL	20
logprivacy	Don’t log message contents if True	False
host	Server that runs SMSC	127.0.0.1
port	The port number for the connection to the SMSC.	2775
ssl	Activate ssl connection	no
username		smppclient
password		password
bind	Bind type: transceiver, receiver or transmitter	transceiver
bind_to	Timeout for response to bind request	30
trx_to	Maximum time lapse allowed between transactions, after which, the connection is considered as inactive and will reconnect	300
res_to	Timeout for responses to any request PDU	60
pdu_red_to	Timeout for reading a single PDU, this is the maximum lapse of time between receiving PDU’s header and its complete read, if the PDU reading timed out, the connection is considered as ‘corrupt’ and will reconnect	10
con_loss_retry	Reconnect on connection loss ? (yes, no)	yes
con_loss_delay	Reconnect delay on connection loss (seconds)	10
con_fail_retry	Reconnect on connection failure ? (yes, no)	yes
con_fail_delay	Reconnect delay on connection failure (seconds)	10
src_addr	Default source adress of each SMS-MT if not set while sending it, can be numeric or alphanumeric, when not defined it will take SMSC default	Not defined
src_ton	Source address TON setting for the link: 0=Unknown, 1=International, 2=National, 3=Network specific, 4=Subscriber number, 5=Alphanumeric, 6=Abbreviated	2
src_npi	Source address NPI setting for the link: 0=Unknown, 1=ISDN, 3=Data, 4=Telex, 6=Land mobile, 8=National, 9=Private, 10=Ermes, 14=Internet, 18=WAP Client ID	1
dst_ton	Destination address TON setting for the link: 0=Unknown, 1=International, 2=National, 3=Network specific, 4=Subscriber number, 5=Alphanumeric, 6=Abbreviated	1
dst_npi	Destination address NPI setting for the link: 0=Unknown, 1=ISDN, 3=Data, 4=Telex, 6=Land mobile, 8=National, 9=Private, 10=Ermes, 14=Internet, 18=WAP Client ID	1
bind_ton	Bind address TON setting for the link: 0=Unknown, 1=International, 2=National, 3=Network specific, 4=Subscriber number, 5=Alphanumeric, 6=Abbreviated	0
bind_npi	Bind address NPI setting for the link: 0=Unknown, 1=ISDN, 3=Data, 4=Telex, 6=Land mobile, 8=National, 9=Private, 10=Ermes, 14=Internet, 18=WAP Client ID	1
validity	Default validity period of each SMS-MT if not set while sending it, when not defined it will take SMSC default (seconds)	Not defined
priority	SMS-MT default priority if not set while sending it: 0, 1, 2 or 3	0
requeue_delay	Delay to be considered when requeuing a rejected message	120
addr_range	Indicates which MS’s can send messages to this connector, seems to be an informative value	Not defined
systype	The system_type parameter is used to categorize the type of ESME that is binding to the SMSC. Examples include “VMS” (voice mail system) and “OTA” (over-the-air activation system).	Not defined
dlr_expiry	When a SMS-MT is not acked, it will remain waiting in memory for dlr_expiry seconds, after this period, any received ACK will be ignored	86400
submit_throughput	Active SMS-MT throttling in MPS (Messages per second), set to 0 (zero) for unlimited throughput	1
proto_id	Used to indicate protocol id in SMS-MT and SMS-MO	Not defined
coding	Default coding of each SMS-MT if not set while sending it: 0=SMSC Default, 1=IA5 ASCII, 2=Octet unspecified, 3=Latin1, 4=Octet unspecified common, 5=JIS, 6=Cyrillic, 7=ISO-8859-8, 8=UCS2, 9=Pictogram, 10=ISO-2022-JP, 13=Extended Kanji Jis, 14=KS C 5601	0
elink_interval	Enquire link interval (seconds)	30
def_msg_id	Specifies the SMSC index of a pre-defined (‘canned’) message.	0
ripf	Replace if present flag: 0=Do not replace, 1=Replace	0
dlr_msgid	Indicates how to read msg id when receiving a receipt: 0=msg id is identical in submit_sm_resp and deliver_sm, 1=submit_sm_resp msg-id is in hexadecimal base, deliver_sm msg-id is in decimal base, 2=submit_sm_resp msg-id is in decimal base, deliver_sm msg-id is in hexadecimal base.	0

Note

When adding a SMPP Client connector, only it’s cid is required, all the other parameters will be set to their respective defaults.

Note

Connector restart is required only when changing the following parameters: host, port, username, password, systemType, logfile, loglevel; any other change is applied without requiring connector to be restarted.

Here’s an example of adding a new transmitter SMPP Client connector with cid=Demo:

jcli : smppccm -a
Adding a new connector: (ok: save, ko: exit)
> cid Demo
> bind transmitter
> ok
Successfully added connector [Demo]

All the above parameters can be displayed after connector creation:

jcli : smppccm -s Demo
ripf 0
con_fail_delay 10
dlr_expiry 86400
coding 0
submit_throughput 1
elink_interval 10
bind_to 30
port 2775
con_fail_retry yes
password password
src_addr None
bind_npi 1
addr_range None
dst_ton 1
res_to 60
def_msg_id 0
priority 0
con_loss_retry yes
username smppclient
dst_npi 1
validity None
requeue_delay 120
host 127.0.0.1
src_npi 1
trx_to 300
logfile /var/log/jasmin/default-Demo.log
systype
cid Demo
loglevel 20
bind transmitter
proto_id None
con_loss_delay 10
bind_ton 0
pdu_red_to 10
src_ton 2

Note

From the example above, you can see that showing a connector details will return all it’s parameters even those you did not enter while creating/updating the connector, they will take their respective default values as explained in SMPP Client connector parameters

Listing connectors will show currently added SMPP Client connectors with their CID, Service/Session state and start/stop counters:

jcli : smppccm -l
#Connector id                        Service Session          Starts Stops
#888                                 stopped None             0      0
#Demo                                stopped None             0      0
Total connectors: 2

Updating an existent connector is the same as creating a new one, simply type smppccm -u <cid> where cid is the connector id you want to update, you’ll run into a new interactive session to enter the parameters you want to update (c.f. SMPP Client connector parameters).

Here’s an example of updating SMPP Client connector’s host:

jcli : smppccm -u Demo
Updating connector id [Demo]: (ok: save, ko: exit)
> host 10.10.1.2
> ok
Successfully updated connector [Demo]

More control commands:

• smppccm -1 <cid>: Start connector and try to connect
• smppccm -0 <cid>: Stop connector and disconnect
• smppccm -r <cid>: Remove connector (unrecoverable)

Filter manager

The Filter manager module is accessible through the filter command and is providing the following features:

filter command line options

Command	Description
-l, –list	List filters
-a, –add	Add filter
-r FID, –remove=FID	Remove filter using it’s FID
-s FID, –show=FID	Show filter using it’s FID

Filters are used by MO/MT routers to help decide on which route a message must be delivered, the following flowchart provides details of the routing process:

Routing process flow

Jasmin provides many Filters offering advanced flexibilities to message routing:

Jasmin Filters

Name	Routes	Description
TransparentFilter	All	This filter will always match any message criteria
ConnectorFilter	MO	Will match the source connector of a message
UserFilter	MT	Will match the owner of a MT message
GroupFilter	MT	Will match the owner’s group of a MT message
SourceAddrFilter	All	Will match the source address of a MO message
DestinationAddrFilter	All	Will match the destination address of a MT message
ShortMessageFilter	All	Will match the content of a message
DateIntervalFilter	All	Will match the date of a message
TimeIntervalFilter	All	Will match the time of a message
TagFilter	All	Will check if message has a defined tag
EvalPyFilter	All	Will pass the message to a third party python script for user-defined filtering

Check The message router for more details about Jasmin’s routing.

When adding a Filter, the following parameters are required:

• type: One of the supported Filters: TransparentFilter, ConnectorFilter, UserFilter, GroupFilter, SourceAddrFilter, DestinationAddrFilter, ShortMessageFilter, DateIntervalFilter, TimeIntervalFilter, TagFilter, EvalPyFilter
• fid: Filter id (must be unique)

When choosing the Filter type, additional parameters may be added to the above required parameters:

Filters parameters

Name	Example	Parameters
TransparentFilter		No parameters are required
ConnectorFilter	smpp-01	cid of the connector to match
UserFilter	bobo	uid of the user to match
GroupFilter	partners	gid of the group to match
SourceAddrFilter	^20d+	source_addr: Regular expression to match source address
DestinationAddrFilter	^85111$	destination_addr: Regular expression to match destination address
ShortMessageFilter	^hello.*$	short_message: Regular expression to match message content
DateIntervalFilter	2014-09-18;2014-09-28	dateInterval: Two dates separated by ; (date format is YYYY-MM-DD)
TimeIntervalFilter	08:00:00;18:00:00	timeInterval: Two timestamps separated by ; (timestamp format is HH:MM:SS)
TagFilter	32401	tag: numeric tag to match in message
EvalPyFilter	/root/thirdparty.py	pyCode: Path to a python script, (External business logic for more details)

Here’s an example of adding a TransparentFilter

jcli : filter -a
Adding a new Filter: (ok: save, ko: exit)
type fid
> type transparentfilter
> fid TF
> ok
Successfully added Filter [TransparentFilter] with fid:TF

Here’s an example of adding a SourceAddrFilter

jcli : filter -a
Adding a new Filter: (ok: save, ko: exit)
> type sourceaddrfilter
jasmin.routing.Filters.SourceAddrFilter arguments:
source_addr
> source_addr ^20\d+
> ok
You must set these options before saving: type, fid, source_addr
> fid From20*
> ok
Successfully added Filter [SourceAddrFilter] with fid:From20*

Here’s an example of adding a TimeIntervalFilter

jcli : filter -a
Adding a new Filter: (ok: save, ko: exit)
> fid WorkingHours
> type timeintervalfilter
jasmin.routing.Filters.TimeIntervalFilter arguments:
timeInterval
> timeInterval 08:00:00;18:00:00
> ok
Successfully added Filter [TimeIntervalFilter] with fid:WorkingHours

It is possible to list filters with:

jcli : filter -l
#Filter id        Type                   Routes Description
#StartWithHello   ShortMessageFilter     MO MT  <ShortMessageFilter (msg=^hello.*$)>
#ExternalPy       EvalPyFilter           MO MT  <EvalPyFilter (pyCode= ..)>
#To85111          DestinationAddrFilter  MO MT  <DestinationAddrFilter (dst_addr=^85111$)>
#September2014    DateIntervalFilter     MO MT  <DateIntervalFilter (2014-09-01,2014-09-30)>
#WorkingHours     TimeIntervalFilter     MO MT  <TimeIntervalFilter (08:00:00,18:00:00)>
#TF               TransparentFilter      MO MT  <TransparentFilter>
#TG-Spain-Vodacom TagFilter              MO MT  <TG (tag=21401)>
#From20*          SourceAddrFilter       MO     <SourceAddrFilter (src_addr=^20\d+)>
Total Filters: 7

It is possible to obtain more information of a specific filter by typing filter -s <fid>:

jcli : filter -s September2014
DateIntervalFilter:
Left border = 2014-09-01
Right border = 2014-09-30

More control commands:

• filter -r <fid>: Remove filter

External business logic

In addition to predefined filters listed above (Filter manager), it is possible to extend filtering with external scripts written in Python using the EvalPyFilter.

Here’s a very simple example where an EvalPyFilter is matching the connector cid of a message:

First, write an external python script:

# File @ /opt/jasmin-scripts/routing/abc-connector.py
if routable.connector.cid == 'abc':
    result = True
else:
    result = False

Second, create an EvalPyFilter with the python script:

jcli : filter -a
Adding a new Filter: (ok: save, ko: exit)
> type EvalPyFilter
jasmin.routing.Filters.EvalPyFilter arguments:
pyCode
> pyCode /opt/jasmin-scripts/routing/abc-connector.py
> fid SimpleThirdParty
> ok
Successfully added Filter [EvalPyFilter] with fid:SimpleThirdParty

This example will provide an EvalPyFilter (SimpleThirdParty) that will match any message coming from the connector with cid = abc.

Using EvalPyFilter is as simple as the shown example, when the python script is called it will get the following global variables set:

• routable: one of the jasmin.routing.Routables.Routable inheriters (Routable for more details)
• result: (default to False) It will be read by Jasmin router at the end of the script execution to check if the filter is matching the message passed through the routable variable, matched=True / unmatched=False

Note

It is possible to check for any parameter of the SMPP PDU: TON, NPI, PROTOCOL_ID … since it is provided through the routable object.

Note

Using EvalPyFilter offers the possibility to call external webservices, databases … for powerfull routing or even for logging, rating & billing through external third party systems.

Hint

More examples in the this FAQ’s question: Can you provide an example of how to use EvalPyFilter ?

HTTP Client connector manager

The HTTP Client connector manager module is accessible through the httpccm command and is providing the following features:

httpccm command line options

Command	Description
-l, –list	List HTTP client connectors
-a, –add	Add a new HTTP client connector
-r FID, –remove=FID	Remove HTTP client connector using it’s CID
-s FID, –show=FID	Show HTTP client connector using it’s CID

A HTTP Client connector is used in SMS-MO routing, it is called with the message parameters when it is returned by a matched MO Route (Receiving SMS-MO for more details).

When adding a HTTP Client connector, the following parameters are required:

• cid: Connector id (must be unique)
• url: URL to be called with message parameters
• method: Calling method (GET or POST)

Here’s an example of adding a new HTTP Client connector:

jcli : httpccm -a
Adding a new Httpcc: (ok: save, ko: exit)
> url http://10.10.20.125/receive-sms/mo.php
> method GET
> cid HTTP-01
> ok
Successfully added Httpcc [HttpConnector] with cid:HTTP-01

All the above parameters can be displayed after Connector creation:

jcli : httpccm -s HTTP-01
HttpConnector:
cid = HTTP-01
baseurl = http://10.10.20.125/receive-sms/mo.php
method = GET

Listing Connectors will show currently added Connectors with their CID, Type, Method and Url:

jcli : httpccm -l
#Httpcc id        Type                   Method URL
#HTTP-01          HttpConnector          GET    http://10.10.20.125/receive-sms/mo.php
Total Httpccs: 1

Stats manager

The Stats manager module is responsible for showing real time statistics, aggregated counters and values such as current bound connections of a User, number of http requests, number of sent messages through a Route, Filter, Connector …

Note

All values are collected during Jasmin’s uptime and they are lost when Jasmin goes off, Stats manager shall be used for monitoring activities but not for advanced business reports.

The Stats manager module is accessible through the stats command and is providing the following features:

stats command line options

Command	Description
–user=UID	Show user stats using it’s UID
–users	Show all users stats
–smppc=CID	Show smpp connector stats using it’s CID
–smppcs	Show all smpp connectors stats
–smppsapi	Show SMPP Server API stats

The Stats manager covers different sections, this includes Users, SMPP Client connectors, Routes (MO and MT), APIs (HTTP and SMPP).

User statistics

The Stats manager exposes an overall view of all existent users as well as a per-user information view:

• stats –users: Will show an overall view of all existent users
• stats –user foo: Will show detailed information for foo

Here’s an example of showing an overall view where users sandra and foo are actually having 2 and 6 SMPP bound connections, user bar is using the HTTP Api only and sandra is using both APIs:

jcli : stats --users
#User id  SMPP Bound connections  SMPP L.A.            HTTP requests counter  HTTP L.A.
#sandra   2                       2019-06-02 15:35:01  20                     2019-06-01 12:12:33
#foo      6                       2019-06-02 15:35:10  0                      ND
#bar      0                       ND                   1289                   2019-06-02 15:39:12
Total users: 3

The columns shown for each user are explained in the following table:

Columns of the overall statistics for users

Column	Description
SMPP Bound connections	Number of current bound SMPP connections
SMPP L.A.	SMPP Server Last Activity date & time
HTTP requests counter	Counter of all http requests done by the user
HTTP L.A.	HTTP Api Last Activity date & time

Here’s an example of showing sandra’s detailed statistics:

jcli : stats --user sandra
#Item                     Type         Value
#bind_count                SMPP Server  26
#submit_sm_count           SMPP Server  1500
#submit_sm_request_count   SMPP Server  1506
#unbind_count              SMPP Server  24
#data_sm_count             SMPP Server  0
#last_activity_at          SMPP Server  2019-06-02 15:35:01
#other_submit_error_count  SMPP Server  4
#throttling_error_count    SMPP Server  2
#bound_connections_count   SMPP Server  {'bind_transmitter': 1, 'bind_receiver': 1, 'bind_transceiver': 0}
#elink_count               SMPP Server  16
#qos_last_submit_sm_at     SMPP Server  2019-06-02 12:31:23
#deliver_sm_count          SMPP Server  1430
#connects_count            HTTP Api     156
#last_activity_at          HTTP Api     2019-06-01 12:12:33
#rate_request_count        HTTP Api     20
#submit_sm_request_count   HTTP Api     102
#qos_last_submit_sm_at     HTTP Api     2019-05-22 15:56:02
#balance_request_count     HTTP Api     16

This is clearly a more detailed view for user sandra, the following table explains the items shown for sandra:

Details user statistics view items

Item	Type	Description
last_activity_at	SMPP Server	Date & time of last received PDU from user
bind_count	SMPP Server	Binds counter value
bound_connections_count	SMPP Server	Currently bound connections
submit_sm_request_count	SMPP Server	Number of requested SubmitSM (MT messages)
submit_sm_count	SMPP Server	Number of SubmitSM (MT messages) really sent by user
throttling_error_count	SMPP Server	Throttling errors received by user
other_submit_error_count	SMPP Server	Any other error received in response of SubmitSM requests
elink_count	SMPP Server	Number of enquire_link PDUs sent by user
deliver_sm_count	SMPP Server	Number of DeliverSM (MO messages or receipts) received
data_sm_count	SMPP Server	Number of DataSM (MO messages or receipts) received
qos_last_submit_sm_at	SMPP Server	Date & time of last SubmitSM (MT Message) sent
unbind_count	SMPP Server	Unbinds counter value
qos_last_submit_sm_at	HTTP Api	Date & time of last SubmitSM (MT Message sent)
connects_count	HTTP Api	HTTP request counter value
last_activity_at	HTTP Api	Date & time of last HTTP request
submit_sm_request_count	HTTP Api	Number of SubmitSM (MT messages) sent
rate_request_count	HTTP Api	Number of rate requests
balance_request_count	HTTP Api	Number of balance requests

SMPP Client connectors statistics

The Stats manager exposes an overall view of all existent smppc connectors as well as a per-smppc information view:

• stats –smppcs: Will show an overall view of all existent smppc connectors
• stats –smppc foo: Will show detailed information for foo

Here’s an example of showing an overall view where smppc connectors MTN and ORANGE are actives, connector SFONE made no activity at all:

jcli : stats --smppcs
#Connector id  Connected at Bound at             Disconnected at     Submits Delivers QoS errs Other errs
#MTN           6            2019-06-02 15:35:01  2019-06-02 15:35:01 12/10   9/10     2        0
#Orange        1            2019-06-02 15:35:01  2019-06-02 15:35:01 0/0     12022/0  0        0
#SFONE         0            ND                   ND                  0/0     0/0      0        0
Total connectors: 3

The columns shown for each user are explained in the following table:

Columns of the overall statistics for smppcs

Column	Description
Bound count	Binds counter value
Connected at	Last connection date & time
Bound at	Last successful bind date & time
Disconnected at	Last disconnection date & time
Submits	Number of requested SubmitSM PDUs / Sent SubmitSM PDUs
Delivers	Number of received DeliverSM PDUs / Number of received DataSM PDUs
QoS errs	Number of rejected SubmitSM PDUs due to throttling limitation
Other errs	Number of all other rejections of SubmitSM PDUs

Here’s an example of showing MTN’s detailed statistics:

jcli : stats --smppc MTN
#Item                      Value
#bound_at                  2019-06-02 15:35:01
#disconnected_count        2
#other_submit_error_count  0
#submit_sm_count           2300
#created_at                2019-06-01 12:29:42
#bound_count               3
#last_received_elink_at    2019-06-02 15:32:28
#elink_count               34
#throttling_error_count    44
#last_sent_elink_at        2019-06-02 15:34:57
#connected_count           3
#connected_at              2019-06-02 15:35:01
#deliver_sm_count          1302
#data_sm_count             0
#submit_sm_request_count   2344
#last_seqNum               1733
#last_seqNum_at            2019-06-02 15:35:57
#last_sent_pdu_at          2019-06-02 15:35:59
#disconnected_at           2019-06-01 10:18:21
#last_received_pdu_at      2019-06-02 15:36:01
#interceptor_count         0
#interceptor_error_count   0

This is clearly a more detailed view for connector MTN, the following table explains the items shown for MTN:

Details of smppc statistics view items

Item	Description
created_at	Connector creation date & time
last_received_pdu_at	Date & time of last received PDU
last_sent_pdu_at	Date & time of last sent PDU
last_received_elink_at	Date & time of last received enquire_link PDU
last_sent_elink_at	Date & time of last sent enquire_link PDU
last_seqNum_at	Date & time of last sequence_number claim
last_seqNum	Value of last claimed sequence_number
connected_at	Last connection date & time
bound_at	Last successful bind date & time
disconnected_at	Last disconnection date & time
connected_count	Last connection date & time
bound_count	Binds counter value
disconnected_count	Last disconnection date & time
submit_sm_request_count	Number of requested SubmitSM (MT messages)
submit_sm_count	Number of SubmitSM (MT messages) really sent (having ESME_ROK response)
throttling_error_count	Throttling errors received
other_submit_error_count	Any other error received in response of SubmitSM requests
elink_count	Number of enquire_link PDUs sent
deliver_sm_count	Number of DeliverSM (MO messages or receipts) received
data_sm_count	Number of DataSM (MO messages or receipts) received
interceptor_count	Number of successfully intercepted messages (MO)
interceptor_error_count	Number of failures when intercepting messages (MO)

SMPP Server API statistics

The Stats manager exposes collected statistics in SMPP Server API through the following jCli command:

• stats –smppsapi

Here’s an example of showing the statistics:

jcli : stats --smppsapi
#Item                      Value
#disconnect_count          2
#bound_rx_count            1
#bound_tx_count            0
#other_submit_error_count  0
#bind_rx_count             0
#bind_trx_count            0
#created_at                2019-06-04 02:22:17
#last_received_elink_at    ND
#elink_count               89
#throttling_error_count    1
#submit_sm_count           199
#connected_count           2
#connect_count             16
#bound_trx_count           1
#data_sm_count             2
#submit_sm_request_count   200
#deliver_sm_count          145
#last_sent_pdu_at          2019-06-05 12:12:13
#unbind_count              6
#last_received_pdu_at      2019-06-05 12:16:21
#bind_tx_count             6
#interceptor_count         0
#interceptor_error_count   0

The following table explains the items shown in the above example:

Details of smppsapi statistics view items

Item	Description
created_at	Connector creation date & time
last_received_pdu_at	Date & time of last received PDU
last_sent_pdu_at	Date & time of last sent PDU
last_received_elink_at	Date & time of last received enquire_link PDU
connected_count	Last connection date & time
connect_count	TCP Connection request count
disconnect_count	Disconnection count
bind_trx_count	Transceiver bind request count
bound_trx_count	Actually bound transceiver connections count
bind_rx_count	Receiver bind request count
bound_rx_count	Actually bound receiver connections count
bind_tx_count	Transmitter bind request count
bound_tx_count	Actually bound transmitter connections count
submit_sm_request_count	Number of requested SubmitSM (MT messages)
submit_sm_count	Number of SubmitSM (MT messages) accepted (returned a ESME_ROK response)
deliver_sm_count	Number of DeliverSM (MO messages or receipts) sent
data_sm_count	Number of DataSM (MO messages or receipts) sent
elink_count	Number of enquire_link PDUs received
throttling_error_count	Throttling errors returned
other_submit_error_count	Any other error returned in response of SubmitSM requests
interceptor_count	Number of successfully intercepted messages (MT)
interceptor_error_count	Number of failures when intercepting messages (MT)

HTTP API statistics

The Stats manager exposes collected statistics in HTTP API through the following jCli command:

• stats –httpapi

Here’s an example of showing the statistics:

jcli : stats --httpapi
#Item                    Value
#server_error_count      120
#last_request_at         ND
#throughput_error_count  4
#success_count           14332
#route_error_count       156
#request_count           20126
#auth_error_count        78
#created_at              2019-06-04 02:22:17
#last_success_at         2019-06-05 18:20:29
#charging_error_count    178
#interceptor_count         0
#interceptor_error_count   0

The following table explains the items shown in the above example:

Details of httpapi statistics view items

Item	Description
created_at	Connector creation date & time
last_request_at	Date & time of last http request
last_success_at	Date & time of last successful http request (SMS is accepted for sending)
request_count	HTTP request count
success_count	Successful HTTP request count (SMS is accepted for sending)
auth_error_count	Authentication errors count
route_error_count	Route not found errors count
throughput_error_count	Throughput exceeded errors count
charging_error_count	Charging/Billing errors count
server_error_count	Unknown server errors count
interceptor_count	Number of successfully intercepted messages (MT)
interceptor_error_count	Number of failures when intercepting messages (MT)