多媒体的发展

PDF
多媒体的发展/2011年/文章

研究文章|开放获取

体积 2011年 |文章的ID 372591年 | https://doi.org/10.1155/2011/372591

帕维尔Segec Tatiana Kovacikova, 开源产品的调查为构建一个SIP通信平台”,多媒体的发展, 卷。2011年, 文章的ID372591年, 21 页面, 2011年 https://doi.org/10.1155/2011/372591

开源产品的调查为构建一个SIP通信平台

学术编辑器:t . Turletti
收到了 2011年7月29日
修改后的 2011年10月31日
接受 2011年11月15日
发表 2012年1月24日

文摘

会话初始化协议(SIP)是一个多媒体信号的协议,它已经发展成为一个广泛采用的通信标准。SIP到现有的IP网络的集成了IP网络成为一个融合实时和非实时多媒体通信的平台。这个聚合平台集成数据、语音、视频的存在,消息和会议服务到一个单一的网络,为用户提供了新的交流经验。开源社区导致SIP通过开源软件的开发采用SIP客户端和服务器。在本文中,我们提供一个开放SIP系统调查,可以构建使用公开可用的软件。我们确定了SIP服务开发和编程的特点、服务和应用程序的SIP-converged平台,支持SIP功能和最重要的技术。我们提出一种先进的聚合IP通信平台,使用SIP服务交付。平台支持的音频和视频通话,连同媒体服务,如音频会议、语音信箱、存在和即时消息。使用SIP应用程序编程接口(api),允许部署先进的综合服务平台。与开源软件平台实现。 Architecture components run on standardized hardware with no need for special purpose investments.

1。介绍

IP网络模型的成功与它的许多有吸引力的服务已经开始一个基于IP技术的网络收敛的过程。由于这种趋同,人们相互间的交流模式已经改变。新的IP网络技术及其进化导致交流平台能够提供许多服务和应用程序。多媒体技术已经成为标准,许多先进的沟通平台,特别是对语音IP (VoIP)。建立自己的多媒体平台音频和视频电话,音频会议,存在,消息从来都不是一件容易的事。此外,这些新的多媒体技术为创建创新提供新的机会和有吸引力的服务。个人服务可以集成运行实时和非实时服务,从而提供一个融合统一通信环境任意组合的服务,应用程序、设备和网络。

会话初始化协议(SIP) [1提供一个开放的多媒体通信协议。它被认为是一个关键协议对网络收敛。SIP促进建筑融合IP通信网络集成和配合现有的电信网络和设备。SIP技术仍在不断发展之中,但是核心规范完全标准化,采用,并被广泛实施。有许多商业产品和通信平台基于SIP的市场上,包括那些来自思科、微软、亚美亚,Radvision。SIP也带来互联网多媒体实时通信方法;因此,SIP通信可能被视为只是一个IP服务,运行在标准的硬件和操作系统和中间件标准。由于这种方法,有许多高性能和高质量的软件产品提供了某种形式的开源或免费软件许可证。这些产品与相应的软件包可用于创建丰富的多媒体融合网络。

在这篇文章中,我们确定关键协议,技术和服务,我们提出了一个先进的聚合IP通信平台使用SIP服务交付。这个平台是基于SIP和开放补充通信协议作为开源软件实现。平台集成了个人的开源软件包支持音频和视频通话以及媒体服务如音频会议、语音信箱、存在和即时消息。使用SIP应用程序编程接口(api),平台促进开发和部署先进的click2call和web-initiated会议等综合服务。一个NAT遍历也提供了解决方案。所有体系结构组件在标准化的硬件上运行而无需特殊目的投资。该平台并不是一个简单的SIP PBX,而是一个强大、灵活、容易扩展开源交流平台,是可利用的在很多方面。

本文不提供比较详尽的组件的特性或一个完整的设计指导。为更好地理解它所需的技术和功能,可以将SIP通信平台。平台促进构建自己的试验台,可用于教育和研究在大学和高中。

2SIP功能,服务开发和编程突出显示。SIP-converged平台的服务和应用程序介绍了部分3。节4,最重要的技术支持SIP功能标识。提出SIP-converged平台及其逻辑组件和适当的开源产品描述部分5。最后,结论部分提供了6

2。创建SIP服务

SIP的主要好处之一是它能被用于创建新的通信服务。有许多方法用于创建SIP服务可扩展平台功能。下面是这些方法的概述。

2.1。SIP基线协议机制

与经典的电话在PSTN、ISDN、SIP端点不哑终端。因此,许多服务是实现电信网络或PBX环境中可以使用SIP提供基线功能在SIP服务器和/或SIP端点。一系列IETF没有指定的服务,与传统的电信世界。几个最好的当前实践rfc存在描述的部署服务,如呼叫转移、呼叫保持,音乐暂停,等叫停车,叫皮卡。

2.2。新方法和标题

SIP设计容易扩展;因此,新功能和服务可以通过定义新的SIP实现方法或SIP header。这些新的方法或头不需要要得到所有SIP服务器的支持。如果一个SIP代理和一个未知的方法或头接收请求,它将代理请求。新方法已经定义(信息、PRACK、发布、SUBSCRIBY通知,信息,参考,更新)作为基线SIP的扩展规范。这些新方法提供服务,如存在,即时消息,并与电信网络交互工作。

2.3。使用专用工具编程SIP服务

SIP服务可以由服务实现逻辑,创建和实现SIP体系结构。一般来说,可以使用任何编程语言。逻辑是用于处理一个特定的SIP信令消息流对特殊条件由于特殊事件做出反应。这些事件可以触发接收特定的SIP消息,或一口头值,或一个特定消息的参数2]。接口定义,包括调用处理CPL Language-SIP [3),一个共同的网关Interface-SIP CGI (4],SIP servlet [5),而综合Networks-JAIN API (Java API6]。使用编程api的开发SIP通信服务和应用程序非常类似于它的应用程序开发。编程api通常提供的SIP应用程序服务器

3所示。先进的SIP应用程序和服务

本部分调查服务和应用程序提供SIP-converged通信平台的一个重要组成部分。

3.1。SIP即时消息和存在(简单的)

即时通讯(IM)服务与业务服务已成为占主导地位的基本的VoIP服务。已经建立,这些服务将为21世纪的“拨号音”(7]。由于许多专有IM服务,有一个努力在IETF标准化存在和即时通讯服务。目前,两个IETF工作组(WG)专业IM和存在服务:可扩展消息传递和到场协议工作组(xmpp WG) [8)和SIP的即时消息和存在利用扩展(简单wg) (9]。这导致了两个协议的定义可用于即时通讯和业务服务:XMPP协议(非常受欢迎的继任者,但仍然专有jabber协议)和简单的即时通讯和存在利用扩展(SIP)。

简单的雨伞覆盖超过十rfc有关存在和消息传递。简单介绍两种服务,存在和即时通讯,这在逻辑上是耦合在一起。我被定义为一个快速(接近实时)之间的短消息交换的参与者。页面有两个IM SIP解决方案模式和一个会话模式(10,11]。页面即时通讯模式,在RFC 3428中定义的(12),使用一个新定义的文本communication-MESSAGE SIP方法。消息的方法是直接发送到参与者,没有特定的SIP会话(没有会话建立对话框),见图1。会话模式假定IM消息交换是建立一个会话的一部分通过某种方法(如对接协议)。会话类型的即时通讯工具实现,SIP消息可能是会话中继协议(厂商建议零售价)13,14]。厂商建议零售价是一种基于文本的面向连接的即时消息传输协议传输任意内容(二进制)在对等的基础上。厂商建议零售价并不是一个独立的协议,但它使用自己的消息通信(发送和报告)。

SIP的存在是一个服务,可用性和用户交流的意愿。最初,只有两个州是网上和线下。如今,面前是一个功能丰富的服务,提供各种各样的信息和功能。简单的架构内的状态服务器使用一个事件通知框架(15]。扩展的主要SIP事件通知框架规范允许SIP用户代理请求通知从远程节点表明某些事件发生。它还使用一般的即时消息和存在(IMP)框架中定义的(10,11]。标准化两个新的SIP事件通知扩展方法,订阅,通知,和一些新的标题(15]。SIP事件通知框架存在通知中指定的RFC 3856 (16)定义了SIP的“端到端”模式的存在。该模型不是非常强大;因此,框架扩展到允许积极推动业务信息与一个新的SIP网络方法发布(17]。这个模型SIP的存在称为“基于主体”或集中的模型。然而,提供典型的IM联系人列表等服务,实现简单的SIP使者采用XML配置访问协议(XCAP)协议的家庭。XCAP允许客户端读、写和修改应用程序配置数据存储在服务器上的XML格式(18];信息,这信息是存在。

实现完整的简单的标准(见图2)是一项复杂的任务,然而很少有实现。许多SIP软件供应商,由于简单框架的复杂性,实现更简单和更功能丰富XMPP协议到他们的产品中。

3.2。媒体应用程序和服务

在一个SIP网络中,需要先进的媒体处理功能可用。这些功能使我们能够构建统一信息和统一通信等有趣的应用程序。媒体功能包括公告、消息记录服务交互,媒体混合和多党沟通(19]。媒体处理通常是由媒体服务器。语音信箱,音频会议,交互式语音应答(IVR)是最受欢迎的服务使用媒体的功能。通信与媒体服务器,在RFC 6230中定义的,使用SIP (20.]。RFC 6230中描述了一个框架,它适用于与分布式应用程序逻辑架构和媒体处理。

语音信箱是一个服务,允许发送、存储和检索音频信息,就是象一个电话应答机。实现可能有所不同,但通常每个SIP用户关联到一个语音信箱,这样,当调用这个用户并没有回答(因为他是忙或离线),然后调用者重定向到一个语音信箱系统,并被要求留个口信。当得知他有语音信息,例如,通过SIP事件包,然后被可以联系他们的语音信箱服务器检索消息。语音信箱服务基于一个标准的SIP统一资源标识符(URI)解决方案(21]。语音邮件系统是一种很常见的服务IP PBX解决方案。

