CN1983921B - 一种端到端媒体流安全的实现方法及系统 - Google Patents

Abstract

本发明公开了一种端到端媒体流安全的实现方法，该方法由主叫用户终端发起会话请求消息，并在该消息中指示本用户终端是否支持媒体流保护能力；网络实体接收到所述会话请求消息后确定本次会话是否需要媒体流保护，并在所述会话请求消息中携带相应指示；以及被叫用户终端接收到会话请求消息后，若判断主叫用户终端支持媒体流保护能力、本次会话需要媒体流保护并且本被叫用户终端支持媒体流保护能力，则对本次会话实施端到端媒体流安全保护，否则，不对本次会话实施端到端媒体流安全保护。本发明还同时公开了一种通信系统及终端设备。

Description

一种端到端媒体流安全的实现方法及系统

技术领域

本发明涉及通信技术领域，尤其涉及一种端到端媒体流安全的实现方法及系统。

背景技术

IP多媒体子系统(IMS)网络中的媒体层面的网络安全方案大致可以分为两类：一类是非端到端(或者端到网络)的媒体流保护，其另一类是端到端的媒体流保护。

非端到端的媒体流保护的网络模型如图1A所示，端到端的媒体流保护的网络模型如图1B所示，其中，RTP Proxy对于3GPP可以是GGSN/SGSN，对于TISPAN可以是BGF，对于3GPP2可以是PDSN。

非端到端的媒体流保护通常需要中间实体反复地进行加密-解密-加密-解密操作，因而可能影响通话质量。

端到端的媒体流保护方案是密钥由网络侧实体分配到主叫终端、被叫终端。通话时由主叫终端加密，被叫终端解密，不需要一些中间的实体(例如RTP-Proxy)来反复执行解密-加密-解密-加密...过程，因此效率较高，通话质量较高。

另外，在电信部门的监管中存在合法监听业务。合法监听是指(国家或地区)安全机构出于执法的需要，对某个用户或某个通信过程进行监听。监听包括信令层面监听和媒体层面监听。对于信令层面的监听，需要输出监听对象的监听相关信息；对于媒体层面的监听，需要输出监听对象的通信内容(即媒体流)。

在3GPP中，用于传送信令层面的监听相关信息的合法监听架构如图2A所示，用于传送信令层面的监听相关信息及媒体层面的监听对象的通信内容的合法监听架构如图2B所示。其中，P-CSCF/S-CSCF和GSN通过X11接口可以知道要合法监听的用户URI，GSN通过X2接口携带媒体流安全算法和密钥到监听中心，GSN通过X3接口可以将媒体流传送到合法监听监控中心(LEMF)。这样监听中心就可以完成对加密的媒体流的合法监听。

由于现有的端到端媒体流保护只考虑到通讯双方都支持媒体流保护的情况，没有考虑到其中一方甚至双方都不支持媒体流保护的情况。如，主叫支持媒体流保护，被叫不支持媒体流保护，那么就可能出现主叫对媒体流加密，而被叫因为不支持媒体流保护而无法识别收到的媒体流，导致不能进行会话的情况发生。另外，合法监听一般来说是直接监听没有保护的媒体流，因此，在对媒体流进行端到端保护后如何分发密钥给监管实体，以保证合法监听也成为需要解决的问题。

发明内容

本发明提供一种端到端媒体流安全的实现方法及系统，以解决现有技术中在实现端到端媒体流安全时会话双方中的一方用户终端不支持媒体流保护时导致不能进行会话的问题；进一步的，解决因实施端到端媒体流保护导致合法监听存在困难的问题。

本发明提供以下技术方案：

一种端到端媒体流安全的实现方法，包括如下步骤：

主叫用户终端发起会话请求消息，并在该会话消息中携带指示本用户终端是否支持媒体流保护能力的标识；

网络实体接收到所述会话请求消息后确定本次会话是否需要媒体流保护，并在所述会话请求消息中携带相应指示；以及

被叫用户终端接收到会话请求消息后，若判断主叫用户终端支持媒体流保护能力、本次会话需要媒体流保护并且本被叫用户终端支持媒体流保护能力，则对本次会话实施端到端媒体流安全保护，否则，放弃对本次会话实施端到端媒体流安全保护。

其中：

被叫用户终端在向主叫用户终端返回的响应消息中携带本被叫用户终端是否支持媒体流保护能力的指示，使主叫用户终端能够确定本次会话是否能够实施端到端媒体流安全保护。

