It is going wrong because of that code on sqlbox. It is setting the original message validity in minutes, instead of msg_escaped,so validity is sent to bearerbox and smsc in minutes but since the last changes it is expected in unixtimestamp secs. I bet that for MT with validity set from smsbox, in sqlbox table you have the validity value in unixtime instead of that in minutes.
This is how I get. If you set validity param on sendsms smsbox: from minutes to unix timestamp msg->sms.validity = validity * 60 + time(NULL); sqlbox: smsbox_to_bearerbox() from unixtimestamp to minutes msg->sms.validity = (msg->sms.validity - time(NULL))/60; ... send_msg(conn->bearerbox_connection, conn, msg); smsc_smpp: arrives here in minutes but is expected in sec unix timestamp. validity = msg->sms.validity; gw_gmtime(validity); here the validity is in minutes thas why that issue.... PS: Sorry if I interfered On Sat, Feb 16, 2013 at 6:06 PM, Rene Kluwen <[email protected]> wrote: > msg_escaped is just a duplicate of the original message. > It is used because gw_sql_save_msg does in-place quoting of the resulting > message. > > It gets weirder. From the log files of a client: > > 2013-02-05 12:22:08 [24338] [9] DEBUG: schedule_delivery_time: > "130205122108000+" > 2013-02-05 12:22:08 [24338] [9] DEBUG: validity_period: > "130205122108000+" > > Also they know me to write: > > Gets weirder. I set the validity period and we're still getting back SMSC > returned error code 0x00000062 (Invalid message validity period) in > response > to submit_sm. > > Something is going terribly wrong here. > > > From: Rinor Hoxha [mailto:[email protected]] > Sent: zaterdag 16 februari 2013 17:33 > To: Rene Kluwen > Cc: [email protected] > Subject: Re: Validity perdiod > > I also was looking into this. > Is it possible he wanted msg_escaped in place of msg so when inserting into > db, validity has the original value in minutes? > > if (msg_type(msg) == sms) { > debug("sqlbox", 0, "smsbox_to_bearerbox: sms received"); > 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")); > msg_destroy(msg_escaped); > } > > send_msg(conn->bearerbox_connection, conn, msg); > Br, Rinor > > On Sat, Feb 16, 2013 at 3:36 PM, Rene Kluwen <[email protected]> > wrote: > 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 > > >
