业务请求、协商、响应方法、装置及网络设备、系统与流程

本发明涉及通信领域，尤其涉及一种业务请求、协商、响应方法、装置及网络设备、系统。

背景技术：

rcs(richcommunicationsuite，富媒体通信)中多媒体业务数据的传输主要使用msrp(messagesessionrelayprotocol)协议。msrp协议栈通过点对点的方式，基于tcp(transmissioncontrolprotocol，传输控制协议)传输消息或文件，这种传输方式具有数据传输快、传输占用带宽少的特点。msrp适用于实时性要求高的业务，如即时消息(instantmessaging，im)、文件传输、图片共享、游戏、业务操作控制等。不过相关方案中，在使用msrp进行数据传输时，所有的msrp媒体业务数据均需要经过sbc(sessionbordercontroller，会话边界控制器)进行中转，然后由sbc将业务数据发送给接收端。经过sbc主要是为了实现媒体地址nat(networkaddresstranslation，网络地址转换)穿越、媒体地址合法性验证等。

随着5g网络的发展，终端和as(applicationserver，应用服务器)之间传递的数据量不断增加，数据传输时延要求越来越小，由sbc进行中转的模式不能适应业务发展的要求，需要对现有的方案进行改进。

技术实现要素：

本发明实施例提供的业务请求、协商、响应方法、装置及网络设备、系统，主要解决的技术问题是：解决相关技术中as与终端间的媒体业务数据需要经sbc进行中转，导致数据传输时延大，用户侧体验不佳的问题。

为解决上述技术问题，本发明实施例提供一种业务协商方法，包括：

根据业务请求端的请求向业务响应端发送携带业务请求端第一公网通信地址的业务请求；

根据业务响应端的响应向业务请求端发送响应消息，响应消息中携带业务响应端的第二公网通信地址，第一公网通信地址和第二公网通信地址用于业务响应端与业务请求端建立公网通信链路。

本发明实施例还提供一种业务请求方法，包括：

将用于业务请求的请求消息发送给会话边界控制器sbc，请求消息用于sbc向业务响应端发送携带本端第一公网通信地址的业务请求；

接收业务响应端在接收到业务请求后通过sbc发送的响应消息，响应消息中携带有业务响应端的第二公网通信地址；

根据第二公网通信地址同业务响应端建立公网通信链路进行业务数据传输实现业务。

本发明实施例还提供一种业务响应方法，包括：

接收sbc发送的业务请求，业务请求中包含业务请求端的第一公网通信地址；

将与业务请求对应的业务响应发送给sbc，业务响应用于sbc向业务请求端发送携带本端第二公网通信地址的响应消息；

根据第一公网通信地址同业务请求端建立公网通信链路进行业务数据传输实现业务。

本发明实施例还提供一种业务协商装置，包括：

请求转发模块，用于根据业务请求端的请求向业务响应端发送携带业务请求端第一公网通信地址的业务请求；

响应转发模块，用于根据业务响应端的响应向业务请求端发送响应消息，响应消息中携带业务响应端的第二公网通信地址，第一公网通信地址和第二公网通信地址用于业务响应端与业务请求端建立公网通信链路。

本发明实施例还提供一种业务请求装置，包括：

请求发送模块，用于将用于业务请求的请求消息发送给会话边界控制器sbc，请求消息用于sbc向业务响应端发送携带本端第一公网通信地址的业务请求；

响应接收模块，用于接收业务响应端在接收到业务请求后通过sbc发送的响应消息，响应消息中携带有业务响应端的第二公网通信地址；

第一建链模块，用于根据第二公网通信地址同业务响应端建立公网通信链路进行业务数据传输实现业务。

本发明实施例还提供一种业务响应装置，包括：

请求接收模块，用于接收sbc发送的业务请求，业务请求中包含业务请求端的第一公网通信地址；

响应发送模块，用于将与业务请求对应的业务响应发送给sbc，业务响应用于sbc向业务请求端发送携带本端第二公网通信地址的响应消息；

第二建链模块，用于根据第一公网通信地址同业务请求端建立公网通信链路进行业务数据传输实现业务。

本发明实施例还提供一种网络设备，包括处理器、存储器及通信总线；

通信总线用于实现处理器和存储器之间的连接通信；

处理器用于执行存储器中存储的业务协商程序以实现如上的业务协商方法的步骤；或处理器用于执行存储器中存储的业务请求程序以实现如上的业务请求方法的步骤；或处理器用于执行存储器中存储的业务响应程序以实现如上的业务响应方法的步骤。

本发明实施例还提供一种网络系统，包括终端、sbc以及as，终端、sbc以及as三者两两通信连接；

终端为上述处理器可执行业务请求程序以实现如上业务请求方法步骤的网络设备，sbc为如上处理器可执行业务协商程序以实现如上的业务协商方法步骤的网络设备；as为如上处理器可执行业务响应程序以实现如上的业务响应方法的步骤的网络设备；

或，

终端为如上处理器可执行业务响应程序以实现如上业务响应方法的步骤的网络设备，sbc为如上处理器可执行业务协商程序以实现如上业务协商方法步骤的网络设备；as为如上处理器可执行业务请求程序以实现如上业务请求方法步骤的网络设备。

本发明实施例还提供一种存储介质，存储介质中存储有业务协商程序、业务请求程序以及业务响应程序中的至少一个，业务协商程序可被一个或者多个处理器执行，以实现如上业务协商方法的步骤；业务请求程序可被一个或者多个处理器执行，以实现如上业务请求方法的步骤；业务响应程序可被一个或者多个处理器执行，以实现如上业务响应方法的步骤。

本发明的有益效果是：

根据本发明实施例提供的业务请求、协商、响应方法、装置、网络设备、系统及存储介质，在业务会话协商阶段，sbc设备可以根据业务请求端的请求向业务响应端发送携带业务请求端第一公网通信地址的业务请求，并且根据业务响应端的响应向业务请求端发送携带业务响应端的第二公网通信地址的响应消息，从而让业务请求端和业务响应端可以基于第一公网通信地址和第二公网通信地址和第一公网通信地址建立公网通信链路，使得业务请求端和业务响应端在业务数据传输阶段可以采用基于公网通信地址建立的通信链路进行业务数据传输，而不必依赖于sbc进行业务数据中转，从而减小业务数据传输的时延，提升业务数据传输的速率，提升终端侧用户的业务体验。

本发明其他特征和相应的有益效果在说明书的后面部分进行阐述说明，且应当理解，至少部分有益效果从本发明说明书中的记载变的显而易见。

附图说明

图1为相关技术中提供的一种通信系统的结构示意图；

图2为本发明实施例一中提供的一种业务实现方案中的交互流程图；

图3为本发明实施例二中提供的一种业务实现方案中的交互流程图；

图4为本发明实施例二中提供的sbc生成业务请求的一种流程图；

图5为本发明实施例三中提供的一种业务实现方案中的交互流程图；

图6为本发明实施例四中提供的业务请求装置的一种结构示意图；

图7为本发明实施例四中提供的业务协商装置的一种结构示意图；

图8为本发明实施例四中提供的业务响应装置的一种结构示意图；

图9为本发明实施例七中提供的网络设备的一种硬件结构示意图；

图10为本发明实施例七中提供的网络系统的一种示意图；

图11为本发明实施例八中提供的网络系统的一种结构示意图；

图12为本发明实施例八示例1中提供的一种业务实现方案中的交互流程图；

图13为本发明实施例八示例2中提供的一种业务实现方案中的交互流程图；

图14为本发明实施例八示例3中提供的一种网络系统抵御恶意终端媒体攻击的一种流程图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，下面通过具体实施方式结合附图对本发明实施例作进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

实施例一：

通信技术的演进已经到了第五代，5g通信技术主要面向未来的五个主要应用场景：

1)超高速场景，为未来移动宽带用户提供极速数据网络接入；

2)支持大规模人群，为高人群密度地区或场合提供高质量移动宽带体验；

3)随时随地最佳体验，确保用户在移动状态仍享有高质量服务；

4)超可靠的实时连接，确保新应用和用户实例在时延和可靠性方面符合严格的标准；

5)无处不在的物物通信，确保高效处理多样化的大量设备通信，包括机器类设备和传感器等。

随着5g网络的发展，可以提供更多信息量的快速传递和更丰富的业务体验，多媒体内容代替文本信息、视频通话、个人社交呈现等特点，都已成为技术发展的新趋势，rcs成为5g网络基础上的业务应用的一个发展方向。

rcs，是由gsma(globalsystemformobilecommunicationsassembly，全球移动通信联盟)负责规划，构建在ims(ipmultimediasubsystem，网际协议多媒体子系统)网络之上的具有统一业务集定义的技术标准，是基于手机电话号码簿实现语音、消息、状态呈现等多媒体业务的总称。

rcs是基于ims网络之上的应用，ims是3gpp(thirdgenerationpartnershipproject，第三代合作伙伴计划)提出的支持ip多媒体业务的子系统，是多媒体通信的发展方向，作为4g时代中的应用子系统，能很好的满足4g时代中人与人之间的通信，其显著特征是采用了sip(sessioninitialprotocol，会话初始协议)体系，通信与接入方式无关，具备多种多媒体业务的控制功能与承载能力分离、呼叫与会话分离、应用与服务分离、业务与网络分离，以及移动网与因特网业务融合等多种能力。

相关技术中，rcs中多媒体业务数据的传输需要依赖sbc进行中转，请参见图1示出的相关技术中提供的一种通信系统的结构示意图：

通信系统1包括终端11、nat设备12、sbc13以及as14，终端11与nat设备12通信连接，nat设备12与sbc13通信连接，sbc13同时还与as14通信连接：

其中，终端11负责发起请求或接收业务请求后对业务请求进行响应，对于终端11而言，无论是会话协商阶段(或称“会话连接阶段”)还是业务数据传输阶段(或称“媒体连接阶段”)，其都使用自己的私网ip地址。