网络实体仅在主叫用户终端支持媒体流保护能力并且确定本次会话需要媒体流保护时，为本次会话分配媒体流安全密钥并携带在会话请求消息中。

仅主叫用户终端不支持媒体保护能力，并且本次会话需要媒体流保护时，由被叫用户终端决定是否继续本次会话。

仅被叫用户终端不支持媒体保护能力，并且本次会话需要媒体流保护时，由主叫用户终端决定是否继续本次会话。

主叫用户终端设备在所述会话请求消息中进一步携带媒体流安全算法列表；并且，被叫用户终端在确定会话双方用户终端均支持媒体流保护能力和本次会话需要媒体流保护时，从所述列表中选择本用户终端支持的媒体流安全算法并携带在向主叫用户终端返回的响应消息中。

在会话双方用户终端均支持媒体流保护能力和本次会话需要媒体流保护时，如果需要对主叫侧或/和被叫侧的用户进行监听，主叫侧或/和被叫侧的网络实体进一步将分配的媒体流安全密钥和最终端选择的媒体流安全算法传送到对应的监管功能实体。

所述监管功能实体将所述媒体流安全密钥和最终端选择的媒体流安全算法传送到监听中心，用于对主叫侧或/和被叫侧的媒体流进行监听。或者，

所述监管功能实体利用所述媒体流安全密钥和最终端选择的媒体流安全算法对会话的媒体流进行解密，并将解密后的媒体流传送到对应的监听中心。

所述密钥具有有效期，在该效期内所述密钥用于多次会话。

在会话请求消息中扩展SIP消息头域或新增指示是否需要对媒体流进行保护。

一种通信系统，包括：

用于发起会话请求消息，并在该会话消息中携带指示本用户终端是否支持媒体流保护能力的标识的第一用户终端；

用于根据所述会话请求消息后确定本次会话是否需要媒体流保护，并在所述会话请求消息中携带相应指示的网络实体；

用于接收到会话请求消息后，若判断第一用户终端支持媒体流保护能力、本次会话需要媒体流保护并且本用户终端支持媒体流保护能力，则对本次会话实施端到端媒体流安全保护，否则，放弃对本次会话实施端到端媒体流安全保护的第二用户终端。

所述的通信系统还包括：

用于接收媒体流安全密钥和媒体流安全算法，利用该密钥和算法解密媒体流，或者将该密钥监和算法传送到其他设备用于解密媒体流监管功能实体。

一种终端设备，包括：

发送模块，用于发起会话请求消息并在该消息中指示本用户终端设备是否支持媒体流保护能力；

接收模块，用于接收会话请求消息，并且仅在根据会话消息判断发送该会话请求消息的终端设备支持媒体流保护能力、本次会话需要媒体流保护并且本终端设备支持媒体流保护能力，确定对本次会话实施端到端媒体流安全保护。

所述发送模块进一步在会话请求消息中携带媒体流安全算法列表。

所述接收模块在确认需要对本次会话实施端到端媒体流安全保护后，所述发送模块从接收到的媒体流安全算法列表中选择支持的媒体流安全算法并携带在发送的响应消息中。

本发明在会话消息中携带终端是否支持媒体流保护能力的信息，使通信双方能够及时获知对端是否支持媒体流保护能力，从而避免了在实施端到端媒体流保护时，因一方支持媒体流保护能力而另一端不支持导致不能进行会话的问题；本发明在需要实施端到端媒体流保护时，可以根据监听的需要将媒体流安全算法和密钥发送到监听实体，因而可以实现合法监听，方便电信的监管。

附图说明

图1A为非端到端的媒体流保护模型示意图；

图1B为端到端的媒体流保护模型示意图；

图2A为IMS中传送信令层面的监听相关信息的模型示意图；

图2B为IMS中传送信令层面和媒体层面的监听相关信息的模型示意图；

图3A为本发明中终端设备的结构示意图；

图3B为本发明中一种实现端到端媒体流的系统结构示意图；

图4为本发明中实现端到端媒体流保护的主要流程图；

图5、图6分别为本发明中只有主叫用户终端或者被叫用户终端一方不支持媒体保护能力时，不需要端到端媒体流保护的流程图；

图7为本发明中主叫和被叫用户终端均支持媒体保护能力时，主叫侧分配密钥的端到端媒体流保护的流程图；

