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/[email protected]/msg08136.html and the > same problem as Joaquin Vera in this post > http://www.mail-archive.com/[email protected]/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]> ; [email protected] > *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]> ; [email protected] > *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/[email protected]/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:* [email protected] >> *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. >> >> >> >> >> >
