CN101175074A - 一种实现端到端媒体流密钥协商的方法和*** - Google Patents

Abstract

本发明提供一种实现端到端媒体流密钥协商的方法和***，具体为：主叫终端发起呼叫，在呼叫过程中密钥应用服务器获得加密能力信息，根据获得的加密能力信息生成密钥，并分配给主叫终端和被叫终端。应用本发明方案，主叫终端和被叫终端自身并不生成密钥，而是由密钥应用服务器生成密钥，无需进行时钟同步，也无需PKI体系的支持，可以大大降低端到端媒体流密钥协商的复杂度，便于媒体流加密业务的推广。另外，由于密钥应用服务器可以由运营商控制，从而可以满足合法监听的实际需求。

Description

一种实现端到端媒体流密钥协商的方法和***

技术领域

本发明涉及媒体流加密技术，特别是涉及一种实现端到端媒体流密钥协商的方法和***。

背景技术

媒体流一般基于实时传输协议(RTP，Real-time Transport Protocol)进行传输，这里的所述的媒体流为音频媒体流、视频媒体流等。但由于RTP协议本身并不涉及安全问题，使媒体流在传输过程中存在泄密、被攻击等安全隐患。

为了加强媒体流在传输过程中的安全性，目前已提出多种生成和分配密钥的方法，即密钥协商方法。之后，终端可以利用分配的密钥实现媒体流的传输，达到安全传输媒体流的目的。

在现有技术中，密钥协商方法中有两种典型方法：一种是多媒体因特网密钥(MIKEY)公钥模式，另一种是MIKEY DH模式。

其中，MIKEY公钥模式的基本思想是：由主叫终端生成密钥和信封密钥，所述密钥用信封密钥进行加密，信封密钥再利用被叫终端证书的公钥进行加密，然后将加密后的密钥通过MIKEY协议发送到被叫终端，被叫终端解密后获得密钥，完成密钥协商过程。

在MIKEY公钥模式中，为了保障密钥协商过程的安全、顺利地进行，要求主叫终端和被叫终端之间进行时钟同步，并具备公钥基础设施(PKI)***的支持。而实际应用中，实现时钟同步以及PKI***支持比较复杂，不利于密钥协商的实现。比如：在电话会议中，存在多个需要传输媒体流的终端。如果要对多个终端的媒体流加密，则需要将多个终端进行时钟同步，这大大增加了密钥协商的困难。又比如：主叫终端和被叫终端为普通的移动终端，而由于移动终端数量大，将很难完成PKI***中证书管理等工作，无法顺利进行密钥协商。

MIKEY DH模式的基本思想是：在主叫终端和被叫终端分别生成DH值，再利用MIKEY协议交换彼此的DH值，然后根据双方的DH值产生密钥。

MIKEY DH模式也需要进行时钟同步，而且实现MIKEY DH模式非常复杂，计算量大，对终端性能要求高，不利于密钥协商的实现。

另外，实际应用中，运营商为了安全机构满足合法监听的要求，需要获得媒体流中的密钥。而现有技术中，只有参与交互的终端才可以获得密钥，这里所述参与交互的终端可能为主叫和被叫两个终端，也可能为多个终端，任何参与交互之外的第三方都无法获得密钥，即无法满足合法监听的要求。

发明内容

有鉴于此，本发明提供一种实现端到端媒体流密钥协商的方法，由密钥应用服务器生成密钥，避免PKI支持和时钟同步。

为了达到上述目的，本发明提出的技术方案为：

一种实现端到端媒体流密钥协商的方法，该方法为：

主叫终端发起呼叫，在呼叫过程中密钥应用服务器获得加密能力信息，根据获得的加密能力信息生成密钥，并分配给主叫终端和被叫终端。

本发明还提供一种实现端到端媒体流密钥协商的***，由密钥应用服务器生成密钥，避免PKI支持和时钟同步。

为了达到上述目的，本发明提出的技术方案为：

一种实现端到端媒体流密钥协商的***，该***包括：主叫终端、密钥管理子***和被叫终端；其中

所述主叫终端，用于将携带有自身加密能力信息的呼叫请求消息发送给密钥管理子***，并接收返回的密钥；

所述密钥管理子***，至少包括密钥应用服务器，用于生成密钥并分配给主叫终端和被叫终端；

所述被叫终端，用于接收由密钥管理子***分配的密钥。

综上所述，本发明提出的一种实现端到端媒体流密钥协商的方法和***，主叫终端和被叫终端自身不生成密钥，而是由密钥应用服务器生成密钥，也无需进行时钟同步，无需PKI体系的支持，可以大大降低端到端媒体流密钥协商的复杂度，便于媒体流加密业务的推广。另外，由于密钥应用服务器可以由运营商控制，从而可以满足合法监听的实际需求。

附图说明

图1是本发明方案流程图；

图2是方法实施例一的消息流示意图；

图3是方法实施例二的消息流示意图；

图4是方法实施例三的消息流示意图；

图5是***实施例一的基本结构示意图；

图6是***实施例二的基本结构示意图。

具体实施方式

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

本发明的基本思想是：在主叫终端发起针对被叫终端的呼叫流程中，由密钥应用服务器根据获得的加密能力信息生成密钥，并将生成的密钥在后续的呼叫流程中分配给主叫终端和被叫终端。

图1是本发明的流程图。如图1所示，本发明包括：

步骤101：主叫终端发起呼叫。

步骤102：在呼叫过程中密钥应用服务器获得加密能力信息，根据获得的加密能力信息生成密钥，并分配给主叫终端和被叫终端。

本发明中，密钥应用服务器可以在呼叫请求过程中获得加密能力信息，也可以在呼叫响应过程中获得加密能力信息。

如果在呼叫请求过程中获得加密能力信息，实现端到端媒体流密钥协商方法为：

步骤a：主叫终端向被叫终端发送呼叫请求消息，在呼叫请求过程中，密钥应用服务器获得并记录呼叫请求消息中主叫终端的加密能力信息。

步骤b：被叫终端向主叫终端返回呼叫响应消息，在返回的过程中，密钥应用服务器根据事先记录的主叫终端的加密能力信息生成密钥，再将密钥分配给主叫终端和被叫终端。

本发明所述的密钥可以由主叫侧密钥应用服务器生成，也可以由被叫侧密钥应用服务器生成。

如果由主叫侧密钥应用服务器生成密钥，则所述步骤a包括：

a1、主叫终端将携带有自身加密能力信息的呼叫请求消息发送给主叫侧密钥应用服务器，主叫侧密钥应用服务器记录主叫终端的加密能力信息。

a2、主叫侧密钥应用服务器将呼叫请求消息发送给被叫侧密钥应用服务器，由被叫侧密钥应用服务器记录主叫终端的加密能力信息，再转发给被叫终端。

