几种开源SIP协议栈对比

随着VoIP和NGN技术的发展,H.323时代即将过渡到SIP时代,在H.323的开源协议栈中,Openh323占统治地位,它把一个复杂而又先进的H.323协议栈展现在普通程序员的眼前,为H.323普及立下了汗马功劳。而然当在SIP时代,则出现了群雄割据的状况,SIP相对于H.323简单,灵活,于是各种协议栈层出不穷,下面将详细对比最具有代表性的5个开源项目:OPAL,VOCAL,sipX,ReSIProcate,oS IP

OPAL是Open Phone Abstraction Library,是Openh323的下一个版本,它仍然使用了Openh323的体系结构,并在其基础上进行扩展,同时实现了SIP,H.323,但在音频和视频的编码和传输部分有较大改动。OPAL初衷设计是包含任何电话通信协议,所以其底层进行了高度的抽象化,所以也能够很容易的支持MGCP,PSTN和将来会出现的协议。不过由于Openh323的最后一个版本还在开发中,所以原本6月发布的OPAL也被推迟,现有的OPAL还非常不完善,BUG也非常多,不过相信以Openh323的开发班底,一定能让OPAL十分优秀。
CVS : :pserver:anonymous@cvs.sourceforge.net:/cvsroot/openh323/opal
Language : C++
VxWorks port : Yes
Win32 port : Yes
Linux port : Yes
Supports RFC 3261 : Yes
Supports RFC 2327 : Yes
Supports RFC 3264 : Yes
Supports RFC 3263 : No
Supports RFC 3515 : Yes
Supports RFC 3262 : No
Supports RFC 3311 : No
TCP : Yes
UDP : Yes
SIZE :  8MB
License : MPL
Document : None
Samples : UA,GK

VOCAL是vovida.org开发的SIP系统,VOCAL应该是目前功能最完善,使用者最多的开源SIP协议栈了.它不只包括了协议栈,还包括了h323与sip转换网关,对SIP的各种Server的功能支持也非常完善.不过很可惜,不支持windows平台,而且自从vovida被CISCO收购以后就停止了开发,最后的版本是2003年4月的1.5.0。
CVS : :pserver:anonymous@cvs.vovida.org:/cvsroot/vocal
Language : C++
VxWorks port : No
Win32 port : Partial
Linux port : Yes
Supports RFC 3261 : Partial
Supports RFC 2327 : Yes
Supports RFC 3264 :
Supports RFC 3263 :
Supports RFC 3515 : Yes
Supports RFC 3262 :
Supports RFC 3311 :
TCP : Yes
UDP : Yes
SIZE : 6MB
License: Vovida software licencse
Document : Few
Samples : UA,GK,GW

sipX是一个SIP系统,由SIPFoundry开发。sipX是从reSIProcate分离出来的,sipX除了包括SIP stack外,还包括了sipXphone,sipXproxy,sipXregistry等等...,由它们构成了完整的SIP系统,而且sipx还支持嵌入式系统,各个模块可以按需取舍。不过可惜是几乎没有任何开发文档。
SVN : http://scm.sipfoundry.org/viewsvn/
Language : C++
VxWorks port : Yes
Win32 port : Yes
Linux port : Yes
Supports RFC 3261 : Yes
Supports RFC 2327 : Yes
Supports RFC 3264 : Yes
Supports RFC 3263 : Yes
Supports RFC 3515 : Yes
Supports RFC 3262 : No
Supports RFC 3311 : No
TCP : Yes
UDP : Yes
SIZE : <4 Mb
License : LGPL
Document : None
Samples : UA,GK,GW

