Re: SMPP SMS-MO broken

Nisan Bloch <[email protected]>
Newsgroups gmane.comp.mobile.kannel.devel
Message-ID <[email protected]>
Hi
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/ >http://www.global-networks.ch/ 
>[email protected]
>------------------------------------------------------------------
>Member of the GSM Association
></blockquote></x-html>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.