Hello All,
I've been looking at the SMPP 3.4 schedule_delivery_time and
validity_period implimentation in kannel by dumping the submit_sm pdu's
and comparing against tcpdump's and specs. Emabling full (pdu) debugging
gives ...
...
...52:22 [5] DEBUG: schedule_delivery_time: "0206251653220048"
...52:22 [5] DEBUG: validity_period: "0206251653220048"
Where as the SMPP 3.4 spec by definition require times to be in the
format ...YYMMDDhhmmsstnnp. Extra debugging provides my gwqdiff as 48 so
as you can see from this that the tnnp part looks out of line
The culprit is an extra '0' in the buffer creation (see patch). The
result ...
...
...37:25 [5] DEBUG: schedule_delivery_time: "020625184725048+"
...37:25 [5] DEBUG: validity_period: "020625183825048+"
I'm still testing smsc's capability (at time of writing smsc is ignoring
deferred timing - although this may be a server clock issue) however the
enclosed patch is required regardless I believe.
Cheers,
Alan
Index: gw/smsc_smpp.c
===================================================================
RCS file: /home/cvs/gateway/gw/smsc_smpp.c,v
retrieving revision 1.71
diff -r1.71 smsc_smpp.c
339c339
< buffer = octstr_format("%02d%02d%02d%02d%02d%02d0%01d%02d%1s",
---
> buffer = octstr_format("%02d%02d%02d%02d%02d%02d%01d%02d%1s",
349c349
< buffer = octstr_format("%02d%02d%02d%02d%02d%02d0%01d%02d%1s",
---
> buffer = octstr_format("%02d%02d%02d%02d%02d%02d%01d%02d%1s",
