XSWITCH云平台目前建设在腾讯云上。今天在调试Kamailio，收到SIP包后发到另一台VM上的FreeSWITCH中，中间通过公网IP发送。然后遇到了pike模块告警，说数据包太多。pike模块是Kamailio里的限流模块，将阈值调高了一倍还是不行，遂抓包找原因，最后发现是网络层篡改了Route字段，将里面的公网IP改成了私网IP，造成了SIP消息在公网和私网IP间无限循环，直到遇到限流（幸亏开了限流模块）。
首先要核实问题，发现从我本地电脑发出的数据包也有此问题，但这也可能是由于我本地的路由器引起的。检查本地路由器没有开启ALG功能。又重新核实。在两台腾讯云服务器上通过公网IP测试。
发现，如果A的IP是公网IP，到达对方后Route字段会被改为私网IP，而如果用私网IP就不受影响。
给腾讯提了工单，响应挺快，只是沟通了很多次，工程师说是腾讯云默认没有开ALG，然后定位到问题，联系产品给我加了个ALG功能，然后让我把公网IP迁移到EIP或买个EIP，在EIP上开启ALG就可以了。
我直接就不懂了，然后详细说明我认为的ALG是“篡改”包的内容的，如果没开就不会篡改，何来再开启一说？
最后经过电话沟通才把问题说明白。腾讯云默认确实是开了“篡改”功能的，如果想关掉，那就得再“开启”另一个“ALG穿透”功能（实际上控制台页面上叫“设置ALG”），让数据包透明的过。他们认为这才叫“开启”。
好吧，负负得正，反正能解决问题就行了。我相信应该能解决问题，但是没有验证，因为目前在生产环境上动EIP有点风险。
ALG的全称是Application Layer Gateway，即应用层网关。我们都知道，网络有个OSI七层模型，网络交换机和路由器其实是工作在2层和3层，即他们最多只知道IP包里的源IP地址和目的IP地址，而不知道数据包里具体传的是什么。着名的Web服务器和反向代理软件如Apache和Nginx工作在七层，理解HTTP协议，因而可以修改消息内容，并转发。所以，其实他们就是应用层的网关。最近比较火的专门做API转发的API网关也是工作在七层的。
其实，路由器上也是有ALG功能的，但功能一般都比较弱。路由器上的ALG功能一般用于解决FTP和SIP这样的奇葩协议。FTP协议需要两个端口才能传输文件，有主动模式和被动模式等，在有的NAT网络中不容易通过，因而，路由器上的ALG功能可以提供帮助，细节不多说。
SIP协议更奇葩，一个INVITE消息里有好几个IP地址，在NAT网络中有时候就不通了，甚至，有时候信令通了，通话建立了，却没有声音，也多半是NAT惹得祸。因而，路由器上的SIP ALG也可以深度解析SIP包，企图（注意这里用了贬义词）修复里面的IP地址。但是很不幸，很多ALG实现都有Bug。即使ALG没有Bug，SIP协议很复杂，ALG根本Cover不住，你无法预测它在什么情况下改哪个地方，所以，大多数时候，它带来的帮助比带来的问题多得多。除非，除非路由器上的ALG功能有很多配置选项来应对各种问题，比如用Kamailio实现个ALG。但这是不现实的，所以，你应该关掉它！
好吧，到了这里，我们应该可以明确，如果路由器上开启了ALG功能，数据包有被“篡改”的风险，所以我们需要关掉。
问题是，腾讯云上这一功能是默认开启的。所以，他们又在控制台上实现了一个“ALG设置”功能，如果“开启”以后，就关掉了。他们的技术支持工程师会告诉你“ALG默认是不开启的，你可以在EIP上开启”，“开启”后，就好用了长时间无语中。
发了个朋友圈吐槽了一下（不要误会，我本身是腾讯云的TVP，吐槽是我的职责），很多人就建议我迁到阿里云或华为云。其实，腾讯云本身非常不错，他们的技术支持也很及时，只是，在这一问题上，不同的人有不同的认知。也许那个工程师并不懂SIP，也许他只是站在他们产品的角度，“设置ALG”这一功能就是没有开启嘛。所以，每个人都有自己看问题的角度。沟通，需要摆事实讲道理才行。但无论如何，给腾讯提个建议，把这个功能改成“关闭ALG”，就没有歧义了。因为在默认情况下，数据包应该是畅通无阻的，既然有人从中做梗，那就应该“关闭”它，而不是要绕一圈搞个“负负得正”。
再说到SIP的ALG。除了上面说到功能很鸡肋外，其实不管是FreeSWITCH还是Kamailio，都在NAT上做了大量的工作保证在NAT环境下可用。ALG不仅仅是鸡肋功能，简直是SIP公敌。所以，默认在网络环境下开启这一功能是不负责任的。
如果你的SIP服务器运行在腾讯云上，标准的做法是使用EIP并“开启ALG”（再说一遍，实际上是关闭@#^&$@#$@?$x）。（如果你从未来穿越到现在看到这篇文章，现在是2020年）
XSWITCH用户也注意，我们目前还没有迁移到EIP，因为这可能会影响我们很多租户。如果您有问题，请尝试使用TCP，已知TCP的SIP消息不会被篡改。再有问题请与我们联系，我们也会尽快完成EIP迁移。事实上，我们希望所有UDP用户都迁移到TLS上。