会议服务是另一个非常受欢迎的服务,它可以集成到SIP-converged平台。会议是一个服务和许多参与者支持多点通信,基于策略的管理,资源管理,通知。的几款SIP会议已确定(22]。这些模型包括集中式、端点混合,完整的网格,和多播SIP提供本机支持多播通信;因此,这是一个很好的选择会议。不幸的是,由于缺乏一个多播通常是不可行的多播的基础设施。因此,集中式模型,基于星型拓扑与点对点信号和中央媒体混合,是经常使用的23]。更多细节的SIP会议和高水平的需求提供了RFC 4353和RFC 4254 (22,24]。

SIP IVR是基于SIP应用程序,它提供了自动调用与人类交互基于双音多频(DTMF)语气命令。IVR提供了很多可能性(25),通常是在企业环境中使用。最近,RFC 6231已经发表(26]。RFC 6231定义了一个媒体控制通道框架交互式语音应答(IVR)。这个框架还定义了对话框管理请求元素准备,开始和终止对话框的交互以及相关响应和通知满足IVR需求。

4所示。补充网络技术

在本节中,主要的调查补充SIP体系结构提供了所需的网络技术。

4.1。域名服务器(DNS)

SIP是紧密耦合的域名服务器(DNS)。SIP利用DNS在很多不同的方式。SIP解决基于SIP实体被SIP标识统一资源标识符(uri) [27]。SIP URI包含一个用户名(或服务名称)和一个主机名,“@隔开。“有确定了三种类型的SIP URI,记录一个地址(AOR),一个完全限定域名(FQDN),和一个全球路由用户代理(UA)的URI。SIP客户端解决SIP URI到一个IP地址,端口,和下一跳的传输协议实体传输协议的选择尤其有趣,因为SIP可以运行多种传输协议,包括TCP, UDP, SCTP, TLS / TCP, TLS在SCTP, SCTP IPsec。DNS解析过程发生在不同的SIP实体(即。、服务器和端点)在一次会话。一个简化的拓扑和一些SIP专用小交换机实现,一个标准的DNS一个记录可能是足够的。记录提供了一个名称和一个或多个IP地址之间的映射。然而,仅使用记录不建议这么做,因为它不支持环境与不同的传输协议,端口号,和服务器。SIP的推荐DNS部署基础设施使用DNS服务记录(DNS SRV) (28)或命名权限指针(NAPTR) DNS资源记录(29日]。NAPTR RR允许客户区分应该使用哪个协议与映射的资源。SRV RR允许管理员配置多个服务器一个SIP域和找出正确的端口号。

RFC 3263 (30.)提供指导的SIP终端定位适当的SIP服务器。根据指导方针,SIP端点应该首先使用NAPTR RR确定应该使用哪个传输协议与各自的SIP服务器进行通信。SIP服务器的名称是由一个域名从SIP URI标识。NAPTR RR允许域广告不同服务器的各种传输协议。NAPTR RR结构指定顺序和优先领域,它允许SIP域定义的首选传输协议及其备份解决方案。一次解决过程完成后,SIP端点知道哪个传输协议支持和哪个服务器端口提供服务(SRV)。在第二步中,端点解析SRV记录找到/ AAAA的名字。SRV RR的结构允许建立一个与前端负载均衡服务。最后,端点查询一个或AAAA级记录学习适当的IPv4和IPv6地址。现在,端点信息(见图3与正确的SIP服务器连接所需)。

可以使用DNS不仅对学习注册/代理服务器的IP地址(es),但也为媒体服务器地址,ENUM映射,或眩晕/ /冰服务器。公司计划实现SIP在IP基础设施应该有自己的DNS服务器,配置适当的资源记录。如果公司希望与他人互动,那么它应该有自己的DNS服务器注册域(s)。

4.2。NAT遍历

最初,SIP没有反映出安全的主要原则,现代IP网络的一个重要问题。然而,随着全球IP网络的可用性,安全已经开始被越来越多的考虑。许多安全设备,轻量级的如NATs或者防火墙等重型的,市场上出现了。RFC 3235 (31日)已经产生了使应用协议设计更NAT友好。不幸的是,SIP违反大多数的建议,因为应用程序层协议,它与L3 IP地址(SIP和SDP)在其应用程序消息。因此,实现SIP信令和媒体功能到一个安全的网络并不是一个简单的任务。NATs和防火墙等安全设备在SIP网络调用一些并发症。两个问题被identified-those相关信号流和相关媒体流。信号流部分解决的问题使用TCP的UDP和使用“接收”参数的“通过”的标题。NAT的遍历,许多方法已确定。他们可以分为两组。

第一组依赖SIP端点检测的NAT和来确定它的类型。这些功能必须由SIP实现无人机(客户端)和特殊的网络服务支持服务器。这些服务器帮助UAs NAT检测任务。这组的解决方案被称为“影厅NAT遍历”,包括解决方案如眩晕、和冰。眩晕(NAT)会话遍历实用程序是一个IETF标准化解决方案(32),允许一个SIP UA检测的NAT和学习的公共IP地址和端口分配给这个SIP UA NAT-ing过程中。内部公共IP地址和端口然后使用SIP和SDP头本地私有IP地址,而不是设备。不幸的是,眩晕不工作在所有的情况下。例如,在对称NAT眩晕不工作,眩晕有问题时一个SIP终端多个IP地址。第二个IETF提出的解决方案是把(遍历使用继电器在NAT)或眩晕继电器33]。是一个客户端-服务器协议,允许一个SIP UA学习公共IP地址(中继传输地址)的服务器,请求它作为继电器的实体。这个地址是用来传送传入的媒体包(见图4)。通信的客户机可能请求服务器同行将转播,可能控制传送的是如何实现的。客户端可能学习通过DNS服务器的IP地址SRV记录或通过其他方式。客户可能利用UDP、TCP或TLS连接到服务器。把服务的利用可以保护使用身份验证。把作品与UDP协议;但是关于TCP的工作仍在进行中。把解决NAT遍历问题,但引入了几个新的”问题。“把服务器是一个中央故障点;因此应可靠地部署。此外,服务器必须所有媒体转发数据包,传入和传出; therefore, there are some TURN system performance issues that can occur.

因此,第三种解决方案,称为冰(交互式连接建立),推荐。击晕,然后是冰的部分解决方案。冰是由IETF RFC 5245(指定的34)和RFC 5768 (35]。冰很简单;它允许一个SIP UA收集“候选人的沟通”,提供远程党,因此最大限度地提高成功的机会。冰谈判有几个阶段。首先,SIP客户端收集候选人。在这个阶段,SIP客户端发现所有地址可用于通信。有三种类型的候选人:许多候选人代表客户的服务器IP地址,反身候选人已经解决从眩晕的地址,和一个转发候选地址已从客户机把继电器的分配。客户端分配优先级为特定候选人和将它们发送给远程的政党开始offer-answer谈判过程。接受远程对等候选人后,客户端本地候选人搭配收到远程候选人。客户端开始检查连接的对每一个候选人。 Finally, the session is established.

第二组的NAT遍历解决方案被称为“远端NAT遍历。”这组认为的SIP代理作为一个实体需要关心NATs和防火墙,它应该像往常一样使用本地地址进行通信。这个解决方案需要NAT和防火墙设备实现SIP友好应用层网关(ALG),通用即插即用(“),特殊设备的部署在边境之间的私人和公共网络部分作为一个背靠背的用户代理(B2BUA),或部署的特殊实体配合SIP服务器在公共网络和作为媒体中继服务器(RTP代理/媒体代理)。这些解决方案通常是专有的,尽管“似乎是一种很有前途的技术得到广泛的支持,许多供应商(微软,消费电子产品供应商)和标准化36]。然而,“有很多安全问题,因为“不实现任何安全机制及其部署被认为是有风险的。

SIP / NAT方案帮助安装所需条件成功的传出和传入的信号和媒体会话建立情况一口UA NAT。NAT设备后面介绍的问题反过来traffic-how达到SIP端点,而背后NAT为传入会话。为了解决这个问题,RFC 5626 (37]建议的维生机制方案用来保持NAT SIP终端之间的通信的翻译及其服务SIP服务器(注册或代理)打开。这个扩展假设一些NAT翻译,由于通信发起SIP终端与服务SIP服务器(例如,那些在SIP登记)将保持打开状态;因此,这种转换将重用通过NAT传入的SIP请求路由到SIP端点。NAT翻译保持打开状态保持消息传输,即客户机到服务器“ping”维生和相应想一想“乒乓球”消息(37]。提出有两种维生机制:CRLF维生和眩晕维生消息交换。

4.3。SIP安全

SIP是一个应用层协议,一方面暴露所有的ip网络安全问题,直接关系到SIP另一方面的问题。然而,作为一个IP堆栈协议,SIP可能重用整个投资组合的安全机制已经为IP网络开发。SIP安全威胁可分为三类(38]。第一类是继承了古典与知识产权相关的威胁和漏洞威胁如重播攻击、拒绝服务(39),欺骗、嗅探和中间人攻击。第二类包括一些SIP-specific漏洞提高SIP的性质,包括攻击如恶意终止并注册请求。第三类包括漏洞由于SIP应用程序的复杂性,服务器,或其他组件,如实现漏洞由于SQL注入或缓冲区溢出(38]。保护一个SIP架构对所有这些安全威胁是一项复杂的任务,因为它包括保护信号会话和媒体流的保护。

