CN101222320B - 一种媒体流安全上下文协商的方法、系统和装置 - Google Patents

Abstract

本发明实施例提供一种媒体流安全上下文协商的方法、系统和装置，主叫终端设备(UE)通过会话请求消息将自身提供的媒体流安全上下文信息发送给被叫UE，所述媒体流安全上下文信息包括安全算法；接收被叫UE提供的媒体流安全上下文信息；主叫UE和被叫UE根据双方提供的包括安全算法的媒体流安全上下文信息获得密钥。由于不需要UE进行复杂的计算，也不需要网络中具备公钥设施等要求，而是直接由主叫UE和被叫UE进行交互来获得包括安全算法和密钥的媒体流安全上下文信息，从而实现了IMS系统中媒体流安全上下文协商，有利于后续在IMS网络中进行媒体流安全保护。

Description

一种媒体流安全上下文协商的方法、系统和装置 

技术领域

本发明涉及媒体流加密技术，特别是涉及一种媒体流安全上下文协商的方法、系统和装置。 

背景技术

IP多媒体业务子系统(IMS，IP Multimedia Network Subsystem)是固定和移动网络的核心会话控制层，是通信领域发展的重点之一，并已经在第三代伙伴项目(3GPP，The Third Generation Partnership Project)和先进网络的电信与因特网融合的服务与协议标准化组织(TISPAN，Telecommunications and Internet Converged Services and Protocols for Advanced Networking)中定义了与IMS相关的规范，比如：网络架构、接口、协议等等。 

其中，安全问题是3GPP和TISPAN制定规范的一个重要方面。为了能够保证安全，将IMS网络划分为接入域和网络域，并分别定义了接入域和网络域的安全规范。 

但目前关于安全的规范都是针对IMS网络中控制面的，即如何保证IMS网络中会话协议的安全，而媒体流本身则是通过明文传输。在这种情况下，用户在通话过程中，媒体流可能被窃听、窜改等，用户通话安全无法得到保障。 

主叫用户设备(UE，User Equipment)和被叫UE对媒体流进行安全保护，则双方需要对媒体流安全上下文达成一致。这里的媒体流安全上下文主要是指用来加密媒体流的密钥、安全算法、密钥标识、密钥的有效期等安全参数。具体协商的时候，消息中可以只携带部分参数，其它的参数可以是预先设置好的默认参数，例如默认的密钥有效期等，也可以在后续的消息中继续携带和协商。目前，现有的因特网工程任务组(IETF，Internet Engineering Tesk Force)中有很多协商媒体流安全上下文信息的机制，例如RFC 3830(RFC，Request for Comments)多媒体因特网密钥(MIKEY，Multimedia Internet  KEYing)协议中的预先共享密钥(PSK，Pre-Shared-Key)模式，赫尔曼(DH，Deffi-Helman)模式，公钥(PKI，Public Key Infrastructure)模式等等，RFC4568中的安全信息描述SDES协议等。但是这些协议都不能直接应用于IMS的媒体流安全保护之中，比如，MIKEY-DH模式对UE的计算性能要求很高，但目前的终端能力还不能满足要求，所以MIKEY-DH模式无法直接应用于IMS中；又比如，MIKEY-PKI模式需要公钥设施，但目前的IMS网络种还没有部署PKI，所以MIKEY-PKI模式也无法直接应用于IMS中；再比如，MIKEY-PSK模式需要主叫和被叫UE预先共享密钥，但目前还没有共享密钥的机制，所以MIKEY-PSK模式也无法直接应用于IMS中。由此可见，目前还没有可以解决IMS网络中的媒体流安全问题的方法。 

发明内容

有鉴于此，本发明方法实施例提供一种媒体流安全上下文协商的方法，可以在IMS系统中实现媒体流安全上下文协商，有利于IMS系统利用协商获得的密钥进行保护媒体流； 

本发明实施例还提供一种媒体流安全上下文协商的系统，可以在IMS系统中实现媒体流安全上下文协商，有利于IMS系统利用协商获得的密钥进行保护媒体流； 

本发明实施例还提供一种媒体流安全上下文协商的装置，可以在IMS系统中媒体流安全上下文协商，有利于IMS系统利用协商获得的密钥进行保护媒体流。 

为了达到上述第一个发明目的，本发明实施例提出的技术方案为： 

一种实现媒体流安全上下文协商的方法，该方法包括： 

主叫终端设备UE通过会话请求消息将自身提供的媒体流安全上下文信息发送给被叫UE，所述媒体流安全上下文信息包括安全算法； 

主叫UE接收被叫UE通过会话应答消息提供的媒体流安全上下文信息，所述被叫UE提供的媒体流安全上下文信息是根据主叫UE提供的媒体流安全上下文信息所确定的； 

主叫UE和被叫UE根据双方提供的包括安全算法的媒体流安全上下文信息获得密钥。 

为了达到上述第一个发明目的，本发明实施例还提出另外的技术方案 为：一种实现媒体流安全上下文协商的方法，该方法包括： 

主叫UE将携带有媒体流保护指示信息的会话请求消息发送给被叫UE； 

被叫UE检查媒体流保护指示信息，确定自身支持媒体流保护； 

被叫UE和主叫UE根据双方提供的包括安全算法的媒体流安全上下文信息获得密钥。 

对于第二个发明目的，本发明实施例提出的技术方案为： 

一种实现媒体流安全上下文协商的系统，该系统包括： 

主叫UE，通过会话请求消息将自身提供的包括安全算法的媒体流安全上下文信息发送给被叫UE； 

被叫UE，被叫UE根据会话请求消息中主叫UE提供的媒体流安全上下文信息确定自身需要提供的媒体流安全上下文信息，通过会话应答消息将确定提供的媒体流安全上下文信息发送给主叫UE； 

所述主叫UE和被叫UE根据双方提供的包括安全算法的媒体流安全上下文信息获得密钥。 

对于第二个发明目的，本发明实施例还提出另外的技术方案为： 

一种实现媒体流安全上下文协商的系统，该系统包括： 

主叫UE，将携带有媒体流保护指示信息的会话请求消息发送给被叫UE，获得包括安全算法和密钥的媒体流安全上下文信息； 

被叫UE，接收携带有媒体流保护指示信息的会话请求消息，检查媒体流保护指示信息，确定自身支持媒体流保护； 

所述主叫UE和被叫UE还根据双方提供的包括安全算法的媒体流安全上下文信息获得密钥。 

对于第三个发明目的，本发明提出的技术方案为： 

一种实现媒体流安全上下文协商的装置，该装置包括： 

收发单元，通过会话请求消息将自身提供的至少一套的媒体流安全上下文信息发送给被叫UE，所述每一套媒体流安全上下文包括安全算法；接收被叫UE通过会话应答消息提供的至少一套媒体流安全上下文信息，所述被叫UE提供的媒体流安全上下文信息是根据主叫UE提供的至少一套媒体流安全上下文信息中选择出的；将生成的密钥携带于选择出的一套媒体流安全上下文中发送给被叫UE； 

选择单元，从被叫UE提供的所有媒体流安全上下文信息中选择出一套； 

密钥生成单元，根据选择出的媒体流安全上下文信息中的安全算法生成密钥。 

一种实现媒体流安全上下文协商的装置，该装置为主叫UE，包括： 

收发单元，通过会话请求消息将提供的至少一套媒体流安全上下文信息发送给被叫UE，所述每一套媒体流安全上下文信息包括安全算法和主叫UE自身的密钥生成参数；接收被叫UE通过会话应答消息提供的一套媒体流安全上下文信息，所述被叫UE提供的一套媒体流安全上下文信息中的密钥生成参数为被叫UE自身的密钥生成参数； 

密钥生成单元，根据主叫UE自身的密钥生成参数以及被叫UE自身的密钥生成参数产生密钥。 

一种实现媒体流安全上下文协商的装置，该装置为主叫UE，包括： 

收发单元，将携带有媒体流保护指示信息的会话请求消息发送给被叫UE；接收被叫UE通过会话应答消息提供的至少一套媒体流安全上下文信息，所述媒体流安全上下文信息包括安全算法和对应的密钥；将选择单元选择出的媒体流安全上下文信息发送给被叫UE； 

选择单元，从被叫UE提供的所有媒体流安全上下文信息中进行选择。 

综上所述，本发明提出的一种媒体流安全上下文协商的方法、系统和装置，由于不需要UE进行复杂的计算，也不需要网络中具备公钥设施等要求，而是直接由主叫UE和被叫UE进行交互来获得包括安全算法和密钥的媒体流安全上下文信息，从而实现了IMS系统中媒体流安全上下文协商，有利于后续在IMS网络中进行媒体流安全保护。 

附图说明

图1为本发明方法实施例一的方法流程图； 

图2为本发明方法实施例二的消息流示意图； 

图3为本发明方法实施例三的消息流示意图； 

图4为本发明方法实施例四的消息流示意图； 

图5为本发明方法实施例五的消息流示意图； 

图6为本发明系统实施例一基本结构示意图； 

图7为本发明系统实施例二的基本结构示意图； 

图8为本发明系统实施例三的基本结构示意图； 

图9为本发明方法实施例六的消息流示意图； 

图10为本发明方法实施例七的消息流示意图； 

图11为本发明方法实施例八的消息流示意图； 

图12为本发明系统实施例四的基本结构示意图； 

图12A为本发明系统实施例五的基本结构示意图； 

图12B为本发明系统实施例六的基本结构示意图； 

图13A为本发明系统实施例七的基本结构示意图； 

图13B为本发明系统实施例八的基本结构示意图。 

具体实施方式

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

图1是本发明方法实施例一的流程图。如图1所示，方法实施例一包括以下步骤： 

步骤101：第一实体发送会话建立请求消息给第二实体，所述会话建立请求消息携带有第一实体侧提供的媒体流安全能力信息。 

步骤102：第二实体根据会话建立请求消息确定本侧需提供的媒体流安全能力信息，并将提供的媒体流安全能力信息通过会话建立响应消息返回给第一实体。 

步骤103：第一实体根据本侧提供的媒体流安全能力信息和第二实体侧提供的媒体流安全能力信息生成密钥，并将生成的密钥发送给第二实体。 

这里所述第一实体侧提供的媒体流安全能力信息可以为第一实体自身向第二实体提供的媒体流安全能力信息，也可以为第一实体侧其它实体向第二实体提供的媒体流安全能力信息。相应地，所述第二实体提供的媒体流安全能力信息可以为第二实体自身向第一实体提供的媒体流安全能力信息，也可以为第二实体侧其它实体向第一实体提供的媒体流安全能力信息。 

上述媒体流安全能力协商方法中，只有第一实体生成密钥。此后，第一 实体侧和第二实体侧可以利用所述第一实体生成的密钥保护传输的媒体流。 

实际应用中，第二实体也可以生成密钥，其具体实现为：在步骤103之后进一步包括：第二实体根据第一实体侧提供的媒体流安全能力信息和本侧提供的媒体流安全能力信息生成密钥，再将生成的密钥发送给第一实体。之后，第一实体侧和第二实体侧可以利用双方生成的密钥保护传输媒体流。 

实际应用中，第二实体侧其它实体也可以生成密钥，并将生成的密钥发送给第一实体。比如：第一实体为UE，第二实体为MGCF/CSCF，在步骤103之后进一步包括：MGCF/CSCF将所述UE生成的密钥下发给媒体网关MGW/媒体代理MP，MGW/MP根据UE提供的媒体流安全能力信息和自身提供的媒体流安全能力信息生成密钥，并将自身生成的密钥通过MGCF/CSCF发生给主叫UE。 

当然，双方生成密钥之后，第一实体侧和第二实体侧也可以不直接利用双方生成的密钥传输媒体流，而是分别根据本侧生成的密钥和对侧生成的密钥衍生出新的密钥。之后，第一实体侧和第二实体侧再利用衍生出的密钥传输媒体流，同样可以达到保护媒体流的目的。 