实际中，在实现呼叫的信令链路上，存在主叫侧呼叫业务实体和被叫侧呼叫业务实体。当然，这里所述的主叫侧呼叫业务实体和被叫侧呼叫业务实体可以是两个不同的网元，也可以是具有主叫侧呼叫业务实体和被叫侧呼叫业务实体功能的同一个网元。针对主叫侧呼叫业务实体来说，步骤a1中所述将呼叫请求消息发送给主叫侧密钥应用服务器的方法具体为：

a11、主叫终端将呼叫请求消息先发送给主叫侧呼叫业务实体；

a12、主叫侧呼叫业务实体根据事先获得的过滤准则，对接收到的呼叫请求消息进行过滤处理，并将携带有加密能力信息的呼叫请求消息转发给主叫侧密钥应用服务器，主叫侧密钥应用服务器再记录呼叫请求消息中主叫终端的加密能力信息。

通常，主叫侧呼叫业务实体会接收到许多类型的消息，而只有满足携带有加密能力信息的呼叫请求消息时，主叫侧密钥应用服务器才被增加到信令链路中，之后，与当前呼叫相关的消息都将被转发到主叫侧密钥应用服务器。这样，就需要事先制定过滤准则来判别接收到的消息是否为携带有加密能力的呼叫请求消息，这里所述的过滤准则可以事先保存在主叫侧呼叫业务实体自身所在的归属用户服务器(HSS)中，并在用户注册时，从HSS下载到主叫侧呼叫业务实体。

相应地，所述步骤a2可以为：

a21、主叫侧密钥应用服务器通过主叫侧呼叫业务实体，将所述呼叫请求消息发送给被叫侧呼叫业务实体。

a22、被叫侧呼叫业务实体根据事先获得的过滤准则，对接收到的呼叫请求进行过滤处理，并将携带有加密能力信息的呼叫请求消息转发给被叫侧密钥应用服务器。

与主叫侧呼叫业务实体相似，被叫侧呼叫业务实体也会接收到许多类型的消息，而只有接收到携带有加密能力信息的呼叫请求消息时，被叫侧密钥应用服务器才被增加到信令链路中，之后，与当前呼叫相关的消息都将被转发到被叫侧密钥应用服务器。这样，也需要事先制定过滤准则来判别接收到的消息是否为携带有加密能力的呼叫请求消息。需要注意的是，这里所述的过滤准则是被叫侧的过滤准则，事先保存在被叫侧呼叫业务实体自身所在的HSS中，并在用户注册时，从HSS下载到被叫侧呼叫业务实体。

a23、被叫侧密钥应用服务器记录呼叫请求消息中主叫终端的加密能力信息，再通过被叫侧呼叫业务实体将呼叫请求消息转发给被叫终端。

当然，如果呼叫业务实体下的终端都具备加密能力，而且要求传输的媒体流必须进行加密，那么呼叫请求消息也可以不经过过滤处理，而是直接转发给密钥应用服务器即可。

本发明中，所述步骤b具体包括：

b1、被叫终端判断自身是否存在呼叫请求消息中所述加密能力信息，如果存在，则向被叫侧密钥应用服务器返回携带有自身加密能力信息的呼叫响应消息。

这里，所述被叫终端是通过被叫侧呼叫业务实体将呼叫响应消息转发给被叫侧密钥应用服务器。

b2、被叫侧密钥应用服务器根据呼叫响应消息中被叫终端的加密能力信息，以及记录的主叫终端的加密能力信息确定被叫终端支持加密，并将呼叫响应消息发送给主叫侧密钥应用服务器。

这里，被叫侧密钥应用器是通过被叫侧呼叫业务实体和主叫侧呼叫业务实体，将所述呼叫响应消息转发给主叫侧密钥应用服务器。

b3、主叫侧密钥应用服务器根据事先记录的主叫终端的加密能力信息生成密钥，并将密钥通过呼叫响应消息分配给主叫终端。

本步骤所述主叫终端的加密能力信息是指被叫终端也支持的加密能力信息。比如：主叫终端的加密能力信息包括AES-CM加密算法、128位或256位密钥长度等信息，而被叫终端的加密能力信息包括：AES-CM加密算法或AES-F8加密算法、128位密钥长度等信息，那么，密钥应用服务器就可以根据主叫终端和被叫终端相同的加密能力信息生成密钥，即根据AES-CM加密算法和128位密钥长度等信息生成密钥。

另外，本步骤所述主叫侧密钥应用服务器是通过主叫侧呼叫业务实体将呼叫响应消息转发给主叫终端。

b4、主叫终端再向被叫终端发送确认消息或信息更新消息，并在发送的过程中，由主叫侧密钥应用服务器将生成的密钥通过确认消息或信息更新消息发送给被叫终端。

这里，主叫终端发送确认消息还是信息更新消息与步骤a中发送的呼叫请求消息相关。如果所述呼叫请求消息的会话初始协议(SIP)消息头中包含预处理(precondition)协商，则被叫终端返回的呼叫响应消息为183消息，之后，主叫终端将向被叫终端发送信息更新消息，即UPDATE消息，所述的UPDATE消息主要用户更新服务质量(Qos)等信息，其具体情况属于与呼叫流程相关的现有技术，此处不再赘述。如果所述呼叫请求消息的SIP消息头中不包含precondition协商，则被叫终端返回的呼叫响应消息为200 OK消息，主叫终端再向被叫终端发送确认消息，即ACK消息。

以上是由主叫侧密钥应用服务器生成密钥的情况，如果需要由被叫侧密钥应用服务器生成密钥，则所述步骤a为：

主叫终端将携带有自身加密能力信息的呼叫请求消息发送给被叫侧密钥应用服务器，被叫侧密钥应用服务器记录所述主叫终端的加密能力信息，将转发给被叫终端。

这里，主叫终端是通过主叫侧呼叫业务实体、主叫侧密钥应用服务器和被叫侧呼叫业务实体将呼叫请求消息转发给被叫终端的。

相应地，所述步骤b具体包括：

B1、被叫终端判断自身是否存在呼叫请求消息中所述加密能力信息，如果存在，则向被叫侧密钥应用服务器返回携带有自身加密能力信息的呼叫响应消息。

这里，所述被叫终端是通过被叫侧呼叫业务实体将呼叫响应消息转发给被叫侧密钥应用服务器。

B2、被叫侧密钥应用服务器根据呼叫响应消息中被叫终端的加密能力信息，以及记录的主叫终端的加密能力信息确定被叫终端支持加密，生成密钥，并将携带有密钥的呼叫响应消息发送给主叫终端。

与主叫侧密钥应用服务器生成密钥的方法一样，这里所述主叫终端的加密能力信息是指被叫终端也支持的加密能力信息。另外，主叫终端和被叫终端相同的加密能力信息也可以由被叫终端确定后，通过呼叫响应消息返回给密钥应用服务器，其具体实现方法与主叫侧密钥应用服务器生成密钥时的情况相同，此处不再赘述。

本步骤中，被叫侧密钥应用器是通过被叫侧呼叫业务实体、主叫侧呼叫业务实体和主叫侧密钥应用服务器将所述呼叫响应消息转发给主叫终端的。