ReSIProcate同样也是由SIPFoundry开发,ReSIProcate最开始起源于Vocal,由于Vocal开始只支持rfc3254,为了支持最新的rfc3261,ReSIProcate诞生了,但现在,ReSIProcate已经成为一个独立SIP协议栈了,它十分稳定,并且很多商业程序都在使用。
SVN : http://scm.sipfoundry.org/viewsvn/resiprocate/main/sip/
Language : C++
VxWorks port : No
Win32 port : Yes
Linux port : Yes
Supports RFC 3261 : Yes
Supports RFC 2327 : Yes
Supports RFC 3264 : Yes
Supports RFC 3263 : Partial
Supports RFC 3515 : Yes
Supports RFC 3262 : No
Supports RFC 3311 : No
TCP : Yes
UDP : Yes
SIZE : < 2.5 Mb
License : Vovida
Document : Few
Samples : None

oSIP的开发开始于2000年7月,第一个版本在2001年5月发布,到现在已经发展到2.0.9了。它采用ANSI C编写,而且结构简单小巧,所以速度特别快,它并不提供高层的SIP会话控制API,它主要提供一些解析SIP/SDP消息的API和事务处理的状态机,oSIP的作者还开发了基于oSIP的UA lib:exosip和proxy server lib:partysip.
CVS : :ext:anoncvs@savannah.gnu.org:/cvsroot/osip
Language : C
VxWorks port : Yes
Win32 port : Yes
Linux port : Yes
Supports RFC 3261 : Yes
Supports RFC 2327 : Yes
Supports RFC 3264 : Yes
Supports RFC 3263 : Yes
Supports RFC 3515 : No
Supports RFC 3262 : No
Supports RFC 3311 : Yes
TCP : Yes
UDP : Yes
SIZE : 400kb
License : LGPL
Samples : UA,GK

[1] [2] 下一页  

文章录入:csh    责任编辑:csh 

综合上述评测,可以看出5种SIP协议栈各有千秋,OPAL有发展潜力,VOCAL比较完善,sipX兼容性好,ReSIProcate教稳定,oSIP小巧而快速。所以要根据应用的不同选择恰当的协议栈进行研究开发。

上一页  [1] [2] 

文章录入:csh    责任编辑:csh

(0)

