Iovzprovide研究

目录

1，Iovzprovide简介

2，Iovzprovide设计思路 

2.1，总体

2.2，多级门户

2.3，面向运营商

2.3，安全

3，Iovzprovide实验 

3.1关于ip配置

3.2关于呼叫

3.3关于门户

4，经验感受

---

1，Iovzprovide简介

IvozProvider是面向 公共网络的，面向运营商的多级 IP电话解决方案 。

IvozProvider使用知名且稳定的免费软件项目来完成平台的不同任务，包括下图的所有开源工程。

• Debian是ivozprovide的运行操作系统
• Kamailio负责实现sip代理、sip中继
• Asterisk负责实现as
• Mysql负责数据库支持
• Homer sip capture负责sip流量、通话质量测量
• Rtp proxy、Rtpengine负责媒体处理
• Graylog view负责日志部分
• Apache负责网站部分

2，Iovzprovide设计思路

2.1，总体

设计总图如下：

• Sip信令流:

Iovzprovide内部涉及3个实体： sip代理、sip中继、as。

其中sip代理负责和sip用户对接，sip中继负责和sip运营商对接；内部sip中继、sip代理和as对接。不准许外部实体与as直接对接。

• RTP流：

Iovzprovide内部涉及2个实体： media中继、as。

两个外部实体直接和media中继交互，如果需要media中继会和as交互。同样不准许外部实体与as直接交互。

• http流：

http主要用于提供门户网站，配置数据、查看状态等。

Iovzprovide内部涉及1个实体： web portale

Iovzprovide提供四级门户网站。

2.2，多级门户

IvozProvider的门户网站设计是允许同一基础架构中含有多种角色：

• God Admin：解决方案的管理员和维护者。提供对多个品牌运营商的访问。

他们最重要的任务是创建品牌并对其进行配置，以便他们拥有足够的自主权来正确使用该平台：

• 配置他们的网络访问。
• 配置其品牌门户外观：主题，颜色等

他们的全局属性还使他们负责：

• 监控平台，以便始终保持UP＆RUNNING
• 分析平台日志，以跟踪可能的错误。
• 安全机制，以避免外部攻击。
• 获取通话音质的全局统计数据。
• 根据需求，增加平台的可用资源：
  • 增加独立安装中的可用资源
  • 根据需要迁移到具有多个AS，媒体中继等的分布式安装。

• Brand Admin：负责向多家公司运营商提供访问权限，担保和账单。

品牌运营商最重要的任务可以通过此门户进行管理：创建和配置公司，以便他们可以正常工作。

由于品牌运营商也可以为其公司开票并确保外部消费者设置正确，因此还必须管理：

• 与PSTN互通性协商。
• 包含结算流程所需的所有公司信息。
• 定价计划及费用核算。
• 出入局路由设置。
• 为每个结算周期创建发票并将其发送给客户。

• Company Admin：负责自己的PBX配置并管理最终的平台用户。

公司管理员可以访问品牌运营商提供的门户。

从它的角度来看，它在云中有一个虚拟pbx，必须为其用户进行配置。

• 配置终端，分机和用户。
• 使用适当的逻辑配置DDI传入过程：
  • 直接发送给用户
  • IVR
  • 转接
  • 传真
• • 来电转发
  • 请勿打扰
  • 呼叫等待

• User：链中的最后一个链接，具有SIP凭证，可以访问自己的门户以进行自定义配置。

最终用户有两种不同的凭证，都由其公司管理员提供：

• 用户门户访问凭证
• 用于将其终端（或终端）注册到IvozProvider的SIP凭证

通过用户门户，它可以浏览他们的呼叫注册表并配置：

• 来电转发
• 请勿打扰
• 呼叫等待

2.3，面向运营商

IvozProvider是一款电话解决方案，设计时考虑了横向扩展功能， 它只允许通过增加机器和资源来处理大量流量和用户。

以下是IvozProvider设计成面向运营商的一些主要想法：