保护信号会话,SIP提供了一些内置的安全机制,例如,身份验证、数据完整性和机密性。它们包括质疑身份验证机制,他们安全的MIME (S / MIME)机制,和安全SIP模式(SIP)与传输层安全(TLS) [1]。SIP认证是基于HTTP身份验证机制,在一个请求的发起者可能挑战提供其身份的保证。有两个版本的HTTP身份验证:HTTP基本和HTTP摘要认证。HTTP基本身份验证不支持SIP版本2,因为它发送一个密码明文。HTTP摘要认证是一个质询-响应机制使用加密散列(如MD5)的用户名/密码/随机nonce价值领域。HTTP消化提供了某种程度的重放攻击保护与现时标志值,这是有效的一段时间,它包含一个“质量的保护(回城)”参数。使用HTTP摘要认证所需最小的保护机制,但取决于使用强密码。在一个基于SIP的网络中,HTTP消化机制通常发生在UA和SIP服务器之间(代理注册,“无人飞行系统”),用于客户端身份验证和授权。使用HTTP摘要,用户保证其证书的有效性。然而,SIP header(如安全至关重要的联系,,)提供。提供SIP信号完整性保护和机密性,可以使用S / MIME和TLS。

的S / MIME提供了一个一致的方式发送和接收用户之间的安全数据基于认证等机制,消息完整性和数据机密性(加密)。S / MIME使用证书持有人的断言被一个终端用户的地址。这些证书相关的密钥用于SIP消息的签名或加密的身体。可以是公共或私人密钥交换机制。RFC 3261指定了三重数据加密标准(3 des)密码套件和SHA1(安全散列算法)签名算法作为S / MIME的强制实现。RFC 3853 (40)更新指导S / MIME的高级加密标准(AES)作为一个加密算法,RSA(李维斯特,Shamir和Adleman)作为数字签名算法,和SHA1算法[消化40]。相比3 des、AES是更快的内存需求较低的机制,这使得它适合于移动设备,例如。AES也需要使用TLS在SIP,结合密码套件要求和简化了SIP安全实现。SMIME为SIP消息体,提供端到端的机密性部分,SIP header的机密性,完整性保护身体和身份验证发送方的消息41]。目前S / MIME不是广泛部署在SIP,问题主要是由于证书分布。RFC 6072 (42)解决这个问题,提出了一种发现其他用户的证书和认证检索和认证管理的机制。它使用一个“凭证服务”结合SIP标识规范(RFC 4474)用于管理用户的私人和公共证书和允许SIP用户存储、更新和检索他们的证书SIP消息发布。使用凭证服务SIP无人机可能订阅其他SIP UA证书交付给订阅UA使用SIP消息通知。由于SIP身份规范,SIP用户不允许使用证书签署的任何知名认证机构同时还强烈绑定用户的身份证书。

安全SIP信号通信的另一个选择是使用TLS(传输层安全)43在传输层)。TLS已经用于SIP安全(SIP)模式。TLS提供机密性、完整性和重放攻击保护服务。TLS协议由两层组成。上层由从TLS握手协议和应用程序数据协议实体提供安全服务。TLS握手协议的握手协议用于对等认证和密钥交换,警报协议用于错误条件信号,和更改密码协议用于通知新密码和钥匙的使用。底层,称为TLS协议,位于顶端的传输协议(TCP、SCTP)。TLS协议将消息记录的上层实体,然后细分,并应用所需的处理如压缩、MAC计算,和加密。最后,它封装了它通过TLS连接并发送给接收方,应用反向处理收到的消息。在SIP体系结构中,可以使用TLS在敌手的基础上(UA和SIP服务器之间或SIP服务器本身),与SIP实体的信誉提供签名的证书。 The deployment usually uses one unencrypted channel on the port 5060 and the secure one on the port 5061. TLS runs over connection-oriented protocols such as TCP or SCTP as it relies on their reliable transport features. Currently, there are only few SIP clients which smoothly support TLS. TLS cannot be used with UDP because the lost or reordering of datagrams breaks TLS handshaking and TLS record layer functionalities. When UDP is preferred as a transport protocol, the datagram TLS (DTLS) is used. DTLS, standardized in RFC 4347 [44),使通信隐私数据报协议。迪泰是基于TLS协议,它提供了安全保障。

最后,在网络层,可以使用IPSec安全SIP通信。IPSec由三个主要组件:从一个数据飞机组件,策略组件和信号组件。数据平面组件启用运输保护。有两个可用的安全机制,验证头(啊)和封装安全载荷(ESP)。啊提供服务,如完整性保护和数据源认证,和可选的重放保护。ESP提供了相同的服务啊。另外,它还提供了机密性。啊和ESP可能使用不同的加密算法。一个政策组件定义安全协会(SA)为一组IPSec的规则。SA定义的参数集IPSec邻居不得不同意。 As parameters, packet matching criteria, mode of operation, type of security protocols, cryptographic algorithms, integrity algorithms, and keys have to be used with a particular packet flow exchanged among IPSec neighbours. A signalling component provides IPSec neighbours’ authentication, SA parameters negotiation, and the key exchange procedures. As a signalling protocol, the Internet Key Exchange (IKE) protocol is used. IPsec may operate in two modes, a transport mode and a tunnel mode. The establishment of IPSec tunnel has two phases. During phase 1 (IKE Phase 1), the IKE protocol is used to negotiate IKE SA parameters used with its own key management exchange procedures. During phase 2 (IKE Phase 2), IPSec SA parameters themselves are negotiated. IPSec is supported by an underlying operating system, while the integration to a SIP application is not usually required. IPSec works for all, UDP-, TCP-, and SCTP based SIP signalling. Since SIP routing entities on the signalling path read, add, or change the information in SIP headers, IPSec for SIP is usually applied on the hop by hop basis. IPSec may also be used to protect the RTP media on the end-to-end basis without the active involvement of SIP UAs.

预计一个安全通信架构保护不仅信号信息,而且媒体流量。保护媒体流,实时传输协议(RTP) [45)作为主要载体,一个新的RTP媒体资料(RTP / SAVP)已经提出了安全实时传输协议(SRTP) [46]。SRTP是一种有效的计算成本较低的安全协议,内存和带宽需求具有良好的互操作性的结果。SRTP提供机密性、完整性、重放攻击保护、和数据来源认证为RTP和媒体服务器流量(46]。机密性是通过加密RTP载荷。RTP定义了AES和零加密方法。零方法时使用不需要加密。AES是默认加密方法可操作的两种模式,分段整数计数器模式和这种模式。身份验证算法可以保护整个原始RTP包的完整性。认证确保数据包沿着路径被修改和插入。HMAC / SHA1,用作强制性消息身份验证算法。推荐使用10-byte身份验证标记一个RTP流保护,但是,VoIP包的小尺寸减少的开销,可以使用一个4字节的认证标签。如果使用,验证操作执行后整个RTP数据包加密保护。 SRTP uses two types of keys: session keys and master keys. All session keys used for authentication and encryption can be derived from a single master key. SRTP standard does not define how the master key is exchanged. It is responsible of a key exchange protocol. Currently, several key exchange protocols are available, for example, the SDP Security Descriptions (SDES) protocol [47)、多媒体互联网键控(米奇)48),数据报TLS(迪泰)49),和ZRTP协议(50]。SRTP扩展了原始RTP报头和两个字段,一个可选的主密钥标识符(MKI)和推荐认证标签。SRTP MKI标识主密钥是用来获取当前会话密钥用于加密和/或消息身份验证。身份验证标记用于携带消息身份验证数据。

DNS服务在SIP网络中起着重要的作用。一般来说,一个DNS服务沉重的负面影响SIP和IP网络的操作。DNSSEC DNS用于解析DNS安全扩展问题。DNSSEC,最初在RFC 2535中定义的(51),旨在验证查询结果的真实性和完整性的签署。它使用公钥加密(不对称)和一组特殊的DNS RR法案同样启用域名系统安全扩展意识到客户端(解析器),以确保验证预期的响应请求的域名的所有者。这有助于避免当服务器试图重定向服务器客户端恶意。法案同样然而,域名系统安全扩展作品完美只有在整个DNS层次签署。这不能期望在不久的将来,因为根区最近签署的,在2010年7月。目前,DNNSEC实现策略预期的连锁离岛DNS安全互联通过代表团点。

获得了SIP通信环境是一项复杂的任务可以通过实施各种安全机制在不同级别的通信栈。安全无法保证一个机制或协议。提高安全性的一个SIP架构,上面提到的机制组合使用(见图5)。

4.4。高可用性

SIP技术是现在经常使用。SIP通信系统,特别是大型企业,必须减少由于软件或硬件故障服务不可用。因此,高可用性(HA)的一个重要特性是一个通信体系结构。为了避免单点故障,备份组件一起合适的故障转移机制必须实现。哈哈不是具体的技术,但一个应该达到的目标。SIP HA问题核心SIP网络的不间断可用性组件提供SIP服务尽管链接中断,设备故障,或攻击。

从一个SIP网络体系结构的角度来看,有几个设计方法确定了实现高可用性的SIP网络组件(52]。第一种方法是基于静态的组合列表或DNS SRV记录(服务)。第二种方法使用基于硬件或软件负载平衡机制。第三种方法利用冗余设备的先进故障转移情报。所有这些方法提供网络弹性通过冗余设计部署,通常一个备份系统部署能力提供服务的主人或主系统的失败。

4.1.1。静态列表

这种方法利用SIP客户的特点,可以配置一个静态列表的替代SIP服务器。客户端试图联系主服务器,如果它没有反应,然后客户端联系人备份服务器。然而,这个SIP UA特性并没有受到广泛支持。

以域名系统哈。以域名系统哈是一个非常简单的解决方案利用中小学SIP服务器,而HA机制与正确配置DNS服务使用SRV记录。DNS NAPTR和SRV记录允许操作员调整个人的体重和优先级与主服务器和辅助服务器相关的记录和控制DNS解析过程。DNS服务器处理SIP客户端请求并提供DNS的反应,也提供的信息分配的权重和优先级。SIP客户端然后选择SIP服务器联系。这个解决方案需要DNS SRV SIP客户支持,支持DNS记录解决是不够的。以域名系统哈很简单;然而,有些问题来自一些DNS服务的特性,如缓存DNS解决答案,慢反应,采用故障变化。

10/24/11。负载平衡

