Amol Patwardhan wrote:
Hi Stipe/Alex,
Please take a look at the SMPP PDU dump: Kannel bearerbox II version
cvs-20060110
2006-01-29 15:51:41 [12663] [6] DEBUG: SMPP[XXX]: Got PDU:
2006-01-29 15:51:41 [12663] [6] DEBUG: SMPP PDU 0x8a0c5e8 dump:
2006-01-29 15:51:41 [12663] [6] DEBUG: type_name: deliver_sm
2006-01-29 15:51:41 [12663] [6] DEBUG: command_id: 5 = 0x00000005
2006-01-29 15:51:41 [12663] [6] DEBUG: command_status: 0 = 0x00000000
2006-01-29 15:51:41 [12663] [6] DEBUG: sequence_number: 2 = 0x00000002
2006-01-29 15:51:41 [12663] [6] DEBUG: service_type: NULL
2006-01-29 15:51:41 [12663] [6] DEBUG: source_addr_ton: 1 = 0x00000001
2006-01-29 15:51:41 [12663] [6] DEBUG: source_addr_npi: 1 = 0x00000001
2006-01-29 15:51:41 [12663] [6] DEBUG: source_addr: "97339405477"
2006-01-29 15:51:41 [12663] [6] DEBUG: dest_addr_ton: 1 = 0x00000001
2006-01-29 15:51:41 [12663] [6] DEBUG: dest_addr_npi: 1 = 0x00000001
2006-01-29 15:51:41 [12663] [6] DEBUG: destination_addr: "4900"
2006-01-29 15:51:41 [12663] [6] DEBUG: esm_class: 0 = 0x00000000
2006-01-29 15:51:41 [12663] [6] DEBUG: protocol_id: 0 = 0x00000000
2006-01-29 15:51:41 [12663] [6] DEBUG: priority_flag: 0 = 0x00000000
2006-01-29 15:51:41 [12663] [6] DEBUG: schedule_delivery_time: NULL
2006-01-29 15:51:41 [12663] [6] DEBUG: validity_period: NULL
2006-01-29 15:51:41 [12663] [6] DEBUG: registered_delivery: 0 = 0x00000000
2006-01-29 15:51:41 [12663] [6] DEBUG: replace_if_present_flag: 0 = 0x00000000
2006-01-29 15:51:41 [12663] [6] DEBUG: data_coding: 0 = 0x00000000
2006-01-29 15:51:41 [12663] [6] DEBUG: sm_default_msg_id: 0 = 0x00000000
2006-01-29 15:51:41 [12663] [6] DEBUG: sm_length: 23 = 0x00000017
2006-01-29 15:51:41 [12663] [6] DEBUG: short_message:
2006-01-29 15:51:41 [12663] [6] DEBUG: Octet string at 0x8a0ca50:
2006-01-29 15:51:41 [12663] [6] DEBUG: len: 23
2006-01-29 15:51:41 [12663] [6] DEBUG: size: 24
2006-01-29 15:51:41 [12663] [6] DEBUG: immutable: 0
2006-01-29 15:51:41 [12663] [6] DEBUG: data: 0F 0F 0F 0F 0F 0F 0F 02 05 00
02 02 0b 01 0c 0a XXXXXXXBE XXXXXX
2006-01-29 15:51:41 [12663] [6] DEBUG: data: 0c 02 02 0b 09 30 03
,XXXXXX
2006-01-29 15:51:41 [12663] [6] DEBUG: Octet string dump ends.
2006-01-29 15:51:41 [12663] [6] DEBUG: SMPP PDU dump ends.
2006-01-29 15:51:41 [12663] [6] ERROR: SMPP[MAR]: Mallformed addr `4900',
expected at least 7 digits.
*******************************************************************************
When I reverted the kannel version back to: Kannel bearerbox II version cvs-20050908
After this it works fine i.e., the TON is accepted and not treated as 'Mallformed'.
SMPP PDU for this version,
2006-02-05 10:01:50 [12740] [6] DEBUG: SMPP[MAR]: Got PDU:
2006-02-05 10:01:50 [12740] [6] DEBUG: SMPP PDU 0x927d140 dump:
2006-02-05 10:01:50 [12740] [6] DEBUG: type_name: deliver_sm
2006-02-05 10:01:50 [12740] [6] DEBUG: command_id: 5 = 0x00000005
2006-02-05 10:01:50 [12740] [6] DEBUG: command_status: 0 = 0x00000000
2006-02-05 10:01:50 [12740] [6] DEBUG: sequence_number: 1 = 0x00000001
2006-02-05 10:01:50 [12740] [6] DEBUG: service_type: NULL
2006-02-05 10:01:50 [12740] [6] DEBUG: source_addr_ton: 1 = 0x00000001
2006-02-05 10:01:50 [12740] [6] DEBUG: source_addr_npi: 1 = 0x00000001
2006-02-05 10:01:50 [12740] [6] DEBUG: source_addr: "97339405477"
2006-02-05 10:01:50 [12740] [6] DEBUG: dest_addr_ton: 1 = 0x00000001
2006-02-05 10:01:50 [12740] [6] DEBUG: dest_addr_npi: 1 = 0x00000001
2006-02-05 10:01:50 [12740] [6] DEBUG: destination_addr: "4900"
2006-02-05 10:01:50 [12740] [6] DEBUG: esm_class: 0 = 0x00000000
2006-02-05 10:01:50 [12740] [6] DEBUG: protocol_id: 0 = 0x00000000
2006-02-05 10:01:50 [12740] [6] DEBUG: priority_flag: 0 = 0x00000000
2006-02-05 10:01:50 [12740] [6] DEBUG: schedule_delivery_time: NULL
2006-02-05 10:01:50 [12740] [6] DEBUG: validity_period: NULL
2006-02-05 10:01:50 [12740] [6] DEBUG: registered_delivery: 0 = 0x00000000
2006-02-05 10:01:50 [12740] [6] DEBUG: replace_if_present_flag: 0 = 0x00000000
2006-02-05 10:01:50 [12740] [6] DEBUG: data_coding: 0 = 0x00000000
2006-02-05 10:01:50 [12740] [6] DEBUG: sm_default_msg_id: 0 = 0x00000000
2006-02-05 10:01:50 [12740] [6] DEBUG: sm_length: 4 = 0x00000004
2006-02-05 10:01:50 [12740] [6] DEBUG: short_message: "Test"
2006-02-05 10:01:50 [12740] [6] DEBUG: SMPP PDU dump ends.
2006-02-05 10:01:50 [12740] [6] DEBUG: SMPP[MAR]: Sending PDU:
2006-02-05 10:01:50 [12740] [6] DEBUG: SMPP PDU 0x927d218 dump:
2006-02-05 10:01:50 [12740] [6] DEBUG: type_name: deliver_sm_resp
2006-02-05 10:01:50 [12740] [9] DEBUG: send_msg: sending msg to boxc: <XXX>
2006-02-05 10:01:50 [12740] [6] DEBUG: command_id: 2147483653 = 0x80000005
2006-02-05 10:01:50 [12740] [6] DEBUG: command_status: 0 = 0x00000000
2006-02-05 10:01:50 [12740] [9] DEBUG: boxc_sender: sent message to <127.0.0.1>
2006-02-05 10:01:50 [12740] [6] DEBUG: sequence_number: 1 = 0x00000001
2006-02-05 10:01:50 [12740] [6] DEBUG: message_id: NULL
2006-02-05 10:01:50 [12740] [6] DEBUG: SMPP PDU dump ends.
yep, the following commit added the "checking":
http://www.kannel.org/cgi-bin/viewcvs.cgi/gateway/gw/smsc/smsc_smpp.c.diff?r1=1.80&r2=1.81
Unfortunatly the checking itself is correct, speaking in semantics of the SMPP
protocoll. Which means the SMSC is mis-behaving.
@Alex: is it enough to set 'dest-addr-ton', 'dest-addr-npi' inside smsc group to
get rid of this. Or is the checking done before that and hence we baild out?
@Amol: you should contact your SMSC provider and let them now that their
desination-ton for the shortcode is not right, they should send the appropriate
TON value for network internal numbers (shortcode).
Stipe
-------------------------------------------------------------------
Kölner Landstrasse 419
40589 Düsseldorf, NRW, Germany
tolj.org system architecture Kannel Software Foundation (KSF)
http://www.tolj.org/ http://www.kannel.org/
mailto:st_{at}_tolj.org mailto:stolj_{at}_kannel.org
-------------------------------------------------------------------