nat设备12用于将来自终端的消息中的私网ip地址转换成公网ip地址，完成与sbc13以及as14的通信。同时，nat设备12还用于将来自公网侧消息转发给终端11。网络地址转换属接入广域网(wan)技术，是一种将私有(保留)地址转化为合法ip地址的转换技术，负责提供私网ip地址和公网ip地址的转换，并提供私网数据流和公网数据流的转发。

通信系统1中的sbc13包括会话协商单元131、媒体中转单元132，其中会话协商单元131负责对终端的接入和会话进行认证，并向as14发送来自终端的业务请求或业务响应。媒体中转单元132用于接收来自as14的业务数据并发送给终端11，或者是接收来自终端11的业务数据，并将接收到的业务数据发送给as14。

as14包括会话处理单元141和媒体传输单元142，其中，会话处理单元141用于接收终端11通过sbc13转发的业务请求或者业务响应，同终端11间实现会话协商，在会话协商阶段结束后，会话处理单元141还会将协商所得的ip地址传输给媒体传输单元142。媒体传输单元142用于在sbc13以及nat设备12的帮助下实现与终端11间的媒体业务数据交互。

在相关技术中，通信系统1中的nat设备12与sbc13之间基于公网ip进行通信，而sbc13与as14间基于私网ip进行通信。所以，sbc13的会话协商单元131在中转as14与终端11间的会话协商消息(业务请求或业务响应)时，需要进行公网ip与私网ip的转换。例如，在接收到as14需要发送给终端的业务响应时，会话协商单元131需要将业务请求中as的私网ip转换成sbc13的公网ip地址，然后将转换后的业务响应发送给nat设备12，以供nat设备12将业务响应发送给终端11。对应地，如果会话协商单元131接收到nat设备12转发的终端11的业务请求，由于sbc13与nat设备12间基于公网ip通信，所以，在该业务请求中携带有nat设备12转换后的公网ip地址，而sbc13与as14间基于私网ip进行通信，所以，会话协商单元131需要将该业务请求中携带的nat设备12的公网ip地址转换成sbc的私网ip地址，然后才能将业务请求中发送给as14。

同样的，媒体中转单元132在中转as14和终端11间的媒体业务数据时，也需要对公网ip地址与私网ip地址进行转换，具体的转换示例和会话协商阶段中会话协商单元131的转换类似，这里不再赘述。

在相关技术中，sbc13对会话协商消息以及媒体业务数据的中转，可以实现媒体地址nat穿越、媒体地址合法性验证等，可以避免as14的公网ip地址直接对外暴露，从而可以提升as14的安全性。不过，由于sbc13在对媒体业务数据进行中转时，必然需要花费一定的处理时间，这导致了业务数据传输时延大，用户业务体验不佳的问题。

为了解决相关技术中通过sbc来中转终端与as间业务数据所带来的问题，本实施例提供一种业务实现方案，该业务实现方案包括业务请求方法、业务协商方法以及业务响应方法，下面结合图2示出的业务实现方案中业务请求端、业务响应端以及sbc三端的交互图：

在对本实施例中实现业务的流程进行介绍之前，先对本实施例中，业务请求端与业务响应端进行介绍：可以理解的是，在实际的业务过程中，有些业务是由终端发起的，在这种情况下，终端作为业务请求端，而应用服务器作为业务响应端；当然，还存在另一些业务是由应用服务器发起的，此时，应用服务器作为业务请求端，而终端则作为业务响应端。

业务请求端包括私网通信地址和公网通信地址，同样的，业务响应端也包括私网通信地址和公网通信地址，为了区分业务请求端的公网通信地址和业务响应端的公网通信地址，在本实施例中，将业务请求端的公网通信地址称为“第一公网通信地址”，将业务响应端的公网通信地址称为“第二公网通信地址”。本领域技术人员可以理解的是，这仅仅是为了便于介绍而对两个公网通信地址进行区分的一种手段，并不用于限定本实施例的范围。可以理解的是，终端侧的公网通信地址可以是指nat设备的公网通信地址。

s202：业务请求端将用于业务请求的请求消息发送给sbc。

在本实施例中，业务请求端在需要向业务响应端请求某种业务服务时，可以生成请求消息，然后将请求消息发送给sbc。然后由sbc根据业务请求端的请求消息向业务响应端发送业务请求。sbc发送给业务响应端的业务请求中携带有业务请求端的第一公网通信地址。

s204：sbc根据业务请求端的请求向业务响应端发送携带业务请求端第一公网通信地址的业务请求。

可以理解的是，sbc在向业务响应端发送业务请求是根据从业务请求端接收到的请求消息生成的，在业务请求中携带有业务请求端的第一公网通信地址，所以在本实施例的一些示例中，业务请求端发送给sbc的请求消息中，就可以携带有该第一公网通信地址。在这种情况下，sbc可以直接将该请求消息作为业务请求发送给业务响应端。例如，在本实施例的一些示例当中，业务请求端为as，as在向终端请求开始某种业务时，会在发送给sbc的请求消息中携带自己的公网ip地址，当sbc接收到as的请求消息后，可以不对其中的公网ip地址进行修改，直接将该请求消息作为业务请求发送给终端。

在本实施例的另一些示例当中，业务请求端发送给sbc的请求消息中携带的是其私网通信地址，在这种情况下，sbc需要将根据业务请求端的第一公网通信地址以及请求消息生成业务请求，例如将请求消息中的私网通信地址修改为第一公网通信地址从而生成业务请求，然后将该业务请求发送给业务响应端。例如，在本实施例的一些示例当中，as作为业务请求端，其在向sbc发送请求消息时，携带的是as的私网ip地址，在这种情况下，sbc接收到请求消息后，需要将请求消息as的私网ip地址修改为as的公网ip地址，然后将修改处理后得到的请求消息作为业务请求发送给终端。又例如，终端作为业务请求端时，通过nat设备发送给sbc的请求消息中，也携带的是终端的私网ip地址，当sbc接收到来自终端的请求消息后，将该请求消息中的私网通信地址修改为终端侧的公网ip地址，从而得到业务请求。

s206：业务响应端将与业务请求对应的业务响应发送给sbc。

业务响应端接收到业务请求之后，可以根据业务请求对业务请求端的请求进行响应，所以业务响应端会根据业务请求向业务请求端发送业务响应。该业务响应发送给sbc，让sbc根据业务响应向业务请求发送携带业务响应端第二公网通信地址的响应消息。

s208：sbc根据业务响应端的响应向业务请求端发送携带业务响应端第二公网通信地址的响应消息。

和sbc根据业务请求端的请求向业务响应端发送业务响应类似，在本实施例中，sbc向业务请求端发送响应消息是根据从业务响应端接收到的业务响应生成的，在响应消息中携带有业务响应端的第二公网通信地址，所以在本实施例的一些示例中，业务响应端发送给sbc的业务响应中，可以携带有该第二公网通信地址。在这种情况下，sbc可以直接将该业务响应作为响应消息发送给业务请求端。例如，在本实施例的一些示例当中，业务响应端为as，as在根据终端的请求发送业务响应时，可以在业务响应中携带自己的公网通信地址。对于sbc来说，接收到携带as公网通信地址的业务响应之后，可以不对其中的公网ip地址进行修改，直接将该业务响应作为请求消息对应的响应消息发送给终端。

在本实施例的另一些示例当中，业务响应端发送给sbc的业务响应中携带的是其私网通信地址，在这种情况下，sbc需要将根据业务响应端的第二公网通信地址以及业务响应生成响应消息，例如通过将业务响应中的私网通信地址修改为第二公网通信地址从而生成响应消息，然后将该响应消息发送给业务请求端，作为业务请求端所发送的请求消息的应答。例如，在本实施例的一些示例当中，as作为业务响应端，其在向sbc发送业务响应时，携带的是as的私网ip地址，在这种情况下，sbc接收到业务响应后，需要将请求消息as的私网ip地址修改为as的公网ip地址，然后修改处理后的业务响应作为响应消息发送给终端。又例如，终端作为业务响应端时，通过nat设备向sbc发送业务响应，该业务响应中，也携带的是终端的私网ip地址，当sbc接收到来自终端的业务响应后，将该业务响应中的私网通信地址修改为终端侧的公网ip地址，从而得到可以发送给as侧的响应消息。

在本实施例的一些示例当中，sbc发送给终端的响应消息中还包括as的端口号。

s210：业务响应端与业务请求端基于第一公网通信地址和第二公网通信地址建立公网通信链路。

在会话协商阶段，通过sbc向业务响应端发送的业务请求，可以使得业务响应端获取到业务请求端的第一公网通信地址；通过sbc向业务请求端发送的响应消息可以使得业务请求端获取到业务响应端的第二公网通信地址。在此基础上，业务请求端和业务响应端可以根据该第一公网通信地址与第二公网通信地址在彼此之间建立公网通信链路。该公网通信链路为基于公网通信地址建立的通信链路，该通信链路可以在业务请求端和业务响应端之间进行业务数据的传输，实现业务而不必依赖于sbc的中转。

下面对业务响应端与业务请求端之间建立公网通信链路的过程进行简单介绍：

可以理解的是，在建链过程中，建链请求可以由业务请求端发起，也可以由业务响应端发起。例如，在本实施例的一种示例中，建链请求由业务请求端发起，在这种情况下，业务请求端实际就是建链发起端，而业务响应端就是建链响应端。业务请求端根据会话协商获取到的第二公网通信地址向业务响应端发送建链请求，业务响应端在接收到该建链请求之后，可以根据会话协商阶段获取到的第一公网通信地址向业务请求端发送建链响应，从而与业务请求端之间建立起公网通信链路。在本实施例的另一种示例中，建链请求由业务响应端向业务请求端发起，在这种情景下，业务响应端作为建链请求端，而业务请求端作为建链响应端。业务响应端根据会话协商时获取到的第一公网通信地址向业务请求端发送建链请求。在业务请求端接收到建链请求后，如果同意建立基于公网的通信链路，就可以向业务响应端发送表征肯定的建链响应；否则业务请求端可以拒绝该建链请求。

