说说NAT

昨天没有发，今天发早一点。

这两天我一直在做视频转码，试了ffmpeg、libbpx以及Cisco新开放的OpenH264。尤其是最后的OpenH264，文档很少，刚刚开源，也找不到什么参考资料，代码嘛，写得也不怎么清爽，还是C++的。因此，这几天我的FreeSWITCH应该是Crash了不下100次，因此，便没有时间写微信了。

视频转码有无数的参数，因此，是个任重道远的活，所以，这里就先不说了。今天说一说QQ群中网友提到的一个问题，比较典型。

首先是有一个网友私下问我问题，我让他到群里问，后来我看到群里有人问一个在NAT环境下电话不通的问题（不知道是不是跟私聊的一个人，私聊跟群里对不上号，呵呵）。问题是，如果不开视频，则经过NAT设备的通话是通的，一开视频就不通了。看起来很奇怪，原因也可能有很多，因此，我提议他打开SIP Trace（使用sofia global siptrace on命令）将抓包的数据放到Pastebin上。接着他问什么是Pastebin，我说先看新手指南，接着他问什么是新手指南，我说那得看http://www.freeswitch.org.cn 。是的，我建议所有提问题的人都先看新手指南。

说到这里，群里还有个人说他也有同样的问题。这就是在群里问问题比私下问的好处，你能找到与你有同样问题的人，他们会跟你分享经验。

当日志贴到Pastebin以后，我看了一下，客户端发了INVITE以后，FreeSWITCH回了407要求认证，这时候客户端回了ACK，然后应该重新发带认证的INVITE。结果FreeSWITCH等了半天没有收到，因此报WRONG_CALL_STATE错误，呼叫失败。（有对SIP呼叫流程不清楚的读者可以看《FreeSWITCH：VoIP实战》第四章，点击左下角的查看原文查看）

这里说一下，有了这个日志我们马上就定位到问题了，所以，贴日志很重要。

出现这个问题的原因可能是客户端根本没回下一个INVITE（这不大可能），或者是路由器或NAT设备将该INVITE包拦截或丢掉了。

由于现象是音频电话通，视频电话不通。而这两种电话的区别一般是INVITE包中的SDP不同，后者比较大一些。从收到的第一个INVITE包来看，大小已有1265字节，极有可能是后续的INVITE包更大而超过了MTU，被路由器分包或导致了其它问题导致FreeSWITCH收不到完整的INVITE包。日志中的内容如下：

recv 1265 bytes from udp/[10.0.10.1]:62468 at 14:24:47.759160:

因此我让他换TCP试试，TCP是面向连接的协议，具有丢包重传机制，因而能保证IP包的完整。但他试了以后问题依旧。

后来，我忙别的事情，再回来看时群里已经有朋友帮他解决了，说是路由器有ALG（Application Layer Gateway），他改了SIP服务端口就好了。ALG是一个看起来很美好但到处都是Bug的NAT解决方案，因此在使用FreeSWITCH的时候，我们都建议关掉它。不过，不知道该方便中的ALG为什么只对视频请求有问题，音频却没问题。总之，根本原因还不知道。但这里我要说的不是这个问题。而是——有问题在群里问，我不在的时候别人也能帮你。

关于NAT我们先说到这里，后面有空我会详细说（可能得写一个系列）。最后，贴上Anthony在《FreeSWITCH1.2》中说的关于NAT的部分，英文好的读者可以读读：

To be honest, the original stance of the FreeSWITCH developers on the NAT issue was, "Not our problem!" In an ideal world, every device behind a NAT firewall

is well aware of its circumstances and can successfully solve its own problems. Unfortunately, we do not live in an ideal world (of course if we were in an ideal world, none of us would have a job because there would be no problems to solve). So we decided, "OK fine, we'll give it a shot!" We soon learned that our users had a myriad of devices that they wanted to use with FreeSWITCH, but these devices had absolutely no idea how to deal with NAT. Soon, we began the monumental task of developing techniques to allow these devices to work despite their shortcomings. NAT is a vicious opponent and the faint-hearted do not stand a chance to survive.

----------------------------------------

题图：辟邪绘（五图之一） 参见 http://en.wikipedia.org/wiki/Extermination_of_Evil

----------------------------------------

FreeSWITCH-CN是什么？

FreeSWITCH-CN是FreeSWITCH中文社区，我们的官方网站是 http://www.freeswitch.org.cn 。FreeSWITCH-CN同时也是一个微信公共账号，可以通过点击本页最顶端的“FreeSWITCH中文社... ”，或在通迅录->订阅号中搜索“FreeSWITCH-CN”来订阅，也可以到官方网站上扫描二维码。当然，不管是新用户还是老用户，随时都可以输入m或1显示本账号的主菜单。

FreeSWITCH-CN的账号维护者是Seven Du，在此，他会分享多年的FreeSWITCH使用经验，分享一些对开源VoIP软件以及软件社区的思考，并隔三差五的解答一些粉丝关心的问题。Seven Du于2007年听说、2008年开始使用FreeSWITCH，2009年创办FreeSWITCH-CN中文社区，2011~2013连续三年参加了在美国芝加哥举办的ClueCon全球VoIP开发者大会，该会议是由FreeSWITCH核心团队主办的。