一种SIP消息处理方法和装置

技术领域

本发明涉及通信领域，尤其涉及一种SIP消息处理方法和装置。

背景技术

在通信技术领域中，部分业务呼叫系统控制面采用会话初始协议(SESSIONInitiation Protocol，SIP)协议栈，通过在全局环境中设置域名系统(Domain NameSystem，DNS)统一解析业务平台接入地址的方式，将呼叫路由到各个不同的应用服务器(Application Server，AS)业务平台。此种结构下，每一个AS业务平台采用统一的接入地址和端口，接收SIP协议呼叫，完成SIP的接入处理。

业务系统由于需要处理大用户量、高并发场景，需要满足一定的业务处理性能要求。通常，单个信令处理设备不能完成对应负荷处理，往往采用设置集群处理方式，在整个业务系统中部署SIP消息处理集群，以将设备区分为SIP接入设备以及SIP处理设备，两者配合工作，共同完成SIP消息的处理工作。SIP接入设备完成SIP接入以及负载分担操作，将SIP消息负载分发到具体SIP处理设备进行处理；SIP处理设备进行实际具体的业务流程处理。

传统技术框架下，SIP接入设备通常采用配置较高的负载均衡设备，完成SIP消息的统一接入。其中，SIP消息的处理能力依赖于SIP接入设备的处理性能，但在部分场景下，SIP接入设备的处理性能有限，这就使得SIP消息处理效率低、平台用户容量受限。

如何避免设备处理性能有限导致的SIP消息处理效率低的问题，是本申请所要解决的技术问题。

发明内容

本申请实施例的目的是提供一种SIP消息处理方法和装置，用以解决设备处理性能有限导致的SIP消息处理效率低的问题。

第一方面，提供了一种SIP消息处理方法，应用于SIP处理集群中的至少一个SIP接入设备，所述SIP接入设备包括多个SIP实体，包括：

接收IMS核心网络下发的第一SIP消息；

通过所述第一SIP消息对应的SIP实体的业务网络侧地址端口将所述第一SIP消息转发至对应的SIP业务处理设备，其中，所述SIP实体的业务网络侧地址端口对应于唯一SIP业务处理设备的内网业务端口；

如果接收到所述SIP业务处理设备发送的第二SIP消息，则通过接收所述第二SIP消息的目标SIP实体的CSCF侧端口向所述IMS核心网络发送所述第二SIP消息，所述第二SIP消息携带所述目标SIP实体的目标业务网络侧地址端口，所述目标业务网络侧地址端口用于指示所述IMS核心网络向所述目标SIP实体发送所述第一SIP消息的关联SIP消息。

第二方面，提供了一种SIP消息处理装置，包括：

接收模块，接收IMS核心网络下发的第一SIP消息；

转发模块，通过所述第一SIP消息对应的SIP实体的业务网络侧地址端口将所述第一SIP消息转发至对应的SIP业务处理设备，其中，所述SIP实体的业务网络侧地址端口对应于唯一SIP业务处理设备的内网业务端口；

发送模块，如果接收到所述SIP业务处理设备发送的第二SIP消息，则通过接收所述第二SIP消息的目标SIP实体的CSCF侧端口向所述IMS核心网络发送所述第二SIP消息，所述第二SIP消息携带所述目标SIP实体的目标业务网络侧地址端口，所述目标业务网络侧地址端口用于指示所述IMS核心网络向所述目标SIP实体发送所述第一SIP消息的关联SIP消息。

第三方面，提供了一种电子设备，该电子设备包括处理器、存储器及存储在该存储器上并可在该处理器上运行的计算机程序，该计算机程序被该处理器执行时实现如第一方面的方法的步骤。

第四方面，提供了一种计算机可读存储介质，该计算机可读存储介质上存储计算机程序，该计算机程序被处理器执行时实现如第一方面的方法的步骤。

在本申请实施例应用于SIP处理集群中的至少一个SIP接入设备，所述SIP接入设备包括多个SIP实体，该方法包括：接收IMS核心网络下发的第一SIP消息；通过所述第一SIP消息对应的SIP实体的业务网络侧地址端口将所述第一SIP消息转发至对应的SIP业务处理设备，其中，所述SIP实体的业务网络侧地址端口对应于唯一SIP业务处理设备的内网业务端口；如果接收到所述SIP业务处理设备发送的第二SIP消息，则通过接收所述第二SIP消息的目标SIP实体的CSCF侧端口向所述IMS核心网络发送所述第二SIP消息，所述第二SIP消息携带所述目标SIP实体的目标业务网络侧地址端口，所述目标业务网络侧地址端口用于指示所述IMS核心网络向所述目标SIP实体发送所述第一SIP消息的关联SIP消息。由于SIP实体的业务网络侧地址端口对应于唯一SIP业务处理设备的内网业务端口，因此无需对IMS核心网下发的SIP消息执行解析即可高效转发至对应的SIP业务处理设备，而且，对于SIP业务处理设备发送的SIP消息，能根据CSCF侧地址端口执行快速转发，降低SIP接入设备解析SIP消息消耗的处理性能。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本发明的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是一种SIP处理集群的结构示意图。

