RE: deferred parameters
I think now we tight the problem down to not Kannel-related but SMSC-related. If we send a valid schedule_delivery_time, but the SMSC delivers immediately it is an issue on their side. Rene Kluwen Chimit -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Alejandro Guerrieri Sent: donderdag 22 juni 2006 5:34 To: users@kannel.org Subject: Re: deferred parameters Yep, I think that's how it should be... I've made a few more tests with increasing deferred values (0, 1, 60 and 600), here are the results: deferred=0 - 2006-06-21 23:19:59 - 060622021959000+ deferred=1 - 2006-06-21 23:20:07 - 060622022107000+ deferred=60 - 2006-06-21 23:20:11 - 060622032011000+ deferred=600 - 2006-06-21 23:20:19 - 060622122019000+ So now the difference are now consistent with 3:00, 3:01, 4:00 and 13:00 Hours difference (which makes sense with the GMT -3 Timezone. Maybe my former message was sent with deferred=60 ant that's why it showed a 4-hour difference and 3:01 :P ). Anyway, the messages are being delivered right after submital, no matter what I put on the deferred parameter. I've checked SMPP 3.4 and it says as follows: == 5.2.15 schedule_delivery_time This parameter specifies the scheduled time at which the message delivery should be first attempted. It defines either the absolute date and time or relative time from the current SMSC time at which delivery of this message will be attempted by the SMSC. It can be specified in either absolute time format or relative time format. The encoding of a time format is specified in Section 7.1.1. And 7.1.1 says: 7.1.1 Time Format In this interface, all time/date related fields will be in ASCII with the following format: YYMMDDhhmmsstnnp where 'YY' last two digits of the year (00-99) 'MM' month (01-12) 'DD' day (01-31) 'hh' hour (00-23) 'mm' minute (00-59) 'ss' second (00-59) 't' tenths of second (0-9) 'nn' Time difference in quarter hours between local time (as expressed in the first 13 octets) and UTC (Universal Time Constant) time (00-48). 'p' - + Local time is in quarter hours advanced in relation to UTC time. - Local time is in quarter hours retarded in relation to UTC time. R Local time is relative to the current SMSC time. Note: Where responses are reported by the SMSC the local time of the SMSC will be given, and the format will be YYMMDDhhmmss, with the same definitions as above. = So Kannel obviously translates the times to UTC and send that to the SMSC. Even with an offset hanging around, it's a positive delay so should have worsen the referral, and if not, the deferred=600 (10 hours) should have worked isn't it? It doesn't make sense, unless the SMSC it's ignoring the parameter... I'll make some more tests over other links tomorrow and see if I can find some pattern. Please let me know if anybody figures out where the problem could be. TIA Alejandro. On 6/21/06, Rene Kluwen [EMAIL PROTECTED] wrote: What is your scheduled_delivery_time if you set deferred to a higher value? In this case, the immediate delivery is correct, from a point of view of your SMSC. Because you submit the message at 19:48:07 (Argentina time) and the message should be delivered at 23:48:07 (UTC time). These times are identical. In smsbox.c the msg-sms.deferred field is copied directly from the http parameter. The following code translates this field into the pdu-u.submit_sm.schedule_delivery_time: if (msg-sms.deferred = 0) { 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); } As far as I can see, this is correct. Still there should be some kind of bug here, because if the log that you show is a pdu from posting the link that is just above the log, the schedule_delivery_time should be 060621234907000+ (note the 8 that is now a 9). Rene Kluwen Chimit -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Rene Kluwen Sent: donderdag 22 juni 2006 2:14 To: Alejandro Guerrieri; users@kannel.org Subject: RE: deferred parameters SMPP: 7.1.1.1 Absolute Time format This is the default format used by SMPP. Scheduled delivery times and expiry times are specified in their global UTC format, including the quarter hour offset and direction symbol + or -. Rene Kluwen Chimit -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Alejandro Guerrieri Sent: donderdag 22 juni 2006 1:04 To: users@kannel.org Subject: Re: deferred parameters I've upgraded Kannel to latest CVS release, 20060621 and I still can't defer the messages. I've tried with a simple message: http://myhost:myport/cgi-bin/sendsms?username=myuserpassword=mypassfrom=12 34to=1234567890smsc=mysmsctext=testdeferred=1 But the message gets delivery
Re: deferred parameters
Yes, I'm afraid Kannel it's now doing fine. I'll try with other SMSC links and check with the SMSC operator(s) to isolate the problem. Thanks Rene and Martin for the help. Regards, On 6/22/06, Rene Kluwen [EMAIL PROTECTED] wrote: I think now we tight the problem down to not Kannel-related but SMSC-related. If we send a valid schedule_delivery_time, but the SMSC delivers immediately it is an issue on their side. Rene Kluwen Chimit -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Alejandro Guerrieri Sent: donderdag 22 juni 2006 5:34 To: users@kannel.org Subject: Re: deferred parameters Yep, I think that's how it should be... I've made a few more tests with increasing deferred values (0, 1, 60 and 600), here are the results: deferred=0 - 2006-06-21 23:19:59 - 060622021959000+ deferred=1 - 2006-06-21 23:20:07 - 060622022107000+ deferred=60 - 2006-06-21 23:20:11 - 060622032011000+ deferred=600 - 2006-06-21 23:20:19 - 060622122019000+ So now the difference are now consistent with 3:00, 3:01, 4:00 and 13:00 Hours difference (which makes sense with the GMT -3 Timezone. Maybe my former message was sent with deferred=60 ant that's why it showed a 4-hour difference and 3:01 :P ). Anyway, the messages are being delivered right after submital, no matter what I put on the deferred parameter. I've checked SMPP 3.4 and it says as follows: == 5.2.15 schedule_delivery_time This parameter specifies the scheduled time at which the message delivery should be first attempted. It defines either the absolute date and time or relative time from the current SMSC time at which delivery of this message will be attempted by the SMSC. It can be specified in either absolute time format or relative time format. The encoding of a time format is specified in Section 7.1.1. And 7.1.1 says: 7.1.1 Time Format In this interface, all time/date related fields will be in ASCII with the following format: YYMMDDhhmmsstnnp where 'YY' last two digits of the year (00-99) 'MM' month (01-12) 'DD' day (01-31) 'hh' hour (00-23) 'mm' minute (00-59) 'ss' second (00-59) 't' tenths of second (0-9) 'nn' Time difference in quarter hours between local time (as expressed in the first 13 octets) and UTC (Universal Time Constant) time (00-48). 'p' - + Local time is in quarter hours advanced in relation to UTC time. - Local time is in quarter hours retarded in relation to UTC time. R Local time is relative to the current SMSC time. Note: Where responses are reported by the SMSC the local time of the SMSC will be given, and the format will be YYMMDDhhmmss, with the same definitions as above. = So Kannel obviously translates the times to UTC and send that to the SMSC. Even with an offset hanging around, it's a positive delay so should have worsen the referral, and if not, the deferred=600 (10 hours) should have worked isn't it? It doesn't make sense, unless the SMSC it's ignoring the parameter... I'll make some more tests over other links tomorrow and see if I can find some pattern. Please let me know if anybody figures out where the problem could be. TIA Alejandro. On 6/21/06, Rene Kluwen [EMAIL PROTECTED] wrote: What is your scheduled_delivery_time if you set deferred to a higher value? In this case, the immediate delivery is correct, from a point of view of your SMSC. Because you submit the message at 19:48:07 (Argentina time) and the message should be delivered at 23:48:07 (UTC time). These times are identical. In smsbox.c the msg-sms.deferred field is copied directly from the http parameter. The following code translates this field into the pdu-u.submit_sm.schedule_delivery_time: if (msg-sms.deferred = 0) { 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); } As far as I can see, this is correct. Still there should be some kind of bug here, because if the log that you show is a pdu from posting the link that is just above the log, the schedule_delivery_time should be 060621234907000+ (note the 8 that is now a 9). Rene Kluwen Chimit -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Rene Kluwen Sent: donderdag 22 juni 2006 2:14 To: Alejandro Guerrieri; users@kannel.org Subject: RE: deferred parameters SMPP: 7.1.1.1 Absolute Time format This is the default format used by SMPP. Scheduled delivery times and expiry times are specified in their global UTC format, including the quarter hour offset and direction symbol + or -. Rene Kluwen Chimit -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Alejandro Guerrieri Sent: donderdag 22 juni 2006 1:04 To: users@kannel.org Subject: Re: deferred parameters I've upgraded Kannel to latest CVS release
Re: deferred parameters
I've upgraded Kannel to latest CVS release, 20060621 and I still can't defer the messages. I've tried with a simple message: http://myhost:myport/cgi-bin/sendsms?username=myuserpassword=mypassfrom=1234to=1234567890smsc=mysmsctext=testdeferred=1 But the message gets delivery inmediately. Here's a copy of kannel.log where the PDU is being logged: 2006-06-21 19:48:07 [20158] [48] DEBUG: SMPP PDU 0x8841750 dump: 2006-06-21 19:48:07 [20158] [48] DEBUG: type_name: submit_sm 2006-06-21 19:48:07 [20158] [48] DEBUG: command_id: 4 = 0x0004 2006-06-21 19:48:07 [20158] [48] DEBUG: command_status: 0 = 0x 2006-06-21 19:48:07 [20158] [48] DEBUG: sequence_number: 2 = 0x0002 2006-06-21 19:48:07 [20158] [48] DEBUG: service_type: NULL 2006-06-21 19:48:07 [20158] [48] DEBUG: source_addr_ton: 2 = 0x0002 2006-06-21 19:48:07 [20158] [48] DEBUG: source_addr_npi: 1 = 0x0001 2006-06-21 19:48:07 [20158] [48] DEBUG: source_addr: * 2006-06-21 19:48:07 [20158] [48] DEBUG: dest_addr_ton: 2 = 0x0002 2006-06-21 19:48:07 [20158] [48] DEBUG: dest_addr_npi: 1 = 0x0001 2006-06-21 19:48:07 [20158] [48] DEBUG: destination_addr: 2006-06-21 19:48:07 [20158] [48] DEBUG: esm_class: 0 = 0x 2006-06-21 19:48:07 [20158] [48] DEBUG: protocol_id: 0 = 0x 2006-06-21 19:48:07 [20158] [48] DEBUG: priority_flag: 0 = 0x 2006-06-21 19:48:07 [20158] [48] DEBUG: schedule_delivery_time: 060621234807000+ 2006-06-21 19:48:07 [20158] [48] DEBUG: validity_period: NULL 2006-06-21 19:48:07 [20158] [48] DEBUG: registered_delivery: 0 = 0x 2006-06-21 19:48:07 [20158] [48] DEBUG: replace_if_present_flag: 0 = 0x 2006-06-21 19:48:07 [20158] [48] DEBUG: data_coding: 0 = 0x 2006-06-21 19:48:07 [20158] [48] DEBUG: sm_default_msg_id: 0 = 0x 2006-06-21 19:48:07 [20158] [48] DEBUG: sm_length: 4 = 0x0004 2006-06-21 19:48:07 [20158] [48] DEBUG: short_message: test 2006-06-21 19:48:07 [20158] [48] DEBUG: SMPP PDU dump ends. I can see there's a line: schedule_delivery_time: 060621234807000+ It looks like it's GMT +1 time, but the date it's not being offsetted at all (19:48:07 gets translated to 23:48:07 +000). BTW, the server is set to America/Buenos_Aires timezone (GMT -3) so I'm not sure if that's ok or not... I've tried with deferred=1, 60, 6000 and even 6 to no avail, the messages got delivered inmediately. (I even tried with negative values, but I've got an error in return). Maybe the SMSC it's ignoring the parameter, or schedule_delivery_time it's wrong? Regards, -- Alejandro Guerrieri Magicom http://www.magicom-bcn.net/ LinkedIn: http://www.linkedin.com/in/aguerrieri On 6/21/06, Alejandro Guerrieri [EMAIL PROTECTED] wrote: Martín, I've read the user-guide (a few thousand times perhaps ;) ) and noticed the ? on the SMPP protocol. That lead me to think that it wasn't tested. My unsuccesful trying didn't help... It was an 1.4.0 at the time of testing. I'll do a new round of tests this week with a new snapshot, maybe it's now fixed (or the SMSC it's ignoring the parameter...). Regards, On 6/21/06, Mi Reflejo [EMAIL PROTECTED] wrote: Yes it's tested and used. Take a look to cvs user guide (http://www.kannel.org/download/kannel-userguide-snapshot/userguide.html) deferrednumber (minutes) Optional. If given, the SMS center will postpone the message to be delivered at now plus this many minutes. Note: you must have your Kannel box time synchronized with the SMS Center. Which version of kannel are you using? If you are using cvs head please post the smpp trace. if not please upgrade to head. Martín. On 6/21/06, Alejandro Guerrieri [EMAIL PROTECTED] wrote: Hi all, Has anyone tried using the deferred parameter with an SMPP link? User-Guide puts a question mark on it, so I assume that means not tested. I've tried with some SMPP links we have without success: the messages get delivered without any delay, blatantly ignoring the deferred parameter setting. Is that a problem related to Kannel, the SMPP protocol or just the SMSC ignoring it? On the other hand, specially if this is something related to protocols, it would be cool to have some sort of soft-deferring, meaning Kannel doing the deferral (on the store-file perhaps). This would work on all kind of links ('at' modems included) since Kannel would be keeping the messages until delivery time. Thank you in advance, -- Alejandro Guerrieri Magicom http://www.magicom-bcn.net/ LinkedIn: http://www.linkedin.com/in/aguerrieri -- Alejandro Guerrieri Magicom http://www.magicom-bcn.net/ LinkedIn: http://www.linkedin.com/in/aguerrieri
RE: deferred parameters
SMPP: 7.1.1.1 Absolute Time format This is the default format used by SMPP. Scheduled delivery times and expiry times are specified in their global UTC format, including the quarter hour offset and direction symbol + or -. Rene Kluwen Chimit -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Alejandro Guerrieri Sent: donderdag 22 juni 2006 1:04 To: users@kannel.org Subject: Re: deferred parameters I've upgraded Kannel to latest CVS release, 20060621 and I still can't defer the messages. I've tried with a simple message: http://myhost:myport/cgi-bin/sendsms?username=myuserpassword=mypassfrom=12 34to=1234567890smsc=mysmsctext=testdeferred=1 But the message gets delivery inmediately. Here's a copy of kannel.log where the PDU is being logged: 2006-06-21 19:48:07 [20158] [48] DEBUG: SMPP PDU 0x8841750 dump: 2006-06-21 19:48:07 [20158] [48] DEBUG: type_name: submit_sm 2006-06-21 19:48:07 [20158] [48] DEBUG: command_id: 4 = 0x0004 2006-06-21 19:48:07 [20158] [48] DEBUG: command_status: 0 = 0x 2006-06-21 19:48:07 [20158] [48] DEBUG: sequence_number: 2 = 0x0002 2006-06-21 19:48:07 [20158] [48] DEBUG: service_type: NULL 2006-06-21 19:48:07 [20158] [48] DEBUG: source_addr_ton: 2 = 0x0002 2006-06-21 19:48:07 [20158] [48] DEBUG: source_addr_npi: 1 = 0x0001 2006-06-21 19:48:07 [20158] [48] DEBUG: source_addr: * 2006-06-21 19:48:07 [20158] [48] DEBUG: dest_addr_ton: 2 = 0x0002 2006-06-21 19:48:07 [20158] [48] DEBUG: dest_addr_npi: 1 = 0x0001 2006-06-21 19:48:07 [20158] [48] DEBUG: destination_addr: 2006-06-21 19:48:07 [20158] [48] DEBUG: esm_class: 0 = 0x 2006-06-21 19:48:07 [20158] [48] DEBUG: protocol_id: 0 = 0x 2006-06-21 19:48:07 [20158] [48] DEBUG: priority_flag: 0 = 0x 2006-06-21 19:48:07 [20158] [48] DEBUG: schedule_delivery_time: 060621234807000+ 2006-06-21 19:48:07 [20158] [48] DEBUG: validity_period: NULL 2006-06-21 19:48:07 [20158] [48] DEBUG: registered_delivery: 0 = 0x 2006-06-21 19:48:07 [20158] [48] DEBUG: replace_if_present_flag: 0 = 0x 2006-06-21 19:48:07 [20158] [48] DEBUG: data_coding: 0 = 0x 2006-06-21 19:48:07 [20158] [48] DEBUG: sm_default_msg_id: 0 = 0x 2006-06-21 19:48:07 [20158] [48] DEBUG: sm_length: 4 = 0x0004 2006-06-21 19:48:07 [20158] [48] DEBUG: short_message: test 2006-06-21 19:48:07 [20158] [48] DEBUG: SMPP PDU dump ends. I can see there's a line: schedule_delivery_time: 060621234807000+ It looks like it's GMT +1 time, but the date it's not being offsetted at all (19:48:07 gets translated to 23:48:07 +000). BTW, the server is set to America/Buenos_Aires timezone (GMT -3) so I'm not sure if that's ok or not... I've tried with deferred=1, 60, 6000 and even 6 to no avail, the messages got delivered inmediately. (I even tried with negative values, but I've got an error in return). Maybe the SMSC it's ignoring the parameter, or schedule_delivery_time it's wrong? Regards, -- Alejandro Guerrieri Magicom http://www.magicom-bcn.net/ LinkedIn: http://www.linkedin.com/in/aguerrieri On 6/21/06, Alejandro Guerrieri [EMAIL PROTECTED] wrote: Martín, I've read the user-guide (a few thousand times perhaps ;) ) and noticed the ? on the SMPP protocol. That lead me to think that it wasn't tested. My unsuccesful trying didn't help... It was an 1.4.0 at the time of testing. I'll do a new round of tests this week with a new snapshot, maybe it's now fixed (or the SMSC it's ignoring the parameter...). Regards, On 6/21/06, Mi Reflejo [EMAIL PROTECTED] wrote: Yes it's tested and used. Take a look to cvs user guide (http://www.kannel.org/download/kannel-userguide-snapshot/userguide.html) deferrednumber (minutes) Optional. If given, the SMS center will postpone the message to be delivered at now plus this many minutes. Note: you must have your Kannel box time synchronized with the SMS Center. Which version of kannel are you using? If you are using cvs head please post the smpp trace. if not please upgrade to head. Martín. On 6/21/06, Alejandro Guerrieri [EMAIL PROTECTED] wrote: Hi all, Has anyone tried using the deferred parameter with an SMPP link? User-Guide puts a question mark on it, so I assume that means not tested. I've tried with some SMPP links we have without success: the messages get delivered without any delay, blatantly ignoring the deferred parameter setting. Is that a problem related to Kannel, the SMPP protocol or just the SMSC ignoring it? On the other hand, specially if this is something related to protocols, it would be cool to have some sort of soft-deferring, meaning Kannel doing the deferral (on the store-file perhaps). This would work on all kind of links ('at' modems included) since Kannel would be keeping the messages until delivery time. Thank you in advance
RE: deferred parameters
What is your scheduled_delivery_time if you set deferred to a higher value? In this case, the immediate delivery is correct, from a point of view of your SMSC. Because you submit the message at 19:48:07 (Argentina time) and the message should be delivered at 23:48:07 (UTC time). These times are identical. In smsbox.c the msg-sms.deferred field is copied directly from the http parameter. The following code translates this field into the pdu-u.submit_sm.schedule_delivery_time: if (msg-sms.deferred = 0) { 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); } As far as I can see, this is correct. Still there should be some kind of bug here, because if the log that you show is a pdu from posting the link that is just above the log, the schedule_delivery_time should be 060621234907000+ (note the 8 that is now a 9). Rene Kluwen Chimit -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Rene Kluwen Sent: donderdag 22 juni 2006 2:14 To: Alejandro Guerrieri; users@kannel.org Subject: RE: deferred parameters SMPP: 7.1.1.1 Absolute Time format This is the default format used by SMPP. Scheduled delivery times and expiry times are specified in their global UTC format, including the quarter hour offset and direction symbol + or -. Rene Kluwen Chimit -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Alejandro Guerrieri Sent: donderdag 22 juni 2006 1:04 To: users@kannel.org Subject: Re: deferred parameters I've upgraded Kannel to latest CVS release, 20060621 and I still can't defer the messages. I've tried with a simple message: http://myhost:myport/cgi-bin/sendsms?username=myuserpassword=mypassfrom=12 34to=1234567890smsc=mysmsctext=testdeferred=1 But the message gets delivery inmediately. Here's a copy of kannel.log where the PDU is being logged: 2006-06-21 19:48:07 [20158] [48] DEBUG: SMPP PDU 0x8841750 dump: 2006-06-21 19:48:07 [20158] [48] DEBUG: type_name: submit_sm 2006-06-21 19:48:07 [20158] [48] DEBUG: command_id: 4 = 0x0004 2006-06-21 19:48:07 [20158] [48] DEBUG: command_status: 0 = 0x 2006-06-21 19:48:07 [20158] [48] DEBUG: sequence_number: 2 = 0x0002 2006-06-21 19:48:07 [20158] [48] DEBUG: service_type: NULL 2006-06-21 19:48:07 [20158] [48] DEBUG: source_addr_ton: 2 = 0x0002 2006-06-21 19:48:07 [20158] [48] DEBUG: source_addr_npi: 1 = 0x0001 2006-06-21 19:48:07 [20158] [48] DEBUG: source_addr: * 2006-06-21 19:48:07 [20158] [48] DEBUG: dest_addr_ton: 2 = 0x0002 2006-06-21 19:48:07 [20158] [48] DEBUG: dest_addr_npi: 1 = 0x0001 2006-06-21 19:48:07 [20158] [48] DEBUG: destination_addr: 2006-06-21 19:48:07 [20158] [48] DEBUG: esm_class: 0 = 0x 2006-06-21 19:48:07 [20158] [48] DEBUG: protocol_id: 0 = 0x 2006-06-21 19:48:07 [20158] [48] DEBUG: priority_flag: 0 = 0x 2006-06-21 19:48:07 [20158] [48] DEBUG: schedule_delivery_time: 060621234807000+ 2006-06-21 19:48:07 [20158] [48] DEBUG: validity_period: NULL 2006-06-21 19:48:07 [20158] [48] DEBUG: registered_delivery: 0 = 0x 2006-06-21 19:48:07 [20158] [48] DEBUG: replace_if_present_flag: 0 = 0x 2006-06-21 19:48:07 [20158] [48] DEBUG: data_coding: 0 = 0x 2006-06-21 19:48:07 [20158] [48] DEBUG: sm_default_msg_id: 0 = 0x 2006-06-21 19:48:07 [20158] [48] DEBUG: sm_length: 4 = 0x0004 2006-06-21 19:48:07 [20158] [48] DEBUG: short_message: test 2006-06-21 19:48:07 [20158] [48] DEBUG: SMPP PDU dump ends. I can see there's a line: schedule_delivery_time: 060621234807000+ It looks like it's GMT +1 time, but the date it's not being offsetted at all (19:48:07 gets translated to 23:48:07 +000). BTW, the server is set to America/Buenos_Aires timezone (GMT -3) so I'm not sure if that's ok or not... I've tried with deferred=1, 60, 6000 and even 6 to no avail, the messages got delivered inmediately. (I even tried with negative values, but I've got an error in return). Maybe the SMSC it's ignoring the parameter, or schedule_delivery_time it's wrong? Regards, -- Alejandro Guerrieri Magicom http://www.magicom-bcn.net/ LinkedIn: http://www.linkedin.com/in/aguerrieri On 6/21/06, Alejandro Guerrieri [EMAIL PROTECTED] wrote: Martín, I've read the user-guide (a few thousand times perhaps ;) ) and noticed the ? on the SMPP protocol. That lead me to think that it wasn't tested. My unsuccesful trying didn't help... It was an 1.4.0 at the time of testing. I'll do a new round of tests this week with a new snapshot, maybe it's now fixed (or the SMSC it's ignoring the parameter...). Regards, On 6/21/06, Mi Reflejo [EMAIL PROTECTED] wrote: Yes it's tested and used. Take a look to cvs user guide (http
Re: deferred parameters
Yep, I think that's how it should be... I've made a few more tests with increasing deferred values (0, 1, 60 and 600), here are the results: deferred=0 - 2006-06-21 23:19:59 - 060622021959000+ deferred=1 - 2006-06-21 23:20:07 - 060622022107000+ deferred=60 - 2006-06-21 23:20:11 - 060622032011000+ deferred=600 - 2006-06-21 23:20:19 - 060622122019000+ So now the difference are now consistent with 3:00, 3:01, 4:00 and 13:00 Hours difference (which makes sense with the GMT -3 Timezone. Maybe my former message was sent with deferred=60 ant that's why it showed a 4-hour difference and 3:01 :P ). Anyway, the messages are being delivered right after submital, no matter what I put on the deferred parameter. I've checked SMPP 3.4 and it says as follows: == 5.2.15 schedule_delivery_time This parameter specifies the scheduled time at which the message delivery should be first attempted. It defines either the absolute date and time or relative time from the current SMSC time at which delivery of this message will be attempted by the SMSC. It can be specified in either absolute time format or relative time format. The encoding of a time format is specified in Section 7.1.1. And 7.1.1 says: 7.1.1 Time Format In this interface, all time/date related fields will be in ASCII with the following format: YYMMDDhhmmsstnnp where 'YY' last two digits of the year (00-99) 'MM' month (01-12) 'DD' day (01-31) 'hh' hour (00-23) 'mm' minute (00-59) 'ss' second (00-59) 't' tenths of second (0-9) 'nn' Time difference in quarter hours between local time (as expressed in the first 13 octets) and UTC (Universal Time Constant) time (00-48). 'p' - + Local time is in quarter hours advanced in relation to UTC time. - Local time is in quarter hours retarded in relation to UTC time. R Local time is relative to the current SMSC time. Note: Where responses are reported by the SMSC the local time of the SMSC will be given, and the format will be YYMMDDhhmmss, with the same definitions as above. = So Kannel obviously translates the times to UTC and send that to the SMSC. Even with an offset hanging around, it's a positive delay so should have worsen the referral, and if not, the deferred=600 (10 hours) should have worked isn't it? It doesn't make sense, unless the SMSC it's ignoring the parameter... I'll make some more tests over other links tomorrow and see if I can find some pattern. Please let me know if anybody figures out where the problem could be. TIA Alejandro. On 6/21/06, Rene Kluwen [EMAIL PROTECTED] wrote: What is your scheduled_delivery_time if you set deferred to a higher value? In this case, the immediate delivery is correct, from a point of view of your SMSC. Because you submit the message at 19:48:07 (Argentina time) and the message should be delivered at 23:48:07 (UTC time). These times are identical. In smsbox.c the msg-sms.deferred field is copied directly from the http parameter. The following code translates this field into the pdu-u.submit_sm.schedule_delivery_time: if (msg-sms.deferred = 0) { 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); } As far as I can see, this is correct. Still there should be some kind of bug here, because if the log that you show is a pdu from posting the link that is just above the log, the schedule_delivery_time should be 060621234907000+ (note the 8 that is now a 9). Rene Kluwen Chimit -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Rene Kluwen Sent: donderdag 22 juni 2006 2:14 To: Alejandro Guerrieri; users@kannel.org Subject: RE: deferred parameters SMPP: 7.1.1.1 Absolute Time format This is the default format used by SMPP. Scheduled delivery times and expiry times are specified in their global UTC format, including the quarter hour offset and direction symbol + or -. Rene Kluwen Chimit -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Alejandro Guerrieri Sent: donderdag 22 juni 2006 1:04 To: users@kannel.org Subject: Re: deferred parameters I've upgraded Kannel to latest CVS release, 20060621 and I still can't defer the messages. I've tried with a simple message: http://myhost:myport/cgi-bin/sendsms?username=myuserpassword=mypassfrom=12 34to=1234567890smsc=mysmsctext=testdeferred=1 But the message gets delivery inmediately. Here's a copy of kannel.log where the PDU is being logged: 2006-06-21 19:48:07 [20158] [48] DEBUG: SMPP PDU 0x8841750 dump: 2006-06-21 19:48:07 [20158] [48] DEBUG: type_name: submit_sm 2006-06-21 19:48:07 [20158] [48] DEBUG: command_id: 4 = 0x0004 2006-06-21 19:48:07 [20158] [48] DEBUG: command_status: 0 = 0x 2006-06-21 19:48:07 [20158] [48] DEBUG: sequence_number: 2 = 0x0002 2006-06-21 19:48:07 [20158] [48
Re: deferred parameters
Martín, I've read the user-guide (a few thousand times perhaps ;) ) and noticed the ? on the SMPP protocol. That lead me to think that it wasn't tested. My unsuccesful trying didn't help... It was an 1.4.0 at the time of testing. I'll do a new round of tests this week with a new snapshot, maybe it's now fixed (or the SMSC it's ignoring the parameter...). Regards, On 6/21/06, Mi Reflejo [EMAIL PROTECTED] wrote: Yes it's tested and used. Take a look to cvs user guide (http://www.kannel.org/download/kannel-userguide-snapshot/userguide.html) deferrednumber (minutes) Optional. If given, the SMS center will postpone the message to be delivered at now plus this many minutes. Note: you must have your Kannel box time synchronized with the SMS Center. Which version of kannel are you using? If you are using cvs head please post the smpp trace. if not please upgrade to head. Martín. On 6/21/06, Alejandro Guerrieri [EMAIL PROTECTED] wrote: Hi all, Has anyone tried using the deferred parameter with an SMPP link? User-Guide puts a question mark on it, so I assume that means not tested. I've tried with some SMPP links we have without success: the messages get delivered without any delay, blatantly ignoring the deferred parameter setting. Is that a problem related to Kannel, the SMPP protocol or just the SMSC ignoring it? On the other hand, specially if this is something related to protocols, it would be cool to have some sort of soft-deferring, meaning Kannel doing the deferral (on the store-file perhaps). This would work on all kind of links ('at' modems included) since Kannel would be keeping the messages until delivery time. Thank you in advance, -- Alejandro Guerrieri Magicom http://www.magicom-bcn.net/ LinkedIn: http://www.linkedin.com/in/aguerrieri -- Alejandro Guerrieri Magicom http://www.magicom-bcn.net/ LinkedIn: http://www.linkedin.com/in/aguerrieri