Section 5.2.19 of the SMPP v3.4 shows the data_coding parameter as: 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 So 0x05 is 0 0 0 0 0 1 0 1 -> JIS (X 0208-1990) b and 0xF5 is on of: 1 1 1 1 x x x x GSM message class control - see [GSM 03.38] e BTW, you're trying this on a GSM network, or is it CDMA or TDMA? Are you sure that the carrier supports wap-push at all? Not all carriers do, you should check with them just to be sure. Regards, Alejandro On Sat, Sep 27, 2008 at 8:42 AM, Alex Arias <[EMAIL PROTECTED]> wrote: > Hi Alejandro, > > Having found the meaning of the DCS (data coding scheme) here > http://ozekisms.com/index.php?ow_page_number=251 I believe the needed > configuration should be: > > DCS = 0xf5 > > -Compressed text > -message class = 1 (to mobile) > -8 bit data enconding > > If I add to your funcion the kannel parameter mclass = 1 it sends the DCS > = 0xf5 !! as you see in the log below. *H**owever that did not solved the > problem*, so now I'm running out out ideas. > > I tried to do the same with PPG setting the header X-Kannel-MClass = 1 but > the message is never delivered. Not even logged in the sms log. The message > is accepted by the PPG, the wap log says the message has been deliveried to > bearerbox but then and after there is no trace. > > I also found that the flags of the log of that message woth DCS = 0xf5 are > set like this: > > [flags:1:1:-1:*-1*:-1] > where > [flags:%m:%c:%M:%C:%d] > and charset %C is not set to 1 (binary) This might be the problem > > I'll keep you posted if I get something! > > 2008-09-25 14:06:56 [2802] [19] DEBUG: boxc_receiver: sms received > 2008-09-25 14:06:56 [2802] [19] DEBUG: send_msg: sending msg to boxc: > <ecomm> > 2008-09-25 14:06:56 [2802] [6] DEBUG: SMPP[smsc_1]: Sending PDU: > 2008-09-25 14:06:56 [2802] [6] DEBUG: SMPP PDU 0x2aaaac002770 dump: > 2008-09-25 14:06:56 [2802] [6] DEBUG: type_name: submit_sm > 2008-09-25 14:06:56 [2802] [6] DEBUG: command_id: 4 = 0x00000004 > 2008-09-25 14:06:56 [2802] [6] DEBUG: command_status: 0 = 0x00000000 > 2008-09-25 14:06:56 [2802] [6] DEBUG: sequence_number: 7047 = 0x00001b87 > 2008-09-25 14:06:56 [2802] [6] DEBUG: service_type: NULL > 2008-09-25 14:06:56 [2802] [6] DEBUG: source_addr_ton: 2 = 0x00000002 > 2008-09-25 14:06:56 [2802] [6] DEBUG: source_addr_npi: 1 = 0x00000001 > 2008-09-25 14:06:56 [2802] [6] DEBUG: source_addr: "[protected]" > 2008-09-25 14:06:56 [2802] [6] DEBUG: dest_addr_ton: 2 = 0x00000002 > 2008-09-25 14:06:56 [2802] [6] DEBUG: dest_addr_npi: 1 = 0x00000001 > 2008-09-25 14:06:56 [2802] [6] DEBUG: destination_addr: "[protected]" > 2008-09-25 14:06:56 [2802] [6] DEBUG: esm_class: 64 = 0x00000040 > 2008-09-25 14:06:56 [2802] [6] DEBUG: protocol_id: 0 = 0x00000000 > 2008-09-25 14:06:56 [2802] [6] DEBUG: priority_flag: 0 = 0x00000000 > 2008-09-25 14:06:56 [2802] [6] DEBUG: schedule_delivery_time: NULL > 2008-09-25 14:06:56 [2802] [6] DEBUG: validity_period: NULL > 2008-09-25 14:06:56 [2802] [6] DEBUG: registered_delivery: 0 = 0x00000000 > 2008-09-25 14:06:56 [2802] [6] DEBUG: replace_if_present_flag: 0 = > 0x00000000 > *2008-09-25 14:06:56 [2802] [6] DEBUG: data_coding: 245 = 0x000000f5* > 2008-09-25 14:06:56 [2802] [6] DEBUG: sm_default_msg_id: 0 = 0x00000000 > 2008-09-25 14:06:56 [2802] [6] DEBUG: sm_length: 50 = 0x00000032 > 2008-09-25 14:06:56 [2802] [6] DEBUG: short_message: > 2008-09-25 14:06:56 [2802] [6] DEBUG: Octet string at 0x2aaaac002130: > 2008-09-25 14:06:56 [2802] [6] DEBUG: len: 50 > 2008-09-25 14:06:56 [2802] [6] DEBUG: size: 1024 > 2008-09-25 14:06:56 [2802] [6] DEBUG: immutable: 0 > 2008-09-25 14:06:56 [2802] [6] DEBUG: data: 06 05 04 0b 84 23 f0 1b 06 > 01 ae 02 05 6a 00 45 .....#.......j.E > 2008-09-25 14:06:56 [2802] [6] DEBUG: data: c6 0c 03 68 74 74 70 3a 2f > 2f 77 77 77 2e 67 6f ...http://www.go > 2008-09-25 14:06:56 [2802] [6] DEBUG: data: 6f 67 6c 65 2e 63 6f 6d 00 > 01 03 74 65 73 74 00 ogle.com...test. > 2008-09-25 14:06:56 [2802] [6] DEBUG: data: 01 > 01 .. > 2008-09-25 14:06:56 [2802] [6] DEBUG: Octet string dump ends. > 2008-09-25 14:06:56 [2802] [6] DEBUG: SMPP PDU dump ends. > > > *From:* Alejandro Guerrieri <[EMAIL PROTECTED]> > *Sent:* Friday, September 26, 2008 1:19 AM > *To:* Alex Arias <[EMAIL PROTECTED]> > *Cc:* users@kannel.org ; [EMAIL PROTECTED] ; [EMAIL PROTECTED] > *Subject:* Re: wap push received as garbage > > Hmm, you could try using the alt-dcs, coding and other available parameter > to set the data-coding (check the userguide for the details). > > I'm checking the SMPP Specs, and thos data coding values are: > > 0x05 -> "JIS (X 0208-1990)" > > 0xF5 -> "Extended Kanji JIS (X 0212-1990)" > > Checking on Kannel's source code, Kannel doesn't even know how to handle > 0x05, are you sure about that? > > Regards, > > Alejandro > > On Thu, Sep 25, 2008 at 4:26 PM, Alex Arias <[EMAIL PROTECTED]> wrote: > >> Hi Alejandro, >> >> I see that I have exactly the same problem as Christian Vandrei in this >> post http://www.mail-archive.com/users@kannel.org/msg08136.html and the >> same problem as Joaquin Vera in this post >> http://www.mail-archive.com/users@kannel.org/msg10058.html >> >> So both believe that the problem is the data_coding parameter that should >> be set to something different than 0x04. It should be 0xf5 or 0x05 >> >> Christian, Joaquin were you able to solve this already? >> >> Thanks >> >> Alex >> >> >> *From:* Alex Arias <[EMAIL PROTECTED]> >> *Sent:* Thursday, September 25, 2008 9:48 PM >> *To:* Alejandro Guerrieri <[EMAIL PROTECTED]> >> *Cc:* Aarno Syvänen <[EMAIL PROTECTED]> ; users@kannel.org >> *Subject:* Re: wap push received as garbage >> >> Hi Alejandro, >> >> Thank you for your reply. I already used your funcion (thanks BTW), but >> unfortunately I got the same results. Below is the log using your function. >> It produces basically the same parameters as sending through PPG. I believe >> is the case of an old case from Joaquin Vera with subject "Wap push as a >> text SMS". The problem seems to be in the parameter "data_coding" that >> currently is "0x04" but should be "0xf5". Do you know how to change that >> parameter in Kannel? >> >> >> 2008-09-24 11:18:04 [2802] [19] DEBUG: boxc_receiver: sms received >> 2008-09-24 11:18:04 [2802] [19] DEBUG: send_msg: sending msg to boxc: >> <ecomm> >> 2008-09-24 11:18:04 [2802] [6] DEBUG: SMPP[smsc_1]: Sending PDU: >> 2008-09-24 11:18:04 [2802] [6] DEBUG: SMPP PDU 0x2aaaac000d40 dump: >> 2008-09-24 11:18:04 [2802] [6] DEBUG: type_name: submit_sm >> 2008-09-24 11:18:04 [2802] [6] DEBUG: command_id: 4 = 0x00000004 >> 2008-09-24 11:18:04 [2802] [6] DEBUG: command_status: 0 = 0x00000000 >> 2008-09-24 11:18:04 [2802] [6] DEBUG: sequence_number: 1228 = 0x000004cc >> 2008-09-24 11:18:04 [2802] [6] DEBUG: service_type: NULL >> 2008-09-24 11:18:04 [2802] [6] DEBUG: source_addr_ton: 2 = 0x00000002 >> 2008-09-24 11:18:04 [2802] [6] DEBUG: source_addr_npi: 1 = 0x00000001 >> 2008-09-24 11:18:04 [2802] [6] DEBUG: source_addr: "34488" >> 2008-09-24 11:18:04 [2802] [6] DEBUG: dest_addr_ton: 2 = 0x00000002 >> 2008-09-24 11:18:04 [2802] [6] DEBUG: dest_addr_npi: 1 = 0x00000001 >> 2008-09-24 11:18:04 [2802] [6] DEBUG: destination_addr: "[protected]" >> 2008-09-24 11:18:04 [2802] [6] DEBUG: esm_class: 64 = 0x00000040 >> 2008-09-24 11:18:04 [2802] [6] DEBUG: protocol_id: 0 = 0x00000000 >> 2008-09-24 11:18:04 [2802] [6] DEBUG: priority_flag: 0 = 0x00000000 >> 2008-09-24 11:18:04 [2802] [6] DEBUG: schedule_delivery_time: NULL >> 2008-09-24 11:18:04 [2802] [6] DEBUG: validity_period: NULL >> 2008-09-24 11:18:04 [2802] [6] DEBUG: registered_delivery: 0 = >> 0x00000000 >> 2008-09-24 11:18:04 [2802] [6] DEBUG: replace_if_present_flag: 0 = >> 0x00000000 >> 2008-09-24 11:18:04 [2802] [6] DEBUG: data_coding: 4 = 0x00000004 >> 2008-09-24 11:18:04 [2802] [6] DEBUG: sm_default_msg_id: 0 = 0x00000000 >> 2008-09-24 11:18:04 [2802] [6] DEBUG: sm_length: 50 = 0x00000032 >> 2008-09-24 11:18:04 [2802] [6] DEBUG: short_message: >> 2008-09-24 11:18:04 [2802] [6] DEBUG: Octet string at 0x2aaaac000f40: >> 2008-09-24 11:18:04 [2802] [6] DEBUG: len: 50 >> 2008-09-24 11:18:04 [2802] [6] DEBUG: size: 1024 >> 2008-09-24 11:18:04 [2802] [6] DEBUG: immutable: 0 >> 2008-09-24 11:18:04 [2802] [6] DEBUG: data: 06 05 04 0b 84 23 f0 1b >> 06 01 ae 02 05 6a 00 45 .....#.......j.E >> 2008-09-24 11:18:04 [2802] [6] DEBUG: data: c6 0c 03 68 74 74 70 3a >> 2f 2f 77 77 77 2e 67 6f ...http://www.go >> 2008-09-24 11:18:04 [2802] [6] DEBUG: data: 6f 67 6c 65 2e 63 6f 6d >> 00 01 03 74 65 73 74 00 ogle.com...test. >> 2008-09-24 11:18:04 [2802] [6] DEBUG: data: 01 >> 01 .. >> 2008-09-24 11:18:04 [2802] [6] DEBUG: Octet string dump ends. >> 2008-09-24 11:18:04 [2802] [6] DEBUG: SMPP PDU dump ends. >> 2008-09-24 11:18:04 [2802] [6] DEBUG: SMPP[smsc_1]: Got PDU: >> 2008-09-24 11:18:04 [2802] [6] DEBUG: SMPP PDU 0x2aaaac000d40 dump: >> 2008-09-24 11:18:04 [2802] [6] DEBUG: type_name: submit_sm_resp >> 2008-09-24 11:18:04 [2802] [6] DEBUG: command_id: 2147483652 = >> 0x80000004 >> 2008-09-24 11:18:04 [2802] [6] DEBUG: command_status: 0 = 0x00000000 >> 2008-09-24 11:18:04 [2802] [6] DEBUG: sequence_number: 1228 = 0x000004cc >> 2008-09-24 11:18:04 [2802] [6] DEBUG: message_id: "370c07a" >> 2008-09-24 11:18:04 [2802] [6] DEBUG: SMPP PDU dump ends. >> >> >> *From:* Alejandro Guerrieri <[EMAIL PROTECTED]> >> *Sent:* Thursday, September 25, 2008 8:33 PM >> *To:* Alex Arias <[EMAIL PROTECTED]> >> *Cc:* Aarno Syvänen <[EMAIL PROTECTED]> ; users@kannel.org >> *Subject:* Re: wap push received as garbage >> >> Alex, >> >> Wap push is a binary-coded message. What PPG does is to transform your >> request into a binary message, so there's nothing unusual about it. >> >> Some carriers does not support sending binary messages on their networks, >> so maybe the problem is not with your request but with the network. I don't >> know if that's the case, but if you can test the same message over a >> different link maybe you can discard this. >> >> I've made a small php function that encodes the binary message without >> using the PPG at all. You can try it if you want, if this also renders >> garbled text you can be almost certain that there's a problem with the >> network. >> >> Check here: >> >> http://www.mail-archive.com/users@kannel.org/msg03255.html >> >> Hope it helps, >> >> Alejandro Guerrieri >> >> On Thu, Sep 25, 2008 at 1:40 PM, Alex Arias <[EMAIL PROTECTED]> wrote: >> >>> Hi Aarno, >>> >>> Thank you very much for your reply. I tried to send a wap push (binary). >>> The process is as follows: >>> >>> >>> 1. Wap push sent to Kannel PPG using PAP format >>> 2. Kannel encode the PAP request and send it to the operator via SMPP >>> 3. Operator acknowledges the mesage and deliver it to the phone >>> 4. The phone get weird characters instead of the functional wap push >>> >>> I took the resultant binary message from the smsbox log and posted here >>> >>> Any idea? I believe the problem is in the parameters sent in the SMPP >>> protocol. For example I had to patch Kannel and change the value of >>> esm_class to 0 as the operator rejected the sms. This might be something >>> similar. How do I tell the operator, in the SMPP protocol, that the message >>> is a wap push? What parameters are involved and what should be the right >>> value? >>> >>> Thank you >>> Alex >>> >>> >>> >>> >>> >>> >>> *From:* Aarno Syvänen <[EMAIL PROTECTED]> >>> *Sent:* Thursday, September 25, 2008 10:16 AM >>> *To:* Alex Arias <[EMAIL PROTECTED]> >>> *Cc:* users@kannel.org >>> *Subject:* Re: wap push received as garbage >>> >>> >>> Hi, >>> >>> did you try to send a binary message, or text ? >>> >>> Aarno >>> >>> On 24 Sep 2008, at 17:53, Alex Arias wrote: >>> >>> Hi everybody, >>> >>> I'm trying to send a wap push to an operator via PAP->PPG->SMPP and they >>> get garbage instead of a functional wap push. I'm using Kannel as PPG. The >>> message is accepted OK by Kannel and delivered OK to operator, but they >>> don't get the right message. >>> >>> Thank you so much for your help! Below are the details >>> >>> >>> PAP MESSAGE-------------------------------- >>> >>> --multipart-boundary >>> Content-Type: application/xml >>> >>> <?xml version="1.0"?> >>> <!DOCTYPE pap PUBLIC "-//WAPFORUM//DTD PAP 1.0//EN" >>> "http://www.wapforum.org/DTD/pap_1.0.dtd"; > >>> <pap> >>> <push-message push-id="[EMAIL PROTECTED]" >>> deliver-before-timestamp="2009-11-01T06:45:00Z" >>> deliver-after-timestamp="2007-02-27T06:45:00Z" >>> progress-notes-requested="false"> >>> <address address-value="WAPPUSH=[protected]/[EMAIL >>> PROTECTED]"/<protected/[EMAIL PROTECTED]/> >>> > >>> </push-message> >>> </pap> >>> >>> --multipart-boundary >>> Content-Type: text/vnd.wap.si >>> >>> <?xml version="1.0"?> >>> <!DOCTYPE si PUBLIC "-//WAPFORUM//DTD SI 1.0//EN" >>> "http://www.wapforum.org/DTD/si.dtd";> >>> <si> >>> <indication action="signal-high" created="1999-06-25T15:23:15Z" >>> si-expires="2009-06-25T15:23:15Z" si-id="[EMAIL PROTECTED]" href=" >>> http://www.google.com";>Test</indication<http://www.google.com%22%3ETest%3C/indication> >>> > >>> </si> >>> --multipart-boundary-- >>> >>> BINARY MESSAGE-------------------------------- >>> binary message: >>> 010605AE8DBDC39302056A0045C6080AC3071999062515231510C30720090625152315110335406463682E636F6D000D03676F6F676C652E636F6D00010354657374000101 >>> UDH:0605040B8423F0 >>> >>> CORE LOG (debug)-------------------------------- >>> >>> 2008-09-24 08:27:47 [2802] [17] DEBUG: boxc_receiver: got sms from wapbox >>> >>> 2008-09-24 08:27:47 [2802] [17] DEBUG: send_msg: sending msg to box: < >>> 127.0.0.1> >>> >>> 2008-09-24 08:27:47 [2802] [6] DEBUG: SMPP[smsc_1]: Sending PDU: >>> >>> 2008-09-24 08:27:47 [2802] [6] DEBUG: SMPP PDU 0x1b117f50 dump: >>> >>> 2008-09-24 08:27:47 [2802] [6] DEBUG: type_name: submit_sm >>> >>> 2008-09-24 08:27:47 [2802] [6] DEBUG: command_id: 4 = 0x00000004 >>> >>> 2008-09-24 08:27:47 [2802] [6] DEBUG: command_status: 0 = 0x00000000 >>> >>> 2008-09-24 08:27:47 [2802] [6] DEBUG: sequence_number: 546 = 0x00000222 >>> >>> 2008-09-24 08:27:47 [2802] [6] DEBUG: service_type: NULL >>> >>> 2008-09-24 08:27:47 [2802] [6] DEBUG: source_addr_ton: 2 = 0x00000002 >>> >>> 2008-09-24 08:27:47 [2802] [6] DEBUG: source_addr_npi: 1 = 0x00000001 >>> >>> 2008-09-24 08:27:47 [2802] [6] DEBUG: source_addr: "[protected]" >>> >>> 2008-09-24 08:27:47 [2802] [6] DEBUG: dest_addr_ton: 2 = 0x00000002 >>> >>> 2008-09-24 08:27:47 [2802] [6] DEBUG: dest_addr_npi: 1 = 0x00000001 >>> >>> 2008-09-24 08:27:47 [2802] [6] DEBUG: destination_addr: "[protected]" >>> >>> 2008-09-24 08:27:47 [2802] [6] DEBUG: esm_class: 64 = 0x00000040 >>> >>> 2008-09-24 08:27:47 [2802] [6] DEBUG: protocol_id: 0 = 0x00000000 >>> >>> 2008-09-24 08:27:47 [2802] [6] DEBUG: priority_flag: 0 = 0x00000000 >>> >>> 2008-09-24 08:27:47 [2802] [6] DEBUG: schedule_delivery_time: NULL >>> >>> 2008-09-24 08:27:47 [2802] [6] DEBUG: validity_period: "080925152747000+" >>> >>> 2008-09-24 08:27:47 [2802] [6] DEBUG: registered_delivery: 0 = 0x00000000 >>> >>> 2008-09-24 08:27:47 [2802] [6] DEBUG: replace_if_present_flag: 0 = >>> 0x00000000 >>> >>> 2008-09-24 08:27:47 [2802] [6] DEBUG: data_coding: 4 = 0x00000004 >>> >>> 2008-09-24 08:27:47 [2802] [6] DEBUG: sm_default_msg_id: 0 = 0x00000000 >>> >>> 2008-09-24 08:27:47 [2802] [6] DEBUG: sm_length: 76 = 0x0000004c >>> >>> 2008-09-24 08:27:47 [2802] [6] DEBUG: short_message: >>> >>> 2008-09-24 08:27:47 [2802] [6] DEBUG: Octet string at 0x2aaaac000dc0: >>> >>> 2008-09-24 08:27:47 [2802] [6] DEBUG: len: 76 >>> >>> 2008-09-24 08:27:47 [2802] [6] DEBUG: size: 1024 >>> >>> 2008-09-24 08:27:47 [2802] [6] DEBUG: immutable: 0 >>> >>> 2008-09-24 08:27:47 [2802] [6] DEBUG: data: 06 05 04 0b 84 23 f0 01 06 05 >>> ae 8d bd c3 93 02 .....#.......... >>> >>> 2008-09-24 08:27:47 [2802] [6] DEBUG: data: 05 6a 00 45 c6 08 0a c3 07 19 >>> 99 06 25 15 23 15 .j.E........%.#. >>> >>> 2008-09-24 08:27:47 [2802] [6] DEBUG: data: 10 c3 07 20 09 06 25 15 23 15 >>> 11 03 35 40 64 63 ... [EMAIL PROTECTED] >>> >>> 2008-09-24 08:27:47 [2802] [6] DEBUG: data: 68 2e 63 6f 6d 00 0d 03 67 6f >>> 6f 67 6c 65 2e 63 h.com...google.c >>> >>> 2008-09-24 08:27:47 [2802] [6] DEBUG: data: 6f 6d 00 01 03 54 65 73 74 00 >>> 01 01 om...Test... >>> >>> 2008-09-24 08:27:47 [2802] [6] DEBUG: Octet string dump ends. >>> >>> 2008-09-24 08:27:47 [2802] [6] DEBUG: SMPP PDU dump ends. >>> >>> 2008-09-24 08:27:47 [2802] [6] DEBUG: SMPP[smsc_1]: Got PDU: >>> >>> 2008-09-24 08:27:47 [2802] [6] DEBUG: SMPP PDU 0x2aaaac000d40 dump: >>> >>> 2008-09-24 08:27:47 [2802] [6] DEBUG: type_name: submit_sm_resp >>> >>> 2008-09-24 08:27:47 [2802] [6] DEBUG: command_id: 2147483652 = 0x80000004 >>> >>> 2008-09-24 08:27:47 [2802] [6] DEBUG: command_status: 0 = 0x00000000 >>> >>> 2008-09-24 08:27:47 [2802] [6] DEBUG: sequence_number: 546 = 0x00000222 >>> >>> 2008-09-24 08:27:47 [2802] [6] DEBUG: message_id: "6fa7a87a" >>> >>> 2008-09-24 08:27:47 [2802] [6] DEBUG: SMPP PDU dump ends. >>> >>> >>> >>> >>> >> >