图2是另一种SIP处理集群的结构示意图。

图3a是本发明的一个实施例一种SIP处理集群的结构示意图。

图3b是本发明的一个实施例一种SIP消息处理方法的流程示意图之一。

图4是本发明的一个实施例一种SIP消息处理方法的流程示意图之二。

图5是本发明的一个实施例一种SIP消息处理方法的流程示意图之三。

图6是本发明的一个实施例一种SIP消息处理方法的流程示意图之四。

图7是本发明的一个实施例一种SIP消息处理方法的流程示意图之五。

图8是本发明的一个实施例一种SIP消息处理方法的流程示意图之六。

图9是本发明的一个实施例一种SIP消息处理方法的流程示意图之七。

图10是本发明的一个实施例一种SIP消息处理方法的流程示意图之八。

图11是本发明的一个实施例一种SIP消息处理装置的结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。本申请中附图编号仅用于区分方案中的各个步骤，不用于限定各个步骤的执行顺序，具体执行顺序以说明书中描述为准。

在SIP消息处理集群中，如图1所示，可以由SIP接入设备负责完成与IMS(InternetProtocol Multimedia Subsystem，网际互连协议多媒体子系统)核心网络的全部信令交互。后端的SIP处理设备不配置IMS核心网络地址，与IMS核心网络的消息交互全部通过SIP接入设备完成。在SIP处理设备完成业务处理后，通过SIP接入设备向IMS核心网络发送SIP响应消息。

在图1示出的结构中，整个业务AS采用统一的地址端口进行业务发布，IMS核心网元将业务负载统一发送到AS发布的地址端口进行处理。整个AS中只有SIP接入设备具备IMS核心网络地址，实现与IMS核心网络的互通。SIP处理设备不具备IMS核心网络地址，所有的SIP消息接收以及消息发送工作，全部交由SIP接入设备完成。

SIP信令接入设备负责完成对外的业务地址端口发布，接收IMS核心网发送的业务SIP消息，以及向IMS核心网发送业务响应消息；SIP信令接入设备接收到IMS核心网SIP消息后，需要按照一定的策略，将SIP具体消息分发到后端的SIP信令处理设备，完成具体业务流程。

SIP信令处理设备负责完成具体的业务流程操作，并通过SIP接入设备，向IMS核心网发送响应消息，完成SIP业务流程。

此种方案中，SIP接入设备为了保证把同一呼叫的消息发送到相同的SIP处理设备进行处理，需要进行SESSION(时域)会话保持，后续的所有消息需要依据SESSION会话，查找后端SIP信令处理设备，保证同一呼叫消息的持续性。

在NFV(Network Functions Virtualization，网络功能虚拟化)环境下，由于使用了虚拟化技术，单台设备处理性能下降。SIP接入设备全代理模式中，所有的SIP消息全部通过SIP接入设备进行转发，为了保证同一呼叫必须分发到同一个后端SIP业务处理设备，SIP接入设备采用SESSION保持的方法，记录每一个呼叫SESSION的分发业务设备，后续收到消息的时候，需要匹配CALL-ID(Identity Document)，查找SESSION表。在大用户量场景下，受限于设备性能，SESSION表往往成为业务发展的瓶颈。即使进行hash分表的策略，接入设备也需要进行大数据量查找，才能正确匹配CALL-ID以及SIP业务处理设备的对应关系，不利于进行业务的快速扩展。NFV环境中设备都为统一分配的资源池虚拟设备，处理性能相对比传统架构下专用设备有较大的下降，导致了单平台的用户规模受限。

另外，在上述SIP消息处理集群中，还可以应用图2所示的结构，SIP接入设备负责完成IMS核心网络的SIP消息接收操作，业务AS发布服务地址端口为SIP接入设备的地址端口信息。IMS核心网络的SIP消息到达SIP接入模块后，接入模块将消息分发到后端SIP处理设备进行处理；同时SIP处理设备也具备IMS核心网络地址，通过在响应或者发送消息中添加VIA以及Record-Route信息的方式，直接将后续的SIP消息导向后端SIP处理设备，不再经过SIP接入设备，实现高并发下的SIP处理集群。

在这种方案中，整个业务AS采用统一的地址端口进行业务发布，IMS核心网元将业务负载统一发送到AS发布的地址端口进行处理。AS中将业务地址信息配置在SIP接入设备上面，IMS核心网络通过路由配置规则，将业务导向AS中的SIP接入设备。

