At 09:23 AM 10/21/02 +0200, Andreas Fink wrote:
yup - this is smpp 3.4. Your dump shows an optional parameter tag 04 24 which is the msg_payload parameter.
We have a hack where I have added the following into smpp_pdu.def
OPT_INTEGER(id_1, 2)
OPT_INTEGER(len_1,2)
OPT_OCTETS(data_1, len_1)
OPT_INTEGER(id_2, 2)
OPT_INTEGER(len_2,2)
OPT_OCTETS(data_2, len_1)
OPT_INTEGER(id_3, 2)
OPT_INTEGER(len_3,2)
OPT_OCTETS(data_3, len_1)
Then in smpp_pdu_unpack we check for these. It wont allways work, it will depend on which other optional params are used by the SMSC. We almost need an array type in the def file to handle this properly.
With most SMSCs using ver 3.3 will solve this. We however have one that only talks 3.4
Nisan
There seems to be a problem in the SMPP module.
I have a connection to an SMSC which should deliver me incoming SMS but instead I always get messages with no content.
I've added an octstr dump to see the original SMPP PDU as raw data and found that the text is very well received but not correctly decoded apparently. The test message contained the word "TEST" Here's what I see:
The PDU dump in binary
2002-10-21 09:13:45 [6] DEBUG: SMPP PDU dump ends.
2002-10-21 09:14:04 [6] DEBUG: Octet string at 0x80d9038:
2002-10-21 09:14:04 [6] DEBUG: len: 53
2002-10-21 09:14:04 [6] DEBUG: size: 54
2002-10-21 09:14:04 [6] DEBUG: immutable: 0
2002-10-21 09:14:04 [6] DEBUG: data: 00 00 00 05 00 00 00 00 ........
2002-10-21 09:14:04 [6] DEBUG: data: 00 00 00 01 00 01 01 39 .......9
2002-10-21 09:14:04 [6] DEBUG: data: 37 31 35 30 34 39 32 30 71504920
2002-10-21 09:14:04 [6] DEBUG: data: 39 35 38 00 03 09 39 37 958...97
2002-10-21 09:14:04 [6] DEBUG: data: 38 33 00 00 00 00 00 00 83......
2002-10-21 09:14:04 [6] DEBUG: data: 01 00 00 00 00 04 24 00 ......$.
2002-10-21 09:14:04 [6] DEBUG: data: 04 54 45 53 54 .TEST
2002-10-21 09:14:04 [6] DEBUG: Octet string dump ends.
The PDU dump after decoding
2002-10-21 09:14:04 [6] DEBUG: SMPP[link5]: Got PDU:
2002-10-21 09:14:04 [6] DEBUG: SMPP PDU 0x80d9038 dump:
2002-10-21 09:14:04 [6] DEBUG: type_name: deliver_sm
2002-10-21 09:14:04 [6] DEBUG: command_id: 5 = 0x00000005
2002-10-21 09:14:04 [6] DEBUG: command_status: 0 = 0x00000000
2002-10-21 09:14:04 [6] DEBUG: sequence_number: 1 = 0x00000001
2002-10-21 09:14:04 [6] DEBUG: service_type: NULL
2002-10-21 09:14:04 [6] DEBUG: source_addr_ton: 1 = 0x00000001
2002-10-21 09:14:04 [6] DEBUG: source_addr_npi: 1 = 0x00000001
2002-10-21 09:14:04 [6] DEBUG: source_addr: "971504920958"
2002-10-21 09:14:04 [6] DEBUG: dest_addr_ton: 3 = 0x00000003
2002-10-21 09:14:04 [6] DEBUG: dest_addr_npi: 9 = 0x00000009
2002-10-21 09:14:04 [6] DEBUG: destination_addr: "9783"
2002-10-21 09:14:04 [6] DEBUG: esm_class: 0 = 0x00000000
2002-10-21 09:14:04 [6] DEBUG: protocol_id: 0 = 0x00000000
2002-10-21 09:14:04 [6] DEBUG: priority_flag: 0 = 0x00000000
2002-10-21 09:14:04 [6] DEBUG: schedule_delivery_time: NULL
2002-10-21 09:14:04 [6] DEBUG: validity_period: NULL
2002-10-21 09:14:04 [6] DEBUG: registered_delivery: 1 = 0x00000001
2002-10-21 09:14:04 [6] DEBUG: replace_if_present_flag: 0 = 0x00000000
2002-10-21 09:14:04 [6] DEBUG: data_coding: 0 = 0x00000000
2002-10-21 09:14:04 [6] DEBUG: sm_default_msg_id: 0 = 0x00000000
2002-10-21 09:14:04 [6] DEBUG: sm_length: 0 = 0x00000000
2002-10-21 09:14:04 [6] DEBUG: short_message: ""
2002-10-21 09:14:04 [6] DEBUG: SMPP PDU dump ends.
2002-10-21 09:14:04 [6] DEBUG: SMPP[link5]: Sending PDU:
Anyone have seen this before?
Andreas Fink
Global Networks, Inc.
------------------------------------------------------------------
Tel: +41-61-6932730 Fax: +41-61-6932729 Mobile: +41-79-2457333
Global Networks, Inc. Schwarzwaldallee 16, 4058 Basel, Switzerland
Web: http://www.global-networks.ch/ [EMAIL PROTECTED]
------------------------------------------------------------------
Member of the GSM Association
</blockquote></x-html>
