CN105530252A - 一种呼叫处理方法及装置 - Google Patents

Abstract

本发明公开了一种呼叫处理方法及装置，应用于IPPBX设备，该方法包括：根据呼叫分类策略确定IP接入用户的呼叫所属的类型，其中，第一类型呼叫包括只需直接转发用户间媒体流的呼叫；当IP接入用户的呼叫属于第一类型呼叫时，通过内核处理所述呼叫的媒体流。本发明公开的呼叫处理方法及装置，用来解决在运用asterisk开源代码的嵌入式设备上，IPPBX设备处理IP接入用户呼叫并发能力不足的问题。

Description

一种呼叫处理方法及装置

技术领域

本发明涉及通信领域，尤其涉及一种呼叫处理方法及装置。

背景技术

专用交换机(PBX，PrivateBranchExchange)简而言之就是集团电话，它被广泛地运用在企业办公机构中，极大地提高了企业的办事效率。但是，传统的PBX存在不少问题，首先是它对新兴的计算机与电话集成(CTI，ComputerTelephonyIntegration)和网络电话(VoIP，VoiceoverInternetProtocol)支持不够，而且传统的PBX采用的是专用技术，缺乏开放性和标准性，并且价格昂贵。近年来，随着因特网(Internet)的流行和网络协议(IP，InternetProtocol)的成功，基于IP协议的IPPBX应运而生，有望解决传统PBX的不足。

IPPBX是一种基于IP的公司电话系统，还有类似IPPBX或者IP-PBX的书写方式。这个系统可以完全将话音通信集成到公司的数据网络中，从而建立能够连接分布在全球各地办公地点和员工的统一话音和数据网络。

IPPBX最显著的特征是：成为一个集成通信系统，通过电信网和互联网，仅需要单一设备即可为用户提供语音、传真、数据和视频等多种通信方式。此外，该系统还可以建立中、小型的呼叫中心，并且造价低廉。通过与网络软硬件的充分结合，能够提高工作效率，并节约通信成本(省时、节费)。

目前基于开源项目asterisk的IPPBX方案应用越来越广泛，asterisk框架的媒体流处理方案如图1所示。通道A在收到呼叫后，把呼叫信息提交到呼叫交换模块，呼叫交换模块向通道B发起呼叫，呼叫建立之后，呼叫交换模块将通道A和通道B以桥接的方式连接起来，媒体流通过呼叫交换模块进行交换。

IPPBX的通道类型可以划分为模拟通道(模拟线直接接入)、数字通道(E1/T1接入)、IP通道(会话初始化协议(SIP，SessionInitiationProtocol)、媒体网关控制协议(MGCP，MediaGatewayControlProtocol)等IP协议接入的用户)，IPPBX用户多是IP接入的(组网灵活，扩展方便)。如果通道是IP通道(如SIP接入用户)，系统通过套接字SOCKET接收媒体流报文，然后把媒体流报文送到呼叫交换模块，进行编解码转换等媒体流处理，最后再通过另外一个通道的SOCKET将报文发送出去。

这种模式能够非常方便地进行媒体流的处理，比如编解码转换、双音多频(DTMF，DualToneMultiFrequency)的转换、二次拨号检测等，呼叫的双方在编码方式、DTMF方式等参数上不受限制。但是多数情况下，在一个呼叫系统中，全网的同类用户参数都是一致的，不需要编解码等参数的转换，也无需进行二次拨号检测；比如公司、楼宇等应用环境，只有前台、人工总机、话务员等特权用户具有需要检测二次拨号的业务，普通用户完全不需要，如此，现有的媒体流处理模式是对中央处理单元(CPU，CentralProcessingUnit)资源的极大浪费，尤其是在嵌入式设备上，CPU资源有限，会造成IPPBX的并发用户数较小。

发明内容

为了解决上述技术问题，本发明提供一种呼叫处理方法及装置，用来解决在运用asterisk开源代码的嵌入式设备上，IPPBX设备处理IP接入用户呼叫并发能力不足的问题。