在本实施例的一些示例中，建链响应端在接收到建链请求端发送的建链请求后，可以对建链请求端进行验证，只有验证建链请求端是之间与自己进行会话协商的设备后，才会允许建链公网通信链路。可以理解的是，建链响应端对建链请求端的身份合法性进行验证，可以通过验证建链请求端的公网通信地址实现：建链请求端在向建链响应端发起建链请求的时候，可以在建链请求中携带自己的公网通信地址。建链响应端对接收到该建链请求之后，确定该建链请求中所携带的公网通信地址是否是自己在会话协商阶段获取到的公网通信地址。

继续结合上述示例进行介绍：

首先，假定建链请求端为业务请求端，则在建链请求端发送的建链请求中携带有第一公网通信地址。建链响应端接收到建链请求之后，可以将建链请求中携带的公网通信地址与自己在会话协商过程中获取到的业务请求端的第一公网通信地址进行比对，确定二者是否一致。若二者一致，则说明该建链请求就是由预先同自己进行会话协商的业务请求端，因此建链请求端的身份合法，建链响应端可以可以发起表征肯定的建链响应，从而同建链请求端建立起公网通信链路；若二者不一致，则说明发起建链请求的建链请求端并不是业务请求端，因此，作为建链响应端的业务响应端可以拒绝建链请求端的建链请求。

假定建链请求端为业务响应端，则建链响应端为业务请求端。业务响应端作为建链请求端，在向建链响应端发送建链请求时，可以在该建链请求中携带自己的公网通信地址，即第二公网通信地址。建链响应端接收到一个建链请求之后，将其中的公网通信地址与自己在会话协商阶段从业务响应端获取到的第二公网通信地址进行比对，若二者一致，则说明建链请求端就是与自己进行会话协商的业务响应端，因此，作为建链响应端的业务请求端可以根据预先获取到的第二公网通信地址向建链请求端发送表征同意建链的建链响应，与对端建立起公网通信链路，然后在该通信链路上进行业务数据的传输。如果建链响应端通过比对发现接收到的建链请求中所携带的公网通信地址不是第二公网通信地址，则说明该建链请求端身份不合法，因此建链响应端可以拒绝该建链请求端的建链请求。

根据前面的介绍可知，在本实施例的一些示例中，业务请求端为终端，在本实施例的另一些示例当中，业务请求端为应用服务器。考虑到在通信系统当中，终端通常是通过nat设备对外通信的，对于外界设备而言，主动发起对终端的通信可能不是特别容易，因此，在本实施例中，建链请求可以由终端向as发起，也即终端作为建链请求端，as作为建链响应端。所以，当终端为业务请求端时，建链请求由业务请求端向业务响应端发送，当终端为业务响应端时，建链请求由业务响应端向业务请求端发送。

本实施例提供的业务请求方法、业务协商方法以及业务响应方法，在会话协商阶段，通过向业务响应端发送包含业务请求端第一公网通信地址的业务请求，并根据业务响应端的响应，向业务请求端发送携带业务响应端第二公网通信地址的响应消息，使得业务请求端和业务响应端可以获取到彼此的公网通信地址，然后基于对方的公网通信地址在二者之间建立起公网通信链路进行业务数据传输，实现业务，避免了业务数据的传输需要经过sbc进行中转，造成业务数据传输速率不高，时延大的问题，提升了终端侧的用户业务体验。

实施例二：

本实施例将实施例一的基础上继续对业务实现方案进行介绍，假定本实施例中终端为业务请求端，as为业务响应端，例如，假定终端需要向as上传视频数据。同时，假定as向sbc发送的消息中携带的仍是as的私网通信地址，请参见图3示出的一种业务实现方案的流程图：

s302：终端通过nat设备向sbc发送请求消息。

终端由于需要向应用服务器上传视频数据，因此，终端可以向as发起视频数据上传请求。在该请求消息中携带可以携带有终端所请求的业务服务类型。

在本实施例中，终端通过nat设备实现对外通信，终端向nat设备发送的请求消息中携带有终端的私网通信地址，同时该请求消息的源地址为终端的私网通信地址，目的地址为sbc的公网通信地址。在nat设备接收到该请求消息之后，会对请求消息中源地址进行转换，将该源地址修改为nat设备的公网通信地址。可以理解的是，nat设备的公网通信地址实际也就可以视为终端的公网通信地址，在本实施例中，终端作为业务请求端，因此nat设备的公网通信地址实际就是第一公网通信地址。

nat设备完成私网通信地址到公网通信地址的转换之后，可以将转换后的请求消息发送到目的地址，也即发送给sbc设备。

s304：sbc根据请求消息生成业务请求。

sbc设备接收到nat设备转发过来的请求消息之后，可以根据请求消息生成业务请求。sbc生成的业务请求中携带有终端侧的公网通信地址，即第一公网通信地址。可以理解的是，sbc可以将请求消息中终端的私网通信地址修改为终端侧的第一公网通信地址，从而得到业务请求。

在本实施例的一些示例中，并不是针对终端所请求的所有业务，都要在终端与as之间建立公网通信链路，例如，在一些情况下，针对终端所请求的某些业务，as并不希望对外暴露自己的公网通信地址。所以本实施例提供一种可供参考的sbc生成业务请求的流程，请参见图4：

s402：sbc判断业务请求端所请求的业务是否支持采用公网通信链路进行业务数据传输。

若判断结果为是，则执行s404，否则执行s406。

在本实施例中，sbc可以根据请求消息的消息体来判断业务请求所请求的业务是否支持采用公网通信链路进行传输，例如，本实施例中，终端在请求进行视频数据上传时，可以在请求消息的消息中携带所请求的服务类型，让sbc根据消息体中的服务类型来确定所请求的业务是否支持采用公网通信链路进行业务数据传输。

在本实施例的另一些示例当中，sbc可以根据请求消息的消息头来判断业务请求端所请求的业务是否支持采用公网通信链路进行业务数据传输。在这种情况下，业务请求端向sbc发送的请求消息的消息头中应当存在对应的指示信息。例如，在请求消息的消息头中包括服务指示，当服务指示为“0”时，表征业务请求端所请求的业务支持基于公网通信地址进行传输，当服务指示为“1”时，表征业务请求端所请求的业务不支持基于公网通信地址进行业务数据传输。可以理解的是，在这种方案当中，可以由业务请求端在发送请求消息之前先根据自己所请求的业务服务类型确定其该业务是否支持采用公网通信链路进行业务数据传输，也即该业务是否支持媒体直连。然后，业务请求端根据判断阶段设置请求消息的消息头。

在本实施例的其他一些示例当中，sbc可以结合请求消息的消息头和消息体来判断所请求的业务支持采用公网通信链路进行业务数据传输。例如，sbc要求根据两种方式的判断结果均表征所请求的业务支持媒体直连时，才会判定所请求的业务支持采用公网通信链路进行业务数据传输。

s404：sbc在生成的业务请求中携带业务请求端的第一公网通信地址。

如果sbc经过判断确定所请求的业务支持采用公网通信链路进行业务数据传输，则sbc需要生成携带业务请求端第一公网通信地址的业务请求。

s406：sbc在生成的业务请求中携带自己的私网通信地址。

如果sbc经过判断确定所请求的业务不支持采用公网通信链路进行业务数据传输，则sbc可以确定该业务对应的业务数据还是会按照相关技术中的方式进行传输，即经过自己进行中转。由于sbc同as之间基于私网通信地址进行通信，因此，sbc需要在生成的业务请求端携带自己的私网通信地址。

s306：sbc将业务请求发送给as。

sbc生成业务请求之后，可以将该业务请求发送给as，可以理解的是，sbc与as之间在通信的时候可以通过cscf(callsessioncontrolfunction，呼叫会话控制功能)网元进行中转，例如，sbc将业务请求先发送给cscf网元，然后由cscf网元将业务请求转发给as。当然，sbc与as之间的通信方式不限于上述示例中示出的方式。

s308：as根据业务请求向sbc发送业务响应。

as在接收到来自sbc的业务请求之后，可以根据业务请求发送业务响应，让sbc根据自己的响应向终端发送对应于请求消息的响应消息。

在本实施例中，as在会话协商阶段并不关心终端所请求的业务是否支持采用公网通信链路进行业务数据传输，无论终端请求的是何种业务，as在向sbc发送业务响应的时候，携带的均是自己的私网通信地址。

在as生成业务响应之后，将携带自己私网通信地址的业务响应发送给sbc，可以理解的是，业务响应的传输路径与业务请求的传输路径对应，所以在本实施例的一些示例当中，业务响应可以经cscf网元发送给sbc。

s310：sbc根据业务响应生成响应消息。

sbc接收到来自as的业务响应之后，根据业务响应生成发送给终端的响应消息。在响应消息中携带有as侧的公网通信地址，即第二公网通信地址。

同样地，如果不是所有业务的业务数据都支持采用公网通信链路进行传输，则sbc在生成响应消息的时候，需要先确定业务响应所对应的业务是否支持采用公网通信链路进行传输。可以理解的是，如果sbc能够直接确定自己从as处接收到的业务响应是针对之前所发送的业务请求的，则sbc可以根据业务请求所请求的业务是否支持采用公网通信链路进行传输来确定如何对业务响应中的私网通信地址进行修改。

在本实施例的另一些示例当中，sbc也可以根据响应消息的消息头和/或消息体来进行判断。具体判断方式可以参见sbc生成业务请求的过程，这里不再赘述。

如果经过sbc的判断，确定业务响应所对应的业务支持媒体直连，则sbc可以对业务响应中as侧的私网通信地址进行修改，将其修改成as侧的公网通信地址，从而的到响应消息；否则sbc可以将业务响应中的私网通信地址修改成自己的公网通信地址，生成响应消息。

s312：sbc通过nat设备将响应消息发送给终端。

sbc生成响应消息之后，可以将响应消息传输给nat设备，让nat设备根据终端的私网通信地址将该响应消息传输给终端。