图8为本发明中主叫和被叫用户终端均支持媒体保护能力时，被叫侧分配密钥的端到端媒体流保护的流程图；

图9为本发明中主叫和被叫用户终端均不支持媒体保护能力时，不需要端到端媒体流保护的流程图；

图10为本发明中会话过程中终端切换引起的媒体流保护重新协商的流程图；

图11为本发明中实现合法监听的流程图。

具体实施方式

本实施例主要以IMS网络为例进行说明。

本发明在主叫用户终端发起的会话消息中携带终端是否支持媒体流保护能力的标识，并结合现有会话建立过程中网络实体确定的本次会话是否需要媒体流保护的标识，接收到会话消息的被叫用户终端根据所述标识和本终端是否支持媒体流保护能力确定本次会话是否可以实施端到端媒体流保护；进一步的，被叫用户终端在向主叫终端返回的响应消息中携带本终端是否支持媒体流保护能力，使会话双方都能确定本次会话是否能够实施媒体流安全保护，从而避免会话过程因一方终端不支持媒体流保护能力而导致不能进行会话的问题。

主叫用户终端在会话消息中进一步携带媒体流安全算法，被叫用户终端在确定会话双方用户终端均支持媒体流保护能力和本次会话需要媒体流保护时，从所述列表中选择本用户终端支持的媒体流安全算法并携带在向主叫用户终端返回的响应消息中，从而使会话双方用户终端能够及时协商保护媒体流的加解密算法。

本发明中所称的媒体流安全算法包括完整性保护算法和加密算法，相应的媒体流安全密钥包括完整性保护密钥和加密密钥。

较佳的方式是，在会话消息中携带媒体流保护能力集，该能力集可包括但不限于：终端是否支持媒体流保护能力、本次会话是否需要媒体流保护、完整性保护算法列表、加密算法列表、完整性密钥、加密密钥等。其中终端是否支持媒体流保护能力、完整性保护算法、加密算法由终端侧决定，本次会话是否需要媒体流保护是由网络实体根据用户签约数据以及用户签约的业务数据共同决定。完整性密钥、加密密钥由网络实体管理并分发，如IMS网络中的业务呼叫会话控制功能(S-CSCF)实体或者由其他网络实体分发，也可以由独立的密钥分配中心实体来管理并分发，然后发给IMS的相应的网络实体。

可以通过扩展SIP消息头域或新增参数来指示是否需要对媒体流进行保护。

本发明中终端设备30的结构如图3A所示，包括接收处理模块300和发送处理模块310。

发送处理模块310，用于发起会话请求消息并在该消息中指示本用户终端是否支持媒体流保护能力；进一步的，在会话请求消息中携带支持的媒体流安全算法列表。

接收处理模块300，在接收到会话请求消息后，根据本用户终端和发送该会话请求消息的终端是否支持媒体流保护能力的情况作进一步处理：

1、如果双方都支持，则表明需要建立端到端的媒体流保护。

2、如果本方支持，另一方不支持，则不需要建立端到端的媒体流保护。由本方决定是拒绝会话还是继续会话。

3、如果本方不支持，另一方支持，则不需要建立端到端的媒体流保护。

4、如果双方都不支持，则不需要建立端到端的媒体流保护，继续进行普通的会话。

根据这些情况，调用发送处理模块310来给对方发送响应消息。

本发明的系统结构示意图如图3B所示，图中未示出监管功能实体，可以参数图2A、图2B所示。

参阅图4(结合图3B)所示，本发明实现媒体流端到端保护的主要流程如下：

步骤1至步骤2：主叫UE1在会话请求消息中携带媒体流保护能力集参数，其中包括终端是否支持媒体流保护能力、完整性保护算法列表、加密算法列表。

步骤3至步骤8：主叫S-CSCF1收到会话请求消息后，根据用户签约数据以及应用服务器AS1中的业务数据决定主叫本次会话是否需要媒体流保护，如果需要，并且会话请求中的信息表明主叫终端支持媒体流保护能力，则分配相应的完整性密钥和加密密钥，否则，不分配完整性密钥和加密密钥；然后更新媒体流保护能力集并发送到被叫侧.

步骤9至步骤14：S-CSCF2根据收到的主叫侧的媒体流保护能力集，再根据被叫UE2的签约数据以及AS2的业务数据来决定被叫本次会话是否需要媒体流保护。如果需要，并且会话请求中的信息表明主叫终端支持媒体流保护能力和主叫侧没有分配密钥，则分配相应的完整性密钥和加密密钥；然后，更新媒体流保护能力集并发送到被叫P-CSCF2。