SIP接入设备收到IMS核心网络的SIP消息后，通过预配置策略，将消息导向后端SIP业务处理设备，由SIP业务处理设备进行具体业务流程操作后，直接向核心网络进行响应。

SIP业务处理设备上面也同时配置IMS核心网络地址，此时，SIP业务处理设备也具备与IMS核心网络之间的交互能力，可以不用通过SIP接入设备，通过在VIA(VirtualInterface Architecture，虚拟接口结构)以及Record-Route(记录路由)中添加节点的方式，直接将同一呼叫后续的IMS核心网络消息导向本业务处理设备，直接处理，减轻SIP接入设备的性能压力。

此种方案中，SIP接入设备为了保证把同一呼叫的消息发送到相同的SIP处理设备进行处理，也需要进行SESSION会话保持，后续的所有消息需要依据SESSION会话，查找后端SIP信令处理设备，保证同一呼叫消息的持续性。

由于这种方案大幅减少了通过SIP接入设备处理的SIP消息数量，对接入设备的性能提升有较大的提高。但是，此种技术方案中，后端SIP业务处理设备也需要占用IMS核心网络地址资源，造成了资源的浪费以及故障排查的难度增加。在NFV环境部署下，标准部署为单个AS业务配置统一接入地址端口信息，单个AS占用大量核心网侧网络资源，往往是不可接受的。

以上两种方案中，考虑到一般SIP接入设备为了防止单点故障，需要进行双机配置。在双机切换的时候，为了防止呼叫中断，需要在双机之间进行SESSION的实时同步操作，这也会耗费大量的接入设备处理能力。在双机切换的时候，为了防止呼叫中断，需要在双机之间进行SESSION的实时同步操作，这也会耗费大量的接入设备处理能力。

由于SESSION会话保持的存在，SIP接入设备需要对所有接收发送的SIP消息进行消息解码，获取消息CALL-ID，进行SIP业务处理设备选取工作。针对每一个消息进行解码，也会耗费接入设备处理能力。

为了解决现有技术中存在的问题，本申请实施例提供一种SIP消息处理方法，应用于SIP处理集群中的至少一个SIP接入设备，所述SIP接入设备包括多个SIP实体。图3a示出了包含本申请实施例所述的SIP接入设备的SIP处理集群的结构示意图，图3b示出了本申请实施例提供的方法流程示意图，本申请实施例提供的方案包括以下步骤：

S11：接收IMS核心网络下发的第一SIP消息。

在本步骤中，由SIP处理集群中的SIP接入设备接收上述第一SIP消息。该第一SIP消息可以是IMS核心网络下发的消息。

S12：通过所述第一SIP消息对应的SIP实体的业务网络侧地址端口将所述第一SIP消息转发至对应的SIP业务处理设备，其中，所述SIP实体的业务网络侧地址端口对应于唯一SIP业务处理设备的内网业务端口。

上述第一SIP消息具体可以由SIP接入设备中的某个SIP实体接收，SIP接入设备中与SIP消息对应的SIP实体预先配置有唯一相对应的SIP业务处理设备。在本步骤中，无需根据标识执行查询即可确定转发消息的目标SIP业务处理设备，也不需要对消息执行详细解析，有效优化处理流程，降低处理负荷。

S13：如果接收到所述SIP业务处理设备发送的第二SIP消息，则通过接收所述第二SIP消息的目标SIP实体的CSCF侧端口向所述IMS核心网络发送所述第二SIP消息，所述第二SIP消息携带所述目标SIP实体的目标业务网络侧地址端口，所述目标业务网络侧地址端口用于指示所述IMS核心网络向所述目标SIP实体发送所述第一SIP消息的关联SIP消息。

该第二SIP消息具体可以是IP包，是由SIP业务处理设备发送至对应的SIP实体的消息。本步骤中，由SIP接入设备的SIP实体接收内网业务处理设备发送的SIP消息(IP包)，从IP包中提取SIP原始信息，但无需执行SIP消息解析。

本步骤中，通过接收所述第二SIP消息的目标SIP实体的CSCF侧端口向所述IMS核心网络发送所述第二SIP消息，由于第二SIP消息携带有目标SIP实体的目标业务网络侧地址端口，能便于核心网络下次发送同一SIP业务消息时直接发送到相对应的SIP实体，避免多次对SIP业务消息执行转发。

具体的，上述第二SIP消息由SIP业务处理设备生成，作为request消息向IMS核心网络侧发送。上述SIP业务处理设备可以在VIA信息中添加SIP接入设备VRRP地址和SIP实体核心网络侧端口信息，这样对端设备回复response时，可以直接回复消息到SIP接入设备的指定SIP实体。SIP接入模块此时不再需要解析SIP消息，直接可以按照实体中端口映射规则将消息转发到本业务处理设备，能进一步降低消息处理性能，提高处理效率。

