Fourat Zouari wrote: > seems to be the reason for that :) > thanks for your help. > anyway, where can we found a well documented sqlbox integration ?
sqlbox is not a part of kannel. this is standalone module and docs should be provided from his author (don't know who is now). I found resolution to your issue just by reading the sources :) > > 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 >> >> >> -- Thanks, Alex