为了达到上述技术目的，本发明提供一种呼叫处理方法，应用于IPPBX设备，包括：根据呼叫分类策略确定IP接入用户的呼叫所属的类型，其中，第一类型呼叫包括只需直接转发用户间媒体流的呼叫；当IP接入用户的呼叫属于第一类型呼叫时，通过内核处理所述呼叫的媒体流。

进一步地，所述根据呼叫分类策略确定IP接入用户的呼叫所属的类型之后，该方法还包括：当IP接入用户的呼叫属于第二类型呼叫时，通过应用层处理所述呼叫的媒体流，其中，所述第二类型呼叫包括需要实时监测呼叫内容的呼叫以及需要IPPBX设备产生媒体流的呼叫。

进一步地，当IP接入用户的呼叫属于第二类型呼叫时，通过应用层处理所述呼叫的媒体流，包括：当IP接入用户的呼叫属于第二类型呼叫时，通过应用层分别为主被叫侧创建实时传输协议(RTP，Real-timeTransportProtocol)流，并建立主被叫侧之间的连接，从主被叫侧中的一侧通道接收媒体流报文，经编解码转换处理后发送到主被叫侧中的另一侧通道。

进一步地，所述根据呼叫分类策略确定IP接入用户的呼叫所属的类型，包括：在呼叫建立时，和/或，在呼叫过程中媒体流参数改变时，根据主被叫侧的媒体流参数和业务确定所述呼叫所属的类型。

进一步地，所述根据主被叫侧的媒体流参数和业务确定所述呼叫所属的类型，包括：

如果一呼叫的主被叫侧具有需要监测媒体流信息的业务，或者，需要IPPBX设备产生媒体流并检测用户的媒体流信息，或者，主被叫侧的媒体流参数不一致，则确定所述呼叫属于第二类型呼叫；

否则，确定所述呼叫属于第一类型呼叫。

进一步地，当IP接入用户的呼叫属于第一类型呼叫时，通过内核处理所述呼叫的媒体流，包括：当IP接入用户的呼叫属于第一类型呼叫时，根据配置的转发规则通过内核对所述呼叫的媒体流报文进行修改，并通过内核转发修改后的媒体流报文。

进一步地，当IP接入用户的呼叫属于第一类型呼叫时，所述通过内核处理所述呼叫的媒体流之前，该方法还包括：通过应用层生成媒体流的转发规则，并配置所述转发规则至内核。

进一步地，所述转发规则包括：

在主叫侧到被叫侧的方向上，将用户数据报协议(UDP)报文+(源IP：主叫侧远端IP+源端口：主叫侧远端端口+目的IP：主叫侧本地IP+目的端口：主叫侧本地端口号)，修改为：UDP报文+(源IP：被叫侧本地IP+源端口：被叫侧本地端口+目的IP：被叫侧远端IP+目的端口：被叫侧远端端口号)；

在被叫侧到主叫侧的方向上，将UDP报文+(源IP：被叫侧远端IP+源端口：被叫侧远端端口+目的IP：被叫侧本地IP+目的端口：被叫侧本地端口号)，修改为：UDP报文+(源IP：主叫侧本地IP+源端口：主叫侧本地端口+目的IP：主叫侧远端IP+目的端口：主叫侧远端端口号)。

本发明还提供一种呼叫处理装置，应用于IPPBX设备，包括：应用层呼叫交换模块，用于根据呼叫分类策略确定IP接入用户的呼叫所属的类型，其中，第一类型呼叫包括只需直接转发用户间媒体流的呼叫；内核转发模块，用于当IP接入用户的呼叫属于第一类型呼叫时，处理所述呼叫的媒体流。

进一步地，所述应用层呼叫交换模块，用于当IP接入用户的呼叫属于第二类型呼叫时，处理所述呼叫的媒体流，其中，所述第二类型呼叫包括需要实时监测呼叫内容的呼叫以及需要IPPBX设备产生媒体流的呼叫。

进一步地，所述应用层呼叫交换模块，用于当IP接入用户的呼叫属于第二类型呼叫时，处理所述呼叫的媒体流，包括：当IP接入用户的呼叫属于第二类型呼叫时，分别为主被叫侧创建RTP流，并建立主被叫侧之间的连接，从主被叫侧中的一侧通道接收媒体流报文，经编解码转换处理后发送到主被叫侧中的另一侧通道。