可选的，在SIP接入设备接收到SIP业务处理设备的发送消息操作请求后，由SIP接入设备根据接收端口信息，反向查询业务实体配置信息，获取业务实体标识。然后，从接收的IP包中提取SIP原始消息，以及SIP业务处理设备封装的IMS核心网络侧目的地址端口信息，准备进行消息的发送操作。随后，由SIP接入设备调用业务实体，从该业务实体标识的IMS侧网络端口发出原始SIP消息到目标IMS侧地址端口，完成本次消息发送操作。

本方案执行主体为SIP接入设备，这个接入设备具体可以包括“SIP默认实体”和至少一个“SIP实体N”，其中N为正整数。其中，由于SIP实体对应于唯一处理设备，这就使得SIP实体接收到SIP消息之后不需要执行解析或数据查找，直接根据预配置的唯一端口转发SIP消息，对于业务处理设备反馈的SIP消息也能根据CSCF侧地址端口高效转发，转发消息过程中无需进行会话保持，降低解析和会话保持所需耗费的处理性能。

在本申请实施例中，以处理NFV环境下的彩铃呼叫业务消息为例进行说明，应理解的是，本方案也可以应用于其他业务消息的处理场景中。

本申请实施例中的彩铃呼叫AS可以采用B2BUA(Back-to-Back User Agent，背靠背用户代理)方式，进行呼叫串接处理。

本申请实施例提供的方案应用于SIP处理集群，其中包括SIP接入设备以及SIP业务处理设备。SIP接入设备负责完成与IMS核心网交互，SIP业务处理设备负责完成具体彩铃业务流程处理。本申请实施例方案的执行主体为上述SIP处理集群中的SIP接入设备。

可选的，上述SIP处理集群中可以设置有多个SIP接入设备。比如，参见图3a，在集群中设置一对SIP接入设备，每台设备包括但不限于核心网络侧网络资源、内网业务网络资源、网管网络资源。两台设备针对IMS核心网络侧网络资源采用VRRP(Virtual RouterRedundancy Protocol，虚拟路由冗余协议)方式虚拟出一个业务IP，面向IMS网络侧发布业务地址以及默认业务端口(cscf：5060)。核心网络侧通过iFC功能标签判断后，依据预配置路由，将呼叫路由到虚拟业务IP地址以及业务默认端口(cscf：5060)。

两台SIP接入设备定时判断状态，虚拟IP附着的接入设备为MASTER设备，负责完成SIP消息的接收、发送、分发操作；虚拟IP没有附着的接入设备为BACKUP设备，实现热备份。当MASTER设备判断业务进程故障或者设备故障时，启动VRRP切换，将业务地址切换到BACKUP设备，将BACKUP设备切换到MASTER设备运行。

在实际应用中，维护保障两台接入设备进行完全一样的SIP业务处理设备配置，这样可以保障在主备设备上面实现完全一样的SIP处理实体。当发生接入设备主备切换的时候，由于采用自定义匹配算法完全一致、SIP实体配置完全一致，因此从设备提升为MASTER后，可以直接无缝接管SIP消息的接收和发送操作。

另外，由于SIP接入设备不需要进行session会话保持，两台SIP接入设备也不需要进行session会话同步。同一呼叫主叫侧消息，如果在默认实体上接收消息，由于CALL-ID不变、自定义匹配算法不变、SIP实体不变，因此可以保障将消息分发到相同的SIP业务处理设备；如果在其他SIP实体上面接收消息，那么由于SIP实体的端口映射固定保持，也可以保障将消息分发到相同的SIP业务处理设备。同一呼叫被叫侧消息，由于采用了确定SIP实体进行发送，查询SIP实体端口号映射规则以及SIP业务处理设备标识，直接可以将消息分发到相同的SIP业务处理设备。

在本申请实施例中，SIP接入设备预先配置后端SIP业务处理设备连接。具体可以包括针对每一台SIP业务处理设备，在接入设备主进程中启动一个对应的SIP实体。如图3a中所示的SIP实体1、SIP实体2……SIP实体N。其中，每个SIP实体均包含唯一不重复的IMS核心网络侧端口号，唯一不重复的内网业务网络侧端口号以及SIP业务处理设备标识。

其中，SIP接入设备可以采用全代理方式，能有效节约IMS核心网络资源。后端的SIP业务处理设备为内网设备，可以依据业务进行动态的扩缩容。

本申请实施例提供的方案，针对SIP接入设备摈弃session会话保持，实现快速、低延迟完成高并发场景下的SIP消息分发功能。进一步的，由于摈弃session会话保持，双机部署时无需进行session同步操作，可以做到快速无损切换，能有效提高主要SIP接入设备故障时的业务处理稳定性。

