Patch: gw/smsc/smsc_smpp.c (Re: syncronize kannel with smsc)

I stand corrected. bb sends in, at least in SMPP, absolute time as GMT + 
validity * 60 for validity and scheduled delivery time. Not very safe or 
good. Needs the server to be synchronized with SMSc, which would probably 
mean both have to be ntp synchronized.

This is a defect of the SMPP spec. It defines the format of relative time in 
absolute terms, instead of seconds, making it difficult to calculate and 
reconstruct.

The proposed patch makes smpp work with relative time. Please test, I do not 
have access to an SMSc. Let me know how it goes. I hope that all SMScs 
support it. It is more accurate than absolute time, since it doesn't require 
synchronization between smsc and bearerbox.

Please vote.

BR,
Nikos
----- Original Message ----- 
From: "Milan P. Stanic" <[email protected]>
To: <[email protected]>
Sent: Monday, November 22, 2010 4:25 PM
Subject: Re: syncronize kannel with smsc


> On Mon, 2010-11-22 at 05:31, ishagh ouldbah wrote:
>> are you sure?
>
> According to SMPP version 3.4 time can be absolute or relative. Absolute
> time is default.
> How it is implemented in particular software is another question. I
> think that the kannel uses absolute time, at least for SMPP.
>
> Here is comment from gw/smsc/smsc_smpp.c
> ---------------------------------------------------------
> /*
>     * check for validity and defered settings
>     * were message value has higher priiority then smsc config group
>     * value
>     * Note: we always send in UTC and just define "Time Difference" as
>     * 00 and
>     *       direction '+'.
>     */
>
> ----------------------------------------------------------
>
>> ________________________________
>> From: Nikos Balkanas <[email protected]>
>> To: ishagh ouldbah <[email protected]>; [email protected]
>> Sent: Mon, November 22, 2010 1:00:48 PM
>> Subject: Re: syncronize kannel with smsc
>>
>> Well, UG is wrong there.  In the SMSc definitions it states:
>>
>> validityperiod integer
>>
>> How long the message will be valid, i.e., how long the SMSC will try try 
>> to send
>> the message to the recipient. Defined in minutes.
>>
>> BR,
>> Nikos
>> ----- Original Message ----- From: ishagh ouldbah
>> To: Nikos Balkanas ; [email protected]
>> Sent: Monday, November 22, 2010 1:31 PM
>> Subject: Re: syncronize kannel with smsc
>>
>>
>> thans for your reponce
>> but in SMS Push (send-sms) CGI Variables it is writen in the userguid 
>> that to
>> use
>> the variable validity you should syncronize with smsc
>> contant
>> Optional. If given, Kannel will
>> inform SMS Center that it should
>> only try to send the message for
>> this many minutes. If the
>> destination mobile is off other
>> situation that it cannot receive
>> the sms, the smsc discards the
>> message. Note: you must have
>> your Kannel box time
>> synchronized with the SMS
>> Center.
>> note that i need to specify it for a specified service
>> regards
>>
>>
>>
>>
>>
>> From: Nikos Balkanas <[email protected]>
>> To: ishagh ouldbah <[email protected]>; [email protected]
>> Sent: Sun, November 21, 2010 4:00:52 PM
>> Subject: Re: syncronize kannel with smsc
>>
>> Hi,
>>
>> You don't need to. SMPP protocol works with validity period (relative 
>> time).
>> Therefore, no absolute time is ever involved and you don't need to 
>> synchronize.
>>
>> BR,
>> Nikos
>> ----- Original Message ----- From: ishagh ouldbah
>> To: [email protected]
>> Sent: Sunday, November 21, 2010 4:18 PM
>> Subject: syncronize kannel with smsc
>>
>>
>> Hi all,
>> I want to set validity variable so I need to syncrnize with the smsc
>> my question is
>> How can I syncronize kannel box with smsc
>> regards
>>
>>
>>
>>
>
> -- 
> Kind regards,  Milan
> --------------------------------------------------
> Arvanta, IT Security        http://www.arvanta.net
> Please do not send me e-mail containing HTML code.
>

Index: gw/smsc/smsc_smpp.c
===================================================================
--- gw/smsc/smsc_smpp.c	(revision 4850)
+++ gw/smsc/smsc_smpp.c	(working copy)
@@ -746,11 +746,64 @@
     }
 }
 
