Hi, first of all: please start new thread when it's not a answer to the previous one!
which version of kannel are you using? I remember to fix this issue in cvs, so if you don't use cvs version, then try it first... Thanks! zhu shi song wrote: > I use http client to send sms to kannel. coding =2 , mclass=1. Kannel > compose the PDU as following: 2004-07-06 17:52:38 [6228] [8] DEBUG: > SMPP[test168]: Sending PDU: 2004-07-06 17:52:38 [6228] [8] DEBUG: SMPP PDU > 0x8247220 dump: > 2004-07-06 17:52:38 [6228] [8] DEBUG: type_name: submit_sm > 2004-07-06 17:52:38 [6228] [8] DEBUG: command_id: 4 = 0x00000004 > 2004-07-06 17:52:38 [6228] [8] DEBUG: command_status: 0 = 0x00000000 > 2004-07-06 17:52:38 [6228] [8] DEBUG: sequence_number: 63 = 0x0000003f > 2004-07-06 17:52:38 [6228] [8] DEBUG: service_type: NULL > 2004-07-06 17:52:38 [6228] [8] DEBUG: source_addr_ton: 2 = 0x00000002 > 2004-07-06 17:52:38 [6228] [8] DEBUG: source_addr_npi: 1 = 0x00000001 > 2004-07-06 17:52:38 [6228] [8] DEBUG: source_addr: "13013" > 2004-07-06 17:52:38 [6228] [8] DEBUG: dest_addr_ton: 2 = 0x00000002 > 2004-07-06 17:52:38 [6228] [8] DEBUG: dest_addr_npi: 1 = 0x00000001 > 2004-07-06 17:52:38 [6228] [8] DEBUG: destination_addr: "3748" > 2004-07-06 17:52:38 [6228] [8] DEBUG: esm_class: 3 = 0x00000003 > 2004-07-06 17:52:38 [6228] [8] DEBUG: protocol_id: 0 = 0x00000000 > 2004-07-06 17:52:38 [6228] [8] DEBUG: priority_flag: 0 = 0x00000000 > 2004-07-06 17:52:38 [6228] [8] DEBUG: schedule_delivery_time: NULL > 2004-07-06 17:52:38 [6228] [8] DEBUG: validity_period: NULL > 2004-07-06 17:52:38 [6228] [8] DEBUG: registered_delivery: 0 = 0x00000000 > 2004-07-06 17:52:38 [6228] [8] DEBUG: replace_if_present_flag: 0 = > 0x00000000 > 2004-07-06 17:52:38 [6228] [8] DEBUG: data_coding: 25 = 0x00000019 > 2004-07-06 17:52:38 [6228] [8] DEBUG: sm_default_msg_id: 0 = 0x00000000 > 2004-07-06 17:52:38 [6228] [8] DEBUG: sm_length: 12 = 0x0000000c > 2004-07-06 17:52:38 [6228] [8] DEBUG: short_message: > 2004-07-06 17:52:38 [6228] [8] DEBUG: Octet string at 0x8245818: > 2004-07-06 17:52:38 [6228] [8] DEBUG: len: 12 > 2004-07-06 17:52:38 [6228] [8] DEBUG: size: 13 > 2004-07-06 17:52:38 [6228] [8] DEBUG: immutable: 0 > 2004-07-06 17:52:38 [6228] [8] DEBUG: data: 00 64 00 6a 00 6b 00 69 > 00 66 00 64 .d.j.k.i.f.d > 2004-07-06 17:52:38 [6228] [8] DEBUG: Octet string dump ends. > 2004-07-06 17:52:38 [6228] [8] DEBUG: SMPP PDU dump ends. > 2004-07-06 17:52:38 [6228] [8] WARNING: SMPP: PDU NUL terminated string > has no NUL. > > I notice that the data_coding of PDU is 0x19. The value is encoded > according to GSM03.38. It doesn't conform to SMPP standard. Accroding > to SMPP, 7-4bit of data_coding can't be 0001. please read the description > of data_coding in SMPP v3_4. I don't understand the point. Please help > me. > > 5.2.19 data_coding > Bits 7 6 5 4 3 2 1 0 Meaning Notes > 0 0 0 0 0 0 0 0 SMSC Default Alphabet > 0 0 0 0 0 0 0 1 IA5 (CCITT T.50)/ASCII (ANSI X3.4) b > 0 0 0 0 0 0 1 0 Octet unspecified (8-bit binary) b > 0 0 0 0 0 0 1 1 Latin 1 (ISO-8859-1) b > 0 0 0 0 0 1 0 0 Octet unspecified (8-bit binary) a > 0 0 0 0 0 1 0 1 JIS (X 0208-1990) b > 0 0 0 0 0 1 1 0 Cyrllic (ISO-8859-5) b > 0 0 0 0 0 1 1 1 Latin/Hebrew (ISO-8859-8) b > 0 0 0 0 1 0 0 0 UCS2 (ISO/IEC-10646) a > 0 0 0 0 1 0 0 1 Pictogram Encoding b > 0 0 0 0 1 0 1 0 ISO-2022-JP (Music Codes) b > 0 0 0 0 1 0 1 1 reserved > 0 0 0 0 1 1 0 0 reserved > 0 0 0 0 1 1 0 1 Extended Kanji JIS(X 0212-1990) b > 0 0 0 0 1 1 1 0 KS C 5601 b > 0 0 0 0 1 1 1 1 reserved > : > 1 0 1 1 1 1 1 1 reserved > 1 1 0 0 x x x x GSM MWI control - see [GSM 03.38] d > 1 1 0 1 x x x x GSM MWI control - see [GSM 03.38] d > 1 1 1 0 x x x x reserved > 1 1 1 1 x x x x GSM message class control - see [GSM 03.38] e > Notes: > a. These coding schemes are common to GSM, TDMA and CDMA. The SMPP > protocol allows ESME applications to use the same DCS value (i.e. the GSM > 03.38 value) for all three technologies. > b. In cases where a Data Coding Scheme is defined for TDMA and/ or CDMA > but not defined for GSM, SMPP uses GSM 03.38 reserved values. > c. There is no default setting for the data_coding parameter. > d. The data_coding parameter will evolve to specify Character code > settings only. Thus the recommended way to specify GSM MWI control is by > specifying the relevant settings in the optional parameters > _ms_msg_wait_facilities and ms_validity. e. The data_coding parameter will > evolve to specify Character code settings only. Thus the recommended way > to specify GSM message class control is by specifying the relevant setting > in the optional parameter dest_addr_subunit. > > > > --------------------------------- > Do you Yahoo!? > Yahoo! Mail - 50x more storage than other providers!