在SIP接入设备针对IMS核心网元与内部SIP业务处理设备，开启多SIP实体并进行端口映射，实现按照收发端口进行快速的设备对应。本方案中，在SIP接入处理设备上采用多端口的方式与IMS核心网络实现交互，规避单端口收发速率限制，极大提高了单台设备处理性能。

另外，SIP接入设备还可以对SIP实体标识的SIP业务处理设备进行主动性active/deactive操作。当接入设备默认实体接收到呼叫初始消息INVITE时，不再将业务导向标识为deactive的SIP业务处理设备，保证该业务处理设备不再接收增量呼叫，从而随着呼叫延续处理后，指定SIP业务处理设备上统计session数为0，此时可以进行SIP业务处理设备的软件更新或者硬件替换等维护性操作，保障业务的成功率。

基于上述实施例提供的方案，可选的，如图4所示，在上述步骤S11之前，还包括：

S21：预配置用于接收IMS核心网络下发的SIP消息的多个SIP实体，所述多个SIP实体包括SIP默认实体和至少一个SIP非默认实体，其中，所述SIP实体预配置IMS核心网络侧端口资源、内网业务网络侧端口资源、SIP业务处理设备标识中的至少一项。

在本申请实施例提供的方案中，预先配置SIP处理集群中的SIP接入设备，集群中可以包含有多个SIP接入设备。在SIP接入设备中预先配置多个SIP实体，多个SIP实体中包含一个SIP默认实体和至少一个SIP非默认实体。各个SIP非默认实体与一个SIP业务处理设备对应，SIP非默认实体在接收到IMS核心网络下发的SIP消息时，无需执行解析即可向相对应的SIP业务处理设备转发SIP消息，有效提高业务处理效率，避免大量消息解析造成高负荷的情况。

可选的，集群中的SIP接入设备中的各个SIP实体与各个SIP业务处理设备一一对应，减少消息传输过程中执行的解析处理步骤。

下面提供一种本步骤的具体执行方法，应理解的是，在实际应用过程中也可以采用其他方法配置各SIP实体。

首先，在集群中配置多台SIP业务处理设备，保障业务处理设备的业务连接性以及与SIP接入设备的内部网络联通性。

然后，在集群中配置两台(或更多数量)SIP接入处理设备，配置IMS网络侧信息以及业务处理网络信息。随后，配置VRRP双机信息，业务监控信息，保障业务中断或者设备中断时，正常完成双机切换。

接着，在SIP接入设备配置SIP业务处理实体信息，对应每一台SIP业务处理设备，配置一个业务处理实体信息，包括：IMS网络侧业务端口、内部处理设备侧业务端口以及SIP业务处理设备标识。

最后，在SIP接入设备开启业务处理实体，核对端口映射规则，完成集群中SIP业务处理设备的预配置。

基于上述实施例提供的方案，如图5所示，在上述步骤S11之后，还包括：

S31：根据所述第一SIP消息获取SIP实体信息；

S32：根据所述SIP实体信息确定所述第一SIP消息对应的SIP实体，所述SIP实体信息表征接收所述第一SIP消息的实体类型。

在SIP接入设备从IMS核心网络侧接收SIP消息之后，SIP接入设备可以从Socket接收信息中提取查询实体信息。判断本次接收消息的实体信息是否为默认实体。上述实体类型具体包括非默认实体和默认实体。

如果接收消息的实体是非默认实体，则SIP接入设备中的SIP非默认实体(如SIP实体1)接收到IMS核心网络侧SIP消息后，接入设备中的该具体SIP实体不再分解具体SIP消息内容，直接使用该具体SIP实体中的内网业务端口将消息发送到实体中标识的SIP业务处理设备，实现消息的无解析直接转发，有效减少解析步骤。

随后，如果SIP接入设备的SIP非默认实体接收到内网业务处理设备发送的SIP消息时，从IP包中提取SIP原始信息，但不做SIP消息解析、从IP包中提取CSCF侧地址端口，使用实体中的CSCF网络侧端口信息，发送SIP消息到IMS核心网络侧。

基于上述实施例提供的方案，可选的，如图6所示，上述步骤S32，包括：

S41：如果所述实体信息表征接收所述第一SIP消息的SIP实体为SIP非默认实体，则将接收所述第一SIP消息的SIP实体确定为所述第一SIP消息对应的SIP实体。

在本实施例中，如果接收SIP消息的是SIP非默认实体，由于预先为各个SIP非默认实体配置了SIP业务处理设备，因此无需接收到SIP消息的SIP非默认实体再进行消息解析，而是直接将接收到的SIP消息转发至相对应的SIP业务处理设备即可，实现高效转发，提高处理效率。其中，在执行转发之前，还可以对接收到的SIP消息进行封装，随后将封装后的SIP消息转发至相对应的SIP业务处理设备。