进一步地，所述应用层呼叫交换模块，用于根据呼叫分类策略确定IP接入用户的呼叫所属的类型，包括：在呼叫建立时，和/或，在呼叫过程中媒体流参数改变时，根据主被叫侧的媒体流参数和业务确定所述呼叫所属的类型。

进一步地，所述应用层呼叫交换模块，用于根据主被叫侧的媒体流参数和业务确定所述呼叫所属的类型，包括：

如果一呼叫的主被叫侧具有需要监测媒体流信息的业务，或者，需要IPPBX设备产生媒体流并检测用户的媒体流信息，或者，主被叫侧的媒体流参数不一致，则确定所述呼叫属于第二类型呼叫；

否则，确定所述呼叫属于第一类型呼叫。

进一步地，所述内核转发模块，用于当IP接入用户的呼叫属于第一类型呼叫时，处理所述呼叫的媒体流，包括：当IP接入用户的呼叫属于第一类型呼叫时，根据配置的转发规则对所述呼叫的媒体流报文进行修改，并转发修改后的媒体流报文。

进一步地，所述应用层呼叫交换模块，还用于当IP接入用户的呼叫属于第一类型呼叫时，在内核转发模块处理所述呼叫的媒体流之前，生成媒体流的转发规则，并配置所述转发规则至所述内核转发模块。

进一步地，所述转发规则包括：

在主叫侧到被叫侧的方向上，将用户数据报协议(UDP)报文+(源IP：主叫侧远端IP+源端口：主叫侧远端端口+目的IP：主叫侧本地IP+目的端口：主叫侧本地端口号)，修改为：UDP报文+(源IP：被叫侧本地IP+源端口：被叫侧本地端口+目的IP：被叫侧远端IP+目的端口：被叫侧远端端口号)；

在被叫侧到主叫侧的方向上，将UDP报文+(源IP：被叫侧远端IP+源端口：被叫侧远端端口+目的IP：被叫侧本地IP+目的端口：被叫侧本地端口号)，修改为：UDP报文+(源IP：主叫侧本地IP+源端口：主叫侧本地端口+目的IP：主叫侧远端IP+目的端口：主叫侧远端端口号)。

在本发明中，根据呼叫分类策略确定IP接入用户的呼叫所属的类型，其中，第一类型呼叫包括只需直接转发用户间媒体流的呼叫；当IP接入用户的呼叫属于第一类型呼叫时，通过内核处理所述呼叫的媒体流。如此，通过本发明，对一次呼叫进行分类，由内核直接处理第一类型呼叫的媒体流，从而有效提高CPU利用率，达到了提高系统并发能力的目的。

进一步地，在呼叫建立阶段，和/或，在呼叫过程中媒体流参数变化阶段，更改呼叫类型，如此，能够动态调整媒体流的处理方法，最大限度地在不影响系统功能的前提下优化系统性能。

附图说明

图1为现有技术中asterisk框架的媒体流处理示意图；

图2为本发明实施例提供的呼叫处理的示意图；

图3为本发明实施例中IPPBX设备的应用层呼叫交换模块的处理流程图；

图4为本发明实施例中IPPBX设备的内核转发模块的处理流程图；

图5为CPU性能对比图。

具体实施方式

以下结合附图对本发明的实施例进行详细说明，应当理解，以下所说明的实施例仅用于说明和解释本发明，并不用于限定本发明。

本发明实施例提供一种呼叫处理方法，应用于IPPBX设备，包括：根据呼叫分类策略确定IP接入用户的呼叫所属的类型，其中，第一类型呼叫包括只需直接转发用户间媒体流的呼叫；当IP接入用户的呼叫属于第一类型呼叫时，通过内核处理所述呼叫的媒体流。

进一步地，当IP接入用户的呼叫属于第二类型呼叫时，通过应用层处理所述呼叫的媒体流，其中，所述第二类型呼叫包括需要实时监测呼叫内容的呼叫以及需要IPPBX设备产生媒体流的呼叫。

