Opensmppbox Slow Response (submit_sm_resp)

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Opensmppbox Slow Response (submit_sm_resp)

garz m
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: <a href="tel:(214)%20748-3652" value="+12147483652" target="_blank">2147483652 = 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 | xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |
| 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
Reply | Threaded
Open this post in threaded view
|

Re: Opensmppbox Slow Response (submit_sm_resp)

Rene Kluwen
Once the message is in the access log it has passed opensmppbox already.
So if throughput is slow, maybe it's your downstream smsc connection.


------ Origineel bericht ------
Van: "garz m" <[hidden email]>
Verzonden: 30-3-2017 10:24:54
Onderwerp: Opensmppbox Slow Response (submit_sm_resp)

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: <a href="tel:(214)%20748-3652" value="+12147483652">2147483652 = 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 | xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |
| 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
Reply | Threaded
Open this post in threaded view
|

Re: Opensmppbox Slow Response (submit_sm_resp)

garz m
Hi Rene,

Thanks for the response. I have the same understanding - access logs are processed transactions of the bearerbox. In this case, the submission from the opensmppbox to sqlbox to bearerbox is right on time. But then again the response back of opensmppbox is delayed. Isn't that opensmppbox should send right away the submit_sm_resp once it gets the submit_sm? Is there on the codes I can adjust to achieve this behaviour?

BR,
Garzie

On Mon, Apr 3, 2017 at 9:29 PM, Rene Kluwen <[hidden email]> wrote:
Once the message is in the access log it has passed opensmppbox already.
So if throughput is slow, maybe it's your downstream smsc connection.


------ Origineel bericht ------
Van: "garz m" <[hidden email]>
Verzonden: 30-3-2017 10:24:54
Onderwerp: Opensmppbox Slow Response (submit_sm_resp)

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: <a href="tel:(214)%20748-3652" value="+12147483652" target="_blank">2147483652 = 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 | xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |
| 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