基于上述实施例提供的方案，可选的，如图7所示，在上述步骤S41，包括：

S51：确定所述SIP实体信息对应的SIP实体是否可用；

S52：如果所述SIP实体信息对应的SIP实体可用，将接收所述第一SIP消息的SIP实体确定为所述第一SIP消息对应的SIP实体。

本申请实施例中，在执行转发之前首先确定SIP实体是否可用，以提高消息处理有效性，避免转发至不可用的SIP实体。具体的，SIP接入设备可以对SIP实体的状态进行可用性检测。当按照预先确定自定义匹配算法选择到的SIP业务处理设备不可用，或者按照端口映射标识的SIP业务处理设备不可用时，SIP接入设备统一将消息路由到默认业务处理设备，保障AS对IMS核心网络侧消息作出必要反应。另外，如果所述SIP实体信息对应的SIP实体不可用，可以由SIP默认实体进一步确定第一SIP消息对应的SIP实体。

基于上述实施例提供的方案，可选的，如图8所示，上述步骤S32，包括：

S61：如果所述实体信息表征接收所述第一SIP消息的SIP实体为SIP默认实体，则获取所述第一SIP消息中的呼叫标识；

S62：根据预设匹配算法将所述呼叫标识匹配的SIP实体确定为所述第一SIP消息对应的SIP实体。

举例而言，SIP默认实体(如图3a所示，业务端口为5060)接收IMS核心网络SIP消息时，首先分解SIP消息内容，提取其中的CALL-ID，采用自定义匹配算法确定SIP实体编号(比如SIP实体1的编号)，之后用选取的SIP实体业务网络侧地址端口(比如SIP实体1的端口：5101)，向相应的SIP业务处理设备(比如图3a中的SIP业务处理设备-1)发送重新组装IP包。

该IP包具体可以包含原始SIP消息、CSCF侧地址端口信息、SIP接入设备选取SIP实体CSCF侧地址端口信息，供SIP处理设备填写响应消息的VIARecord-Route信息。

上述预设匹配算法可以根据实际需求预先设定，下面基于一种可选的预设匹配算法说明本方案。

在本方案中，基于图3a示出的结构，SIP接入设备对外统一发布VRRP虚拟地址以及固定的默认业务端口(5060)，当IMS核心网络侧从默认端口接收消息时，需要解析接收到的SIP消息，按照自定义匹配算法，将呼叫导向特定的SIP处理设备，并且需要保证，对相同的CALL-ID的呼叫，应该导向相同的SIP处理设备，具体可以按以下步骤执行：

由SIP接入设备中的默认业务端口从IMS核心网络侧接收SIP消息，并提取SIP消息其中的CALL-ID字段，该CALL-ID即为本实施例中所述的第一SIP消息中的呼叫标识。

该CALL-ID为一串随机字符串，SIP接入设备将该字符串中的逐个字符对应ASCII码值相加求和，得到CALL-ID和值SUM。

SIP接入设备提取集群中配置的后端SIP处理设备实体数量NUM。按照SUM％NUM的算法简单取余后，确定初步实体编号。由于在图3a示出的实例中，实体0对应的是集群保底冗余实体功能，因此将最终获取实体号加1后确定为本次呼叫的实体号。

由SIP接入设备提取配置的处理实体信息，提取实体中配置的IMS网络侧端口信息以及业务VRRP地址信息，通过实体中配置的内网端口信息，组装一个内部消息包发送到实体中指定的SIP处理设备。该内部消息报中可以包括：IMS侧VRRP地址，本次采用实体的IMS侧端口；SIP处理设备封装后续消息时，采用IMS侧信息进行消息字段填写。

通过以上步骤，即可基于预设匹配算法确定所述呼叫标识匹配的目标SIP实体，并根据所述目标SIP实体的业务网络侧地址端口将所述第一SIP消息转发至对应的目标SIP业务处理设备。

可选的，基于上述实施例提供的方案，如图9所示，上述步骤S12，包括：

S71：根据所述第一SIP消息生成IP包，所述IP包包括所述第一SIP消息、所述SIP默认实体的CSCF侧地址端口、所述目标SIP实体的CSCF侧地址端口中的至少一项。

S72：以所述第一SIP消息对应的SIP实体的业务网络侧地址端口向对应的SIP业务处理设备发送所述IP包。

SIP接入设备向SIP业务处理设备发送的IP包中，包含但不限于以下内容：原始SIP消息、IMS核心网侧发送数据IP地址和端口信息、集群内部选定的SIP实体中包含的VRRP地址和核心网络侧端口信息；从IP包的原始发送远端端口，可以得到SIP接入模块SIP实体的内网业务网络侧端口信息。