不管是一方生成密钥，还是双方都生成密钥，本发明所述的第一实体和第二实体可以分别为：主叫UE和被叫UE，或者主叫UE和被叫侧媒体网关控制功能实体(MGCF)，或者主叫UE和主叫侧会话控制功能实体(CSCF)，或者被叫侧CSCF和被叫UE。 

其中，如果第一实体和第二实体分别为主叫UE和被叫UE，其安全能力协商的方法又可以称为用户到用户的媒体流安全能力协商的方法；而如果第一实体和第二实体为主叫UE和主叫侧CSCF，或者为被叫侧CSCF和被叫UE，或者为主叫UE和被叫侧MGCF，其安全协商的方法又可以称为用户到网络的媒体流安全能力协商的方法。 

在用户到用户媒体流安全能力协商方法中，即第一实体和第二实体分别为主叫UE和被叫UE，所述主叫UE和被叫UE之间可以直接利用密钥保护传输的媒体流； 

在用户到网络的媒体流安全能力协商方法中，如果第一实体和第二实体分别为主叫UE和被叫侧MGCF，所述主叫UE和被叫侧MGCF之间并不直接传输媒体流，所述被叫侧MGCF需要将密钥下发给被叫侧媒体网关(MGW)，由主叫UE和被叫侧MGW之间利用密钥保护传输的媒体流。 

具体分为以下几种情况： 

如果只有一方生成密钥，当被叫侧MGCF接收到主叫UE生成的密钥后，将接收到的密钥下发给被叫侧MGW；或者， 

如果双方都生成密钥，当被叫侧MGCF自身生成密钥后，将主叫UE生成的密钥和自身生成的密钥下发给被叫侧MGW；或者，当被叫侧MGCF自身生成密钥后，将主叫UE生成的密钥和自身生成的密钥衍生出新的密钥，再将新的密钥下发给被叫侧MGW；或者， 

如果双方都生成密钥，当被叫侧MGCF先将主叫UE生成的密钥下发给被叫侧MGW，被叫侧MGW再生成密钥，并将生成的密钥通过被叫侧MGCF返回给主叫侧UE；或者主叫UE和被叫侧MGW再根据本侧和对侧生成的密钥衍生出新的密钥。也就是说，主叫UE根据自身生成的密钥和MGW生成的密钥衍生出新的密钥，被叫侧MGW根据主叫UE生成的密钥和自身生成的密钥衍生出新的密钥。 

如果第一实体和第二实体分别为主叫UE和主叫侧CSCF，或者为被叫侧CSCF和被叫UE，它们之间也并不直接传输媒体流，所述主/被叫侧CSCF还需要将密钥下发给主/被叫侧媒体代理MP，由主/被叫UE和主/被叫侧MP之间利用密钥传输媒体流。以主叫UE和主叫侧CSCF为例，具体也分为以下几种情况： 

如果只有一方生成密钥，当主叫侧CSCF接收到主叫UE生成的密钥后，将接收到的密钥下发给主叫侧MP；或者， 

如果双方都生成密钥，当主叫侧CSCF自身生成密钥后，将主叫UE生成的密钥和自身生成的密钥下发给主叫侧MP；或者，当主叫侧CSCF自身生成密钥后，将主叫UE生成的密钥和自身生成的密钥衍生出新的密钥，再 将新的密钥下发给主叫侧MP；或者， 

如果双方都生成密钥，当主叫侧CSCF先将主叫UE生成的密钥下发给主叫侧MP，主叫侧MP再生成密钥，并将生成的密钥通过主叫侧CSCF返回给主叫UE；或者主叫UE和主叫侧MP再根据本侧和对侧生成的密钥衍生出新的密钥。也就是说，主叫UE根据自身生成的密钥和主叫侧MP生成的密钥衍生出新的密钥，主叫侧MP根据主叫UE生成的密钥和自身生成的密钥衍生出新的密钥。 

被叫CSCF和被叫UE的情况与此相似，此处不再赘述。 

这里所述MP的功能是处理媒体层面的数据流，具体可以为媒体资源处理器(MRFP)、GPRS支持节点(GGSN)、边界网关功能实体(BGF)等功能实体的一个功能单元，也可以是单独的一个功能实体。 

图2是本发明方法实施例二的消息流示意图。实施例二中，第一实体为主叫UE，第二实体为被叫UE，采用用户到用户安全能力协商的方法，并且第一实体和第二实体双方都生成密钥。 

如图2所示，方法实施例二包括以下步骤： 

步骤201：主叫UE向被叫UE发送会话建立请求消息，所述会话建立请求消息携带有主叫UE的媒体流安全能力信息。 

本步骤所述的会话建立请求消息就是一种会话请求消息，比如为邀请(INVITE)消息，所述媒体流安全能力信息包括安全算法，还可以包括需保护的媒体类型、安全传输协议类型和安全前提中一种或几种任意的组合。 

这里所述安全算法可以为完整性安全算法或机密性安全算法，所述需保护的媒体类型可以为文本、音频、视频等，所述安全传输协议类型可以为RTP/SAVP或RTP/SAVPF等。 

所述安全前提是用来指示本次会话对媒体流安全的要求，可以包括第一实体期望的媒体流安全保护的强度标识，比如：强制的(mandatory)、可选的(optional)、可忽略的(none)。所述安全前提还可以包括期望的安 全协商配置结果和当前的配置情况，比如：是否完成协商、接收方向已经完成安全配置、接收和发送方法都完成安全配置等。 

另外，这里所述主叫UE的媒体流安全能力信息可以为主叫UE提供给被叫UE的媒体流安全能力信息。比如：主叫UE可以支持5种安全算法，但可以只选择其中3种安全算法提供给被叫UE，那么，INVITE消息中就可以只携带所提供的3种安全算法即可。当然，主叫UE也可以将支持的5中安全算法都提供给被叫UE，如何确定提供的媒体流安全能力信息则需要由实际情况决定。这里的媒体流安全能力信息相当于一套或一套以上媒体流安全上下文，每一套媒体流安全上下文包括一种安全算法。 

步骤202：被叫UE将携带有自身媒体流安全能力信息的会话建立响应消息返回给主叫UE。 

本步骤所述的会话建立响应消息就是一种会话应答消息，比如为183消息，所述自身媒体流安全能力信息是被叫UE提供的媒体流安全能力信息，可以为能够被主叫UE支持的全部或部分信息。比如：被叫UE从接收到的INVITE消息中确定主叫UE可以支持3种安全算法，如果被叫UE自身只支持其中的两种安全算法，则可以向主叫UE返回可以支持的全部两种安全算法，也可以向主叫UE返回其中一种安全算法。实际应用中，由于媒体流安全能力信息就是一套或一套以上媒体流安全上下文信息的总称，并且，每一套媒体流安全上下文信息都包括安全算法，所以，如果被叫UE返回一种或一种以上安全算法，也可以称为返回一套或一套以上媒体流安全上下文信息。即：被叫UE从主叫UE提供的所有媒体流安全上下文中选择出自身支持的至少一套媒体流安全上下信息，将选择出的至少一套媒体流安全上下文信息作为自身提供的媒体流安全上下文信息，并返回给主叫UE。 

步骤203～步骤204：主叫UE根据自身的媒体流安全能力信息和被叫UE提供的媒体流安全能力信息生成密钥，并将生成的密钥通过确认(PRACK)消息发送给被叫UE。 

这里，所述主叫UE可以从自身和被叫UE都支持的安全算法中确定一 种算法，并根据该算法生成密钥，例如，算法中的密钥长度要求是128位的，则生成对应128位长度的密钥。生成的密钥可以携带于媒体流安全能力信息中。同时，携带密钥的媒体流安全能力信息还可以包括密钥标识、密钥有效期等信息。如果将媒体流安全能力信息称为媒体流安全上下文信息，也就是说，主叫UE可以从被叫UE提供的至少一套的媒体流安全上下文信息中选择出一套，将自身生成的密钥携带于选择出的媒体流安全上下文信息，并通过确认PRACK消息发送给被叫UE。实际应用中，也可以通过UPDATE消息发送给被叫UE。 

步骤205～步骤206：被叫UE根据自身的媒体流安全能力信息和主叫UE的媒体流安全能力信息生成密钥，并将生成的密钥通过200消息返回给主叫UE。 

同样，被叫UE也可以将生成的密钥携带于媒体流安全能力信息中，所述媒体流安全能力信息还可以包括密钥标识、密钥有效期等信息。这里，如果将媒体流安全能力信息称为媒体流安全上下文信息，那么，被叫UE获得主叫UE返回的携带有密钥的媒体流安全上下文信息后，就可以确定该媒体流安全上下文信息中的安全算法是双方都支持的安全算法，直接根据该安全算法生成密钥即可。 

此时，主叫UE和被叫UE都获得了双方生成的密钥，可以利用所述密钥保护传输的媒体流。比如：主叫UE生成密钥X，被叫UE生成密钥Y。当主叫UE需要向被叫UE传输媒体流时，就可以利用密钥X/密钥Y将媒体流保护后传输给被叫UE；反之亦然。 

如果传输的媒体流有多个或多种，在步骤203和步骤205中还可以分别对不同的媒体流生成不同的密钥，并利用密钥标识进行区分。 

实际应用中，如果只需要主叫UE生成密钥，被叫UE和主叫UE利用相同的密钥对媒体流进行保护，则可以省略步骤205和步骤206；或者，如果只需要被叫UE生成密钥，则可以省略步骤203。如果主叫UE和被叫UE需要利用衍生的密钥进行加解密，则可以在步骤206之后，进一步包括：主 叫UE和被叫UE分别根据双方生成的密钥衍生出新的密钥，并将衍生出的密钥作为保护媒体流的密钥。 

当然，本实施例是利用呼叫过程进行安全能力协商，实际应用中，还可以利用专门的安全能力协商的过程，其方法与本实施例相似，只是承载密钥或媒体流安全能力信息的消息不同而已。 

本实施例安全协商结束后，呼叫过程还将继续进行，比如：在步骤206之后，主叫UE还需要向被叫UE发送更新(UPDATE)消息，被叫UE返回200消息等。 

另外，本实施例是主叫UE和被叫UE是通过PRACK消息和200消息传输密钥的。实际应用中，还可以利用其他的消息，比如UPDATE消息和200消息来传输密钥。 

图3是本发明实施例三的流程图。本实施例中，第一实体为主叫UE，第二实体为MGCF；本实施例中，由于第二实体为MGCF，被叫用户为CS域中的用户。当主叫UE与MGCF之间建立呼叫连接之后，主叫UE通过MGCF控制之下的MGW传输媒体流。 

如图3所示，实施例四实现媒体流安全协商的方法包括以下步骤： 

步骤301：主叫UE向MGCF发送会话建立请求消息，所述会话建立请求消息携带有主叫UE提供的媒体流安全能力信息。 

本步骤与实施例二的步骤201相同，此处不再赘述。 

步骤302～步骤303：MGCF通知MGW进行资源预留，MGW向MGCF返回响应消息。 

本步骤中，所述资源预留就是MGCF指示MGW增加实时传输协议(RTP)端点等，至于如何进行资源预留则属于现有技术，此处不再详细描述。 

步骤304：MGCF向主叫UE返回会话建立响应消息，即183消息，所述183消息携带有MGW支持的媒体流安全能力信息。 

这里所述MGW支持的媒体流安全能力信息可以是主叫UE提供并可以由MGW支持的全部信息，也可以是MGCF从所述支持的全部信息选择出的部分信息。 

步骤305～步骤306：主叫UE根据自身提供的媒体流安全能力信息和MGW可以支持的媒体流安全能力信息生成密钥，并将生成的密钥通过PRACK消息发送给MGCF。 

步骤307～步骤309：MGCF根据MGW支持的媒体流安全能力信息和主叫UE提供的媒体流安全能力信息生成密钥，并将主叫UE生成的密钥和自身生成的密钥下发给MGW，并接收MGW返回的响应消息。 