+static Octstr *relative_time(time_t now, struct tm *abs, int interval){
+    struct tm tm = gw_gmtime(now + interval);
 
+    if (tm.tm_sec >= abs->tm_sec)
+        tm.tm_sec -= abs->tm_sec;
+    else{
+        tm.tm_sec += 60 - abs->tm_sec;
+        tm.tm_min += 1;
+    }
+    if (tm.tm_min >= abs->tm_min)
+        tm.tm_min -= abs->tm_min;
+    else{
+        tm.tm_min += 60 - abs->tm_min;
+        tm.tm_hour += 1;
+    }
+    if (tm.tm_hour >= abs->tm_hour)
+        tm.tm_hour -= abs->tm_hour;
+    else{
+        tm.tm_hour += 24 - abs->tm_hour;
+        tm.tm_mday += 1;
+    }
+    if (tm.tm_mday >= abs->tm_mday)
+        tm.tm_mday -= abs->tm_mday;
+    else{
+        int days = 30;
+
+        tm.tm_mon += 1;
+        if (tm.tm_mon == 1){                         // February
+            if ((tm.tm_year + 1900)%4)
+               days = 28;
+            else                                     // Leap year
+               days = 29;
+        }
+        else if (!tm.tm_mon%2){
+            if (tm.tm_mon <= 6)
+                days = 31;
+        }
+        else if (tm.tm_mon > 6)
+             days = 31;
+        tm.tm_mday += days - abs->tm_mday;
+    }
+    if (tm.tm_mon >= abs->tm_mon)
+        tm.tm_mon -= abs->tm_mon;
+    else{
+        tm.tm_mon += 12 - abs->tm_mon;
+        tm.tm_year += 1;
+    }
+    tm.tm_year -= abs->tm_year;
+    return(octstr_format("%02d%02d%02d%02d%02d%02d000R", tm.tm_year, tm.tm_mon,
+        tm.tm_mday, tm.tm_hour, tm.tm_min, tm.tm_sec));
+}
+
 static SMPP_PDU *msg_to_pdu(SMPP *smpp, Msg *msg)
 {
     SMPP_PDU *pdu;
     int validity;
+    struct tm tm;
+    time_t now = 0;
 
     pdu = smpp_pdu_create(submit_sm,
     	    	    	  counter_increase(smpp->message_id_counter));
@@ -913,23 +966,25 @@
 
     /*
      * check for validity and defered settings
-     * were message value has higher priiority then smsc config group value
-     * Note: we always send in UTC and just define "Time Difference" as 00 and
-     *       direction '+'.
+     * were message value has higher priority than smsc config group value
+     * Note: we send in relative time.
      */
     validity = msg->sms.validity != SMS_PARAM_UNDEFINED ? msg->sms.validity : smpp->validityperiod;
     if (validity != SMS_PARAM_UNDEFINED) {
-        struct tm tm = gw_gmtime(time(NULL) + validity * 60);
-        pdu->u.submit_sm.validity_period = octstr_format("%02d%02d%02d%02d%02d%02d000+",
-                tm.tm_year % 100, tm.tm_mon + 1, tm.tm_mday,
-                tm.tm_hour, tm.tm_min, tm.tm_sec);
+        now = time(NULL);
+        tm = gw_gmtime(now);
+        pdu->u.submit_sm.validity_period = relative_time(now, &tm,
+            validity * 60);
+
     }
 
     if (msg->sms.deferred != SMS_PARAM_UNDEFINED) {
-        struct tm tm = gw_gmtime(time(NULL) + msg->sms.deferred * 60);
-        pdu->u.submit_sm.schedule_delivery_time = octstr_format("%02d%02d%02d%02d%02d%02d000+",
-                tm.tm_year % 100, tm.tm_mon + 1, tm.tm_mday,
-                tm.tm_hour, tm.tm_min, tm.tm_sec);
+        if (!now){
+            now = time(NULL);
+            tm = gw_gmtime(now);
+        }
+        pdu->u.submit_sm.schedule_delivery_time = relative_time(now, &tm,
+            msg->sms.deferred * 60);
     }
 
     /* ask for the delivery reports if needed */