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
