Hi Alejandro,
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.
Yes, this appears to be the behaviour currently.
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?
From the perspective of someone implementing an application that sits on
top of kannel, certainly the desired behaviour is that multipart messages
should just behave like single part messages, which is how it operates
now.
The only problem is that if the first part gets delivered, and subsequent
parts do not get delivered, and the SMSc behaves in such a way that they
treat each individual message part as it's own identity that should either
receive a DLR or not based on the registered_delivery parameter, that we
could get the impression that a multipart message has been successfully
delivered when in fact delivery of all parts except the initial message
failed.
One course of action that occurs to me as viable at least where mysql is
being used as DLR storage, is that you have 2 tables: 1 for message and
one for message part. The dlr-url is stored in the message table, and
these have a 1-to-many relationship.
The DLRs received from the SMSc should operate on the message_part table.
Once all message parts are marked as finalised the dlr-url is hit. If any
part of the message failed the status should be FAIL (alternatively we
could include a new status PARTIAL FAIL).
This seems desirable to me because otherwise you're at the mercy of the
SMSc behaving sensibly which will not always be the case.
Cheers,
Iain
Alejandro
On Fri, Jun 12, 2009 at 7:28 AM, Iain Dooley <i...@workingsoftware.com.au>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
