PDT系统二次开发接口设计方案.docx

pdt系统二次开发接口设计方案 第 3 页 共 32 页产品版本：密级：1.0机密产品名称：页数：共 页pdt系统二次开发接口设计方案v1.0(仅供内部使用）拟制:日期：审核:日期：审核:日期：批准:日期：目录目录21前言41.1目的41.2范围41.3读者对象41.4参考文献41.5缩略语52设计思路52.1业务概述52.2设计准则62.3方案由来62.4sip二次开发接口方案设计思路82.4.1sip二次开发接口方案出发点82.4.2sip二次开发接口方案优缺点82.4.3sip二次开发接口方案简述82.5api二次开发接口方案设计思路112.5.1api二次开发接口方案出发点112.5.2api二次开发接口方案优缺点122.5.3api二次开发接口方案简述122.6xml二次开发接口方案设计思路152.6.1xml二次开发接口方案出发点152.6.2xml二次开发接口方案优缺点162.6.3xml二次开发接口方案简述163设计方案初步建议213.1方案对比情况列表213.2方案开发阶段对比213.3方案建议243.3.1推荐方案243.3.2方案开发阶段建议253.3.3具体方案设计274开发方案总体设计275开发环境的配置276运行环境的配置277测试环境的配置278性能指标28ha版权所有 侵权必究 pdt系统二次开发接口设计方案 第 32 页 共 32 页1 前言1.1 目的本文档主要为pdt系统提供二次开发接口设计、二次开发开发环境配置、运行环境配置。1.2 范围pdt系统主要用于公安、码头/港口、大型厂矿企业。公安市场主要用于替代现有的mpt系统，使用场景一般为多站系统。码头/港口/大型厂矿企业一般为单站系统。不同行业客户在语音通信和数据传输方面有着各自不同的需求。系统集成商通常需要根据客户需求开发相应的应用服务软件，并与数字集群系统集成起来为客户提供相应的解决方案。数字集群系统的二次开发接口就是为集成数字集群系统与客户应用服务软件而提供的开发接口。二次开发接口通常包括服务认证、呼叫、短消息、监控、用户管理、设备监控等方面的接口。随着技术的发展，随着用户新需求的不断涌现，二次开发接口也将随之不断变化和扩展。本文档适用于pdt单播系统的二次开发指导，也可为pdt同播系统二次开发设计提供参考。1.3 读者对象本文档的阅读对象为项目负责人、项目管理人员、系统设计人员、编码人员、测试人员。1.4 参考文献数字集群系统二次开发接口设计whitepaper.pdfa-capi accessnet-t common application programming interface.pdfpdt数字集群空中接口标准.docpdt系统软件需求规格书v1.3.2.docpdt系统总体设计方案_主稿.docpdt系统总体设计方案_附件.doc1.5 缩略语表11 缩略语缩略语全称描述sipsession initiation protocol会话初始协议rtprealtime transport protocol实时传输协议rtcprealtime transport control protocol实时传输控制协议snmpsimple network management protocol简单网络管理协议xmlextensible markup language可扩展标记语言apiapplication programming interface应用程序编程接口pdtpublic digital trunk共用数字集群nmsnetwork manage system网络管理系统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.4 sip二次开发接口方案设计思路2.4.1 sip二次开发接口方案出发点pdt系统采用sip协议作为网络互联的协议标准，而且调度台也是使用sip协议进行调度业务实施，实际系统开发中已经做了相应卡率，目前已拥有一定基础。sip协议也能通过扩展来实现其他的一些功能。2.4.2 sip二次开发接口方案优缺点优点：1) sip是一项类似于http的基于文本的协议，使用方便且易于扩展，是目前基于ip的非常流行的一种通信协议；2) pdt系统采用sip协议作为网络互联和调度台的协议标准，实际系统开发中已经拥有一定基础；3) sip对于二次开发接口中的业务类接口有良好的支持。缺点：1) sip作为二次开发接口直接提供给二次开发人员使用，对二次开发人员的技术要求相对较高，二次开发人员需了解sip协议；2) sip对于用户管理、设备监控等方面的支持尚需扩展，即sip对二次开发接口中的网管类接口支撑力度有限，甚至不适用。2.4.3 sip二次开发接口方案简述 设计思路要点sip协议作为目前应用广泛的基于ip的通信协议，pdt标准在组织在此基础上扩展的psip标准已经提供了呼叫、短消息等通信相关的内容，pdt系统二次开发接口可以直接使用这部分标准协议。但在管理类用户管理、设备监控等方面，sip并没有提供标准，这些均需要扩展sip协议来实现，而且根据sip的现有标准来看，扩展工作比较繁琐。对于二次开发者，pdt系统提供专用的二次开发sip标准，二次开发用户程序与pdt系统的通信关系图如下：sip二次开发接口方案在pdt系统内部的提供方式示意图： sip标准格式可参考sip标准、psip语法.doc、pdt数字集群互联标准.doc、pdt有线调度台接口技术规范-cr.xls等，此处略。 典型处理流程简述为便于说明sip二次开发接口方案设计思路，特描述1-2个典型场景。.1 foacsu单呼场景2.5 api二次开发接口方案设计思路2.5.1 api二次开发接口方案出发点api是一种比较传统的二次开发接口的表现方式。基本上可以说所有的进行二次开发的用户，都能比较容易接受api这种形式的二次开发接口。pdt系统的二次开发接口功能完全可以由一组api函数与事件来实现，pdt系统与api服务的交互对用户完全透明，使用各种协议或自定义数据流交互均可。2.5.2 api二次开发接口方案优缺点优点：1) api作为传统的二次开发接口的表现形式，很容易被二次开发者接受；2) api作为二次开发接口，对pdt系统的内部信息能够很好的封装，api服务与pdt系统可以用任何自定义的私有协议进行通信，对二次开发用户具有很好的透明性；3) api对二次开发接口的业务类与管理类功能，均可定义对应的api实现。缺点：1) api作为二次开发接口的表现形式，必然需要给用户提供类似于windows系统的dll文件，让用户进行二次开发。根据api提供的文件的不同，就需要对二次开发用户所用的操作系统和开发工具进行限制；2) api的可扩展性有一定的不足，且对于版本管理有一定的要求，而且新提供版本以后，二次开发程序大多需要重编译，而对于sip、xml二次开发方案则能很好的规避这种缺陷。2.5.3 api二次开发接口方案简述 设计思路要点api二次开发接口方案预先定义一组结构和函数，以文件的形式提供给二次开发者使用。api二次开发接口方案以二次开发程序调用函数，系统利用回调函数返回事件数据完成交互。二次开发用户程序与pdt系统的通信关系图如下： api二次开发接口方案在pdt系统内部的提供方式示意图： api定义函数格式：pdt_主功能名_子功能名 ( 参数列表 )回调函数格式：pdt_callback_function ( 事件类型, 成功标志, 事件数据 )事件类型有两种：1） 调用函数的响应事件事件类型名：函数名_ack2） pdt系统主动上报的事件事件类型名：pdt_主功能名_子功能名_ind用户不需要调用函数响应的事件pdt_主功能名_子功能名_req用户需要调用函数进行响应的事件api方式的交互原理图：api方案各函数事件实际的例子详见api二次开发方案“.1 foacsu单呼场景”中的应用。 典型处理流程简述为便于说明api二次开发接口方案设计思路，特描述1-2个典型场景。.1 foacsu单呼场景2.6 xml二次开发接口方案设计思路2.6.1 xml二次开发接口方案出发点xml具有很强的开放性，使得许多软件生产商提供的软件产品支持xml，使得xml成为不同用户的异构应用系统之间的数据交换的标准语言，具备了数据交换的透明性、各个用户只要保证自己的信息系统提供的数据符合xml规范，就不用担心数据接收方的解码问题。xml不依赖于实现语言和运行环境，且具有很强的可读性和易用性，利用xml作为二次开发接口方案具有很明显的优点。对于目前pdt系统业务类的采用的sip协议和网管类采用的snmp协议，xml都可以以嵌入sip与snmp的方式兼容，而且xml很容易扩展一些sip、snmp等标准协议不容易扩展的内容，故引发出xml二次开发接口方案。更对分析可参见“2.3 方案由来”章节。2.6.2 xml二次开发接口方案优缺点优点：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.3 xml二次开发接口方案简述 设计思路要点xml的语法非常简单且基于文本便于阅读，对二次开发用户的技术要求不高。xml的结构与内容分离，可以很方便的把现有的pdt系统中使用到的sip、snmp等协议内容嵌入到xml中，提高了模块的重用率。对于不熟悉sip、snmp的二次开发用户，可以定义类似于api的原语来充当xml的内容。同时，xml也能很好的进行扩展。对于xml二次开发接口方案，pdt系统仅需提供自己的xml标准规则，二次开发用户即可进行二次开发，无需限定二次开发程序的开发环境与运行环境。二次开发用户程序与pdt系统的通信关系图如下：xml二次开发接口方案在pdt系统内部的提供方式示意图： xml标准格式1） 对于已有标准的兼容格式协议数据单元例如sip消息：sip消息数据单元2） 对于扩展的功能二次开发程序主动发起的功能：parameter1parameter2parameter3pdt系统响应：parameter1parameter2parameter3parameter1parameter2parameter3pdt系统主动发起的功能：parameter1parameter2parameter3例：二次开发程序发起的呼叫请求：2000001foacsu1pdt系统对呼叫请求的响应：2000001foacsu1successringingpdt系统主动上报的呼叫pdt系统主动挂机：calledcancel 典型处理流程简述为便于说明xml二次开发接口方案设计思路，特描述1-2个典型场景。.1 foacsu单呼场景xml嵌入sip方式场景同sip二次开发方案“.1 foacsu单呼场景”。xml扩展功能方式场景同api二次开发方案“.1 foacsu单呼场景”。3 设计方案初步建议3.1 方案对比情况列表对于上述的三种方案，以下表格是对各方案在用户的角度进行对比的情况：方案提供的资料开发与运行环境的限制易用性可扩展性备注sipsip标准文档无难一般可封装apiapiapi文档、头文件、运行库文件有易一般xmlxml标准文档无易好可封装api对于上述三种方案，以下表格式对各方案在实现二次开发功能的适用程度对比的情况：方案业务类控制面业务类数据面管理类（网管类）sip适用语音媒体暂沿用rtp分组数据待定sip承载数据不适用不适用api适用（自定义协议）语音媒体暂沿用rtp分组数据待定api承载数据可利用回调函数上报方式进行适用（自定义协议）xml适用（可嵌入sip实现，也可自定义xml语法实现）语音媒体暂沿用rtp分组数据待定xml承载数据适用适用（可嵌入snmp实现，也可自定义xml语法实现）3.2 方案开发阶段对比根据需求和开发的难易程度，pdt系统二次开发接口方案提供接口的优先级次序大致如下表：（业务类类数据面语音媒体数据建议直接使用rtp，另外以后有可能增加的分组数据暂不作考虑。）接口分类优先级具体功能方案对比业务类控制面服务认证类a服务请求服务认证服务拒绝对业务类的基础功能，目前pdt系统已有完整的sip协议支撑。采用三种方案的任何一种，对于pdt系统的工作也没有需要调整的地方，还是可以一直沿用sip协议。sip方案在这一块的工作量最少，仅需整理协议文档即可。xml方案在此处可以考虑嵌入sip的方式，这样工作量和sip方案相近；考虑到使用sip对技术门槛有一定要求，xml方案也可以自定义协议来完成业务类功能接口，这部分工作主要在于xml与sip的相互转换，工作量适中。api方案在此处的工作量类似于xml方案的第二种情况。呼叫控制类呼叫基础类a单呼组呼紧急呼叫全呼广播呼叫呼叫补充类b呼叫转移包容呼叫强拆/强插动态重组呼叫授权混音控制短消息类a短消息单呼短消息组呼状态呼叫分组消息类c待定其他业务类功能d待定管理类（网管类）配置类apdt系统目前各类由网管负责的配置对网管类的基础功能，目前主要由网管部门用snmp或自定义接口来实现。采用任一种方案，网管部门开发方式不变，由二次开发接口服务来实现二次开发接口的转换。sip方案在网管类功能接口上，标准sip没有提供很好的支持方法，扩展工作量比较大。xml方案和业务类功能接口类似，也有两种方法可以选择，一种是直接嵌入snmp，工作量最小；另一种方法就是xml自定义协议，需xml与snmp的互转。api方案与xml方案的第二种方法类似。管理类用户管理类a新建用户修改用户权限删除用户遥晕/遥闭/恢复组管理类a新建组修改组权限删除组各种信息记录与统计b通话记录与统计录音记录与统计其它监控类用户监控类b用户状态监控用户位置监控呼叫监控类b呼叫监控呼叫录音短消息监控设备监控类a基站设备监控与告警基站环境监控与告警交换设备监控与告警控制设备监控与告警链路设备监控与告警网络安全设备监控与告警综上所述，无论二次开发接口才用何种方案，都建议遵循不影响pdt系统现有设计为原则，二次开发接口服务进行二次开发接口与pdt系统内部交互协议之间的转换。对比之下，xml方案应该是能够以比较小的代价达到这个目标的方案。3.3 方案建议3.3.1 推荐方案推荐使用的方案：xml二次开发方案。推荐理由：1） xml文档结构简单，易于理解，容易被二次开发用户接受；2） xml方案仅需提供给用户二次开发文档介绍xml自定义协议即可，对二次开发用户的开发与运行环境不做任何要求；3） xml方案可扩展性非常强，而且版本管理可以做到完全前向兼容，pdt系统二次开发服务版本升级并不影响二次开发程序的运行；4） xml方案具有很强的兼容性而且可以提供很大的自由度。例如技术优势比较突出的二次开发用户完全可以用xml内嵌sip、snmp等符合pdt系统协议的标准协议与pdt系统交互，而对技术并不是很强的二次开发用户，也可以提供xml自定义语法来实现同样的功能，用户仅需按规则填入功能与参数既能实现与pdt系统的交互；5） xml方案可以兼容api方案，对于习惯于api使用的二次开发用户，pdt系统完全可以以xml自定义协议为通讯标准，简单封装即可形成api头文件和运行库供给二次开发用户使用；6） xml方案给二次开发用户使用时，可以简单转换即可提供多种使用方式。例如，xml很容易切换到命令行调用方式，让习惯命令行的用户使用。xml方案实现pdt集群系统二次开发接口的系统结构示意图