Re: SMPP validity dates and time difference

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
> >>>
> >>>
> >>>
> >>>
> >>
> >
> >
>