Am 06.04.2009 um 16:49 schrieb Hervé Nicol:
Yes, but for instance in my case, my SMSC operator's server is not in
UTC.
seems you misunderstood this part? kannel send time in UTC and
therefore sets timedifference to 00+ (means UTC time no difference).
If SMSC don't parse it correctly it's SMSC bug but not kannels.
On top of that, in some cases, both servers may not be well
synchronized.
this is another issue... use ntpd...
A relative validity date works in any case.
it doesn't work in any case... let us assume you sent message with
relative 5 min,
smsc accepted your message and wrote in to DB but didn't recorded
absolute timestamp.
Then 5min passed and smsc want process your message from DB. Yes it
will send it...
Yes you will say, this is smsc bug... Yes, but real world looks
different ;)
-
Hervé Nicol
Le lundi 06 avril 2009 à 16:38 +0200, Alexander Malysh a écrit :
Hi,
kannel will send validity in utc therefore 00+ is hardcoded.
Thanks,
Alex
Am 06.04.2009 um 16:12 schrieb Hervé Nicol:
Hello,
I already sent this messages to the "users" mailing list, but I
guess
that was not the right place for such some protocol oriented
thoughts.
SMPP validity dates is specified following this time format:
“YYMMDDhhmmsstnnp”, where:
* ‘nn’ is the Time difference in quarter hours between local time
(as
expressed in the first 13 bytes) and UTC (Universal Time Constant)
time
(00-48).
* 'p' is '+' or '-' depending if local time is retarded or
advanced in
relation to UTC time.
It seems to me that these parameters are hard coded to "00+" in
Kannel.
Wouldn't it be nice if we could set them from the config file?
On top of that, I've seen the 'R' value as 'p' parameter. I think
it's
a feature starting from SMPP V3.4
The 'R' value defines a relative validity date. It means you don't
care
anymore about server's timezones or the different servers time
offset,
but just define the how long you want your SMS to be valid.
For instance, “000000000500000R”, means "5 minutes validity from
when
the SMSC receives the message".
What do you think of this possibility?
I currently use relative validity, but our patch replaces the actual
"full date" behaviour. I guess it breaks compatibility with older
SMPP
gateways.
Thanks for your advice.
-
Hervé Nicol