SIP负载平衡机制分配SIP多个SIP服务器的流量以达到最佳性能可伸缩性、避免过载,HA的服务支持。基于硬件的负载平衡解决方案是在商业产品中实现。基于软件的解决方案使用专用服务器的主要任务是分派到下一个跳SIP服务器的通信。这些交通调度程序(负载平衡器)可能使用不同的选择机制,如循环(RR)计划。另一种方法使用加权或自适应平衡方案,请求分布比例,分配权重。实现交通调度员应考虑某种检查机制,控制服务器的可访问性。如果发生故障时,应停止派遣SIP消息服务器不可用。

第三种方法假设一些智能设备保护。虚拟路由器冗余协议(VRRP)、标准化在RFC 2338 (53),提供了选举过程,一个设备当选活动和其他备用。当使用VRRP心跳消息,一个活跃的服务器监控备用服务器。活动服务器发生故障时,备用服务器需要活跃的角色。两个服务器有相同的虚拟IP地址,但真正不同的IP地址。VRRP标准化机制适合一对冗余(1 + 1)服务器。VRRP有一个名为VRRPd的开源实现。作为替代VRRPd,开源的linux实现鲤鱼(公共地址冗余协议)(UCARP)可以使用。鲤鱼是一个开源的替代思科私有HSRP,主要实现对BSD (Berkeley Software Distribution)。非常类似于VRRP操作机制。然而,VRRP和鲤鱼有实施限制; the standby backup server must decide correctly when the active server does not work. When the active server is “dead,” the failover mechanism must make sure that a “dead” device will not receive any further messages. This is a challenging task, which needs actualization of the different network information, such as LAN switching tables, ARP tables, and DNS caches. Another issue is how to replicate the stateful SIP knowledge from a previously active server to the standby server. This has not been considered in the specification. Thus, VRRP and CARP are usually suitable for layer 3 connectivity checking.

还有其他的软件解决方案,允许监视彼此的可用性。Linux HA项目(54)就是其中之一。Linux HA项目为Linux提供了一个高可用性(集群)的解决方案,FreeBSD, OpenBSD, Solaris,和Mac OS x项目的主要软件是心跳,gpl许可的便携式的集群管理程序对于HA集群,3.0.4实际可用的版本。心跳是一个守护进程,提供了交流和会员集群基础设施服务。心跳提供对等的信息存在或消失过程在其他机器上的集群。在心跳基础设施、起搏器集群资源管理器必须部署。起搏器是一个开源HA集群资源管理器适用于这两个小型和大型(55]。起搏器启动和停止服务,集群使哈。也有另外的解决方案,例如,开放电信平台(OTP)由爱立信和开源OpenSAF服务哈,可以使用。然而,这仍然是一个悬而未决的问题在服务器的同步。一个分布式复制块设备(DRBD)可以使用。DRBD是基于软件的,复制存储机制镜像的内容块设备,如硬盘,分区和主机之间的逻辑卷在一个集群中。DRBD可以被看作是一个基于网络raid系统。然而,它并不复制动态状态,通常保存在RAM。通常,派工用于同步数据库服务器集群中。因此,一些机制,使SIP若干SIP服务器之间同步状态信息是必需的。 This can be achieved with an entity which replicates SIP messages.

我们的测试个人机制模拟硬件故障宣称与UCARP不可用的平均时间是3,75年与VRRPd 4, 12秒,心跳4,49秒心跳起搏器5,7秒。优化配置参数可以减少故障转移到2的时候,只有心跳25秒。软件故障模拟的心跳起搏器,取得了以下结果:4,75秒起搏器的标准设置和2,73秒的优化配置。

5。提出了SIP通信平台

在本节中,我们确定了一个基于sip的聚合平台的关键组件,满足上述要求。平台可以实现SIP服务如IP语音和视频、语音信箱、会议、即时消息传递和存在,它允许设计、实现和部署新的综合服务。平台支持信号的近端和远端NAT遍历和媒体流。通信平台是基于IETF标准和使用开源软件(56)组件。

5.1。该平台提供的功能和服务

该平台提供了以下服务:(我)音频和视频通话,(2)媒体服务,如音频会议、语音信箱和IVR,(3)即时通讯和基于简单的存在,(iv)它允许编程通过标准化的api的应用程序服务器或新服务开发新模块和服务使用其他手段(如专用api),(v)NAT遍历解决方案允许连接/用户位于NAT的后面,(vi)与其他IP多媒体系统互连(瘦,H.323)或消息传递平台(XMPP),(七)注册和查找服务用于注册和定位SIP服务,(八)多个SIP设备/ SIP与并行分支。

平台可能是多余的,因为它应该重用HA机制或潜在分层冗余的网络设计。然而,冗余需要追加投资所必需的冗余服务器和网络组件。强烈建议部署包括DNS服务器。平台允许与其他类型的互连通信网络(GSM或PSTN、ISDN等),但额外的投资需要专门的硬件(如网络接口卡片,路由器与电信网络接口)。这个平台可以与其他IP通信平台互联H.323或IMS(例如,OpenIMS)。从安全的角度来看,平台使用摘要式身份验证和凭证存储在一个数据库服务器。这些凭据应该用于不同的目的(IM,登记、呼叫允许存在,路由,等等)。SIP组件可能会提供一些保护机制对DoS攻击(黑名单、过滤器),但安全应包括网络基础设施(如防火墙和路由器周长与白名单)。该平台可以提供信号和媒体流保护使用TLS和SRTP的客户支持。它可以很容易地扩展和负载均衡技术。 The platform provides IPv4 and IPv6 connectivity.

5.2。平台的组件

平台包含许多不同的软件组件交互在一起来提供所需的服务和功能。认为这些软件组件运行在一个标准的电脑或服务器电脑(没有专门的硬件)。以下组件已确定(见图6)。

5.2.1。SIP端点(应用程序或客户端)

SIP客户使他们的用户访问平台服务。端点至少应该提供HTTP摘要认证,音频或视频通话,基于简单的存在,和消息传递。先进的SIP终端可以使用TLS和SRTP安全特性,通过XCAP联系人管理,直接语音邮件访问。客户端可以使用眩晕NAT。

5.2.2。SIP服务器

SIP服务器提供的功能一个SIP注册和SIP代理服务器。SIP服务器作为SIP注册允许注册和认证的客户至少与HTTP摘要认证模式。凭证连同位置数据(IP地址和端口)是存储在数据库中。不同数据库类型应该支持。SIP服务器作为SIP代理应该允许快速和强大的SIP信号处理和提供灵活的配置SIP信号处理,这有助于整合其他服务器实体,如应用程序,媒体服务器和网关使用SIP通信接口。如果需要更灵活的调用处理,主要功能的可扩展性的SIP服务器应该支持(比如SIP API和编程语言)。SIP服务器应该支持不同的网络层协议(IPv4和IPv6),不同的传输协议(TCP, UDP SCTP inter-SIP代理连接),和安全协议(TLS跳了跳连接)。出于测试目的,可以使用自签名证书。为生产部署,众所周知的权威证书必须被使用。SIP服务器应该支持DNS查找在RFC 3263中定义的(30.]。SIP服务器应该支持代呼叫详细记录。

5.2.3。媒体服务器

媒体服务器提供媒体服务处理所需的功能,如打公告,语音录音,语音信箱存储、语音邮件访问和播放出来,媒体混合媒体转码,和音频会议。媒体服务器应该支持自助服务配置和定制。媒体服务器应该支持不同的网络、运输、和安全协议,可以通过客户端访问平台服务。提供语音信箱账户应该集成在SIP服务器账户管理功能。

5.2.4。SIP状态和IM服务器

这些服务器是一个简单的架构的一部分,提供集中的解决方案处理存在的用户和即时消息交付SIPMLE框架中被定义。的平台,我们使用集中的业务解决方案,而不是一个点对点的存在。

5.2.5。XCAP服务器

XCAP服务器是SIP业务解决方案的一部分,允许客户端读、写和修改业务数据(例如好友列表)存储在服务器上的XML格式和同步多个无人机。XCAP服务器也用于处理存在授权策略。通过HTTP访问XCAP服务器,应该意识到通过SIP客户端接口(必须执行)或通过用户个人的HTTP接口。

. 5.2.6。应用服务器(如)

SIP作为用于提供SIP服务和应用程序开发和托管。SIP应该提供一些api为SIP服务设计开发(57]。如果需要,SIP作为可以作为一个完全操作SIP服务器,但通常是用于开发和提供增值服务,如click2call web会议,第三方呼叫控制器。

5.2.7。网关

网关的目的是提供连接到其他平台。有不同类型的网关根据必需的功能。我们平台使用软件包,允许部署之间的互连信令网关SIP和H.323或SCCP网络互连和部署一个小鬼网关的简单与XMPP。连接到其他类型的网络与不同的通信栈需要特殊的硬件,比如网络接口的网关。

5.2.8。NAT遍历解决方案的组成部分

NAT遍历组件提供正确处理信号所需的功能为用户和媒体流NAT背后的两个方向。我们建议实现影厅遍历解决方案(基于客户机)由部署眩晕,把服务器和客户机将这些解决方案纳入一个SIP客户端软件。服务器必须被放置在公共网络的一部分。这些服务器允许客户检测的NAT设备一起使用影厅NAT类型的NAT。解决办法是有限的几个当前可用的开源解决方案。因此,我们建议实现远端遍历解决方案(一个基于服务器)。远端NAT遍历由媒体实现中继服务器,在合作与SIP服务器允许绕过NATs媒体流。通过媒体传递服务器不需要SIP客户端需要注意的NAT环境。此外,它适用于任何类型的NAT。媒体中继服务器应该使用IPv4和IPv6互相配合实体确保客户使用不同的IP协议的互连。然而,媒体中继服务器必须是交通总量的比例适当的媒体。因此,许多并发媒体流媒体服务器性能可以解决使用多个服务器和一些负载平衡机制。 We also recommend to use far-end NAT solutions in situations where an IP client with running SIP UA uses several network interfaces with several IP addresses, but without the possibility to setup connectivity preferences.

