学海无涯
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进行转换和互通。这是个很不错的想法，让人有很多想象空间。
一位台湾技术人士的网站：http://ihower.tw/rails3/index.html 。不需要翻墙阅读，难得啊。
还没有仔细阅读，无法评价是否是精品。不过从作者文章的布局看（据说也会出实体书），至少是花了不少精力的。也许和Django book互有短长。
最近的项目中需要开发web services，目前主要考虑两个框架： Raby on Rails和Django。网络上比较推荐RoR，但是考虑到我们目前已有的项目和技术积累，我更偏向Python一些，因此更关注Django。
网络上有免费的Django入门教材：
其中文翻译为以下网址：
当前电脑（XP）的登录用户名是wang，而另一台电脑设置（Ubuntu）的共享目录只允许yxh用户登陆。从当前电脑登陆该电脑时，会被直接拒绝。需要修改为以yxh名义登陆。（当然，也可以注销当前用户，换成yxh登陆当前电脑，不过这样就要中断当前正在进行的工作。）
采用net命令进行设置即可，例如目标电脑名是linuxubuntu：
net use \\linuxubuntu /user:yxh
输入yxh的密码后，就可以在当前电脑直接登陆linuxubuntu这台电脑了。
在两篇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包的方法，实在让人感觉多此一举。即没有减少流量，也不能降低丢包对语音质量的影响，反而增加了网络设备的复杂性。从实际应用来看，也没有什么人会采用这种方式。
日常偶尔读点书，享受一点阅读的乐趣，也许需要记点什么，就开辟这个栏目。
现在正在读的书是南怀瑾先生的全集，好多本啊，累死我了。另外正在学习的技术类书籍（说文档可能更合适）是37signals的GettingReal，也是一篇让人拿起就放不下的文章。
希望自己能好好学习，天天向上。
昨天Commit代码时，网络意外中断。今天再次Commit时，RapidSVN提示出错：
Error: Error while performing action: Working copy ‘… …’ locked.
看这描述的意思，是本地文件在上次操作时进行了锁定，由于没有正常退出解锁，导致后续操作无法再继续。
要解决也很容易，将上次的操作clean掉即可，点击菜单 Extras -> Cleanup，清理完成后，重新Commit即可成功。
据说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