So, you mean each solution is vulnerable to SMSC bugs. Why not giving Kannel some more power / flexibility to bypass SMSC bugs?
Advices such as "use ntpd" or "use UTC" seem obvious to me. But, in real life, as you said, things may be different. A small company can not always obtain its TELCO to do this way. regards, - Hervé Nicol Le lundi 06 avril 2009 à 17:09 +0200, Alexander Malysh a écrit : > 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 > >>> > >>> > >>> > >>> > >> > > > > >
