云南龙网

  1. 首页 > 云知道 > >

在Vovida的基础上实现自己的SIP协议栈①( 三 )

云知道


对于一个Vocal系统的用户而言 ， Vocal同样为其提供了以下的一些能力：
1． 通过Web来配置整个Vocal系统；
2． 使用SNMP网管来检测整个系统和呼叫组网的状态；
3． 可以定义一个用户的呼叫特性列表（相当于H.323系列中的H.450补充协议部分）；
4． 授权检查；
5． 广告信息；
6． 基于RSVP的简单QoS保证 。
同时 ， VOCAL也提供了具体的文档和SDK包以给用户做二次开发 ， 用户可以在C ， 以及Call Processing Language(CPL) ， Java Telephony API上开发自己的应用 。
二．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/Register/RTP Gateway/三者和而为一的园区出口网关的时候 ， 资源上势必会非常的紧张 ， 这个是不能不予以考虑的问题 。相反H.323在打开逻辑通道的情况下（OpenLogicalChannel消息）只建立一个套接字 。

推荐阅读


上一篇：卫生间下水道有咕噜声是什么原因

下一篇：移动定向流量指定的软件怎么查