s314：终端向as发送建链请求。

终端接收到响应消息之后，如果确定as同意响应自己的请求消息，则可以根据响应消息中携带的公网通信地址向as发送建链请求。可以理解的是，在终端向as发送建链请求时，建链请求也同样需要通过nat设备进行私网通信地址与公网通信地址的转换后再发送给as。另外，在终端发送的建链请求中携带有终端侧的公网通信地址。

s316：as对建链请求进行验证。

as接收到终端侧发送的建链请求之后，可以根据建链请求对建链请求端的身份进行验证，确定发送建链请求的是否是之前与自己进行会话协商的业务请求端。可选地，as可以判断建链请求中所携带的公网通信地址是否是自己在会话协商阶段所获得的终端侧的公网通信地址，也即第一公网通信地址。

在确定建链请求中的公网通信地址是第一公网通信地址的情况下，as确定建链请求端的身份合法。

在本实施例的另一些示例中，as不仅会根据建链请求中的公网通信地址对建链请求端的身份进行认证，而且还会根据建链请求中建链请求端的私网通信地址进行认证。在这种情况下，sbc根据来自终端的请求消息向as发送业务请求时，还会在业务请求中携带终端的私网通信地址。这样当as接收到建链请求之后，除了对建链请求中的公网通信地址进行认证以外，还可以结合建链请求中的私网通信地址进行认证，判断该建链请求中的私网通信地址是否是业务请求中携带的私网通信地址。如果as判断建链请求中的公网通信地址与私网通信地址均与业务请求中的一致，则可以确认建链请求端就是业务请求端。

s318：as向终端发送建链响应。

在as确定建链请求是由之前的业务请求端发起时，as可以向终端发送表征肯定的建链响应。

s320：as与终端建立公网通信链路。

在终端接收到建链响应之后，可以基于第二公网通信地址同as建立起公网通信链路，随后在该通信链路上向as进行视频数据传输，实现对应的数据传输业务。

本实施例提供的业务实现方案，终端和as不仅可以通过在会话协商阶段获取的对端的公网通信地址，从而建立用于业务数据传输的通信链路，避免业务数据传输过程中需要sbc中转的问题；而且，sbc在向as发送业务请求或在向终端发送响应消息之前，可以根据业务请求端所请求的业务是否支持媒体直连来确定是否要携带业务请求端公网通信地址或业务响应端公网通信地址，使得一些业务可以采用公网通信链路传输，另一些业务可以继续采用相关技术中的方案实现，在改善用户体验的问题可以兼容相关技术的方案。

更进一步的，在本实施例提供的业务实现方案中，as在接收到建链请求之后，可以对建链请求端的身份进行验证，保证与自己建立基于公网通信链路的是之前协商过的终端，提升了应用服务器的安全性。

可以理解的是，实施例二中虽然仅介绍了终端作为业务请求端，as作为业务响应端时的业务实现方案，不过本领域技术人员可以理解的是，实施例二中方案的实现原理也适用于终端作为业务响应端，接收as的请求的情景。

实施例三：

本实施例同样在实施例一的基础上继续对业务实现方案进行介绍，这里假定业务请求端为as，而终端则作为业务响应端。例如，假定as请求终端接收自己的消息推送。同时，还假定as在向sbc发送消息时，可以根据实际情况选择携带自己公网通信地址，或者携带自己的私网通信地址。

请参见图5示出的业务实现方案的一种可选的流程图：

s502：as确定需要请求的业务支持采用公网通信链路进行业务数据传输。

在本实施例中，as在需要向终端发起请求时，会先确定自己当前所请求的业务是否支持采用公网通信链路进行业务数据传输，也即自己当前所请求的业务是否支持媒体直连。若判断结果为是，则as将在生成的请求信息中携带自己的公网通信地址，因为as在本实施例中作为业务请求端，所以as的公网通信地址即为第一公网通信地址。

可以理解的是，如果经过判断，as确定自己当前所请求的业务不支持采用公网通信链路进行业务传输，则说明该业务的业务数据还是需要通过sbc进行中转，因此，as在生成请求消息时，在该请求消息中添加的是自己的私网通信地址。

s504：as向sbc发送请求消息。

as生成请求消息之后，将该请求消息发送给sbc，可以理解的是，as与sbc之间可以通过cscf网元进行通信，即as先将请求消息发送给cscf网元，然后由cscf网元将该请求消息发送给sbc。当然可以理解的是，在一些其他的示例当中，as与sbc之间的通信方式也可以与上述方式不同。

s506：sbc确定as所请求的业务支持采用公网通信链路进行业务数据传输。

sbc接收到as发送的请求消息之后，需要根据请求消息生成业务请求。在本实施例中，sbc也需要确定as所请求的业务是否支持采用公网通信链路进行业务数据传输，如果判断结果为是，则sbc可以不对请求消息中的通信地址进行修改，即可得到携带as的公网通信地址，即第一公网通信地址的业务请求；如果sbc的判断结果为否，则sbc需要对as发送的携带as私网通信地址的业务请求进行修改，将其中as的私网通信地址修改为sbc的公网通信地址后才能得到业务请求。

可以理解的是，sbc在确定as所请求的业务是否支持媒体直连时，可以根据请求消息的消息体进行判断。在消息体中包含有as所请求业务服务的类型，所以sbc根据所请求业务服务的类型确定业务是否支持媒体直连。当然，由于as在发送请求消息的时候也需要先判断自己所请求的业务是否支持媒体直连服务，因此，在本实施例的一种示例当中，as在得到判断结果之后，可以将判断结果携带在请求消息中发送给sbc，这样，当sbc接收到as发送的请求消息之后，可以直接从接收到的请求消息中确定出as所请求的业务是否支持媒体直连，避免了sbc根据请求消息中的业务服务类型进行判断的过程。例如，在as向sbc发送的请求消息的消息头中包括有服务指示，如果该服务指示的值为“0”，则代表该请求消息所请求的业务服务支持媒体直连服务，否则，说明该业务请求所请求的业务服务不支持媒体直连服务。

s508：sbc将请求消息作为业务请求发送给终端。

假定sbc确定请求消息所请求的业务服务支持媒体直连服务，则sbc可以将携带有as公网通信地址的请求消息作为业务请求发送给终端。如果sbc确定请求消息所请求的业务服务不支持媒体直连服务，则sbc可以将携带自己公网通信地址的业务请求发送给终端。

s510：终端根据接收到的业务请求向sbc发送业务响应。

终端通过nat设备接收到业务请求之后，可以根据业务请求向sbc发送业务响应。业务响应中携带有终端的私网通信地址。可以理解的是，业务响应需要通过nat设备发送给sbc。在nat设备接收到业务响应之后，可以将业务响应的源地址从终端的私网通信地址修改为自己的公网通信地址，从而实现私网通信地址到公网通信地址的转换。由于终端在本实施例中作为业务响应端，因此，nat设备的公网通信地址实际可以被视为终端的公网通信地址，即第二公网通信地址。

s512：sbc根据业务响应生成响应消息。

sbc在接收到来自终端的业务响应之后，可以根据业务响应生成响应消息，在该响应消息中也携带有终端侧的第二公网通信地址。不过本领域技术人员可以明白的是，在本示例中，是因为as所请求的业务服务支持媒体直连，因此，sbc将会在响应消息中携带终端的第二公网通信地址。在本实施例的其他一些示例中，如果as所请求的业务不支持媒体直连，则sbc则需要在响应消息中携带自己的私网通信地址。

另外，在本实施例中，sbc在接收来自终端侧的业务响应之后，如果可以确定该业务响应是属于哪一个业务请求的，则sbc可以直接根据业务请求确定该业务响应对应的业务是否支持媒体直连；但如果sbc不能确定出接收到业务响应是对应哪一个业务请求，则sbc在根据业务响应生成响应消息时，需要根据业务响应的消息头和/或消息体确定该业务响应对应的业务是否支持媒体直连，从而确定该在对应的响应消息中携带终端侧的第二公网通信地址还是sbc的私网通信地址。

s514：sbc将响应消息发送给as。

sbc生成响应消息之后，可以将响应消息通过cscf网元发送给as，从而让as根据响应消息确定终端是否接受自己的请求。在as确定终端针对其业务请求进行了表征肯定的应答后，可以在接收到响应消息之后与终端建立公网通信链路。

s516：终端向as发送建链请求。

在终端的响应到达as侧之后，终端可以根据业务请求中所携带的第一公网通信地址，即as侧的公网通信地址向as发送建链请求。可以理解的是，在终端向as发送建链请求时，建链请求也同样需要通过nat设备进行私网通信地址与公网通信地址的转换后再发送给as。

s518：as对建链请求进行验证。

as接收到终端侧发送的建链请求之后，可以根据建链请求对建链请求端的身份进行验证，确定发送建链请求的是否是之前与自己进行会话协商的业务响应端。可选地，as可以判断建链请求中所携带的公网通信地址是否是自己在会话协商阶段所获得的终端侧的公网通信地址，也即第二公网通信地址。

在确定建链请求中的公网通信地址是第二公网通信地址的情况下，as确定建链请求端的身份合法。

在本实施例的另一些示例中，as不仅会根据建链请求中的公网通信地址对建链请求端的身份进行认证，而且还会根据建链请求中建链请求端的私网通信地址进行认证。在这种情况下，sbc根据来自终端的业务响应向as发送响应消息时，还会在响应消息中携带终端的私网通信地址。这样当as接收到建链请求之后，除了对建链请求中的公网通信地址进行认证以外，还可以结合建链请求中的私网通信地址进行认证，判断该建链请求中的私网通信地址是否是响应消息中携带的私网通信地址。如果as判断建链请求中的公网通信地址与私网通信地址均与响应消息中的一致，则可以确认建链请求端就是业务响应端。

s520：as向终端发送建链响应。

在as确定建链请求是由之前的业务响应端发起时，as可以向终端发送表征肯定的建链响应。

s522：as与终端建立公网通信链路。

