Hi, I don't think it makes much sense to have individual verification for each part. The SMSc should respond with OK if message succesfully assembled and delivered as a whole; else if any part fails, failure. After all, if any part fails, correct behaviour would be to resend the whole SMS.
Additionally, if part verification was enabled, then the sender would have the extra burden to mix and match different DLR parts, to see if the message was sent. I believe that it is the SMSc's responsibility to resend individual parts that failed in the final step, provided it has received the whole message succesfully. BR, Nikos ----- Original Message ----- From: Alejandro Guerrieri To: Iain Dooley Cc: [email protected] Sent: Friday, June 12, 2009 9:08 AM Subject: Re: registered_delivery - clarification 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