B3、主叫终端再向被叫终端发送确认消息或信息更新消息，并在发送的过程中，由被叫侧密钥应用服务器将生成的密钥通过确认消息或信息更新消息发送给被叫终端。

这里，主叫终端向被叫终端发送确认消息还是信息更新消息，也与呼叫请求消息的SIP消息头中是否携带有precondition协商相关，其情况与主叫侧密钥应用服务器生成密钥的情况相关，此处不再赘述。

通过本发明方案，主叫侧密钥应用服务器或被叫侧密钥应用服务器可以根据主叫终端的加密能力信息生成密钥，并分配给主叫终端和被叫终端，这适合于将加密作为一项基本业务的情况。也就是说，只要主叫终端和被叫终端有加密能力，都需要生成密钥，之后，主叫终端和被叫终端之间传输的媒体流都将利用分配的密钥进行加密。

在实际应用中，也可以将加密作为一项增值业务。这需要用户事先签约加密业务，密钥应用服务器只为经过签约的终端生成密钥。这里，可以预先根据用户签约情况设置加密业务签约信息，所述加密业务签约信息可以包括用户标识和签约情况。当密钥应用服务器接收到呼叫请求消息，就可以通过查询加密业务签约信息，根据呼叫请求消息中的用户标识来确定用户是否签约。如果主叫终端已经签约，则由主叫侧密钥应用服务器生成密钥；如果主叫终端没有签约，而被叫终端已经签约，则由被叫侧密钥应用服务器生成密钥。

在将加密业务作为增值业务的情况下，所述呼叫请求过程的步骤a1和步骤a2之间将进一步包括：

主叫侧密钥应用服务器查询事先设置的加密业务签约信息，根据用户标识判断主叫终端是否已经签约，如果已经签约，则将用于主叫侧生成密钥标识***呼叫请求消息；否则，将被叫侧生成密钥标识***呼叫请求消息。

相应地，步骤a2所述被叫侧密钥应用服务器将呼叫请求消息发送给被叫终端之前进一步包括：

主叫侧密钥应用服务器判别呼叫响应消息中密钥生成侧标识，如果是主叫侧生成密钥标识，则继续执行步骤a2；如果是被叫侧生成密钥标识，则执行步骤X，所述步骤X具体为：

X1、被叫侧密钥应用服务器查询事先设置的加密业务签约信息，根据用户标识判断被叫终端是否已经签约，如果已经签约，则将呼叫请求消息转发给被叫终端；

X2、被叫终端判断自身是否存在呼叫请求消息中所述加密能力信息，如果存在，则向被叫侧密钥应用服务器返回携带有自身加密能力信息的呼叫响应消息；

X3、被叫侧密钥应用服务器根据呼叫响应消息中被叫终端的加密能力信息，以及记录的主叫终端的加密能力信息确定被叫终端支持加密能力，根据记录的主叫终端的加密能力信息生成密钥，并将携带有密钥的呼叫响应消息通过被叫侧呼叫业务实体、主叫侧呼叫业务实体和主叫侧密钥应用服务器发送给主叫终端；

X4、主叫终端再向被叫终端发送确认消息或信息更新消息，并在发送的过程中，由被叫侧密钥应用服务器将生成的密钥通过确认消息或信息更新消息发送给被叫终端。

也就是说，在主叫终端和被叫终端都支持加密能力的情况下，如果主叫终端签约了加密业务，则由主叫侧密钥应用服务器生成并分配密钥；如果主叫终端没有签约加密业务而被叫终端签约了加密业务，则由被叫侧密钥应用服务器生成并分配密钥。

如果密钥应用服务器在呼叫响应过程中获得加密能力信息，其具体实现为：

主叫终端向被叫终端携带有主叫终端的加密能力信息的呼叫请求消息，被叫终端根据主叫终端的加密能力信息和被叫终端的加密能力确定生成密钥的加密能力信息，再通过呼叫响应消息将确定的加密能力信息发送给密钥应用服务器，密钥应用服务器从呼叫响应消息中获得加密能力信息，所述密钥应用服务器为主叫侧密钥应用服务器或被叫侧密钥应用服务器。

在这种情况下，密钥应用服务器可以不记录呼叫请求消息中主叫终端的加密能力信息，而直接根据呼叫响应消息中的加密能力信息生成密钥。

这里，所述主叫终端向被叫终端发送呼叫请求消息的方法为：

s1、主叫终端通过主叫侧呼叫业务实体将呼叫请求消息发送给主叫侧密钥应用服务器；

s2、再由主叫侧密钥应用服务器通过主叫侧呼叫业务实体和被叫侧呼叫业务实体，将呼叫请求消息发送给被叫侧密钥应用服务器；

s3、然后由被叫侧密钥应用服务器通过被叫侧呼叫业务实体将呼叫请求消息发送给被叫终端。

所述步骤s1具体为：

主叫终端将呼叫请求发送给主叫侧呼叫业务实体，主叫侧呼叫业务实体根据事先获得的过滤准则将接收到的呼叫请求消息进行过滤处理，将携带有主叫终端的加密能力信息的呼叫请求消息转发给主叫侧密钥应用服务器。

所述步骤s2具体为：

主叫侧密钥应用服务器通过主叫侧呼叫业务实体将将呼叫请求消息发送给被叫侧呼叫业务实体，被叫侧呼叫业务实体根据事先获得的过滤准则将接收到的呼叫请求消息进行过滤处理，将携带有主叫终端的加密能力信息的呼叫请求消息转发给被叫侧密钥应用服务器。

上述是将加密业务作为基本业务的描述，也可以作为增值业务，即事先设置加密业务签约信息，具体实现为：

如果获得加密能力信息的密钥应用服务器为主叫侧密钥应用服务器，所述呼叫请求消息中携带有用户标识，则所述步骤s1和步骤s2之间进一步包括：

主叫侧密钥应用服务器查询事先设置的加密业务签约信息，根据用户标识判断主叫终端是否已经签约，如果已经签约，则将用于主叫侧生成密钥标识***呼叫请求消息；否则，将被叫侧生成密钥标识***呼叫请求消息。

相应地，所述步骤s3将呼叫请求消息发送给被叫终端之前，该方法进一步包括：

被叫侧密钥应用服务器判别呼叫响应消息中密钥生成侧标识，如果是主叫侧生成密钥标识，则继续执行；如果是被叫侧生成密钥标识，则执行步骤Y，所述步骤Y具体为：

所述步骤Y具体为：

Y1、被叫侧密钥应用服务器查询事先设置的加密业务签约信息，根据用户标识判断被叫终端是否已经签约，如果已经签约，则将呼叫请求消息转发给被叫终端；

Y2、被叫终端根据主叫终端的加密能力信息和自身的加密能力信息确定生成密钥的加密能力信息，再通过呼叫响应消息将确定的加密能力信息发送给被叫侧密钥应用服务器；