实际应用中，MGCF可以通过修改(MODIFY)消息将密钥下发给MGW。当然，下发的信息还可以包括需要保护的媒体类型、安全传输协议类型、安全算法、密钥标识、密钥有效期等信息。 

步骤310：MGCF将自身生成的密钥通过200消息返回给主叫UE。 

此时，主叫UE和被叫用户一侧的MGW都获得了密钥，就可以利用获得的密钥保护传输媒体流。 

与实施例二相似，主叫UE和MGW还可以利用衍生的密钥传输媒体流。那么，在步骤307中还进一步包括：MGCF将主叫UE生成的密钥和自身生成的密钥衍生出新的密钥；所述步骤308下发的密钥为衍生出的密钥。相应地，所述步骤310之后，主叫UE还需要根据自身生成的密钥和MGCF生成的密钥衍生出新的密钥。 

实际应用中，MGCF自身也可以不生成密钥，而是由MGW生成密钥。这样，MGCF只需将主叫UE生成的密钥下发给MGW即可，同时将MGW生成的密钥发送给主叫UE。 

本实施例是以双方都生成密钥为例进行描述的。实际应用中，如果只需要主叫UE生成密钥，就可以省略步骤307；如果只需要MGCF生成密钥，就可以省略305。 

与实施例二相似，本实施例安全协商结束后，呼叫过程还将继续进行， 比如：在步骤310之后，主叫UE还需要向MGCF发送UPDATE消息，MGCF返回200消息等。 

图4是本发明实施四的消息流示意图。本实施例中，第一实体为主叫UE，第二实体为主叫侧CSCF，采用用户到网络安全能力协商的方法，并且双方都生成密钥。 

本实施例所述第一实体和第二实体都是主叫侧的实体，实际应用中，由于主叫UE发起呼叫时，被叫侧实体也需要参与呼叫过程，所以，被叫侧也有相应的第一实体和第二实体。被叫侧的第一实体和第二实体也可以如主叫侧一样生成密钥，并利用密钥进行媒体流的传输。但需要注意的是，主叫侧和被叫侧进行安全协商完全是独立的。比如：主叫侧进行安全协商，并生成密钥，被叫侧可以不进行安全协商，仍然采用普通的呼叫过程。也就是说，呼叫结束之后，主叫侧和被叫侧都可以分别采用各侧生成的密钥保护各侧的媒体流，也可以只有一侧采用密钥保护传输的媒体流。 

本实施例中，假设主叫侧和被叫侧都进行安全能力协商。 

如图4所示，实施例四实现媒体流安全协商的方法包括以下步骤： 

步骤401：主叫UE向主叫侧CSCF发送会话建立请求消息，所述会话建立请求消息携带有主叫UE的媒体流安全能力信息。 

与实施例二相似，本步骤所述的会话建立请求消息为INVITE消息，所述媒体流安全能力信息包括安全算法。 

步骤402：主叫侧CSCF删除会话建立请求消息中主叫UE的安全算法，并将所述会话建立请求消息继续发送给被叫侧CSCF。 

由于主叫侧和被叫侧安全协商是完全独立的，被叫侧不需要获取主叫UE提供的媒体流安全能力信息，所以，可以由主叫侧CSCF将主叫UE提供的安全算法删除。当然，如果被叫侧CSCF直接忽略掉会话建立请求中的主叫UE的安全算法，也可以不删除。 

步骤403：被叫侧CSCF将被叫侧MP支持的安全算法添加到会话建立 请求消息，并将所述会话建立请求消息继续发送给被叫UE。 

步骤404：被叫UE将携带有自身媒体流安全能力信息的会话建立响应消息返回给被叫侧CSCF。 

与实施例二相同，本步骤所述的会话建立响应消息为183消息。 

步骤405：被叫侧CSCF记录被叫UE的媒体流安全能力信息，再删除会话建立响应消息中被叫UE的安全算法，并将所述会话建立响应消息继续返回给主叫侧CSCF。 

步骤406：主叫侧CSCF将主叫侧MP支持的安全算法添加到会话建立响应消息中，并继续返回给主叫UE。 

与实施例二的步骤202相似，这里所述主叫MP支持的安全算法可以是主叫UE提供并由主叫侧MP支持的全部安全算法，也可以是主叫侧CSCF从所述全部安全算法中选择出的部分安全算法。 

步骤407～步骤408：主叫UE根据自身的媒体流安全能力信息和主叫侧CSCF返回的媒体流安全能力信息生成密钥X1，并将生成的密钥X1通过PRACK消息发送给主叫侧CSCF。 

所述步骤407～步骤408与实施例二中步骤203～步骤204相似，只是主叫UE接收到的是由主叫侧CSCF提供的主叫侧MP支持的媒体流安全能力信息。 

步骤409：主叫侧CSCF记录PRACK消息中媒体流安全能力信息，再删除PRACK消息中的密钥X1、安全算法，并继续将PRACK消息发送给被叫侧CSCF。 

这里，由于主叫侧和被叫侧安全协商是独立的，被叫侧不需要主叫UE生成的密钥，所以需要将PRACK消息中主叫侧密钥、安全算法等相关信息删除。当然，如果被叫侧CSCF忽略PRACK消息中主叫侧密钥X1和安全算法，也可以不删除。 

步骤410～步骤411：被叫侧CSCF根据被叫侧MP支持的媒体流安全能力信息和被叫UE提供的媒体流安全能力信息生成密钥Y1，并将生成的 密钥Y1添加到PRACK消息中发送给被叫UE。 

步骤412～步骤413：被叫UE记录密钥Y1，再根据自身的媒体流安全能力信息和被叫侧MP支持的媒体流安全能力生成密钥Y2，并将生成的密钥Y2通过200消息返回给被叫侧CSCF。 

步骤414～步骤415：被叫侧CSCF将密钥Y1和密钥Y2下发给被叫侧MP，再删除200消息中密钥Y2，并将所述200消息继续返回给主叫侧CSCF。 

步骤416～步骤418：主叫侧CSCF根据事先记录的主叫UE的媒体流安全能力信息和主叫侧MP支持的媒体流能力信息生成密钥X2，再将密钥X1和密钥X2下发给主叫侧MP，并将生成的密钥X2添加到200消息中继续返回给主叫UE。 

此时，主叫UE和主叫侧CSCF获得了密钥X1和密钥X2，被叫侧CSCF和被叫UE获得了密钥Y1和密钥Y2。在之后传输媒体流的过程中，主叫UE和主叫侧CSCF将利用密钥X1和密钥X2保护传输媒体流，被叫侧CSCF和被叫UE将利用密钥Y1和密钥Y2保护传输媒体流。也就是说，在整个传输过程中，媒体流并不是全程保护，而是分段进行保护的。 

与实施例三相似，步骤417中，主叫侧CSCF也可以不将密钥X1和密钥X2下发给主叫侧MP，而是利用密钥X1和密钥X2衍生出新的密钥X，并将衍生出的密钥X’下发给主叫侧MP。相应地，步骤418之后，主叫UE也将根据密钥X1和密钥X2衍生出新的密钥X’。这里所述是主叫侧的情况，被叫侧情况与之相似，此处不再赘述。 

与实施例三相似，主叫侧CSCF自身也可以不生成密钥，而是由主叫侧MP生成密钥。这样，主叫侧CSCF只需将主叫UE生成的密钥下发给MP即可，之后将MP生成的密钥发送给主叫UE。 

对于被叫侧一方，被叫侧CSCF自身也可以不生成密钥，而是由被叫侧MP先生成密钥，并将生成的密钥通过被叫侧CSCF发送给被叫UE；当被叫UE生成密钥后，再通过被叫侧CSCF将被叫UE生成的密钥下发给被叫侧MP。 

本实施例是以双方都生成密钥为例进行描述的，实际应用中，主叫侧和被叫侧也可以分别只有一方生成密钥。比如：如果主叫侧只需要由主叫UE生成密钥，则可以省略步骤417，如果主叫侧只需要主叫侧CSCF生成密钥，则可以省略步骤407。进一步地，主叫侧CSCF可以在步骤408接收到PRACK消息后，就可以将密钥下发给主叫侧MP，而不必等到200消息时才下发。这里所述为主叫侧的情况，被叫侧情况与此相似，此处不再赘述。 

当然，与实施例二～实施三相似，本实施例步骤418之后，还需要继续执行呼叫其他流程，比如：主叫UE通过主叫侧CSCF、被叫侧CSCF向被叫UE发送UPDATE消息，并接收返回的200消息等。 

另外，本实施例所述的CSCF可以为代理的CSCF，即P-CSCF，也可以为服务的CSCF，即S-CSCF。 

上述实施例二～实施例四中，第一实体需要通过会话建立请求消息向第二实体发送自身提供媒体流安全能力信息，第二实体根据第一实体的媒体流安全能力信息再返回自身提供的媒体流安全能力信息。实际应用中，第一实体和第二实体支持媒体流安全传输的能力可能不相同。为了第二实体可以灵活地选择第一实体的媒体流安全能力信息，第一实体可以事先设置一个或一个以上媒体流安全能力信息，第二实体从所述媒体流安全能力信息中选择一个。 

图5是实现选择媒体流安全能力信息方法实施例五的消息流示意图。如图5所示，该方法为： 

步骤501：第一实体向第二实体发送会话建立请求消息，所述会话建立请求消息包含一个或一个以上媒体流安全能力信息。 

步骤502～步骤503：第二实体从所述媒体流安全能力信息中选择出一个，根据选择出的媒体流安全能力信息和本侧支持的媒体流安全能力信息确定本侧需提供的媒体流安全能力信息，再将本侧提供的媒体流安全能力信息通过会话建立响应消息返回给第一实体。 

这里所述媒体流安全能力信息还可以包含优先级，当第二实体选择媒体流 安全能力信息时，可以按照优先级别进行选择，并将自身能够支持的最高一级的媒体流安全能力信息作为选择出的媒体流安全能力信息。 

本发明的实施例都是以第二实体可以支持安全传输为例进行描述的。实际应用中，如果第二实体不支持第一实体提供的安全算法，或者第二实体不具备安全传输媒体流的能力，那么，当接收到会话建立请求消息时，第二实体将返回失败响应消息，比如4xx消息。 

对于这种情况，如果要保证呼叫成功，可以在事先设置基本会话描述配置，并且基本会话描述配置不包含媒体流安全能力信息。当第二实体从接收到的会话建立请求消息中找不到支持的媒体流安全能力信息，或者不支持选择媒体流安全能力信息的能力时，可以直接将基本会话描述配置作为第一实体提供给自身的配置，此后的呼叫流程将按照现有技术的呼叫流程进行。 

与实施例二相似，实施例三～实施例五中，当第一实体发送的INVITE消息中，所述媒体流安全能力信息除了包括安全算法，还可以包括需保护的媒体类型、安全传输协议类型、安全前提中一种或几种任意的组合。第一实体和第二实体之间交互的其他消息中，所述媒体流安全能力信息也可以包括媒体类型、安全传输协议类型、安全前提中一种或几种任意的组合，至于是否包括密钥和安全算法则与具体的实现相关。比如：在实施例四的步骤409中，就需要主叫侧CSCF将媒体流安全能力信息中的密钥和安全算法删除，此处不再一一列举。 

与实施例二相似，实施例三～实施例五中，可以将生成的密钥携带于媒体流安全能力信息中发送给对方。此时，所述媒体流安全能力信息中还可以包括密钥有效期等参数。如果有多个需要保护的媒体流，每次还可以针对每一个不同的媒体流生成不同的密钥，所述媒体流安全能力信息中还可以包括密钥标识，以区分对应的媒体流。 

