Hi list.
Wanted to ask your opinion about how we should handle DLRs on a message that get split to multiple concatenated messages. Currently - the dlr_url is only saved for the first message, so the originator will only receive a single DLR on the first part of the message. while this is an obvious temporary work around, I don't think its a correct solution. My suggestion is to do something like this - since the message ids on all parts are identical, we can track and collate them anywhere in the boxes. since it's DLR related we'll let the DLR module handle that: - rewrite the DLR entry routines to accept the entire message structure and a module created ID - a key actually - that identifies the network's notion of the current message part : the message reference returned from the SMSC on submit, instead of the current implementation where numerous fields are required. this will allow the DLR routines to access and archive more information from the message structure, such as the message's internal reference id. - the DLR routines will collate messages that have the same internal reference id, of course tracking each parts 'external reference id'. - add another delivery report type that says something like "all parts of a concatenated message have been successfully delivered". - when a part of a concatenated message get a non-permanent delivery report notification from a module (using dlr_find), or a success delivery report, the correct delivery report is created - as it is done now. - when all parts of a concatenated message receives the "success" notification, the DLR message generated will contain the normal DLR_SUCCESS flag set and also the new DLR_MULTI_MESSAGE_COMPLETED flag set (temporary name - just a suggestion). - when a single part of a concatenated message receives a permanent failure notification (DLR_FAILED or DLR_SMSC_FAILED), dlr_find will generate the required notification, and also discard the entire collection of message parts from DLR storage, effectively invalidating any future success reports that might arrive for other parts. in addition, it would be nice if the dlr routines could garbage collect old DLR records that can be safely assumed "lost" and either just remove them from the DLR database optionally also delivering them somehow with the DLR_SMSC_FAILED flag set. I'd say that 2 days is a good time limit. Comments, please ? -- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9581711 (116) +972-67-340014 ::.. Instructions for life: 8. Spend some time alone every day.