Y3、被叫侧密钥应用服务器根据呼叫响应消息中的加密能力信息生成密钥，并将携带有密钥的呼叫响应消息通过被叫侧呼叫业务实体、主叫侧呼叫业务实体和主叫侧密钥应用服务器发送给主叫终端；

Y4、主叫终端再向被叫终端发送确认消息或信息更新消息，并在发送的过程中，由被叫侧密钥应用服务器将生成的密钥通过确认消息或信息更新消息发送给被叫终端。

为了更好地说明本发明方案，下面用较佳实施例进行详细描述。

方法实施例一

本实施例中，加密业务作为一项增值业务，主叫终端和被叫终端都支持加密能力，并都事先进行了签约；本实施例中，主叫侧呼叫业务实体为服务的呼叫会话控制功能实体(S-CSCF)，被叫侧呼叫业务实体为被叫侧S-CSCF；主叫侧密钥应用服务器和被叫侧密钥应用服务器都为SIP应用服务器；主叫终端发送的呼叫响应消息中的SIP消息头中包含precondition协商。

图2是本实施例的消息流示意图。如图2所示，本实施例实现端到端媒体流密钥协商的方法包括以下步骤：

步骤201：主叫终端将呼叫请求消息发送给主叫侧S-CSCF。

这里所述的呼叫请求消息就是SIP协议中的INVITE消息，可以采用三种方法将主叫终端的加密能力信息承载在INVITE消息中：第一种方法是承载在INVITE消息的SDP中；第二种方法是承载在INVITE消息中SIP主叫属性接收协商(Accept-contact)头域中；第三种方法是承载在INVITE消息中SIP的扩展协商域中。

对于第一种承载方法，即承载在会话描述协议(SDP)中，所述加密能力信息的格式为：

m＝<media><port>srtp/avp<format-list>

   [a＝media_encryption:

                   SRTP&

                   [Lists of the Encrypted Algorithms]&

                   [Lists of the Encrypted Key Length]&

                   [Lists of the Message Authentication Algorithms]&

                   [Lists of the Message Authentication Key Length]&

                   [Key Generation side declartion]&

                   [Key derivation rate]；]...

其中，m字段携带媒体信息，支持媒体能力声明；a字段则用来对媒体流进行属性描述，这些属性描述的含义如表一所示：

表一

如果主叫终端指定：采用SRTP协议，AES-CM加密算法，加密密钥的长度为128比特或256比特，消息认证与完整性保护算法采用HMAC-SHA1，消息认证与完整性保护密钥长度位160比特，密钥更新速率为24，则所述呼叫请求消息中的密钥能力信息为：

m＝<media><port>srtp/avp<format-list>

a＝media_encryption:SRTP&AES-CM&128；256&HMAC-SHA1&160&24

对于第二种承载方法，即承载在SIP主叫属性Accept-contact头域中，其格式为：

Accept_Contact:*；media_encryption＝

                  ”SRTP&

                  [Lists of the Encrypted Algorithms]&

                  [Lists of the Encrypted Key Length]&

                  [Lists of the Message Authentication Algorithms]&

                  [Lists of the Message Authentication Key Length]&

                  [Key Generation side declartion]&

                  [Key derivation rate]”；...

其中，media_encryption字段中各个子字段的含义与表一相同，此处不再赘述。

如果主叫终端的加密能力信息与第一种方法相同，其格式为：

Accept_Contact:media_encryption＝”SRTP&AES-CM&128；256&HMAC-SHA1&160&24”

对于第三种承载方法，即承载在SIP的扩展协商域中，则直接将主叫终端的能力信息写入Supported头域中即可，比如：

Supported:media_encryption＝SRTP-[AES-CM]-[128；256；512]-[HMAC-SHA1]-[160]

各子字段的含义与表一相同，此处不再赘述。

步骤202～步骤203：主叫侧呼叫业务实体根据事先获得的过滤准则，对接收到的呼叫请求消息进行过滤处理，并将携带有加密能力信息的呼叫请求消息转发给主叫侧密钥应用服务器。

本步骤所述的过滤准则是主叫侧的过滤准则，其格式如表二所示：

表二

其中，优先级可以由用户自行确定，Supported、Accept_Contact和m分别对应SIP扩展协商域、SIP主叫属性Accept-contact头域和承载在SDP中的三种方法，其他各项定义与现有技术相同，此处不再详细叙述。需要注意的是，由于主叫终端可以任选一种来承载加密能力信息，主叫侧呼叫业务实体需要利用过滤准则中与之对应的项进行过滤处理。比如：主叫终端采用承载在SDP的方法，则主叫侧呼叫业务实体则根据会话描述中m＝srtp/avp进行过滤处理，即表二中可以没有SIP消息头这一项。

实际应用，将主叫侧S-CSCF将呼叫请求消息转发给主叫侧密钥应用服务器时，还需要将过滤准则中的主叫侧密钥应用服务器的地址，以及自身地址***呼叫请求消息中，将主叫侧密钥应用服务器增加到当前呼叫的信令链路中。之后，主叫侧S-CSCF就可以将呼叫请求消息转发给主叫侧密钥应用服务器，并接收从主叫侧密钥应用服务器返回的消息。

当然，如果主叫侧S-CSCF根据过滤准则确定呼叫请求消息不包含加密能力信息，则不会将呼叫请求消息发送给主叫侧密钥应用服务器；同样，被叫侧S-CSCF也不会将呼叫请求消息发送给被叫侧密钥应用服务器。也就是说，呼叫信令链路中将不存在主叫侧密钥应用服务器和被叫侧密钥应用服务器，整个呼叫流程与现有的呼叫流程相同。

步骤204：主叫侧密钥应用服务器记录所述主叫终端的加密能力信息，再查询事先设置的加密业务签约信息，根据呼叫请求消息中用户标识确定主叫终端已经签约，并将主叫侧生成密钥标识***呼叫请求消息中。

本步骤中，所述加密业务签约信息的格式如表三所示：

用户标识	签约情况
		001	已签约
...	...

表三

所述主叫侧生成密钥标识表示密钥将由主叫侧密钥应用服务器生成。为了防止被叫侧密钥应用服务器生成密钥，需要将所述主叫侧生成密钥标识***呼叫请求消息，将该情况通知给被叫侧密钥应用服务器。之后，当被叫侧密钥应用服务器接收到呼叫请求消息时，如果确定该标识为主叫侧生成密钥标识，则不生成密钥。

相反，本步骤中，如果主叫侧密钥应用服务器确定主叫终端没有签约，则将被叫侧生成密钥标识***呼叫请求消息，将该情况通知给被叫侧密钥应用服务器。之后，当被叫侧密钥应用服务器接收到呼叫请求消息时，如果确定该标识为被叫侧生成密钥标识，则可以在后续的呼叫响应过程中生成密钥。