实施例二～实施例五中，所述安全算法可以在rfc4568中定义的媒体流安全描述协议(SDES)中a＝crypto头域中作为crypto-suite参数来携带；所述生成的密钥、密钥标识、密钥有效期等可以在SDES协议中的a＝crypto头域中的key-params参数来携带，具体的可以使用key-method参数指示密钥携带方法， 例如内联(inline)方法。使用key-info参数来携带密钥以及密钥标识和有效期等参数。SDES中对应SRTP协议的可以使用如下头域：srtp-crypto-suite携带安全算法，srtp-key-method参数指示密钥携带方法，例如是用内联(inline)头域表示，srtp-key-info参数携带密钥密钥标识和有效期等参数。对于仅仅携带算法而没有携带密钥的a＝crypto头域，可以仅仅使用crypto-suite头域，或者使用key-params参数中的密钥字段，但将key-info参数设置成一个特殊的值表示没有有效的密钥，例如将key-info字段都标识成空值NULL，或者设置成随便一个没有意义的值。 

实施例二～实施例五中，如果采用多媒体因特网密钥协商(MIKEY)管理协议，其中的安全算法、包括密钥长度、密钥产生率等的安全上下文都可以携带于RFC3830 MIKEY协议中安全策略负载(Security Policy payload)字段中定义的参数中。所述生成的密钥、密钥有效期等可以携带于MIKEY中密钥传输负载(KEMAC，Key data transport payload)字段中。整个MIKEY消息则可以携带于RFC4567规定的a＝key-mgmt SDP属性字段中。 

实施例二～实施例五中，所述安全算法也可以在会话发起协议(SIP)中扩展一个安全算法头域来携带；同样，所述生成的密钥、密钥标识、密钥有效期等也可以在SIP协议来中扩展对应的头域来携带。 

应用本发明实施例方案，呼叫中的第一实体和第二实体都可以获得密钥，从而实现安全传输媒体流的目的。至于是采用用户到用户安全能力协商的方法，还是用户到网络安全能力协商的方法，是采用一方生成密钥的方法，还是双方都生成密钥或者进一步衍生出新的密钥的方法，第一实体和第二实体之间需要协商的具体内容，协商过程采用是否采用呼叫过程中的消息，采用呼叫过程中的哪些消息，协商过程中的信息如何携带于消息中等情况都可以根据网络部署应用本发明方案，此处不再一一列举。 

针对本发明提出的媒体流安全能力协商的方法，本发明还提出一种媒体流安全能力协商的系统。 

图6显示了实现媒体流安全能力协商系统实施例一的基本结构示意图。如图6所示，该系统包括： 

第一实体601，用于向第二实体602发送会话建立请求消息，接收返回的会话响应消息，根据本侧提供的媒体流安全能力信息和第二实体602提供的媒体流安全能力信息生成密钥，并将生成的密钥发送给第二实体602； 

第二实体602，用于接收第一实体601发送的会话建立消息，向第一实体601提供本侧媒体流安全能力信息，并接收第一实体601生成的密钥。 

其中，第一实体601中包括密钥生成单元6011，用于根据本侧已有的媒体流安全能力信息和第二实体602提供的媒体流安全能力信息生成密钥；第一实体601中还包括收发单元6012，用于收发与第二实体602之间交互的消息。 

当然，如果需要双方都生成密钥，第二实体602中也可以包括密钥生成单元6021和收发单元6022，其功能与第一实体601中的相似，此处不再详细描述。 

这里所述第一实体601可以为主叫UE，第二实体602可以为被叫UE。 

所述第一实体601还可以为主叫UE，第二实体602为MGCF，此时，该系统还包括MGW，用于接收从MGCF下发的密钥。 

所述第一实体601还可以为主叫UE，第二实体602为主叫侧CSCF；或者，第一实体601为被叫侧CSCF，第二实体为被叫UE；在这种情况下，该系统还包括MP，用于接收从CSCF下发的密钥。 

图7是本发明系统实施例二的基本结构示意图。如图7所示，本实施例包括： 

主叫UE701，用于向MGCF702发送会话建立消息，接收返回的会话响应消息，根据本侧提供的媒体流安全能力信息和MGCF702提供的媒体流安全能力信息生成密钥，并将生成的密钥发送给MGCF702； 

MGCF702，用于向主叫UE701提供MGW703可以支持的媒体流安全能力信息，接收主叫UE701生成的密钥，根据主叫UE701提供的媒体流安全 能力信息和MGW703支持的媒体流安全能力信息生成密钥，将主叫UE701生成的密钥和自身生成的密钥下发给MGW703； 

MGW703，用于接收从MGCF702下发的密钥。 

当需要进行安全能力协商时，主叫UE701向MGCF702发送携带有自身媒体流安全能力信息的INVITE消息；MGCF702通知MGW703进行资源预留，并将MGW703支持的媒体流安全能力信息携带于183消息中返回给主叫UE701；主叫UE701根据自身的媒体流安全能力信息和MGW703支持的媒体流安全能力信息生成密钥X，并将密钥X携带于PRACK消息中发送给MGCF702；MGCF702根据主叫UE701提供的媒体流安全能力信息和MGW703支持的媒体流安全能力信息生成密钥Y，并将密钥X和密钥Y下发给MGW701，同时将密钥Y通过200消息返回给主叫UE701。 

此时，主叫UE701和MGW703都获得了密钥X和密钥Y，就可以利用密钥X和密钥Y进行媒体流传输，达到保护媒体流的目的。当然，也可以由主叫UE701和MGCF702根据密钥X和密钥Y衍生出新的密钥，并且，MGCF702将衍生出的密钥下发给MGW701。 

图8是本发明系统实施例三的基本结构示意图。如图8所示，本实施例包括： 

主叫UE801，用于根据自身媒体流安全能力信息和主叫侧CSCF802提供的媒体流安全能力信息生成密钥X1，并将生成的密钥X1发送给主叫侧CSCF802； 

主叫侧CSCF802，用于接收主叫UE801生成的密钥X1，根据主叫UE801的媒体流安全能力信息和主叫侧MP803支持的媒体流安全能力信息生成密钥X2，并将密钥X1和密钥X2下发给主叫侧MP803，同时，将密钥X2发送给主叫UE801； 

被叫侧CSCF804，用于根据被叫侧CSCF806支持的媒体流安全能力信息和被叫UE805的媒体流安全能力信息生成密钥Y1，并将生成的密钥Y1发送给被叫UE805，接收被叫UE805生成的密钥Y2，并将密钥Y1和Y2 下发给被叫侧MP806； 

被叫UE805，接收被叫侧CSCF806生成的密钥Y1，并根据被叫侧CSCF806的媒体流安全能力信息和被叫侧MP806支持的媒体流安全能力信息生成密钥Y2，将密钥Y2发送给被叫侧CSCF806。 

当需要进行媒体流安全能力协商时，在主叫侧，主叫UE801向主叫侧CSCF802发送携带有自身媒体流安全能力信息的INVITE消息；主叫侧CSCF802将主叫侧MP803支持的媒体流安全能力信息携带于183消息中返回给主叫UE801；主叫UE801根据自身的媒体流安全能力信息和主叫侧MP803支持的媒体流安全能力信息生成密钥X1，并将密钥X1携带于PRACK消息中发送给主叫侧CSCF802；主叫侧CSCF802根据主叫UE801提供的媒体流安全能力信息和MP803支持的媒体流安全能力信息生成密钥X2，并将密钥X1和密钥X2下发给MP803，同时将密钥X2通过200消息返回给主叫UE801。至于被叫侧的情况与主叫侧相似，此处不再详细描述。 

其中，系统实施例一和系统实施例二的实体中还包括密钥生成单元和收发单元，其功能和结构与图6中的相同，此处不再赘述。 

上述图1至图8中描述了实现媒体流安全能力协商的方法和系统等情况。实际应用中，媒体流安全能力信息可以包含一套或多套媒体流安全能力上下文信息，媒体流安全能力协商也可以称为媒体流安全上下文协商。另外，方法实施例二中描述了主叫UE和被叫UE之间进行媒体流安全上下文协商的方法，本申请还在以下的方法实施例六至方法实施例八中提出另外几种主叫UE和被叫UE之间进行媒体流安全上下文协商的方法。 

图9是本发明方法实施例六的消息流示意图。方法实施例六中，第一实体为主叫UE，第二实体为被叫UE。实际应用中，第一实体和第二实体也可以是MGCF/MGW，具体流程与下述类似，本实施例不再单独描述。 

方法实施例二和方法实施例六的共同之处在于：主叫UE通过会话请求消息将自身提供的媒体流安全上下文信息发送给被叫UE，所述媒体流安全上下文信息包括安全算法；主叫UE接收被叫UE通过会话应答消息提供的 媒体流安全上下文信息，所述被叫UE提供的媒体流安全上下文是根据主叫UE提供的媒体流安全上下文信息所确定的；主叫UE和被叫UE根据双方提供的包括安全算法的媒体流安全上下文信息获得密钥。 

其中，至于主叫UE和被叫UE根据双方提供的包括安全算法的媒体流安全上下文信息获得密钥等情况可以具体参见方法实施例二和方法实施例六。其中，方法实施例六可以如图9所示，可以包括以下步骤： 

步骤901：主叫UE产生本侧的密钥生成参数Pa。 

本步骤中，Pa是用来生成媒体流安全密钥的一个参数，具体实现时可以采用现有技术而生成的一个随机数(nonce)。 

步骤902：主叫UE向被叫UE发送会话请求消息，其中携带有主叫UE提供的媒体流安全上下文信息。例如：主叫UE提供了2套媒体流安全上下文信息，可以表示为：(算法1，Pal)；(算法2，Pa2)。 

本步骤所述的会话请求消息是会话发起协议SIP的邀请(INVITE)消息，也可以是更新(UPDATE)消息。所述媒体流安全上下文信息至少包括密钥生成参数Pa和安全算法，此外，还可能包括密钥有效期(lifetime)和密钥标识(key identifier)中一种或两种。会话请求消息中可以包括至少一套的媒体流安全上下文信息，供被叫UE来选择，这里的每一套媒体流安全上下文信息可以按照优先级来进行排列或者每套都增加对应的优先级指示，表明主叫对各套媒体流安全上下文信息选择的优先程度。另外，如果是多套媒体流安全上下文信息，则步骤901中将会为每一套媒体流安全上下文生成各自的密钥生成参数。 

这里的媒体安全算法可以为完整性安全算法或机密性安全算法的一种或者两种的组合。 

步骤903：被叫UE收到会话请求消息后，产生本侧的密钥生成参数Pb。 

步骤904：被叫UE向主叫UE发送183响应消息，其中携带本侧提供的媒体流安全上下文信息。例如(算法2，Pb) 

这里，被叫UE提供的媒体流安全上下文信息是被叫UE根据会话请求 消息中主叫UE提供所有的媒体流安全上下文信息中确定自身需要提供的媒体流安全上下文信息。也就是说，如果主叫UE向被叫UE提供至少一套的媒体流安全上下文信息时，被叫UE根据自身支持的情况，从主叫提供的所有媒体流安全上下文信息中选择并确定一套，作为自身提供给主叫UE的媒体流安全上下文信息。当然，被叫UE并不是直接将选择的媒体流安全上下文信息发送给主叫UE，还需要将自身的密钥生成参数作为选择出的媒体流安全上下文信息中的密钥生成参数发送给主叫UE，即：发送给主叫的媒体流安全上下文信息应该包括密钥生成参数Pb和对应选择的安全算法。 

另外，如果主叫UE只提供一套媒体流安全上下文信息，那么，被叫UE也可以不进行选择，主叫UE和被叫UE根据双方提供的包括安全算法的媒体流安全上下文信息获得密钥的方法为：被叫UE根据的主叫UE提供的媒体流安全上下文中的密钥生成参数和自身的密钥生成参数产生密钥，主叫UE根据被叫UE提供的媒体流安全上下文中的密钥生成参数和自身的密钥生成参数产生密钥。 

实际应用中，本步骤所述的会话响应消息也可以为200响应消息。 

步骤904，：被叫UE根据密钥生成参数Pa和Pb衍生出媒体流安全密钥。 

