Re: Validity perdiod
Alexander Malysh <[email protected]>
| Newsgroups | gmane.comp.mobile.kannel.devel |
|---|---|
| Message-ID | <[email protected]> |
Hi Rene, I don't understand how it should be possible if you not set validity in sendsms interface. Are you using new version of smsbox? If so, could you please post your URL to smsbox? Thanks, Alex Am 18.02.2013 um 14:19 schrieb Rene Kluwen <[email protected]>: > 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 <[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:[email protected]] On Behalf Of Alexander Malysh > Sent: maandag 18 februari 2013 10:02 > To: Rene Kluwen > Cc: [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 <[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 don’t 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 that’s a different story. > > == Rene > > From: Alexander Malysh [mailto:[email protected]] On Behalf Of Alexander Malysh > Sent: maandag 18 februari 2013 9:29 > To: Rene Kluwen > Cc: [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 <[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; > > Isn’t this field encoded twice now? Once in smsbox and another time in sqlbox? > > Alexander, you made this change. Please shed some light. > > From: [email protected] [mailto:[email protected]] On Behalf Of Rene Kluwen > Sent: vrijdag 15 februari 2013 15:16 > To: [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