具体而言，对IPPBX设备的IP接入用户的呼叫进行分类，其中，对于第一类型呼叫，IPPBX设备只需要转发用户之间的媒体流，不需要关心媒体流的内容；对于第二类型呼叫，IPPBX设备需要实时监测呼叫的内容，比如监听二次拨号或者媒体流内容，或者，需要IPPBX设备产生媒体流。

如图2所示，第一类型呼叫由内核转发模块来处理媒体流，媒体流不送到用户态处理，第二类型呼叫仍然通过SOCKET送到用户态由应用层呼叫交换模块处理。于实际应用中，IPPBX设备的多数应用场景，如楼宇、医院等，第一类型呼叫占所有呼叫的80％，而由内核处理媒体流，与用户态相比能较好地提高系统的性能，从而达到提高系统并发能力的目的。

进一步地，根据呼叫分类策略确定IP接入用户的呼叫所属的类型，包括：在呼叫建立时，和/或，在呼叫过程中媒体流参数改变时，根据主被叫侧的媒体流参数和业务确定所述呼叫所属的类型。其中，在呼叫过程中媒体流参数改变，指的是：在呼叫过程中，主被叫侧中的任意一侧的媒体流参数发生改变。

其中，根据主被叫侧的媒体流参数和业务确定所述呼叫所属的类型，包括：

如果一呼叫的主被叫侧具有需要监测媒体流信息的业务，或者，需要IPPBX设备产生媒体流并检测用户的媒体流信息，或者，主被叫侧的媒体流参数不一致，则确定所述呼叫属于第二类型呼叫；

否则，确定所述呼叫属于第一类型呼叫。

其中，在判断呼叫是否属于第一类型时，也是根据业务和媒体流参数确定的，即：一呼叫的主被叫侧不具有需要监测媒体流信息的业务；并且，无需要IPPBX设备产生媒体流并检测用户的媒体流信息；并且，主被叫侧的媒体流参数一致。

具体而言，呼叫分类策略如下：第一类型呼叫和第二类型呼叫根据主被叫侧的媒体流参数和业务进行划分；可以在呼叫建立时，和/或，在呼叫过程中媒体流参数改变时，对呼叫进行归类划分。当呼叫的主被叫侧具有需要监测媒体流信息的业务(比如盲转、询问转)时，或者，在特定的需要IPPBX设备产生媒体流和检测用户的媒体流信息的情况(比如中继/用户呼入自动总机)下，或者，当主被叫侧的媒体流参数不一致(如需要IPPBX设备进行编解码转换)时，将呼叫归为第二类型呼叫；其他无需做编解码转换，无特殊业务，只需要直接转发媒体流的呼叫(比如两个同类型用户之间的呼叫)归为第一类型呼叫。其中，当呼叫过程中触发了部分业务，也可能会发生呼叫类型的转变，比如当呼叫为第一类型时，若管理员开启了呼叫监听，或者用户发起了呼叫保持，此时，该呼叫的类型切换为第二类型；而当呼叫监听结束或者呼叫保持恢复，又将该呼叫的类型切换为第一类型。

进一步地，当IP接入用户的呼叫属于第二类型呼叫时，通过应用层处理所述呼叫的媒体流，包括：

当IP接入用户的呼叫属于第二类型呼叫时，通过应用层分别为主被叫侧创建实时传输协议(RTP，Real-timeTransportProtocol)流，并建立主被叫侧之间的连接，从主被叫侧中的一侧通道接收媒体流报文，经编解码转换处理后发送到主被叫侧中的另一侧通道。

进一步地，当IP接入用户的呼叫属于第一类型呼叫时，通过内核处理所述呼叫的媒体流，包括：当IP接入用户的呼叫属于第一类型呼叫时，根据配置的转发规则通过内核对所述呼叫的媒体流报文进行修改，并通过内核转发修改后的媒体流报文。

进一步地，当IP接入用户的呼叫属于第一类型呼叫时，所述通过内核处理所述呼叫的媒体流之前，该方法还包括：通过应用层生成媒体流的转发规则，并配置所述转发规则至内核。

其中，所述转发规则包括：

在主叫侧到被叫侧的方向上，将用户数据报协议(UDP，UserDatagramProtocol)报文+(源IP：主叫侧远端IP+源端口：主叫侧远端端口+目的IP：主叫侧本地IP+目的端口：主叫侧本地端口号)，修改为：UDP报文+(源IP：被叫侧本地IP+源端口：被叫侧本地端口+目的IP：被叫侧远端IP+目的端口：被叫侧远端端口号)；

