Dear Rene / Users:
Good day!
I'd like to consult to you our experience using Kannel Opensmppbox.When an
ESME sends large TPS traffic, we noticed slow response from the Opensmppbox
app, thus creating a queue at the ESME's end. I have here sample PDUs:
*Submit_SM PDU*
*==============*
2017-03-27 14:59:13 [1641] [30] DEBUG: SMPP[]: Got PDU:
2017-03-27 14:59:13 [1641] [30] DEBUG: SMPP PDU 0x7fe24d4a77c0 dump:
*2017-03-27 14:59:13 [1641] [30] DEBUG: type_name: submit_sm*
2017-03-27 14:59:13 [1641] [30] DEBUG: command_id: 4 = 0x00000004
2017-03-27 14:59:13 [1641] [30] DEBUG: command_status: 0 = 0x00000000
2017-03-27 14:59:13 [1641] [30] DEBUG: sequence_number: 4488803 =
0x00447e63
2017-03-27 14:59:13 [1641] [30] DEBUG: service_type: NULL
2017-03-27 14:59:13 [1641] [30] DEBUG: source_addr_ton: 5 = 0x00000005
2017-03-27 14:59:13 [1641] [30] DEBUG: source_addr_npi: 0 = 0x00000000
2017-03-27 14:59:13 [1641] [30] DEBUG: source_addr: "xxxxxxxx"
2017-03-27 14:59:13 [1641] [30] DEBUG: dest_addr_ton: 1 = 0x00000001
2017-03-27 14:59:13 [1641] [30] DEBUG: dest_addr_npi: 1 = 0x00000001
2017-03-27 14:59:13 [1641] [30] DEBUG: destination_addr: "xxxxxxxxxxxx"
2017-03-27 14:59:13 [1641] [30] DEBUG: esm_class: 0 = 0x00000000
2017-03-27 14:59:13 [1641] [30] DEBUG: protocol_id: 0 = 0x00000000
2017-03-27 14:59:13 [1641] [30] DEBUG: priority_flag: 0 = 0x00000000
2017-03-27 14:59:13 [1641] [30] DEBUG: schedule_delivery_time: NULL
2017-03-27 14:59:13 [1641] [30] DEBUG: validity_period: "170329065905000+"
2017-03-27 14:59:13 [1641] [30] DEBUG: registered_delivery: 1 = 0x00000001
2017-03-27 14:59:13 [1641] [30] DEBUG: replace_if_present_flag: 0 =
0x00000000
2017-03-27 14:59:13 [1641] [30] DEBUG: data_coding: 0 = 0x00000000
2017-03-27 14:59:13 [1641] [30] DEBUG: sm_default_msg_id: 0 = 0x00000000
2017-03-27 14:59:13 [1641] [30] DEBUG: sm_length: 103 = 0x00000067
2017-03-27 14:59:13 [1641] [30] DEBUG: short_message:
2017-03-27 14:59:13 [1641] [30] DEBUG: Octet string at 0x7fe24d342720:
2017-03-27 14:59:13 [1641] [30] DEBUG: len: 103
2017-03-27 14:59:13 [1641] [30] DEBUG: size: 104
2017-03-27 14:59:13 [1641] [30] DEBUG: immutable: 0
2017-03-27 14:59:13 [1641] [30] DEBUG: data: xx xx xx xx xx xx xx xx
xx xx xx xx xx xx xx xx xxxxxxxxxxxxxxxx
2017-03-27 14:59:13 [1641] [30] DEBUG: data: xx xx xx xx xx xx xx xx
xx xx xx xx xx xx xx xx xxxxxxxxxxxxxxxx
2017-03-27 14:59:13 [1641] [30] DEBUG: data: xx xx xx xx xx xx xx xx
xx xx xx xx xx xx xx xx xxxxxxxxxxxxxxxx
2017-03-27 14:59:13 [1641] [30] DEBUG: data: xx xx xx xx xx xx xx xx
xx xx xx xx xx xx xx xx xxxxxxxxxxxxxxxx
2017-03-27 14:59:13 [1641] [30] DEBUG: data: xx xx xx xx xx xx xx xx
xx xx xx xx xx xx xx xx xxxxxxxxxxxxxxxx
2017-03-27 14:59:13 [1641] [30] DEBUG: data: xx xx xx xx xx xx xx xx
xx xx xx xx xx xx xx xx xxxxxxxxxxxxxxxx
2017-03-27 14:59:13 [1641] [30] DEBUG: data: xx xx xx xx xx xx xx
xxxxxxx
2017-03-27 14:59:13 [1641] [30] DEBUG: Octet string dump ends.
2017-03-27 14:59:13 [1641] [30] DEBUG: SMPP PDU dump ends.
*Submit_SM_Resp PDU:*
*==================*
2017-03-27 14:59:39 [1641] [29] DEBUG: SMPP[]: Sending PDU:
2017-03-27 14:59:39 [1641] [29] DEBUG: SMPP PDU 0x7fe24d34a6d0 dump:
*2017-03-27 14:59:39 [1641] [29] DEBUG: type_name: submit_sm_resp*
2017-03-27 14:59:39 [1641] [29] DEBUG: command_id: 2147483652
<(214)%20748-3652> = 0x80000004
2017-03-27 14:59:39 [1641] [29] DEBUG: command_status: 0 = 0x00000000
2017-03-27 14:59:39 [1641] [29] DEBUG: sequence_number: 4488803 =
0x00447e63
2017-03-27 14:59:39 [1641] [29] DEBUG: message_id:
2017-03-27 14:59:39 [1641] [29] DEBUG: Octet string at 0x7fe24d341f30:
2017-03-27 14:59:39 [1641] [29] DEBUG: len: 36
2017-03-27 14:59:39 [1641] [29] DEBUG: size: 37
2017-03-27 14:59:39 [1641] [29] DEBUG: immutable: 0
2017-03-27 14:59:39 [1641] [29] DEBUG: data: 32 32 39 64 62 39 32 63
2d 35 37 61 63 2d 34 33 229db92c-57ac-43
2017-03-27 14:59:39 [1641] [29] DEBUG: data: 34 35 2d 61 64 34 66 2d
36 61 35 65 65 39 66 31 45-ad4f-6a5ee9f1
2017-03-27 14:59:39 [1641] [29] DEBUG: data: 66 62 39 30
fb90
2017-03-27 14:59:39 [1641] [29] DEBUG: Octet string dump ends.
2017-03-27 14:59:39 [1641] [29] DEBUG: SMPP PDU dump ends.
Looking at the Bearerbox Access logs, i found that this sample was
processed right on time:
*Access Logs (CDRs)*
*2017-03-27 14:59:14 Sent SMS* [SMSC:HTTP.SMSC] [SVC:xxxxxx] [ACT:] [BINF:]
[FID:229db92c-57ac-4345-ad4f-6a5ee9f1fb90] [META:?smpp?] [from:xxxxxxxxxxx]
[to:+xxxxxxxxxxx] [flags:-1:0:-1:0:19] [msg:103:]
2017-03-27 14:59:19 Receive DLR [SMSC:HTTP.SMSC] [SVC:xxxxxx] [ACT:]
[BINF:] [FID:229db92c-57ac-4345-ad4f-6a5ee9f1fb90]
[META:?orig_msg?dlr_mask=19&] [from:xxxxxxxxx] [to:+xxxxxxxxxxxx]
[flags:-1:-1:-1:-1:1] [msg:0:] [udh:0:]
Also, DB table check confirmed that indeed the transaction was processed on
time:
*DB Sent_SMS*
+---------------------+------+------------------------------
--------+---------------------------------------------------
------------------------------------------------------+
| from_unixtime(time) | momt | dlr_url |
msgdata
|
+---------------------+------+------------------------------
--------+---------------------------------------------------
------------------------------------------------------+
| 2017-03-27 14:59:13 | MT | 229db92c-57ac-4345-ad4f-6a5ee9f1fb90 |
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |
| 2017-03-27 14:59:19 | DLR | 229db92c-57ac-4345-ad4f-6a5ee9f1fb90 | NULL
|
+---------------------+------+------------------------------
--------+---------------------------------------------------
------------------------------------------------------+
These logs, for me, is clear that opensmppbox response is slow for the
submissions from ESME's.
Our setup by the way is this:
*ESME <=> Opensmppbox <=> SQLBox <=> Bearebox <=> HTTP SMSC*
I hope you can take a look about this case.
Thank you and looking forward to your comments.
Kind regards,
Garzie