另外，SIP业务处理设备需要向IMS核心网络侧发送response消息时，在SIP消息组装时，在Record-Route信息中添加SIP接入设备VRRP地址和SIP实体核心网络侧端口信息。这样IMS核心网络侧设备后续发送request时，可以提取Record-Route信息，直接将消息发送到SIP接入设备的指定SIP实体，SIP接入模块此时不再需要解析SIP消息，直接可以将消息转发到本SIP业务处理设备。

下面，结合图10举例说明本实施例提供的方案。本申请实施例提供的方案，首先由SIP接入设备从IMS核心网络侧接收SIP消息，SIP接入设备从Socket接收信息中提取查询实体信息。然后，判断本次接收消息的实体信息是否为默认实体。

如果不是默认实体，那么判断业务实体是否可用，如果可用，那么不再进行消息解析，直接将SIP消息封装后，发送到实体标识的SIP业务处理设备。

如果是默认实体，解析SIP原始消息，从中提取CALL-ID以及是否为呼叫起始消息业务标识。并按照如上述任一种实施例所述的自定义匹配算法，获取针对本次呼叫处理的目标业务实体编号。

随后，判断目标业务实体编号是否为可用状态，如果目标业务实体不可用，那么直接将消息转发到默认实体处理设备进行处理。

如果目标业务实体可用，则判断接收到的SIP消息是否为呼叫起始INVITE消息。

如果判断结果为False，标识标识消息为呼叫接续过程中消息，直接将SIP消息封装后发送到对应实体标识的SIP业务处理设备。

如果判断结果为True，则判断目标业务实体状态是否为ACTIVE状态。

如果结果为ACTIVE状态，表明业务实体标识业务处理设备为正常可用状态，直接将SIP消息封装后发送到实体标识的SIP业务处理设备。

如果结果不为ACTIVE，那么表明业务实体标识业务处理设备为非正常可用状态，不再将新建呼叫负荷指向该业务实体，将消息转发到默认实体处理设备进行处理。

在分发消息到默认实体标识业务处理设备的步骤中，具体可以提取默认业务实体内部业务处理侧地址端口信息，将原始SIP消息、IMS核心网络侧地址端口信息、默认实体IMS侧端口信息进行封装后，采用IP方式发送内部处理消息到默认实体标识SIP业务处理设备。

在分发消息到实体标识业务处理设备的步骤中，提取目标业务实体内部业务处理侧地址端口信息，将原始SIP消息、IMS核心网络侧地址端口信息、目标实体IMS侧端口信息进行封装后，采用IP方式发送内部处理消息到默认实体标识SIP业务处理设备。

本申请实施例提供的方案能应用于NFV场景中，用于处理高并发彩铃呼叫SIP消息的处理，本实施例提供的方案摈弃SESSION保持，尽量减少SIP消息解析，提高业务接入处理性能，实现大用户量、高并发场景下的SIP信令协议消息的低延迟处理。

SIP处理集群中包括SIP接入设备以及SIP业务处理设备，SIP接入设备完全代理AS所有SIP消息，提供IMS核心网络侧地址和端口资源信息，完成于IMS核心网络的通信，配置双机运行，避免单点故障；SIP业务处理设备配置多台设备组建集群运行，提供可扩展的业务处理能力，同时SIP业务处理设备不配置IMS核心网络侧网络资源，采用内网私有协议通信的方式，减少对IMS核心网络侧资源需求；

由于在接入设备上摒弃session会话保持，能有效减少SIP消息解析和重新组装，通过面向SIP业务处理设备设置一对一端口映射的方法，实现SIP消息的快速分发，提高接入设备处理能力。

SIP接入设备通过设置多端口的方式，充分利用SIP协议VIARecord-Route路由机制，面向IMS核心网络提供过程中多端口支持，避免将所有业务出口放置到默认业务端口上，减轻默认业务端口的单端口业务负荷，提高单设备接口处理能力。

SIP接入设备在分发SIP消息到SIP业务处理设备的时候，摒弃SIP标准消息，采用私有协议重新组装IP包，携带原始SIP消息、IMS核心网侧发送地址端口信息、SIP接入设备侧业务实体中IMS核心网侧配置的地址端口信息；SIP业务处理设备进行消息发送的时候，组装的SIP消息中需要采集SIP接入设备传入的IMS侧地址端口信息，进行SIP消息中的VIA/Record-Route信息填写和确认，以通知IMS侧对端网络设备后续的消息处理路径；同时提供IMS侧目的网络地址端口信息，以便在SIP接入设备代理发送的时候，不需要重新解析和构建SIP消息，直接进行消息发送，提高SIP接入设备的处理效率。