在被叫侧到主叫侧的方向上，将UDP报文+(源IP：被叫侧远端IP+源端口：被叫侧远端端口+目的IP：被叫侧本地IP+目的端口：被叫侧本地端口号)，修改为：UDP报文+(源IP：主叫侧本地IP+源端口：主叫侧本地端口+目的IP：主叫侧远端IP+目的端口：主叫侧远端端口号)。

此外，本实施例还提供一种呼叫处理装置，应用于IPPBX设备，包括：应用层呼叫交换模块，用于根据呼叫分类策略确定IP接入用户的呼叫所属的类型，其中，第一类型呼叫包括只需直接转发用户间媒体流的呼叫；内核转发模块，用于当IP接入用户的呼叫属于第一类型呼叫时，处理所述呼叫的媒体流。

进一步地，所述应用层呼叫交换模块，还用于当IP接入用户的呼叫属于第二类型呼叫时，处理所述呼叫的媒体流，其中，所述第二类型呼叫包括需要实时监测呼叫内容的呼叫以及需要IPPBX设备产生媒体流的呼叫。

进一步地，所述应用层呼叫交换模块，用于当IP接入用户的呼叫属于第二类型呼叫时，处理所述呼叫的媒体流，包括：当IP接入用户的呼叫属于第二类型呼叫时，分别为主被叫侧创建RTP流，并建立主被叫侧之间的连接，从主被叫侧中的一侧通道接收媒体流报文，经编解码转换处理后发送到主被叫侧中的另一侧通道。

进一步地，所述应用层呼叫交换模块，用于根据呼叫分类策略确定IP接入用户的呼叫所属的类型，包括：

在呼叫建立时，和/或，在呼叫过程中媒体流参数改变时，根据主被叫侧的媒体流参数和业务确定所述呼叫所属的类型。

进一步地，所述应用层呼叫交换模块，用于根据主被叫侧的媒体流参数和业务确定所述呼叫所属的类型，包括：

如果一呼叫的主被叫侧具有需要监测媒体流信息的业务，或者，需要IPPBX设备产生媒体流并检测用户的媒体流信息，或者，主被叫侧的媒体流参数不一致，则确定所述呼叫属于第二类型呼叫；

否则，确定所述呼叫属于第一类型呼叫。

进一步地，所述内核转发模块，用于当IP接入用户的呼叫属于第一类型呼叫时，处理所述呼叫的媒体流，包括：当IP接入用户的呼叫属于第一类型呼叫时，根据配置的转发规则对所述呼叫的媒体流报文进行修改，并转发修改后的媒体流报文。

进一步地，所述应用层呼叫交换模块，还用于当IP接入用户的呼叫属于第一类型呼叫时，在内核转发模块处理所述呼叫的媒体流之前，生成媒体流的转发规则，并配置所述转发规则至所述内核转发模块。

其中，所述转发规则包括：

在主叫侧到被叫侧的方向上，将UDP报文+(源IP：主叫侧远端IP+源端口：主叫侧远端端口+目的IP：主叫侧本地IP+目的端口：主叫侧本地端口号)，修改为：UDP报文+(源IP：被叫侧本地IP+源端口：被叫侧本地端口+目的IP：被叫侧远端IP+目的端口：被叫侧远端端口号)；

在被叫侧到主叫侧的方向上，将UDP报文+(源IP：被叫侧远端IP+源端口：被叫侧远端端口+目的IP：被叫侧本地IP+目的端口：被叫侧本地端口号)，修改为：UDP报文+(源IP：主叫侧本地IP+源端口：主叫侧本地端口+目的IP：主叫侧远端IP+目的端口：主叫侧远端端口号)。

于实际应用中，上述模块例如通过处理器执行存储在存储器中的程序/指令实现。

图3为本发明实施例中IPPBX设备的应用层呼叫交换模块的处理流程图。如图3所示，IPPBX设备的应用层呼叫交换模块的处理步骤如下：

