昨天测试「通过」了，今天把过程中遇到的一些问题写下来，免得以后忘掉，而且也许会有用处。
1. 业务梳理中发现，电信的匹配规则比移动和联通都要严厉
如果一个业务代码，在 SPOA 上填写了以长号码 XXXX01、空指令匹配上行，那么下发的时候，不但 LinkID 要原样回复，业务代码只能写这个，而且长号码也不能自己随意写，必须写这个 XXXX01。当然，如果匹配规则是模糊匹配，那么扩展长号码是允许的。
这样一来，那种利用一个入口指令实现转向到各种不同资费的业务上的做法就行不通了。不过，测试中摸索出了电信网关的处理逻辑，也就是具体鉴权时的做法。也不像上面所说的那样无懈可击。
电信网关的处理逻辑，应该是在上行的时候生成了一个 LinkID。下行鉴权时，检查 Submit 短信中的长号码和 LinkID，将其和上行时的内容一起再次用业务代码上配置的匹配规则进行匹配，若能通过，就放行。
由此可见，如果以 XXXX01 为匹配规则的业务如果想要以长号码 XXXX02 下发，只要增加一条匹配规则：长号码 XXXX02，内容为空 / 模糊，就可以下发成功。由于电信 SPOA 将同样的长号码的精确 / 模糊两种匹配模式视为不同的匹配规则，因此可以利用这个来实现不同业务代码之间的转向。
不过，这要求在业务申报 / 梳理的时候必须很精细。而且，后面会提到一个问题，可能导致更麻烦的情况。
2. 交叉/嵌套关系的匹配规则的匹配优先级问题
应该说，这个问题对于任何一个匹配为己任的系统，都是一个问题。有的系统显式地指定规则的应用优先级顺序，有的系统采用最长匹配等方法来自动判定优先级。从电信 SPOA 看来，它用的显然不是前者。
那么是否有进行某些智能化的匹配方法呢？我们做了一个实验：
(1) 配置一个定制类业务，长号码 XXXX01，命令字 01，均为精确匹配。
(2) 配置一个点播类业务，长号码 XXXX01，空指令，均为模糊匹配。
(3) 终端上行 01 至 XXXX01，发现收到了点播的 Deliver。
由此可见，至少，电信的网关在处理这种明显的包含关系的匹配规则的时候，是没有处理好的。匹配到的结果，我认为很可能是无法预测的。
因为这个问题，导致了在业务申报和梳理的时候，必须更加地小心，特别针对多次申报 / 业务管理员多次更换、交接的情况。
3. 定制类业务的二次确认问题
此次测试，电信强制让所有的定制类业务都有了二次确认。虽然不好说是否和移动、联通一样是可以逐个业务进行开 / 关的（很有可能），但起码测试的时候是全开的。
二次确认的短信，是网关自行发送。长号码为 XXXX0001 这样的形式，后四位应该是一个流水号。回复此短信（无需一定要是 Y），就可以定制成功，网关接口就会收到「DG + 业务代码 + ……」的短信。
订购成功之后，若把这条短信翻出来再回，网关接口就会收到发往 XXXX0001 的信息。若是有业务的匹配规则定在 XXXX0 附近，就要小心了。相信每个业务都做好错误处理的话，应该问题不大。
大的问题是，网关有时候会把用户回复到 XXXX0001 的短信直接丢到 SP 这边来，而且没有 LinkID，这就要命了。我希望这只是网关接口还不够稳定的原因。
4. 「错误提示免费业务用 10 个 0，即 0000000000」
很抱歉，电信没有类似移动的帮助代码，因此除了包月 PUSH 之外，绝对无法主动下行了（割接之后）。
福富软件今天在 SPOA 上抛出了一个所谓「免费的错误提示业务代码」。其实我们早就问到了。关于这个东东的具体用途，其实是用来对那些没有匹配到任何业务上的上行短信进行回复的。它也必须跟 LinkID，肯定是不收费的，除此之外和一个普通点播业务没有太多区别（上下行频率未知）。
匹配到某个业务上的短信，是不能用这个业务代码去回的。
5. 定制和退订的同步关系短信
这其实是网关测试时遇到的问题，不过在业务测试的时候进一步证实了。
根据 SMGP 3.0 协议，定制和退订成功之后，SP 的网关接口会收到一条同步定制关系的短信。也是根据协议，短信后面的发送方号码和发送内容是可选的。不过在网关测试的时候，却是严格都要求带上。
这次业务测试的时候，也是如此，所以，就把它们当作必须的吧。
6. 00000
发 00000 到电信那边，按照协议，会直接退掉所有业务。SP 这边会收到 00000 的短信，回不回它都没有什么问题，不过，「最好是回」（原话）。
有一个问题来了，用什么资费代码回？询问福富软件的结果，是说填「空」。我们只好理解为无内容了。发了之后，没有状态报告 DELIVRD，不过也没有 UNDELIV。询问的结果，是「正常」。
姑且认为正常吧。
没有评论:
发表评论