通信，让生活更美好！
项目名称是：sipml5，地址：http://code.google.com/p/sipml5/
该项目基于Google的WebRTC项目。这点与我以前写的一篇blog吻合，将SIP引入WebRTC不仅是可能，而且已经有人搞定了！
粗略地看了一下该项目的情况，界面是比较丑陋，不过看介绍应该是基本可用的。这是个好消息啊，尤其对企业用户而言，可能都不需要每个员工安装部署SIP终端，直接部署该终端即可，再结合云通信平台，整个系统都能简化不少。
如果该项目能覆盖Chrome, Firefox以及IE三个主要平台，基本就可以在实际环境中部署。非常让人期待啊。
目前发现比较好的SIP终端软件有以下两个，
CSipSimple : http://code.google.com/p/csipsimple/
SipDroid : http://sipdroid.org/
CSipSimple的口碑似乎还不错。看了一下它的网站，CSipSimple采用了pjsip协议栈，这个协议栈终端设备中有广泛的应用。
2013-09-13 updated：根据最新消息，下个版本的Asterisk很有可能选择pjsip作为新的sip协议栈。
缺省情况下，只允许以root身份运行wireshark，否则无法抓包，命令如下：
sudo wireshark
每次都这样启动实在是比较麻烦，最好还是允许普通用户也运行wireshark并抓包。为此，需要执行以下命令即可：
sudo dpkg-reconfigure wireshark-common
sudo chmod o+x /usr/bin/dumpcap
在SIP族协议中，只有RFC4028明确讨论了对话keep-alive问题。实际上这在工程应用、生产环境部署中，是个非常重要的话题，尤其是SIP基于UDP协议时，网络原因丢包是很常见的，另外还有软终端任意退出对话等情况。缺乏keep-alive保护的SIP服务器毫无疑问将会严重消耗资源，最终导致整个server被迫退出服务。
RFC4028协议考虑到有状态Proxy、无状态Proxy等情况，提出扩展Session-Expires以及Min-SE两个新的Header，并且通过reINVITE消息来keep-alive dialog。基本上，这个协议本身没有太多问题，按照它的思路，的确是可以解决keep-alive的问题，但是在实际部署中，该协议未必可取，有很大的缺陷：
（1）SIP运营商可能会拒绝reINVITE消息。实际上很多SIP运营商会拒绝reINVITE消息，这是出于SIP运营商媒体处理方面的考虑。最初应用reINVITE就是为了修改媒体流，而这毫无疑问会导致SIP运营商媒体服务器重新分配资源等情况出现。RFC4028中只是定义了新增Header和callFlow，不幸的是，却没有区分出这个reINVITE与更改媒体流的reINVITE，因此实际部署时是否有效，我们需要打一个很大的问号。
（2）采用reINVITE流程太过重型了。正如前面所说，keep-alive的reINVITE消息是没有与更改媒体流的reINVITE进行区分，因此可以肯定绝大部分SIP服务器或者终端，在收到这个reINVITE消息时，会启动媒体更改流程。对话内重改媒体毫无疑问是个很重型的流程，一旦对话内本身就可能有媒体类业务，例如Music On Hold等，就很有可能导致冲突。
如果不采用reINVITE消息，在4028协议中也同时建议可以采用UPDATE消息。在UPDATE消息中可以不携带SDP更改媒体。这种方式可能是比较可行，但是未必所有的SIP设备会支持UPDATE消息并用于keep-alive过程。
方案之二应该采用SIP最基础协议RFC3261中定义的OPTIONS消息。理由如下：
（1）该消息定义在RFC3261协议中，这个协议是整个SIP协议族的基础。基本上不可能有SIP设备（包括服务器、Proxy、终端等）会不支持这个消息。
（2）我们注意到，这个消息可以在对话内，也可以在对话外使用。在RFC3261中很明确地定义了：
An OPTIONS request received within a dialog generates a 200 (OK) response
that is identical to one constructed outside a dialog and does not
have any impact on the dialog.
（3）对话内使用OPTIONS，最显著的优点就是“does not have any impact on the dialog”，对现有对话没有任何影响，更不可能去更改媒体。
（4）对端设备如果由于某种原因已经退出，当然就不能产生200OK响应消息，此时可以理所当然地拆除当前对话，从而保护服务器自身资源，达到keep-alive的目的。
对于设备层级的keep-alive，采用OPTIONS没有任何问题。但是对于dialog层级的keep-alive，则会有问题。原因在于：dialog内的OPTIONS消息有可能被对端作为对话外的OPTIONS来处理。也就是说，如果设备是alive的，但是dialog的BYE消息丢失了，无论dialog内还是dialog外，设备对OPTIONS都可能会返回200OK。
Requests that do not change in any way the state of a dialog may be received within a dialog (for example, an OPTIONS request). They are processed as if they had been received outside the dialog.
方案三是采用RFC5626协议，对于UDP-SIP的情况，该协议建议采用STUN keep-alive方式。缺陷在于：定义有些复杂，而且很多SIP设备未必会支持。
呼叫服务器和媒体服务器合一的情况下，当然也可以由媒体服务器检测RTP/RTCP来keep-alive，不过这是另外一个topic了，这种方式可能更合适于SIP终端设备。
毫无疑问，WebRTC是个好东西。之所以这么说，是因为他居然开源了GIPS的audio引擎。GIPS的回声抑制、噪声消除等方面的技术，几乎独步天下。当年GIPS仅靠这些个算法包，就活得有滋有味。Skype、MSN、QQ等等，凡是做IP语音通信的，都无一例外地使用了GIPS的技术，这里还没包括各硬件芯片厂商。
Google居然将它开源了，牛啊！实在是让人佩服！
既然已经开源了，我们也希望在已有的free项目中引入webrtc的相关模块（主要是EC, NS等）。看了一下webrtc的文档（目前还是非常简陋），忽然有个想法，其实我们没有必要将webrtc的模块引入我们的项目，相反，我们只需要基于webrtc，将我们已经实现的SIP会话层以及GUI层添加到webrtc中。从webrtc的模块分层看，这样似乎更可行一些。
替换掉webrtc的会话层，或者新增SIP会话层似乎都是可行的。不过编译webrtc实在是麻烦，居然要vc2005（还不能是express版本）/ Win7 SDK / DirectX SDK等等，个个都是巨无霸。
另外，这个对Speex项目应该也有影响吧？Speex项目自己实现了一个audio引擎，不过其中的EC，NS等关键部件效果还是不太让人满意，不知道他们会不会从webrtc中获得灵感。
RTMP全称是Real Time Messaging Protocol。这个协议由Macromedia公司开发，为Flash player以及Flash media server提供语音、视频流媒体服务的私有协议。目前Macromedia已经公开了这个协议的细节。
值得注意的是，虽然Flash player/media server/RTMP通常用于提供网络视频流媒体，例如各种各样的视频网站，它们的组合也可以提供在线会议的功能。考虑到几乎所有的浏览器都可能安装有flash，因此终端用户几乎不需要另外安装软件，就可以访问视频、会议等服务，对这些业务的在线部署实在是非常方便。
Macromedia公开RTMP协议，可能是出于与HTML5竞争的需要。这对最终用户而言，无疑是有利的。
而吸引我注意的则是另外一则消息：FreeSwitch最新版本中实现了mod_rtmp模块，通过这个模块，FreeSwitch可以成为RTMP Server，并与传统的SIP进行转换和互通。这是个很不错的想法，让人有很多想象空间。
在两篇RFC文档中对iLBC有比较全面的介绍：
1、RFC3591 Internet Low Bit Rate Codec (iLBC) 这篇主要是讲解iLBC的基本原理，非语音处理领域的专业人士很难看得明白。
2、RFC3952 Real-time Transport Protocol (RTP) Payload Format for internet Low Bit Rate Codec (iLBC) Speech 进行RTP传输是必须遵守的规范，VOIP领域人士基本能看明白。
简单点说：iLBC采用8KHZ，16bit采样，但是分成两种模式：30ms（毫秒）模式以及20ms（毫秒）模式。最初只定义了30ms模式，后来考虑到窄带网络丢包的情况，增加了20ms模式。目前大部分设备多采用的是30ms模式。
30ms模式是指每30ms发送一帧，则每帧数据是400bits （50bytes），如果是20ms一帧，则每帧数据是304bits（38bytes）。
在SDP描述中，必须明确指明codec名字是iLBC。
如果是20ms模式，必须在SDP中明确指明，否则会认为是30ms模式。在RFC文档中有如下描述：
If 20 ms frame size mode is used, remote iLBC encoder SHALL receive “mode” parameter in the SDP “a=fmtp” attribute by copying them directly from the MIME media type string as a semicolon separated with parameter=value, where parameter is “mode”, and values can be 0 and 20 (where 0 is reserved and 20 stands for preferred 20 ms frame size). An example of the media representation in SDP for describing iLBC when 20 ms frame size mode is used might be:
m=audio 49120 RTP/AVP 97
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=20 <– 30ms模式中，多数厂家的设备不会携带这个attribute。
需要注意的是SDP协商与一般的codec协商有不同，其中比较关键的就是ptime不能应用到iLBC的协商中。iLBC总是采用最低速率模式，例如，只要一方要求30ms模式，双方都必须使用30ms模式：
That is, an offer of “mode=20” receiving an answer of “mode=30” will result in “mode=30” being used by both participants. Similarly, an offer of “mode=30” and an answer of “mode=20” will result in “mode=30” being used by both participants.
注解：我想可能就是这个原因（当然，也有历史遗留的可能），大家都不约而同地采用30ms模式，避免对媒体资源的重新调配。
不能使用ptime的原因在于一个RTP包中，可能会封装若干个iLBC包，这种情况下ptime无法表述究竟是哪种模式：
Parameter ptime can not be used for the purpose of specifying iLBC operating mode, due to fact that for the certain values it will be impossible to distinguish which mode is about to be used (e.g., when ptime=60, it would be impossible to distinguish if packet is carrying 2 frames of 30 ms or 3 frames of 20 ms, etc.).
注解：在一个RTP包中封装多个iLBC包的方法，实在让人感觉多此一举。即没有减少流量，也不能降低丢包对语音质量的影响，反而增加了网络设备的复杂性。从实际应用来看，也没有什么人会采用这种方式。
据说WebRTC是Web方式进行语音、视频实时通信的框架。项目地址如下：
http://sites.google.com/site/webrtc/ （需翻墙浏览？）
暂时还不太清楚这个技术的细节，不过如果像Google宣传的那样，就可以实现高质量的web通信方式。传统的SIP软终端就面临很大的挑战，从另一方面来说，可能也是一次打破现有格局的机遇。
SIPp是一个非常好的SIP性能测试工具，我们一直用它，：-） 不过一直是在windows环境中使用这个软件。
而最近忙于将已有系统迁移到Linux环境，因此就有必要研究一下linux环境下的SIPp，我们以ubuntu环境为主。在ubuntu环境中安装、运行SIPp基本是非常简单的，因为ubuntu的软件源中已经加入了SIPp，不过运行时有些地方需要注意。
下面我们逐一进行介绍：
step 1: 安装SIPp
sudo apt-get install sip-tester
step 2: 运行SIPp
命令与windows环境的SIPp一样，需要注意的是Ubuntu/Kubuntu的网络环境中，缺省会安装一个循环网卡，如果运行SIPp时不指定本地地址，SIPp很可能会以该Loopback的地址填写SIP消息中的各项参数，导致大量呼损。因此我们只需注意以-i指定本地地址，以-p指定本地端口即可。下面是两个示例：
运行SIPp接收端程序：sipp -sn uas -i 192.168.1.10 -p 5060
运行SIPp发起端程序：sipp 192.168.1.20:5060 -sn uac -i 192.168.1.10 -p 5061 -r 3 -rp 1000 -m 30000
在运行SIPp进行测试时，经常有人会问到：“为什么我运行sipp会出现下面这个错误提示呢？”
Error opening terminal: cygwin
这个错误是说SIPp无法找到运行时必要的terminal信息，这有可能是由以下几方面的因素导致的：
（1）计算机上没有安装cygwin。cygwin是必须要有的。
（2）直接在command命令行窗口运行sipp。这个是最常见的错误。大家可能觉得把cygwin的bin目录以及sipp的目录加入到path路径就可以直接运行sipp了。直接运行时，还是没有指定cygwin的terminal信息，同样会出错。
那么该如何运行SIPp呢？
请注意SIPp安装后，在“start”程序组中建立了快捷方式“start sipp”，我们应点击这个快捷方式来运行SIPp。这个快捷方式，实际上是指向SIPp安装目录下的批处理文件：startterm.bat。打开这个批处理文件，我们可以很清楚地看到，首先进行了terminal信息的设置，然后进行了必要的mount操作，最后才能正常运行SIPp。