步骤301：呼叫交换模块接收到来自主叫通道的呼叫请求；

步骤302：呼叫交换模块解析呼叫请求的会话描述协议(SDP，SessionDescriptionProtocol)参数，以从中获得主叫通道所对应的远端媒体流参数；

步骤303：呼叫交换模块对远端媒体流参数与本地媒体流配置参数进行协商，获取主叫侧的编解码参数和RTP流参数，RTP流参数包括本地IP地址、本地UDP端口号、远端IP地址、远端UDP端口号；

步骤304：呼叫交换模块向被叫通道发起呼叫请求，被叫通道接收到呼叫请求后向远端被叫用户发送呼叫请求；

步骤305：呼叫交换模块接收到来自被叫通道的被叫用户的应答消息；

步骤306：呼叫交换模块解析应答消息中的SDP参数，以从中获得被叫通道所对应的远端媒体流参数，并将该远端媒体流参数与本地媒体流配置参数进行协商，获得被叫通道的编解码参数和RTP流参数，RTP流参数包括本地IP地址、本地UDP端口号、远端IP地址、远端UDP端口号；

步骤307：呼叫交换模块根据呼叫分类策略对呼叫进行归类；具体而言，根据主被叫侧的编解码参数和用户业务对呼叫进行分类；

步骤308：针对第二类型的呼叫，呼叫交换模块分别为主被叫侧创建RTP流，并且建立主被叫侧之间的连接，呼叫交换模块从主被叫侧中的一侧通道接收到媒体流报文，经过编解码转换处理后，发送到主被叫侧中的另外一侧通道；

针对第一类型的呼叫，呼叫交换模块根据主被叫侧的RTP参数生成转发规则，并将两条转发规则配置到内核转发模块。

于此，在主叫侧到被叫侧的方向上，媒体流的转发规则如下：

UDP报文+(源IP：主叫侧远端IP+源端口：主叫侧远端端口+目的IP：主叫侧本地IP+目的端口：主叫侧本地端口号)，

报文修改为：UDP报文+(源IP：被叫侧本地IP+源端口：被叫侧本地端口+目的IP：被叫侧远端IP+目的端口：被叫侧远端端口号)；

在被叫侧到主叫侧的方向上，媒体流的转发规则如下：

UDP报文+(源IP：被叫侧远端IP+源端口：被叫侧远端端口+目的IP：被叫侧本地IP+目的端口：被叫侧本地端口号)，

报文修改为：UDP报文+(源IP：主叫侧本地IP+源端口：主叫侧本地端口+目的IP：主叫侧远端IP+目的端口：主叫侧远端端口号)。

图4为本发明实施例中IPPBX设备的内核转发模块的处理流程图。如图4所示，IPPBX设备的内核转发模块的处理步骤如下：

步骤401：接收并处理到本地的UDP报文，生成SKB(Structsk_buff)结构，其中，SKB结构是linux系统内核传输控制协议(TCP，TransmissionControlProtocol)/IP堆栈(stack)中用于管理数据缓冲器(DataBuffer)的结构，是网络数据报在内核中的表现形式；

步骤402：从SKB结构中获取会话信息，并利用会话的当前方向信息去匹配第一类型呼叫的转发规则；具体而言，第一类型呼叫的转发规则包括在主叫侧到被叫侧方向上媒体流的转发规则以及在被叫侧到主叫侧方向上媒体流的转发规则，根据会话的当前方向信息确定当前会话的方向为主叫侧到被叫侧方向或者被叫侧到主叫侧方向，根据确定的会话方向，匹配对应的方向上的媒体流转发规则；

步骤403：如果当前方向信息能够匹配到相应的转发规则，根据转发规则修改UDP报文的源地址、目的地址、源端口号和目的端口号，并基于修改结果重新计算和修改UDP报文的校验和；

步骤404：修改后的UDP报文重新进行查找路由，并修改UDP报文的路由项；

步骤405：通过本地发包，将UDP报文发送出去。

图5为CPU性能对比图。如图5所示，以主频1.5G的ARMCPU、16路IP用户并发呼叫为例，每5秒进行一次CPU占用率采样，从图5可见优化前(即采用图1所示处理方式)，CPU的占用率在25％～30％(即，图5中位于上面的曲线)，而优化后(即采用图2所示处理方式)，CPU的占用率可降至5％～15％(即，图5中位于下面的曲线)。可见，通过本发明实施例有效提高了CPU的利用率。

