Okay, I just proved myself wrong as well. Looking more closely in dlr.c, it seems that "ts" is replaced with the original foreign id from the first message:
if (msg->sms.foreign_id != NULL) octstr_destroy(msg->sms.foreign_id); msg->sms.foreign_id = octstr_duplicate(ts); if (msg->sms.split_parts != NULL) { struct split_parts *split = msg->sms.split_parts; if (split->orig->sms.foreign_id != NULL) octstr_destroy(split->orig->sms.foreign_id); split->orig->sms.foreign_id = octstr_duplicate(ts); } Now what happens is that you only receive intermediate dlr's multiple times. After reaching a final state, dlr-url is called and after that the DLR is deleted from the dlr store. So consequtive dlr's won't be found in the store and generate a warning message. == Rene -----Original Message----- From: users-boun...@kannel.org [mailto:users-boun...@kannel.org] On Behalf Of Rene Kluwen Sent: Wednesday, 15 September, 2010 19:00 To: 'Nikos Balkanas'; 'Alejandro Guerrieri' Cc: users@kannel.org Subject: RE: registered_delivery and multi-parts message Actually I am pretty sure now that I am right and you are wrong. Look here at some code from smsc_smpp.c: Octstr *tmp; /* check if msg_id is C string, decimal or hex for this SMSC */ if (smpp->smpp_msg_id_type == -1) { /* the default, C string */ tmp = octstr_duplicate(pdu->u.submit_sm_resp.message_id); } else { if ((smpp->smpp_msg_id_type & 0x01) || (!octstr_check_range(pdu->u.submit_sm_resp.message_id, 0, octstr_len(pdu->u.submit_sm_resp.message_id), gw_isdigit))) { tmp = octstr_format("%llu", strtoll( /* hex */ octstr_get_cstr(pdu->u.submit_sm_resp.message_id), NULL, 16)); } else { tmp = octstr_format("%llu", strtoll( /* decimal */ octstr_get_cstr(pdu->u.submit_sm_resp.message_id), NULL, 10)); } } /* SMSC ACK.. now we have the message id. */ if (DLR_IS_ENABLED_DEVICE(msg->sms.dlr_mask)) dlr_add(smpp->conn->id, tmp, msg); -----Original Message----- From: Nikos Balkanas [mailto:nbalka...@gmail.com] Sent: Wednesday, 15 September, 2010 18:36 To: Rene Kluwen; 'Alejandro Guerrieri' Cc: 'Ivan Kurnosov'; users@kannel.org Subject: Re: registered_delivery and multi-parts message You don't remember well. The submit_sm_resp contains the SMSc messageid, aka forreign ID, different one for each submit_sm_resp for each part. Therefore there would be a different dlr_entry for each part. BR, Nikos ----- Original Message ----- From: Rene Kluwen To: 'Alejandro Guerrieri' ; 'Nikos Balkanas' Cc: 'Ivan Kurnosov' ; users@kannel.org Sent: Wednesday, September 15, 2010 7:25 PM Subject: RE: registered_delivery and multi-parts message As far as I recall, the timestamp field in the DLR table is set to the submit_resp message id. But it has been a while since I've looked at the code. So I may be wrong. Conclusion: It will only find one DLR entry and the other ones won't be found. == Rene From: Alejandro Guerrieri [mailto:alejandro.guerri...@gmail.com] Sent: Wednesday, 15 September, 2010 18:21 To: Nikos Balkanas Cc: Rene Kluwen; Ivan Kurnosov; users@kannel.org Subject: Re: registered_delivery and multi-parts message You're wrong. When you queue the message, you specify the dlr-url to use. If kannel splits the message into 3 segments, and you modify kannel to ask for DLR's on the 3 of them, you'll get the same dlr-url called 3 times. If you set dlr-url=http://my.host.com/dlr.php?id=1234, it will be called 3 TIMES with "1234". Only"dynamic" elements like the timestamp or any other thing that could change between parts would change, but your "id" would continue to be 1234. Good luck dealing with it on your DLR handling application... Regards, Alex 2010/9/15 Nikos Balkanas <nbalka...@gmail.com> Actually, it won't complain. Each received submit_sm_resp will generate a separate dlr_entry, one for each part. When the respective DLRs arrive they will be correctly matched and call a different dlr_url in smsbox one for each part, as correctly pointed out by Alex. smpp->sent_msgs is matched since it is filled after sms is split by bearerbox. BR, Nikos ----- Original Message ----- From: "Rene Kluwen" <rene.klu...@chimit.nl> To: "'Ivan Kurnosov'" <zer...@zerkms.ru>; "'Nikos Balkanas'" <nbalka...@gmail.com>; <users@kannel.org> Sent: Wednesday, September 15, 2010 3:35 PM Subject: RE: registered_delivery and multi-parts message True, it's a Kannel thing, not an smpp spec issue. What you did probably won't break Kannel... but... you might get some log messages where Kannel complains about not being able to find DLR or not interested in it. == Rene -----Original Message----- From: users-boun...@kannel.org [mailto:users-boun...@kannel.org] On Behalf Of Ivan Kurnosov Sent: Wednesday, 15 September, 2010 14:08 To: Nikos Balkanas; users@kannel.org Subject: Re: registered_delivery and multi-parts message How they can broke it? It is just removing registered_delivery from other messages than 1st 2010/9/15 Nikos Balkanas <nbalka...@gmail.com>: That's a kannel, not a spec limitation. And these 3 lines of code you changed propably have broken your kannel. BR, Nikos ----- Original Message ----- From: "Ivan Kurnosov" <zer...@zerkms.ru> To: "Nikos Balkanas" <nbalka...@gmail.com>; <users@kannel.org> Sent: Wednesday, September 15, 2010 2:24 PM Subject: Re: registered_delivery and multi-parts message Actually, I can ;-) I already fixed kannel (to be clear - i've just commented 3 lines of code) to send only one DLR msg. So now I get N delivery messages. But I'm very curious - is it just kannel "feature" or some smpp specification mandatory? I've asked this question because one of my SMSC (currently i'm working with 3 different companies) does not send me delivery messages if it is 0x1 just at first and not at second message. So I need to know whether I need to ask their support to reconfigure SMSC or make some tricks to get that info 2010/9/15 Nikos Balkanas <nbalka...@gmail.com>: Hi, This is a known kannel limitation. In a multpart SMS it will request DLR only for the first part. Nothing you can do about it. BR, Nikos ----- Original Message ----- From: "Ivan Kurnosov" <zer...@zerkms.ru> To: <users@kannel.org> Sent: Wednesday, September 15, 2010 8:28 AM Subject: registered_delivery and multi-parts message Hello there. Why does 2010-09-15 16:26:32 [25217] [6] DEBUG: registered_delivery: 0 = 0x00000000 for second part even though it was 0x1 for first one? Is not it a bug? While reading SMPP v3.4 specification I did not see any recommendations about how to set registered_delivery if there are multiple parts. -- With best regards, Ivan Kurnosov -- With best regards, Ivan Kurnosov -- With best regards, Ivan Kurnosov