CN1599353B

CN1599353B - 基于网间互联协议的话务台系统及其通话方法

Info

Publication number: CN1599353B
Application number: CN031596223A
Authority: CN
Inventors: 张德文; 王聪
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2003-09-19
Filing date: 2003-09-19
Publication date: 2010-04-07
Anticipated expiration: 2023-09-19
Also published as: CN1599353A

Abstract

本发明涉及话务台，公开了一种基于网间互联协议的话务台系统及其工作方法，使得在下一代网络中能够实现话务台的功能。这种基于网间互联协议的话务台系统包含依次连接的用户交互模块、核心功能模块、内部协议处理模块和网络接口模块，其中所述用户交互模块用于接收用户的指令并发送给所述核心功能模块，或者从所述核心功能模块获取需要显示的信息并显示给用户；所述核心功能模块用于完成呼叫处理、用户数据管理和话单管理功能；所述内部协议处理模块用于对内部协议消息的打包和解包，在收到外部的需要确认的消息时发送确认消息；所述网络接口模块，与外部的IP网络连接，用于收发IP数据包。

Description

基于网间互联协议的话务台系统及其通话方法

技术领域

本发明涉及话务台，特别涉及基于IP协议的话务台。

背景技术

传统的语音通信网络即公用电话交换网(Public Switched TelephoneNetwork，简称″PSTN″)是基于电路交换的网络，在这种网络中，话务台是基于电路交换的。

在采用2B+D的综合业务数字网(Integrated Services Digital Network，简称″ISDN″)中，两个B通道以每信道64Kbps的速率传送数据或将两个信道捆绑在一起以128Kbps的速率使用；一个16Kbps的控制信道D通道，用来传递信号，如建立或切断通话，传递控制信号。

传统的话务台一般采用2B+D的ISDN链路实现与用户交换机(PrivateBranch Exchange，简称″PBX″)的连接，话务台与用户交换机之间采用一个B通道建立半永久连接，完成话路承载。话务台与用户交换机之间的通信承载在D通道上。

下一代网络(Next Generation Network，简称″NGN″)不同于PTSN，NGN是基于统一协议的、基于分组的网络。近几年随着网间互联协议(Internet Protocal，简称″IP″)的发展，人们认识到电信网络、计算机网络及有线电视网络将最终汇集到统一的IP网络上，即人们通常所说的″三网″融合大趋势，IP协议使得各种以IP为基础的业务都能在不同的网上实现互通，人类首次具有了统一的为三大网都能接受的通信协议。

NGN是以业务驱动为特征的网络，将业务从承载网中剥离出来，灵活地构建于一个统一的开放平台上，由于平台的开放性和标准性，未来业务的开发者可能是运营商，也可能是第三方，从而可以使业务的种类得到极大地丰富。

NGN应该是可以同时提供话音、数据、多媒体等多种业务的综合性的、全开放的网络平台体系，可以归纳为三大特点：采用分层的全开放的网络，具有独立的模块化结构；是业务驱动的网络，业务和呼叫控制完全分离，呼叫与承载完全分离；是基于统一协议的分组的网络体系。而具有这些功能的下一代网络关键技术是软交换。

作为下一代业务网络的核心技术之一，软交换(Softswitch)目前得到了业界的普遍支持。Softswitch思想吸取了IP、异步转移模式(AsynchronousTransfer Mode，简称″ATM″)、智能网络(Intelligent Network，简称″IN″)和时分多路复用(Time Division Multiplexing，简称″TDM″)等众家之长，形成分层的全开放的体系构架，使得各个运营商可以根据自己的需要，全部或部分利用Softswitch体系的产品，采用适合自己的网络解决方案，在充分利用现有资源的同时，寻找到自己的网络立足点。

在实际应用中，上述方案存在以下问题：传统的话务台不能适用于下一代网络。随着IP网络的广泛使用和软交换技术的发展，客观上要求提供基于IP网络的话务台。

造成这种情况的一个主要原因在于，NGN是基于软交换的网络，也可以说NGN是基于统一协议的、基于分组的网络，而传统话务台是应用于传统的基于电路交换的网络PSTN中，因此传统话务台不适应NGN。

发明内容

本发明要解决的技术问题是提供一种基于网间互联协议的话务台系统及其通话方法，使得在NGN中能够实现话务台的功能。

为了解决上述技术问题，本发明提供了一种基于网间互联协议的话务台系统，所述系统包含依次连接的用户交互模块、核心功能模块、内部协议处理模块和网络接口模块，其中，

所述用户交互模块用于接收用户的指令并发送给所述核心功能模块，或者从所述核心功能模块获取需要显示的信息并显示给用户；

