Re: smpp data_coding seems not correct

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!