本步骤的参数Pa是被叫UE选择出的媒体流安全上下文中的密钥生成参数，参数Pb是被叫UE的密钥生成参数，即：被叫UE根据选择出的媒体流安全上下文中的密钥生成参数和自身的密钥生成参数产生密钥。 

这里，步骤904和904’没有必然的先后顺序。实际应用中，步骤901和步骤903中的密钥生成参数也可以是已有的，或者由主叫UE和被叫UE事先生成的，没有必要在本流程中临时生成。 

步骤905：主叫UE收到被叫UE发送的响应消息后，根据密钥生成参数Pa和Pb衍生出媒体流安全密钥。 

同样，本步骤是主叫UE根据步骤904中被叫UE发送的媒体流安全上下文中的密钥生成参数Pb和自身的密钥生成参数Pa产生密钥。 

这里衍生密钥的方法可以使用主叫UE和被叫UE事先规定好的密钥产 生函数，例如使用如下的函数： 

KEY＝KDF(Pa，Pb，[other]) 

KEY是衍生出的加密媒体的密钥； 

KDF是一个密钥生成函数，具体的可以使用一个哈希Hash函数。[other]是其它相关参数，例如RTP流的标识SSRC等信息，这样就可以用来进一步的为每个RTP流产生一个密钥；或者[other]代表所要产生的KEY的密钥的长度；也可以不使用[other]参数。 

此后，主叫UE和被叫UE还需要继续后续的呼叫流程。 

由于主叫UE和被叫UE都获得了密钥，此后就可以利用获得的密钥保护传输的媒体流。 

本实施例中，所述安全算法可以使用RFC4568中定义的媒体流安全描述协议(SDES)中的a＝crypto头域作为crypto-suite参数来携带；所述密钥生成参数Pa和Pb、密钥标识、密钥有效期等参数可以在SDES协议a＝crypto头域中的key-params参数来携带，具体的可以使用key-method参数指示方法，例如内联(inline)方法或者key-method-ext扩展的新的方法，使用key-info参数来携带密钥生成参数Pa和Pb以及密钥标识和有效期等参数。SRTP协议对应的SDES协议中的头域可以按照如下的方法使用：srtp-crypto-suite头域携带安全算法，srtp-key-method参数指示携带方法，例如内联(inline)方法或者使用key-method-ext扩展的新的方法，srtp-key-info参数携带密钥生成参数Pa和Pb以及密钥标识和有效期等参数。使用SDES携带多套媒体流安全上下文信息可以使用多个a＝crypto头域进行携带，优先级信息可以按照a＝crypto头域的排列顺序标识。 

本实施例中，如果采用多媒体因特网密钥协商(MIKEY)管理协议，其中的安全算法、包括密钥长度、密钥产生率等的安全上下文都可以携带于RFC3830 MIKEY协议中安全策略负载(Security Policy payload)字段中定义的各个参数中。所述密钥生成参数Pa和Pb可以携带于MIKEY中密钥传输负载(KEMAC，Key data transport payload)字段中的Key data sub-payload字段。 整个MIKEY消息则可以携带于RFC4567规定的a＝key-mgmt SDP的属性字段中。使用多个a＝key-mgmt头域也可以可以携带多套媒体流安全上下文信息，优先级信息可以按照a＝key-mgmt头域的排列顺序标识。 

以下的方法实施例七和方法实施例八的共同之处在于：主叫UE将携带有媒体流保护指示信息的会话请求消息发送给被叫UE；被叫UE检查媒体流保护指示信息，确定自身支持媒体流保护，被叫UE和主叫UE获得包括安全算法和密钥的媒体流安全上下文。 

也就是说，被叫UE在接收到媒体流保护指示信息时，可以根据媒体流保护指示信息确定本次会话的媒体流要求保护，判断自身是否支持媒体流保护，如果自身支持，则可以继续执行本流程。实际应用中，如果被叫UE确定自身不支持媒体流保护，就可以直接结束会话。 

至于被叫UE与主叫UE如何获得包括安全算法和密钥的媒体流安全上下文信息的方法则可以包括以下三种方法： 

第一种方法是：被叫UE将自身提供的至少一套媒体流安全上下文信息发送给主叫UE，每一套媒体流安全上下文信息包括安全算法和对应的密钥；主叫UE直接从被叫UE发送的所有的媒体流安全上下文信息中选择出一套，并将选择出的一套媒体流安全上下文信息发送给被叫UE。 

也就是说，由于被叫UE提供的媒体流安全上下文信息中已经存在密钥，主叫UE只需要从中选择一套并通知被叫UE，双方就可以确定安全算法和对应的密钥，从而达到协商的目的。 

当然，实际应用中，主叫UE从被叫UE发送的所有的媒体流安全上下文信息中选择出一套，以及将选择出的一套媒体流安全上下文信息发送给被叫UE之间，该方法还可以进一步包括：主叫UE将自身生成的新的密钥作为所述选择出的一套媒体流安全上下文中的密钥。 

也就是说，虽然供主叫UE选择的媒体流安全上下文信息是由被叫UE提供的，但主叫UE也完全可以自行确定密钥，只是确定的密钥需要符合所选择的媒体流安全上下文中的安全算法的规定即可。 

第二种方法是：被叫UE将自身提供的至少一套媒体流安全上下文信息发送给主叫UE，每一套媒体流安全上下文信息包括安全算法和对应的密钥；主叫UE从被叫UE提供的所有媒体流安全上下文信息中选择出自身支持的至少一套媒体流安全上下信息，将选择出的至少一套媒体流安全上下文信息发送给被叫UE；所述被叫UE从主叫UE提供的至少一套的媒体流安全上下文信息中选择出一套，并发送给主叫UE。 

也就是说，主叫UE可以从被叫UE提供的媒体流安全上下文信息进行选择，但最后决定使用哪一套仍然由被叫UE确定，这里主叫UE也可以将自身生成的新的密钥作为所述选择出的一套媒体流安全上下文中的密钥。这样，经过协商之后，双方都可以确定安全算法和对应的密钥，同样达到协商的目的。 

第三种方法是：被叫UE将媒体流保护指示信息返回给主叫UE；主叫UE检查媒体流保护指示信息，确定所述被叫UE支持媒体流保护；主叫UE将自身提供的至少一套媒体流安全上下文信息发送给被叫UE，每一套媒体流安全上下文信息包括安全算法和对应的密钥；被叫UE从主叫UE发送的所有的媒体流安全上下文信息中选择出一套，并将选择出的一套媒体流安全上下文信息发送给主叫UE。 

也就是说，当被叫UE检查到媒体流保护指示信息时，可以确定本次会话的媒体流需要进行保护。如果被叫UE自身支持媒体流保护，则向主叫UE返回相应的媒体流保护指示信息。当主叫UE接收到被叫UE的媒体流保护指示信息时，就可以确定主叫UE是支持本次会话的媒体流保护的。此后，双方再继续进行协商，确定一套媒体流安全上下文信息，就可以利用其中密钥对后续传输的媒体流进行保护了。 

这里，被叫UE从主叫UE发送的所有的媒体流安全上下文信息中选择出一套，以及将选择出的一套媒体流安全上下文信息发送给主叫UE之间，该方法也可以进一步包括：被叫UE将自身生成的新的密钥作为选择出的一套媒体流安全上下文信息中的密钥。 

也就是说，虽然供被叫UE选择的媒体流安全上下文信息是由主叫UE提供 的，但被叫UE也完全可以自行确定密钥，只是确定的密钥需要符合所选择的媒体流安全上下文中的安全算法的规定即可。 

图10是本发明方法实施例七的消息流示意图。实施例七中，第一实体为主叫UE，第二实体为被叫UE。主叫或者被叫也可以是媒体网关控制功能实体/媒体网关功能实体(MGCF/MGW)，具体流程类似。 

如图10所示，方法实施例七包括以下步骤： 

步骤1001：主叫UE向被叫UE发送INVITE消息，其中携带媒体流安全保护的指示信息，来指示需要媒体流安全保护的媒体，例如：音频1和视频2。 

具体实施时，媒体流安全保护的指示信息可以使用IETF的草案draft-ietf-mmusic-securityprecondition-04.txt中描述的安全前提的使用方法来指示需要保护的媒体。也可以不使用安全前提的方法，而使用将需要保护的媒体的传输协议设置为安全传输协议的方法来指示，例如将媒体传输协议设置为RTP/SAVP。也可以使用RFC4566中的k＝prompt头域来指示需要媒体流安全保护的媒体。 

步骤1002：被叫UE收到会话请求消息后，检查媒体流安全保护的指示信息，确定自身支持媒体流保护；返回183应答消息，其中携带支持的需要媒体流安全保护的媒体对应的本侧的媒体安全上下文信息，例如：被叫UE仅仅支持视频2，并为视频2提供2套媒体流安全上下文信息，(算法1，密钥1)；(算法2，密钥2)。 

所述媒体流安全上下文信息至少包括密钥和媒体安全算法，此外，还可以包括密钥有效期(lifetime)和密钥标识(key identifier)中的一种或两种的组合。响应消息中可以包括多套媒体流安全上下文信息，供主叫UE来选择。这里的每一套媒体流安全上下文信息可以按照优先级来进行排列或者每套都增加对应的优先级指示，表明被叫UE对各套媒体流安全上下文信息的选择的优先程度。 

这里的媒体安全算法可以为完整性安全算法或机密性安全算法的一种 或者两种的组合。这里使用的消息也可以是200应答消息。 

步骤1003：主叫UE向被叫UE发送PRACK响应消息，其中携带本侧的提供的媒体流安全上下文信息，例如：选择183消息中的(算法2，密钥2)。 

这里主叫UE对于183消息的处理方式有两种，一种是PRACK消息中的媒体流安全上下文信息是主叫UE根据183消息中被叫UE提供的媒体流安全上下文信息中确定自身需要提供的媒体流安全上下文信息。也就是说，如果被叫UE提供至少一套的媒体流安全上下文信息时，主叫UE可以根据自身支持的情况，从被叫提供的所有媒体流安全上下文信息中选择并确定一套或一套以上，作为自身提供给被叫UE的媒体流安全上下文信息并利用PRACK消息等发送给被叫UE。此后，被叫UE在收到PRACK后，从PRACK消息中媒体流安全上下文信息中最终确定一套，并通过PRACK消息后的200消息发送给主叫UE，步骤1003和1004描述这种情况。 

另外一种处理方式是主叫UE收到183响应后，直接确定最终使用的一套媒体流安全上下文信息，并在PRACK消息中发送给被叫UE，被叫UE在收到PRACK后，再发送的200响应中就不一定要携带媒体流安全上下文信息了。 

本步骤中，PRACK中选择和提供的媒体流安全上下文信息至少包括密钥和对应的安全算法，此外，还可以包括密钥有效期(lifetime)和密钥标识(key identifier)中的一种或两种的组合。不论PRACK中携带几套媒体流安全上下文，PRACK中的媒体流安全上下文信息中的密钥都可以与被叫中发送的密钥不同，例如，这里可以不使用“密钥2”，而主叫自己产生一个“密钥3”并发送给被叫。这里的主被叫使用不同的密钥的使用方法可以参考RFC4568中的主被叫密钥不同的使用方法。 

如果主叫UE收到被叫UE发送的消息不是183消息，而是200消息，则本步骤所述的确认消息为ACK确认消息，消息携带的内容类似。 

步骤1004：被叫UE向主叫UE返回PRACK对应的200消息，其中携 带协商被叫UE选定的媒体流安全上下文信息，本实施例中为(算法2，密钥2)。 

此后，主叫UE和被叫UE还需要继续后续的呼叫流程。 

由于主叫UE和被叫UE都获得了对应的密钥，可以利用所述密钥保护传输的媒体流。 