所述核心功能模块用于完成呼叫处理、用户数据管理和话单管理功能；其中，所述核心功能模块进一步包含呼叫处理子模块、用户数据管理子模块和话单管理子模块，所述呼叫处理子模块负责处理和呼叫有关的操作；所述用户数据管理子模块用于根据用户要求或定时从网络上的软交换设备下载用户信息、进行管理并在用户发送查询请求的时候输出；所述话单管理子模块用于根据用户要求或定时从网络上的软交换设备下载用户的话单信息、进行管理并在用户发送查询请求的时候输出；

所述内部协议处理模块用于对内部协议消息的打包和解包，在收到外部的需要确认的消息时发送确认消息；

所述网络接口模块，与外部的网间互联协议网络连接，用于收发网间互联协议数据包。

其中，所述系统还包含依次连接的声卡模块、音频处理模块和实时传输通道模块，其中，

所述声卡模块用于采集用户语音并转换成音频流，或将接收到的音频流还原为语音；

所述音频处理模块用于对所述音频流编码成音频包，或将音频包解码成音频流；

所述实时传输通道模块还与所述网络接口模块相连，用于支持实时传输协议/实时传输控制协议，接收来自所述网络接口模块的数据包并转换为音频包发送给所述音频处理模块，或者将来自所述音频处理模块的音频包转换为数据包发送到所述网络接口模块。

所述网络接口模块根据用户数据报协议和外界通信。

所述网络接口模块根据不同的端口号将需要发送给所述实时传输通道模块的语音信息和需要发送给所述内部协议处理模块的控制信息分离。

通过比较可以发现，本发明的技术方案与现有技术的区别在于，本方案中IP话务台通过IP网络与软交换设备和通话方连接；不同于传统的基于电路交换的话务台，IP话务台是基于软交换的，能够适用下一代网络；本发明还提出了一种可以基于多媒体个人电脑的IP话务台具体实现方式。

这种技术方案上的区别，带来了较为明显的有益效果，即该方案不但能够实现传统话务台的所有功能，而且能够适用于NGN。另外，本发明提供的话务台是在多媒体个人电脑上实现的，因此可以提供高度直观的用户图形界面，并且因为主要的业务处理可以用软件的方式实现，因此可以花费很低的升级成本通过升级软件来增加新的功能。

附图说明

图1为根据本发明的一个实施例的基于网间互联协议的话务台系统的模块结构图；

图2为根据本发明的一个实施例的基于网间互联协议的话务台通话方法流程图；

图3为根据本发明的一个实施例的基于网际互联协议的话务台查询用户信息或话单信息的方法的流程图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明作进一步地详细描述。

IP话务台终端可以运行在多媒体个人电脑(Personal Computer，简称″PC″)上，该PC的网络接入设备连接到宽带城域网上；同时宽带城域网上还接着呼叫服务器(Call Server)。IP话务台和呼叫服务器通过IP网络相互进行通信。

IP话务台实行控制流与媒体流相分离的方式，控制流和媒体流通过不同的端口发送或接收消息。IP话务台的控制信息采用自定义协议，将其封装在用户数据报协议(User Datagram Protocol，简称″UDP″)包中进行传送，话务台终端及相应的交换机主机都具有UDP包解包模块，解包后对控制消息分别进行不同的处理。IP话务台的媒体流采用实时传输协议/实时传输控制协议(Real-time Transport Protocol/Real-time Transport Control Protocol，简称″RTP/RTCP″)，较好的保证了话音的传输质量。其中RTP是用于英特网上针对多媒体数据流的一种传输协议，RTCP和RTP一起提供流量控制和拥塞控制服务。

由于话务台控制消息承载在UDP上，而UDP并不是一种面向连接的传输协议，它不能保证传输的可靠性，因此我们有必要的采取措施来保证传送消息的可靠性。在本发明的一个较佳实施例中，IP话务台中采用了一种简单的消息确认与重发机制，即对收到的每条控制信息都返回一条确认消息对其进行确认，如果在一定时间段内，发送命令方没有收到接收方的确认消息则该控制信息需要重发。使用这种方式有效地提高了消息传送的可靠性。

下面结合本发明的一个实施例来说明，该实施例的系统模块组成如图1。

IP话务台软件系统由用户交互模块10、内部协议处理模块20、核心功能模块30、音频处理模块40、声卡模块50、网络接口模块60和实时传输通道模块70组成。其中核心功能模块30还包含呼叫处理子模块31、用户数据管理子模块32和话单管理子模块33。

