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:
"000000000100000R"

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 = 0x00000004
2018-07-17 10:57:20 [2565] [25] DEBUG: command_status: 0 = 0x00000000
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 = 0x00000003
2018-07-17 10:57:20 [2565] [25] DEBUG: protocol_id: 0 = 0x00000000
2018-07-17 10:57:20 [2565] [25] DEBUG: priority_flag: 1 = 0x00000001
2018-07-17 10:57:20 [2565] [25] DEBUG: schedule_delivery_time: NULL
2018-07-17 10:57:20 [2565] [25] DEBUG: validity_period: "180717105820000+"

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

[a***@kannel.org]

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

Post by Денис Давыдов
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.
2018-07-17 10:57:20 [29721] [421] DEBUG: validity_period: "000000000100000R"
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 = 0x00000004
2018-07-17 10:57:20 [2565] [25] DEBUG: command_status: 0 = 0x00000000
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 = 0x00000003
2018-07-17 10:57:20 [2565] [25] DEBUG: protocol_id: 0 = 0x00000000
2018-07-17 10:57:20 [2565] [25] DEBUG: priority_flag: 1 = 0x00000001
2018-07-17 10:57:20 [2565] [25] DEBUG: schedule_delivery_time: NULL
2018-07-17 10:57:20 [2565] [25] DEBUG: validity_period: "180717105820000+"
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

[Денис Давыдов]

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

Post by a***@kannel.org
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

Post by Денис Давыдов
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.

Post by Денис Давыдов
For example, this is a snippet from the opensmppbox logfile (this was a

"000000000100000R"

Post by Денис Давыдов
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 = 0x00000004
2018-07-17 10:57:20 [2565] [25] DEBUG: command_status: 0 = 0x00000000
2018-07-17 10:57:20 [2565] [25] DEBUG: sequence_number: 225108 =

0x00036f54

Post by Денис Давыдов
2018-07-17 10:57:20 [2565] [25] DEBUG: service_type: "CMT"
...
2018-07-17 10:57:20 [2565] [25] DEBUG: esm_class: 3 = 0x00000003
2018-07-17 10:57:20 [2565] [25] DEBUG: protocol_id: 0 = 0x00000000
2018-07-17 10:57:20 [2565] [25] DEBUG: priority_flag: 1 = 0x00000001
2018-07-17 10:57:20 [2565] [25] DEBUG: schedule_delivery_time: NULL

"180717105820000+"

Post by Денис Давыдов
For me the goal is to keep relative time format keep unchanged while

message leaves the kannel.

Post by Денис Давыдов
Any feedback is appreciated. Thanks!
--
Kind regards,
Denis

[a***@kannel.org]

Hi Denis,

sorry but it make no sense to me. If Kannel send absolute time format than SMSC can do whatever
it want with it, recalculate to local time etc. Absolute time is not afffected if you are moving between TZs.

Alex

Post by Денис Давыдов
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
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

Post by Денис Давыдов
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.
2018-07-17 10:57:20 [29721] [421] DEBUG: validity_period: "000000000100000R"
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 = 0x00000004
2018-07-17 10:57:20 [2565] [25] DEBUG: command_status: 0 = 0x00000000
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 = 0x00000003
2018-07-17 10:57:20 [2565] [25] DEBUG: protocol_id: 0 = 0x00000000
2018-07-17 10:57:20 [2565] [25] DEBUG: priority_flag: 1 = 0x00000001
2018-07-17 10:57:20 [2565] [25] DEBUG: schedule_delivery_time: NULL
2018-07-17 10:57:20 [2565] [25] DEBUG: validity_period: "180717105820000+"
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