步骤15至步骤16：P-CSCF2用被叫注册中产生的加密密钥将这些信息加密发送到被叫UE2。被叫UE2利用密钥解密信息后，如果被叫UE2支持媒体流保护能力，则选择一个自己支持的完整性保护算法、加密算法，完成算法协商，否则，不作选择。

步骤17至步骤19：被叫UE2在能力集中携带本终端是否支持媒体流保护能力、协商后的完整性保护算法和加密算法、密钥等信息，并通过响应消息将更新过的媒体流保护能力集发送到主叫侧S-CSCF1。

步骤20至步骤21：主叫侧S-CSCF1(也可以由主叫侧P-CSCF决定是否需要媒体流保护，并以此决定是否需要将这些信息加密发送到UE)根据收到的会话响应消息最终决定本次会话是否确实需要媒体流保护，并将更新过的媒体流保护能力集发送到主叫P-CSCF1；该P-CSCF1用主叫注册中产生的加密密钥将这些信息加密发送到主叫UE1。这样就完成了主、被叫媒体流保护算法协商和密钥分发。

根据主叫侧终端是否支持媒体流保护能力、本次会话是否需要媒体流保护以及被叫侧终端是否支持媒体流保护能力的不同结果。如下表所示的几种典型组合情况(该表中仅为举例说明，并没有穷尽所有的组合情况)：

参阅图5所示，仅被叫用户终端支持媒体流保护能力，不需要建立端到端的媒体流保护，会话是否继续由被叫终端决定。

步骤1至步骤2：主叫UE1在会话请求消息中携带的媒体流保护能力集中的“终端是否支持媒体流保护能力”为否，或者不携带媒体流保护能力集。

步骤3至8：主叫侧S-CSCF1发现主叫终端不支持媒体流保护能力，因此无论根据用户签约数据以及AS中的业务数据发现本次会话是否需要媒体流保护，都不需要分配完整性密钥和加密密钥，将媒体流保护能力集中的“终端是否支持媒体流保护能力”设置为“否”，以及“本次会话是否需要媒体流保护”设置为否，发到被叫侧S-CSCF2。

步骤9至步骤14：被叫侧S-CSCF2虽然根据用户签约数据以及AS中的业务数据发现本次会话需要媒体流保护，但是由于主叫终端不支持媒体流保护能力，因此知道本次会话不能够使用媒体流保护，也不需要分配完整性密钥和加密密钥。被叫侧S-CSCF2把媒体流保护能力集中的“本次会话是否需要媒体流保护”设置成“是”，但是完整性密钥和加密密钥为空，发给被叫P-CSCF2。

步骤15至步骤16：P-CSCF2用被叫注册中产生的加密密钥将信息加密发送到被叫UE2；被叫UE2解密信息后，虽然本终端支持媒体流保护能力，但发现主叫UE1不支持，因此，确定本次会话不需要端到端的媒体流保护。

如果被叫UE2决定拒绝本次会话，则执行步骤17-1至步骤17-5，向主叫侧返回拒绝会话的响应消息。如果被叫UE2决定正常接续，则执行步骤18-1至步骤18-6，向主叫侧返回响应消息。

参阅图6所示，仅主叫用户终端支持媒体流保护能力，不需要建立端到端的媒体流保护，会话是否继续由主叫终端决定。

步骤1至步骤2：主叫UE1在会话请求消息中携带的媒体流保护能力集的“终端是否支持媒体流保护能力”为是。

步骤3至步骤8：主叫侧S-CSCF1发现主叫终端支持媒体流保护能力，且根据用户签约数据以及AS中的业务数据发现本次会话需要媒体流保护，主叫侧S-CSCF1分配完整性密钥和加密密钥，更新“媒体流保护能力集”后将会话请求发到被叫侧S-CSCF2。

步骤9至步骤14：被叫侧S-CSCF2发现主叫侧本次会话需要媒体流保护，并且已经分配完整性密钥和加密密钥，根据用户签约数据以及AS中的业务数据更新“媒体流保护能力集”的“本次会话是否需要媒体流保护”标识，发送到被叫侧P-CSCF2。

步骤15：被叫侧P-CSCF2用在注册过程中生成的UE2和P-CSCF2之间的加密密钥加密“媒体流保护能力集”发送到被叫侧UE2。

