Re: Opensmppbox Slow Response (submit_sm_resp)

2017-04-04 Thread 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  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" 
> 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 = 0x0004
> 2017-03-27 14:59:13 [1641] [30] DEBUG:   command_status: 0 = 0x
> 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 = 0x0005
> 2017-03-27 14:59:13 [1641] [30] DEBUG:   source_addr_npi: 0 = 0x
> 2017-03-27 14:59:13 [1641] [30] DEBUG:   source_addr: ""
> 2017-03-27 14:59:13 [1641] [30] DEBUG:   dest_addr_ton: 1 = 0x0001
> 2017-03-27 14:59:13 [1641] [30] DEBUG:   dest_addr_npi: 1 = 0x0001
> 2017-03-27 14:59:13 [1641] [30] DEBUG:   destination_addr: ""
> 2017-03-27 14:59:13 [1641] [30] DEBUG:   esm_class: 0 = 0x
> 2017-03-27 14:59:13 [1641] [30] DEBUG:   protocol_id: 0 = 0x
> 2017-03-27 14:59:13 [1641] [30] DEBUG:   priority_flag: 0 = 0x
> 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 =
> 0x0001
> 2017-03-27 14:59:13 [1641] [30] DEBUG:   replace_if_present_flag: 0 =
> 0x
> 2017-03-27 14:59:13 [1641] [30] DEBUG:   data_coding: 0 = 0x
> 2017-03-27 14:59:13 [1641] [30] DEBUG:   sm_default_msg_id: 0 = 0x
> 2017-03-27 14:59:13 [1641] [30] DEBUG:   sm_length: 103 = 0x0067
> 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   
> 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   
> 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   
> 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   
> 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   
> 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   
> 2017-03-27 14:59:13 [1641] [30] DEBUG:  data: xx xx xx xx xx xx xx
>  xxx
> 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> = 0x8004
> 2017-03-27 14:59:39 [1641] [29] DEBUG:   command_status: 0 = 0x
> 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

Re: Opensmppbox Slow Response (submit_sm_resp)

2017-04-03 Thread 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" 
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 = 0x0004
2017-03-27 14:59:13 [1641] [30] DEBUG:   command_status: 0 = 0x
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 = 
0x0005
2017-03-27 14:59:13 [1641] [30] DEBUG:   source_addr_npi: 0 = 
0x

2017-03-27 14:59:13 [1641] [30] DEBUG:   source_addr: ""
2017-03-27 14:59:13 [1641] [30] DEBUG:   dest_addr_ton: 1 = 0x0001
2017-03-27 14:59:13 [1641] [30] DEBUG:   dest_addr_npi: 1 = 0x0001
2017-03-27 14:59:13 [1641] [30] DEBUG:   destination_addr: 
""

2017-03-27 14:59:13 [1641] [30] DEBUG:   esm_class: 0 = 0x
2017-03-27 14:59:13 [1641] [30] DEBUG:   protocol_id: 0 = 0x
2017-03-27 14:59:13 [1641] [30] DEBUG:   priority_flag: 0 = 0x
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 = 
0x0001
2017-03-27 14:59:13 [1641] [30] DEBUG:   replace_if_present_flag: 0 = 
0x

2017-03-27 14:59:13 [1641] [30] DEBUG:   data_coding: 0 = 0x
2017-03-27 14:59:13 [1641] [30] DEBUG:   sm_default_msg_id: 0 = 
0x

2017-03-27 14:59:13 [1641] [30] DEBUG:   sm_length: 103 = 0x0067
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   
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   
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   
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   
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   
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   
2017-03-27 14:59:13 [1641] [30] DEBUG:  data: xx xx xx xx xx xx xx  
xxx

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 
 = 0x8004

2017-03-27 14:59:39 [1641] [29] DEBUG:   command_status: 0 = 0x
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:xx] [ACT:] 
[BINF:] [FID:229db92c-57ac-4345-ad4f-6a5ee9f1fb90] [META:?smpp?] 
[from:xxx]