综上所述，本发明实施例提出了一种在采用asterisk开源代码库的IPPBX设备中由内核来处理和转发媒体流代替应用层转发媒体流的优化方法。在原有的系统中，所有IP接入用户的媒体流处理都要内核通过socket将RTP报文送到用户态，应用层收包处理后封装RTP，再通过socket发送到内核，由内核进行路由和发送。然而，在电话网中，大量用户是同类型、同参数的，这些用户之间的通话产生的媒体流在应用层只是简单转发，而上述流程中socket收发报文需要消耗大量的CPU资源。在本发明实施例针对上述呼叫的媒体流由内核直接转发，有效地提高了CPU的利用率，达到了提高系统并发能力的目的。

以上显示和描述了本发明的基本原理和主要特征和本发明的优点。本发明不受上述实施例的限制，上述实施例和说明书中描述的只是说明本发明的原理，在不脱离本发明精神和范围的前提下，本发明还会有各种变化和改进，这些变化和改进都落入要求保护的本发明范围内。

Claims (16)

1.一种呼叫处理方法，应用于网络协议专用交换机IPPBX设备，其特征在于，包括：

根据呼叫分类策略确定网络协议IP接入用户的呼叫所属的类型，其中，第一类型呼叫包括只需直接转发用户间媒体流的呼叫；

当IP接入用户的呼叫属于第一类型呼叫时，通过内核处理所述呼叫的媒体流。

2.如权利要求1所述的方法，其特征在于，所述根据呼叫分类策略确定IP接入用户的呼叫所属的类型之后，还包括：当IP接入用户的呼叫属于第二类型呼叫时，通过应用层处理所述呼叫的媒体流，其中，所述第二类型呼叫包括需要实时监测呼叫内容的呼叫以及需要IPPBX设备产生媒体流的呼叫。

3.如权利要求2所述的方法，其特征在于，当IP接入用户的呼叫属于第二类型呼叫时，通过应用层处理所述呼叫的媒体流，包括：当IP接入用户的呼叫属于第二类型呼叫时，通过应用层分别为主被叫侧创建实时传输协议RTP流，并建立主被叫侧之间的连接，从主被叫侧中的一侧通道接收媒体流报文，经编解码转换处理后发送到主被叫侧中的另一侧通道。

4.如权利要求1-3中任一项所述的方法，其特征在于，所述根据呼叫分类策略确定IP接入用户的呼叫所属的类型，包括：在呼叫建立时，和/或，在呼叫过程中媒体流参数改变时，根据主被叫侧的媒体流参数和业务确定所述呼叫所属的类型。

5.如权利要求4所述的方法，其特征在于，所述根据主被叫侧的媒体流参数和业务确定所述呼叫所属的类型，包括：

如果一呼叫的主被叫侧具有需要监测媒体流信息的业务，或者，需要IPPBX设备产生媒体流并检测用户的媒体流信息，或者，主被叫侧的媒体流参数不一致，则确定所述呼叫属于第二类型呼叫；

否则，确定所述呼叫属于第一类型呼叫。

6.如权利要求1所述的方法，其特征在于，当IP接入用户的呼叫属于第一类型呼叫时，通过内核处理所述呼叫的媒体流，包括：当IP接入用户的呼叫属于第一类型呼叫时，根据配置的转发规则通过内核对所述呼叫的媒体流报文进行修改，并通过内核转发修改后的媒体流报文。

7.如权利要求6所述的方法，其特征在于，当IP接入用户的呼叫属于第一类型呼叫时，所述通过内核处理所述呼叫的媒体流之前，还包括：通过应用层生成媒体流的转发规则，并配置所述转发规则至内核。

8.如权利要求6或7所述的方法，其特征在于，所述转发规则包括：

在主叫侧到被叫侧的方向上，将用户数据报协议UDP报文+(源IP：主叫侧远端IP+源端口：主叫侧远端端口+目的IP：主叫侧本地IP+目的端口：主叫侧本地端口号)，修改为：UDP报文+(源IP：被叫侧本地IP+源端口：被叫侧本地端口+目的IP：被叫侧远端IP+目的端口：被叫侧远端端口号)；

