RE: Validity perdiod

"Rene Kluwen" <[email protected]>
Newsgroups gmane.comp.mobile.kannel.devel
Message-ID <[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 < <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 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:[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;

 

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:[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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.