步骤16至步骤19：被叫侧UE2利用密钥解密信息后，获知本次会话需要媒体流保护，但发现本终端不支持媒体流保护能力，在会话响应中将“媒体流保护能力集”的“终端是否支持媒体流保护能力”更新为否，发送到主叫侧。

步骤20至步骤22：主叫侧S-CSCF1据此知道本次会话不能够使用媒体流保护，将此响应通过P-CSCF2转发到主叫UE1.

步骤23、主叫UE1解密信息后，虽然本终端支持媒体流保护能力，但发现被叫UE2不支持，因此，确定本次会话不需要端到端的媒体流保护。

如果主叫UE1决定拒绝本次会话，则执行步骤24-1至步骤24-6，向被叫侧发送会话取消消息。如果主叫UE1决定正常接续，则执行步骤25-1至步骤25-6，向被叫侧发送会话响应消息。

参阅图7所示，主被叫双方都支持媒体流保护能力，由主叫侧S-CSCF1分配完整性密钥和加密密钥，建立端到端的媒体流保护。

步骤1至步骤2：主叫UE1在会话请求消息中携带的媒体流保护能力集的“终端是否支持媒体流保护能力”为是。

步骤3至步骤8：主叫侧S-CSCF1发现主叫终端支持媒体流保护能力，且根据用户签约数据以及AS中的业务数据发现本次会话需要媒体流保护，主叫侧S-CSCF1分配完整性密钥和加密密钥，更新媒体流保护能力集后将会话请求发到被叫侧S-CSCF2。

步骤9至步骤14：被叫侧S-CSCF2发现主叫侧本次会话需要媒体流保护，并且已经分配完整性密钥和加密密钥，根据用户签约数据以及AS中的业务数据更新媒体流保护能力集的“本次会话是否需要媒体流保护”，并发送到被叫侧P-CSCF2。

步骤15：P-CSCF2用在注册过程中生成的UE2和P-CSCF2之间的加密密钥加密媒体流保护能力集发送到被叫侧UE2。

步骤16至步骤19：被叫侧UE2解密信息后，发现主叫UE1支持和本终端均支持媒体流保护能力并且本次会话需要媒体保护，知道可以建立一个端到端的媒体流会话。因此，在主叫侧的完整性算法和加密列表中选择自己支持的一个，并保存完整性密钥和加密密钥，将媒体流保护能力集中相应的算法更新，并通过响应消息发送到主叫侧。

步骤20至21：主叫侧S-CSCF1根据媒体流保护能力集知道本次会话能够使用媒体流保护，将媒体流保护能力集转发到主叫侧P-CSCF1。P-CSCF1用在注册过程中生成的UE1和P-CSCF1之间的加密密钥加密媒体流保护能力集发送到主叫侧UE1。

步骤22：主叫侧UE1知道可以建立一个端到端的媒体流会话。继续会话交互，直到端到端的媒体流保护会话建立。

参阅图8所示，主被叫双方都支持媒体流保护能力，由被叫侧S-CSCF2分配完整性密钥和加密密钥，建立端到端的媒体流保护。该处理流程与图7所示流程的区别在于：主叫侧S-CSCF1发现主叫终端支持媒体流保护能力，且根据用户签约数据以及AS中的业务数据发现本次会话不需要媒体流保护，主叫侧S-CSCF1并不分配完整性密钥和加密密钥，并将媒体流保护能力集中的本次会话是否需要媒体流保护设置为否，并将会话请求发到被叫侧。然后，被叫侧S-CSCF2根据被叫用户签约数据以及AS中的业务数据发现本次会话需要媒体流保护，并且主叫UE1支持媒体流保护能力，被叫侧S-CSCF2分配完整性密钥和加密密钥，并更新媒体流保护能力集，并发送到被叫侧P-CSCF2。其余的处理过程与图7同理，不再赘述。

参阅图9所示，主、被叫用户终端都不支持媒体流保护能力，不需要建立端到端的媒体流保护。

主叫UE1在会话请求消息中携带的媒体流保护能力集中的“终端是否支持媒体流保护能力”为否，或者不携带媒体流保护能力集；主叫侧S-CSCF1和被叫侧S-CSCF2在获知主叫侧UE1不支持媒体流保护能力时，即使根据用户的签约数据确定本次会话需要媒体流保护，也不再分配完整性密钥和加密密钥；被叫UE2获知本终端和主叫UE1均不支持媒体流保护能力，因此，本次会话不需要端到端的媒体流保护.相关的详细处理请参阅上述的描述.

