registered_delivery gets set to nonzero when dlr-mask and dlr-url are present. Assuming that you're in fact setting those parameters, I see your point. I'm not sure what the regular behaviour should be, when a message is being split by kannel?
Let's analyze the facts further: I assume the behaviour now is only to set registered_delivery = 1 on the first part of the split message, and subsequent parts get set to zero. This causes kannel to only care about the first part of the message regarding dlrs. On the other hand, if all parts go as registered_delivery = 1, a dlr entry for all those parts would be needed (to match the incoming dlr later). Those dlr entries would share the same dlr-url, thus causing kannel to hit the same url again and again with confusing results (e.g., a "delivered" entry after a permanent "failed" on the same "id"). So, a possible solution would be to modify kannel to handle two extra parameters on the dlr-url: * part number * number of parts That way, the dlr-url's would have different part numbers (and you would know how many parts to expect), so your application layer would know where a message was completely delivered. I can think of an alternate approach where kannel holds hitting the dlr-url until all parts have arrived, but since there's so many possible intermediate statuses (that could happen on each separate parta at the same time) and the process itself it's asynchronous by nature... I don't see it like a viable solution. Opinions? Alejandro On Fri, Jun 12, 2009 at 7:28 AM, Iain Dooley <[email protected]>wrote: > hi all, i received some clarification back from the carrier: it was only > the first of a multipart message that got registered_delivery = 1, then any > subsequent parts of the multipart message had registered_delivery = 0. this > seems pretty sensible seeing as, from my perspective, a concatenated message > is really only 1 message. > > cheers > iain > >