本实施例是将加密业务作为一项增值业务，如果将加密业务作为一项基本业务，并规定由主叫侧生成密钥，则无需设置加密业务签约信息，主叫侧密钥应用服务器无需查询加密业务签约信息，直接在后续的呼叫响应过程中生成密钥即可。

实际应用中，如果从呼叫响应过程中获得加密能力信息，本步骤也可以不记录主叫终端的加密能力信息。

步骤205～步骤206：主叫侧密钥应用服务器将呼叫请求消息返回给主叫侧S-CSCF，主叫侧S-CSCF再直接将呼叫请求消息转发给被叫侧S-CSCF。

所述步骤205中，为了保证主叫侧密钥应用服务器自身能接收到返回的呼叫响应消息，还需要将自身地址***到呼叫请求消息的记录路径(Record-Route)字段中。

步骤207～步骤208：被叫侧S-CSCF根据事先获得的过滤准则，对接收到的呼叫请求进行过滤处理，并将携带有加密能力信息的呼叫请求消息转发给被叫侧密钥应用服务器。

被叫侧获得过滤准则与主叫侧获得的过滤准则相似，区别在于，会话情形字段中为目的端(Terminating)，地址字段为被叫侧密钥应用服务器地址，其格式如表四所示：

表四

其他字段的含义与表三相同，此处不再赘述。

如果被叫侧S-CSCF接收到的呼叫请求消息不包含加密能力信息，则不会转发到被叫侧密钥应用服务器。

步骤209～步骤211：被叫侧密钥应用服务器记录呼叫请求消息中主叫终端的加密能力信息，并判别呼叫响应消息中密钥生成侧标识为主叫侧密钥生成标识，再通过被叫侧呼叫业务实体将呼叫请求消息转发给被叫终端。

步骤212～步骤214：被叫终端判断自身是否存在呼叫请求消息中所述加密能力信息，如果存在，则通过被叫侧S-CSCF向被叫侧密钥应用服务器返回携带有自身加密能力信息的呼叫响应消息。

由于本实施主叫终端发送的呼叫响应消息的SIP消息头中包含precondition协商，则所述的呼叫响应消息为183消息。如果呼叫响应消息的SIP消息头中不包含precondition协商，则这里所述的呼叫响应消息为200OK消息，可以表示成功呼叫响应消息。当然，如果被叫终端不支持加密能力，则应该返回失败呼叫响应消息，即返回4xx错误信息，比如：420消息等。

步骤215～步骤218：被叫侧密钥应用服务器根据呼叫响应消息中被叫终端的加密能力信息，以及记录的主叫终端的加密能力信息，确定被叫终端支持加密能力，再直接将呼叫响应消息通过被叫侧S-CSCF和主叫侧S-CSCF转发给主叫侧密钥应用服务器。

步骤219～步骤221：主叫侧密钥应用服务器确定呼叫响应消息中的密钥生成侧标识为主叫侧生成密钥标识，根据事先记录的主叫终端的加密能力信息生成密钥，并将密钥通过主叫侧S-CSCF返回给主叫终端。

这里，主叫侧密钥应用服务器可以将生成的密钥承载于183消息中SDP的k字段中。

步骤222～步骤224：主叫终端从呼叫响应消息中获得密钥后，并通过主叫侧S-CSCF向主叫侧密钥应用服务器发送信息更新消息。

这里所述的信息更新消息就是UPDATE消息。

步骤225～步骤231：主叫侧密钥应用服务器将生成的密钥添加到UPDATE消息中SDP的k字段中，并通过主叫侧S-CSCF、被叫侧S-CSCF和被叫侧密钥应用服务器发送给被叫终端，被叫终端从UPDATE消息中获得密钥。

本实施例中，在步骤222和步骤223之间，即主叫终端发送UPDATE消息之前，主叫终端还需要向被叫终端发送确认(PRACK)消息，其具体过程与现有技术相同，此处不再赘述。

另外，当被叫终端获得密钥之后，即步骤231之后，被叫终端还需要向主叫终端返回200 OK消息，这也与现有技术相同，此处不再赘述。

方法实施例二

本实施例中，加密业务作为一项增值业务，主叫终端和被叫终端都支持加密能力，但只有被叫终端已经签约；本实施例中，主叫侧呼叫业务实体为主叫侧S-CSCF，被叫侧呼叫业务实体为被叫侧S-CSCF；主叫侧密钥应用服务器和被叫侧密钥应用服务器都为SIP应用服务器；主叫终端发送的呼叫响应消息中的SIP消息头中不包含precondition协商。

图3是本实施例的消息流示意图。如图3所示，本实施例实现端到端媒体流密钥协商的方法包括以下步骤：

步骤301～步骤303与实施例一中的步骤201～步骤203相同，此处不再赘述。

步骤304：主叫侧密钥应用服务器记录所述主叫终端的加密能力信息，再查询事先设置的加密业务签约信息，根据呼叫请求消息中用户标识确定主叫终端没有签约，将被叫侧生成密钥标识***呼叫请求消息中。

步骤305～步骤308与实施例中的步骤205～步骤208相似，此处不再赘述。

步骤309～步骤311：被叫侧密钥应用服务器记录呼叫请求消息中主叫终端的加密能力信息，并判别呼叫响应消息中密钥生成侧标识为被叫侧密钥生成标识，再查询事先设置的加密业务签约信息，根据呼叫请求消息中用户标识确定被叫终端已经签约，则通过被叫侧呼叫业务实体将呼叫请求消息转发给被叫终端。

实际应用中，如果被叫侧密钥应用服务器确定被叫终端没有签约，则将呼叫请求消息中的密钥生成侧标识更新为无密钥生成标识，表示主叫侧密钥应用服务器或被叫侧密钥应用服务器都无需生成密钥。进一步地，被叫侧密钥应用服务器再将自身从呼叫信令链路中删除。之后，当主叫侧密钥应用服务器接收到携带由无密钥生成标识的呼叫响应消息，也将自身从呼叫信令链路中删除。

步骤312～步骤314与实施例一的步骤212～步骤214相似，区别在于：由于主叫终端发送的呼叫响应消息中的SIP消息头中不包含precondition协商，则返回的呼叫响应消息应该为200 OK消息。

步骤315：被叫侧密钥应用服务器根据呼叫响应消息中被叫终端的加密能力信息，以及记录的主叫终端的加密能力信息，确定被叫终端支持加密能力；并在确定呼叫响应消息中携带的是被叫侧生成密钥标识后，根据事先记录的加密能力信息生成密钥。

本实施例是将加密业务作为一项增值业务，如果作为基本业务，则被叫侧密钥应用服务器无需查询加密业务签约信息，直接生成密钥即可。

步骤316～步骤321：被叫侧密钥应用服务器将生成的密钥添加到呼叫响应消息中，并通过被叫侧S-CSCF、主叫侧S-CSCF和主叫侧密钥应用服务器返回给主叫终端，主叫终端从呼叫响应消息中获得密钥。