在终端接收到建链响应之后，可以基于第一公网通信地址同as建立起公网通信链路，随后在该通信链路上接收as的消息推送，实现对应的数据传输业务。

本发明实施例提供的业务实现方案，终端和as可在会话协商阶段获取的对端的公网通信地址，建立用于业务数据传输的通信链路，从而避免业务数据传输过程中需要sbc中转的问题。更进一步的，在本实施例提供的业务实现方案中，as在接收到建链请求之后，可以对建链请求端的身份进行验证，保证与自己建立基于公网通信链路的是之前协商过的终端，提升了应用服务器的安全性。

可以理解的是，实施例三中虽然仅介绍了as作为业务请求端，终端作为业务响应端时的业务实现方案，不过本领域技术人员可以理解的是，实施例三中方案的实现原理也适用于as作为业务响应端，接收终端的请求的情景。

实施例四：

本实施例提供一种业务请求装置、一种业务协商装置以及一种业务响应装置，请分别参见图6-8所示出的各装置的结构示意图：

首先，请参见图6示出的业务请求装置60的结构示意图，业务请求装置60包括请求发送模块602、响应接收模块604以及第一建链模块606，其中，请求发送模块602用于将用于业务请求的请求消息发送给sbc；响应接收模块604用于接收业务响应端在接收到业务请求后通过sbc发送的响应消息；第一建链模块606用于根据第二公网通信地址同业务响应端建立公网通信链路进行业务数据传输实现业务。其中，请求发送模块602在向sbc发送请求消息之后，可以让sbc根据请求消息向业务响应端发送携带业务请求装置60侧的第一公网通信地址。而响应接收模块604接收到的响应消息中包括业务响应端的第二公网通信地址。

图7示出了一种业务协商装置70，该业务协商装置70包括请求转发模块702、响应转发模块704，其中请求转发模块702用于根据业务请求端的请求向业务响应端发送携带业务请求端第一公网通信地址的业务请求，而响应转发模块704用于根据业务响应端的响应向业务请求端发送响应消息.

图8示出的是一种业务响应装置80的结构示意图：业务响应装置80包括请求接收模块802、响应发送模块804以及第二建链模块806，其中，请求接收模块802用于接收sbc发送的业务请求，业务请求中包含业务请求端的第一公网通信地址；响应发送模块804用于将与业务请求对应的业务响应发送给sbc，业务响应用于sbc向业务请求端发送携带本端第二公网通信地址的响应消息；第二建链模块806用于根据第一公网通信地址同业务请求端建立公网通信链路进行业务数据传输实现业务。

在本实施例中，业务请求装置60可以部署在终端上，也可以部署在应用服务器上，业务请求装置60中请求发送模块602、响应接收模块604以及第一建链模块606的功能可以由终端的处理器控制终端的通信单元实现，或者可以由应用服务器的处理器与通信单元共同实现。

业务协商装置70可以部署在sbc上，其中，请求转发模块702、响应转发模块704的功能可以由sbc的处理器与通信单元共同实现。

业务响应装置80和业务请求装置60类似，也可以部署在终端上或者是部署在应用服务器上，请求接收模块802、响应发送模块804以及第二建链模块806的功能可以由终端的处理器控制终端的通信单元实现，或者可以由应用服务器的处理器与通信单元共同实现。

在本实施例中，请求发送模块602在需要向业务响应端请求某种业务服务时，可以生成请求消息，然后将请求消息发送给sbc。然后由sbc根据业务请求端的请求消息向业务响应端发送业务请求。sbc发送给业务响应端的业务请求中携带有业务请求端的第一公网通信地址。

在sbc向业务响应端发送了业务请求之后，业务响应端将会向sbc反馈业务响应。当sbc接收到业务响应之后，可以根据该业务响应向业务请求装置60发送响应消息，响应接收模块604可以接收sbc发送的响应消息，该响应消息中携带有业务响应端的第二公网通信地址。随后，第一建链模块606可以根据该第二公网通信地址与业务响应端进行建链交互，建立公网通信链路。

业务协商装置70的请求转发模块702根据业务请求装置60的请求向业务响应装置80发送携带业务请求装置60第一公网通信地址的业务请求。

可以理解的是，请求转发模块702在向业务响应装置80发送业务请求是根据从业务请求装置60接收到的请求消息生成的，在业务请求中携带有业务请求装置60的第一公网通信地址，所以在本实施例的一些示例中，业务请求装置60发送给业务协商装置70的请求消息中，就可以携带有该第一公网通信地址。在这种情况下，请求转发模块702可以直接将该请求消息作为业务请求发送给业务响应装置80。例如，在本实施例的一些示例当中，业务请求装置60为as，as在向终端请求开始某种业务时，会在发送给业务协商装置70的请求消息中携带自己的公网ip地址，当请求转发模块702接收到as的请求消息后，可以不对其中的公网ip地址进行修改，直接将该请求消息作为业务请求发送给终端。

在本实施例的另一些示例当中，业务请求装置60发送给业务协商装置70的请求消息中携带的是其私网通信地址，在这种情况下，请求转发模块702需要将根据业务请求装置60的第一公网通信地址以及请求消息生成业务请求，例如将请求消息中的私网通信地址修改为第一公网通信地址从而生成业务请求，然后将该业务请求发送给业务响应装置80。例如，在本实施例的一些示例当中，as作为业务请求装置60，其在向业务协商装置70发送请求消息时，携带的是as的私网ip地址，在这种情况下，请求转发模块702接收到请求消息后，需要将请求消息as的私网ip地址修改为as的公网ip地址，然后将修改处理后得到的请求消息作为业务请求发送给终端。又例如，终端作为业务请求端时，通过nat设备发送给业务协商装置70的请求消息中，也携带的是终端的私网ip地址，当请求转发模块702接收到来自终端的请求消息后，将该请求消息中的私网通信地址修改为终端侧的公网ip地址，从而得到业务请求。

业务响应装置80将与业务请求对应的业务响应发送给业务协商装置70。

业务响应装置80的请求接收模块802接收到业务请求之后，可以根据业务请求对业务请求装置60的请求进行响应，所以响应发送模块804会根据业务请求向业务请求装置60发送业务响应。该业务响应发送给业务协商装置70，让业务协商装置70根据业务响应向业务请求发送携带业务响应装置80第二公网通信地址的响应消息。

业务协商装置70的响应转发模块704根据业务响应装置80的响应向业务请求装置60发送携带业务响应装置80第二公网通信地址的响应消息。

和请求转发模块702根据业务请求装置60的请求向业务响应装置80发送业务响应类似，在本实施例中，响应转发模块704向业务请求装置60发送响应消息是根据从业务响应装置80接收到的业务响应生成的，在响应消息中携带有业务响应装置80的第二公网通信地址，所以在本实施例的一些示例中，业务响应装置80发送给业务协商装置70的业务响应中，可以携带有该第二公网通信地址。在这种情况下，响应转发模块704可以直接将该业务响应作为响应消息发送给业务请求装置60。例如，在本实施例的一些示例当中，业务响应装置80为as，as在根据终端的请求发送业务响应时，可以在业务响应中携带自己的公网通信地址。对于业务协商装置70来说，接收到携带as公网通信地址的业务响应之后，响应转发模块704可以不对其中的公网ip地址进行修改，直接将该业务响应作为请求消息对应的响应消息发送给终端。

在本实施例的另一些示例当中，业务响应装置80发送给业务协商装置70的业务响应中携带的是其私网通信地址，在这种情况下，响应转发模块704需要将根据业务响应装置80的第二公网通信地址以及业务响应生成响应消息，例如通过将业务响应中的私网通信地址修改为第二公网通信地址从而生成响应消息，然后将该响应消息发送给业务请求装置60，作为业务请求装置60所发送的请求消息的应答。例如，在本实施例的一些示例当中，as作为业务响应装置80，其在向业务协商装置70发送业务响应时，携带的是as的私网ip地址，在这种情况下，响应转发模块704接收到业务响应后，需要将请求消息as的私网ip地址修改为as的公网ip地址，然后修改处理后的业务响应作为响应消息发送给终端。又例如，终端作为业务响应端时，通过nat设备向业务协商装置70发送业务响应，该业务响应中，也携带的是终端的私网ip地址，当响应转发模块704接收到来自终端的业务响应后，将该业务响应中的私网通信地址修改为终端侧的公网ip地址，从而得到可以发送给as侧的响应消息。

在本实施例的一些示例当中，响应转发模块704发送给终端的响应消息中还包括as的端口号。

在会话协商阶段，通过业务协商装置70向业务响应装置80发送的业务请求，可以使得业务响应装置80获取到业务请求装置60的第一公网通信地址；通过业务协商装置70向业务请求装置60发送的响应消息可以使得业务请求装置60获取到业务响应装置80的第二公网通信地址。在此基础上，业务请求装置60和业务响应装置80可以根据该第一公网通信地址与第二公网通信地址在彼此之间建立公网通信链路。该公网通信链路为基于公网通信地址建立的通信链路，该通信链路可以在业务请求装置60和业务响应装置80之间进行业务数据的传输，实现业务而不必依赖于业务协商装置70的中转。

下面对业务响应装置80与业务请求装置60之间建立公网通信链路的过程进行简单介绍：

可以理解的是，在建链过程中，建链请求可以由业务请求装置60的第一建链模块606发起，也可以由业务响应装置80的第二建链模块806发起。例如，在本实施例的一种示例中，建链请求由第一建链模块606发起，在这种情况下，业务请求装置60实际就是建链发起端，而业务响应装置80就是建链响应端。第一建链模块606根据会话协商获取到的第二公网通信地址向业务响应装置80发送建链请求，第二建链模块806在接收到该建链请求之后，可以根据会话协商阶段获取到的第一公网通信地址向业务请求装置60发送建链响应，从而与业务请求装置60之间建立起公网通信链路。在本实施例的另一种示例中，建链请求由业务响应装置80的第二建链模块806向业务请求装置60发起，在这种情景下，业务响应装置80作为建链请求端，而业务请求装置60作为建链响应端。第二建链模块806根据会话协商时获取到的第一公网通信地址向业务请求装置60发送建链请求。在第一建链模块606接收到建链请求后，如果同意建立基于公网的通信链路，就可以向业务响应装置80发送表征肯定的建链响应；否则业务请求装置60可以拒绝该建链请求。

