我希望有人可以帮助我解决我遇到的关于“中间”类型（即类型= 4）的DLR继续排队的问题。
我的理解是，在美国，成功和最终的DLR（即DELIVERED（1））很少见，而中间DLR如“在SMSC上排队”。当承运人代表其客户接受消息时，ACCEPTD，REJECTD更为常见。
我们使用的SMSC仅对未传递的消息发送回类型= 2，对于成功传递给运营商的消息，键入= 4 DLR。我们在Kannel中使用内部DLR存储（不使用mysql），问题是类型= 4的DLR不被认为是最终的，因此不会离开DLR队列。当我们返回type = 4 DLR时，在bearerbox日志中会看到以下消息。
2013-11-05 14:59:06 [15084] [6] DEBUG: DLR[internal]: Looking for DLR smsc=test, ts=4154168431, dst=<censored>, type=4
2013-11-05 14:59:06 [15084] [6] DEBUG: DLR[internal]: created DLR message for URL <http://localhost/dlr.php>
2013-11-05 14:59:06 [15084] [6] DEBUG: DLR[internal]: DLR not destroyed, still waiting for other delivery report
看来Kannel在DLR退出队列之前正在等待类型= 1或2的DLR进入。
是否有一个Kannel设置使其类型= 4 DLR被视为最终DLR并因此清除DLR内存不足？我已经搞乱了Kannel中的dlr-mask设置，但我不认为该属性能解决我的问题。
提前致谢，如果我能提供更多信息，请告诉我。
TL; DR：我如何让Kannel认为类型= 4的DLR是最终的DLR。
答案 0 :(得分：1)
如果不改变源代码，就无法做到这一点。这些值在Kannel源代码中是硬编码的，并且不能通过配置值或sendsms地址的URL参数进行更改。
至少你会对获得DLR感到高兴。您可以为DLR使用某种外部存储，例如MySQL，并在您不再需要它们之后从应用程序中删除DLR表中的那些条目。