由于本实施例中，后续主叫终端向被叫终端发送的ACK消息不存在SDP，即无法将密钥承载于SDP中的k字段中，所以，在本步骤中，为了与ACK承载密钥的方法保持一致，可以在200OK中新增加一个SIP头域来承载生成的密钥，比如新增加Media-Key头域，其格式如下所示：

Media-Key:<Key>

其中，Key表示生成的密钥。这样，就可以利用200OK将密钥返回给主叫终端。

步骤322～步骤326：主叫终端通过主叫侧S-CSCF、主叫侧密钥应用服务器和被叫侧S-CSCF，将确认消息发送给被叫侧密钥应用服务器。

这里所述的确认消息就是ACK消息，其发送过程及其意义属于现有技术，此处不再赘述。

步骤327～331：被叫侧密钥应用服务器将生成的密钥添加到ACK消息中，并通过被叫侧S-CSCF发送给被叫终端，被叫终端从ACK消息中获得密钥。

这里，也需要事先为所述ACK消息新增加一个Media-Key头域来承载生成的密钥。

方法实施例三

本实施例将加密业务作为一项基本业务，密钥应用服务器从呼叫响应消息中获得加密能力信息；本实施例中，主叫侧呼叫业务实体为主叫侧S-CSCF，被叫侧呼叫业务实体为被叫侧S-CSCF；主叫侧密钥应用服务器和被叫侧密钥应用服务器都为S-CSCF中SIP代理模式单元；主叫终端发送的呼叫响应消息中的SIP消息头中不包含precondition协商。

图4是本实施例的消息流示意图。如图4所示，本实施例包括以下步骤：

步骤401～步骤409：主叫终端向被叫终端发送呼叫请求消息，在发送的过程中，当主叫侧呼叫业务实体接收到呼叫请求消息时，根据事先获得的过滤准则对呼叫请求消息进行过滤，并将携带有主叫终端加密能力的呼叫请求消息发送给主叫侧密钥应用服务器，当被叫侧呼叫业务实体接收到呼叫请求消息时，根据事先获得的过滤准则对呼叫请求消息进行过滤，并将携带有主叫终端加密能力的呼叫请求消息发送给被叫侧密钥应用服务器。

步骤410：被叫终端根据主叫终端的加密能力信息和自身加密能力确定生成密钥的加密能力信息。

步骤411～步骤415：被叫终端通过被叫侧呼叫业务实体、被叫侧密钥应用服务器和主叫侧呼叫业务实体，将携带有生成密钥的加密能力信息的呼叫响应消息发送给主叫侧密钥应用服务器。

步骤416～步骤419：主叫侧密钥应用服务器根据呼叫响应消息中的密钥能力信息生成密钥，并将密钥通过主叫侧呼叫业务实体发送给主叫终端，主叫终端从呼叫响应消息中获得密钥。

步骤420～步骤421：主叫终端通过主叫侧呼叫业务实体将向主叫侧密钥应用服务器发送确认消息。

步骤422～步骤428：主叫侧密钥应用服务器将生成的密钥添加到确认消息中，再通过主叫侧呼叫业务实体、被叫侧呼叫业务实体、被叫侧密钥应用服务器，将确认消息发送给被叫终端，被叫终端从确认消息中获得密钥。

本实施例所述呼叫请求消息为INVITE消息，呼叫响应消息为200 OK，确认消息为ACK消息，至于如何在200OK消息和ACK消息中携带密钥可以与实施例二中所述的方法相同，此处不再赘述。

应用本发明方案，主叫终端和被叫终端自身不生成密钥，而是由第三方设备，即密钥应用服务器生成密钥，无需进行时钟同步，也无需PKI体系的支持，可以大大降低端到端媒体流密钥协商的复杂度，便于媒体流加密业务的推广。

密钥应用服务器还可以将生成的密钥保存下来，可以满足合法监听的实际需要。

本发明实施例是以含有IP多媒体子***(IMS)的网络，并且在IMS网络中信令链路可以提供安全保障的情况为例进行说明的。实际应用中，还可以将本发明方法应用于其他类型的网络中，如：基于软交换的下一代网络，其方法与本发明类似，此处不再一一列举。

针对实现端到端媒体流密钥协商的方法，本发明还提出一种实现端到端媒体流密钥协商的***。

***实施例一

图5是***实施例一的基本结构示意图。如图5所示，该***包括：主叫终端501、密钥管理子***502和被叫终端503。

其中，所述主叫终端501，用于将携带有自身加密能力信息的呼叫请求消息发送给密钥管理子***502，并接收返回的密钥；

所述密钥管理子***502，至少包括密钥应用服务器，用于生成密钥并分配给主叫终端501和被叫终端502；

所述被叫终端503，用于接收由密钥管理子***502分配的密钥。

其中，所述密钥管理子***502包括：

主叫侧呼叫业务实体5021，用于过滤来自主叫终端501的呼叫请求消息，将携带有加密能力信息的呼叫请求消息转发给主叫终端501，并转发主叫终端501、主叫侧密钥应用服务器5022和被叫侧呼叫业务实体5023之间交互的消息；

主叫侧密钥应用服务器5022，记录主叫终端501的加密能力信息并生成密钥；

被叫侧呼叫业务实体5023，用于过滤呼叫请求消息，将携带有加密能力信息的呼叫请求消息转发给被叫侧密钥应用服务器5024，并转发被叫终端501、被叫侧密钥应用服务器5024和主叫侧呼叫业务实体5021之间交互的消息；

被叫侧密钥应用服务器5024，记录主叫终端501的加密能力信息。

当主叫终端501发起呼叫时，主叫终端501将呼叫请求消息先发送给主叫侧呼叫业务实体5021；主叫侧呼叫业务实体5021根据事先获得的过滤准则，对接收到的呼叫请求消息进行过滤处理，并将携带有加密能力信息的呼叫请求消息转发给主叫侧密钥应用服务器5022，主叫侧密钥应用服务器5022记录呼叫请求消息中主叫终端的加密能力信息；主叫侧密钥应用服务器5022通过主叫侧呼叫业务实体5021，将所述呼叫请求消息发送给被叫侧呼叫业务实体5023；被叫侧呼叫业务实体5023根据事先获得的过滤准则，对接收到的呼叫请求进行过滤处理，并将携带有加密能力信息的呼叫请求消息转发给被叫侧密钥应用服务器5024；被叫侧密钥应用服务器5024记录呼叫请求消息中主叫终端的加密能力信息，再通过被叫侧呼叫业务实体5023将呼叫请求消息转发给被叫终端503。

之后，被叫终端503判断自身是否存在呼叫请求消息中所述加密能力信息，如果存在，则向被叫侧密钥应用服务器5024返回携带有自身加密能力信息的呼叫响应消息；被叫侧密钥应用服务器5024根据呼叫响应消息中被叫终端的加密能力信息，以及记录的主叫终端的加密能力信息确定被叫终端支持加密能力，并将呼叫响应消息发送给主叫侧密钥应用服务器5022；主叫侧密钥应用服务器5024根据事先记录的主叫终端的加密能力信息生成密钥，并将密钥通过呼叫响应消息分配给主叫终端501。