5.2.9。数据库服务器

数据库服务器用于存储客户端位置数据,身份验证凭证和个人证书(如果使用)。数据库一起使用与其他组件实现身份验证、授权和会计(AAA)的功能。数据库在生产服务后必须获得足够的最佳实践和使用IP网络基础设施组件(如防火墙、访问列表),底层操作系统(如IP表),并推荐配置。

5.2.10。DNS服务器

DNS服务器提供域定义记录,它支持NAPTR和深水平台的资源记录所有组件,允许定义传输协议支持和定位的每个服务器的地址。如果平台与PSTN是相互联系的,然后DNS服务器作为ENUM映射。DNS可能会提供一个前端负载均衡服务。DNS服务器应该适用DNNSEC扩展提供验证DNS的反应。法案同样然而,域名系统安全扩展部署取决于法案同样的支持域名系统安全扩展法案同样权威的DNS服务器或扩展域名系统安全扩展实现一个特定的国家。

提供的列表组件标识先进SIP通信平台的逻辑组件。一个真正真正的实现可能不同,这取决于特定的产品选择和设计目标平台的具体实现。

5.3。的调查和相关开源产品可用
5.3.1。SIP客户端

作为最低要求,一个SIP客户端应该支持核心SIP功能,包括音频和视频通话、即时通讯,和存在。先进的SIP客户应该支持XCAP, NAT遍历(否则远端NAT功能使用的平台必须实现),支持一些安全机制(TLS和SRTP),或多个传输协议。目前有许多SIP软件客户开源或免费许可下可用。下表(见表19)识别并提供特性概述开源SIP客户端可用于不同的操作系统(OS)平台,如Microsoft Windows操作系统,Android操作系统,Linux操作系统,或Mac OS X。我们分析了SIP客户尚未发布了两年多了。然而,它必须提到有几个SIP客户,没有分析从以下几个原因。客户端没有几年的新版本,因此我们假设它没有发展(如闪烁,KPhone, miniSIP OpenSoftPhone),这应该是一个SIP测试工具(QJSimple),或只实现了消息(洋泾浜,同情)。有六个客户为Microsoft Windows操作系统,六个客户为Linux操作系统,四个客户为苹果Mac OS X,和两个新兴客户为Android操作系统。客户提供一个messenger-like GUI界面适合联系人管理,但只有一个客户端支持XCAP XCAP服务器上存储联系人(Jitsi)。分析客户不同的功能实现;总的来说,几乎所有的客户支持广泛的音频编解码器和简单,至少简单的页面即时通讯方式。支持视频通信不是广泛采用,和一个简单的会话模式只支持一个客户(Jitsi)。安全机制的实现已种植,但仍然不是一个通用的特性可用的SIP客户端。 Six out of nine clients have implemented TLS and only five out of nine clients implement SRTP with a standardized key exchange mechanism. Only two clients, Jitsi and Linphone, support IPv6.


SIP客户端 Jitsi 眨眼Lite microSIP 同声传译的电话 QuteCom Ekiga Linphone SIPDroid Csipsimple

www jitsi.org Icanblink
com
microsip
.org.ua
sflphone.org qutecom.org ekiga.org linphone.org sipdroid.org code.google
.com/p/
csipsimple

许可证 LGPLv3 GPLv3 GPL GPLv3 GPL GPL GPLv2 GPLv3 GPL

释放 1.0 beta1 - 3689 0.2.7 1.8.2 0.9.13 2.2。1 3.2.7 3.4.3 2.3 0.2.3

日期 4.10.2011 25.5.2011 15.10.2011 5.4.2011 9.5.2011 31.5.2010 25.3.2011 24.6.2011 19.6.2011

操作系统 赢,Linux, Mac X 赢,Linux、Mac 赢得 Linux Linux、Mac OS赢, Linux,赢得 Linux,赢,Mac, Android, WebOS 安卓 安卓

多个帐户 是的 是的 没有 是的 是的 是的 是的 没有 没有

音频 是的 是的 是的 是的 是的 是的 是的 是的 是的
G722, G722, Speex, G722, iLBC, G722, speex, G.722HD, Speex,
G728, speex, PCMU, speex, PCMA, G728, GSM、 PCMU, PCMU,
speex, GSM、iLBC PCMA, GSM、 PCMU, G726, PCMU, PCMA, PCMA,
GSM、iLBC PCMU, GSM、iLBC PCMU, G.722, G721speex, PCMA, speex, GSM、iLBC
PCMU, PCMA 丝绸、 PCMA,凯尔特人 许可: GSM、 G.722 GSM、BV16 丝绸、G.722
PCMA, G.722 AMR (AMR) - - - PCMU,
DVI4 世行,G.729 PCMA,凯尔特人

视频 是的
H264,
H263
没有 没有 没有 是的
h .
是的 是的 是的 没有
H264, H264,
H263, H263 H263 -
H261 1998年,
还在 MPEG4,
还在

DNS incron NAPTR 是的 是的 是的 没有 是的 是的 是的 - - - - - - - - - - - -

简单的 是的 没有 是的 没有 是的 是的 是的 - - - - - - 是的

即时通讯 页面/会话模式 - - - - - - 页面模式 页面模式 页面模式 页面模式 页面模式 - - - - - - 页面模式

XCAP 是的 是的 没有 没有 没有 没有 没有 - - - - - - - - - - - -

TLS 是的 是的 是的 是的 没有 没有 是的 - - - - - - 是的

媒体加密/关键等。 SRTP / ZRTP,米奇在进步 SRTP SRTP SRTP / ZRTP 在Everbee SRTP /密钥交换 没有 没有 没有正式确认 SRTP / ZRTP

NAT 没有 眩晕,冰 眩晕 - - - - - - 眩晕 眩晕 眩晕 眩晕,冰

通信协议 SIP, XMPP,瞄准/ ICQ, MSN,
雅虎
SIP SIP SIP, IAX SIP、MSN、严、目标,ICQ, XMPP SIP, H.323 SIP SIP SIP

传输协议 TLS TCP, UDP TLS TCP, UDP TLS TCP, UDP UDP, TLS / SSL UDP UDP TCP, UDP TLS UDP, TCP UDP, TCO, TLS

IPv4 / IPv6 是的/是的 是/否 是/否 是/否 是/否 是/否 是的/是的 - - - - - - - - - - - -

语音邮件 是的 是的 没有 是的 - - - - - - 没有 没有 - - - - - - - - - - - -

支持基本的音频/视频会议和页面模式消息传递是光滑的。然而,先进的SIP功能,如简单或TLS提供不同级别的标准的采用,以及不同客户的互操作性差。根据所需的功能和我们的经验,我们已经评估了Jitsi传播者(SIP沟通者)其次是眨眼的客户是最好的和最特色为Microsoft Windows客户机,Mac X,和Linux操作系统。安卓系统,我们认为cSipSimple随后SipDroid客户机是最合适的,尽管目前Jitsi Android端口。Jitsi沟通者是一个功能丰富的音频/视频和聊天多协议沟通者。它最初是斯特拉斯堡大学开发,和现在在LGPL开源许可下提供的。最后,我们可以状态,很难预测开源项目的进一步发展。为例,Jitsi沟通者尚未作为一个稳定版本发布。

5.3.2。SIP服务器

SIP服务器应该支持SIP注册和SIP代理功能。SIP服务器应该模块化和灵活的,允许强大的SIP调用处理。它应该支持安全机制和TLS连接与不同类型的认证服务器。服务器应该提供一个NAT遍历解决方案。对于SIP服务器,存在两种广泛使用的解决方案:Kamailio OpenSIPS。都是打开项目的继任者(SER项目的叉)。SER (SIP表达路由器)服务器被称为Sip-Router(2008年以来)是一个SIP代理,拥有众多的全球实现和支持广泛的开源社区开发人员,维护人员和支持者。SER自2001年以来一直在发展,2004年在GPL下发布开源许可证。其发展背后的历史是有点复杂,导致建立几个可行的解决方案,如打开2005年(2008年改名为Kamailio)和2008年OpenSIPS。目前,Kamailio和SIP-router项目的开发人员正试图合并这两个项目。 In a present time, Kamailio and SER can be considered identical (starting from 3.0 releases). The OpenSIPS fork is still going along its own development way.

Kamailio(前打开)和OpenSIPS都是非常受欢迎的和可行的SER-based SIP代理解决方案。尽管前打开项目是分开的,这两个解决方案都提供了核心功能(见表非常相似2)。都是在GPL许可下发布,并提供一个模块化的设计架构,每秒可以处理成千上万的电话设置,支持类似的协议(TCP, UDP, SCTP) AAA功能(MySQL、PostgreSQL、甲骨文、半径、LDAP),和SNMP监视。两台服务器支持TLS,可用于一个信任的概念扩展到多畴的层面,在双方协议可以建立信任关系。验证数据(认证机构的证书和链)本地存储。两台服务器支持枚举,最低成本路由、负载平衡和路由故障转移。都提供一个脚本配置语言,允许灵活的SIP路由配置。他们采用CPL SIP api和支持其他脚本语言提供应用程序级别的功能。差异是只有在2008年以后新模块开发。例如,在2011年Kamailio IMS模块介绍了扩展,允许建立一个IMS试验台与最新Kamailio SIP服务器版本。这两个解决方案是成熟的开源实现的SIP服务器统一声音,视频,IM和存在服务在一个有效的方法。


SIP服务器 Kamailio / SIP路由器 OpenSIPS

www kamailio.org/sip-router.org opensips.org

许可证 GPL

最后的版本 3.2.0 1.7.0
操作系统 Linux Linux

SIP注册 是的
SIP代理 是的

B2BUA 没有 是的

底层事务访问 是的
分叉 是的
模块化的体系结构 是的

NAT遍历 是的 是的
与RTPProxy Mediaproxy 与RTPProxy Mediaproxy

Keepalive 是的