本实施例中，所述安全算法可以在RFC4568中定义的媒体流安全描述协议(SDES)中的a＝crypto头域作为crypto-suite参数来携带；所述密钥、密钥标识、密钥有效期等参数可以在SDES协议a＝crypto头域中的key-params参数来携带，具体的可以使用key-method参数指示携带方法，例如内联(inline)方法或者使用key-method-ext扩展的方法。使用key-info参数来携带密钥以及密钥标识和有效期等参数。对应SRTP协议的SDES的头域可以按照如下的方法使用：srtp-crypto-suite携带安全算法，srtp-key-method指示携带方法，例如内联(inline)方法或者使用key-method-ext扩展的方法，srtp-key-info携带密钥以及密钥标识和有效期等参数。使用SDES可以携带多套媒体流安全上下文信息，即使用多个a＝crypto头域即可以进行携带，优先级信息可以按照a＝crypto头域的排列顺序标识。 

本实施例中，如果采用多媒体因特网密钥协商(MIKEY)管理协议，其中的安全算法、密钥有效期等的安全上下文都可以携带于RFC3830 MIKEY协议中安全策略负载(Security Policy payload)字段中定义的参数中。所述密钥以及密钥标识可以携带于MIKEY中密钥传输负载(KEMAC，Key data transportpayload)字段中的Key data sub-payload字段。整个MIKEY消息则可以携带于RFC4567规定的a＝key-mgmt SDP属性字段中。使用多个a＝key-mgmt头域也可以携带多套媒体流安全上下文信息，优先级信息可以按照a＝key-mgmt头域的排列顺序标识。 

图11是本发明方法实施例八的消息流示意图，包括以下步骤： 

步骤1101：主叫UE向被叫UE发送INVITE消息，其中携带媒体流安全保护的指示信息，来指示需要媒体流安全保护的媒体，例如：音频1和视 频2。 

具体实施时，媒体流安全保护的指示信息可以使用IETF的草案draft-ietf-mmusic-securityprecondition-04.txt中描述的安全前提的方法来指示需要保护的媒体。这里的用法和IETF的草案中的用法不同的地方是这里的INVITE和后续的183消息不携带安全算法和密钥等信息，例如，如果使用SDES协议，就不携带a＝crypto：..头域，而在后续的PRACK和200消息中才携带安全算法和密钥等信息，相应的，主叫UE和被叫UE发送的INVITE和后续的183消息中的安全前提的状态则设置为实际状态的值即可，具体值的设置可以参考RFC3312和所述的安全前提的IETF的草案中的状态设置方法，因为这里INVITE和后续的183消息中没有携带安全算法和密钥等信息，所以后续的PRACK和200消息中的安全前提的设置方法可以采用如下的方法进行设置：方法一，PRACK中的设置方法还是设置实际的状态值，而200中的目前状态值设置为最终的状态值，例如，a＝curr:sec e2e sendrecva＝des:sec mandatory e2e sendrecv；方法二，PRACK和200消息中的目前状态值仍然设置为实际的状态值，后续的安全前提的状态值使用update和对应的200消息进行最后的确认设置，具体的方法参见RFC3312和所述的安全前提的IETF草案。这里也可以不使用安全前提的方法，而使用将需要保护的媒体的传输协议设置为安全传输协议的方法来指示本次会话媒体流需要安全保护，例如将媒体传输协议设置为RTP/SAVP。也可以使用RFC4566中的k＝prompt头域来指示需要媒体流安全保护的媒体。 

步骤1102：被叫UE收到INVITE消息后，检查媒体流安全保护的指示信息，确定自身支持保护指示出的需要媒体流安全保护的媒体，返回183应答消息，其中携带本侧的媒体流安全保护的指示信息，指示出本侧支持的需要媒体流安全保护的媒体，例如，视频2。 

与方法实施例七不同的是，本步骤并不直接向主叫UE返回提供的媒体流安全上下文信息，而仅仅将自身可以支持媒体流保护的信息通知给主叫UE。其中，183消息中的参数具体设置的方法类似于INVITE消息中的设置 万法。 

步骤1103：主叫UE检查被叫UE返回的指示信息，确定被叫UE支持指示出的媒体的安全保护，并向被叫UE发送PRACK消息，其中携带本侧提供的媒体流安全上下文信息，例如：主叫UE提供了2套媒体流安全上下文信息，(算法1，密钥1)；(算法2，密钥2)。 

所述媒体流安全上下文信息至少包括密钥和媒体安全算法，此外，还可以包括密钥有效期(lifetime)和密钥标识(key identifier)中的一种或两种的组合。PRACK消息中可以包括多套媒体流安全上下文信息，供被叫UE来选择。这里，主叫UE向被叫UE提供至少一套媒体流上下文信息，每一套媒体流安全上下文信息可以按照优先级来进行排列或者每套都设置有对应的优先级指示，表明主叫UE对各套媒体流安全上下文信息的选择的优先程度。 

这里的媒体安全算法可以为完整性安全算法或机密性安全算法的一种或者两种的组合。 

步骤1104：被叫UE向主叫UE返回PRACK对应的200消息，其中携带被叫UE选择的媒体流安全上下文信息，本实施例中为(算法2，密钥2)。 

这里所述的媒体流安全上下文信息是被叫UE从PRACK消息携带的至少一套的媒体流安全上下文信息中选择的一套，并在PRACK的200消息中发送给主叫UE。如果媒体流安全上下文信息是按照事先设置的优先级顺序进行排列或者设置有表示优先级顺序的优先级指示，则可以按照优先级顺序来进行选择，即可以选择优先级最高的媒体流安全上下文信息。 

当然，200消息中的媒体流安全上下文信息中的密钥也可以与步骤1104被叫UE发送的密钥不同。例如，这里可以不使用“密钥2”，而是由被叫UE自己产生一个“密钥3”并发送给主叫。主被叫使用不同的密钥的使用方法可以参考RFC4568中的主被叫密钥不同的使用方法。 

此后，主叫UE和被叫UE继续后续的呼叫流程。 

由于主叫UE和被叫UE都获得了对应的密钥，可以利用所述密钥保护 传输的媒体流。 

实际应用中，主叫UE和被叫UE也可以使用衍生的密钥进行加解密，则可以在步骤1104之后，进一步包括：主叫UE和被叫UE分别根据双方的密钥衍生出新的密钥，并将衍生出的密钥作为保护媒体流的密钥。 

另外，本实施例是主叫UE和被叫UE是通过PRACK消息和200消息传输密钥的。实际应用中，还可以利用其他的消息，比如UPDATE消息和200消息来传输密钥。 

本实施例中，所述安全算法可以在RFC4568中定义的媒体流安全描述协议(SDES)中a＝crypto头域中作为crypto-suite参数来携带；所述密钥、密钥标识、密钥有效期等参数可以在SDES协议a＝crypto头域中的key-params参数来携带，具体的可以使用key-method参数指示携带方法，例如内联(inline)方法或者使用key-method-ext扩展的方法。使用key-info参数来携带密钥以及密钥标识和有效期等参数。具体的对应SRTP协议的SDES的头域可以按照如下的方法使用：srtp-crypto-suite携带安全算法，srtp-key-method指示携带方法，例如内联(inline)方法或者使用key-method-ext扩展的方法，srtp-key-info携带密钥以及密钥标识和有效期等参数。使用SDES可以携带多套媒体流安全上下文信息，即使用多个a＝crypto头域即可以进行携带，优先级信息可以按照a＝crypto头域的排列顺序标识。 

本实施例中，如果采用多媒体因特网密钥协商(MIKEY)管理协议，其中的安全算法、密钥有效期等的安全上下文都可以携带于RFC3830 MIKEY协议中安全策略负载(Security Policy payload)字段中定义的参数中。所述密钥以及密钥标识可以携带于MIKEY中密钥传输负载(KEMAC，Key data transportpayload)字段中的Key data sub-payload字段。整个MIKEY消息则可以携带于RFC4567规定的a＝key-mgmt SDP属性字段中。使用多个a＝key-mgmt头域也可以可以携带多套媒体流安全上下文信息，优先级信息可以按照a＝key-mgmt头域的排列顺序标识。 

针对上述主叫UE和被叫UE之间进行媒体流安全上下文协商的方法，本发明还提出相应的系统实施例。 

图12是针对方法实施例二和方法实施六的系统实施例四的结构示意图。如图12所示，该系统可以包括： 

主叫UE1201，通过会话请求消息将自身提供的包括安全算法的媒体流安全上下文信息发送给被叫UE1202。 

被叫UE1202，被叫UE根据会话请求消息中主叫UE提供的媒体流安全上下文信息确定自身需要提供的媒体流安全上下文信息，通过会话应答消息将确定提供的媒体流安全上下文信息发送给主叫UE。 

所述主叫UE1201和被叫UE1202根据双方提供的包括安全算法的媒体流安全上下文信息获得密钥。 

当然，如果该系统应用于不同的方法，其中功能模块的划分可能是不一样的。 

如果该系统用于方法实施例二，那么，会话请求消息为INVITE消息，会话应答消息为183消息，所述主叫UE1201通过会话请求消息提供的媒体流安全上下文信息为至少一套媒体流安全上下文信息。该系统的具体情况可以由图12A表示，如图12A所示的系统实施五，主叫UE1201可以包括： 

收发单元1201a，通过会话请求消息将自身提供的包括安全算法的媒体流安全上下文信息发送给被叫UE1202，将生成的密钥通过确认PRACK消息或UPDATE消息发送给被叫UE1202。 

当然，这里收发单元1201可以提供至少一套的媒体流安全上下文信息；另外，还可以接收被叫UE1202通过会话应答消息提供的至少一套媒体流安全上下文信息，所述被叫UE1202提供的媒体流安全上下文是根据主叫UE1201提供的至少一套媒体流安全上下文信息中选择出的； 

选择单元1201b，用于从被叫UE1202提供的至少一套的媒体流安全上下文信息中选择出一套； 

密钥生成单元1201c，用于根据选择出的媒体流安全上下文信息中的安全 算法生成密钥。 

相应地，被叫UE1202包括： 

收发单元1202a，用于接收主叫UE1201通过会话请求消息提供的包括安全算法的媒体流安全上下文信息；接收主叫UE通过确认PRACK消息或UPDATE消息发送的密钥。 

选择单元1202b，用于从主叫UE1201提供的所有媒体流安全上下文信息中选择出自身支持的至少一套媒体流安全上下信息，将选择出的至少一套媒体流安全上下文信息作为自身提供的媒体流安全上下文信息，并通过收发单元1202a发送给主叫UE1201。 

进一步地，被叫UE1202还可以包括： 

密钥生成单元1202c，用于根据双方提供的媒体流安全上下文信息中的安全算法生成密钥，并通过收发单元发送给主叫UE1201。 

进一步地，主叫UE1201还可以包括： 

衍生单元1201d，根据双方生成的密钥衍生出新的密钥； 

同样，被叫UE1202还可以包括： 

衍生单元1202d，根据双方生成的密钥衍生出新的密钥。 

如果该系统用于方法实施例六，那么，所述会话请求消息为INVITE消息，所述会话应答消息为183消息或200消息，所述主叫UE发送给被叫UE的媒体流安全上下文信息包括事先生成的密钥生成参数，所述被叫UE发送给主叫UE的媒体流安全上下文信息包括事先生成的密钥生成参数。该系统的具体情况可以由图12B表示，如图12B所示的系统实施例六的示意图，主叫UE1201可以包括： 

收发单元1201m，用于通过会话请求消息将自身提供的至少一套媒体流安全上下文信息发送给被叫UE1202，每一套媒体流安全上下文中信息中包括安全算法和主叫UE自身的密钥生成参数；接收被叫UE1202提供的包括安全算法和被叫UE自身的密钥生成参数的一套媒体流安全上下文信息。 

密钥生成单元1201n，根据被叫UE1202发送的媒体流安全上下文中的密钥 生成参数和自身的密钥生成参数产生密钥。 

相应地，被叫UE1202包括： 

收发单元1202m，用于接收主叫UE1201D的会话请求消息，通过183消息或200消息向主叫UE1201发送选择的媒体流安全上下文信息，所述选择出的媒体流安全上下文信息包括安全算法和被叫UE自身的密钥生成参数。 