之后，主叫终端501再通过主叫侧呼叫业务实体5021、主叫侧密钥应用服务器5022、被叫侧呼叫业务实体5023、被叫侧密钥应用服务器5024向被叫终端503发送确认消息或信息更新消息，并在发送的过程中，由主叫侧密钥应用服务器5022将生成的密钥通过确认消息或信息更新消息发送给被叫终端503。

当然，实际应用中，也可以由被叫侧密钥应用服务器5024分配密钥，其过程与上述流程相似，此处不再赘述。

***实施例二

图6是***实施例二的基本结构示意图。与图5的区别在于：本实施例中的密钥应用服务器可以放置在呼叫业务实体内，作为呼叫业务实体的一个功能单元。此时，所述密钥管理子***502包括：

主叫侧呼叫业务实体601，包括主叫侧呼叫单元6011和主叫侧密钥应用服务器6012；

所述主叫侧呼叫单元6011用于过滤来自主叫终端的呼叫请求消息，将携带有加密能力信息的呼叫请求消息转发给主叫侧密钥应用服务器6012，并转发主叫终端501、主叫侧密钥应用服务器6012和被叫侧呼叫业务实体602之间交互的消息；所述主叫侧密钥应用服务器6012为SIP代理模式单元，用于生成密钥；

被叫侧呼叫业务实体602，包括被叫侧呼叫单元6021和被叫侧密钥应用服务器6022；

所述被叫侧呼叫单元6021用于过滤来自被叫终端的呼叫请求消息，将携带有加密能力信息的呼叫请求消息转发给被叫侧密钥应用服务器6022，并转发被叫终端503、被叫侧密钥应用服务器6022和主叫侧呼叫业务实体601之间交互的消息；所述被叫侧密钥应用服务器6022为SIP代理模式单元，用于记录加密能力信息。

综上所述，以上仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (17)

1.一种实现端到端媒体流密钥协商的方法，其特征在于，该方法为：

主叫终端发起呼叫，在呼叫过程中密钥应用服务器获得加密能力信息，根据获得的加密能力信息生成密钥，并分配给主叫终端和被叫终端。

2.根据权利要求1所述的方法，其特征在于，所述获得加密能力信息的方法具体为：

a、主叫终端向被叫终端发送呼叫请求消息，在呼叫请求过程中，密钥应用服务器从呼叫请求消息中获得并记录主叫终端的加密能力信息；

所述生成并分配密钥的方法具体为：

b、被叫终端向主叫终端返回呼叫响应消息，在返回的过程中，密钥应用服务器根据事先记录的主叫终端的加密能力信息生成密钥，密钥应用服务器再将密钥分配给主叫终端和被叫终端。

3.根据权利要求2所述的方法，其特征在于，所述密钥应用服务器为主叫侧密钥应用服务器，所述步骤a具体为：

a1、主叫终端将携带有自身加密能力信息的呼叫请求消息发送给主叫侧密钥应用服务器，主叫侧密钥应用服务器记录所述主叫终端的加密能力信息；

a2、主叫侧密钥应用服务器将呼叫请求消息发送给被叫侧密钥应用服务器，由被叫侧密钥应用服务器记录主叫终端的加密能力信息，再转发给被叫终端。

所述步骤b具体为：

b1、被叫终端判断自身是否存在呼叫请求消息中所述加密能力信息，如果存在，则向被叫侧密钥应用服务器返回携带有自身加密能力信息的呼叫响应消息；

b2、被叫侧密钥应用服务器根据呼叫响应消息中被叫终端的加密能力信息，以及记录的主叫终端的加密能力信息确定被叫终端支持加密能力，并将呼叫响应消息发送给主叫侧密钥应用服务器；

b3、主叫侧密钥应用服务器根据事先记录的主叫终端的加密能力信息生成密钥，并将密钥通过呼叫响应消息分配给主叫终端；

b4、主叫终端再向被叫终端发送确认消息或信息更新消息，并在发送的过程中，由主叫侧密钥应用服务器将生成的密钥通过确认消息或信息更新消息发送给被叫终端。

4.根据权利要求3所述的方法，其特征在于，步骤a1所述主叫终端将呼叫请求消息发送给主叫侧密钥应用服务器的方法为：

a11、主叫终端将呼叫请求消息先发送给主叫侧呼叫业务实体；

a12、主叫侧呼叫业务实体根据事先获得的过滤准则，对接收到的呼叫请求消息进行过滤处理，并将携带有加密能力信息的呼叫请求消息转发给主叫侧密钥应用服务器，主叫侧密钥应用服务器记录呼叫请求消息中主叫终端的加密能力信息。

5.根据权利要求3所述的方法，其特征在于，所述步骤a2具体为：

a21、主叫侧密钥应用服务器通过主叫侧呼叫业务实体，将所述呼叫请求消息发送给被叫侧呼叫业务实体；

a22、被叫侧呼叫业务实体根据事先获得的过滤准则，对接收到的呼叫请求进行过滤处理，并将携带有加密能力信息的呼叫请求消息转发给被叫侧密钥应用服务器；

a23、被叫侧密钥应用服务器记录呼叫请求消息中主叫终端的加密能力信息，再通过被叫侧呼叫业务实体将呼叫请求消息转发给被叫终端。

6.根据权利要求3所述的方法，其特征在于，所述呼叫请求消息携带有用户标识，所述步骤a1和步骤a2之间进一步包括：

主叫侧密钥应用服务器查询事先设置的加密业务签约信息，根据用户标识判断主叫终端是否已经签约，如果已经签约，则将用于主叫侧生成密钥标识***呼叫请求消息；否则，将被叫侧生成密钥标识***呼叫请求消息。

7.根据权利要求6所述的方法，其特征在于，步骤a2所述被叫侧密钥应用服务器将呼叫请求消息发送给被叫终端之前进一步包括：被叫侧密钥应用服务器判别呼叫响应消息中密钥生成侧标识，如果是主叫侧生成密钥标识，则继续执行步骤a2；如果是被叫侧生成密钥标识，则执行步骤X，所述步骤X具体为：

X1、被叫侧密钥应用服务器查询事先设置的加密业务签约信息，根据用户标识判断被叫终端是否已经签约，如果已经签约，则将呼叫请求消息转发给被叫终端；

X2、被叫终端判断自身是否存在呼叫请求消息中所述加密能力信息，如果存在，则向被叫侧密钥应用服务器返回携带有自身加密能力信息的呼叫响应消息；

X3、被叫侧密钥应用服务器根据呼叫响应消息中被叫终端的加密能力信息，以及记录的主叫终端的加密能力信息确定被叫终端支持加密能力，根据记录的主叫终端的加密能力信息生成密钥，并将携带有密钥的呼叫响应消息通过被叫侧呼叫业务实体、主叫侧呼叫业务实体和主叫侧密钥应用服务器发送给主叫终端；