在本实施例的一些示例中，建链响应端在接收到建链请求端发送的建链请求后，可以对建链请求端进行验证，只有验证建链请求端是之间与自己进行会话协商的设备后，才会允许建链公网通信链路。可以理解的是，建链响应端对建链请求端的身份合法性进行验证，可以通过验证建链请求端的公网通信地址实现：建链请求端在向建链响应端发起建链请求的时候，可以在建链请求中携带自己的公网通信地址。建链响应端对接收到该建链请求之后，确定该建链请求中所携带的公网通信地址是否是自己在会话协商阶段获取到的公网通信地址。

继续结合上述示例进行介绍：

首先，假定建链请求端为业务请求装置60，则在建链请求端发送的建链请求中携带有第一公网通信地址。建链响应端接收到建链请求之后，可以将建链请求中携带的公网通信地址与自己在会话协商过程中获取到的业务请求装置60的第一公网通信地址进行比对，确定二者是否一致。若二者一致，则说明该建链请求就是由预先同自己进行会话协商的业务请求装置60，因此建链请求端的身份合法，建链响应端可以可以发起表征肯定的建链响应，从而同建链请求端建立起公网通信链路；若二者不一致，则说明发起建链请求的建链请求端并不是业务请求装置60，因此，作为建链响应端的业务响应装置80可以拒绝建链请求端的建链请求。

假定建链请求端为业务响应装置80，则建链响应端为业务请求装置60。业务响应装置80作为建链请求端，在向建链响应端发送建链请求时，可以在该建链请求中携带自己的公网通信地址，即第二公网通信地址。建链响应端接收到一个建链请求之后，将其中的公网通信地址与自己在会话协商阶段从业务响应装置80获取到的第二公网通信地址进行比对，若二者一致，则说明建链请求端就是与自己进行会话协商的业务响应装置80，因此，作为建链响应端的业务请求装置60可以根据预先获取到的第二公网通信地址向建链请求端发送表征同意建链的建链响应，与对端建立起公网通信链路，然后在该通信链路上进行业务数据的传输。如果建链响应端通过比对发现接收到的建链请求中所携带的公网通信地址不是第二公网通信地址，则说明该建链请求端身份不合法，因此建链响应端可以拒绝该建链请求端的建链请求。

根据前面的介绍可知，在本实施例的一些示例中，业务请求装置60为终端，在本实施例的另一些示例当中，业务请求装置60为应用服务器。考虑到在通信系统当中，终端通常是通过nat设备对外通信的，对于外界设备而言，主动发起对终端的通信可能不是特别容易，因此，在本实施例中，建链请求可以由终端向as发起，也即终端作为建链请求端，as作为建链响应端。所以，当终端为业务请求装置60时，建链请求由业务请求装置60向业务响应装置80发送，当终端为业务响应装置80时，建链请求由业务响应装置80向业务请求装置60发送。

本实施例提供的业务请求装置、业务协商装置以及业务响应装置，在会话协商阶段，通过向业务响应装置发送包含业务请求装置第一公网通信地址的业务请求，并根据业务响应装置的响应，向业务请求装置发送携带业务响应装置第二公网通信地址的响应消息，使得业务请求装置和业务响应装置可以获取到彼此的公网通信地址，然后基于对方的公网通信地址在二者之间建立起公网通信链路进行业务数据传输，实现业务，避免了业务数据的传输需要经过业务协商装置进行中转，造成业务数据传输速率不高，时延大的问题，提升了终端侧的用户业务体验。

实施例五：

本实施例将实施例四的基础上继续对业务实现方案进行介绍，假定本实施例中业务请求装置为终端，业务响应装置为as，同时假定业务协商装置为sbc，例如，假定终端需要向as上传视频数据。同时，假定as向sbc发送的消息中携带的仍是as的私网通信地址：

终端通过nat设备向sbc发送请求消息。

终端由于需要向应用服务器上传视频数据，因此，终端可以向as发起视频数据上传请求。在该请求消息中携带可以携带有终端所请求的业务服务类型。

在本实施例中，终端通过nat设备实现对外通信，终端向nat设备发送的请求消息中携带有终端的私网通信地址，同时该请求消息的源地址为终端的私网通信地址，目的地址为sbc的公网通信地址。在nat设备接收到该请求消息之后，会对请求消息中源地址进行转换，将该源地址修改为nat设备的公网通信地址。可以理解的是，nat设备的公网通信地址实际也就可以视为终端的公网通信地址，在本实施例中，终端作为业务请求端，因此nat设备的公网通信地址实际就是第一公网通信地址。

nat设备完成私网通信地址到公网通信地址的转换之后，可以将转换后的请求消息发送到目的地址，也即发送给sbc设备。

sbc设备接收到nat设备转发过来的请求消息之后，可以根据请求消息生成业务请求。sbc生成的业务请求中携带有终端侧的公网通信地址，即第一公网通信地址。可以理解的是，sbc可以将请求消息中终端的私网通信地址修改为终端侧的第一公网通信地址，从而得到业务请求。

在本实施例的一些示例中，并不是针对终端所请求的所有业务，都要在终端与as之间建立公网通信链路，例如，在一些情况下，针对终端所请求的某些业务，as并不希望对外暴露自己的公网通信地址。所以本实施例提供一种可供参考的sbc生成业务请求的流程：

sbc判断业务请求端所请求的业务是否支持采用公网通信链路进行业务数据传输。在本实施例中，sbc可以根据请求消息的消息体来判断业务请求所请求的业务是否支持采用公网通信链路进行传输，例如，本实施例中，终端在请求进行视频数据上传时，可以在请求消息的消息中携带所请求的服务类型，让sbc根据消息体中的服务类型来确定所请求的业务是否支持采用公网通信链路进行业务数据传输。

在本实施例的另一些示例当中，sbc可以根据请求消息的消息头来判断业务请求端所请求的业务是否支持采用公网通信链路进行业务数据传输。在这种情况下，业务请求端向sbc发送的请求消息的消息头中应当存在对应的指示信息。例如，在请求消息的消息头中包括服务指示，当服务指示为“0”时，表征业务请求端所请求的业务支持基于公网通信地址进行传输，当服务指示为“1”时，表征业务请求端所请求的业务不支持基于公网通信地址进行业务数据传输。可以理解的是，在这种方案当中，可以由业务请求端在发送请求消息之前先根据自己所请求的业务服务类型确定其该业务是否支持采用公网通信链路进行业务数据传输，也即该业务是否支持媒体直连。然后，业务请求端根据判断阶段设置请求消息的消息头。

在本实施例的其他一些示例当中，sbc可以结合请求消息的消息头和消息体来判断所请求的业务支持采用公网通信链路进行业务数据传输。例如，sbc要求根据两种方式的判断结果均表征所请求的业务支持媒体直连时，才会判定所请求的业务支持采用公网通信链路进行业务数据传输。

如果sbc经过判断确定所请求的业务支持采用公网通信链路进行业务数据传输，则sbc需要生成携带业务请求端第一公网通信地址的业务请求。

如果sbc经过判断确定所请求的业务不支持采用公网通信链路进行业务数据传输，则sbc可以确定该业务对应的业务数据还是会按照相关技术中的方式进行传输，即经过自己进行中转。由于sbc同as之间基于私网通信地址进行通信，因此，sbc需要在生成的业务请求端携带自己的私网通信地址。

sbc生成业务请求之后，可以将该业务请求发送给as，可以理解的是，sbc与as之间在通信的时候可以通过cscf(callsessioncontrolfunction，呼叫会话控制功能)网元进行中转，例如，sbc将业务请求先发送给cscf网元，然后由cscf网元将业务请求转发给as。当然，sbc与as之间的通信方式不限于上述示例中示出的方式。

as在接收到来自sbc的业务请求之后，可以根据业务请求发送业务响应，让sbc根据自己的响应向终端发送对应于请求消息的响应消息。

在本实施例中，as在会话协商阶段并不关心终端所请求的业务是否支持采用公网通信链路进行业务数据传输，无论终端请求的是何种业务，as在向sbc发送业务响应的时候，携带的均是自己的私网通信地址。

在as生成业务响应之后，将携带自己私网通信地址的业务响应发送给sbc，可以理解的是，业务响应的传输路径与业务请求的传输路径对应，所以在本实施例的一些示例当中，业务响应可以经cscf网元发送给sbc。

sbc接收到来自as的业务响应之后，根据业务响应生成发送给终端的响应消息。在响应消息中携带有as侧的公网通信地址，即第二公网通信地址。

同样地，如果不是所有业务的业务数据都支持采用公网通信链路进行传输，则sbc在生成响应消息的时候，需要先确定业务响应所对应的业务是否支持采用公网通信链路进行传输。可以理解的是，如果sbc能够直接确定自己从as处接收到的业务响应是针对之前所发送的业务请求的，则sbc可以根据业务请求所请求的业务是否支持采用公网通信链路进行传输来确定如何对业务响应中的私网通信地址进行修改。

在本实施例的另一些示例当中，sbc也可以根据响应消息的消息头和/或消息体来进行判断。具体判断方式可以参见sbc生成业务请求的过程，这里不再赘述。

如果经过sbc的判断，确定业务响应所对应的业务支持媒体直连，则sbc可以对业务响应中as侧的私网通信地址进行修改，将其修改成as侧的公网通信地址，从而的到响应消息；否则sbc可以将业务响应中的私网通信地址修改成自己的公网通信地址，生成响应消息。

sbc生成响应消息之后，可以将响应消息传输给nat设备，让nat设备根据终端的私网通信地址将该响应消息传输给终端。