选择单元1202r，从主叫UE1201发送的多套媒体流安全上下文中选择出一套媒体流安全上下文。 

密钥生成单元1202n，根据选择单元1202r选择出的媒体流安全上下文中主叫UE的密钥生成参数和被叫UE自身的密钥生成参数产生密钥。 

图13A和13B分别是针对方法实施例七和方法实施八的系统结构示意图。如图13A所示的系统实施例七的示意图，该系统可以包括： 

主叫UE1301，将携带有媒体流保护指示信息的会话请求消息发送给被叫UE1302，获得包括安全算法和密钥的媒体流安全上下文。 

被叫UE1302，接收携带有媒体流保护指示信息的会话请求消息，检查媒体流保护指示信息，确定自身支持媒体流保护，获得包括安全算法和密钥的媒体流安全上下文。 

实际应用中，如果该系统应用于不同的方法，其中的功能模块划分可能是不一样的。 

其中，主叫UE1301包括： 

收发单元1301a，用于将携带有媒体流保护指示信息的会话请求消息发送给被叫UE1302；接收被叫UE1302的183消息或200消息，将选择出的媒体流安全上下文信息通过PRACK消息或UPDATE消息发送给被叫UE1302。 

当然，收发单元1301a接收被叫UE1302提供的媒体流安全上下文信息可以至少为一套媒体流安全上下文信息，所述媒体流安全上下文信息包括安全算法和对应的密钥。 

选择单元1301b，从被叫UE1302发送的所有的媒体流安全上下文信息中进行选择。 

被叫UE1302可以包括： 

收发单元1302a，用于接收携带有媒体流保护指示信息的会话请求消息；检查媒体流保护指示信息，确定自身支持媒体流保护，将自身提供的至少一套媒体流安全上下文信息通过183消息或200消息发送给主叫UE1301，所述媒体流安全上下文信息包括安全算法和对应的密钥；接收主叫UE1301通过PRACK消息或ACK消息返回的选择出的媒体流安全上下文信息。 

如果该系统应用于方法实施例七中由主叫UE直接确定一套媒体流安全上下文信息，那么，所述主叫UE1301中的选择单元1301b选择出的媒体流安全上下文信息为一套媒体流安全上下文信息。在这种情况下，主叫UE1301中还可以增加一个密钥替换单元1301c，将所述选择单元选择出的媒体流安全上下文信息中的密钥替换为主叫UE自身生成的密钥，并发送给被叫UE1302。 

如果该系统应用于方法实施例七中由被叫UE确定一套媒体流安全上下信息的方法，那么，主叫UE1301中的选择单元1301b选择出的媒体流安全上下文信息为至少一套媒体流安全上下文信息，所述被叫UE的收发单元进一步用于向主叫UE发送携带有媒体流保护指示信息的消息。被叫UE1302还可以进一步包括： 

选择单元1302b，用于从主叫UE1301提供的至少一套的媒体流安全上下文信息中选择出一套，并通过收发单元发送给主叫UE1301。 

图13B是应用于方法实施例八的系统结构示意图，如图13B所示的系统实施例八的示意图，主叫UE1301包括： 

收发单元1301m，用于将携带有媒体流保护指示信息的会话请求消息发送给被叫UE1302；接收被叫UE通过183消息或200消息发送的媒体流保护指示信息，确定所述被叫UE支持媒体流保护；将自身提供的至少一套媒体流安全上下文信息通过PRACK消息或ACK消息发送给被叫UE，并接收被叫UE1302通过200消息发送的选择出的一套媒体流安全上下文信息。 

相应地，被叫UE1302包括： 

收发单元1302m，用于接收携带有媒体流保护指示信息的会话请求消息； 检查媒体流保护指示信息，确定自身支持媒体流保护，通过183消息或200消息将携带有媒体流保护指示信息发送给主叫UE1301；接收主叫UE1301通过PRACK消息或UPDATE消息发送的至少一套媒体流安全上下文信息；将选择出的一套媒体流安全上下文信息通过200消息发送给主叫UE1301，所述媒体流安全上下文信息包括安全算法和对应的密钥。 

选择单元1302n，用于从主叫UE1301提供的至少一套的媒体流安全上下文信息中选择出一套，并通过收发单元发送给主叫UE1301。 

实际应用中，被叫UE1302中还可以包括一个密钥替换单元1302r，将所述选择单元1302n选择出的媒体流安全上下文信息中的密钥替换为被叫UE1302自身生成的密钥，并发送给主叫UE1302。 

上述方法和系统可以应用于IMS等系统中。 

从上述内容可以看出，主叫UE和被叫UE中可以包括收发单元、密钥生成单元、选择单元、衍生单元等等情况，这些单元如何组合，其功能具体是什么，则与上述具体的方法或系统相关。 

比如：以方法实施例二中的主叫UE为例，如果主叫UE可以根据自身生成的密钥和被叫UE生成的密钥衍生新的密钥，那么，该主叫UE可以包括收发单元、选择单元、密钥生成单元、衍生单元，各个单元的功能和连接关系可以与图12A中UE1201中的各个单元对应。当然，如果所述主叫UE被其它UE呼叫时，也应该同时具备被叫UE1202的功能，此处不再赘述。 

又比如：以方法实施例六为例，如果主叫UE可以根据自身的密钥生成参数和被叫UE的密钥生成参数来产生密钥，那么，该主叫UE可以包括收发单元和密钥生成单元，其情况与图12B中UE1201中的各个单元对应，此处不再赘述。 

又比如：以方法实施例七为例，如果只有主叫UE发送媒体流保护指示信息，那么，该主叫UE可以包括收发单元、选择单元和密钥替换单元，其情况与图13A中UE1301中的各个单元对应，此处不再赘述。 

总之，本发明还提出实现媒体流安全上下文协商的装置，其内部结构示意 图按照其实现方式的不同而不同，可以分别用图12、图12A、图12B、图13A以及图13B中UE内部结构图表示，此处不再赘述。 

应用本发明实施例方案，由于不需要UE进行复杂的计算，也不需要网络中具备公钥设施等要求，而是直接由主叫UE和被叫UE进行交互来获得包括安全算法和密钥的媒体流安全上下文信息，从而实现了IMS系统中媒体流安全上下文协商，有利于后续在IMS网络中进行媒体流安全保护。 

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

Claims (36)

1.一种实现媒体流安全上下文协商的方法，其特征在于，该方法包括：

主叫终端设备UE通过会话请求消息将自身提供的媒体流安全上下文信息发送给被叫UE，所述媒体流安全上下文信息包括安全算法；

主叫UE接收被叫UE通过会话应答消息提供的媒体流安全上下文信息，所述被叫UE提供的媒体流安全上下文信息是根据主叫UE提供的媒体流安全上下文信息所确定的；

主叫UE和被叫UE根据双方提供的包括安全算法的媒体流安全上下文信息获得密钥。

2.根据权利要求1所述的方法，其特征在于，所述会话请求消息为邀请INVITE消息，所述会话应答消息为183消息或200消息，所述主叫UE通过会话请求消息提供的媒体流安全上下文信息为至少一套媒体流安全上下文信息；

所述被叫UE确定自身提供媒体流安全上下文信息的方法为：所述被叫UE从主叫UE提供的所有媒体流安全上下文信息中选择出自身支持的至少一套媒体流安全上下信息，将选择出的至少一套媒体流安全上下文信息作为自身提供的媒体流安全上下文信息。

3.根据权利要求2所述的方法，其特征在于，所述主叫UE和被叫UE根据双方提供的包括安全算法的媒体流安全上下文信息获得密钥的步骤包括：

所述主叫UE从被叫UE提供的至少一套的媒体流安全上下文信息中选择出一套，将自身生成的密钥携带于选择出的媒体流安全上下文信息，并通过确认PRACK消息或UPDATE消息发送给所述被叫UE。

4.根据权利要求3所述的方法，其特征在于，所述主叫UE将生成的密钥通过确认PRACK消息或UPDATE消息发送给被叫UE之后，该方法进一步包括：

所述被叫UE生成密钥并通过200消息发送给所述主叫UE。

5.根据权利要求4所述的方法，其特征在于，所述被叫UE将生成的密钥 通过200消息发送给所述主叫UE之后，该方法进一步包括：

所述主叫UE和被叫UE根据双方生成的密钥衍生出新的密钥。

6.根据权利要求1所述的方法，其特征在于，所述主叫UE发送给被叫UE的媒体流安全上下文信息还包括主叫UE自身的密钥生成参数；

所述被叫UE提供的媒体流安全上下文信息还包括被叫UE自身的密钥生成参数；

所述主叫UE和被叫UE根据双方提供的包括安全算法的媒体流安全上下文信息获得密钥的方法为：所述被叫UE根据的主叫UE提供的媒体流安全上下文中的密钥生成参数和自身的密钥生成参数产生密钥，所述主叫UE根据被叫UE提供的媒体流安全上下文中的密钥生成参数和自身的密钥生成参数产生密钥。

7.根据权利要求6所述的方法，其特征在于，所述会话请求消息为INVITE消息，所述会话应答消息为183或200消息。

8.根据权利要求1所述的方法，其特征在于，所述会话请求消息为INVITE消息，所述会话应答消息为183或200消息，所述主叫UE发送给被叫UE的媒体流安全上下文信息为至少一套媒体流安全上下文信息，每一套媒体流安全上下文中信息中还包括密钥生成参数；

所述被叫UE确定自身提供的媒体流安全上下文信息的方法为：从主叫UE提供的至少一套的媒体流安全上下文信息中选择出自身支持的一套，并将自身的密钥生成参数作为选择出的媒体流安全上下文信息中的密钥生成参数发送给主叫UE。

9.根据权利要求8所述的方法，其特征在于，所述主叫UE和被叫UE根据双方提供的包括安全算法的媒体流安全上下文信息获得密钥的步骤包括：

所述被叫UE根据选择出的媒体流安全上下文中的密钥生成参数和自身的密钥生成参数产生密钥，所述主叫UE根据被叫UE发送的媒体流安全上下文中的密钥生成参数和自身的密钥生成参数产生密钥。

10.一种实现媒体流安全上下文协商的方法，其特征在于，该方法包括： 

主叫UE将携带有媒体流保护指示信息的会话请求消息发送给被叫UE；

被叫UE检查媒体流保护指示信息，确定自身支持媒体流保护；

被叫UE与主叫UE根据双方提供的包括安全算法的媒体流安全上下文信息获得密钥。

11.根据权利要求10所述的方法，其特征在于，所述被叫UE和主叫UE根据双方提供的包括安全算法的媒体流安全上下文信息获得密钥的步骤包括：

所述被叫UE将自身提供的至少一套媒体流安全上下文信息发送给主叫UE，所述媒体流安全上下文信息包括安全算法和对应的密钥；

所述主叫UE直接从被叫UE发送的所有的媒体流安全上下文信息中选择出一套，并将选择出的一套媒体流安全上下文信息发送给被叫UE。

12.根据权利要求11所述的方法，其特征在于，所述会话请求消息为INVITE消息；

所述被叫UE将自身提供的至少一套媒体流安全上下文信息通过183消息或200消息发送给主叫UE；

所述主叫UE将选择出的一套媒体流安全上下文信息通过PRACK消息或ACK消息发送给被叫UE。

13.根据权利要求11所述的方法，其特征在于，所述主叫UE从被叫UE发送的所有的媒体流安全上下文信息中选择出一套，以及将选择出的一套媒体流安全上下文信息发送给被叫UE之间，该方法进一步包括：

所述主叫UE将自身生成的新的密钥作为所述选择出的一套媒体流安全上下文中的密钥。

14.根据权利要求10所述的方法，其特征在于，所述被叫UE和主叫UE根据双方提供的包括安全算法的媒体流安全上下文信息获得密钥的步骤包括：