X4、主叫终端再向被叫终端发送确认消息或信息更新消息，并在发送的过程中，由被叫侧密钥应用服务器将生成的密钥通过确认消息或信息更新消息发送给被叫终端。

8.根据权利要求1所述的方法，其特征在于，所述获得加密能力信息的方法为：

主叫终端向被叫终端发送携带有主叫终端的加密能力信息的呼叫请求消息，被叫终端根据主叫终端的加密能力信息和自身的加密能力信息确定生成密钥的加密能力信息，再通过呼叫响应消息将确定的加密能力信息发送给密钥应用服务器，密钥应用服务器从呼叫响应消息中获得加密能力信息。

9.根据权利要求8所述的方法，其特征在于，所述主叫终端向被叫终端发送呼叫请求消息的方法为：

s1、主叫终端通过主叫侧呼叫业务实体将呼叫请求消息发送给主叫侧密钥应用服务器；

s2、再由主叫侧密钥应用服务器通过主叫侧呼叫业务实体和被叫侧呼叫业务实体，将呼叫请求消息发送给被叫侧密钥应用服务器；

s3、然后由被叫侧密钥应用服务器通过被叫侧呼叫业务实体将呼叫请求消息发送给被叫终端。

10.根据权利要求9所述的方法，其特征在于，所述步骤s1具体为：

主叫终端将呼叫请求发送给主叫侧呼叫业务实体，主叫侧呼叫业务实体根据事先获得的过滤准则将接收到的呼叫请求消息进行过滤处理，将携带有主叫终端的加密能力信息的呼叫请求消息转发给主叫侧密钥应用服务器。

所述步骤s2具体为：

主叫侧密钥应用服务器通过主叫侧呼叫业务实体将将呼叫请求消息发送给被叫侧呼叫业务实体，被叫侧呼叫业务实体根据事先获得的过滤准则将接收到的呼叫请求消息进行过滤处理，将携带有主叫终端的加密能力信息的呼叫请求消息转发给被叫侧密钥应用服务器。

11.根据权利要求9所述的方法，其特征在于，所述获得加密能力信息的密钥应用服务器为主叫侧密钥应用服务器，所述呼叫请求消息中携带有用户标识，所述步骤s1和步骤s2之间进一步包括：

主叫侧密钥应用服务器查询事先设置的加密业务签约信息，根据用户标识判断主叫终端是否已经签约，如果已经签约，则将用于主叫侧生成密钥标识***呼叫请求消息；否则，将被叫侧生成密钥标识***呼叫请求消息。

12.根据权利要求11所述的方法，其特征在于，所述步骤s3将呼叫请求消息发送给被叫终端之前，该方法进一步包括：

被叫侧密钥应用服务器判别呼叫响应消息中密钥生成侧标识，如果是主叫侧生成密钥标识，则继续执行；如果是被叫侧生成密钥标识，则执行步骤Y，所述步骤Y具体为：

所述步骤Y具体为：

Y1、被叫侧密钥应用服务器查询事先设置的加密业务签约信息，根据用户标识判断被叫终端是否已经签约，如果已经签约，则将呼叫请求消息转发给被叫终端；

Y2、被叫终端根据主叫终端的加密能力信息和自身的加密能力信息确定生成密钥的加密能力信息，再通过呼叫响应消息将确定的加密能力信息发送给被叫侧密钥应用服务器；

Y3、被叫侧密钥应用服务器根据呼叫响应消息中的加密能力信息生成密钥，并将携带有密钥的呼叫响应消息通过被叫侧呼叫业务实体、主叫侧呼叫业务实体和主叫侧密钥应用服务器发送给主叫终端；

Y4、主叫终端再向被叫终端发送确认消息或信息更新消息，并在发送的过程中，由被叫侧密钥应用服务器将生成的密钥通过确认消息或信息更新消息发送给被叫终端。

13.根据权利要求2或8所述的方法，其特征在于，所述主叫终端的加密能力信息承载于呼叫请求消息的会话描述协议SDP中；或者承载于呼叫请求消息的会话初始协议SIP主叫属性接收协商Accept-contact头域中；或者承载于呼叫请求中SIP扩展协商域中，所述SIP扩展协商域为支持supported域。

14.根据权利要求2或8所述的方法，其特征在于，如果主叫终端发送的呼叫请求消息包含预处理Precondition协商，则所述生成的密钥承载于SDP的k字段中；

如果主叫终端发送的呼叫请求消息不包含预处理Precondition协商，则预先设置新的SIP头域，将所述生成的密钥承载于新的SIP头域中。

15.一种实现端到端媒体流密钥协商的***，其特征在于，该***包括：主叫终端、密钥管理子***和被叫终端；其中

所述主叫终端，用于将携带有自身加密能力信息的呼叫请求消息发送给密钥管理子***，并接收返回的密钥；

所述密钥管理子***，至少包括密钥应用服务器，用于生成密钥并分配给主叫终端和被叫终端；

所述被叫终端，用于接收由密钥管理子***分配的密钥。

16.根据权利要求15所述的***，其特征在于，所述密钥管理子***包括：

主叫侧呼叫业务实体，用于过滤来自主叫终端的呼叫请求消息，将携带有加密能力信息的呼叫请求消息转发给主叫侧密钥应用服务器，并转发主叫终端、主叫侧密钥管理实体和被叫侧呼叫业务实体之间交互的消息；

主叫侧密钥应用服务器，记录主叫终端加密能力，生成密钥；

被叫侧呼叫业务实体，用于过滤呼叫请求消息，将携带有加密能力信息的呼叫请求消息转发给被叫侧密钥应用服务器，并转发被叫终端、被叫侧密钥应用服务器和主叫侧呼叫业务实体之间交互的消息；

被叫侧密钥应用服务器，记录主叫终端加密能力信息。

17.根据权利要求15所述的***，其特征在于，所述密钥管理子***包括：

主叫侧呼叫业务实体，包括主叫侧呼叫单元和主叫侧密钥应用服务器；

所述主叫侧呼叫单元用于过滤来自主叫终端的呼叫请求消息，将携带有加密能力信息的呼叫请求消息转发给主叫侧密钥应用服务器，并转发主叫终端、主叫侧密钥应用服务器和被叫侧呼叫业务实体之间交互的消息；所述主叫侧密钥应用服务器为SIP代理模式单元，用于记录主叫终端的加密能力信息，生成密钥；

被叫侧呼叫业务实体，包括被叫侧呼叫单元和被叫侧密钥应用服务器；

所述被叫侧呼叫单元用于过滤呼叫请求消息，将携带有加密能力信息的呼叫请求消息转发给被叫侧密钥应用服务器，并转发被叫终端、被叫侧密钥应用服务器和主叫侧呼叫业务实体之间交互的消息；所述被叫侧密钥应用服务器为SIP代理模式单元，用于记录加密能力信息。

Images