在Vovida的基础上实现自己的SIP协议栈

在Vovida的基础上实现自己的SIP协议栈（一）卢政2003/08/01写在前面的话不少通讯方面的同好已经读了我在去年岁末撰写的《如何用OpenH323开发自己的H.323协议栈》,大都给予了很高的评价,甚至可以说是好评如潮,说来惭愧,我只不过把十几个人的工作进行了整理和归纳而已,事实上我自己的代码只有很少的一部分(主要在H.245/H.235部分),后来很多朋友向我索要RTH323的测试版本一直未果,我在这里说明一下,由于该软件的使用和二次开发的权利已经被某欧洲公司所买断,所以我已经无权发布测试代码,如有不便敬请大家原谅.在我们开发RTH323之际,我已经开始注意SIP协议了,并且根据RFC2543设计了不少实验代码,因为当时的开发有一个H.323-SIP的翻译网关的需求,不过后来这个计划又取消了,也从这个时候开始我逐渐对SIP有了比较浓厚的兴趣,只是并没有做什么实际的工作,仅仅初步了解了一下协议的整体构造.直到去年年底,我接触了Vovida的开放原码的SIP系统--Vocal以后,我决定开始系统的了解SIP的整个构造,我个人认为Vocal是一个非常典型的SIP系统,里面包含了所有构造电信级呼叫中心，区域网关以及中继网关的所有内容,而且代码清晰,比较易于改造；于是我花费了大概6个月的时间阅读了整个Vocal系统的代码,并在很多重要的地方做了标注.正好在今年的5月份,我的公司有构造一个大型的Voice/VideoIP企业呼叫中心的计划,我就把我对Vocal的研究成果提交给公司,方案得到通过,现在我的公司正在和国内某个知名大学合作准备在现有Vocal基础上改造一个企业级的视频电话呼叫平台不过我个人而言,对这个计划不是非常的满意,由于时间和金钱上的限制,大部分的电讯级补充服务第一阶段没有实现的,只可能在第二阶段去实现该计划,时间可能要持续很长,所以我也很希望有其他的开发公司参与完成这个方面的开发,当然我们也可以为有兴趣的公司提供技术咨询或者展开合作。我写这本文的目的在于公布我个人对Vocal这个开放原代码系统的一些研究成果,当然里面有很多地方没有说得非常清楚,本身要用文字来阐述程序的设计思想就是一个非常困难的事情,所以我在里面大量的绘制了很多图表,来帮助读者阅读本文,这次公布的是有关UA端的内容,后续在本文中将介绍Vocal系统中的ProvisionServer;MarshalServer;RedirectServer;HeartBeatServer:PolicyServer:CDRServer:NetworkManager:FeatureServer:以及各种协议的Translator,读者需要具备对SIP,H.323,MGCP,QoS的基本了解,以及对Java,XML,CallProcessingLanguage，C++的知识，在以下章节中不会对这些基本的知识做太详细的介绍。预计本文全部刊登完毕大概需近一年的时间，我希望有软件开发公司来和我合作完成这篇文章或者是共同从事Vocal系统的二次开发工作。从这半年的阅读Vocal的过程中我体会到Vocal系统的商业应用价值非常大，有人在论坛上和我讨论：改造别人的应用平台的难度和重新开发一个应用的难度哪个更大，双方都各置一词，就我个人觉得，大型的商业软件如果按照开放原代码来进行改造，特别是一些基础平台（例如操作系统），速度肯定是比从零开始要快很多的，RTH323就是一个成功的范例，这也是国内很多软件厂商的基本运行模式，特别对于一些人员，技术，资金都不是非常充裕的公司这可能也是唯一的方案，但是开放原代码的软件大部分的效率非常低下，而且代码冗余，注释比较少，可读性非常差，甚至还有一些致命错误（Vocal中的FeatureServer中就有这样的错误，往往可以造成系统崩溃）所以这样做的前提条件就是能把握住工作的重点，能及时发现并排除问题，这样才可能把开放原代码改造成高效率的商业应用。目录一．楔子二．H.323和SIP之间的差异三．本文的主要内容1．UserAgent的简介2．UA部分主要程序部分的介绍2．1主程序：\SIP\UA\UA.cxx2．2创建一个UserAgent的实体2.3HeartLessProxy的创建2．4让UserAgentRun起来2.5HeartLessProxyRun方法的实现2.5.1WorkerThread的Run方法2.5.1.1processSipEvent2.5.1.2processUaDeviceEvent2.5.1.3processUaDigitEvent2.5.2SipThread的Run方法2.6在UserAgent中的四个重要实例的Run方法2.6.1媒体设备启动2.6.2启动RTP线程，用于对RTP/RTCP包的接收和发送管理；2.6.3合法用户列表的获取(RedirectionServer专用)2.6.4监测线程：2.6.5自动呼叫3.开始一个呼叫和等待对方呼叫：3.1系统创建StateIdle状态：3.2开始一个呼叫：3.2.1OpStartCall主程序部分：3.2.2取得键盘的事件3.2.3状态机（State）对各个操作（Operator）的处理过程：3.2.4开始一个呼叫所经历的各种操作（Operator）3.2.5如何进入待机状态(Idle状态)3.2.6如何开始拨号并且开始一个呼叫：3.2.6.1OpStartDialTone本地发送拨号音；3.2.6.2OpAddDigit输入电话号码开始拨号：3.2.6.3OpStopDialTone；3.2.6.4OpInviteUrl建立一个INVITE消息并且发送到被叫；3.2.7进入Trying状态3.2.7.1OpStartTimer启动每个事件的定时器：3.2.7.2挂机事件的检测机制3.2.7.3OpStartRingbackTone向被叫进行铃声回放。3.2.7.4OpReDirect进行重定向服务的操作3.2.7.5授权检查3.2.7.6OpFarEndAnswered处理接收到的OK回应3.2.7.7在Vocal中如何实现RSVP资源预留协议3.2.8用户处于通话的StateInCall状态：3.2.8.1OpStartAudioDuplex主叫打开RTP通道3.2.8.2处理RTP/RTCP包:3.2.8.3ACK消息的处理过程OpAck3.2.8.4OpConfTargetOk多方会议检测：3.2.9呼叫等待3.2.9.1呼叫等待的详细描述：3.2.9.2操作之间存在的竞争3.2.9.3呼叫中所涉及模块介绍3.3等待对方的呼叫3.3.1OpRing等待对方的振铃消息3.3.2OpStartRinging开始响铃3.3.3OpRingingInvite处理又一个INVITE消息（呼叫等待）3.3.4OpAnswerCall被叫打开媒体通道开始通讯3.3.5回到StateInCall状态4.如何在改造现有的终端使之能传递视频流。4.1一个H.261+的Codec的基本构造4.2增加视频能力所需要做的工作一．引言在各种的IP网络多媒体通讯协议中，当前在市场上占据主流位置的应当算是ITU的H.323和IETF的SIP两个协议，目前在单纯的话音市场，MGCP协议由于有大规模的用户扩容能力应用也正呈现上升的趋势，在2000年以前市场上占主流的主要是H.323协议，然而SIP协议由于它避免了复杂的原语(ASN.1)分析，它的应用也在2000年以后也得到高速的普及，甚至有超过H.323的趋势，成为H.323最有力的竞争对手，当然，由于SIP协议的一些固有缺陷（下面将会详细介绍这些缺陷），这种情况在未来的几年可能不会出现，不过对于中等规模的多媒体通讯业务（每小时接入60000门）应用而言，采用SIP不失为一个方便，快捷的开发策略。在各种的VOIP开放原码的开发项目中，Vovida的基于SIP协议的VoCAL（VovidaOpenCommunucAtionLibrary）不仅仅是在基于SIP的开放原代码协议栈中是最为庞大而且完善的，甚至在所有的原码开放的多媒体通讯协议栈中同样也是完善而且全面的，目前发布的VOCAL1.4.0主要支持RFC2543，据称在新版本的Vocal1.5.0将支持RFC3261协议；Vocal提供了基本的SIP呼叫控制和切换，例如：用户注册和登记，呼叫初始化，修改呼叫特性，或者重新定义呼叫特性，终止呼叫；以及一些用户的基本呼叫特性：例如呼叫前转，呼叫等待，呼叫阻塞，呼叫转移，语音邮件等等。对于一个Vocal系统的用户而言，Vocal同样为其提供了以下的一些能力：1．通过Web来配置整个Vocal系统；2．使用SNMP网管来检测整个系统和呼叫组网的状态；3．可以定义一个用户的呼叫特性列表（相当于H.323系列中的H.450补充协议部分）；4．授权检查；5．广告信息；6．基于RSVP的简单QoS保证。同时，VOCAL也提供了详细的文档和SDK包以给用户做二次开发，用户可以在C++，以及CallProcessingLanguage(CPL)，JavaTelephonyAPI上开发自己的应用。二．H.323和SIP之间的差异：这一节和本文的内容似乎没有太大的关系，不过笔者认为作为市场主流的H.323和SIP之间需要做一个相关性的比较，以免使很多读者在选择协议的时候陷入歧途。虽然Vocal在SIP的应用上已经可以算是一个成功的实例，所以目前单纯以Vocal作为主体开发SIP的多媒体通讯系统从理论上是可行的，但是事实上目前所有的VOIP商业系统都是以H.323为主体，兼容SIP协议，似乎还没有一个厂商在实际上支持SIP（Cisco好象有类似的产品，不过应用前景似乎不是非常明朗），首先从市场上来看，H.323的系统已经有大量的投资，应用也非常普遍，SIP相对比较新，似乎不够成熟；从市场上来看，越来越多的附加服务将成为应用的主流，SIP领域相对来说比H.323能够提供更多，更灵活的服务，而且在信令的互通性上有更加多的优势，当然H.323也能够保证其他解决方案之间的互用性；但是，目前MGCP协议已经得到了大量的工业支持，简单的终端和更加复杂完善的呼叫控制方式让它得到了更多的应用，很可能会成为SIP的潜在竞争者。其次我们从ITU和IETF的条款保证上来看，IETF所制定的草案一开始都阐述一个让人失望的观点：本草案作为参考资料是不合适的，除非在制定和完善中，这样在协议成熟和完全理解期间必然会把一些工作引入误区，特别是某些协议被更新和升级期间。相对而言，作为官方实体的ITU制定的协议一旦实施就不再轻易的改变，因此在发布协议前，已经对协议作了很长时间的互通性测试。最后从技术上来看，SIP和H.323在技术实现上有很大的不同：a．开发速度：SIP当然的优于H.323协议太简单了，不过如果H.323原语部分可以比较好的解析的话，事实上两者开发速度相差不大。b．多播：在这个方面IETF具有优势，有非常强大的应用经验的，SIP已经设计在很多多播的骨干网络上，h.323v1,v2要使用多单播同时进行的方式才能完成，不过H.323V3版本多播的支持就已经非常不错了。c．地址的运用上SIP使用Url上的机制非常灵活，这样可以让SIP以一种非常灵活的方式重定向到非SIP服务器上去，被另外一个SIP呼叫的SIP终端也能重定向到某个网页或者是电子邮件地址。对于H.323而言，命名的机制就非常混乱了，从ASN.1的文件我们可以看到有h323-ID，url-ID，transport-ID，email-ID，partynumber等等。d．对于SIP而言，所有的消息都采用文本编码，所以SIP消息非常简单，这样在开发的时候简单的网络检测就可以调试，反观H.323协议采用了PER或者BER的二进制编码方式，信令不是非常直观。e.系统资源的消耗上，SIP可以说是开销惊人，每次服务器发出通告的时候，都需要建立一个监听套接字，这样的结果势必造成大量的闲置套接字，假设在建立一个完整的Proxy/Registe