对数据库的身份验证和授权 MySQL、PostgreSQL SQLLite这样,UnixODBC BerkeleyDB,甲骨文,文本文件,LDAP、半径、直径 MySQL、PostgreSQL UnixODBC BerkeleyDB,甲骨文,文本文件,LDAP、半径、直径

信令协议 SIP

传输协议 TCP, UDP TLS, SCTP TCP, UDP TLS, SCTP

IPv4 / IPv6 是的/是的

管理web GUI 是的 是的
SIREMIS OpenSIPS-CP, SerMyAdmin

DNS NAPTR深水救生艇,枚举
多畴的 是的
简单(存在和IM) 是的

XCAP服务器 是的 是的
使铭记于心 与OpenXCAP服务器
网关 XMPP, MSN,短信 XMPP, MSN,短信
标准化的SIP服务API CPL, SIP servlet API(海洋) CPL, SIP servlet API
其他服务工具 Lua Perl, Python Perl

媒体服务 没有
航空类路由 是的
负载平衡 是的
进攻的保护 是的
IP黑名单

OpenSIPS解决方案可以受益于一个支持一个厂商建议零售价中继服务器用于厂商建议零售价IM传送场景的会话消息/ NAT。Kamailio可以受益于一体化的集成简单的解决方案。还有其他开源SIP服务器实现,但他们仍在实验阶段,例如,YXA服务器和OpenJSIP。还有其他著名的星号B2BUA等解决方案,它提供了良好的媒体处理能力。

有几个广泛采用和支持服务器的解决方案,提供先进的媒体服务。他们主要是设计为先进的电话平台针对交换机市场。这些平台通常设计成独立的解决方案,支持通信使用音频、视频、文本、或其他形式的媒体。然而,从体系结构的角度来看,他们并不像SIP代理服务器的设计与灵活的消息路由规则。在我们的平台,他们发挥了作用媒体服务器(语音邮件、会议、IVR),网关,或B2BUA实体。分析了四种解决方案:星号,FreeSWITCH,橡胶树,sem。我们建议使用星号,因为它有一个高质量的文档和一个更大的社区的支持者。从实验的角度,我们不得不提到的解决方案,如FreeSWITCH、橡胶树,两者都提供有趣的特性(见表3)。


媒体服务器 星号 FreeSwitch 橡胶树 扫描电镜

www Asterisk.org Freeswitch.org Yate.null.ro www.iptel.org/sems
许可证 GPL MPL GPL GPLv2 +
持续稳定的rel。 1.8.2.3 1.0.6 3.3.0 1.4.2
操作系统 Linux、Mac OS X * BSD、Solaris,窗户 Linux、Mac OS X * BSD、Solaris,窗户 Linux、Mac OS、FreeBSD、窗户 Linux
Wrritten在 C C / c++ c++ C / c++
体系结构 B2BUA B2BUA - - - - - - - - - - - -

模块化 是的

NAT遍历 没有 眩晕 没有 - - - - - -
认证、授权与数据库 MySQL、PostgreSQL、LDAP、半径 MySQL、PostgreSQL、LDAP、半径 MySQL、PostgreSQL半径 直径
VoIP通信协议 SIP, H, 323年,SCCP、MGCP IAX GoogleTalk SIP、H.323 IAX, SCCP SIP, H.323、MGCP IAX,叮当声 SIP
电话信号协议 ISDN / SS7 FXS / FXO ISDN / SS7 ISDN / SS7 FXS / FXO Sigtran 没有
消息传递协议 XMPP 简单,XMPP XMPP / Jabber 没有
调用加密 SRTP SRTP 没有 SRTP
传输协议 TCP, UDP SCTP, TLS TCP, UDP SCTP, TLS TCP, UDP SCTP UDP
IPv4 / IPv6 是的/是的 是的/是的 是的/ - 是的/ -
Web GUI 是的 是的 - - - - - - 没有
简单的 没有 是的 没有 没有
SIP网关 是的 是的 是的 没有
音频编解码器 ADPCM, PCMU、PCMA G.722、G.722.1 G.722.1附件C, G.723.1,于,G.729a, GSM, iLBC,线性,LPC-10 Speex 凯尔特人,G.722.1、G.722.1C G.722、PCMU PCMA, GSM,于,AAL2 RFC 3551, G.723.1, G.729AB, AMR, iLBC, Speex, LPC-10 DVI4、丝绸 GSM、speex iLBC AMR-NB PCMU PCMA, GSM、于、iLBCi speex, adpcm, L16
视频编解码器 没有 H.261 Theora, h, h +、h + +、h、MP4 没有 没有

代码转换 是的

IVR Announc。 是的 安。

语音邮件 是的 是的 - - - - - - 是的

音频会议 是的

电话录音 是的 是的 - - - - - - - - - - - -

IP /交换机的功能 是的 没有

CDR 是的 - - - - - -

传真 T.30, T.38 T.30, T.38 - - - - - - 没有
从文本到语音 是的 是的 - - - - - - 没有

SIP API 没有

编程语言 Adhersion CGI任何语言 C / c++、Python、Perl Lua, Java、JavaScript, Erlang, Ruby Python c++、Python DSM

网关的使用取决于部署场景。互连的信号水平,星号,FreeSWITCH和橡胶树可能被使用。连接在媒体层面,特殊专用硬件必须被使用。星号支持广泛的网络接口卡组合,所以它是最合适的解决方案。专用的网关,如思科ISR路由器是一个可选择的解决方案,而不需要额外的网关。互连与XMPP, Kamailio / OpenSIPS XMPP支持。

5.3.3。SIP状态和IM服务器

简单的实时允许用户发送和接收即时消息和知道其他用户的可用性或现状。实际上,只有两个开源解决方案通过一个集成的支持简单的存在和IM, Kamailio, OpenSIPS。打开后的简单的功能已经添加项目叉;因此,实现哲学是不同的。Kamailio服务器提供一体化解决方案。简单的功能是与新开发的集成存在,消息,Xcap服务器和HTTP模块。不需要外部应用程序或依赖,因为他们现在Kamailio服务器的一部分。然而,一个在一起xcap_client模块可以使用外部Xcap服务器。OpenSIPS集成简单的功能是建立在存在模块。Xcap服务器功能被排除在主服务器和它是一个OpenSIPSxcap_client模块提供连接到外部xcap服务器OpenXcap服务器。提到的两种解决方案可以使用作为一个独立的简单的服务器与Xcap功能,可以使用在IETF SIP架构,或IMS台建在OpenIMSCore或Kamailio IMS的解决方案。目前还没有其他开源简单集成解决方案。只提供业务功能,Mobicent存在服务(议员)可以使用58]。议员提供业务功能开发的基于sip的网络使用标准互联网工程任务组(IETF),开放移动联盟(OMA),第三代合作伙伴计划(3 gpp)和欧洲电信标准协会(ETSI)。

5.3.4。XCAP服务器

两个产品进行了调查,Kamailio SIP服务器和嵌入式XCAP / HTTP服务器功能或独立OpenXCAP服务器(59]。

5.3.5。应用服务器(如)

有一个可用的开源产品数量;然而,选择取决于SIP服务工具是用于服务开发计划。创建轻量级服务由最终用户自己定义的,CPL的API,可以使用。Kamailio和OpenSIPS服务器支持它。与一个强大的服务逻辑开发先进的服务,必须使用更高级的编程API如SIP servlet或JAIN API。SIP Servlet API为开发服务提供了更多的灵活性,将SIP和HTTP协议SIP Servlet通常是一个HTTP Servlet API的扩展。耆那教的API,另一方面,与许多协议支持提供了一个健壮的API,包括电信的。有几个SIP Servlet或JAIN实现如:(我)SailFin。Sailfin [60)是一个扩展的SIP servlet容器广泛使用GlassFish开源企业平台开发的领导下甲骨文和GPLv2许可下提供的。一种支持SIP Servlet API技术。然而,文档是经常过时或不可用,因为改变的主要项目的支持者从太阳到Oracle。(2)Mobicents。Mobicents [58)是一个开源的VoIP平台认证JSLEE 1.1和SIP servlet 1.1技术。Mobicents是SIP服务平台开发的领导下RedHat和GPLv2许可下提供的。Mobicents子项目由Mobicents SIP servlet (GPLv2.1),媒体服务器(GPLv2)和SIP服务(GPLv2)。(3)Cipango。Cipango [61年)是一个扩展SIP Servlet的Jetty HTTP Servlet引擎。Cipango / Jetty然后收敛SIP / HTTP应用程序服务器都符合SIP servlet 1.1和HTTP servlet 2.5标准。(iv)WeSIP。WeSIP [62年)是一个SIP和HTTP聚合应用程序服务器建立在一个打开SIP平台之上,增加了一个J2EE层打开,所以它可以受益于现有的打开模块和功能。

也有解决方案,使用其他方法,如外部脚本调用(星号,Kamailio / OpenSIPS),编程语言如Perl (Kamailio / OpenSIPS), Lua (Kamailio), Python (Kamailio)、Java或专有的API,如Adhearsion [63年星号),或专有的脚本语言(Astrerisk)。

5.3.6。NAT遍历组件

NAT遍历可能包括几个组件。然而,只有几个开源产品是可用的。VOVIDA-based部署眩晕,眩晕服务器可以使用。这眩晕服务器可用几个Linux发行版的存储库(Debian, CentOS, RedHat)。另一个选择是mySTUN包(64年];然而,这个包没有进化超过两年。有些眩晕服务器公开。支持TCP NAT遍历,有简单的遍历通过NATs UDP和TCP(表演)Vovida眩晕服务器的扩展,叫STUN-over-TCP可用。然而,它并不适合对称NAT。来支持它,必须部署或冰。对于将实现,两个开源项目已确定:TurnServer [65年)和reStund项目(66年]。TurnServer的最新版本是0.5版在2011年6月出版。基于麻木服务器提供免费服务(67年]。使用冰协商功能,冰可以使用扩展MediaProxy服务器。支持眩晕/冰转开发,有几个开源库,如PJNATH (PJSIP NAT助手),返回,ice4j。

