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 <rene.klu...@chimit.nl> 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" <garz...@gmail.com>
> Aan: users@kannel.org
> 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: 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
>
>

Reply via email to