推荐PDT系统二次开发接口设计方案精品Word下载.docx
- 文档编号:17134169
- 上传时间:2022-11-28
- 格式:DOCX
- 页数:29
- 大小:405.40KB
推荐PDT系统二次开发接口设计方案精品Word下载.docx
《推荐PDT系统二次开发接口设计方案精品Word下载.docx》由会员分享,可在线阅读,更多相关《推荐PDT系统二次开发接口设计方案精品Word下载.docx(29页珍藏版)》请在冰豆网上搜索。
实时传输控制协议
SNMP
SimpleNetworkManagementProtocol
简单网络管理协议
XML
eXtensibleMarkupLanguage
可扩展标记语言
API
ApplicationProgrammingInterface
应用程序编程接口
PDT
PublicDigitalTrunk
共用数字集群
NMS
NetworkManageSystem
网络管理系统
2设计思路
2.1业务概述
PDT集群系统二次开发接口应该以二次开发商的需求为导向,结合PDT集群系统设计和建设的实际情况,而进行设计,理想情况是将二者统一考虑,使PDT集群系统的设计自然包含了二次开发的接口,故本文档尽量从PDT集群系统的业务分类和设计出发,进行二次开发接口设计。
PDT集群系统二次开发接口业务主要分为业务面和管理面两个方面。
业务面主要是指PDT集群系统提供的专业通信方面的通信业务,按PDT系统的划分,又分为控制面与数据面(业务面)两个部分。
控制面分为服务认证、呼叫控制、短消息/GPS数据、分组控制等,数据面主要是语音媒体和分组数据。
注:
短消息/GPS数据也可以划分到数据面。
管理面是为了辅助PDT集群系统完成通信业务而实施的一些辅助业务,目前按PDT系统划分,管理面基本由网管层面完成,它包含了配置、管理、监控等方面的内容。
配置包含PDT系统现有的可供用户配置的内容和二次开发接口可能扩展的配置;
管理包含用户管理、组管理、权限管理、各种信息记录与统计等;
监控包含对PDT系统的监视、控制、报警等。
目前二次开发接口暂不考虑互联业务。
综上所述,目前PDT系统二次开发接口考虑的层面大致如下图:
2.2设计准则
二次开发接口设计应遵循的准则:
1)以满足系统集成商二次开发的需求为导向;
2)结合PDT集群系统设计和建设的实际情况;
3)应尽可能地方便系统集成开发商进行开发和集成;
4)应最大程度地保障数字集群系统运行的安全性和可靠性;
5)应充分地考虑二次开发接口的可扩展性和可演进性;
2.3方案由来
根据设计准则,我们可以将二次开发接口设计分为两个部分进行考虑:
PDT集群系统部分、二次开发用户部分。
对于PDT集群系统部分,为了最大程度保障集群系统运行的安全性和可靠性,应尽量将PDT集群系统的设计和二次开发接口统一考虑或维持原有设计,对系统设计的改动尽量少甚至不要改动,将二次开发接口作为系统发展的自然延伸。
从业务层面来说:
1)业务类控制面的设计,PDT系统在调度和互联方向,现在已经提供了SIP协议方式来进行控制面的设计,从现有设计和以后需要扩展的设计来说,SIP协议应该完全能够满足此方向上业务类控制面设计的要求,故PDT系统应该沿用SIP方案进行设计。
2)对于业务类数据面,目前语音媒体数据是用RTP协议进行传输,而分组数据目前系统还没有设计,这方面肯定是要沿用现有设计的,此处不过多讨论。
3)对于管理类网管面,目前网管部分一部分是使用标准SNMP协议来进行设计,另外的一些部分可能需要用到一些自定义的协议来进行设计,而对于以后需要扩展的部分,也有一部分可以继续沿用SNMP协议进行设计,还有一部分也需要自定义协议进行设计,故管理类网管面也需要沿用以前的方案设计,后续设计可能需要考虑与二次开发接口的配合。
结合上述三个方面的分析,PDT集群系统部分在二次开发接口的业务层面,目前的设计是多样化的,总的来说设计的技术手段有四种:
SIP、RTP、SNMP、自定义协议。
对于二次开发用户部分,提供给用户的接口应该满足:
功能性(即充分满足用户需求)、易用性(利于用户学习与使用)、可维护性(即接口的可扩展和可演进性)。
对于不熟悉PDT系统的二次开发用户,他们的需求肯定是易用性放在第一位的,要满足这类用户的要求,则要求提供的二次开发接口应该极具可读性,即要求二次开发接口对业务的抽象非常好,符合用户对事物的逻辑认知。
对于熟悉PDT系统的二次开发用户,他们对功能性的要求更高,甚至可能涉及到了一些技术细节,他们可能直接可以使用PDT系统现有的四种技术手段(SIP、SNMP、RTP、自定义协议)中的一部分或者全部来进行二次开发,当然他们的需求也可能与不熟悉PDT系统的二次开发用户一样。
综合上面两部分的考虑,我们可以考虑在PDT集群系统与二次开发用户程序之间的传输机制上进行一些变通,即两者之间的传输方式是可以扩展的,支持多样化的。
它既可以传输抽象好后的接口来实现业务功能,也可以直接传输PDT集群系统的SIP、SNMP等原始消息来实现业务功能,在技术层面来说,XML协议是能很好的做到这一点的,这里把采用XML作为二次开发接口的传输方式的方案定义为XML二次开发接口方案。
当然,能实现上面所说的这些要求,并不一定只有XML方案适合,其实用SIP协议封装也能达到要求,这里把采用SIP作为二次开发接口的传输方式的方案定义为SIP二次开发接口方案。
然而传统的二次开发接口都是以API的形式来体现的,用API也能够实现上述要求,这里把以API形式体现作为二次开发接口的方案定义为API二次开发接口方案(API二次开发接口方案的传输形式可以是XML也可以是SIP更可以是私有协议)。
结合上述分析,二次开发接口的设计方案主要有三种:
1)SIP二次开发接口方案;
2)API二次接口开发方案。
3)XML二次开发接口方案;
以下本文档就对三种方案进行初步设计与分析,然后比较三种方案,并提出最终的推荐方案。
2.4SIP二次开发接口方案设计思路
2.4.1SIP二次开发接口方案出发点
PDT系统采用SIP协议作为网络互联的协议标准,而且调度台也是使用SIP协议进行调度业务实施,实际系统开发中已经做了相应卡率,目前已拥有一定基础。
SIP协议也能通过扩展来实现其他的一些功能。
2.4.2SIP二次开发接口方案优缺点
优点:
1)SIP是一项类似于HTTP的基于文本的协议,使用方便且易于扩展,是目前基于IP的非常流行的一种通信协议;
2)PDT系统采用SIP协议作为网络互联和调度台的协议标准,实际系统开发中已经拥有一定基础;
3)SIP对于二次开发接口中的业务类接口有良好的支持。
缺点:
1)SIP作为二次开发接口直接提供给二次开发人员使用,对二次开发人员的技术要求相对较高,二次开发人员需了解SIP协议;
2)SIP对于用户管理、设备监控等方面的支持尚需扩展,即SIP对二次开发接口中的网管类接口支撑力度有限,甚至不适用。
2.4.3SIP二次开发接口方案简述
2.4.3.1设计思路要点
SIP协议作为目前应用广泛的基于IP的通信协议,PDT标准在组织在此基础上扩展的pSIP标准已经提供了呼叫、短消息等通信相关的内容,PDT系统二次开发接口可以直接使用这部分标准协议。
但在管理类用户管理、设备监控等方面,SIP并没有提供标准,这些均需要扩展SIP协议来实现,而且根据SIP的现有标准来看,扩展工作比较繁琐。
对于二次开发者,PDT系统提供专用的二次开发SIP标准,二次开发用户程序与PDT系统的通信关系图如下:
SIP二次开发接口方案在PDT系统内部的提供方式示意图:
2.4.3.2SIP标准格式
可参考SIP标准、《pSIP语法.doc》、《PDT数字集群互联标准.doc》、《PDT有线调度台接口技术规范-CR.xls》等,此处略。
2.4.3.3典型处理流程简述
为便于说明SIP二次开发接口方案设计思路,特描述1-2个典型场景。
FOACSU单呼场景
2.5API二次开发接口方案设计思路
2.5.1API二次开发接口方案出发点
API是一种比较传统的二次开发接口的表现方式。
基本上可以说所有的进行二次开发的用户,都能比较容易接受API这种形式的二次开发接口。
PDT系统的二次开发接口功能完全可以由一组API函数与事件来实现,PDT系统与API服务的交互对用户完全透明,使用各种协议或自定义数据流交互均可。
2.5.2API二次开发接口方案优缺点
1)API作为传统的二次开发接口的表现形式,很容易被二次开发者接受;
2)API作为二次开发接口,对PDT系统的内部信息能够很好的封装,API服务与PDT系统可以用任何自定义的私有协议进行通信,对二次开发用户具有很好的透明性;
3)API对二次开发接口的业务类与管理类功能,均可定义对应的API实现。
1)API作为二次开发接口的表现形式,必然需要给用户提供类似于Windows系统的dll文件,让用户进行二次开发。
根据API提供的文件的不同,就需要对二次开发用户所用的操作系统和开发工具进行限制;
2)API的可扩展性有一定的不足,且对于版本管理有一定的要求,而且新提供版本以后,二次开发程序大多需要重编译,而对于SIP、XML二次开发方案则能很好的规避这种缺陷。
2.5.3API二次开发接口方案简述
2.5.3.1设计思路要点
API二次开发接口方案预先定义一组结构和函数,以文件的形式提供给二次开发者使用。
API二次开发接口方案以二次开发程序调用函数,系统利用回调函数返回事件数据完成交互。
二次开发用户程序与PDT系统的通信关系图如下:
API二次开发接口方案在PDT系统内部的提供方式示意图:
2.5.3.2API定义
函数格式:
PDT_主功能名_子功能名(参数列表)
回调函数格式:
PDT_CALLBACK_FUNCTION(事件类型,成功标志,事件数据)
事件类型有两种:
1)调用函数的响应事件
事件类型名:
函数名_Ack
2)PDT系统主动上报的事件
PDT_主功能名_子功能名_Ind用户不需要调用函数响应的事件
PDT_主功能名_子功能名_Req用户需要调用函数进行响应的事件
API方式的交互原理图:
API方案各函数事件实际的例子详见”中的应用。
2.5.3.3典型处理流程简述
为便于说明API二次开发接口方案设计思路,特描述1-2个典型场景。
2.6XML二次开发接口方案设计思路
2.6.1XML二次开发接口方案出发点
XML具有很强的开放性,使得许多软件生产商提供的软件产品支持XML,使得XML成为不同用户的异构应用系统之间的数据交换的标准语言,具备了数据交换的透明性、各个用户只要保证自己的信息系统提供的数据符合XML规范,就不用担心数据接收方的解码问题。
XML不依赖于实现语言和运行环境,且具有很强的可读性和易用性,利用XML作为二次开发接口方案具有很明显的优点。
对于目前PDT系统业务类的采用的SIP协议和网管类采用的SNMP协议,XML都可以以嵌入SIP与SNMP的方式兼容,而且XML很容易扩展一些SIP、SNMP等标准协议不容易扩展的内容,故引发出XML二次开发接口方案。
更对分析可参见“”章节。
2.6.2XML二次开发接口方案优缺点
1)XML文档的内容和结构完全分离,这使得XML能够很简单的内嵌SIP、SNMP等协议内容,同时也可以嵌入自定义的元素来实现功能的扩展;
2)XML文档互操作性强,纯文本文件可以方便地穿越防火墙,在不同操作系统上的不同系统之间通信;
3)XML具有统一的标准语法,任何系统和产品所支持的XML文档,都具有统一的格式和语法。
这样就使得XML具有了跨平台跨系统的特性;
4)XML是一种可扩展的语言,可以根据XML的基本语法来进一步限定使用范围和文档格式,从而定义一种新的语言,易于让用户认可与接受;
5)XML目前流行于很多场合,典型场合如:
数据交换、Web服务与集成、内容管理、配置等,这让PDT系统定义XML二次开发接口能够借鉴一些比较成熟的方案的经验,让XML二次开发方案更加可行;
6)XML对于二次开发接口的业务类控制面和管理类(网管类)各类功能可以嵌入SIP、SNMP方式实现,也可以扩展XML语法标准来实现,甚至对于业务类数据面的功能,XML也完全可以承载。
1)大数据量低效率。
XML的文本表现手法、标记的符号化会导致XML数据比二进制表现数据量增加,尤其当数据量很大的时候,效率就成为很大的问题。
针对这一缺点,PDT集群系统二次开发接口设计方案可将数据量很大的业务类数据面沿用系统已有的RTP/RTCP协议,这将有效的规避XML的此缺点;
2)XML是树状存储,虽然搜索效率极高,但是插入和修改比较困难。
这项缺点是针对数据项的,在PDT集群系统的二次开发接口中,关于数据检索类的需求应该很少甚至没有,可以忽略XML的该缺点。
2.6.3XML二次开发接口方案简述
2.6.3.1设计思路要点
XML的语法非常简单且基于文本便于阅读,对二次开发用户的技术要求不高。
XML的结构与内容分离,可以很方便的把现有的PDT系统中使用到的SIP、SNMP等协议内容嵌入到XML中,提高了模块的重用率。
对于不熟悉SIP、SNMP的二次开发用户,可以定义类似于API的原语来充当XML的内容。
同时,XML也能很好的进行扩展。
对于XML二次开发接口方案,PDT系统仅需提供自己的XML标准规则,二次开发用户即可进行二次开发,无需限定二次开发程序的开发环境与运行环境。
XML二次开发接口方案在PDT系统内部的提供方式示意图:
2.6.3.2XML标准格式
1)对于已有标准的兼容格式
<
PDT>
协议名称>
协议数据单元<
/协议名称>
/PDT>
例如SIP消息:
SIP>
SIP消息数据单元<
/SIP>
2)对于扩展的功能
二次开发程序主动发起的功能:
API>
<
!
--用户发送的指令-->
FunctionMain>
<
FunctionSub>
<
Parameter1>
Parameter1<
/Parameter1>
Parameter2>
Parameter2<
/Parameter2>
Parameter3>
Parameter3<
/Parameter3>
/FunctionSub>
/FunctionMain>
/API>
PDT系统响应:
--用户发送的原指令-->
--对应用户指令的返回事件-->
EventMain>
EventSub>
/EventSub>
/EventMain>
PDT系统主动发起的功能:
--PDT系统事件-->
Parameter>
/Parameter>
例:
二次开发程序发起的呼叫请求:
CC>
CallSetup>
Called>
2000001<
/Called>
CallType>
FOACSU<
/CallType>
UserPrivateFlag>
1<
/UserPrivateFlag>
/CallSetup>
/CC>
PDT系统对呼叫请求的响应:
CallSetupAck>
Flag>
Success<
/Flag>
Ind>
Ringing<
/Ind>
/CallSetupAck>
PDT系统主动上报的呼叫PDT系统主动挂机:
CallCancel>
Reason>
CalledCancel<
/Reason>
2.6.3.3典型处理流程简述
为便于说明XML二次开发接口方案设计思路,特描述1-2个典型场景。
XML嵌入SIP方式场景同。
XML扩展功能方式场景同。
3设计方案初步建议
3.1方案对比情况列表
对于上述的三种方案,以下表格是对各方案在用户的角度进行对比的情况:
方案
提供的资料
开发与运行环境的限制
易用性
可扩展性
备注
SIP标准文档
无
难
一般
可封装API
API文档、头文件、运行库文件
有
易
XML标准文档
好
对于上述三种方案,以下表格式对各方案在实现二次开发功能的适用程度对比的情况:
业务类控制面
业务类数据面
管理类(网管类)
适用
语音媒体暂沿用RTP
分组数据待定
SIP承载数据不适用
不适用
适用(自定义协议)
API承载数据可利用回调函数上报方式进行
适用(可嵌入SIP实现,也可自定义XML语法实现)
XML承载数据适用
适用(可嵌入SNMP实现,也可自定义XML语法实现)
3.2方案开发阶段对比
根据需求和开发的难易程度,PDT系统二次开发接口方案提供接口的优先级次序大致如下表:
(业务类类数据面语音媒体数据建议直接使用RTP,另外以后有可能增加的分组数据暂不作考虑。
)
接口分类
优先级
具体功能
方案对比
服务认证类
A
服务请求
服务认证
服务拒绝
对业务类的基础功能,目前PDT系统已有完整的SIP协议支撑。
采用三种方案的任何一种,对于PDT系统的工作也没有需要调整的地方,还是可以一直沿用SIP协议。
SIP方案在这一块的工作量最少,仅需整理协议文档即可。
XML方案在此处可以考虑嵌入SIP的方式,这样工作量和SIP方案相近;
考虑到使用SIP对技术门槛有一定要求,XML方案也可以自定义协议来完成业务类功能接口,这部分工作主要在于XML与SIP的相互转换,工作量适中。
API方案在此处的工作量类似于XML方案的第二种情况。
呼叫控制类
呼叫基础类
单呼
组呼
紧急呼叫
全呼
广播呼叫
呼叫补充类
B
呼叫转移
包容呼叫
强拆/强插
动态重组
呼叫授权
混音控制
短消息类
短消息单呼
短消息组呼
状态呼叫
分组消息类
C
待定
其他业务类功能
D
配置类
PDT系统目前各类由网管负责的配置
对网管类的基础功能,目前主要由网管部门用SNMP或自定义接口来实现。
采用任一种方案,网管部门开发方式不变,由二次开发接口服务来实现二次开发接口的转换。
SIP方案在网管类功能接口上,标准SIP没有提供很好的支持方法,扩展工作量比较大。
XML方案和业务类功能接口类似,也有两种方法可以选择,一种是直接嵌入SNMP,工作量最小;
另一种方法就是XML自定义协议,需XML与SNMP的互转。
API方案与XML方案的第二种方法类似。
管理类
用户管理类
新建用户
修改用户权限
删除用户
遥晕/遥闭/恢复
组管理类
新建组
修改组权限
删除组
各种信息记录与统计
通话记录与统计
录音记录与统计
其它
监控类
用户监控类
用户状态监控
用户位置监控
呼叫监控类
呼叫监控
呼叫录音
短消息监控
设备监控类
基站设备监控与告警
基站环境监控与告警
交换设备监控与告警
控制设备监控与告警
链路设备监控与告警
网络安全设备监控与告警
综上所述,无论二次开发接口才用何种方案,都建议遵循不影响PDT系统现有设计为原则,二次开发接口服务进行二次开发接口与PDT系统内部交互协议之间的转换。
对比之下,XML方案应该是能够以比较小的代价达到这个目标的方案。
3.3方案建议
3.3.1推荐方案
推荐使用的方案:
XML二次开发方案。
推荐理由:
1)XML文档结构简单,易于理解,
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 推荐PDT系统二次开发接口设计方案 精品 推荐 PDT 系统 二次开发 接口 设计方案