部署远端NAT遍历解决方案,有两个可用的开源产品,RTPproxy服务器(68年)和MediaProxy服务器(69年]。部署一个RTPproxy耗时少。SIP服务器之间的通信和RTPproxy或MediaProxy,使用专有协议。相比之下,MediaProxy提供了额外的功能,如TLS的支持,T.38传真、半径和数据库服务器日志记录。MediaProxy支持冰谈判的行为像一个继电器的候选人,而政策可以从OpenSIPS配置控制。这些解决方案与Kamailio / OpenSIPS项目紧密结合,支持他们的服务器模块。

5.3.7。数据库服务器

数据库是用来存储用户的凭证。它也可以用于存储cdr(呼叫详细记录)。此外,它被用作一个位置为SIP注册和代理服务器。有几个开源解决方案,比如MySQL, PostrgeSQL, OpenLDAP, OpenRadius。我们建议使用一个支持多个平台组件。作为数据库服务器,我们建议使用MySQL服务器,因为它支持与所有其他平台组件连接。经常使用MySQL数据库服务器;此外,有大量的信息来源和“如何”实现指南。当然,可以使用其他的解决方案,但实施更耗时。

作为一个DNS服务器,我们建议使用标准BIND9服务器,因为它提供了所需的功能,如NAPTR / SRV,枚举,DNSSEC,树多畴的,私人或公共的树木。BIND9服务器可以从Linux发行版的存储库。作为一种替代方法,可以使用PowerDNS服务器。

5.4。高可用性和弹性

提出了平台的解决方案可以提供高可用性特性,可以用不同的方式来实现。首先,一个正确配置DNS公顷可能作为前端哈,我们提出使用DNS服务器。DNS服务器必须配置为响应的NAPTR SRV记录与一个预定义的秩序和偏好值(NAPTR),分别重点和权重SRV记录。第二个选项包括负载平衡器的部署。Kamailio / OpenSIPS服务器操作作为一个无状态SIP代理结合适当的模块(调度员,carrierroute)可以使用。另外,有一个Mobicents SIP负载均衡器可用,这实际上是一个简单的SIP代理服务器。第三种选择是基于VRRP协议(70年]。最后,一个服务器集群可能部署使用心跳框架(54)和一个可选支持分布式复制块设备(DRBD) [71年]。

5.5。提出解决方案

推广SIP技术作为服务提供者平台,先进的学习,以及研究和实验平台,我们不考虑商业产品,我们只分析了开源组件。SIP平台提供了一个生活环境,可用于硕士学位课程由我们部门领导。它还允许一个简单的访问SIP技术和先进的服务。这个平台是为了建立低成本和基于开源软件。SIP与新服务和通信平台是开放的和可伸长的组件。

使用开源组件上面所提到的,我们建立了一个实验室原型环境所有这些特性。虽然在我们的研究中,我们使用Kamailio SIP服务器(见表4、解决方案1),该平台可以实现通过两个完全可比和替代的解决方案和组件列在表中4


SIP服务器 Kamailio OpenSIPS
媒体服务器 星号/
FreeSWITCH
星号
简单和XCAP Kamailio OpenSIPS /
OpenXCAP
NAT遍历 RTPproxy MediaProxy
应用程序服务器 Sailfin Mobicents
数据库服务器 MySQL MySQL
网关 星号 星号
小鬼XMPP网关 Kamailio Kamailio
DNS服务器 Bind9 Bind9
DHCP服务器 dhcp3-server dhcp3-server

所有平台组件,Xen服务器虚拟化技术的帮助,一个硬件服务器上运行(参见图7)。操作系统平台,64位Debian linux操作系统发布莱尼已经使用。只有XMPP服务器上运行Ubuntu 10.10 Maverick。所有组件都是基于开源软件。作为一个SIP服务器,使用Kamailio服务器的核心部分。Kamailio SIP服务器,由于灵活的路由和配置功能,提供了一个主要的SIP路由逻辑架构。Kamailio服务器作为平台的注册和代理服务器。位置服务器和身份验证凭据存储,使用MySQL服务器(Kamailiodb_mysql模块)。SIP服务器的路由逻辑是主要配置,这样呼叫路由功能的SIP服务器本身。如果一个被不可用(离线,忙,长时间响),电话被重定向到媒体服务器和语音信箱服务通过IVR调用一个特定的用户。为此,用星号位置数据库的实时集成数据库已实现。然后一个声音消息传递使用电子邮件服务被电子邮件箱。语音消息也可以使用一个预定义的语音信箱SIP地址和用户密码。此外,星号服务器是用来实现一个音频会议服务。为此,一个MeetMe应用程序使用。MeetMe支持静态和动态创建会议室,密码保护会议和会议控制机制(例如,静音)。SIP服务器配置路由SIP地址分配的会议服务星号。消息传递和业务服务上实现一个专门的简单的服务器与Xcap功能(Kamailio Xcap)使用存在,presence_xml,xcap_server,xhttpKamailio模块。SIP服务器的主要路由逻辑配置相应的简单消息路由到简单的服务器。由于保护Xcap的访问,使用用户的身份验证凭证。因此,简单的集成服务器与主位置数据库实现。简单的服务器还提供了XMPP网关功能(pua_xmpp,xmpp,紫色的模块),这使两个存在的集成和信息架构,简单和XMPP。互连的场景中,我们使用了一个xmpp模块,另外两个还没有完成,或者代码bug被发现。的xmpp模块可以在两种模式中,一个组件模式和服务器模式。测试专用的XMPP服务器已经安装(Jabberd2)。测试的实现表明,发展xmpppua_xmppKamailio模块尚未确定(服务器模式没有工作)。据相关测试服务,只有消息一直没有问题。XMPP之间存在服务没有正常工作和简单(3.1.5 Kamailio版本)。XMPP网关作为替代,OpenSIPS服务器可以使用。

然而,在测试期间OpenSIPS XMPP网关功能(xmpp在模块),一个错误代码uri_xmpp2sip ()功能被发现;因此,它是不可能正确地利用模块功能。

作为一个集成的SIP / HTTP服务的一个例子,说明了SIP服务发展机会,与一种扩展的平台。作为一个功能齐全的选择,Mobicent也可以使用。Sailfin一样已经使用SIP servlet开发和托管平台用于click2call服务。Click2call服务服务,使一个电话两个或两个以上的相关方之间建立直接从web页面。click2call服务是一个很好的例子,通过SIP技术服务创建一个新的方法。click2call服务实现第三方呼叫控制实体(3 pcc)负责调用初始化。

为了解决NAT遍历问题,眩晕服务器已经实现的一个平台。在特殊情况下,RTPproxy媒体代理已经实现。可以或者用于RTPproxy IPv4 / IPv6互相配合场景。最后,定义的DNS服务器已正常使用SIP和XMPP SRV记录。平台是无状态连接到一个思科呼叫管理器(CCM)通过CCM调用路由到公共交换电话网络(PSTN)。对于调用路由到PSTN,远程方ID头已经被插入。该平台支持TLS使用自签名证书。

几个测试互连场景一直在执行服务使用不同的SIP客户端实现,模拟内部和域间的连接。信令消息交换已经被抓获,分析,评估证明互连。对于一些场景,IMS客户端(Boghe)能够注册一个SIP可以使用域和打电话。

一般来说,平台组件的安装简单,可直接从各自的包存储库。获得特殊功能可能需要包编译。平台组件的配置,尤其是Kamailio / OpenSIPS服务器的路由行为需要一个深入了解的配置脚本语法。我们认为足够详细文档相关的模块。然而,“入门”指导公开项目主要门户网站是不同的。我们的个人观点是,Kamailio项目提供更准确的结果。另一方面,两个SIP服务器是健壮的和强大的。文档星号是广泛使用,因为星号似乎是最流行的IP PBX和许多可用的扩展和应用。因此,特别是对于较轻的解决方案,其他有趣的媒体服务器是可用的,例如,FreeSWITCH,一个可伸缩的开源跨平台电话平台。

5.6。讲话

提出的两个解决方案集成开源组件,可以用来创建一个高性能、功能丰富的平台。提出的解决方案都是完全具有可比性。这两个提议解决方案由一个独立的组件数量,可以以不同的方式实现的,具有不同数量的逻辑上和物理上部署服务器根据一口运营商的战略和目标。这些组件通常被部署为软件包安装在主机服务器上运行Linux。此外,强大的开源解决方案,集成有许多功能,例如,SipXecs Elastix统一通信(UC)解决方案。他们一起作为一个包提供了Linux操作系统。

Elastix [72年)是一个开源项目,它已经从星号和集成多个开放源代码产品GPLv2许可下提供一个统一的通信解决方案。Elastix包括大量的通信媒体和其他特性支持的开源产品,如邮件服务器(后缀),邮箱(圆的立方体),CRM (vTigerCRM),即时通讯和存在(OpenFire),传真服务器(Hylafax), SIP网络电话交换机(星号1.6)与WebGUI (FreePBX),和一个视频会议服务器,它们运行在Linux CentOS的版本。

SipXecs是高度可伸缩的企业级统一通信和协作LGPL许可下提供的解决方案。支持的发展SipXecs开源组织SIPFoundry [73年]。SipXecs SIP-centric软件解决方案提供PBX电话服务集成与几个开放源码解决方案提供一个加州大学包。SipXecs包括SIP服务器(SipX),即时通讯和存在(OpenFire),通往其他IM,媒体服务器为会议和语音信箱(FreeSWITCH),自动接触分布(ACD),都是可控的,基于web的GUI管理接口包装和运送CentOS linux上运行。

6。结论

