Question is: 1. Are you 100% certain that all SMSC's behave like that? I mean: they send the dlr's deliver_sm only after receiving all parts?
2. Even then, what difference would it make if the registered_delivery on subsequent parts is set to 1 instead of 0? I'm not sure what the proper behavior should be, each approach has its caveats. Regards, Alejandro 2009/6/12 Nikos Balkanas <[email protected]> > 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 <[email protected]> > *To:* Iain Dooley <[email protected]> > *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 >> >> >