下面说明各模块之间的数据传输关系。用户交互模块10向核心功能模块30发送处理后的用户操作信息，核心功能模块30响应用户操作信息，完成一个处理，并向用户交互模块10反馈和用户交互的信息。内部协议处理模块20向核心功能模块30发送解包后的内部协议，核心功能模块30响应该内部协议消息，并完成相应的处理和反馈；核心功能模块30向内部协议处理模块20发送未打包的内部协议，内部协议处理模块进行相应的处理和反馈。内部协议处理模块20向网络接口模块60发送打包后的内部协议，网络接口模块60响应该信息并在成功发送后反馈信息；网络接口模块60向内部协议处理模块20发送进行UDP/IP解包后的内部协议包，内部协议处理模块20完成相应的处理并反馈确认信息。核心功能模块30向实时传输通道模块70发送通道控制信息，实时传输通道模块70响应该信息，完成相应的通道处理。实时传输通道模块70向网络接口模块60发送打包后的RTP/RTCP数据包；网络接口模块60向实时传输通道模块70发送UDP/IP解包后的数据包。核心功能模块30向音频处理模块40发送打开或者关闭音频处理模块40的消息，音频处理模块40完成相应的处理。音频处理模块40向实时传输通道模块70发送编码打包后的音频包；实时传输通道模块70向音频处理模块40发送RTP/RTCP解包后的音频包。音频处理模块40向声卡模块50发送解包解码后的音频流；声卡模块50向音频处理模块40发送采集处理后的音频流。网络接口模块60通过IP网络与软交换设备和通话另一方连接，并向IP网络发送并接收打包后的IP数据包。

用户交互模块10用于和话务员进行交互，对用户操作进行处理，发送处理后的用户操作信息并根据系统提供的信息显示话务台和用户等的状态。在本实施例中，话务员可以通过该模块进行发出呼叫请求、应答呼入呼叫和请求查询一些用户信息等操作。话务台也可以将一些系统信息通过该模块显示，本实施例中，用户交互模块10显示通话时间、累计费用和呼入号码等。该模块是实现人机交互的模块，它的编程可以采用可视化的编程工具来实现。

内部协议处理模块20用于对数据包内的内部协议进行打包、解包，在收到外部的需要确认的协议包即需要确认的信息包时发送确认信息。例如，在本实施例中，在远端呼叫方挂机后，在收到远端呼叫方发送的结束通话信息后，发送一个确认信息表示已经收到远端呼叫方的结束通话信息。

核心功能模块30用于完成呼叫处理、用户数据管理和话单管理等功能。呼叫处理子模块31主要处理和呼叫有关的核心操作，例如，本实施例中，在呼叫呼出时发送呼叫请求的信息，在呼叫呼出和对方建立呼叫连接后打开实时传输通道模块以进行通话。用户数据管理子模块32用于根据用户要求或定时从网络上的软交换设备中下载用户数据，进行管理并在话务员发送查询请求的时候输出。话单管理子模块33用于根据用户要求或定时从网络上的软交换设备下载用户的话单信息，例如话单费用、通话时间等，进行管理并根据话务员需要输出这些信息。需要指出的是，核心功能模块30的功能不止于此，它还可以根据用户的需要增加其他功能，例如自动应答、呼叫转移等等，这里提到的三个功能只是基本的功能。如果要增加其它功能，需要增加相应的功能子模块。

音频处理模块40负责对语音媒体流编解码，对音频包打包和解包。本实施例中，音频处理模块40将从声卡模块50中接收的音频流进行编码和打包，将从实时传输通道模块70中接收的音频包进行解包和解码。熟悉该领域的技术人员可以理解，在该模块中也可以实现对语音通信的加密解密，提高通信的保密性。

声卡模块50负责采集用户语音并转换成音频流并将接收到的音频流还原为语音。这个模块为多媒体PC机上的模块，通常与耳机和话筒相连以进行人机交互，是公知的模块。

网络接口模块60负责IP网络数据包的UDP/IP打包和解包，向IP网络发送并从IP网络接收UDP/IP数据包，根据不同的端口号将控制信息和语音信息分离。该模块包含UDP/IP协议栈，在发送数据时，将待发送的数据包进行UDP/IP封装；在接收数据时，将接收的数据包进行UDP/IP解包。需要说明的是，因为在传输的数据中，语音信息占有绝大多数，因此采用非面向连接的UDP传输以提高速度。熟悉本发明领域的技术人员会理解，也可以使用TCP等其他协议来传输数据，而不会超出本发明的实质和范围。