现代通信技术的发展提供了新的交流的可能性。在本文中,我们分析了关键协议,技术和服务,可以纳入一个融合通信平台。基于案例研究中,我们分析和提出了一个开放的基于sip的交流平台,展示了开源产品的机会完成这个复杂的任务。开源产品我们已经测试了质量好,足够支持文件,实施指南和其他相关材料。它们的部署使构建一个灵活、可伸缩和强大的多媒体通信解决方案,集成和提供许多有趣的服务,这样的音频和视频通话,会议、语音信箱、存在和即时消息。在学术环境中使用开源产品使教师、研究人员和学生保持联系与技术创新。

引用

  1. j·罗森博格,h . Schulzrinne g·贝et al ., SIP:会话发起协议,RFC 3261, 2002年7月。
  2. p . Segeč“编程SIP服务SIP api,”Acta Electrotechnica et Informatica,10卷,不。4,39-45,2010页。视图:谷歌学术搜索
  3. j·伦诺克斯和h Schulzrinne、呼叫处理语言(CPL):一种语言的用户控制互联网电话服务,RFC 3880, 2004年10月。
  4. j·伦诺克斯,h . Schulzrinne和j·罗森博格,常见的为SIP网关接口,RFC 3050, 2001年1月。
  5. JSR 289专家组,JSR - 000289 SIP Servlet 1.1最终发行版,2008年。
  6. jsr - 000032,耆那教的SIP API规范,维护发行版,2006年,http://jcp.org/aboutJava/communityprocess/mrel/jsr032/index.html
  7. h . Sinnreich说道,a·约翰斯顿互联网通信使用SIP:与会话初始化协议提供VoIP和多媒体服务约翰·威利& Sons,纽约,纽约,美国,第二版。
  8. http://datatracker.ietf.org/wg/xmpp/charter/
  9. http://datatracker.ietf.org/wg/simple/charter/
  10. m .天,j . Soenberg h . Sugano模型存在和即时消息,RFC 2778, 2000年2月。
  11. m .天,s . Aggarwal g .莫尔和j·文森特,即时通讯/存在协议要求,RFC 2779, 2000年2月。
  12. b·坎贝尔j·罗森博格,h . Schulzrinne c . Huitem和d . Gurle会话初始化协议(SIP)扩展即时消息,RFC 3428, 2002年12月。
  13. b·坎贝尔,r . Mahy和c·詹宁斯消息会话中继协议(厂商建议零售价),RFC 4975, 2007年9月。
  14. c·詹宁斯,r . Mahy和a·b·罗奇继电器扩展消息会话中继协议(厂商建议零售价),RFC 4976, 2007年9月。
  15. a·b·罗奇会话初始化协议(SIP)特殊事件通知,RFC 3265, 2002年6月。
  16. j·罗森博格事件包存在的会话初始化协议(SIP), RFC 3856, 2004年8月。
  17. a .尼米会话初始化协议(SIP)扩展事件国家出版,RFC 3903, 2004年10月。
  18. j·罗森博格,可扩展标记语言(XML)配置访问协议(XCAP), RFC 4825, 2007年5月。
  19. e .汉堡、j . van Dke和a·斯皮策与SIP基本网络媒体服务,RFC 4240, 2005年12月。
  20. c·博尔顿、t . Melanchuk和s . McGlashan媒体控制通道框架,RFC 6230, 2011年5月。
  21. c·詹宁斯、f·奥迪特和j·艾威尔、会话初始化协议(SIP)的uri的应用,如语音信箱和交互式语音应答(IVR), RFC 4458, 2006年4月。
  22. j·罗森伯格,一个框架的会议会话初始化协议(SIP), RFC 4353, 2006年2月。
  23. m·巴恩斯,c·博尔顿,欧利文湖的框架集中会议,RFC 5239, 2008年6月。
  24. o·莱文和r .甚至高层紧密耦合的SIP会议要求,RFC 4245, 2005年11月。
  25. j . van Meggelen j·史密斯,l·马德森星号:电话的未来O ' reilly,第二版。
  26. s . McGlashan t Melanchuk和c·博尔顿,交互式语音应答(IVR)对媒体的控制方案控制通道框架,RFC 6231, 2011年5月。
  27. t·伯纳斯·李·r·菲尔丁,c·欧文和l . masint统一资源标识符(URI):通用的语法,RFC2396标准,1998年8月。
  28. A . Gulbrandsen p .使得,l . Esibov DNS RR为指定的位置服务(DNS SRV), RFC 2780, 2000年2月。
  29. 米尔林和m . r .丹尼尔,命名权限指针(NAPTR) DNS资源记录,RFC2915, 2000年9月。
  30. j·罗森博格和h . Schulzrinne会话初始化协议(SIP):定位SIP服务器,RFC 3263, 2002年6月。
  31. d . Senie网络地址翻译(NAT)的材料应用程序设计指南,RFC3235, 2002年1月。
  32. j·罗森博格,r . Mahy p·马修斯,d .翅膀,会话遍历公用事业NAT(眩晕),RFC 5389, 2008年10月。
  33. r . Mahy·马修斯和j·罗森博格,遍历使用继电器在NAT(转):继电器扩展为NAT(眩晕)会话遍历公用事业,RFC 5766, 2010年4月。
  34. j·罗森博格,交互式连接(冰):建立一个协议的网络地址翻译(NAT)遍历提供/回答协议,RFC 5245, 2010年4月。
  35. j·罗森博格,表示支持交互式连接机构(冰)的会话初始化协议(SIP), RFC 5768, 2010年4月。
  36. “论坛http://www.upnp.org/
  37. r·c·詹宁斯Mahy f·奥迪特,管理客户端发起连接的会话初始化协议(SIP), RFC 5626, 2009年10月。
  38. w·Werapun a . a . e .蓝b . Paillassa和j . Fasson“解决方案分析SIP安全威胁,”学报》国际会议多媒体计算和系统(ICMCS ' 09)2009年4月,页174 - 180。视图:出版商的网站|谷歌学术搜索
  39. 即Dolnak”,拒绝服务攻击在IP网络上的声音,”诉讼研究通信技术研讨会(RTT的10),VŠB-Technical大学的斯特拉瓦,Velke Losiny,捷克共和国,2010年9月。视图:谷歌学术搜索
  40. j·彼得森,S / MIME高级加密标准(AES)要求会话初始化协议(SIP), RFC 3853, 2011年2月。
  41. j . Kuthan j . Floroiu h . Schulzrinne s Sisalem和Aben,SIP安全约翰·威利& Sons,纽约,纽约,美国,2009年。
  42. c·詹宁斯和j .费施尔证书管理服务的会话初始化协议(SIP), RFC 6072, 2011年2月。
  43. t·迪克斯和c·艾伦,TLS协议,RFC2246, 1999年1月。
  44. 大肠Rescorla和n . Modadugu数据报传输层安全、RFC4347, 2006年4月。
  45. h . Schulzrinne s Casner r·弗雷德里克和诉Jacobsion RTP:实时应用程序的传输协议,RFC 3550, 2003年7月。
  46. m·鲍格d·麦格罗,m . Naslund e·卡拉拉和k . Norrman安全实时传输协议(SRTP), RFC 3711, 2004年3月。
  47. m·鲍格f·安德瑞森,d .翅膀,会话描述协议(SDP)安全描述媒体流,RFC4568, 2006年7月。
  48. j . Arkko e·卡拉拉f . Lindholm k . Naslud和k . Norrman米奇:多媒体网络键控,RFC 3830, 2004年8月。
  49. j .费施尔h . Tschofenig,大肠Rescortla框架,建立一个安全的实时传输协议(SRTP)安全上下文使用数据报传输层安全性(迪泰),RFC 5763, 2010年5月。
  50. p·齐默尔曼,a·约翰斯顿和j .调用ZRTP:单播安全的关键协议RTP媒体路径,RFC 6189, 2011年4月。
  51. d .东湖牌、域名系统安全扩展,RFC 2535, 1999年3月。
  52. 思科公司概述基于sip的语音网络的高可用性http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123cgcr/vvfax_c/callc_c/sip_c/sipha_c/hachap1.htm
  53. 美国骑士,d·韦弗、d·惠普尔和r . Hinden虚拟路由器冗余协议,RFC 2338, 1998年4月。
  54. linux - ha,http://www.linux-ha.org/
  55. 起搏器,一个可伸缩的High-Availibility集群资源管理器,http://clusterlabs.org/
  56. 开放源代码倡议(OSI),http://www.opensource.org/
  57. a·约翰斯顿r .火花,c·坎宁安,s·多诺万,和k·萨默斯(lawrence Summers)会话初始化协议服务的例子,RFC 5359, 2008年10月。
  58. Mobicents项目,http://www.mobicents.org/
  59. OpenXCAP-Free XCAP为SIP服务器简单,http://openxcap.org/
  60. SailFin项目可奈,http://sailfin.java.net/
  61. Cipango,http://www.cipango.org/
  62. WeSIP,http://www.wesip.com/
  63. Adhearsion:开源电话开发框架,http://adhearsion.com/
  64. MySTUN服务器,http://developer.berlios.de/projects/mystun/
  65. 的TurnServer project-open-source服务器实现,http://turnserver.sourceforge.net/
  66. ReStund,http://www.creytiv.com/restund.html
  67. 麻木昏迷/服务器,http://numb.viagenie.ca
  68. RTPproxy,http://www.rtpproxy.org/
  69. MediaProxy-Fast和可伸缩的RTP继电器,http://mediaproxy.ag-projects.com/
  70. keepalive项目,http://www.keepalived.org/
  71. 分布式复制块设备项目,http://www.drbd.org/
  72. Elastix、开源统一通信服务器http://www.elastix.org/
  73. sipXecs企业通信系统,http://www.sipfoundry.org/

版权©2011帕维尔Segec和塔蒂阿娜Kovacikova。这是一个开放的分布式下文章知识共享归属许可,它允许无限制的使用、分配和复制在任何媒介,提供最初的工作是正确引用。


更多相关文章

PDF 下载引用 引用
下载其他格式更多的
订单打印副本订单
的观点16924年
下载3919年
引用

相关文章

文章奖:2020年杰出的研究贡献,选择由我们的首席编辑。获奖的文章阅读