Re: Strange smsbox/bearerbox problem : SMS messages not being sent

Thanks for the help, Alex and Andreas.

I've had a look at the specs. Thanks for the pointer, Andreas.

You are right, Alex. I'm not suffering from throttling problems. I have
no 0x00000058 errors in my logs, despite sometimes sending Kannel over
100 messages in a second on some occasions -- Orange have limited our
service to 6 messages a second. The system must be auto throttling.

The error code appears to be a "submit_sm or submit_multi failed"
message. Looking at the occurences of this error I'm getting it in
relation to a "WARNING: SMPP: PDU NUL terminated string has no NUL."
message following submission of a message. This particular message had
an invalide phone number. I wonder if that is the problem...

10:28:37 [8] DEBUG: SMPP[duckalorange]: Manually forced source addr ton = 1, source add npi = 1
10:28:37 [8] DEBUG: SMPP[duckalorange]: Manually forced dest addr ton = 1, dest add npi = 1
10:28:37 [8] DEBUG: SMPP[duckalorange]: Sending PDU:
10:28:37 [8] DEBUG: SMPP PDU 0x8129a10 dump:
10:28:37 [8] DEBUG:   type_name: submit_sm
10:28:37 [8] DEBUG:   command_id: 4 = 0x00000004
10:28:37 [8] DEBUG:   command_status: 0 = 0x00000000
10:28:37 [8] DEBUG:   sequence_number: 34171 = 0x0000857b
10:28:37 [8] DEBUG:   service_type: NULL
10:28:37 [8] DEBUG:   source_addr_ton: 1 = 0x00000001
10:28:37 [8] DEBUG:   source_addr_npi: 1 = 0x00000001
10:28:37 [8] DEBUG:   source_addr: "xxxxxxxxxxxx"
10:28:37 [8] DEBUG:   dest_addr_ton: 1 = 0x00000001
10:28:37 [8] DEBUG:   dest_addr_npi: 1 = 0x00000001
10:28:37 [8] DEBUG:   destination_addr: "xxxxxxxxxxxx"
10:28:37 [8] DEBUG:   esm_class: 3 = 0x00000003
10:28:37 [8] DEBUG:   protocol_id: 0 = 0x00000000
10:28:37 [8] DEBUG:   priority_flag: 0 = 0x00000000
10:28:37 [8] DEBUG:   schedule_delivery_time: NULL
10:28:37 [8] DEBUG:   validity_period: NULL
10:28:37 [8] DEBUG:   registered_delivery: 0 = 0x00000000
10:28:37 [8] DEBUG:   replace_if_present_flag: 0 = 0x00000000
10:28:37 [8] DEBUG:   data_coding: 0 = 0x00000000
10:28:37 [8] DEBUG:   sm_default_msg_id: 0 = 0x00000000
10:28:37 [8] DEBUG:   sm_length: 61 = 0x0000003d
10:28:37 [8] DEBUG:   short_message:
10:28:37 [8] DEBUG:    Octet string at 0x8128490:
10:28:37 [8] DEBUG:      len:  61
10:28:37 [8] DEBUG:      size: 62
10:28:37 [8] DEBUG:      immutable: 0
10:28:37 [8] DEBUG:      data: 48 69 20 4a 75 6c 69 61   Hi Julia
10:28:37 [8] DEBUG:      data: 6e 2e 20 54 68 6f 75 67   n. Thoug
10:28:37 [8] DEBUG:      data: 68 74 20 49 27 64 20 73   ht I'd s
10:28:37 [8] DEBUG:      data: 65 6e 64 20 74 68 69 73   end this
10:28:37 [8] DEBUG:      data: 20 61 6e 64 20 73 65 65    and see
10:28:37 [8] DEBUG:      data: 20 69 66 20 79 6f 75 20    if you
10:28:37 [8] DEBUG:      data: 67 65 74 20 69 74 2e 20   get it.
10:28:37 [8] DEBUG:      data: 52 6f 72 79 2e            Rory.
10:28:37 [8] DEBUG:    Octet string dump ends.
10:28:37 [8] DEBUG: SMPP PDU dump ends.
10:28:37 [8] WARNING: SMPP: PDU NUL terminated string has no NUL.
10:28:37 [8] DEBUG: SMPP[duckalorange]: Got PDU:
10:28:37 [8] DEBUG: SMPP PDU 0x8129a10 dump:
10:28:37 [8] DEBUG:   type_name: submit_sm_resp
10:28:37 [8] DEBUG:   command_id: 2147483652 = 0x80000004
10:28:37 [8] DEBUG:   command_status: 69 = 0x00000045
10:28:37 [8] DEBUG:   sequence_number: 34171 = 0x0000857b
10:28:37 [8] DEBUG:   message_id: NULL
10:28:37 [8] DEBUG: SMPP PDU dump ends.
10:28:37 [8] ERROR: SMPP[duckalorange]: SMSC returned error code 0x00000045 in response to submit_sm.



On 10/06/03, Alex Judd ([email protected]) wrote:
> With our connection to Orange we have higher capacity, however still got
> 0x00000058 I/F Throttled Error when we exceed our per second limit.
> 
> e.g. "2003-06-10 11:48:07 [5] ERROR: SMPP[Orange]: SMSC returned error code
> 0x00000058 in response to submit_sm."
> 
> Kannel then throttles back (although not very elegantly) and we resume
> message sending.
> 
> Couple of thoughts.
> 
> 1. Are you using the CVS version of Kannel?

Nope 1.3.1

> 2. Should a throttle message be an INFO message not an ERROR (it is
> perfectly legal to over send as long as we react to the throttling messages)
> 3. Control the speed at application level before sending to Kannel

Done that, but it looks like the errors (whatever they are) might
continue.

> 4. We should have more elegant throttling code in the SMPP driver
-- 
Rory Campbell-Lange 
<[email protected]>
<www.campbell-lange.net>