在端到端媒体流保护的会话过程中，由于终端切换引起的媒体流保护重新协商过程如图10所示，会话过程中如果终端切换，新终端发起会话请求INVITE进行媒体流保护算法和密钥的重新协商过程，此时另一侧直接回200，因此协商后的新的参数要在200中返回。其处理过程与图7所示的流程同理，不再赘述。

对端到端保护的媒体流进行合法监听的模型请参阅图2B所示，其中RTP-Proxy对于3GPP是GGSN/SGSN，对于TISPAN是BGF，对于3GPP2是PDSN。

由于在建立会话过程中主、被叫UE已经协商好了完整性保护算法、加密算法，而且合法监听也就是RTP-Proxy将收到的媒体流复制一份到监听中心，因此如果需要合法监听其中某一用户，P-CSCF只能将上述协商好后的完整性保护算法和加密算法以及相应密钥也发送到相应的RTP-Proxy实体，也就是说P-CSCF与RTP-Proxy之间不需要再进行算法协商过程。

参阅图11所示，如果需要合法监听被叫用户，被叫侧P-CSCF2将协商好后的完整性保护算法和加密算法以及相应密钥发送到被叫侧的RTP-Proxy实体。如果需要合法监听主叫用户，主叫侧P-CSCF1将协商好后的完整性保护算法和加密算法以及相应密钥发送到主叫侧的RTP-Proxy实体。RTP-Proxy通过X2接口携带端到端保护的媒体流安全算法和密钥到监听中心，通过X3接口可以将端到端保护的媒体流传送到监听中心。这样监听中心就可以完成对端到端保护的媒体流的合法监听(具体的监听机制可以采用现有技术)。另外，X2接口也可以不携带端到端保护的媒体流安全算法和密钥，RTP-Proxy可以将复制的媒体流解密后再通过X3接口发送到监听中心，同样可以达到合法监听的目的。

P-CSCF和RTP-Proxy之间可以通过扩展Gq/Go(TISPAN中为Gq’/Ia)接口功能来发送上述协商好的保护算法以及相应密钥，或者采取其他方式发送。发送可以采用明文或者加密方式进行。

对于上述所有实例，S-CSCF和AS分别根据用户的签约数据和业务数据决定是否需要对媒体流进行保护(只要其中一个实体确定需要对媒体流进行保护即可)，可以在上述示意流程中多个点进行，上述流程中描述的只是其中一种可能。另外，对于某些简单的呼叫情况，可能不需要AS来参与判断是否对媒体流进行保护，仅由S-CSCF判断即可，此时可以认为呼叫相关的AS功能嵌入在S-CSCF中。

另外，密钥有效期一般是基于每次会话生成的。每次会话结束后，密钥自动失效。在本发明中，密钥也可以存在一定的有效期，对于某些业务在密钥的有效期内，该密钥可以用于多次会话，即可以不需要每次会话都分配密钥。

本发明以S-CSCF分配媒体流密钥为例，也可以是IMS其他网络实体，或者专用的密钥分配中心实体分配管理媒体流密钥。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围.这样，倘若对本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内.

Claims (19)

1.一种端到端媒体流安全的实现方法，其特征在于，包括如下步骤：

主叫用户终端发起会话请求消息，并在该会话请求消息中携带指示本用户终端是否支持媒体流保护能力的标识；

网络实体接收到所述会话请求消息后确定本次会话是否需要媒体流保护，并在所述会话请求消息中携带相应指示；以及

被叫用户终端接收到会话请求消息后，若判断主叫用户终端支持媒体流保护能力、本次会话需要媒体流保护并且本被叫用户终端支持媒体流保护能力，则对本次会话实施端到端媒体流安全保护，否则，放弃对本次会话实施端到端媒体流安全保护。

2.如权利要求1所述的方法，其特征在于，被叫用户终端在向主叫用户终端返回的响应消息中携带本被叫用户终端是否支持媒体流保护能力的指示，使主叫用户终端能够确定本次会话是否能够实施端到端媒体流安全保护。

3.如权利要求1所述的方法，其特征在于，网络实体仅在主叫用户终端支持媒体流保护能力并且确定本次会话需要媒体流保护时，为本次会话分配媒体流安全密钥并携带在会话请求消息中。

