So I understand, that we don't have place for those protocols to put our
unique ID in, when we submit SMS. for SMPP we have message ID, that comes
from SMSC and unusable for unique ID sub (size 3 octets, decimal string).
The same problem for other protocols?
Maybe I am wrong, but I think it is disadvantage of protocol. For my "local
protocols", that I make, I always use some extra field for unique Id or
description or whatever, that in this case must be made by SMS sender
(kannel) and sent back from SMSC with every delivery report.
But I am only beginner and maybe I don't understand... :) And I can not make
patches in C too :(
Ivars
-----Original Message-----
Message: 3
Date: Thu, 02 Sep 2004 13:41:49 +0200
From: Alexander Malysh <[EMAIL PROTECTED]>
Subject: Re: kannel 1.3.2 - kannel confounds DLRs - how can i make
sure that i get the correct dlr-status for sms?
To: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=us-ascii
Ivars Jukams wrote:
> ------------------------------
> Why couldn't we ? it's just a question of inserting the DLR /before
> /sending, looking at the last inserted ID and use it instead of the
> couple timestamp / smsc ...
> ------------------------------
>
> Of course, there is no problem, maybe with making the patch, but I
> don't believe so. There can be such sending process:
> 1) comes request to send SMS;
> 2) write info in to DB about SMS to be sent (with status 'not sent');
> 3) get autoincrement ID (mysql returns it automaticly);
> 4) try to send SMS and use this autoincrement ID instead of timestamp;
> 5) after sending change status to 'waiting for SMSC' response or 'not
> sent' if it crashes in kannel because of any reason;
> 6) after receiving a status message from SMSC do the same process like it
> is now, only use this unque ID to find right message.
from where will you receive this unique id? from smsc you will get _only_
timestamp in case for EMI and msg-id for smpp...
> One more advice - not simply delete records from dlr table, but 'move'
> them to dlr_archieve (the same structure as dlr, only ID is not
> autoincrement) - so we would not lose info about sent messages. copy
> means: insert into dlr_archieve...select...from dlr... and then:
> delete... (i can write queries for MySQL, but not for other dlr DB
> types)
>
> So - some more queries, but with autoincrement ID it will work faster
> anyway.
send us patch we will see ;)
>
> Sorry for my english :)
not a problem so far ;)
>
> Ivars
--
Thanks,
Alex
