Kannel中submit_sm_response里短信ID的编码差异问题咨询

我们已配置多个正常运行的SMPP连接，可处理外发消息的DLR，但某新运营商发送的message_id参数为十六进制编码的普通字符串，而非其他运营商常用的Octet string。

正常情况下，kannel.log中的message_id为Octet string格式，示例如下：

message_id:
   Octet string at 0x7fb584042eb0:
   len:  32
   size: 33
   immutable: 0
   data: 31 38 32 37 64 61 33 30 34 33 61 30 30 30 31 37   1827da3043a00017
   data: 35 33 36 36 65 64 63 61 37 32 38 63 62 33 37 31   5366edca728cb371

该格式可正常解码，且与DLR中的ID（"1827da3043a000175366edca728cb371"）一致。

但新路由的message_id格式为：

message_id: "763307F1"

这是无前缀0x的十六进制编码ID，而对应的DLR PDU中的ID为十进制1983055857（即0x763307F1），导致SQL查询无法匹配DLR与外发消息，DLR被丢弃。

现咨询三个问题：

• 是否可强制Kannel以十进制存储ID？
• 还是需运营商修正该问题？
• 造成两种ID编码差异的原因是什么？

1. 能否强制Kannel以十进制存储ID？ #

可以通过修改Kannel源码或自定义扩展实现，但这不属于官方常规配置项。需要找到Kannel中处理SMPP message_id存储的代码段，将十六进制字符串格式的ID转换为十进制数值后再存入数据库。不过这种自定义修改会增加后续维护成本，每次Kannel版本升级都需要重新适配修改。

2. 是否需要运营商修正？ #

优先要求运营商修正。SMPP协议规范中，message_id字段的标准类型是Octet String（八位字节串），该运营商将其发送为十六进制编码字符串，且DLR又使用十进制ID，属于对协议的不规范实现，不符合行业通用做法。让运营商调整为符合标准的Octet String格式，或者保证message_id与DLR中的ID编码格式一致，是最稳妥、长期可维护的解决方案。

3. 两种ID编码差异的原因 #

• 标准实现：多数运营商遵循SMPP协议规范，将message_id作为Octet String传输，本质是直接传递字节数据，日志中显示的十六进制是字节的可视化形式，实际存储的是对应字符串（如示例中的1827da3043a000175366edca728cb371）。
• 不规范实现：该新运营商可能错误地将message_id的数值本身（而非字节串）进行十六进制编码传输，并且在DLR环节又将该数值转换为十进制格式返回，导致编码格式不统一。这种情况通常是运营商SMPP网关的开发或配置错误，未严格遵循协议定义的字段类型要求。

内容的提问来源于stack exchange，提问作者Pownyan