The issue is fixed as far as sqlbox concerns. Just clarify the following:
2013-02-18 12:12:57 [1243] [7] DEBUG: type_name: submit_sm 2013-02-18 12:12:57 [1243] [7] DEBUG: command_id: 4 = 0x00000004 2013-02-18 12:12:57 [1243] [7] DEBUG: command_status: 0 = 0x00000000 2013-02-18 12:12:57 [1243] [7] DEBUG: sequence_number: 2 = 0x00000002 2013-02-18 12:12:57 [1243] [7] DEBUG: service_type: NULL 2013-02-18 12:12:57 [1243] [7] DEBUG: source_addr_ton: 1 = 0x00000001 2013-02-18 12:12:57 [1243] [7] DEBUG: source_addr_npi: 1 = 0x00000001 2013-02-18 12:12:57 [1243] [7] DEBUG: source_addr: "31628765806" 2013-02-18 12:12:57 [1243] [7] DEBUG: dest_addr_ton: 1 = 0x00000001 2013-02-18 12:12:57 [1243] [7] DEBUG: dest_addr_npi: 1 = 0x00000001 2013-02-18 12:12:57 [1243] [7] DEBUG: destination_addr: "31628765806" 2013-02-18 12:12:57 [1243] [7] DEBUG: esm_class: 3 = 0x00000003 2013-02-18 12:12:57 [1243] [7] DEBUG: protocol_id: 0 = 0x00000000 2013-02-18 12:12:57 [1243] [7] DEBUG: priority_flag: 0 = 0x00000000 2013-02-18 12:12:57 [1243] [7] DEBUG: schedule_delivery_time: NULL 2013-02-18 12:12:57 [1243] [7] DEBUG: validity_period: "711110215159000+" 2013-02-18 12:12:57 [1243] [7] DEBUG: registered_delivery: 1 = 0x00000001 2013-02-18 12:12:57 [1243] [7] DEBUG: replace_if_present_flag: 0 = 0x00000000 2013-02-18 12:12:57 [1243] [7] DEBUG: data_coding: 241 = 0x000000f1 2013-02-18 12:12:57 [1243] [7] DEBUG: sm_default_msg_id: 0 = 0x00000000 2013-02-18 12:12:57 [1243] [7] DEBUG: sm_length: 19 = 0x00000013 2013-02-18 12:12:57 [1243] [7] DEBUG: short_message: "Test to self 12:12." 2013-02-18 12:12:57 [1243] [7] DEBUG: SMPP PDU dump ends. The particular pdu doesn´t have validity period set on the sendsms interface. It should say: validity_period: NULL To what date and time does 711110215159000+ convert? == Rene From: Alexander Malysh [mailto:[email protected]] On Behalf Of Alexander Malysh Sent: maandag 18 februari 2013 13:51 To: Rene Kluwen Cc: [email protected] Subject: Re: Validity perdiod ok, understand... Can you confirm that the issue fixed now? Alex Am 18.02.2013 um 12:01 schrieb Rene Kluwen <[email protected]>: Because we save it into a different table we fetched it from. From: Alexander Malysh [mailto:[email protected]] On Behalf Of Alexander Malysh Sent: maandag 18 februari 2013 11:32 To: Rene Kluwen Cc: [email protected] Subject: Re: Validity perdiod I just want that validity & deferred is the absolute timestamp and not dependent from any message value. As to the mentioned code. I just don't understand why sqlbox first fetch message from db, sends it ro bearerbox and then insert it back to DB?? while (sqlbox_status == SQL_RUNNING && boxc->alive) { if ((msg = gw_sql_fetch_msg()) != NULL) { if (charset_processing(msg) == -1) { error(0, "Could not charset process message, dropping it!"); msg_destroy(msg); continue; } if (global_sender != NULL && (msg->sms.sender == NULL || octstr_len(msg->sms.sender) == 0)) { msg->sms.sender = octstr_duplicate(global_sender); } /* convert validity and deferred to unix timestamp */ if (msg->sms.validity != SMS_PARAM_UNDEFINED) msg->sms.validity = time(NULL) + msg->sms.validity * 60; if (msg->sms.deferred != SMS_PARAM_UNDEFINED) msg->sms.deferred = time(NULL) + msg->sms.deferred * 60; send_msg(boxc->bearerbox_connection, boxc, msg); ^^^^^ here is correct that we send unix timestamp to bearerbox, because bearerbox expects seconds now gw_sql_save_msg(msg, octstr_imm("MT")); ^^^^^^^^^ why do we save message again, that we just fetched from DB? } else { gwthread_sleep(SLEEP_BETWEEN_SELECTS); } Alex Am 18.02.2013 um 10:54 schrieb Rene Kluwen < <mailto:[email protected]> [email protected]>: Not sure why you want to go through all this trouble. But the function sql_to_bearerbox does not do still what you want. Here goes: /* convert validity and deferred to unix timestamp */ if (msg->sms.validity != SMS_PARAM_UNDEFINED) msg->sms.validity = time(NULL) + msg->sms.validity * 60; if (msg->sms.deferred != SMS_PARAM_UNDEFINED) msg->sms.deferred = time(NULL) + msg->sms.deferred * 60; send_msg(boxc->bearerbox_connection, boxc, msg); /* message is sent with validity in absolute seconds */ gw_sql_save_msg(msg, octstr_imm("MT")); /* message is saved in sent_sms in absolute seconds */ From: Alexander Malysh [mailto:malysh00@ <http://gmail.com> gmail.com] On Behalf Of Alexander Malysh Sent: maandag 18 februari 2013 10:02 To: Rene Kluwen Cc: <mailto:[email protected]> [email protected] Subject: Re: Validity perdiod Hi, just found a typo in my patch and changed it to: msg_escaped = msg_duplicate(msg); /* convert validity & deferred to minutes */ if (msg_escaped->sms.validity != SMS_PARAM_UNDEFINED) msg_escaped->sms.validity = (msg_escaped->sms.validity - time(NULL))/60; if (msg_escaped->sms.deferred != SMS_PARAM_UNDEFINED) msg_escaped->sms.deferred = (msg_escaped->sms.deferred - time(NULL))/60; gw_sql_save_msg(msg_escaped, octstr_imm("MT")); This should fix this issue. Alex Am 18.02.2013 um 09:57 schrieb Rene Kluwen < <mailto:[email protected]> [email protected]>: In sqlbox, two different things happen. 1. Select rows from send_sms and send them to bearerbox (with validity in minutes) 2. Relay rows from smsbox to bearerbox and store them in sent_sms on the fly. These messages have been processed by smsbox already and should not be reprocessed. I am not sure what exactly you did because I dont have time to look at the code now. But something is going very wrong here. Even without using sqlbox we are getting invalid validity_period fields in smsc_smpp. On a side note, I see now that opensmppbox never sends a validity field to its connected entity, now I look at it. But thats a different story. == Rene From: Alexander Malysh [mailto:malysh00@ <http://gmail.com> gmail.com] On Behalf Of Alexander Malysh Sent: maandag 18 februari 2013 9:29 To: Rene Kluwen Cc: <mailto:[email protected]> [email protected] Subject: Re: Validity perdiod Hi Rene, I converted validity & deferred to be unix timestamp internally, they were in minutes before. Due to the fact that I didn't know how sqlbox works, I assumed that validity & deferred in the sqlbox tables also stored in minutes therefore this conversion: if validity set then (now - unix timestamp) / 60 -> minutes the counter part is when selecting values from DB and sending to bearerbox: /* convert validity and deferred to unix timestamp */ if (msg->sms.validity != SMS_PARAM_UNDEFINED) msg->sms.validity = time(NULL) + msg->sms.validity * 60; if (msg->sms.deferred != SMS_PARAM_UNDEFINED) msg->sms.deferred = time(NULL) + msg->sms.deferred * 60; Alex Am 16.02.2013 um 15:36 schrieb Rene Kluwen < <mailto:[email protected]> [email protected]>: Also: in sqlbox.c (function smsbox_to_bearerbox()): /* convert validity & deferred to minutes */ if (msg->sms.validity != SMS_PARAM_UNDEFINED) msg->sms.validity = (msg->sms.validity - time(NULL))/60; if (msg->sms.deferred != SMS_PARAM_UNDEFINED) msg->sms.deferred = (msg->sms.deferred - time(NULL))/60; Isnt this field encoded twice now? Once in smsbox and another time in sqlbox? Alexander, you made this change. Please shed some light. From: <mailto:[email protected]> [email protected] [mailto:devel- <mailto:[email protected]> [email protected]] On Behalf Of Rene Kluwen Sent: vrijdag 15 februari 2013 15:16 To: <mailto:[email protected]> [email protected] Subject: Validity perdiod I came across an issue since svn version 4956 of smsbox.c, using smpp. The logs show the following: 2013-02-15 14:52:45 [3144] [7] DEBUG: validity_period: "711110215159000+" This was this afternoon at 14:52. The validity field of the sendsms interface was not set. How do I interpret this as YYMMDDhhmmsstnnp? One of my clients needed to downgrade because of this issue. == Rene
