I should add to my last email that I think that all messages (even single
part messages) should have entries in both message and message_part; ie.
the system treats a single part message as a special kind of multipart
message rather than the other way around.
cheers
iain
On Fri, 12 Jun 2009, Alejandro Guerrieri wrote:
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