进一步的，还可以进行SIP业务处理设备的状态管理，通过设置默认实体，为集群提供处理设备冗余，当SIP业务处理节点故障时，由默认实体进行故障业务处理设备的原有呼叫后续消息处理；可以支持active/deactive业务设备，便于对维护过程中进行业务设备的业务无损软件升级和系统维护工作；处于deactive的实体继续处理原有端口映射呼叫的后续消息，但不再分配新建呼叫。

通过自定义匹配算法以及相同配置的端口映射业务处理实体，组合成为双机的两台SIP接入设备间不再进行SESSION会话同步，即时切换，即时处理，更便于SIP接入设备的维护升级。

与现有技术相比，本申请实施例提供的方案具有以下多方面优点：

session会话保持方面：如果SIP接入设备对所有接收的SIP消息进行消息解析，提取CALL-ID字段，进行session会话保持，则需要占用大量处理性能。本方案中能有效降低消息解析数量，大幅减少消息解析所需消耗的处理资源，不需要进行Session会话保持。

业务多端口协商方面：对IMS核心网络侧，采用默认端口加多个业务端口的形式，默认端口实现统一接入，其他业务端口不需要解析消息，两步完成直接进行快速消息转发。由于彩铃呼叫流程中，单一呼叫往往由多达50个的消息交互构成一个完整呼叫，采用业务多端口协商后，后续的40+消息采用协商端口进行直接转发，极大的提高了处理设备性能，满足NFV场景下千万级用户量平台对接入设备的处理性能要求。

接入设备双机实现方面：本方案中由于采用业务实体映射的方式，当需要切换SIP接入设备时，不再需要在SIP接入设备之间进行session会话同步操作，可以实现即时切换。

发送消息处理方面：由于将发送目的信息采用IP包参数的方式，由SIP业务处理设备直接通知，不再需要进行SIP消息包解析，可以直接发送，提升接入设备处理性能。

处理设备确定方面：本方案采用多端口映射的方式，直接根据端口信息进行匹配映射，不需要解析SIP消息，后端业务处理设备也不需要在SIP消息头域中添加额外信息。

为了解决现有技术中存在的问题，本申请实施例还提供一种SIP消息处理装置80，如图11所示，包括：

接收模块81，接收IMS核心网络下发的第一SIP消息；

转发模块82，通过所述第一SIP消息对应的SIP实体的业务网络侧地址端口将所述第一SIP消息转发至对应的SIP业务处理设备，其中，所述SIP实体的业务网络侧地址端口对应于唯一SIP业务处理设备的内网业务端口；

发送模块83，如果接收到所述SIP业务处理设备发送的第二SIP消息，则通过接收所述第二SIP消息的目标SIP实体的CSCF侧端口向所述IMS核心网络发送所述第二SIP消息，所述第二SIP消息携带所述目标SIP实体的目标业务网络侧地址端口，所述目标业务网络侧地址端口用于指示所述IMS核心网络向所述目标SIP实体发送所述第一SIP消息的关联SIP消息。

本申请实施例提供的装置具体可以是SIP处理集群中的至少一个SIP接入设备，所述SIP接入设备包括多个SIP实体。本申请实施例提供的装置，通过接收IMS核心网络下发的第一SIP消息；根据接收所述第一SIP消息的SIP实体的业务网络侧地址端口将所述第一SIP消息转发至对应的SIP业务处理设备，其中，所述SIP实体的业务网络侧地址端口对应于唯一SIP业务处理设备的内网业务端口；如果接收到所述SIP业务处理设备发送的第二SIP消息，则获取所述第二SIP消息中的CSCF侧地址端口；根据所述CSCF侧地址端口向所述IMS核心网络发送所述第二SIP消息。由于SIP实体的业务网络侧地址端口对应于唯一SIP业务处理设备的内网业务端口，因此无需对IMS核心网下发的SIP消息执行解析即可高效转发至对应的SIP业务处理设备，而且，对于SIP业务处理设备发送的SIP消息，能根据CSCF侧地址端口执行快速转发，降低SIP接入设备解析SIP消息消耗的处理性能。

优选的，本发明实施例还提供一种电子设备，包括处理器，存储器，存储在存储器上并可在所述处理器上运行的计算机程序，该计算机程序被处理器执行时实现上述一种SIP消息处理方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

本发明实施例还提供一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，该计算机程序被处理器执行时实现上述一种SIP消息处理方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。其中，所述的计算机可读存储介质，如只读存储器(Read-Only Memory，简称ROM)、随机存取存储器(Random AccessMemory，简称RAM)、磁碟或者光盘等。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本发明各个实施例所述的方法。

上面结合附图对本发明的实施例进行了描述，但是本发明并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本发明的启示下，在不脱离本发明宗旨和权利要求所保护的范围情况下，还可做出很多形式，均属于本发明的保护之内。