所述被叫UE将自身提供的至少一套媒体流安全上下文信息发送给主叫UE，所述媒体流安全上下文信息包括安全算法和对应的密钥；

所述主叫UE从被叫UE提供的所有媒体流安全上下文信息中选择出自身支持的至少一套媒体流安全上下信息，将选择出的至少一套媒体流安全上下文信 息发送给被叫UE；

所述被叫UE从主叫UE提供的至少一套的媒体流安全上下文信息中选择出一套，并发送给主叫UE。

15.根据权利要求14所述的方法，其特征在于，所述请求消息为INVITE消息；

所述被叫UE将自身提供的至少一套媒体流安全上下文信息通过183消息或200消息发送给主叫UE；

所述主叫UE将选择出的至少一套媒体流安全上下文信息通过PRACK消息或UPDATE消息发送给被叫UE；

所述被叫UE将选择出的一套媒体流安全上下文信息中通过200消息发送给主叫UE。

16.根据权利要求10所述的方法，其特征在于，所述被叫UE和主叫UE根据双方提供的包括安全算法的媒体流安全上下文信息获得密钥的步骤包括：

所述被叫UE将用于指示本侧支持的需媒体流安全保护的媒体的媒体流保护指示信息返回给所述主叫UE；

所述主叫UE检查被叫UE返回的媒体流保护指示信息，确定所述被叫UE支持媒体流保护；

所述主叫UE将自身提供的至少一套媒体流安全上下文信息发送给被叫UE，所述媒体流安全上下文信息包括安全算法和对应的密钥；

所述被叫UE从主叫UE发送的所有的媒体流安全上下文信息中选择出一套，并将选择出的一套媒体流安全上下文信息发送给主叫UE。

17.根据权利要求16所述的方法，其特征在于，所述会话请求消息为INVITE消息；

所述被叫UE将媒体流保护指示信息通过183消息或200消息返回给所述主叫UE；

所述主叫UE将自身提供的至少一套媒体流安全上下文信息通过PRACK消息或UPDATE消息发送给被叫UE； 

所述被叫UE将选择出的一套媒体流安全上下文信息通过200消息发送给主叫UE。

18.根据权利要求16所述的方法，其特征在于，所述被叫UE从主叫UE发送的所有的媒体流安全上下文信息中选择出一套，以及将选择出的一套媒体流安全上下文信息发送给主叫UE之间，该方法进一步包括：

所述被叫UE将自身生成的新的密钥作为选择出的一套媒体流安全上下文信息中的密钥。

19.根据权利要求10至18任一项所述的方法，其特征在于，所述媒体流保护指示信息是采用安全前提的方法所设置的媒体流保护指示信息，或者是采用将媒体对应的传输协议设置成安全传输协议的方法得到的媒体流保护指示信息，或者是采用设置会话描述协议SDP协议中的k头域中的值得到媒体流保护指示信息。

20.一种实现媒体流安全上下文协商的系统，其特征在于，该系统包括：

主叫UE，通过会话请求消息将自身提供的包括安全算法的媒体流安全上下文信息发送给被叫UE；

被叫UE，被叫UE根据会话请求消息中主叫UE提供的媒体流安全上下文信息确定自身需要提供的媒体流安全上下文信息，通过会话应答消息将确定提供的媒体流安全上下文信息发送给主叫UE；

所述主叫UE和被叫UE根据双方提供的包括安全算法的媒体流安全上下文信息获得密钥。

21.根据权利要求20所述的系统，其特征在于，所述会话请求消息为INVITE消息，所述会话应答消息为183消息或200消息，所述主叫UE通过会话请求消息提供的媒体流安全上下文信息为至少一套媒体流安全上下文信息；所述被叫UE包括：

收发单元，用于接收主叫UE通过会话请求消息提供的包括安全算法的媒体流安全上下文信息；接收主叫UE通过确认PRACK消息或UPDATE消息发送的密钥； 

选择单元，用于从主叫UE提供的所有媒体流安全上下文信息中选择出自身支持的至少一套媒体流安全上下信息，将选择出的至少一套媒体流安全上下文信息作为自身提供的媒体流安全上下文信息，并通过收发单元发送给主叫UE；

所述主叫UE包括：

收发单元，通过会话请求消息将自身提供的包括安全算法的媒体流安全上下文信息发送给被叫UE，将生成的密钥通过确认PRACK消息或UPDATE消息发送给所述被叫UE；

选择单元，用于从被叫UE提供的至少一套的媒体流安全上下文信息中选择出一套；

密钥生成单元，用于根据选择出的媒体流安全上下文信息中的安全算法生成密钥。

22.根据权利要求21所述的系统，其特征在于，所述被叫UE进一步包括：

密钥生成单元，用于根据双方提供的媒体流安全上下文信息中的安全算法生成密钥，并通过收发单元发送给主叫UE。

23.根据权利要求22所述的系统，其特征在于，所述主叫UE进一步包括：

衍生单元，根据双方生成的密钥衍生出新的密钥；

所述被叫UE进一步包括：

衍生单元，根据双方生成的密钥衍生出新的密钥。

24.根据权利要求20所述的系统，其特征在于，所述会话请求消息为INVITE消息，所述会话应答消息为183消息或200消息；

所述主叫UE包括：

收发单元，用于通过会话请求消息将自身提供的至少一套媒体流安全上下文信息发送给被叫UE，每一套媒体流安全上下文中信息中包括安全算法和主叫UE自身的密钥生成参数；接收被叫UE提供的包括安全算法和被叫UE自身的密钥生成参数的一套媒体流安全上下文信息；

密钥生成单元，根据被叫UE发送的媒体流安全上下文信息中的密钥生成 参数和自身的密钥生成参数产生密钥；

所述被叫UE包括：

收发单元，用于接收主叫UE的会话请求消息，通过183消息或200消息向主叫UE发送选择的媒体流安全上下文信息，所述选择出的媒体流安全上下文信息包括安全算法和被叫UE自身的密钥生成参数；

选择单元，从主叫UE发送的至少一套的媒体流安全上下文信息中选择出一套；

密钥生成单元，根据选择单元选择出的媒体流安全上下文信息中主叫UE的密钥生成参数和被叫UE自身的密钥生成参数产生密钥。

25.一种实现媒体流安全上下文协商的系统，其特征在于，该系统包括：

主叫UE，将携带有媒体流保护指示信息的会话请求消息发送给被叫UE；

被叫UE，接收携带有媒体流保护指示信息的会话请求消息，检查媒体流保护指示信息，确定自身支持媒体流保护；

所述主叫UE和被叫UE还根据双方提供的包括安全算法的媒体流安全上下文信息获得密钥。

26.根据权利要求25所述的系统，其特征在于，所述会话请求消息为INVITE消息，所述被叫UE包括：

收发单元，用于接收携带有媒体流保护指示信息的会话请求消息；检查媒体流保护指示信息，确定自身支持媒体流保护，将自身提供的至少一套媒体流安全上下文信息通过183消息或200消息发送给主叫UE，所述媒体流安全上下文信息包括安全算法和对应的密钥；接收主叫UE通过PRACK消息或UPDATE消息返回的选择出的媒体流安全上下文信息。

27.根据权利要求26所述的系统，其特征在于，所述主叫UE包括：

收发单元，用于将携带有媒体流保护指示信息的会话请求消息发送给被叫UE；接收被叫UE的183消息或200消息，将选择出的媒体流安全上下文信息通过PRACK消息或UPDATE消息发送给被叫UE；

选择单元，从被叫UE发送的所有的媒体流安全上下文信息中进行选择。 

28.根据权利要求26所述的系统，其特征在于，所述主叫UE中的选择单元选择出的媒体流安全上下文信息为一套媒体流安全上下文信息。

29.根据权利要求27所述的系统，其特征在于，所述主叫UE中的选择单元选择出的媒体流安全上下文信息为至少一套媒体流安全上下文信息；

所述被叫UE进一步包括：

选择单元，用于从主叫UE提供的至少一套的媒体流安全上下文信息中选择出一套，并通过收发单元发送给主叫UE。

30.根据权利要求25所述的系统，其特征在于，所述会话请求消息为INVITE消息，所述主叫UE包括：

收发单元，用于将携带有媒体流保护指示信息的会话请求消息发送给被叫UE；接收被叫UE通过183消息或200消息发送的媒体流保护指示信息，确定所述被叫UE支持媒体流保护；将自身提供的至少一套媒体流安全上下文信息通过PRACK消息或UPDATE消息发送给被叫UE，并接收被叫UE通过200消息发送的选择出的一套媒体流安全上下文信息；

所述被叫UE包括：

收发单元，用于接收携带有媒体流保护指示信息的会话请求消息；检查媒体流保护指示信息，确定自身支持媒体流保护，通过183消息或200消息将携带有用于指示本侧支持的需媒体流安全保护的媒体的媒体流保护指示信息发送给主叫UE；接收主叫UE通过PRACK消息或UPDATE消息发送的至少一套媒体流安全上下文信息；将选择出的一套媒体流安全上下文信息通过200消息发送给主叫UE，所述媒体流安全上下文信息包括安全算法和对应的密钥；

选择单元，用于从主叫UE提供的至少一套的媒体流安全上下文信息中选择出一套，并通过收发单元发送给主叫UE。

31.一种实现媒体流安全上下文协商的装置，其特征在于，该装置为主叫UE，包括：

收发单元，通过会话请求消息将自身提供的至少一套的媒体流安全上下文信息发送给被叫UE，所述每一套媒体流安全上下文包括安全算法；接收被叫 UE通过会话应答消息提供的至少一套媒体流安全上下文信息，所述被叫UE提供的媒体流安全上下文信息是根据主叫UE提供的至少一套媒体流安全上下文信息中选择出的；将生成的密钥携带于选择出的一套媒体流安全上下文中发送给被叫UE；

选择单元，从被叫UE提供的所有媒体流安全上下文信息中选择出一套；

密钥生成单元，根据选择出的媒体流安全上下文信息中的安全算法生成密钥。

32.根据权利要求31所述的装置，其特征在于，所述收发单元进一步用于接收被叫UE发送的密钥；

该装置进一步包括：

衍生单元，根据所述密钥生成单元产生的密钥和被叫UE发送来的密钥衍生出新的密钥。

33.一种实现媒体流安全上下文协商的装置，其特征在于，该装置为主叫UE，包括：

收发单元，通过会话请求消息将提供的至少一套媒体流安全上下文信息发送给被叫UE，所述每一套媒体流安全上下文信息包括安全算法和主叫UE自身的密钥生成参数；接收被叫UE通过会话应答消息提供的一套媒体流安全上下文信息，所述被叫UE提供的一套媒体流安全上下文信息中的密钥生成参数为被叫UE自身的密钥生成参数；

密钥生成单元，根据主叫UE自身的密钥生成参数以及被叫UE自身的密钥生成参数产生密钥。

34.一种实现媒体流安全上下文协商的装置，其特征在于，该装置为主叫UE，包括：

收发单元，将携带有媒体流保护指示信息的会话请求消息发送给被叫UE；接收被叫UE通过会话应答消息提供的至少一套媒体流安全上下文信息，所述媒体流安全上下文信息包括安全算法和对应的密钥；将选择单元选择出的媒体流安全上下文信息发送给被叫UE； 

选择单元，从被叫UE提供的所有媒体流安全上下文信息中进行选择。

35.根据权利要求34所述的装置，其特征在于，所述选择单元选择出的媒体流安全上下文信息为一套媒体流安全上下文信息，该装置进一步包括：

密钥替换单元，将所述选择单元选择出的媒体流安全上下文信息中的密钥替换为主叫UE自身生成的密钥。

36.根据权利要求34所述的装置，其特征在于，所述选择单元选择出的媒体流安全上下文信息为至少一套媒体流安全上下文信息；

该装置进一步包括：

密钥替换单元，将被叫UE发送来的一套媒体流安全上下文信息中的密钥替换为主叫UE自身生成的密钥，并通过收发单元发送给被叫UE。 

Images