4.如权利要求1所述的方法，其特征在于，主叫用户终端不支持媒体保护能力，并且本次会话需要媒体流保护时，由被叫用户终端决定是否继续本次会话。

5.如权利要求1所述的方法，其特征在于，被叫用户终端不支持媒体保护能力，并且本次会话需要媒体流保护时，由主叫用户终端决定是否继续本次会话。

6.如权利要求1至5任一项所述的方法，其特征在于，主叫用户终端设备在所述会话请求消息中进一步携带媒体流安全算法列表；并且，被叫用户终端在确定会话双方用户终端均支持媒体流保护能力和本次会话需要媒体流保护时，从所述列表中选择本用户终端支持的媒体流安全算法并携带在向主叫用户终端返回的响应消息中。

7.如权利要求6所述的方法，其特征在于，在会话双方用户终端均支持媒体流保护能力和本次会话需要媒体流保护时，如果需要对主叫侧或/和被叫侧的用户进行监听，主叫侧或/和被叫侧的网络实体进一步将分配的媒体流安全密钥和最终端选择的媒体流安全算法传送到对应的监管功能实体。

8.如权利要求7所述的方法，其特征在于，所述监管功能实体将所述媒体流安全密钥和最终端选择的媒体流安全算法传送到监听中心，用于对主叫侧或/和被叫侧的媒体流进行监听。

9.如权利要求7所述的方法，其特征在于，所述监管功能实体利用所述媒体流安全密钥和最终端选择的媒体流安全算法对会话的媒体流进行解密，并将解密后的媒体流传送到对应的监听中心。

10.如权利要求3所述的方法，其特征在于，所述密钥具有有效期，在该有效期内所述密钥用于多次会话。

11.如权利要求1所述方法，其特征在于，在会话请求消息中扩展SIP消息头域或新增指示是否需要对媒体流进行保护。

12.一种通信系统，其特征在于，包括：

用于发起会话请求消息，并在该会话消息中携带指示本用户终端是否支持媒体流保护能力的标识的第一用户终端；

用于根据所述会话请求消息后确定本次会话是否需要媒体流保护，并在所述会话请求消息中携带相应指示的网络实体；

用于接收到会话请求消息后，若判断主叫用户终端支持媒体流保护能力、本次会话需要媒体流保护并且本被叫用户终端支持媒体流保护能力，则对本次会话实施端到端媒体流安全保护，否则，放弃对本次会话实施端到端媒体流安全保护的第二用户终端。

13.如权利要求12所述的通信系统，其特征在于，所述第二用户终端在向第一用户终端返回的响应消息中携带本用户终端是否支持媒体流保护能力的指示，使第一用户终端能够确定本次会话是否能够实施端到端媒体流安全保护。

14.如权利要求12所述的通信系统，其特征在于，所述网络实体仅在第一用户终端支持媒体流保护能力并且确定本次会话需要媒体流保护时，为本次会话分配媒体流安全密钥并携带在会话请求消息中。

15.如权利要求12、13或14所述的通信系统，其特征在于，所述第一用户终端在所述会话请求消息中进一步携带媒体流安全算法列表；并且，所述第二用户终端在确定会话双方用户终端均支持媒体流保护能力和本次会话需要媒体流保护时，从所述列表中选择本用户终端支持的媒体流安全算法并携带在向第一用户终端返回的响应消息中。

16.如权利要求15所述的通信系统，其特征在于，还包括：

用于接收媒体流安全密钥和媒体流安全算法，利用该密钥和算法解密媒体流，或者将该密钥和算法传送到其他设备用于解密媒体流监管功能实体。

17.一种终端设备，其特征在于，包括：

发送模块，用于发起会话请求消息，并在该会话消息中携带指示本用户终端设备是否支持媒体流保护能力的标识；

接收模块，用于接收会话请求消息，并且仅在根据会话消息判断发送该会话请求消息的终端设备支持媒体流保护能力、本次会话需要媒体流保护并且本终端设备支持媒体流保护能力，确定对本次会话实施端到端媒体流安全保护。

18.如权利要求17所述的终端设备，其特征在于，所述发送模块进一步在会话请求消息中携带支持的媒体流安全算法列表。

19.如权利要求18所的终端设备，其特征在于，所述接收模块在确认需要对本次会话实施端到端媒体流安全保护后，所述发送模块从接收到的媒体流安全算法列表中选择支持的媒体流安全算法并携带在发送的响应消息中。

Images