seems to be the reason for that :) thanks for your help. anyway, where can we found a well documented sqlbox integration ?
On 2/27/07, Alexander Malysh <[EMAIL PROTECTED]> wrote:
Then it seems your error... Please try insert deferred and validity as NULL not 0 into table for sqlbox. Fourat Zouari wrote: > Hi, > I dont really see where can i get that thing since am using sqlbox to > bypass smsbox (injecting directly into SQL Table). > How can we debug this ? > Thanks for your support > > On 2/27/07, Alexander Malysh <[EMAIL PROTECTED]> wrote: >> >> Hi, >> >> could you please provide URL with all cgi vars you used to send these >> messages. >> >> On Dienstag, 27. Februar 2007, Fourat Zouari wrote: >> > Hope this will help : >> > Using Kannel 1.4.1 and standalone sqlbox version on : >> > Linux tux2 2.6.18-3-686 #1 SMP Mon Dec 4 16:41:14 UTC 2006 i686 >> GNU/Linux >> > >> > Here's two MT message sending cases : >> > >> > ---------[ Case 1 ]----- Begin >> > Message received on cellphone : OK >> > Message ACK : OK >> > System Time : mardi 27 février 2007, 14:56:43 (UTC+0100) >> > SMPP LOG : >> > 2007-02-27 14:56:43 [6518] [12] DEBUG: SMPP PDU 0xabe00ae8 dump: >> > 2007-02-27 14:56:43 [6518] [12] DEBUG: type_name: submit_sm >> > 2007-02-27 14:56:43 [6518] [12] DEBUG: command_id: 4 = 0x00000004 >> > 2007-02-27 14:56:43 [6518] [12] DEBUG: command_status: 0 = 0x00000000 >> > 2007-02-27 14:56:43 [6518] [12] DEBUG: sequence_number: 16142 = >> > 0x00003f0e 2007-02-27 14:56:43 [6518] [12] DEBUG: service_type: NULL >> > 2007-02-27 14:56:43 [6518] [12] DEBUG: source_addr_ton: 2 = >> > 0x00000002 >> > 2007-02-27 14:56:43 [6518] [12] DEBUG: source_addr_npi: 1 = >> > 0x00000001 >> > 2007-02-27 14:56:43 [6518] [12] DEBUG: source_addr: "27200" >> > 2007-02-27 14:56:43 [6518] [12] DEBUG: dest_addr_ton: 1 = 0x00000001 >> > 2007-02-27 14:56:43 [6518] [12] DEBUG: dest_addr_npi: 1 = 0x00000001 >> > 2007-02-27 14:56:43 [6518] [12] DEBUG: destination_addr: "26276778" >> > 2007-02-27 14:56:43 [6518] [12] DEBUG: esm_class: 3 = 0x00000003 >> > 2007-02-27 14:56:43 [6518] [12] DEBUG: protocol_id: 0 = 0x00000000 >> > 2007-02-27 14:56:43 [6518] [12] DEBUG: priority_flag: 0 = 0x00000000 >> > 2007-02-27 14:56:43 [6518] [12] DEBUG: schedule_delivery_time: >> > "070227135643000+" >> > 2007-02-27 14:56:43 [6518] [12] DEBUG: validity_period: >> > "070227135643000+" 2007-02-27 14:56:43 [6518] [12] DEBUG: >> > registered_delivery: 1 = 0x00000001 2007-02-27 14:56:43 [6518] [12] >> DEBUG: >> > replace_if_present_flag: 0 = 0x00000000 >> > 2007-02-27 14:56:43 [6518] [12] DEBUG: data_coding: 0 = 0x00000000 >> > 2007-02-27 14:56:43 [6518] [12] DEBUG: sm_default_msg_id: 0 = >> 0x00000000 >> > 2007-02-27 14:56:43 [6518] [12] DEBUG: sm_length: 4 = 0x00000004 >> > 2007-02-27 14:56:43 [6518] [12] DEBUG: short_message: "test" >> > 2007-02-27 14:56:43 [6518] [12] DEBUG: SMPP PDU dump ends. >> > ---------[ Case 1 ]----- End >> > >> > ---------[ Case 2 ]----- Begin >> > Message received on cellphone : KO >> > Message ACK : OK >> > System Time : mardi 27 février 2007, 12:59:08 (UTC+0100) >> > SMPP LOG : >> > 2007-02-27 12:59:08 [6518] [12] DEBUG: SMPP PDU 0xabe00ae8 dump: >> > 2007-02-27 12:59:08 [6518] [12] DEBUG: type_name: submit_sm >> > 2007-02-27 12:59:08 [6518] [12] DEBUG: command_id: 4 = 0x00000004 >> > 2007-02-27 12:59:08 [6518] [12] DEBUG: command_status: 0 = 0x00000000 >> > 2007-02-27 12:59:08 [6518] [12] DEBUG: sequence_number: 16195 = >> > 0x00003f43 2007-02-27 12:59:08 [6518] [12] DEBUG: service_type: NULL >> > 2007-02-27 12:59:08 [6518] [12] DEBUG: source_addr_ton: 2 = >> > 0x00000002 >> > 2007-02-27 12:59:08 [6518] [12] DEBUG: source_addr_npi: 1 = >> > 0x00000001 >> > 2007-02-27 12:59:08 [6518] [12] DEBUG: source_addr: "27200" >> > 2007-02-27 12:59:08 [6518] [12] DEBUG: dest_addr_ton: 1 = 0x00000001 >> > 2007-02-27 12:59:08 [6518] [12] DEBUG: dest_addr_npi: 1 = 0x00000001 >> > 2007-02-27 12:59:08 [6518] [12] DEBUG: destination_addr: "26276778" >> > 2007-02-27 12:59:08 [6518] [12] DEBUG: esm_class: 3 = 0x00000003 >> > 2007-02-27 12:59:08 [6518] [12] DEBUG: protocol_id: 0 = 0x00000000 >> > 2007-02-27 12:59:08 [6518] [12] DEBUG: priority_flag: 0 = 0x00000000 >> > 2007-02-27 12:59:08 [6518] [12] DEBUG: schedule_delivery_time: >> > "070227115908000+" >> > 2007-02-27 12:59:08 [6518] [12] DEBUG: validity_period: >> > "070227115908000+" 2007-02-27 12:59:08 [6518] [12] DEBUG: >> > registered_delivery: 1 = 0x00000001 2007-02-27 12:59:08 [6518] [12] >> DEBUG: >> > replace_if_present_flag: 0 = 0x00000000 >> > 2007-02-27 12:59:08 [6518] [12] DEBUG: data_coding: 0 = 0x00000000 >> > 2007-02-27 12:59:08 [6518] [12] DEBUG: sm_default_msg_id: 0 = >> 0x00000000 >> > 2007-02-27 12:59:08 [6518] [12] DEBUG: sm_length: 4 = 0x00000004 >> > 2007-02-27 12:59:08 [6518] [12] DEBUG: short_message: "test" >> > 2007-02-27 12:59:08 [6518] [12] DEBUG: SMPP PDU dump ends. >> > ---------[ Case 2 ]----- End >> > >> > And here's the configuration settings for the SMSC handling these >> messages >> > : ---------[ SMSC Conf ]----- Begin >> > group = smsc >> > denied-smsc-id = SMPP-01-TB;SMPP-02-TB;SMPP-03-TB >> > smsc-id = SMPP-02-TF >> > smsc = smpp >> > interface-version = 34 >> > host = 122.27.24.61 >> > port = 2275 >> > receive-port = 2275 >> > smsc-username = "tikcom" >> > smsc-password = "tiki223" >> > system-type = "VMA" >> > address-range = "" >> > reroute-dlr = true >> > enquire-link-interval = 4 >> > throughput = 2 >> > validityperiod = 1440 >> > ---------[ SMSC Conf ]----- End >> > >> > I have the same problem, with and without that 'validityperiod' >> > >> > On 2/26/07, Alexander Malysh <[EMAIL PROTECTED]> wrote: >> > > Hi again, >> > > >> > > Fourat Zouari wrote: >> > > > Am in dicussion with the SMSC Gateway provider support, they say >> that >> > > > kannel is forcing the validityperiod depending on its system local >> > > > time, this is a snapshot of log when sending an SMS-MT : >> > > >> > > did you tried to send this output to SMSC guys? see bellow... >> > > >> > > > ---------------------------------- BEGIN >> > > > 2007-02-26 19:57:58 [24849] [12] DEBUG: SMPP PDU 0xb01053f0 dump: >> > > > 2007-02-26 19:57:58 [24849] [12] DEBUG: type_name: submit_sm >> > > > 2007-02-26 19:57:58 [24849] [12] DEBUG: command_id: 4 = >> > > > 0x00000004 >> > > > 2007-02-26 19:57:58 [24849] [12] DEBUG: command_status: 0 = >> > > > 0x00000000 2007-02-26 19:57:58 [24849] [12] DEBUG: >> sequence_number: >> > > > 914 = 0x00000392 >> > > > 2007-02-26 19:57:58 [24849] [12] DEBUG: service_type: NULL >> > > > 2007-02-26 19:57:58 [24849] [12] DEBUG: source_addr_ton: 2 = >> > > >> > > 0x00000002 >> > > >> > > > 2007-02-26 19:57:58 [24849] [12] DEBUG: source_addr_npi: 1 = >> > > >> > > 0x00000001 >> > > >> > > > 2007-02-26 19:57:58 [24849] [12] DEBUG: source_addr: "22700" >> > > > 2007-02-26 19:57:58 [24849] [12] DEBUG: dest_addr_ton: 1 = >> 0x00000001 >> > > > 2007-02-26 19:57:58 [24849] [12] DEBUG: dest_addr_npi: 1 = >> 0x00000001 >> > > > 2007-02-26 19:57:58 [24849] [12] DEBUG: destination_addr: >> "28582653" >> > > > 2007-02-26 19:57:58 [24849] [12] DEBUG: esm_class: 3 = 0x00000003 >> > > > 2007-02-26 19:57:58 [24849] [12] DEBUG: protocol_id: 0 = >> 0x00000000 >> > > > 2007-02-26 19:57:58 [24849] [12] DEBUG: priority_flag: 0 = >> 0x00000000 >> > > > 2007-02-26 19:57:58 [24849] [12] DEBUG: schedule_delivery_time: >> > > > "070226185758000+" >> > > > 2007-02-26 19:57:58 [24849] [12] DEBUG: validity_period: >> > > > "070226185758000+" >> > > >> > > This seems to be wrong what you set here. You set deferred and >> validity >> > > to the same value! that means in my opinion, don't even try to >> > > deliver this message! >> > > As to the validity_period format: validity_period is formated as UTC >> > > timestamp + timezone in quarter hour + direction. So in you example: >> > > >> > > 07(year) 02(month) 26(day of month) 18(hour) 57(minutes) 58(sec) >> 0(tens >> > > of sec) 00(quarter hours diff to utc) +(direction) >> > > >> > > If you think that there is a bug in kannel, so please provide >> following >> > > infos: >> > > 1) your system time + timezone ( bash# date) >> > > 2) which cgi params you used on sendsms interface >> > > 3) smpp dump as above >> > > >> > > > 2007-02-26 19:57:58 [24849] [12] DEBUG: registered_delivery: 1 = >> > > > 0x00000001 >> > > > 2007-02-26 19:57:58 [24849] [12] DEBUG: replace_if_present_flag: >> > > > 0 >> = >> > > > 0x00000000 >> > > > 2007-02-26 19:57:58 [24849] [12] DEBUG: data_coding: 0 = >> 0x00000000 >> > > > 2007-02-26 19:57:58 [24849] [12] DEBUG: sm_default_msg_id: 0 = >> > > > 0x00000000 >> > > > 2007-02-26 19:57:58 [24849] [12] DEBUG: sm_length: 4 = 0x00000004 >> > > > 2007-02-26 19:57:58 [24849] [12] DEBUG: short_message: "test" >> > > > 2007-02-26 19:57:58 [24849] [12] DEBUG: SMPP PDU dump ends. >> > > > ---------------------------------- END >> > > > >> > > > This message is passed to the mobile (succeeded) >> > > > See the time when sending, it's 2007-02-26 19:57:58 when it was >> 17:57 >> > > > really. >> > > > >> > > > here's another log snapshot wich doesnt succeed sending the MT : >> > > > i've just fixed the system time to the real time (18:01) >> > > > >> > > > ---------------------------------- BEGIN >> > > > 2007-02-26 18:01:19 [24849] [12] DEBUG: SMPP PDU 0x85a3920 dump: >> > > > 2007-02-26 18:01:19 [24849] [12] DEBUG: type_name: submit_sm >> > > > 2007-02-26 18:01:19 [24849] [12] DEBUG: command_id: 4 = >> > > > 0x00000004 >> > > > 2007-02-26 18:01:19 [24849] [12] DEBUG: command_status: 0 = >> > > > 0x00000000 2007-02-26 18:01:19 [24849] [12] DEBUG: >> sequence_number: >> > > > 1005 = 0x000003ed >> > > > 2007-02-26 18:01:19 [24849] [12] DEBUG: service_type: NULL >> > > > 2007-02-26 18:01:19 [24849] [12] DEBUG: source_addr_ton: 2 = >> > > >> > > 0x00000002 >> > > >> > > > 2007-02-26 18:01:19 [24849] [12] DEBUG: source_addr_npi: 1 = >> > > >> > > 0x00000001 >> > > >> > > > 2007-02-26 18:01:19 [24849] [12] DEBUG: source_addr: "22700" >> > > > 2007-02-26 18:01:19 [24849] [12] DEBUG: dest_addr_ton: 1 = >> 0x00000001 >> > > > 2007-02-26 18:01:19 [24849] [12] DEBUG: dest_addr_npi: 1 = >> 0x00000001 >> > > > 2007-02-26 18:01:19 [24849] [12] DEBUG: destination_addr: >> "28582653" >> > > > 2007-02-26 18:01:19 [24849] [12] DEBUG: esm_class: 3 = 0x00000003 >> > > > 2007-02-26 18:01:19 [24849] [12] DEBUG: protocol_id: 0 = >> 0x00000000 >> > > > 2007-02-26 18:01:19 [24849] [12] DEBUG: priority_flag: 0 = >> 0x00000000 >> > > > 2007-02-26 18:01:19 [24849] [12] DEBUG: schedule_delivery_time: >> > > > "070226170119000+" >> > > > 2007-02-26 18:01:19 [24849] [12] DEBUG: validity_period: >> > > > "070226170119000+" >> > > > 2007-02-26 18:01:19 [24849] [12] DEBUG: registered_delivery: 1 = >> > > > 0x00000001 >> > > > 2007-02-26 18:01:19 [24849] [12] DEBUG: replace_if_present_flag: >> > > > 0 >> = >> > > > 0x00000000 >> > > > 2007-02-26 18:01:19 [24849] [12] DEBUG: data_coding: 0 = >> 0x00000000 >> > > > 2007-02-26 18:01:19 [24849] [12] DEBUG: sm_default_msg_id: 0 = >> > > > 0x00000000 >> > > > 2007-02-26 18:01:19 [24849] [12] DEBUG: sm_length: 4 = 0x00000004 >> > > > 2007-02-26 18:01:19 [24849] [12] DEBUG: short_message: "test" >> > > > 2007-02-26 18:01:19 [24849] [12] DEBUG: SMPP PDU dump ends. >> > > > ---------------------------------- END >> > > > >> > > > On 2/26/07, Alexander Malysh <[EMAIL PROTECTED]> wrote: >> > > >> Hi, >> > > >> >> > > >> this is not a kannel bug and you can do nothing to fix the >> > > >> problem. You can >> > > >> only put pressure on SMSC guys that they fix validity parsing on >> SMSC >> > > >> side. >> > > >> >> > > >> Fourat Zouari wrote: >> > > >> > yes it is, how can i fix this ? >> > > >> > >> > > >> > On 2/23/07, Alexander Malysh <[EMAIL PROTECTED]> wrote: >> > > >> >> Hi, >> > > >> >> >> > > >> >> what kannel version? >> > > >> >> if this is 1.4.1 then it must be bug at SMSC because kannel >> > > >> >> send >> > > >> >> > > >> validity >> > > >> >> > > >> >> and deferred always in UTC and set it correctly according to >> SMPP >> > > >> >> spec. >> > > >> >> >> > > >> >> Fourat Zouari wrote: >> > > >> >> > anyone ? >> > > >> >> > >> > > >> >> > On 2/21/07, Fourat Zouari <[EMAIL PROTECTED]> wrote: >> > > >> >> >> Hello, >> > > >> >> >> I have Kannel connected to Telecom Operator's SMSC >> > > >> >> >> 'SMPP3.4'. The Operator's servers time has +2 hours on me, >> > > >> >> >> the correct >> time >> > > >> > > is >> > > >> > > >> >> mine >> > > >> >> >> > > >> >> >> and the operator wont adjust his time. >> > > >> >> >> The problem is when trying to send an MT, my MT is marked on >> the >> > > >> >> >> operator's SMSC with a timetoleave inferior to its time so >> > > >> >> >> it >> > > >> > > will >> > > >> > > >> not >> > > >> >> > > >> >> be >> > > >> >> >> > > >> >> >> delivered to mobile. >> > > >> >> >> As a workaround i synchronize my time on the operator's time >> and >> > > >> >> > > >> all's >> > > >> >> > > >> >> >> done, but after all i wont have a incorrect time. >> > > >> >> >> I tryed to set validityperiod to : >> > > >> >> >> validityperiod = 1440 >> > > >> >> >> But no difference, MTs will pass only when i synchronize my >> > > >> > > server >> > > >> > > >> >> >> time on the operator server time. >> > > >> >> >> > > >> >> -- >> > > >> >> Thanks, >> > > >> >> Alex >> > > >> >> > > >> -- >> > > >> Thanks, >> > > >> Alex >> > > >> > > -- >> > > Thanks, >> > > Alex >> >> >> -- >> Thanks, >> Alex >> -- Thanks, Alex
