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, <amal...@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
>
> > Am 19.07.2018 um 08:51 schrieb Денис Давыдов <dyna...@gmail.com>:
> >
> > 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
>
>

Reply via email to