Re: Keeping relative time format w/o conversion to absolute time format
Alex, Thanks for the answer. Firstly, the set of different validity_period is a requirement in our business workflow. Secondly, our ESMEs is geographically in different TZs and they are movable objects and we don't know ESME's location at the time of sending the message. In this case our SMPP provider recommends us to use the relative time format, because of the end provider's equipment that interacting with ESME works in accordance with local time zone (it is verify validity_period in it's retry sending schemes as I was informed). -- Kind regards, Denis чт, 19 июл. 2018 г. в 12:18, : > Hi, > > tha first question would be, why do you want to keep it in relative time > format? > As answer to your question: no this is not possible now , because Kannel > converts > timestamp to unix timestamp internally on the input side and afterwards to > absolute > time format. Sure you make changes to the source code to send relative > time format… > > Thanks, > Alex > > > Am 19.07.2018 um 08:51 schrieb Денис Давыдов : > > > > Hi all, > > > > Is there a possibility to keep validity_period of MT which sending from > opensmppbox to external SMSCs in the relative time format unchanged? For > now, I see the kannel changing it to the absolute time format. > > > > For example, this is a snippet from the opensmppbox logfile (this was a > submit_sm where is the vp was set to 1 minute): > > > > 2018-07-17 10:57:20 [29721] [421] DEBUG: validity_period: > "010R" > > > > That is a snippet from SMSC log: > > > > 2018-07-17 10:57:20 [2565] [25] DEBUG: SMPP PDU 0x7fe864004010 dump: > > 2018-07-17 10:57:20 [2565] [25] DEBUG: type_name: submit_sm > > 2018-07-17 10:57:20 [2565] [25] DEBUG: command_id: 4 = 0x0004 > > 2018-07-17 10:57:20 [2565] [25] DEBUG: command_status: 0 = 0x > > 2018-07-17 10:57:20 [2565] [25] DEBUG: sequence_number: 225108 = > 0x00036f54 > > 2018-07-17 10:57:20 [2565] [25] DEBUG: service_type: "CMT" > > ... > > 2018-07-17 10:57:20 [2565] [25] DEBUG: esm_class: 3 = 0x0003 > > 2018-07-17 10:57:20 [2565] [25] DEBUG: protocol_id: 0 = 0x > > 2018-07-17 10:57:20 [2565] [25] DEBUG: priority_flag: 1 = 0x0001 > > 2018-07-17 10:57:20 [2565] [25] DEBUG: schedule_delivery_time: NULL > > 2018-07-17 10:57:20 [2565] [25] DEBUG: validity_period: > "18071710582+" > > > > For me the goal is to keep relative time format keep unchanged while > message leaves the kannel. > > > > Any feedback is appreciated. Thanks! > > > > -- > > Kind regards, > > Denis > >
Re: Keeping relative time format w/o conversion to absolute time format
Hi, tha first question would be, why do you want to keep it in relative time format? As answer to your question: no this is not possible now , because Kannel converts timestamp to unix timestamp internally on the input side and afterwards to absolute time format. Sure you make changes to the source code to send relative time format… Thanks, Alex > Am 19.07.2018 um 08:51 schrieb Денис Давыдов : > > Hi all, > > Is there a possibility to keep validity_period of MT which sending from > opensmppbox to external SMSCs in the relative time format unchanged? For now, > I see the kannel changing it to the absolute time format. > > For example, this is a snippet from the opensmppbox logfile (this was a > submit_sm where is the vp was set to 1 minute): > > 2018-07-17 10:57:20 [29721] [421] DEBUG: validity_period: "010R" > > That is a snippet from SMSC log: > > 2018-07-17 10:57:20 [2565] [25] DEBUG: SMPP PDU 0x7fe864004010 dump: > 2018-07-17 10:57:20 [2565] [25] DEBUG: type_name: submit_sm > 2018-07-17 10:57:20 [2565] [25] DEBUG: command_id: 4 = 0x0004 > 2018-07-17 10:57:20 [2565] [25] DEBUG: command_status: 0 = 0x > 2018-07-17 10:57:20 [2565] [25] DEBUG: sequence_number: 225108 = 0x00036f54 > 2018-07-17 10:57:20 [2565] [25] DEBUG: service_type: "CMT" > ... > 2018-07-17 10:57:20 [2565] [25] DEBUG: esm_class: 3 = 0x0003 > 2018-07-17 10:57:20 [2565] [25] DEBUG: protocol_id: 0 = 0x > 2018-07-17 10:57:20 [2565] [25] DEBUG: priority_flag: 1 = 0x0001 > 2018-07-17 10:57:20 [2565] [25] DEBUG: schedule_delivery_time: NULL > 2018-07-17 10:57:20 [2565] [25] DEBUG: validity_period: "18071710582+" > > For me the goal is to keep relative time format keep unchanged while message > leaves the kannel. > > Any feedback is appreciated. Thanks! > > -- > Kind regards, > Denis
Keeping relative time format w/o conversion to absolute time format
Hi all, Is there a possibility to keep validity_period of MT which sending from opensmppbox to external SMSCs in the relative time format unchanged? For now, I see the kannel changing it to the absolute time format. For example, this is a snippet from the opensmppbox logfile (this was a submit_sm where is the vp was set to 1 minute): 2018-07-17 10:57:20 [29721] [421] DEBUG: validity_period: "010R" That is a snippet from SMSC log: 2018-07-17 10:57:20 [2565] [25] DEBUG: SMPP PDU 0x7fe864004010 dump: 2018-07-17 10:57:20 [2565] [25] DEBUG: type_name: submit_sm 2018-07-17 10:57:20 [2565] [25] DEBUG: command_id: 4 = 0x0004 2018-07-17 10:57:20 [2565] [25] DEBUG: command_status: 0 = 0x 2018-07-17 10:57:20 [2565] [25] DEBUG: sequence_number: 225108 = 0x00036f54 2018-07-17 10:57:20 [2565] [25] DEBUG: service_type: "CMT" ... 2018-07-17 10:57:20 [2565] [25] DEBUG: esm_class: 3 = 0x0003 2018-07-17 10:57:20 [2565] [25] DEBUG: protocol_id: 0 = 0x 2018-07-17 10:57:20 [2565] [25] DEBUG: priority_flag: 1 = 0x0001 2018-07-17 10:57:20 [2565] [25] DEBUG: schedule_delivery_time: NULL 2018-07-17 10:57:20 [2565] [25] DEBUG: validity_period: "18071710582+" For me the goal is to keep relative time format keep unchanged while message leaves the kannel. Any feedback is appreciated. Thanks! -- Kind regards, Denis
