专利名称：：一种安全传输媒体流的方法和系统的制作方法
技术领域：
：本发明涉及媒体流加密技术，特别是涉及一种安全传输媒体流的方法和系统。
背景技术：
：i某体流一^l基于实时传4lr协i义(RTP，Real-timeTransportProtocol)进行传输，这里的所述的媒体流为音频媒体流、视频媒体流等。但由于RTP协议本身并不涉及安全问题，使媒体流在传输过程中存在泄密、被攻击等安全隐患。为了加强媒体流在传输过程中的安全性，目前已提出多种生成和分配密钥的方法，即密钥协商方法。之后，终端可以利用分配的密钥实现^某体流的传输，达到安全传输媒体流的目的。在现有技术中，密钥协商方法中有两种典型方法一种是多媒体因特网密钥(MIKEY)7^钥;漠式，另一种是MIKEYDH冲莫式。其中，MIKEY公钥模式的基本思想是由主叫终端生成密钥和信封密钥，所述密钥用信封密钥进行加密，信封密钥再利用被叫终端证书的公钥进行加密，然后将加密后的密钥通过MIKEY协议发送到被叫终端，被叫终端解密后获得密钥，完成密钥协商过程。在MIKEY公钥模式中，为了保障密钥协商过程的安全、顺利地进行，要求主叫终端和被叫终端之间进行时钟同步，并具备公钥基础设施(PKI)系统的支持。而实际应用中，实现时钟同步以及PKI系统支持比较复杂，不利于密钥协商的实现。比如在电话会议中，存在多个需要传输媒体流的终端。如果要对多个终端的媒体流加密，则需要将多个终端进行时钟同步，这大大增加了密钥协商的困难。又比如主叫终端和被叫终端为普通的移动终端，而由于移动终端数量大，将很难完成PKI系统中证书管理等工作，无法顺利进行密钥协商。MIKEYDH模式的基本思想是在主叫终端和被叫终端分别生成DH值，再利用MIKEY协议交换彼此的DH值，然后根据双方的DH值产生密钥。MIKEYDH模式也需要进行时钟同步，而且实现MIKEYDH模式非常复杂，计算量大，对终端性能要求高，不利于密钥协商的实现。另外，实际应用中，运营商为了安全机构满足合法监听的要求，需要获得媒体流中的密钥。而现有技术中，只有参与交互的终端才可以获得密钥，这里所述参与交互的终端可能为主叫和被叫两个终端，也可能为多个终端，任何参与交互之外的第三方都无法获得密钥，即无法满足合法监听的要求。
发明内容本发明提供一种安全传输媒体流的方法和系统，可以在保证链路安全的条件下，避免时钟同步、PKI支持、证书管理等过程，减少生成密钥的复杂度，便于媒体流加密业务的推广。为了达到上述目的，本发明提出的技术方案为一种安全传输媒体流的方法，预先设置密钥生成单元，该方法包括以下步骤A、密钥生成单元在呼叫流程中获取终端的加密能力信息，并根据所述加密能力信息生成用于媒体流的密钥；B、再将生成的密钥分别发送给终端和用于媒体流承载设备；C、终端和媒体流承载设备利用获取的密钥传输媒体流。上述方案中，所述密钥生成单元为主叫侧呼叫会话控制功能实体CSCF的功能单元，所述终端为主叫终端，则步骤A所述密钥生成单元获取加密能力信息的方法具体为主叫终端发起呼叫，将携带有自身加密能力信息的呼叫请求消息发送给主叫侧CSCF,主叫侧CSCF从呼叫请求消息中获取主叫终端的加密能力信息。上述方案中，所述主叫终端的加密能力信息承载于呼叫请求消息的会话描述协议SDP中；或者承载于呼叫请求消息的会话初始协议SIP主叫属性接收协商Accept-contact头域中；或者承载于呼叫请求消息中SIP扩展协商域中，所述SIP扩展协商域为支持supported域；或者承载于呼叫请求消息中征求意见稿RFC4568标准所定义的字段中。上述方案中，步骤B所述将密钥发送给主叫终端的方法为当主叫侧CSCF接收到来自被叫终端的呼叫响应消息时，将事先生成的密钥携带于所述呼叫响应消息发送给主叫终端。上述方案中，所述媒体流承载设备为主叫侧媒体代理MP,步骤B所述将密钥发送给主叫侧MP的方法为主叫侧CSCF将携带有密钥的报文发送给主叫侧资源和接入控制子系统RACS,主叫侧RACS再将密钥发送给主叫侧MP。上述方案中，所述步骤C具体为当媒体流从主叫终端传输给被叫终端时，主叫终端利用获取的密钥对媒体流进行加密，将加密的媒体流传输给主叫侧MP，主叫侧MP再利用获取的密钥对媒体流进行解密，然后将解密后的媒体流传输出去；和/或当媒体流从被叫终端传输给主叫终端时，主叫侧MP利用获取的密钥将来自被叫终端的媒体流进行加密，将加密的媒体流传输给主叫终端，主叫终端再利用获取的密钥对媒体流进行解密。上述方案中，所述密钥生成单元为被叫侧CSCF中的功能单元，所述终端为被叫终端，则步骤A所述获取加密能力信息的方法具体为被叫终端通过被叫侧CSCF接收到来自主叫终端的呼叫请求消息，将携带有被叫终端自身加密能力信息的呼叫响应消息返回给被叫侧CSCF，被叫侧CSCF从呼叫响应消息中获取被叫终端的加密能力信息。上述方案中，步骤B所述将密钥发送给被叫终端的方法为当被叫侧CSCF接收到来自主叫终端与呼叫相关的消息时，将事先生成的密钥携带于所述与呼叫相关的消息发送给被叫终端。上述方案中，所述媒体流承载设备为被叫侧MP，步骤B所述将密钥发送纟合#1叫侧MP的方法为被叫侧CSCF将携带有密钥的报文发送给被叫侧RACS，被叫侧RACS再将密钥发送给被叫侧MP。上述方案中，所述步骤C具体为当媒体流从主叫终端传输到被叫终端时，被叫侧MP利用获取的密钥将来自主叫终端的媒体流进行加密，将加密的媒体流传输给被叫终端，被叫终端再利用获取的密钥对媒体流进行解密；和/或当媒体流从被叫终端传输到主叫终端时，被叫终端利用获取的密钥对媒体流进行加密，将加密的媒体流传输给被叫侧MP,被叫侧MP再利用获取的密钥对媒体流进行解密，然后将解密后的媒体流传输出去。针对第二个发明目的，本发明提出的技术方案是一种安全传输媒体流的系统，包括终端、媒体流承载设备，该系统还包括密钥生成单元；所述终端，用于将自身加密能力信息发送给密钥生成单元，获取密钥，根据密钥负责传输媒体流；所述媒体流承载设备，用于接收由密钥生成单元生成的密钥，根据密钥负责传输媒体流；所述密钥生成单元，用于接收终端输入的加密能力信息，生成密钥，并将生成的密钥分别发送给终端和媒体流承载设备。上述方案中，所述密钥生成单元为P-CSCF中的功能单元，所述媒体流承载设备为MP,该系统进一步包括RACS,用于接收由P-CSCF中密钥生成单元所生成的密钥，并将密钥转发给MP。综上所述，本发明提出一种安全传输媒体流的方法和系统，终端自身并不生成密钥，而是由密钥生成单元生成密钥，无需进行时钟同歩，也无需PKI体系的支持，可以大大降低生成密钥的复杂度，实现安全传输媒体流目的，也便于媒体流加密业务的推广。由于主叫侧和被叫侧可以独立生成自身的密钥，无需与对方协商，所以，在生成和下发密钥的过程中，不影响呼叫流程的执行。另外，由于主叫侧和被叫侧的媒体流承载设备之间传输的是明文，可以满足合法监听的实际需求。图1是本发明的流程图；图2是方法实施例中的消息流示意图；图3是本发明系统的基本结构图；图4是系统实施例的结构图。具体实施方式为使本发明的目的、技术方案和优点更加清楚，下面将结合附图及具体实施例对本发明作进一步地详细描述。本发明的基本思想是预先设置密钥生成单元，负责密钥的生成和分配；终端和媒体流承载设备利用从密钥生成单元获取的密钥传输媒体流，从而达到安全传输媒体流的目的。图l是本发明的流程图。如图l所示，本发明包括以下步骤步骤101:密钥生成单元在呼叫流程中获取终端的加密能力信息，并根据所述加密能力信息生成用于i某体流的密钥。步骤102:密钥生成单元再将生成的密钥分别发送给终端和用于媒体流承载设备。步骤103:终端和媒体流承载设备利用获取的密钥传输媒体流。由于呼叫流程涉及主叫侧和被叫侧，本发明实现安全传输媒体流也相应地分为主叫侧和净皮叫侧两种情况。对于主叫侧来说，所述终端为主叫终端；所述密钥生成单元为主叫侧密钥生成单元，主叫侧密钥生成单元可以是主叫侧CSCF中的功能单元；所述媒体流承载设备为主叫侧媒体流承载设备，即主叫侧MP。在这种情况下，步骤101所述获取主叫终端加密能力信息的方法为主叫终端发起呼叫，将携带有自身加密能力信息的呼叫请求消息发送给主叫侧CSCF，主叫侧CSCF从呼叫请求消息中获取主叫终端的加密能力信息。相应地，步骤102中所述将密钥发送给主叫终端的方法为当主叫侧CSCF接收到来自被叫终端的呼叫响应消息时，将事先生成的密钥携带于所述呼叫响应消息发送给主叫终端。相应地，步骤102中所述将密钥发送给主叫侧MP的方法为主叫侧CSCF将携带有密钥的l艮文发送给主叫侧资源和接入控制子系统RACS;主叫侧RACS再将密钥发送给主叫侧MP。此时，主叫终端和主叫侧MP都从主叫侧P-CSCF中获取了密钥，就可以利用所述密钥传输媒体流。这里所述传输媒体流又可以分为两种情况一种情况是当媒体流从主叫终端传输给被叫终端时，主叫终端利用获取的密钥对媒体流进行加密，将加密的媒体流传输给主叫侧MP，主叫侧MP再利用获取的密钥对媒体流进行加密，然后将解密后的媒体流传输出去，即传输给被叫侧。另外一种情况是当媒体流从被叫终端传输给主叫终端时，主叫侧MP利用获取的密钥将来自被叫终端的媒体流进行加密，将加密的媒体流传输给主叫终端，主叫终端再利用获取的密钥对媒体流进行解密。实际应用中，媒体流可以仅从主叫终端传输给被叫终端，或者仅从被叫终端传输给主叫终端，或者主叫终端和被叫终端都向对方传输媒体流。对于被叫侧来说，所述终端为被叫终端；所述密钥生成单元为被叫侧密钥生成单元，被叫侧密钥生成单元可以是被叫侧CSCF中的功能单元；所述i某体流承载设备为被叫侧媒体流承载设备，即被叫侧MP。在这种情况下，步骤101所述获取被叫终端加密能力信息的方法为被叫终端通过被叫侧CSCF接收到来自主叫终端的呼叫请求消息，将携带有被叫终端自身加密能力信息的呼叫响应消息返回给被叫侧CSCF,被叫侧CSCF从呼叫响应消息中获取被叫终端的加密能力信息。相应地，步骤102所述将密钥发送给被叫终端的方法为当被叫侧CSCF接收到来自主叫终端与呼叫相关的消息时，将事先生成的密钥携带于所述与呼叫相关的消息发送给被叫终端。这里所述的与呼叫相关的消息可以为确认消息或信息更改消息等。相应地，步骤102所述将密钥发送给被叫侧MP的方法为被叫侧CSCF将携带有密钥的报文发送给被叫侧RACS，被叫侧RACS再将密钥发送给被叫侧MP。此时，被叫终端和被叫侧MP都从被叫侧P-CSCF中获取了密钥，就可以利用所述密钥传输媒体流。与主叫侧相似，这里所述传输媒体流又可以分为两种情况一种情况是当媒体流从主叫终端传输到被叫终端时，被叫侧MP利用获取的密钥将来自主叫终端的媒体流进行加密，将加密的媒体流传输给被叫终端，被叫终端再利用获取的密钥对+某体流进行解密。另外一种情况是当媒体流从被叫终端传输到主叫终端时，被叫终端利用获取的密钥对媒体流进行加密，将加密的媒体流传输给被叫侧MP,被叫侧MP再利用获取的密钥对媒体流进行加密，然后将解密后的媒体流传输出去。本发明中，主叫侧和被叫侧都是独立地生成密钥，并将生成的密钥下发给本侧的终端和媒体流承载设备。也就是说，当某一侧生成密钥时，由于该密钥只用于在本侧所属的区域内传输媒体流，而主叫侧和被叫侧区域之外都采用明文传输，所以，在生成密钥时，并不需要与对方进行协商，也不需要将自身生成的密钥发送给对方。需要注意的是，本发明是以主叫侧或被叫侧一方来说明安全传输媒体流的方法，而在实际应用中，由于呼叫过程和传输媒体流将同时涉及主叫侧和被叫侧。为了更好的说明本发明方案，下面的较佳实施例同时涉及主叫侧和被叫侧，以完整说明安全传输媒体流的方法。方法实施例本实施例中，事先在主叫侧和被叫侧设置密钥生成单元，主叫侧密钥生成单元为主叫侧P-CSCF中的功能单元，^C叫侧密钥生成单元为^^皮叫侧P-CSCF中的功能单元；当然，实际应用中，密钥生成单元也可以不是P-CSCF中的功能单元，而是一个独立的服务器。本实施例中，主叫侧还包括主叫终端、主叫侧RACS、主叫侧MP;被叫侧还包括被叫终端、被叫侧RACS、被叫侧MP。另外假设主叫侧P-CSCF生成的密钥为x,被叫侧P-CSCF生成的密钥为y。图2是本实施例的消息流示意图。如图2所示，本实施例包括以下步骤步骤201:主叫侧发起呼叫，将携带有自身加密能力信息的呼叫请求消息发送给主叫侧P-CSCF。这里所述的呼叫请求消息为SIP协议中的INVITE消息，可以采用四种方法将主叫终端的加密能力信息承载在INVITE消息中第一种方法是承载在INVITE消息的SDP中；第二种方法是承载在INVITE消息中SIP主叫属性接收协商(Accept-contact)头域中；第三种方法是承载在INVITE消息中SIP的扩展协商域中；第四种方法是承载在INVITE消息中征求意见稿(RFC4568)标准所定义的字段中。对于第一种承载方法，即承载在会话描述协议(SDP)中，所述加密能力信息的格式为m=<media〉<port〉srtp/avp<format-list>[a=media—encryption:SRTP&[ListsoftheEncryptedAlgorithms]&[ListsoftheEncryptedKeyLength]&<table>tableseeoriginaldocumentpage13</column></row><table>表一如果主叫终端指定采用SRTP协议，AES-CM加密算法，加密密钥的长度为128比特或256比特，消息认证与完整性保护算法釆用HMAC-SHA1，消息认证与完整性保护密钥长度位160比特，密钥更新速率为24,则所述呼叫请求消息中的密钥能力信息为m=<media><port〉srtp/avp<format-list〉a=media—encryption:SRTP&AES-CM&128;256&画AC-SHA1&160&24对于第二种承载方法，即承载在SIP主叫属性Accept-contact头域中，其格式为Accept—Contact:*;media—encryption=，，SRTP&[ListsoftheEncryptedAlgorithms]&[ListsoftheEncryptedKeyLength]&[ListsoftheMessageAuthenticationAlgorithms]&[ListsoftheMessageAuthenticationKeyLength]&[KeyGenerationsidedeclartion]&[Keyderivationrate]，，；....其中，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-SHAl]-[160]其中子字段的含义与表一相同，此处不再赘述。对于第四种承载方法，即承载在RFC4568所定义的字段中，其格式为a=crypto:lAES—CM—128—HMAC—SHAI—80inline:其中子字段的含义也与表一相同，此处不再赘述。步骤202:主叫侧P-CSCF将呼叫请求消息发送给被叫侧P-CSCF。步骤203:主叫侧P-CSCF中的密钥生成单元4艮据主叫终端的加密能力信息生成密钥x。本实施例中，新增加的密钥生成单元为P-CSCF中功能单元，实际应用还可以为其他的CSCF，比如S-CSCF。如果密钥生成单元不是P-CSCF中的功能单元，而是一个独立的服务器，则需要提供P-CSCF和该服务器之间的接口，P-CSCF通过接口从服务器获取生成的密钥。歩骤204:主叫侧P-CSCF发起资源预留过程，在资源预留过程中，主叫侧P-CSCF将生成的密钥x发送给主叫侧RACS。步骤205:主叫侧RACS再将密钥x发送给主叫侧MP。这里，所述的步骤204和步骤205是资源预留过程，主要确定服务质量(Qos)、门限控制等信息，并将确定的Qos、门限控制等信息通过策略下发消息发送给主叫侧MP。在资源预留过程中，P-CSCF可以在资源请求报文(AAR)中媒体组件描述符(Media-Component-Description)的媒体子组件数据值对(Media-Sub-ComponentAVP)中扩展一个用于承载密钥的字段，比如媒体加密密钥(Media-Encryption-Key)字段，将生成的密钥记录在该字段中，将密钥发送给主叫侧RACS。扩展后的格式可以为Media-Component-Description::=<AVPHeader:519>{Media-Component-Number}*[Media-Sub-Component][AF-Application-Identifier][Media-Type][Max-Requested-Bandwidth-UL][Max-Requested-Bandwidth-DL][Flow-Status][RS-Bandwidth][RR-Bandwidth]|Media-Encryption-Keyl其中，IMedia-Encryption-Keyl就是扩展的字段，用于承载密钥。当然，实际应用中，密钥也可以不通过AAR报文发送给主叫侧RACS，而通过其他报文下发，比如资源修改才艮文等，至于如何下发以及如何扩展则与具体的实现相关，此处不再赘述。当主叫侧RACS接收到密钥后，可以通过H.248协议或^^共开》文策略服务(COPS)协议将密钥发送给主叫侧MP。如果主叫侧RACS向主叫侧MP发送COPS消息，其格式为〈DecisionMessage>::=<CommonHeader><ClientHandle>*(<Decision>)|<Error>[<Integrity>〗<Decision>'::=<Context><DecisionFlags>[<NamedDecisionData:Provisioning)]〈NamedDecisionData:Provisioning>::=<InstallDecision>〈InstallDecision>::=*(<PRID><EPD>)此时，可以指定CommonHeader中OpCode=2，Flags=l;ClientHandler对象必选；在Decision对象中指定Command-Code=l(Install),Flags-0x02;在NamedDecisionData:Provisioning对象中指定C-Num=5;在InstallDecision对象中扩展Media-Encryption-Key字段，用于承栽主叫侧RACS接收到的密钥。如果是通过H.248协议下发密钥，则可以在使用添加(Add)命令向关联中增加终结点时，基于媒体描述(MediaDescriptor)的流描述(StreamDescriptor)来承载密钥，即将Diameter消息中Media-Encryption-Key字卑殳4直拷贝到MediaDescriptor的特性标识符SDP—A和encryptkey中。另外，当步骤202中主叫侧P-CSCF接收到呼叫请求消息后，一面继续执行后续的呼叫流程，即执行步骤206;—面生成和下发密钥，即执行步骤203~步骤205。也就是说，后续的呼叫流程与密钥的生成和下发是两个并列的流程，在时间上并没有严格的先后顺序。另外，本实施例中，主叫侧P-CSCF是通过发起资源预留过程将密钥发送给主叫侧MP,而在实际应用中，也可以通过一个独立的下发密钥的过程将密钥发送给主叫侧MP。也就是说，只要能够将生成的密钥发送给主叫MP即可。步骤206:被叫侧P-CSCF将呼叫请求消息发送给被叫终端。步骤207:被叫终端向被叫侧P-CSCF返回携带有自身加密能力信息的呼叫响应消息，被叫侧P-CSCF从呼叫响应消息中获取被叫终端的加密能力信息。这里，所述的呼叫响应消息与被叫终端接收到的呼叫请求消息相关，可以为183消息，也可以为200OK消息。步骤208:被叫侧P-CSCF将呼叫响应消息发送给主叫侧P-CSCF。步骤209:主叫侧P-CSCF通过呼叫响应消息将自身事先生成的密钥返回纟合主叫终端。本步骤中，如果呼叫响应消息为183消息，则主叫侧P-CSCF可以将事先生成的密钥x承载于SDP的k字段中发送给主叫终端。另外，如果之前采用RFC4568的声明机制，才可以将密钥承载到inline字段中。如果呼叫响应消息为200OK消息，则可以在200OK消息扩展一个SIP头域来7fc载密钥x。比如扩展一个Media-Key头;或，其4各式如下所示Media-Key:<Key>其中，Key表示生成的密钥。这样，就可以利用2000K将密钥x返回给主叫终端。步骤210:被叫侧P-CSCF中的生成密钥单元根据被叫终端的加密能力信息生成密钥y。步骤211:被叫侧P-CSCF发起资源预留过程，在所述资源预留过程中将携带有密钥y的报文发送给被叫侧RACS。步骤212:被叫侧RACS再将密钥y发送给被叫侧MP。这里，所述步骤211~步骤212是被叫侧P-CSCF将生成的密钥过程资源预留过程下发给被叫侧MP,其方法与步骤204~步骤205相同，此处不再详细描述。当主叫侧P-CSCF接收到呼叫响应消息时，一面执行后续的呼叫流程，即执行步骤208~步骤209;—面生成和下发密钥，即执行步骤210步骤212。也就是说，在被叫侧，后续的呼叫流程与密钥的生成和下发也是两个并列的流程，在时间上并没有严格的先后顺序。步骤213~步骤214:主叫终端通过主叫侧P-CSCF将确认消息发送给被叫侧P-CSCF。步骤215:被叫侧P-CSCF通过确认消息将生成的密钥y发送给被叫终端。本实施例中，被叫侧P-CSCF是通过确认消息，即PRACK消息或ACK消息将密钥y发送给被叫终端。如果被叫终端之前返回的是183消息，则主叫终端需要向被叫终端发送PRACK消息，被叫侧P-CSCF可以将密钥y承载于PRACK消息中SDP的k字段中；如果被叫终端之前返回的是200OK消息，则主叫终端需要向被叫终端发送ACK消息，被叫侧P-CSCF可以将密钥y承载于ACK消息中扩展的Media-Key字段中。步骤216:主叫终端、主叫侧MP、被叫侧MP和被叫终端利用各自获取的密钥传输媒体流。实际应用中，当主叫终端呼叫被叫终端时，交互的消息或信令应该通过信令链路传输，而但呼叫成功后，媒体流数据则应该通过数据链路传输，即通过主叫终端、主叫侧MP、被叫侧MP和被叫终端传输。传输媒体流的方法具体为当媒体流从主叫终端传输给被叫终端时，主叫终端利用获取的密钥x对:樣体流进行加密，将加密的々某体流传输给主叫侧MP;主叫侧MP再利用获取的密钥x对媒体流进行解密，然后将解密后的媒体流传输给被叫侧MP;被叫侧MP利用获取的密钥y将々某体流进行加密，将加密的i某体流传输给被叫终端，被叫终端再利用获取的密钥y对媒体流进行解密。当媒体流从被叫终端传输给主叫终端时，被叫终端利用密钥y对媒体流进行加密，将加密的媒体流传输给被叫侧MP;被叫侧MP再利用密钥y对媒体流进行解密，然后将解密后的媒体流传输给主叫侧MP;主叫侧MP利用密钥x将媒体流进行加密，将加密的媒体流传输给主叫终端；主叫终端再利用密钥x对媒体流进行解密。也就是说，媒体流在主叫侧用密钥x加密后进行安全传输，在被叫侧用密钥y加密后进行安全传输。另外，实际应用中，如果被叫终端返回183消息，主叫终端还需要在发送PRACK消息后，向被叫终端发送信息更新消息，即UPDATE消息。此时，被叫侧P-CSCF也可以不通过PACK消息向被叫终端发送密钥y，而是通过UPDATE消息向被叫终端发送密钥y。总之，本发明需要强调的是密钥生成单元在呼叫流程中获取终端的加密能力信息，根据加密能力信息生成密钥，再将密钥分别发送给终端和媒体流承载设备。至于从呼叫流程中的哪一条消息中获取加密能力信息，通过哪一条消息将密钥下发给终端，以及如何将密钥下发给媒体流承载设备都可以由应用本发明方案的用户自行确定，此处不再赘述。本发明实施例是以含有IP多媒体子系统(IMS)的网络，并且在IMS网络中信令链路可以提供安全保障的情况为例进行说明的。实际应用中，还可以将本发明方法应用于其他类型的网络中，如基于软交换的下一代网络，其方法与本发明类似，此处不再一一列举。针对安全传输媒体流的方法，本发明还提出一种安全传输媒体流的系统。图3是安全传输媒体流系统的基本结构示意图。如图3所示，该系统包括终端301、媒体流承载设备302和密钥生成单元303。其中，所述终端301，用于将自身加密能力信息发送给密钥生成单元303，获取密钥并根据密钥负责媒体流。所述媒体流承载设备302，用于接收由密钥生成单元303生成的密钥，根据密钥负责传输媒体流。所述密钥生成单元303，用于接收终端301输入的加密能力信息，生成密钥，并将生成的密钥分别发送给终端301和媒体流承载设备302。这里，所述终端301可以为主叫终端或被叫终端；所述々某体流承载设备302可以为主叫侧所述媒体流承载设备或被叫侧媒体流承载设备；所述密钥生成单元303可以为主叫侧密钥生成单元或被叫侧密钥生成单元，密钥生成单元可以为P-CSCF中的功能单元，也可以为独立的服务器。为了更好地说明本发明系统结构和功能，下面用一个系统实施例进行详细描述。200710000851.6说明书第16/17页系统实施例本实施例中，密钥生成单元为P-CSCF中的功能单元，媒体流承载设备为MP,通过RACS获取密钥。图4是本发明的系统结构示意图。如图4所示，本实施例包括主叫终端401、主叫侧P-CSCF402、主叫侧RACS403、主叫侧MP404、被叫终端405、被叫侧P-CSCF406、被叫侧RACS407、被叫侧MP408。所述主叫终端401和被叫终端405，分别将自身加密能力信息发送给主叫侧P-CSCF402和被叫侧P-CSCF406，获取密钥，根据密钥负责传输媒体流o所述主叫侧P-CSCF402和被叫侧P-CSCF406，分别生成密钥，并将生成的密钥分别发送给主叫侧RACS403和被叫侧RACS407。所述主叫侧RACS403和被叫侧RACS407,分别将主叫侧P-CSCF402和净皮叫侧P-CSCF406生成的密钥转发《会主叫侧MP404和#1叫侧MP408。所述主叫侧MP404和被叫侧MP408，分别从主叫侧RACS403和被叫侧RACS407接收密钥，根据密钥负责传输媒体流。当主叫终端401发起呼叫时，主叫终端401向主叫侧P-CSCF402发送携带有自身加密能力信息的呼叫请求消息；主叫侧P-CSCF402通过被叫侧P-CSCF406将呼叫请求消息发送给被叫终端405,同时，主叫侧P-CSCF402根据主叫终端401的加密能力信息生成密钥，并通过主叫側RACS403将密钥发送给主叫侧MP404;当被叫终端405接收到呼叫请求消息时，向被叫侧P-CSCF406返回携带有自身加密能力信息的呼叫响应消息；被叫侧P-CSCF楊将呼叫响应消息返回给主叫侧P-CSCF402,主叫侧P-CSCF402再将事先生成的密钥携带于呼叫响应消息返回给主叫终端401，同时，被叫侧P-CSCF406根据被叫终端405的加密能力信息生成密钥，并通过被叫侧RACS407将密铜发送纟会主叫侧MP408;此后，主叫全冬端401、主叫侧MP404、:故叫侧RACS407和被叫终端405再利用密钥传输i某体流。应用本发明方案，终端和媒体流承载设备可以获取由密钥生成单元生成的密钥，不需要进衧证书管理、时钟同步等比较复杂的过程，可以很容易地实现安全传输媒体流；主叫侧媒体流承载设备与被叫侧媒体流承载设备之间传输的是未经过加密的媒体流，可以满足合法机构在没有密钥的情况下，实现进行合法监听的实际需求；另外，由于主叫侧和被叫侧生成密钥是独立的，无需进行协商，在生成和下发密钥时可以不影响呼叫流程的执行。综上所述，以上仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。权利要求1.一种安全传输媒体流的方法，其特征在于，预先设置密钥生成单元，该方法包括以下步骤A、密钥生成单元在呼叫流程中获取终端的加密能力信息，并根据所述加密能力信息生成用于媒体流的密钥；B、再将生成的密钥分别发送给终端和用于媒体流承载设备；C、终端和媒体流承载设备利用获取的密钥传输媒体流。2、根据权利要求1所述的方法，其特征在于，所述密钥生成单元为主叫侧呼叫会话控制功能实体CSCF的功能单元，所述终端为主叫终端，则步骤A所述密钥生成单元获取加密能力信息的方法具体为主叫终端发起呼叫，将携带有自身加密能力信息的呼叫请求消息发送给主叫侧CSCF,主叫侧CSCF从呼叫请求消息中获取主叫终端的加密能力信息。3、根据权利要求2所述的方法，其特征在于，所述主叫终端的加密能力信息承载于呼叫请求消息的会话描述协议SDP中；或者承载于呼叫请求消息的会话初始协议SIP主叫属性接收协商Accept-contact头域中；或者承载于呼叫请求消息中SIP扩展协商域中，所述SIP扩展协商域为支持supported域；或者承载于呼叫请求消息中征求意见稿RFC4568标准所定义的字段中。4、根据权利要求2所述的方法，其特征在于，步骤B所述将密钥发送给主叫终端的方法为当主叫侧CSCF接收到来自被叫终端的呼叫响应消息时，将事先生成的密钥携带于所述呼叫响应消息发送给主叫终端。5、根据权利要求2所述的方法，其特征在于，所述媒体流承载设备为主叫侧媒体代理MP,步骤B所述将密钥发送给主叫侧MP的方法为主叫侧CSCF将携带有密钥的报文发送给主叫侧资源和接入控制子系统RACS，主叫侧RACS再将密钥发送给主叫侧MP。6、根据权利要求2所述的方法，其特征在于，所述步骤C具体为当媒体流从主叫终端传输给被叫终端时，主叫终端利用获取的密钥对媒体流进行加密，将加密的媒体流传输给主叫侧MP，主叫侧MP再利用获取的密钥对媒体流进行解密，然后将解密后的媒体流传输出去；和/或当媒体流从被叫终端传输给主叫终端时，主叫侧MP利用获取的密钥将来自被叫终端的媒体流进行加密，将加密的媒体流传输给主叫终端，主叫终端再利用获取的密钥对媒体流进行解密。7、根据权利要求1所述的方法，其特征在于，所述密钥生成单元为被叫侧CSCF中的功能单元，所述终端为被叫终端，则步骤A所述获取加密能力信息的方法具体为被叫终端通过被叫侧CSCF接收到来自主叫终端的呼叫请求消息，将携带有被叫终端自身加密能力信息的呼叫响应消息返回给被叫侧CSCF,被叫侧CSCF从呼叫响应消息中获取被叫终端的加密能力信息。8、根据权利要求7所述的方法，其特征在于，步骤B所述将密钥发送给被叫终端的方法为当被叫侧CSCF接收到来自主叫终端与呼叫相关的消息时，将事先生成的密钥携带于所述与呼叫相关的消息发送给被叫终端。9、根据权利要求7所述的方法，其特征在于，所述媒体流承载设备为被叫侧MP,步骤B所述将密钥发送给被叫侧MP的方法为被叫侧CSCF将携带有密钥的报文发送给被叫侧RACS，被叫侧RACS再将密钥发送给被叫侧MP。10、根据权利要求7所述的方法，其特征在于，所述步骤C具体为当媒体流从主叫终端传输到被叫终端时，被叫侧MP利用获取的密钥将来自主叫终端的媒体流进行加密，将加密的媒体流传输给被叫终端，被叫终端再利用获取的密钥对+某体流进行解密；和/或当媒体流从被叫终端传输到主叫终端时，被叫终端利用获取的密钥对媒体流进行加密，将加密的媒体流传输给被叫侧MP,被叫侧MP再利用获取的密钥对媒体流进行解密，然后将解密后的媒体流传输出去。11、一种姿全传输媒体流的系统，包括终端、媒体流承栽设备，其特征在于，该系统还包括密钥生成单元；所述终端，用于将自身加密能力信息发送给密钥生成单元，获取密钥，根据密钥负责传输媒体流；所述媒体流承载设备，用于接收由密钥生成单元生成的密钥，根据密钥负责传输媒体流；所述密钥生成单元，用于接收终端输入的加密能力信息，生成密钥，并将生成的密钥分别发送给终端和^^某体流承载设备。12、根据权利要求11所述的系统，其特征在于，所述密钥生成单元为P-CSCF中的功能单元，所述媒体流承载设备为MP,该系统进一步包括RACS，用于接收由P-CSCF中密钥生成单元所生成的密钥，并将密钥转发给MP。全文摘要本发明提供一种安全传输媒体流的方法和系统，具体为预先设置密钥生成单元，密钥生成单元在呼叫流程中获取终端的加密能力信息，并根据所述加密能力信息生成用于媒体流的密钥；再将生成的密钥分别发送给终端和媒体流承载设备；终端和媒体流承载设备利用获取的密钥传输媒体流。应用本发明方案，主叫终端和被叫终端自身并不生成密钥，而是由密钥生成单元生成密钥，无需进行时钟同步，也无需公钥基础设施(PKI)体系的支持，可以大大降低端到端媒体流密钥协商的复杂度，便于媒体流加密业务的推广并可以满足合法监听的实际需求。文档编号H04N7/167GK101222612SQ20071000085公开日2008年7月16日申请日期2007年1月12日优先权日2007年1月12日发明者涛孔,恺孙,高江海,静黎申请人:华为技术有限公司