Because we save it into a different table we fetched it from.

 

From: Alexander Malysh [mailto:malys...@gmail.com] On Behalf Of Alexander
Malysh
Sent: maandag 18 februari 2013 11:32
To: Rene Kluwen
Cc: devel@kannel.org
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 <rene.klu...@chimit.nl>:





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:malys...@gmail.com] On Behalf Of Alexander
Malysh
Sent: maandag 18 februari 2013 10:02
To: Rene Kluwen
Cc: devel@kannel.org
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:rene.klu...@chimit.nl>
rene.klu...@chimit.nl>:






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:malysh00@ <http://gmail.com> gmail.com] On
Behalf Of Alexander Malysh
Sent: maandag 18 februari 2013 9:29
To: Rene Kluwen
Cc:  <mailto:devel@kannel.org> devel@kannel.org
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:rene.klu...@chimit.nl>
rene.klu...@chimit.nl>:







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:  <mailto:devel-boun...@kannel.org> devel-boun...@kannel.org
[mailto:devel- <mailto:boun...@kannel.org> boun...@kannel.org] On Behalf Of
Rene Kluwen
Sent: vrijdag 15 februari 2013 15:16
To:  <mailto:devel@kannel.org> devel@kannel.org
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

 

Reply via email to