EEPW论坛

第二章 需求分析

2.1 业务场景

在电梯发生通话事件时、并且网路处于通路状态下，被叫端（如客服中心）收到事件后，被叫端（如客服中心）与轿厢内人员进行通话、并随时可以观察轿厢内场景。

2.2 用户需求

用户在需要的情况下可以拨通远程IPC进行双向通话，同时在必要的情况下可以观看现场视频；用户在需要的情况下可应用现场IPC进行远程呼叫救援或客服中心。

2.3 功能需求

(1) 通话传输64Kbps带宽下进行双向语言信息(P2P) 传输，使得双方可进行语音交互。

(2) 轿厢内的视频通过摄像头传输至服务端进行广播模式的单向信息流传输，可同时多终端观看视频。

(3) 使用VoIP作为系统的信令，进行会话信息构建、交互，实现人员终端主动呼叫、被叫端自动应答功能。

(4) 系统包括终端摄像头、信令服务器、视频服务器、NAT穿透服务器等。

2.4 项目范围

1 

1.1 

1.2 

1.3 

1.4 

2.4.1 范围描述

(1) 实现语音数据双向实时通话即语音编码、压缩、发送、解码、播放。

(2) 实现视频单向传输，点播方式即图像采集、处理、编码压缩、打包、发送、转播。

(3) 实现SIP服务及客户端SDP信息交互、保活、****息发送、通话保持、拨号服务。

(4) 实现RTMP服务端视频流接收转发。

(5) 实现本地配置参数文件化保存、处理、预加载。

(6) 实现嵌入式端系统守护进程调度、加载参数、启动特定进程。

(7) 实现服务端NAT穿透服务构建。

(8) 实现服务端流媒体点播服务。

2.4.2 验收标准

(1) 语音通话被叫端网络采用4G dtu的网络、主叫端在宽带网络中，传播时延在1s内。

(2) 视频在宽带有线服务中实现有效播放，时延在5s~10s内。

(3) 主叫端采用拨号方式进行呼叫被叫端，被叫端以自动回复方式打开语音通话，视频采用短消息文本方式打开，进行点播方式，在主叫端可自动发送短消息文本。

2.4.3 可交付成果

(1) 远程服务器端实现SIP转发服务、NAT穿透服务、RTMP流媒体服务。

(2) 客户端（包含主叫、被叫端）实现嵌入式媒体采集终端，具有语音播放、视频采集发送功能。

第三章 数据结构设计

在本次设计中考虑到系统的实际应用性，无论服务端还是客户端均未采用关系型数据库来存取系统中的任何数据，而是采用了最原始的文件系统方式来存取数据。在服务端多数采用XML文本格式（或纯TEXT格式）配置、加载、处理参数数据；在客户端采用JSON文本方式存储、加载、处理参数数据，并用二进制格式的文本方式处理缓存数据。

2 

3 

3.1 服务端

2 

2.1 

服务端主要采用开源应用模块构建系统架构，其数据结构完全依赖原有应用程序的结构组成，采用文本TEXT方式记录、处理数据，以下进行应用的数据结构分析，以及叙述其配置部分的方法。

3.1.1 freeswitch用户数据结构分析

通过freeswitch自建XML数据管理文档进行用户、系统的ID及密码管理，配置文件通过Sofia管理工具进行加载。其目录结构主要位于freeswitch/conf 下，用户拨号参数配置文件位于dialplan目录下的default.xml文件中；用于用户号码管理的文件位于directory/default目录下的标号为1000~1019的XML文件中，用于各个号码差异化处理，当然也可以进行复制该文件新建号码的方式来扩充用户；主要的系统配置文件在sip_profiles目录下，其主要分为内部呼叫控制文件、外部呼叫控制文件，区别在于网络的结构如inbound、outbound和IPv4、IPv6 等，在这里可以设置freeswitch的服务器IP、通讯层协议、媒体服务模式等；在var.xml文件中可以直接设计启动参数和临时更改参数，以命令行“loadxml”动态加载，无需重启整个服务。freeswitch整体结构类似一个微内核系统，由一个调度核心外加各种模块组成，每个模块均以独立进程的方式进行运行，符合软件设计的高内聚低耦合特点。

3.1.2 Coturn 之NAT穿透服务数据结构分析

其系统配置文件位于/usr/local/etc/turnserver.conf文件中，可以从其启动的日志看出其配置的所有参数情况，最重要的是ssl加密密钥的文件加载，传输层数据结构的支持，以及内部、外部服务器IP配置、域配置参数、用户名密码配置参数、端口处理方式等。在穿透处理时采用hash的随机数算法得到对端链接用户ID、密码，而后进行对端P2P的穿越链接的校验。

3.1.3 RTMP媒体数据结构分析

RTMP媒体服务主要采用Nginx+librtmpmodul的方式进行构建，主要数据结构由/usr/local/nginx/conf/nginx.conf文件来管理，在其中可配置http的代理服务器端口映射、流路径控制、端口服务、数据交换、流类型等。媒体数据流打包成RTMP数据包通过传输层tcp协议传输至服务端，而后进行数据交互分发，或以RTMP形式或以HLS形式进行点播观看。可以通过不同路径编号来达到区别流数据、隐匿流数据的目的，同时也可以加载私有视频解码格式进行数据加密。

3.2 客户端

客户端主要数据结构设计分为UA数据、流媒体数据、音频数据、视频数据等。应用JSON数据结构的方式进行数据的存储、加载、交互等处理过程。在UA中交互的SDP数据、音频缓存数据、视频缓存数据，均采用静态双队列的形式，消息邮箱触发处理机制，进行流式数据架构方式构建数据结构，从而建立起相互独立，互不干扰的运行线程，应用高内聚、低耦合的软件设计理念进行应用设计。

2.2 

2.3 

3.2.1  UA数据结构模块设计

UA数据结构中包括主叫端UAC、被叫端UAS，除了身份标识号不一样外其他的数据部分均设计为一致的形式，从系统运行时调用的状态来分，又有静态数据和动态数据；静态数据包括服务的配置，本地标识号配置，动态数据包括程序运行时要动态调整的数据，例如消息体事件触发数据结构。

3.2.2  RTMP数据结构模块设计

以系统运行状态下对数据的需求分静态、动态数据结构，静态数据结构中包括服务器配置，流路径配置，流数据格式配置；动态数据结构中包括流的结构、动态调整数据格式、参数配置、内存大小限制、缓存传输数据内存大小的参数配置、加密与否以及加密方式参数配置等。

3 

3.2.2 

3.2.3 音频数据结构模块设计

音频数据结构中主要为音频的格式、帧率、包大小、缓存数据包数量、延时包丢弃配置等。其最主要的数据结构设计目的是要达到外部信号实时控制其进行数据转换的效果，无论是启动时加载还是运行过程中加载，均能在不破坏原有数据情况下进行参数变更的配置。另外要在启动音频的情况下同时进行P2P的服务器数据加载，此时多方数据交互采用共享内存之方式进行数据内容同步。

3.2.4 视频数据结构模块设计

视频数据模块与音频数据结构模块设计相似，不同之处只在于数据格式、传输路径、网络延时状态下进行参数调整其码率、帧率等。传输流数据采用RTMP协议，打包H264视频数据发送至服务端。