终端接收到响应消息之后，如果确定as同意响应自己的请求消息，则可以根据响应消息中携带的公网通信地址向as发送建链请求。可以理解的是，在终端向as发送建链请求时，建链请求也同样需要通过nat设备进行私网通信地址与公网通信地址的转换后再发送给as。另外，在终端发送的建链请求中携带有终端侧的公网通信地址。

as接收到终端侧发送的建链请求之后，可以根据建链请求对建链请求端的身份进行验证，确定发送建链请求的是否是之前与自己进行会话协商的业务请求端。可选地，as可以判断建链请求中所携带的公网通信地址是否是自己在会话协商阶段所获得的终端侧的公网通信地址，也即第一公网通信地址。

在确定建链请求中的公网通信地址是第一公网通信地址的情况下，as确定建链请求端的身份合法。

在本实施例的另一些示例中，as不仅会根据建链请求中的公网通信地址对建链请求端的身份进行认证，而且还会根据建链请求中建链请求端的私网通信地址进行认证。在这种情况下，sbc根据来自终端的请求消息向as发送业务请求时，还会在业务请求中携带终端的私网通信地址。这样当as接收到建链请求之后，除了对建链请求中的公网通信地址进行认证以外，还可以结合建链请求中的私网通信地址进行认证，判断该建链请求中的私网通信地址是否是业务请求中携带的私网通信地址。如果as判断建链请求中的公网通信地址与私网通信地址均与业务请求中的一致，则可以确认建链请求端就是业务请求端。

在as确定建链请求是由之前的业务请求端发起时，as可以向终端发送表征肯定的建链响应。

在终端接收到建链响应之后，可以基于第二公网通信地址同as建立起公网通信链路，随后在该通信链路上向as进行视频数据传输，实现对应的数据传输业务。

本实施例提供的业务实现方案，终端和as不仅可以通过在会话协商阶段获取的对端的公网通信地址，从而建立用于业务数据传输的通信链路，避免业务数据传输过程中需要sbc中转的问题；而且，sbc在向as发送业务请求或在向终端发送响应消息之前，可以根据业务请求端所请求的业务是否支持媒体直连来确定是否要携带业务请求端公网通信地址或业务响应端公网通信地址，使得一些业务可以采用公网通信链路传输，另一些业务可以继续采用相关技术中的方案实现，在改善用户体验的问题可以兼容相关技术的方案。

更进一步的，在本实施例提供的业务实现方案中，as在接收到建链请求之后，可以对建链请求端的身份进行验证，保证与自己建立基于公网通信链路的是之前协商过的终端，提升了应用服务器的安全性。

可以理解的是，实施例五中虽然仅介绍了终端作为业务请求端，as作为业务响应端时的业务实现方案，不过本领域技术人员可以理解的是，实施例五中方案的实现原理也适用于终端作为业务响应端，接收as的请求的情景。

实施例六：

本实施例同样在实施例四的基础上继续对业务实现方案进行介绍，这里假定图6中的业务请求装置60为as，图7中的业务协商装置70为sbc，而图8中业务响应装置80为终端。例如，假定as请求终端接收自己的消息推送。同时，还假定as在向sbc发送消息时，可以根据实际情况选择携带自己公网通信地址，或者携带自己的私网通信地址。

在本实施例中，as在需要向终端发起请求时，会先确定自己当前所请求的业务是否支持采用公网通信链路进行业务数据传输，也即自己当前所请求的业务是否支持媒体直连。若判断结果为是，则as将在生成的请求信息中携带自己的公网通信地址，因为as在本实施例中作为业务请求端，所以as的公网通信地址即为第一公网通信地址。

可以理解的是，如果经过判断，as确定自己当前所请求的业务不支持采用公网通信链路进行业务传输，则说明该业务的业务数据还是需要通过sbc进行中转，因此，as在生成请求消息时，在该请求消息中添加的是自己的私网通信地址。

as生成请求消息之后，将该请求消息发送给sbc，可以理解的是，as与sbc之间可以通过cscf网元进行通信，即as先将请求消息发送给cscf网元，然后由cscf网元将该请求消息发送给sbc。当然可以理解的是，在一些其他的示例当中，as与sbc之间的通信方式也可以与上述方式不同。

sbc接收到as发送的请求消息之后，需要根据请求消息生成业务请求。在本实施例中，sbc也需要确定as所请求的业务是否支持采用公网通信链路进行业务数据传输，如果判断结果为是，则sbc可以不对请求消息中的通信地址进行修改，即可得到携带as的公网通信地址，即第一公网通信地址的业务请求；如果sbc的判断结果为否，则sbc需要对as发送的携带as私网通信地址的业务请求进行修改，将其中as的私网通信地址修改为sbc的公网通信地址后才能得到业务请求。

可以理解的是，sbc在确定as所请求的业务是否支持媒体直连时，可以根据请求消息的消息体进行判断。在消息体中包含有as所请求业务服务的类型，所以sbc根据所请求业务服务的类型确定业务是否支持媒体直连。当然，由于as在发送请求消息的时候也需要先判断自己所请求的业务是否支持媒体直连服务，因此，在本实施例的一种示例当中，as在得到判断结果之后，可以将判断结果携带在请求消息中发送给sbc，这样，当sbc接收到as发送的请求消息之后，可以直接从接收到的请求消息中确定出as所请求的业务是否支持媒体直连，避免了sbc根据请求消息中的业务服务类型进行判断的过程。例如，在as向sbc发送的请求消息的消息头中包括有服务指示，如果该服务指示的值为“0”，则代表该请求消息所请求的业务服务支持媒体直连服务，否则，说明该业务请求所请求的业务服务不支持媒体直连服务。

假定sbc确定请求消息所请求的业务服务支持媒体直连服务，则sbc可以将携带有as公网通信地址的请求消息作为业务请求发送给终端。如果sbc确定请求消息所请求的业务服务不支持媒体直连服务，则sbc可以将携带自己公网通信地址的业务请求发送给终端。

终端通过nat设备接收到业务请求之后，可以根据业务请求向sbc发送业务响应。业务响应中携带有终端的私网通信地址。可以理解的是，业务响应需要通过nat设备发送给sbc。在nat设备接收到业务响应之后，可以将业务响应的源地址从终端的私网通信地址修改为自己的公网通信地址，从而实现私网通信地址到公网通信地址的转换。由于终端在本实施例中作为业务响应端，因此，nat设备的公网通信地址实际可以被视为终端的公网通信地址，即第二公网通信地址。

sbc在接收到来自终端的业务响应之后，可以根据业务响应生成响应消息，在该响应消息中也携带有终端侧的第二公网通信地址。不过本领域技术人员可以明白的是，在本示例中，是因为as所请求的业务服务支持媒体直连，因此，sbc将会在响应消息中携带终端的第二公网通信地址。在本实施例的其他一些示例中，如果as所请求的业务不支持媒体直连，则sbc则需要在响应消息中携带自己的私网通信地址。

另外，在本实施例中，sbc在接收来自终端侧的业务响应之后，如果可以确定该业务响应是属于哪一个业务请求的，则sbc可以直接根据业务请求确定该业务响应对应的业务是否支持媒体直连；但如果sbc不能确定出接收到业务响应是对应哪一个业务请求，则sbc在根据业务响应生成响应消息时，需要根据业务响应的消息头和/或消息体确定该业务响应对应的业务是否支持媒体直连，从而确定该在对应的响应消息中携带终端侧的第二公网通信地址还是sbc的私网通信地址。

sbc生成响应消息之后，可以将响应消息通过cscf网元发送给as，从而让as根据响应消息确定终端是否接受自己的请求。在as确定终端针对其业务请求进行了表征肯定的应答后，可以在接收到响应消息之后与终端建立公网通信链路。

在终端的响应到达as侧之后，终端可以根据业务请求中所携带的第一公网通信地址，即as侧的公网通信地址向as发送建链请求。可以理解的是，在终端向as发送建链请求时，建链请求也同样需要通过nat设备进行私网通信地址与公网通信地址的转换后再发送给as。

as接收到终端侧发送的建链请求之后，可以根据建链请求对建链请求端的身份进行验证，确定发送建链请求的是否是之前与自己进行会话协商的业务响应端。可选地，as可以判断建链请求中所携带的公网通信地址是否是自己在会话协商阶段所获得的终端侧的公网通信地址，也即第二公网通信地址。

在确定建链请求中的公网通信地址是第二公网通信地址的情况下，as确定建链请求端的身份合法。

在本实施例的另一些示例中，as不仅会根据建链请求中的公网通信地址对建链请求端的身份进行认证，而且还会根据建链请求中建链请求端的私网通信地址进行认证。在这种情况下，sbc根据来自终端的业务响应向as发送响应消息时，还会在响应消息中携带终端的私网通信地址。这样当as接收到建链请求之后，除了对建链请求中的公网通信地址进行认证以外，还可以结合建链请求中的私网通信地址进行认证，判断该建链请求中的私网通信地址是否是响应消息中携带的私网通信地址。如果as判断建链请求中的公网通信地址与私网通信地址均与响应消息中的一致，则可以确认建链请求端就是业务响应端。

在as确定建链请求是由之前的业务响应端发起时，as可以向终端发送表征肯定的建链响应。

在终端接收到建链响应之后，可以基于第一公网通信地址同as建立起公网通信链路，随后在该通信链路上接收as的消息推送，实现对应的数据传输业务。

本发明实施例提供的业务实现方案，终端和as可在会话协商阶段获取的对端的公网通信地址，建立用于业务数据传输的通信链路，从而避免业务数据传输过程中需要sbc中转的问题。更进一步的，在本实施例提供的业务实现方案中，as在接收到建链请求之后，可以对建链请求端的身份进行验证，保证与自己建立基于公网通信链路的是之前协商过的终端，提升了应用服务器的安全性。

可以理解的是，实施例六中虽然仅介绍了as作为业务请求端，终端作为业务响应端时的业务实现方案，不过本领域技术人员可以理解的是，实施例六中方案的实现原理也适用于as作为业务响应端，接收终端的请求的情景。