在被叫侧到主叫侧的方向上，将UDP报文+(源IP：被叫侧远端IP+源端口：被叫侧远端端口+目的IP：被叫侧本地IP+目的端口：被叫侧本地端口号)，修改为：UDP报文+(源IP：主叫侧本地IP+源端口：主叫侧本地端口+目的IP：主叫侧远端IP+目的端口：主叫侧远端端口号)。

9.一种呼叫处理装置，应用于IPPBX设备，其特征在于，包括：

应用层呼叫交换模块，用于根据呼叫分类策略确定IP接入用户的呼叫所属的类型，其中，第一类型呼叫包括只需直接转发用户间媒体流的呼叫；

内核转发模块，用于当IP接入用户的呼叫属于第一类型呼叫时，处理所述呼叫的媒体流。

10.如权利要求9所述的装置，其特征在于，所述应用层呼叫交换模块，还用于当IP接入用户的呼叫属于第二类型呼叫时，处理所述呼叫的媒体流，其中，所述第二类型呼叫包括需要实时监测呼叫内容的呼叫以及需要IPPBX设备产生媒体流的呼叫。

11.如权利要求10所述的装置，其特征在于，所述应用层呼叫交换模块，用于当IP接入用户的呼叫属于第二类型呼叫时，处理所述呼叫的媒体流，包括：当IP接入用户的呼叫属于第二类型呼叫时，分别为主被叫侧创建实时传输协议RTP流，并建立主被叫侧之间的连接，从主被叫侧中的一侧通道接收媒体流报文，经编解码转换处理后发送到主被叫侧中的另一侧通道。

12.如权利要求9至11中任一项所述的装置，其特征在于，所述应用层呼叫交换模块，用于根据呼叫分类策略确定IP接入用户的呼叫所属的类型，包括：在呼叫建立时，和/或，在呼叫过程中媒体流参数改变时，根据主被叫侧的媒体流参数和业务确定所述呼叫所属的类型。

13.如权利要求12所述的装置，其特征在于，所述应用层呼叫交换模块，用于根据主被叫侧的媒体流参数和业务确定所述呼叫所属的类型，包括：

如果一呼叫的主被叫侧具有需要监测媒体流信息的业务，或者，需要IPPBX设备产生媒体流并检测用户的媒体流信息，或者，主被叫侧的媒体流参数不一致，则确定所述呼叫属于第二类型呼叫；

否则，确定所述呼叫属于第一类型呼叫。

14.如权利要求9所述的装置，其特征在于，所述内核转发模块，用于当IP接入用户的呼叫属于第一类型呼叫时，处理所述呼叫的媒体流，包括：

当IP接入用户的呼叫属于第一类型呼叫时，根据配置的转发规则对所述呼叫的媒体流报文进行修改，并转发修改后的媒体流报文。

15.如权利要求14所述的装置，其特征在于，所述应用层呼叫交换模块，还用于当IP接入用户的呼叫属于第一类型呼叫时，在内核转发模块处理所述呼叫的媒体流之前，生成媒体流的转发规则，并配置所述转发规则至所述内核转发模块。

16.如权利要求14或15所述的装置，其特征在于，所述转发规则包括：

在主叫侧到被叫侧的方向上，将用户数据报协议UDP报文+(源IP：主叫侧远端IP+源端口：主叫侧远端端口+目的IP：主叫侧本地IP+目的端口：主叫侧本地端口号)，修改为：UDP报文+(源IP：被叫侧本地IP+源端口：被叫侧本地端口+目的IP：被叫侧远端IP+目的端口：被叫侧远端端口号)；

在被叫侧到主叫侧的方向上，将UDP报文+(源IP：被叫侧远端IP+源端口：被叫侧远端端口+目的IP：被叫侧本地IP+目的端口：被叫侧本地端口号)，修改为：UDP报文+(源IP：主叫侧本地IP+源端口：主叫侧本地端口+目的IP：主叫侧远端IP+目的端口：主叫侧远端端口号)。