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 Issue

2017-04-04 Thread Wan Md Arif Noor Bin. Wan Nizam 
Hi Rene,

I don’t quite understand what you mean by something different from smpp, is 
there any way for me to trace which transaction / sequence was causing this 
error, I already done a tcpdump but can’t really find anything peculiar.

Thanks again,
Arif Noor


From: Rene Kluwen [mailto:rene.klu...@chimit.nl]
Sent: Monday, April 03, 2017 9:26 PM
To: Wan Md Arif Noor Bin. Wan Nizam; users@kannel.org
Subject: Re: Opensmppbox Issue

Most probable cause is that they connect with something different from smpp.

-- Origineel bericht --
Van: "Wan Md Arif Noor Bin. Wan Nizam" 
>
Aan: "users@kannel.org" 
>
Verzonden: 29-3-2017 4:22:28
Onderwerp: Opensmppbox Issue

Hi Kannel Users,

I have an issue where recently user is constatly reconnecting to the 
opensmppbox. Digging into the logs found below information.

1008761:2017-03-29 09:50:23 [17929] [3595] ERROR: SMPP: PDU length was too 
small (4, minimum is 16).
1008762:2017-03-29 09:50:23 [17929] [3595] ERROR: opensmppbox[Zen]: Server sent 
garbage, ignored.
1008763:2017-03-29 09:50:23 [17929] [3595] ERROR: Invalid SMPP PDU received.
1008764:2017-03-29 09:50:23 [17929] [3595] DEBUG: Thread 3595 
(opensmppbox.c:smpp_to_bearerbox) terminates.

This only occur recently since few days ago for that particular user. Can’t 
find anything weird or what sequence caused that in the logs aside from above. 
Kindly advise.

Kannel Version :

Kannel bearerbox version `svn-r5154M'.
Opensmppbox version 1.5.0

Thanks,
Arif Noor

Re: Passing Unicode as MO to HTTP SMSC

2017-04-04 Thread ha...@aeon.pk 
Hi Rene,

Thanks a lot. *=utf8* did the trick, without coding parameter.

Regards,
Hamza

On Mon, Apr 3, 2017 at 6:31 PM, Rene Kluwen  wrote:

> On top of my head, I think the parameter is coding=2 and also charset=utf8.
> Not sure if the http smsc also listens to these. But it's worth a try.
>
> -- Origineel bericht --
> Van: "ha...@aeon.pk" 
> Aan: "kannel users" 
> Verzonden: 1-4-2017 1:12:11
> Onderwerp: Passing Unicode as MO to HTTP SMSC
>
> Hi,
>
> I am using an HTTP SMSC to route my SMS traffic via kannel. The incoming
> MO URL is http://localhost:13031/?username=tester=
> foobar=1234567890==Hello. Filling this URL for all
> parameters and passing onto kannel works very fine. However, if the message
> variable is Unicode, Kannel does not understands it and treats it as
> garbage. How can I let kannel know that the message is Unicodem so that it
> translates it right? Do I pass some extra parameter in the URL?
>
> Many thanks,
> Hamza
>
>