实时传输通道模块70主要用于接收和发送音频包，对音频包进行传送并负责传送中的拥塞控制。该模块采用RTP/RTCP协议，将从音频处理模块40接收到的音频包进行RTP/RTCP打包并发送给网络接口模块60；将从网络接口模块60接收的数据包进行RTP/RTCP解包。

实际的系统可以简化，省略音频处理模块40、声卡模块50和实时传输通道模块70。该简化系统所接收的信息只能为控制信息和固定的按键信息。该简化系统所发送的语音信息为固定的可选的若干条，可以在PC内预先存储几条固定的语音信息，这些存储的语音信息被预先处理成音频包并进行了RTP/RTCP的打包处理。发送固定的语音信息时，UDP/IP从PC的存储器上读取固定的语音包并打包发送。例如，存储的语音信息可以为″请输入您要拨打的分机号码″，″请输入您要拨打的外线号码″，″请稍等″等信息。系统或者话务员根据呼叫用户输入的信息选择这些语音信号输出。

下面结合图2说明本发明一个实施例的呼叫呼出或者呼入的系统工作的流程：

首先进入步骤100，话务台接收呼叫请求消息。该步骤可以分为以下几个子步骤：网络接口接收UDP/IP封装的呼叫请求消息并进行UDP/IP解包；内部协议处理模块对UDP/IP解包后的数据包进行内部协议解包；核心功能模块根据接收到的消息发现是呼叫请求消息。

接着进入步骤110，话务台与呼入方互发握手消息。该步骤是为了保障通话的可靠性，在通话之前测试通话的线路是否可靠。

接着进入步骤120，判断握手是否成功，如果是进入步骤130，否则结束。该步骤中，如果握手成功说明通话双方都已经准备好通话并且通话的线路可靠，否则说明线路丢包严重，无法正常通话。

在步骤130中，IP话务台向用户显示交互的信息。接着进入步骤140。此步骤也可以分为两个子步骤：核心功能模块处理呼入方的信息；用户交互模块显示用户交互信息。在本实施例中，IP话务台通过用户交互模块在界面上显示呼入号码、IP地址以及请求用户应答或拒绝的消息等。

在步骤140中，判断本地用户是否同意通话，如果是进入步骤150，否则进入步骤160。该步骤也可以分为以下两个子步骤：用户操作用户交互界面，例如点击代表同意通话的按钮或点击拒绝通话的按钮；核心功能模块处理用户操作信息，判断用户是否同意通话。

在步骤150中，本地IP话务台发送同意通信消息。接着进入步骤170。如果核心功能模块判断用户同意通话，则通过内部协议处理模块和网络接口模块向对端发送同意通信消息。该步骤需要确认机制，也即要求呼入方在接到该消息后回复一条确认信息，如果本地IP话务台在一定时间内没有收到确认信息则重发同意通信消息，即本地IP话务台保证呼入方收到同意通信消息。

在步骤160中，本地IP话务台发送拒绝通话消息。如果核心功能模块判断用户不同意通话，则通过内部协议处理模块和网络接口模块向对端发送拒绝通话消息。该步骤需要确认机制，也即要求呼入方在接到该消息后回复一条确认信息，如果本地IP话务台在一定时间内没有收到确认信息则重发拒绝通话消息，即本地IP话务台保证呼入方收到拒绝消息。本步骤执行完成后本次呼入呼叫流程结束。

在步骤170中，本地话务台打开实时传输通道和音频处理模块。该步骤通过核心功能模块向实时传输通道模块发送通道管理信息，向音频处理模块发送打开音频处理模块信息实现。

接着进入步骤180，用户进行通话。该步骤可以由以下两个子步骤组成：发送本地的语音信息；还原远端通话方的语音信息。其中发送本地的语音信息还可进一步分为以下子步骤：采集用户输入的语音并转换为音频流；对音频流进行编码和打包形成音频包；对音频包进行RTP/RTCP打包；网络接口对RTP/RTCP包进行UDP/IP封装并发送。其中还原远端通话方的语音信息可以进一步分为以下子步骤：网络接口接收UDP/IP封装的数据包并解包；对数据包进行RTP/RTCP解包；对音频包解包和解码还原为音频流；将音频流还原为语音信号。可以看出，步骤180的两个子步骤在流程上相反。

接着进入步骤190，判断是否本地用户结束通话。如果是进入步骤210，否则进入步骤200。该步骤并非由IP话务台实现，此处为了流程图逻辑上的清晰而添加。

在步骤200中，接收对方结束通话消息。接着进入步骤220。当通话由对方挂机结束，对方在挂机后发出结束通话消息由本地IP话务台接收到后进入该步骤。

