Thank you for the info.. Interesting enough am not using php at this point. I am running the insert directly on MySQL and yet the msgdata is truncated on 0x00
--Sam 2010/1/25 Nikos Balkanas <[email protected]> > Hi, > > Well, as you can see this is not an SQLbox or kannel issue. Assuming that > you already converted your msgdata to binary, it seems to be an insert > problem from your php. My initial response was not to insult, but to jolt > your thinking. You spent time doing the hard thing (convert msgdata to 0x01) > instead of looking the most straightforward, i.e. verify the data in the > database. > > BR, > Nikos > > ----- Original Message ----- > *From:* Sam <[email protected]> > *To:* Nikos Balkanas <[email protected]> ; Alejandro > Guerrieri<[email protected]> > *Cc:* [email protected] > *Sent:* Monday, January 25, 2010 1:22 AM > *Subject:* Re: sqlbox and wap push > > >From the DB. > > > ############# > `momt`, `sender`, `receiver`, `udhdata` , `msgdata`, .... > 'MT', 'coyName', '0000000000000', 0x0605040b8423f0, 0x1b0601ae02056a, > .... > ############# > > > > 2010/1/25 Nikos Balkanas <[email protected]> > >> Wap push is sent as binary sms. Wouldn't hurt to try. Provide a select >> from the DB to verify that you have inserted the correct msgtext. The INSERT >> statement you have provided is not a log, therefore no verification that >> what you think was actually sent. Not really necessary to resend bb logs. >> >> ----- Original Message ----- >> *From:* Sam <[email protected]> >> *To:* Nikos Balkanas <[email protected]> ; Alejandro >> Guerrieri<[email protected]> >> *Cc:* [email protected] >> *Sent:* Monday, January 25, 2010 12:45 AM >> *Subject:* Re: sqlbox and wap push >> >> Hi, >> >> Am sending a wap push. >> >> Without even specifying coding=2 & charset=utf in the send-url, all WORK >> FINE. So i don think this is the problem. >> >> The problem is when i try to use SQLBOX for the same message. One thing >> that i noticed is that when i insert into the DB, the message data get >> truncated on 0x00 as you would also see in the log. I guess this is where >> the problem is and i will be grateful if you can help provide information on >> how to resolve this. >> >> Thank you. >> >> >> 2010/1/24 Nikos Balkanas <[email protected]> >> >>> Hi, >>> >>> Well, I am sure you understand that no one enjoys long mails each day on >>> weekends in their box. >>> >>> When sending binary SMS, you have to specify coding=2 & charset=utf in >>> your send-url. I assume your text is UTF. >>> >>> BR, >>> Nikos >>> >>> ----- Original Message ----- >>> *From:* Sam <[email protected]> >>> *To:* Nikos Balkanas <[email protected]> ; Alejandro >>> Guerrieri<[email protected]> >>> *Cc:* [email protected] >>> *Sent:* Monday, January 25, 2010 12:20 AM >>> *Subject:* Re: sqlbox and wap push >>> >>> Hi, >>> >>> Come on Nikos, I appreciate your effort to offer assistance but you >>> really do not have to insult. Kind words are sufficient and professional ! >>> >>> Anyways, I have changed the field to binary as advised by Alex. Plus i am >>> sure the issue if not from PHP. I am using direct copy of the URL into the >>> browser (works fine) and also direct INSERT in to the DB. See the logs >>> below. >>> >>> One thing that i noticed however is that when i insert into the DB, the >>> message data get truncated on 0x00 as you would also see in the log. I guess >>> this is where the problem is and i will be grateful if you can help provide >>> information on how to resolve this. >>> >>> Thank you. >>> >>> --Sam >>> >>> >>> ############################## SENDING OVER HTTP >>> ####################################################### >>> >>> >>> http://www.hostname.com:13290/cgi-bin/sendsms?user=kannel&pass=rL4y90&udh=%06%05%04%0B%84%23%F0&text=%1B%06%01%AE%02%05%6A%00%45%C6%0C%03%77%77%77%2E%63%6F%79%6E%61%6D%65%2E%63%6F%6D%2F%69%6D%61%67%65%2E%6A%70%67%00%01%03%57%61%70%00%01%01&dlr-mask=31&from=coyName&to=000000000000 >>> >>> 2010-01-24 22:47:49 [32012] [6] DEBUG: SMPP[nuSMSC]: Sending PDU: >>> 2010-01-24 22:47:49 [32012] [6] DEBUG: SMPP PDU 0xb0513a80 dump: >>> 2010-01-24 22:47:49 [32012] [6] DEBUG: type_name: submit_sm >>> 2010-01-24 22:47:49 [32012] [6] DEBUG: command_id: 4 = 0x00000004 >>> 2010-01-24 22:47:49 [32012] [6] DEBUG: command_status: 0 = 0x00000000 >>> 2010-01-24 22:47:49 [32012] [6] DEBUG: sequence_number: 45807 = >>> 0x0000b2ef >>> 2010-01-24 22:47:49 [32012] [6] DEBUG: service_type: NULL >>> 2010-01-24 22:47:49 [32012] [6] DEBUG: source_addr_ton: 5 = 0x00000005 >>> 2010-01-24 22:47:49 [32012] [6] DEBUG: source_addr_npi: 0 = 0x00000000 >>> 2010-01-24 22:47:49 [32012] [6] DEBUG: source_addr: "coyName" >>> 2010-01-24 22:47:49 [32012] [6] DEBUG: dest_addr_ton: 2 = 0x00000002 >>> 2010-01-24 22:47:49 [32012] [6] DEBUG: dest_addr_npi: 1 = 0x00000001 >>> 2010-01-24 22:47:49 [32012] [6] DEBUG: destination_addr: "000000000000" >>> 2010-01-24 22:47:49 [32012] [6] DEBUG: esm_class: 67 = 0x00000043 >>> 2010-01-24 22:47:49 [32012] [6] DEBUG: protocol_id: 0 = 0x00000000 >>> 2010-01-24 22:47:49 [32012] [6] DEBUG: priority_flag: 0 = 0x00000000 >>> 2010-01-24 22:47:49 [32012] [6] DEBUG: schedule_delivery_time: NULL >>> 2010-01-24 22:47:49 [32012] [6] DEBUG: validity_period: NULL >>> 2010-01-24 22:47:49 [32012] [6] DEBUG: registered_delivery: 1 = >>> 0x00000001 >>> 2010-01-24 22:47:49 [32012] [6] DEBUG: replace_if_present_flag: 0 = >>> 0x00000000 >>> 2010-01-24 22:47:49 [32012] [6] DEBUG: data_coding: 4 = 0x00000004 >>> 2010-01-24 22:47:49 [32012] [6] DEBUG: sm_default_msg_id: 0 = >>> 0x00000000 >>> 2010-01-24 22:47:49 [32012] [6] DEBUG: sm_length: 53 = 0x00000035 >>> 2010-01-24 22:47:49 [32012] [6] DEBUG: short_message: >>> 2010-01-24 22:47:49 [32012] [6] DEBUG: Octet string at 0xb0513a20: >>> 2010-01-24 22:47:49 [32012] [6] DEBUG: len: 53 >>> 2010-01-24 22:47:49 [32012] [6] DEBUG: size: 1024 >>> 2010-01-24 22:47:49 [32012] [6] DEBUG: immutable: 0 >>> 2010-01-24 22:47:49 [32012] [6] DEBUG: data: 06 05 04 0b 84 23 f0 1b >>> 06 01 ae 02 05 6a 00 45 .....#.......j.E >>> 2010-01-24 22:47:49 [32012] [6] DEBUG: data: c6 0c 03 77 77 77 2e 63 >>> 6f 79 6e 61 6d 65 2e 63 ...www.coyname.c >>> 2010-01-24 22:47:49 [32012] [6] DEBUG: data: 6f 6d 2f 69 6d 61 67 65 >>> 2e 6a 70 67 00 01 03 57 om/image.jpg...W >>> 2010-01-24 22:47:49 [32012] [6] DEBUG: data: 61 70 00 01 01 >>> ap... >>> 2010-01-24 22:47:49 [32012] [6] DEBUG: Octet string dump ends. >>> >>> >>> ############################## SENDING OVER >>> SQLBOX #################################################### >>> >>> INSERT INTO send_sms (`momt`, `sender`, `receiver`, `msgdata`, >>> `sms_type`, `dlr_mask`, `udhdata` ) >>> VALUES ('MT', 'coyName', '000000000000', CHAR (0x1B, 0x06, 0x01, 0xAE, >>> 0x02, 0x05, 0x6A, 0x00, 0x45, 0xC6, 0x0C, 0x03, 0x77, 0x77, 0x77, 0x2E, >>> 0x63, 0x6F, 0x79, 0x6E, 0x61, 0x6D, 0x65, 0x2E, 0x63, 0x6F, 0x6D, 0x2F, >>> 0x69, 0x6D, 0x61, 0x67, 0x65, 0x2E, 0x6A, 0x70, 0x67, 0x00, 0x01, 0x03, >>> 0x57, 0x61, 0x70, 0x00, 0x01, 0x01), 2, 31, CHAR(0x06, 0x05, 0x04, 0x0B, >>> 0x84, 0x23, 0xf0) ) >>> >>> >>> 2010-01-24 22:53:00 [32012] [6] DEBUG: SMPP[nuSMSC]: Sending PDU: >>> 2010-01-24 22:53:00 [32012] [6] DEBUG: SMPP PDU 0xb0513a80 dump: >>> 2010-01-24 22:53:00 [32012] [6] DEBUG: type_name: submit_sm >>> 2010-01-24 22:53:00 [32012] [6] DEBUG: command_id: 4 = 0x00000004 >>> 2010-01-24 22:53:00 [32012] [6] DEBUG: command_status: 0 = 0x00000000 >>> 2010-01-24 22:53:00 [32012] [6] DEBUG: sequence_number: 45818 = >>> 0x0000b2fa >>> 2010-01-24 22:53:00 [32012] [6] DEBUG: service_type: NULL >>> 2010-01-24 22:53:00 [32012] [6] DEBUG: source_addr_ton: 5 = 0x00000005 >>> 2010-01-24 22:53:00 [32012] [6] DEBUG: source_addr_npi: 0 = 0x00000000 >>> 2010-01-24 22:53:00 [32012] [6] DEBUG: source_addr: "coyName" >>> 2010-01-24 22:53:00 [32012] [6] DEBUG: dest_addr_ton: 2 = 0x00000002 >>> 2010-01-24 22:53:00 [32012] [6] DEBUG: dest_addr_npi: 1 = 0x00000001 >>> 2010-01-24 22:53:00 [32012] [6] DEBUG: destination_addr: "000000000000" >>> 2010-01-24 22:53:00 [32012] [6] DEBUG: esm_class: 67 = 0x00000043 >>> 2010-01-24 22:53:00 [32012] [6] DEBUG: protocol_id: 0 = 0x00000000 >>> 2010-01-24 22:53:00 [32012] [6] DEBUG: priority_flag: 0 = 0x00000000 >>> 2010-01-24 22:53:00 [32012] [6] DEBUG: schedule_delivery_time: NULL >>> 2010-01-24 22:53:00 [32012] [6] DEBUG: validity_period: NULL >>> 2010-01-24 22:53:00 [32012] [6] DEBUG: registered_delivery: 1 = >>> 0x00000001 >>> 2010-01-24 22:53:00 [32012] [6] DEBUG: replace_if_present_flag: 0 = >>> 0x00000000 >>> 2010-01-24 22:53:00 [32012] [6] DEBUG: data_coding: 4 = 0x00000004 >>> 2010-01-24 22:53:00 [32012] [6] DEBUG: sm_default_msg_id: 0 = >>> 0x00000000 >>> 2010-01-24 22:53:00 [32012] [6] DEBUG: sm_length: 14 = 0x0000000e >>> 2010-01-24 22:53:00 [32012] [6] DEBUG: short_message: >>> 2010-01-24 22:53:00 [32012] [6] DEBUG: Octet string at 0xb0513998: >>> 2010-01-24 22:53:00 [32012] [6] DEBUG: len: 14 >>> 2010-01-24 22:53:00 [32012] [6] DEBUG: size: 1024 >>> 2010-01-24 22:53:00 [32012] [6] DEBUG: immutable: 0 >>> 2010-01-24 22:53:00 [32012] [6] DEBUG: data: 06 05 04 0b 84 23 f0 1b >>> 06 01 ae 02 05 6a .....#.......j >>> 2010-01-24 22:53:00 [32012] [6] DEBUG: Octet string dump ends. >>> >>> >>> ########################################################################################################## >>> >>> >>> >>> 2010/1/24 Nikos Balkanas <[email protected]> >>> >>>> Hi, >>>> >>>> Actually you have not. Alex told you that 0x00 could be a problem 3 days >>>> ago. Sorry to say, but the only thing you have shown is inability to think >>>> for yourself. This will not affect your other SMS. Have you verified that >>>> the binary text is inserted OK in your (binary) DB? If not, you have a >>>> problem in your php. I trust you are not asking this group to solve your >>>> php >>>> issues. >>>> >>>> BR, >>>> Nikos >>>> >>>> [..snip..] >>>> >>>> >