IvozProvider所有的模块都可以在同一个主机上运行，​​也可以分离出来在单独的机器上运行。分布式安装可以使资源的按需分配到每一个任务，但需注意：

• 合理的部署模块以保证可靠性。
• 合理的部署关键要素以保证尽量减少通信延迟。
• 合理的部署模块以保证系统能够处理成大量的并发呼叫。

限制VoIP解决方案服务的资源消耗元素是：

• 已经建立呼叫音频管理。
• 每个公司配置（IVR，会议室，外部呼叫过滤器等）
• 配置和记录的数据库。

IvozProvider的设计始终牢记每个实体的可扩展行，因此它可以处理数十万个并发呼叫。要实现这些最重要的是，根据预期的服务质量调整资源分配：

Media relay处理已建立呼叫的方法：

• 根据需要使用尽可能多的媒体中继。
• 分组加入媒体中转，并强制一些公司按需要使用群组。
• 在最终用户附近设置媒体中继，以尽量减少通话中的网络延迟。

AS服务器处理业务的方法：

• 横向扩展：如果需要，可以安装新的应用服务器并将其添加到池中。
• 每个电话都由最不繁忙的Appliction Server处理
• 默认情况下，公司和应用程序服务器之间不存在静态分配关系。通过这种方式，任何应用程序服务器的失败并不重要：平台将在分配呼叫时忽略有故障的应用程序服务器。

2.3，安全

IvozProvider旨在直接从Internet为用户提供服务。虽然它可以在本地环境中使用，但IvozProvider旨在使用公共IP地址为其服务，从而消除了将基础设施与最终用户相连接的VPN或IPSec隧道的需求。

IvozProvider提供的一些安全机制：

• 只有所需的服务才会暴露于互联网。
• 不受信任的原始访问可以通过集成的防火墙过滤掉
• 可以过滤来自IP地址或网络的访问以避免任何类型的网络钓鱼。
• 还有一种防洪机制可以避免短暂的拒绝服务攻击。
• 每家公司的并发呼叫可以限制在固定数量。
• IvozProvider支持来自NAT后面终端的连接 。
• IvozProvider跟踪那些NAT窗口并使用NAT穿透机制保持它们活着 。

3，Iovzprovide实验

3.1关于ip配置

Iovzprovide可以根据管理节点的多少配置不同的ip，管理节点包括2.2提到的多级门户，除过全局节点外其他节点都可以配置多个。且每个节点可以配置一个ip或者多个ip。

如果配置一个ip，可同时作为门户访问ip和sip代理ip，也可以配置多个ip分别作为门户ip和sip代理ip。

理论上配置的这些ip都可以是公网ip。

终端使用不同的域（ip）可以注册到不同的节点上。

3.2关于呼叫

     Iovzprovide用户配置在公司节点上进行。可以使用用户名注册和通话，如zhangsan、lisi。

     公司之间号码可以相同，但公司之间号码可以互通。如公司1有号码1001，公司2也有1001，使用不同的公司域可以分别注册，且可以互通电话。

理论上这种互通可以想办法闭掉，目前没找到。

未进行外部呼叫测试。

3.3关于门户

     从全局门户开始逐级向用户节点的门户，中间节点内容的呈现是根据各级节点选择的不同动态呈现的。

    如，全局门户建立有三个品牌B1，B2，B3。B1创建公司C1，C2，B2创建公司C3。C1创建用户U1，U2，U3。C3创建U4。那么管理时，下级管理子数会由上级的选择自动生成。

4，经验感受

1.由于不能看到该工程的具体设计，暂时没能搞明白它所谓的横向扩展的方式、方法。

2.看它的设计思路，感觉它设计的as是不与sip代理固定绑定的，是根据业务需求动态平衡的。

3.我认为这个工程在门户上的设计还是有借鉴意义的。

4.它使用的一些开源工程比如业务质量监控等也可以借鉴。

5.总体感觉它的设计思路跟我们的设计还是有区别的。