在步骤210中，本地IP话务台发送结束通话消息。接着进入步骤220。当通话由本地用户挂机结束后进入步骤210。该步骤可以分为以下两个子步骤：用户界面发出结束通话命令；核心功能模块响应该命令并发出结束通话消息。该步骤也需要确认机制，即等待一段时间若无确认信息则重发以确保对方收到结束通话消息。

在步骤220中，关闭本地IP话务台的实时传输通道和音频处理模块。该步骤通过核心功能模块发出通道控制信号关闭实时传输通道实现。

至此，本次呼入呼叫结束。

当有呼叫呼出时，IP话务台的工作流程和呼叫呼入的工作流程相似，区别如下：

在步骤100中呼叫请求消息不是接收而是发送。该步骤以分为以下几个子步骤：用户通过用户交互模块发出呼叫请求；核心功能模块根据收到的请求发出呼叫请求消息；内部协议处理模块对呼叫请求消息进行内部协议打包；网络接口模块对内部协议打包后的消息包进行UDP/IP打包并发送。

在步骤110互发握手指令时的握手对方由呼入方变为被叫方。

步骤140中判断的不是本地用户是否同意通话而是远端用户是否同意通话。

步骤150和160中不是发送消息而是接收消息，需要说明的是，在步骤150中，在收到消息后需要发送一个确认消息。

需要说明的是，在以上呼入呼出的流程中，每接收一条协议消息，都经过网络接口模块的接收和UDP/IP解包，内部协议处理模块的解包和核心功能模块的处理这几个子步骤；每发送一条协议消息，都经过核心功能模块发送，内部协议处理模块打包，网络接口模块进行UDP/IP打包并发送这几个子步骤。

下面结合图3说明话务员查询用户信息或者话单信息的流程：

首先进入步骤300，判断话务员是否要求查询，如果是进入步骤310，否则进入步骤340。话务员是通过用户交互模块向IP话务台发出查询要求的。

在步骤310中，判断是否要求实时查询，如果是进入步骤320，否则进入步骤330。一般情况下IP话务台会每隔一定的时间自动从软交换设备上下载用户信息和话单信息，如果话务员需要的是最新的信息，则需要强制IP话务台进行实时查询。因为下载最新的信息需要花费一定的时间，如果话务员希望尽快看到结果，可以不要求实时查询，直接查看IP话务台内的历史数据。

在步骤320中，IP话务台从软交换设备上下载要查询的信息。接着进入步骤330。该步骤可以有以下几个子步骤：核心功能模块中的查询子模块发送查询信息的指令；内部协议处理模块将该指令打包；网络接口模块将指令打包为UDP/IP包并发送给软交换设备；网络接口模块接收软交换设备发送的用户信息并进行UDP/IP解包；内部协议处理模块进行解包；核心功能模块中的查询子模块处理接收到的查询信息。

在步骤330中，通过用户交互模块显示查询的信息。这儿查询的信息主要有两种：用户数据信息和话单信息。用户可以对查询到的信息进行进一步的操作或处理，例如打印话单等。

接着进入步骤340，IP话务台定期从软交换设备上下载一次用户数据信息和话单信息。在本发明的一个较佳实施例中，IP话务台每隔一分钟从软交换设备上下载一次用户数据信息和话单信息。接着进入步骤300。

这些步骤周而复始实现用户查询的工作流程。

需要说明的是，上述所有流程，对于每条收到的远端发送的控制信息都返回一条确认消息对其进行确认，如果在一定时间段内，发送命令方没有收到接收方的确认消息则该控制信息需要重发。

虽然通过参照本发明的某些优选实施例，已经对本发明进行了图示和描述，但本领域的普通技术人员应该明白，可以在形式上和细节上对其作各种各样的改变，而不偏离所附权利要求书所限定的本发明的精神和范围。

Claims

1.一种基于网间互联协议的话务台系统，其特征在于，所述系统包含依次连接的用户交互模块、核心功能模块、内部协议处理模块和网络接口模块，其中，

2.根据权利要求1所述的基于网间互联协议的话务台系统，其特征在于，所述系统还包含依次连接的声卡模块、音频处理模块和实时传输通道模块，其中，

3.根据权利要求1所述的基于网间互联协议的话务台系统，其特征在于，所述网络接口模块根据用户数据报协议和外界通信。

4.根据权利要求2所述的基于网间互联协议的话务台系统，其特征在于，所述网络接口模块根据不同的端口号将需要发送给所述实时传输通道模块的语音信息和需要发送给所述内部协议处理模块的控制信息分离。