实施例七：

本实施例先提供一种存储介质，该存储介质中可以存储有一个或多个可供一个或多个处理器读取、编译并执行的计算机程序，在本实施例中，该存储介质可以存储业务请求程序、业务协商程序和业务响应程序中的至少一个，其中业务请求程序可供一个或多个处理器执行实现前述实施例一至三中介绍的任意一种业务请求方法的步骤。业务协商程序可供一个或多个处理器执行实现前述实施例一至三中介绍的任意一种业务协商方法的步骤。业务响应程序可供一个或多个处理器执行实现前述实施例一至三中介绍的任意一种业务响应方法的步骤。

本实施例中还提供一种网络设备，请参见图9：网络设备90包括处理器91、存储器92以及用于连接处理器91与存储器92的通信总线93，其中存储器92可以为前述存储有业务请求程序、业务协商程序和业务响应程序中至少一个的存储介质：

如果存储器92中存储有业务请求程序，则处理器91可以读取业务请求程序，进行编译并执行实现实施例一至三中介绍的任意一种业务请求方法的步骤。该网络设备可以是终端或者是as，网络设备90实现实施例一至三中业务请求方法的细节可以参见前述实施例的介绍，这里不再赘述。

如果存储器92中存储有业务协商程序，则处理器91可以读取业务协商程序，进行编译并执行实现实施例一至三中介绍的任意一种业务协商方法的步骤。该网络设备可以是sbc，网络设备90实现实施例一至三中业务协商方法的细节可以参见前述实施例的介绍，这里不再赘述。

如果存储器92中存储有业务响应程序，则处理器91可以读取业务响应程序，进行编译并执行实现实施例一至三中介绍的任意一种业务响应方法的步骤。该网络设备可以是终端或者是as，网络设备90实现实施例一至三中业务响应方法的细节可以参见前述实施例的介绍，这里不再赘述。

本实施例还提供一种通信系统，请参见图10，该通信系统10包括终端101、sbc102以及as103，其中，sbc102是图9中处理器可以执行业务协商程序，实现业务协商方法的网络设备。在一种示例中，终端101是图9中处理器可以执行业务请求程序，实现业务请求方法的网络设备，as103是图9中处理器可以执行业务响应程序，实现业务响应方法的网络设备。

在本实施例的另一种示例中，终端101是图9中处理器可以执行业务响应程序，实现业务响应方法的网络设备，as103是图9中处理器可以执行业务请求程序，实现业务请求方法的网络设备。

不过，在更多的示例当中，终端101的处理器既可以执行业务请求程序，实现业务请求方法，也可以执行业务响应程序，实现业务响应方法。同时，as103的处理器也是既可以执行业务请求程序，实现业务请求方法，又可以执行业务响应程序，实现业务响应方法。

本实施例提供的网络系统，在业务会话协商阶段，sbc设备可以根据业务请求端的请求向业务响应端发送携带业务请求端第一公网通信地址的业务请求，并且根据业务响应端的响应向业务请求端发送携带业务响应端的第二公网通信地址的响应消息，从而让业务请求端和业务响应端可以基于第一公网通信地址和第二公网通信地址和第一公网通信地址建立公网通信链路，使得业务请求端和业务响应端在业务数据传输阶段不必依赖于sbc进行业务数据中转，从而减小业务数据传输的时延，提升业务数据传输的速率，提升终端侧用户的业务体验。

实施例八：

本实施例将在实施例七的基础上继续对网络系统以及网络系统中实现业务的过程进行介绍，请参见图11示出的网络系统11的结构示意图：

网络系统11中包括终端111、nat设备112、sbc113以及as114，其中，终端111与nat设备112还是通过私网ip地址进行通信，而nat设备112与sbc113之间则基于公网ip地址进行通信，sbc113与as114之间基于私网ip地址通信。另外，在本实施例提供的网络系统当中，当终端111与as之间需要进行业务时，在经过会话协商之后，nat设备112与as114之间可以基于公网ip地址进行通信。

示例1：

图12示出的是在msrp协议下，终端作为业务请求端向imas发起业务流程图：

s1201：终端向sbc发起文件传输请求(invite)。

在媒体协商的消息体sdp中包含了终端的私网地址，以及本次请求的服务类型。

s1202：sbc判断文件传输服务支持媒体直连后，将终端的私网ip地址改为终端在nat设备转换之后的公网ip地址，转发请求给cscf。

s1203：imas从cscf处接收invite请求，并提取出终端的公网地址信息。

s1204：imas判断文件传输服务支持媒体直连，在会话响应中携带imas的公网地址，并转发会话响应给cscf。

s1205：cscf转发响应给sbc。

s1206：sbc判断本次业务会话支持媒体直连，不需要更改响应中的媒体面地址信息，转发会话响应给终端。

s1207：终端发送ack请求给sbc确认会话建立。

s1208：sbc转发ack请求给cscf。

s1209：cscf转发ack请求给imas。

s1210：终端与imas建立连接。

终端向imas发起tcp连接建立请求，imas检查终端发起的地址是否与会话协商过程中的媒体面地址一致，确定一致后，允许建立tcp连接。

s1211：终端向imas发送msrp消息。

终端发送的msrp消息中包含了msrp路径信息。

s1212：imas返回msrp200ok响应。

msrp200ok响应表示imas接收到msrp数据信息。

示例2：

图13示出的是在msrp协议下，终端作为业务响应端，imas作为业务请求端的业务流程图，假定msrp协议为例终端接收文件传输业务的处理流程。

s1301：imas发起文件传输请求。

imas准备向终端发起文件传输请求，判断文件传输服务支持媒体直连，在请求的媒体协商消息体sdp中包含了imas媒体处理单元的公网地址，以及本次请求的服务类型。

s1302：cscf转发业务请求给sbc。

s1303：sbc判断业务请求中的文件传输服务支持媒体直连，不修改业务请求中的媒体面地址，并将请求转发给终端。

s1304：终端在200ok响应中携带自身的私网地址。

s1305：sbc判断文件传输服务支持媒体直连，在会话响应中将终端的私网地址修改为终端的公网地址，转发会话响应给cscf。

s1306：cscf转发响应给imas。

s1307：imas判断本次业务会话支持媒体直连，记录响应中终端的媒体面ip地址。

s1308：imas发送ack请求给cscf确认会话建立。

s1309：cscf转发ack请求给sbc。

s1310：sbc转发ack请求给终端。

s1311：终端与imas建立连接。

终端向imas发起tcp连接建立请求，imas检查终端发起的地址是否与会话协商过程中的媒体面地址一致，确定一致后，允许建立tcp连接。

s1312.imas向终端发送msrp消息。

imas发送的msrp消息中包含了msrp路径信息。

s1313：终端返回msrp200ok响应。

msrp200ok响应表示终端接收到msrp数据信息。

示例3：

图14给出了网络系统的安全维护，以msrp协议为例描述了本发明中提供的网络系统如何防止恶意终端(例如终端2)发起媒体攻击：

s1401：imas发起文件传输请求。

imas准备向终端1发起文件传输请求，首先，imas判断文件传输服务是否支持媒体直连。在确定判断结果为是的情况下，imas在请求的媒体协商消息体sdp中携带imas自己的公网ip地址以及本次请求的服务类型。

s1402：cscf转发业务请求给sbc。

s1403：sbc确定业务请求中的文件传输服务支持媒体直连，不修改业务请求中的媒体面地址，并将请求转发给终端1。

s1404：终端1在200ok响应中携带自身的私网地址。

s1405：sbc确定文件传输服务支持媒体直连，在会话响应中将终端1的私网地址修改为终端1的公网ip地址，转发会话响应给cscf。

s1406：cscf转发响应给imas。

s1407：imas判断本次业务会话支持媒体直连，记录响应中终端1的媒体面ip地址。

s1408：imas发送ack请求给cscf确认会话建立。

s1409：cscf转发ack请求给sbc。

s1410：sbc转发ack请求给终端1。

s1411：终端2发起媒体攻击。

终端2向imas发起tcp连接建立请求，imas检查终端2发起的地址是否与会话协商过程中的媒体面地址一致，发现不一致，禁止建立与终端2建立tcp连接。

s1412：imas向终端2拒绝tcp连接建立，返回tcprst，但不释放会话，等待终端1建立媒体连接。

显然，本领域的技术人员应该明白，上文中所公开方法中的全部或某些步骤、系统、装置中的功能模块/单元可以被实施为软件(可以用计算装置可执行的程序代码来实现)、固件、硬件及其适当的组合。在硬件实施方式中，在以上描述中提及的功能模块/单元之间的划分不一定对应于物理组件的划分；例如，一个物理组件可以具有多个功能，或者一个功能或步骤可以由若干物理组件合作执行。某些物理组件或所有物理组件可以被实施为由处理器，如中央处理器、数字信号处理器或微处理器执行的软件，或者被实施为硬件，或者被实施为集成电路，如专用集成电路。这样的软件可以分布在计算机可读介质上，由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，计算机可读介质可以包括计算机存储介质(或非暂时性介质)和通信介质(或暂时性介质)。如本领域普通技术人员公知的，术语计算机存储介质包括在用于存储信息(诸如计算机可读指令、数据结构、程序模块或其他数据)的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于ram,rom,eeprom、闪存或其他存储器技术、cd-rom，数字多功能盘(dvd)或其他光盘存储、磁盒、磁带、磁盘存储或其他磁存储装置、或者可以用于存储期望的信息并且可以被计算机访问的任何其他的介质。此外，本领域普通技术人员公知的是，通信介质通常包含计算机可读指令、数据结构、程序模块或者诸如载波或其他传输机制之类的调制数据信号中的其他数据，并且可包括任何信息递送介质。所以，本发明不限制于任何特定的硬件和软件结合。

以上内容是结合具体的实施方式对本发明实施例所作的进一步详细说明，不能认定本发明的具体实施只局限于这些说明。对于本发明所属技术领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干简单推演或替换，都应当视为属于本发明的保护范围。