>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..]
>>>
>>>

Reply via email to