To start with the last thing: 2) You are right. It should use the msgid's in the dlr_url from the dlr instance. I changed it.
About 1): We assume msg->boxc_id and box->boxc_id are the same in this case. Otherwise the message wouldn't have ended up there. == Rene -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Victor Luchitz Sent: maandag 5 juli 2010 20:36 To: [email protected] Subject: smppbox code questions Hello, I have a few questions for you regarding the handling of DLR's by smppbox, which might also turn out to be bugs. 1) In msg_to_pdu function there's a line which reads: dlr = dlr_find(msg->sms.boxc_id, msgid, msg->sms.receiver, dlrtype); I think it's incorrect because when a DLR is stored by smppbox in handle_pdu, the boxc_id it uses is that from smpp_logins file (system_type). That in turn may cause dlr_find to always fail. So in my opinion the correct dlr_find call is this: dlr = dlr_find(box->boxc_id, msgid, msg->sms.receiver, dlrtype); 2) another thing I find not quite correct is the way smppbox splits message ids for concatenated DLR's. Basically, what smppbox does is this: parts = octstr_split(msg->sms.dlr_url, octstr_imm(";")); msgid = gwlist_extract_first(parts); ... Then it loops through all elements of the 'parts' list and here is where the potential problem lies. smppbox assumes that msgid for the concatenated DLR is always equal to dlr_url which is not always true. In fact, I think it's never true for concatenated DLR's stored by the dlr_add call in handle_pdu. Also, for example, the 'msgid' and 'dlrurls' columns in the storage table can have different maxiumum lengths, allowing truncation of the msgid. Here's my proposed fix - add the following bit of code to msg_to_pdu: gwlist_destroy(parts, octstr_destroy_item); parts = octstr_split(dlr->sms.dlr_url, octstr_imm(";")); gwlist_extract_first(parts); right above the following bit: if (gwlist_len(parts) > 0) { while ((msgid2 = gwlist_extract_first(parts)) != NULL) { -- Best regards, Victor Luchitz
