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 :
---------------------------------- 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+" 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