相关推荐

  • 几种开源SIP协议栈对比

    随着VoIP和NGN技术的发展,H.323时代即将过渡到SIP时代,在H.323的开源协议栈中,Openh323占统治地位,它把一个复杂而又先进的H.323协议栈展现在普通程序员的眼前,为H.323普及立下了汗马功劳.而然当在SIP时代,则出现了群雄割据的状况,SIP相对于H.323简单,灵活,于是各种协议栈层出不穷,下面将详细对比最具有代表性的5个开源项目:OPAL,VOCAL,sipX,ReSIProcate,oS IP OPAL是Open Phone Abstraction Library

  • PHP遍历数组的三种方法及效率对比分析

    本文实例分析了PHP遍历数组的三种方法及效率对比.分享给大家供大家参考.具体分析如下: 今天有个朋友问我一个问题php遍历数组的方法,告诉她了几个.顺便写个文章总结下,如果总结不全还请朋友们指出 第一.foreach() foreach()是一个用来遍历数组中数据的最简单有效的方法. <?php $urls= array('aaa','bbb','ccc','ddd'); foreach ($urls as $url){ echo "This Site url is $url! <b

  • 详解Nginx 和 PHP 的两种部署方式的对比

    详解Nginx 和 PHP 的两种部署方式的对比 2种部署方式简介 第一种 前置1台nginx服务器做HTTP反向代理和负载均衡 后面N太服务器的Nginx做Web服务,并调用php-fpm提供的fast cgi服务 此种部署方式最为常见,web服务和PHP服务在同一台服务器上都有部署 第二种 前置1台nginx服务器做Web服务 后面服务器只部署php-fpm服务,供nginx服务器调用 前置1台nginx服务器,在调用后面多例php-fpm服务时,也可以做到负载均衡 如下图 : 对比 从系统

  • 详解C#实例化对象的三种方式及性能对比

    前言 做项目过程中有个需求要实例化两万个对象并添加到List 中,这个过程大概需要1min才能加载完(传参较多),于是开启了代码优化之旅,再此记录. 首先想到的是可能实例化比较耗时,于是开始对每种实例化方式进行测试,过程如下 实例化方式 1.用 New 关键字实例化一个类 2.用 Activator 实例化一个类 3.用 Assembly 实例化一个类 代码实现 测试环境: vs2019 .NET Framework 4.7 Intel Core i7-10510U CPU 首先定义一个类Per

  • SQLServer批量插入数据的三种方式及性能对比

    昨天下午快下班的时候,无意中听到公司两位同事在探讨批量向数据库插入数据的性能优化问题,顿时来了兴趣,把自己的想法向两位同事说了一下,于是有了本文. 公司技术背景:数据库访问类(xxx.DataBase.Dll)调用存储过程实现数据库的访问. 技术方案一: 压缩时间下程序员写出的第一个版本,仅仅为了完成任务,没有从程序上做任何优化,实现方式是利用数据库访问类调用存储过程,利用循环逐条插入.很明显,这种方式效率并不高,于是有了前面的两位同事讨论效率低的问题. 技术方案二: 由于是考虑到大数据量的批量

  • Android开发之Fragment懒加载的几种方式及性能对比

    目录 1. Support时代的懒加载 2. AndrodX时代的懒加载 3. ViewPager2时代的懒加载 4. ViewPage和ViewPager2的性能对比 Android开发中ViewPager+Fragment的懒加载 TabLayout+ViewPager+Fragment是我们开发常用的组合.ViewPager的默认机制就是把全部的Fragment都加载出来,而为了保障一些用户体验,我们使用懒加载的Fragment,就是让我们再用户可见这个Fragment之后才处理业务逻辑.

  • 利用Python判断文件的几种方法及其优劣对比

    目录 前言 懒人的try语句 传统的os模块 时尚的pathlib模块 几种方法优劣对比 总结 前言 我们知道当文件不存在的时候,open()方法的写模式与追加模式都会新建文件,但是对文件进行判断的场景还有很多,比如,在爬虫下载图片的时候,可能需要判断文件是否存在,以免重复下载:又比如,创建新文件的时候,可能需要判断文件是否存在,存在就先做个备份……所以,学习判断文件是否存在,还是很有必要的. 学习是循序渐进的过程,若能建立知识点间的联系,进行系统性的学习,那将更有助于效果.阅读这篇文章,你将读

  • 分布式锁三种实现方式及对比

    分布式锁三种实现方式: 1. 基于数据库实现分布式锁: 2. 基于缓存(Redis等)实现分布式锁: 3. 基于Zookeeper实现分布式锁: 一, 基于数据库实现分布式锁 1. 悲观锁 利用select - where - for update 排他锁 注意: 其他附加功能与实现一基本一致,这里需要注意的是"where name=lock ",name字段必须要走索引,否则会锁表.有些情况下,比如表不大,mysql优化器会不走这个索引,导致锁表问题. 2. 乐观锁 所谓乐观锁与前边

  • PHP生成随机密码4种方法及性能对比

    方法一: 1.在 33 – 126 中生成一个随机整数,如 35, 2.将 35 转换成对应的ASCII码字符,如 35 对应 # 3.重复以上 1.2 步骤 n 次,连接成 n 位的密码 该算法主要用到了两个函数,mt_rand ( int $min , int $max )函数用于生成随机整数,其中 $min – $max 为 ASCII 码的范围,这里取 33 -126 ,可以根据需要调整范围,如ASCII码表中 97 – 122 位对应 a – z 的英文字母,具体可参考 ASCII码表

  • JS对象数组去重的3种方法示例及对比

    目录 一.去重前后数据对比 二.使用方法 1.使用filter和Map 2.使用reduce 3.使用for循环 三.2400条数据,三种方法处理时间对比 总结 一.去重前后数据对比 // 原数据是这样的 // 去重后数据是这样的 [{ [{ "goodsId": "1", "goodsId": "1", "quota": 12, "quota": 12, "skuId&quo

随机推荐