專利名稱：：一種分配媒體流密鑰的方法和多媒體子系統(tǒng)的制作方法
技術領域：
：本發(fā)明涉及媒體流加密技術，特別是涉及一種分配媒體流密鑰的方法多媒體子系統(tǒng)。
背景技術：
：士某體流一般基于實時傳輸十辦i義(RTP，Real-timeTransportProtocol)進行傳輸，這里的所述的媒體流為音頻媒體流、視頻媒體流等。但由于RTP協(xié)議本身并不涉及安全問題，使媒體流在傳輸過程中存在泄密、被攻擊等安全隱患。為了加強媒體流在傳輸過程中的安全性，目前已提出多種生成和分配密鑰的方法，即密鑰協(xié)商方法。之后，終端可以利用分配的密鑰實現(xiàn)媒體流的傳輸，達到安全傳輸媒體流的目的。在現(xiàn)有技術中，密鑰協(xié)商方法中有兩種典型方法一種是多媒體因特網(wǎng)密鑰(MIKEY)公鑰模式，另一種是MIKEYDH模式。其中，MIKEY公鑰模式的基本思想是由主叫終端生成密鑰和信封密鑰，所述密鑰用信封密鑰進行加密，信封密鑰再利用被叫終端證書的公鑰進行加密，然后將加密后的密鑰通過MIKEY協(xié)議發(fā)送到被叫終端，被叫終端解密后獲得密鑰，完成密鑰協(xié)商過程。在MIKEY公鑰模式中，為了保障密鑰協(xié)商過程的安全、順利地進行，要求主叫終端和被叫終端之間進行時鐘同步，并具備公鑰基礎設施(PKI)系統(tǒng)的支持。而實際應用中，實現(xiàn)時鐘同步以及PKI系統(tǒng)支持比較復雜，不利于密鑰協(xié)商的實現(xiàn)。比如在電話會議中，存在多個需要傳輸媒體流的終端。如果要對多個終端的媒體流加密，則需要將多個終端進行時鐘同步，這大大增加了密鑰協(xié)商的困難。又比如主叫終端和被叫終端為普通的移動終端，而由于移動終端數(shù)量大，將很難完成PKI系統(tǒng)中證書管理等工作，無法順利進行密鑰協(xié)商。MIKEYDH模式的基本思想是在主叫終端和被叫終端分別生成DH值，再利用MIKEY協(xié)議交換彼此的DH值，然后根據(jù)雙方的DH值產(chǎn)生密鑰。MIKEYDH才莫式也需要進行時鐘同步，而且實現(xiàn)MIKEYDH才莫式非常復雜，計算量大，對終端性能要求高，不利于密鑰協(xié)商的實現(xiàn)。另外，實際應用中，運營商為了安全機構(gòu)滿足合法監(jiān)聽的要求，需要獲得媒體流中的密鑰。而現(xiàn)有技術中，只有參與交互的終端才可以獲得密鑰，這里所述參與交互的終端可能為主叫和被叫兩個終端，也可能為多個終端，任何參與交互之外的第三方都無法獲得密鑰，即無法滿足合法監(jiān)聽的要求。
發(fā)明內(nèi)容有鑒于此，本發(fā)明的主要目的在于提供一種分配媒體流密鑰的方法和多媒體子系統(tǒng)，可以在保證鏈路安全的條件下，避免時鐘同步、PKI支持、證書管理等過程，減少生成密鑰的復雜度，便于媒體流加密業(yè)務的推廣。為了達到上述第一個目的，本發(fā)明提出的技術方案為一種分配媒體流密鑰的方法，預先設置生成密鑰的安全應用服務器，當主叫終端發(fā)起呼叫時，該方法包括A、安全應用服務器根據(jù)呼叫請求消息判斷主叫終端所屬域與被叫終端所屬域是否已簽署密鑰分發(fā)協(xié)議，如果已經(jīng)簽署，執(zhí)行步驟B后退出本流程；否則執(zhí)行步驟C;B、安全應用服務器根據(jù)在呼叫過程中獲得的加密能力信息生成密鑰，并將生成的同一個密鑰分配給主叫終端和被叫終端；C、安全應用服務器根據(jù)在呼叫過程中獲得的加密能力信息生成密鑰，并將生成的密鑰分配給自身所在一側(cè)的終端。為了達到上述第二個目的，本發(fā)明提出的技術方案為一種多4某體子系統(tǒng)，至少包括主叫終端和被叫終端，該系統(tǒng)還包括安全應用服務器，用于根據(jù)主叫終端所屬域與被叫終端所屬域的簽約情況確定加密方式，根據(jù)在呼叫過程中獲得的加密能力信息生成密鑰，并將生成的密鑰發(fā)送給終端。綜上所迷，本發(fā)明提出的一種分配媒體流密鑰的方法和多媒體系統(tǒng)，由于主叫終端和被叫終端自身并不生成密鑰，而是安全應用服務器生成密鑰的，無需進行時鐘同步，也無需PKI體系的支持，可以大大降低媒體流密鑰協(xié)商的復雜度，便于媒體流加密業(yè)務的推廣。圖l是本發(fā)明的流程圖；圖2是方法實施例一的消息流示意圖；圖3是方法實施例二的消息流示意圖；圖4是方法實施例三的消息流示意圖；圖5是方法實施例四的消息流示意圖；圖6是方法實施例五的消息流示意圖；圖7是本發(fā)明系統(tǒng)基本結(jié)構(gòu)示意圖；圖8是系統(tǒng)實施例的基本結(jié)構(gòu)示意圖。具體實施方式為使本發(fā)明的目的、技術方案和優(yōu)點更加清楚，下面將結(jié)合附圖及具體實施例對本發(fā)明作進一步地詳細描述。本發(fā)明的基本思想是根據(jù)主叫終端所屬域和被叫終端所屬域簽署密鑰分發(fā)協(xié)議的情況確定加密方式，如果簽署了協(xié)議，就采用端到端加密協(xié)商方式獲取相應的密鑰，如果沒有簽署協(xié)議，就利用分段加密方式獲取相應的密鑰。根據(jù)主叫側(cè)開通加密業(yè)務的情況，可以將本發(fā)明分為兩種類型，一種是主加側(cè)將加密業(yè)務作為基本業(yè)務的類型，另一種是主叫側(cè)將加密業(yè)務作為增值業(yè)務的類型。對于主叫側(cè)將加密業(yè)務作為基本業(yè)務的情況下，不管是采用端到端加密協(xié)商方法，還是采用分段加密方式，主叫側(cè)安全應用服務器都將生成密鑰，其方法可以如圖1所示。預先設置生成密鑰的安全應用服務器，當主叫終端發(fā)起呼叫時，終端設備獲取媒體流密鑰的方法包括以下步驟步驟101:安全應用服務器根據(jù)呼叫請求消息判斷主叫終端所屬域與被叫終端所屬域是否已簽署密鑰分發(fā)協(xié)議，如果已經(jīng)簽署，執(zhí)行步驟102后退出本流程；否則執(zhí)行步驟103;呼叫請求消息可以攜帶有用戶標識，安全應用服務器根據(jù)用戶標識可以查詢主叫終端運營商與被叫終端運營商簽署密鑰分發(fā)協(xié)議的相關信息。比如如果簽署了協(xié)議，可事先將簽署密鑰分發(fā)協(xié)議的相關信息設置為"已簽署"，否則，設置為"未簽署"。步驟102:安全應用服務器根據(jù)在呼叫過程中獲得的加密能力信息生成密鑰，并將生成的同一個密鑰分配給主叫終端和被叫終端；本步驟是利用端到端加密協(xié)商方式獲得相應的密鑰，即主叫終端和被叫終端在呼叫過程中協(xié)商生成密鑰的加密能力信息，安全應用服務器根據(jù)雙方協(xié)商確定的加密能力信息生成密鑰，再將生成的密鑰分別發(fā)送給主叫終端和被叫終端。在實現(xiàn)時，該方法可以具體為bl、被叫終端接收來自主叫終端的呼叫請求消息，所述呼叫請求消息攜帶有主叫終端的加密能力信息；b2、被叫終端根據(jù)主叫終端的加密能力信息和自身的加密能力信息，確定生成密鑰的加密能力信息，再返回攜帶有生成密鑰的加密能力信息的呼叫響應消息；b3、主叫側(cè)安全應用服務器根據(jù)呼叫響應消息中的加密能力信息生成密鑰并將生成的密鑰發(fā)送給主叫終端；M、主叫終端再向被叫終端發(fā)送呼叫相關消息，在發(fā)送所述呼叫相關消息的過程中，主叫側(cè)安全應用服務器將生成的密鑰攜帶于所述呼叫相關消息發(fā)送給被叫終端。利用上述端到端加密協(xié)商方式后，主叫終端和被叫終端都可以獲取密鑰，在此后整個傳輸過程中，可以利用獲取的密鑰對媒體流進行加密傳輸。步驟103:安全應用服務器根據(jù)在呼叫過程中獲得的加密能力信息生成密鑰，并將生成的密鑰分配給自身所在一側(cè)的終端。本步驟是利用分段加密方式獲取相應的密鑰，即主叫側(cè)和被叫側(cè)分別生成各自的密鑰，其實現(xiàn)方法可以為cl、主叫側(cè)安全應用服務器記錄來自主叫終端呼叫請求消息中的主叫終端加密能力信息；c2、被叫終端在接收到呼叫請求后，返回攜帶有自身加密能力信息的呼叫響應消息，被叫側(cè)安全應用服務器從呼叫響應消息中獲取并記錄被叫終端的加密能力信息；c3、主叫側(cè)安全應用服務器將根據(jù)主叫終端加密能力信息生成的密鑰發(fā)送給主叫終端，并下發(fā)給主叫側(cè)媒體流承栽設備；c4、被叫側(cè)安全應用服務器將根據(jù)被叫終端加密能力信息生成的密鑰發(fā)送給被叫終端，并將生成的密鑰下發(fā)給被叫側(cè)媒體流承載設備。在利用分段加密協(xié)商的方式中，主叫終端、主叫側(cè)媒體流承栽設備、被叫側(cè)媒體流承載設備和被叫終端都獲取了密鑰，在此后的媒體流傳輸過程中，主叫終端和主叫側(cè)媒體流承載設備之間將傳輸經(jīng)過加密的媒體流，被叫側(cè)媒體流承栽設備和被叫終端之間也將傳輸經(jīng)過加密的媒體流，而主叫側(cè)媒體流承載設備和被叫側(cè)媒體流承栽設備之間將傳輸明文的媒體流。這里所述分段加密方式獲取相應的密鑰的方法是在被叫側(cè)將加密業(yè)務作為基本業(yè)務的情況下的方法。如果被叫側(cè)將加密業(yè)務作為增值業(yè)務，則在被叫終端接收呼叫請求之前，該方法還可以進一步包括被叫側(cè)安全應用服務器查詢事先設置的加密業(yè)務簽約信息，根據(jù)用戶標識判斷出被叫終端是否已經(jīng)簽約，如果已經(jīng)簽約，則繼續(xù)執(zhí)行，即執(zhí)行上述c2c4的步驟；否則，執(zhí)行步驟X;所述步驟X為在被叫終端返回呼叫響應消息過程中，主叫側(cè)安全應用服務器將根據(jù)主叫終端加密能力信息生成的密鑰發(fā)送給主叫終端，并下發(fā)給主叫側(cè)媒體流承栽設備。這里，在步驟X中，由于只有主叫終端和主叫側(cè)4某體流獲取了密鑰，在此后的媒體流傳輸過程中，只有主叫側(cè)對媒體流進行加密，而被叫側(cè)對媒體流進行明文傳輸。上述是主叫側(cè)將加密作為基本業(yè)務的情況，如果主叫側(cè)將加密作為增值業(yè)務，并且在被叫側(cè)將加密業(yè)務作為基本業(yè)務的情況下，可以在步驟101檢查簽署分發(fā)密鑰協(xié)議之前，該方法進一步包括主叫側(cè)安全應用服務器查詢事先設置的加密業(yè)務簽約信息，根據(jù)用戶標識判斷主叫終端是否已經(jīng)簽約，如果已經(jīng)簽約，則繼續(xù)執(zhí)行步驟101;否則，執(zhí)行步驟Y;所述步驟Y為yl、被叫終端接收來自主叫終端的呼叫請求消息，所述呼叫請求消息攜帶有主叫終端的加密能力信息；y2、被叫終端根據(jù)主叫終端的加密能力信息和自身的加密能力信息，確定生成密鑰的加密能力信息，返回攜帶有生成密鑰的加密能力信息的呼叫響應消自y3、被叫側(cè)安全應用服務器根據(jù)呼叫響應消息中的加密能力信息生成密鑰，并將生成的密鑰發(fā)送給主叫終端；y4、主叫終端再向被叫終端返回呼叫相關消息，被叫側(cè)安全應用服務器通過所述呼叫相關消息將生成的密鑰發(fā)送給^^皮叫終端。這里，由于主叫終端和被叫終端都獲取了密鑰，在此后整個傳輸過程中，可以利用獲取的密鑰對i某體流進行加密傳輸。與主叫側(cè)將加密業(yè)務作為基本業(yè)務不同的是，這里所迷的端到端加密所利用的密鑰是由被叫側(cè)安全應用服務器生成的。當然，步驟yl所述被叫終端接收到呼叫響應消息之前，主叫側(cè)安全應用服務器還可以先4艮據(jù)呼叫請求消息判斷出主叫終端所屬域與被叫終端所屬域已簽署密鑰分發(fā)協(xié)議，之后，呼叫請求消息才被發(fā)送給被叫終端。如果被叫側(cè)將加密業(yè)務作為增值業(yè)務，那么，在步驟yl所述被叫終端接收到呼叫請求消息之前，該方法還可以包括被叫側(cè)安全應用服務器查詢事先設置的加密業(yè)務簽約信息，根據(jù)用戶標識判斷出被叫終端已經(jīng)簽約。如果判斷出被叫終端沒有簽約，也就是說，主叫側(cè)和被叫側(cè)都不支持加密業(yè)務，那么，主叫終端和被叫終端將不會獲取密鑰，并將按照現(xiàn)有技術實現(xiàn)呼叫流程。不管主叫側(cè)將加密業(yè)務作為基本業(yè)務，還是作為增值業(yè)務，這里所述的呼叫請求消息都是攜帶有加密能力信息的呼叫請求消息，即主叫終端主動要求進行加密。實際應用中，，主叫終端可以不支持加密或者不要求加密，發(fā)出的呼叫請求消息為不帶加密能力信息的呼叫請求消息。在這種情況下，就可以先判斷呼叫請求消息是否攜帶有加密能力信息，如果有，再繼續(xù)執(zhí)行；如果沒有，則執(zhí)行步驟Z;所述步驟Z為zl、被叫終端接收到呼叫請求消息后，返回攜帶有加密能力信息的呼叫響應消息；z2、被叫側(cè)安全應用服務器從呼叫響應消息中獲得并記錄被叫終端的加密能力信息；z3、當主叫終端接收到呼叫響應消息后，再向被叫終端發(fā)送呼叫相關消息，在發(fā)送的過程中，被叫側(cè)安全應用服務器將根據(jù)加密能力信息生成的密鑰通過呼叫相關消息發(fā)送給被叫終端，并下發(fā)給被叫側(cè)媒體流承載設備。由于只有被叫終端和被叫側(cè)媒體流承載設備獲取了密鑰，在此后的媒體流傳輸過程中，只有被叫側(cè)利用獲取的密鑰對媒體流進行加密傳輸，而主叫側(cè)對媒體流進行明文傳輸。這里，由于主叫終端發(fā)送的是不包含加密能力信息的呼叫請求，還可以在所述被叫終端接收到呼叫請求消息之前，由被叫側(cè)安全應用服務器將事先保存的加密能力信息插入呼叫請求消息；這樣，被叫終端返回呼叫響應消息之前，被叫終端就可以根據(jù)呼叫請求消息中的加密能力信息和自身加密能力信息，確定生成密鑰的加密能力信息，并將確定生成密鑰的加密能力信息添加到呼叫響應消息中。另外，這里所述步驟Z是被叫側(cè)將加密業(yè)務作為基本業(yè)務的情況。如果將加密業(yè)務作為增值業(yè)務，被叫終端接收到呼叫請求消息之前，被叫側(cè)安全應用服務器還可以先查詢事先設置的加密業(yè)務簽約信息，根據(jù)用戶標識判斷出被叫終端已經(jīng)簽約。當然，如果判斷出被叫終端沒有簽約，則可以直接執(zhí)行現(xiàn)有的呼叫流程，主叫終端和被叫終端都不會獲取密鑰。實際應用中，所述呼叫流程中主叫終端和被叫終端之間交互的消息可以包括獲取密鑰狀態(tài)標識，如果主叫終端/被叫終端沒有獲取密鑰，則將發(fā)送給被叫終端/主叫終端消息中的獲取密鑰狀態(tài)標識設置為未獲取密鑰標識；否則，設置為已獲取密鑰標識。通過獲取密鑰狀態(tài)標識可以使呼叫雙方將自身獲取密鑰的情況通知給對方。實際應用中，本發(fā)明所述的安全應用服務器可以為IP多々某體子系統(tǒng)的應用服務器(IMS-AS)，可以為呼叫會話控制功能實體(CSCF)中的功能模塊，也可以為第三方服務器。如果安全應用服務器為IMS-AS,呼叫請求消息是主叫終端經(jīng)過主叫側(cè)IMS-AS和被叫側(cè)IMS-AS發(fā)送給被叫終端的，那么路由呼叫請求消息的方法具體為主叫終端將呼叫請求消息發(fā)送給主叫側(cè)S-CSCF;主叫側(cè)S-CSCF根據(jù)事先獲得的過濾準則，對接收到的呼叫請求消息進行過濾處理，并將攜帶有加密能力信息的呼叫請求消息轉(zhuǎn)發(fā)給主叫側(cè)安全應用服務器；主叫側(cè)安全應通過主叫側(cè)S-CSCF發(fā)送給被叫側(cè)S-CSCF;被叫側(cè)S-CSCF根據(jù)事先獲得的過濾準則，對接收到的呼叫請求消息進行過濾處理，并將攜帶有加密能力信息的呼叫請求消息轉(zhuǎn)發(fā)給被叫側(cè)安全應用服務器；被叫側(cè)安全應用服務器再將呼叫請求消息轉(zhuǎn)發(fā)給被叫終端。為了更好地說明本發(fā)明方案，下面用較佳實施例進行詳細描述。方法實施例一本實施例中，主叫側(cè)和被叫側(cè)都將加密業(yè)務作為基本業(yè)務，并且，主叫側(cè)所屬運營商和被叫側(cè)所屬運營商之間已經(jīng)簽署了分發(fā)密鑰協(xié)議；所述安全應用服務器為IMS-AS，分為主叫側(cè)IMS-AS和被叫側(cè)IMS-AS，并由主叫側(cè)IMS-AS生成密鑰。圖2是本實施例的消息流示意圖。如圖2所示，本實施例包括以下步驟步驟201:主叫終端發(fā)起呼叫，將呼叫請求消息發(fā)送給主叫側(cè)S-CSCF;這里所述的呼叫請求消息就是會話初始協(xié)議(SIP)中的INVITE消息，可以采用四種方法將主叫終端的加密能力信息承栽在INVITE消息中第一種方法是承載在INVITE消息的會話描述協(xié)議(SDP)中；第二種方法是承載在INVITE消息中SIP主叫屬性接收協(xié)商(Accept-contact)頭域中;第三種方法是承載在INVITE消息中SIP的擴展協(xié)商域中；第四種方法是承載在INVITE消息中征求意見稿(RFC4568)標準所定義的字段中。這里所述的加密能力信息也可以稱為加密能力聲明，可以包括SRTP支持、加密算法的支持、密鑰長度的支持等信息。前三種承載方式可以參見本申請人:另一專利申請，此處不再贅述。對于第四種承載方式，可以將加密能力信息承載到SDP的a字段中。另外，呼叫請求消息中還可以攜帶關于加密的安全前提，安全前提中可以包括指定加密方式的標識。在這種情況下，第四種承載方式的格式可以為m=video51372RTP/SAVP31a=cuir:sece2enonea=des:secmandatorye2esendrecva=crypt():1AES—CM_128_HMAC—SHA1—80inline:a=crypt():2AES—CM—128HMAC—SHA1—32inline:m=audio49170RTP/SAVP0a=curr:sec6之cnonea=des:secmandatorye2esendrecva=crypto:lAES—CM—128—HMAC_SHA1_32inline:a=crypto:2AES_CM—128_HMAC—SHA1—80inline:這里包括關于視頻流和音頻流的兩個加密能力聲明和安全前提，以關于視頻流的為例，其中，"a=curr:sece2enone，，和"a:des:secmandatorye2esendrecv"就是安全前提，表示主叫終端期望強制的端到端接收和發(fā)送兩個方面的媒體流加密，同時指出當前主叫終端還沒有實現(xiàn)與媒體流加密有關的前提。另外，"inline"字段表示用于承載密鑰。如果主叫終端還沒有獲取密鑰，"inline"字段應該為空；如果網(wǎng)絡側(cè)生成了密鑰并需要發(fā)送給主叫終端，那么，就可以將生成的密鑰承栽于返回主叫終端的消息中的"inline"字段中，主叫終端可以從"inline"字段中獲取密鑰。實際應用中，由于存在被叫終端可能不支持加密的情況，為了保證呼叫能夠成功，也可以在呼叫請求消息中包括不含加密信息的聲明，即在上述聲明后增力o以下兩個聲明m=video51372RTP/AVP31m-audio49170RTP/AVP0這樣，如果對方不支持加密，則可以按照現(xiàn)有技術完成呼叫過程。步驟202~步驟203:主叫側(cè)S-CSCF根據(jù)事先獲得的過濾準則，對接收到的呼叫請求消息進行過濾處理，并將攜帶有加密能力信息的呼叫請求消息轉(zhuǎn)發(fā)給主叫側(cè)IMS-AS。本實施例中，由于主叫側(cè)將加密業(yè)務作為基本業(yè)務，那么這里所述的過濾準則可以是事先為用戶提供的缺省過濾準則，其格式可以如表一所示優(yōu)先級觸發(fā)點SIP方法證ITESIP消息頭Require:preconditiona=cryptom=RTP/SAVPM情形源端(Originating)地址主叫側(cè)IMS-AS的地址表一這樣，就可以將呼叫請求消息觸發(fā)給主叫側(cè)IMS-AS處理，并且，在此后的呼叫過程中，主叫側(cè)IMS-AS將處于呼叫的信令鏈路中，即所有與呼叫相關的消息都將經(jīng)過主叫側(cè)IMS-AS。步驟204~步驟206:主叫側(cè)IMS-AS判斷出主叫終端所屬域與被叫終端所屬域已簽署密鑰分發(fā)協(xié)議，并將呼叫請求消息通過主叫側(cè)S-CSCF發(fā)送給被叫側(cè)S-CSCF。如果呼叫請求消息中還攜帶有包括安全前提，并在安全前提中包括端到端加密標識，主叫側(cè)IMS-AS根據(jù)呼叫請求就可以判斷出這里一個要求端到端加密的呼叫請求消息。另外，由于本實施例由主叫側(cè)IMS-AS生成密鑰，為了將生成密鑰的情況通知給被叫側(cè)IMS-AS,主叫側(cè)IMS-AS還可以將主叫側(cè)生成密鑰標識插入呼叫請求消息。步驟207~步驟210:被叫側(cè)S-CSCF根據(jù)事先獲得的過濾準則，對接收到的呼叫請求消息進行過濾處理，并將攜帶有加密能力信息的呼叫請求消息轉(zhuǎn)發(fā)給被叫側(cè)IMS-AS,再通過被叫側(cè)S-CSCF轉(zhuǎn)發(fā)給被叫終端。與主叫側(cè)相似，本實施例中，被叫側(cè)也是將加密業(yè)務作為基本業(yè)務，這里所述的過濾準則可以是事先為用戶提供的缺省過濾準則，其格式如表二所示<table>tableseeoriginaldocumentpage18</column></row><table>表二這樣，就可以將呼叫請求消息觸發(fā)給被叫側(cè)IMS-AS處理，并且，在此后的呼叫過程中，被叫側(cè)IMS-AS將處于呼叫的信令鏈路中，即所有與呼叫相關的消息都將經(jīng)過被叫側(cè)IMS-AS。如果呼叫請求消息包括加密方式和生成密鑰側(cè)標識，被叫側(cè)S-CSCF從呼叫請求消息就可以判斷出該呼叫要求端到端加密方式，并且由主叫側(cè)IMS-AS生成密鑰。步驟211~步驟216:被叫終端根據(jù)呼叫請求消息中主叫終端的加密能力信息和自身的加密能力信息，確定生成密鑰的加密能力信息，再向主叫側(cè)IMS-AS:E4回攜帶有生成密鑰的加密能力信息的呼叫響應消息。本實施例中，凈皮叫終端可以返回m=video31337RTP/SAVP31a=curr:sece2enonea=des:secmandatorye2esendrecva=conf:sece2esendrecva=crypto:lAES_CM—128—HMAC—SHA1—80CALLER-ALLOC-KEYinline:m=audio31399RTP/SAVP0<formula>formulaseeoriginaldocumentpage19</formula>在呼叫請求消息中包括有加密能力信息的和沒有加密能力信息的兩種呼叫請求的情況下，如果被叫終端不支持加密，將返回4xx錯誤消息，或者針對沒有加密能力信息的呼叫請求返回呼叫響應消息，即實現(xiàn)普通的呼叫。步驟217-步驟220:主叫側(cè)IMS-AS根據(jù)呼叫響應消息中的加密能力信息生成密鑰，并將生成的密鑰返回給主叫終端。如果消息中包括安全前提，當主叫終端從呼叫響應消息中獲取密鑰后，還可以更改安全前提，同時向被叫終端發(fā)送確認信息。比如<formula>formulaseeoriginaldocumentpage19</formula>其中，第二行和第七行粗體字部分就是更改后的前提。步驟221-步驟229:主叫終端向被叫終端發(fā)送呼叫相關消息，在發(fā)送的過程中，主叫側(cè)IMS-AS將生成的密鑰攜帶于所述呼叫相關消息發(fā)送給被叫終端。這里所迷呼叫相關消息可以為確認消息(PRACK)或更新信息消息(UPDATE)等消息。本實施例中，主叫側(cè)IMS-AS可以由以下方式將密鑰攜帶于消息中，即承載在inliae字段中。比如m=video51372RTP/SAVP31a=curr:sccc2cssndrecva=des:secmandatorye2esendrecva=crypto:lAES_CM—128_HMAC_SHA1—80CALLER曙ALLOC-KEYinline:dORmd旭cmVCspeEc3QGZiNWpVLFJhQXlcfflAwJSojm=audi()49170RTP/SAVP0a=curr:sece之esendrecva=des:secmandatorye2esendrecva=c(mf:sece2esendrecva=crypto:lAES—CM_128_HMAC_SHA1_32CALLER-ALLOC-KEYinline:NzB4dlBINUAvLEw6UzF3WSJ+PSdFcGdUJShpXlZj其中，第五行和第十一行粗體就是攜帶的密鑰。當然，主叫終端和被叫終端之間還需要完成呼叫的其他過程，比如當接收到PRACK消息后，被叫終端還需要向主叫終端返回200OK消息，呼叫流程的具體情況可以參見現(xiàn)有技術，此處不再贅述。本實施例中的安全應用服務器是以IMS-AS為例進行說明的，實際應用中，安全應用服務器也可以是S-CSCF中的功能模塊，或者為第三方服務器。在這種情況下，呼叫信令鏈路可以與現(xiàn)有技術中的信令鏈路相同，實現(xiàn)端到端加密的方法與本實施例相似，其區(qū)別在于如果是S-CSCF中的功能模塊，檢查主叫終端所屬域和被叫終端所屬域是否簽署協(xié)議、將主叫側(cè)密鑰生成側(cè)標識插入呼叫請求消息、生成密鑰等都可以直接由主叫側(cè)S-CSCF完成；如果是第三方服務器，第三方服務器可以只負責生成密鑰，檢查主叫終端所屬域和被叫終端所屬域是否簽署協(xié)議、將主叫側(cè)密鑰生成側(cè)標識插入呼叫請求消息等可以由S-CSCF完成；或者，檢查主叫終端所屬域和被叫終端所屬域是否簽署協(xié)議、將主叫側(cè)密鑰生成側(cè)標識插入呼叫請求消息、生成密鑰等全部由第三方服務器完成，不管是哪種方法，都需要S-CSCF和第三方服務器之間確定交互的協(xié)議，所迷交互的協(xié)議可以由應用本發(fā)明方案的用戶自行確定。方法實施例二本實施例中，主叫側(cè)和被叫側(cè)都將加密業(yè)務作為基本業(yè)務，但主叫終端所屬域和被叫終端所屬域之間沒有簽署密鑰分發(fā)協(xié)議；本實施例中，安全應用服務器為S-CSCF中的功能模塊，即安全應用單元，但為了更好地說明流程，仍然將S-CSCF和安全應用單元分開敘述。圖3是本實施例的消息流示意圖。如圖3所示，本實施例包括以下步驟步驟301~步驟303與實施例一的步驟201~步驟203相似，其區(qū)別僅僅在于，主叫側(cè)S-CSCF將呼叫請求消息發(fā)送給自身的安全應用單元處理。步驟304~步驟306:主叫側(cè)安全應用單元判斷出主叫終端所屬域與尋皮叫終端所屬域沒有簽署密鑰分發(fā)協(xié)議，記錄下呼叫請求消息中的主叫終端的加密能力信息后，再將呼叫請求消息發(fā)送給被叫側(cè)S-CSCF。與實施例一相似，如果呼叫請求消息中還攜帶有包括安全前提，并在安全前提中包括端到端加密標識，主叫側(cè)安全應用單元根據(jù)呼叫請求就可以判斷出這里一個要求端到端加密的呼叫請求消息。但由于主叫終端所屬域與被叫終端所屬域沒有簽署密鑰分發(fā)協(xié)議，主叫側(cè)安全應用單元則可以確定采用分段加密的方式。為了將加密方式通知給被叫側(cè)，主叫側(cè)安全應用單元還可以將端到端加密標識更改為分萃殳加密標識。此后，；故叫側(cè)就可以才艮據(jù)該標識確定該呼叫請求要求進行分段加密。如果不需要被叫終端的用戶獲取加密方式已經(jīng)被更改過，被叫側(cè)還可以將分段加密標識更改為端到端加密標識之后再發(fā)送給被叫終端。當然，這種情況下，當被叫終端返回消息時，也需要將其中的端到端加密標識又重新更改為分,殳加密標識。實際應用中，在確定為分段加密方式后，如果終端具備解析標志能力，還可以提示用戶此次會話不能完全保證通話的安全性。另外，由于進行分段加密，主叫側(cè)和被叫側(cè)雙方無需知道對方的加密能力信息，可以在確定采用分段加密的情況下，將呼叫請求消息中的與加密相關的信息刪除。如果網(wǎng)絡側(cè)采用哪種加密方式的情況并不需要報告給主叫終端，那么，在返回消息給主叫終端時，還可以將事先更改過的加密方式重新恢復為端到端加密。307-步稞310與實施例一中的步驟207-步驟210相似，其區(qū)別僅僅在于，被叫側(cè)S-CSCF將呼叫請求消息發(fā)送給自身的安全應用單元處理。步驟311步驟314:被叫終端在接收到呼叫請求消息后，返回攜帶有自身加密能力信息的呼叫響應消息，被叫側(cè)安全應用服務器從呼叫響應消息中獲取并記錄被叫終端的加密能力信息。步驟315~步驟321:被叫側(cè)S-CSCF繼續(xù)將呼叫響應消息發(fā)送給主叫終端，在發(fā)送的過程中，主叫側(cè)安全應用單元將根據(jù)主叫終端加密能力信息生成的密鑰攜帶于呼叫響應消息中發(fā)送給主叫終端，并下發(fā)給主叫側(cè)媒體流承載設備。本實施例中，主叫側(cè)安全應用單元是在步驟317中根據(jù)步驟304記錄的主叫終端加密能力信息生成密鑰的，但在實際應用中，只要主叫側(cè)安全應用單元獲得了主叫終端得加密能力信息，任何時候都可以生成密鑰，并不一定在步驟317生成。另外，本實施例中，所述媒體流承載設備可以為MP。當主叫側(cè)安全應用單元需要將生成的密鑰下發(fā)給MP時，該方法為主叫側(cè)安全應用單元通過主叫側(cè)S-CSCF將攜帶有密鑰的呼叫響應消息發(fā)送給主叫側(cè)P-CSCF，主叫側(cè)P-CSCF再將攜帶有密鑰的才艮文發(fā)送給主叫側(cè)MP。實際應用中，當主叫側(cè)P-CSCF需要將密鑰下發(fā)給主叫側(cè)MP時，可以通過資源和接入控制子系統(tǒng)(RACS)將密鑰下發(fā)給主叫側(cè)MP。比如主叫側(cè)P-CSCF發(fā)起資源預留過程，在資源預留過程中，主叫側(cè)P-CSCF將生成的密鑰發(fā)送給主叫側(cè)RACS，主叫側(cè)RACS再將密鑰發(fā)送給主叫側(cè)MP。當然，主叫側(cè)P-CSCF也可以通過一個獨立的下發(fā)密鑰的過程將密鑰發(fā)送給主叫側(cè)MP,只要能夠?qū)⒚荑€發(fā)送給主叫MP即可。步驟322-步驟328:主叫終端向被叫終端發(fā)送呼叫相關消息，并在發(fā)送呼叫相關消息的過程中，被叫側(cè)安全應用單元將根據(jù)被叫終端加密能力信息生成的密鑰攜帶于呼叫相關消息中發(fā)送給被叫終端，并下發(fā)給被叫側(cè)媒體流承栽設備。這里，所述呼叫相關消息可以為任何從主叫終端發(fā)送給被叫終端的消息，比如UPDATE消息、PRACK消息等。與主叫側(cè)生成密鑰相似，本實施例中，被叫側(cè)安全應用單元是在步驟323時，根據(jù)步驟313獲取的被叫終端的加密能力信息生成密鑰的。實際應用中，只要被叫側(cè)安全應用單元獲得的被叫終端的加密能力信息，在之后的任何是否生成密鑰都可以，并不一定在步驟324中生成。本實施例所述被叫側(cè)將密鑰下發(fā)給被叫側(cè)媒體流承載設備的方法與主叫側(cè)下發(fā)密鑰給主叫側(cè)媒體流承載設備的方法相似，此處不再贅述。另外，本實施例是以安全應用單元為S-CSCF中的功能單元為例敘述，如果是P-CSCF中的功能單元，其方法與本實施例相似，只是在P-CSCF中生成密鑰后，由P-CSCF將密鑰發(fā)送給終端，并直接下發(fā)給媒體流承載設備即可，至于具體流程此處則不再詳細描述。方法實施三本實施例沖，主叫側(cè)將加密業(yè)務作為基本業(yè)務，而被叫側(cè)將加密作為增值業(yè)務，并且被叫終端未簽約該加密業(yè)務，主叫終端所屬域與被叫終端所屬域之間沒有簽署分發(fā)密鑰協(xié)議；本實施例中，安全應用服務器為IMS-AS。圖4是本實施例的消息流示意圖。如圖4所示，本實施例包括以下步驟步驟401~步驟410與實施例二中步驟301~步驟310相似，其區(qū)別在于，當被叫側(cè)IMS-AS接收到呼叫請求消息時，還將查詢事先設置的加密業(yè)務簽約信息，根據(jù)用戶標識判斷出被叫終端沒有簽約加密業(yè)務。由于被叫終端沒有簽約加密業(yè)務，被叫側(cè)將不會為被叫終端生成密鑰。在這種情況下，被叫側(cè)IMS-AS也可以將自身從信令鏈路中刪除，此后的呼叫流程中的消息將不再經(jīng)過被叫側(cè)IMS-AS;或者被叫側(cè)IMS-AS也可以不將自身從信令鏈路中刪除，但只是轉(zhuǎn)發(fā)消息的作用。步驟411-步驟417:被叫終端向主叫終端返回呼叫響應消息，在返回呼叫響應消息過程中，主叫側(cè)安全應用服務器將根據(jù)主叫終端加密能力信息生成的密鑰發(fā)送給主叫終端，并下發(fā)給主叫側(cè)媒體流承載設備。此后主叫終端和被叫終端還需要完成呼叫流程中的其他部分，但被叫側(cè)不會生成密鑰，也不會將密鑰發(fā)送給被叫終端和被叫側(cè)媒體流承載設備，被叫側(cè)部分的呼叫流程可以與現(xiàn)有技術相同。至于主叫側(cè)如何將密鑰下發(fā)給媒體流承載設備與實施例二相同，此處也不再贅述。當呼叫流程結(jié)束后，只有主叫終端和主叫側(cè)媒體流承載設備獲得了密鑰，媒體流在主叫終端和主叫側(cè)媒體流承載設備是加密傳輸?shù)模诒唤袀?cè)是明文傳輸。方法實施例四本實施例中，主叫側(cè)和被叫側(cè)都將加密業(yè)務作為增值業(yè)務，主叫終端沒有簽約加密業(yè)務，而被叫終端簽約了加密業(yè)務；主叫終端所屬域和被叫終端所屬域之間已經(jīng)簽署了密鑰分發(fā)協(xié)議。圖5是本實施例的消息流示意圖。如圖5所示，本實施例包括以下步驟步驟501~步驟503與實施例一中的步驟201~步驟203相同，此處不再詳細描述。步驟504~步驟506:主叫側(cè)IMS-AS查詢事先設置的加密業(yè)務簽約信息，根據(jù)用戶標識判斷出主叫終端沒有簽約，判斷出主叫終端所屬域與被叫終端所屬域已簽署密鑰分發(fā)協(xié)議，再并將呼叫請求消息通過主叫側(cè)S-CSCF發(fā)送給^皮叫側(cè)S-CSCF。與實施例一相似，如果呼叫請求消息中攜帶有安全前提，所屬安全前提中包括端到端加密標識，主叫側(cè)IMS-AS根據(jù)呼叫請求就可以判斷出這是一個要求端到端加密的呼叫請求消息。由于主叫終端沒有簽約業(yè)務，主叫側(cè)將不會為主叫終端生成密鑰，為了將此情況通知給被叫側(cè)，主叫側(cè)IMS-AS可以將#_叫側(cè)生成密鑰標識插入呼叫請求消息。步驟507~步驟510與實施例一中的步驟207~步驟210相似，其區(qū)別在于，當被叫側(cè)IMS-AS接收到呼叫請求消息后，將查詢事先設置的加密業(yè)務簽約信息，根據(jù)用戶標識判斷出被叫終端已經(jīng)簽約。當然，如果呼叫請求消息還包括安全前提等信息，主叫側(cè)IMS-AS還可以根據(jù)呼叫請求消息確定加密方式為端到端加密，并且密鑰由被叫側(cè)安全應用服務器生成。實際應用中，如果被叫側(cè)IMS-AS判斷出被叫終端沒有簽約加密業(yè)務，則可以將自身從鏈路中刪除，并將無密鑰生成標識插入消息中。此后，當主叫側(cè)IMS-AS從呼叫響應消息中獲取無密鑰生成標識，就可以也將自身從信令鏈路中刪除。步驟511~步驟513:被叫終端根據(jù)呼叫請求消息中主叫終端的加密能力信息和自身的加密能力信息，確定生成密鑰的加密能力信息，再向被叫側(cè)IMS-AS返回攜帶有生成密鑰的加密能力信息的呼叫響應消息。步驟514:被叫側(cè)IMS-AS根據(jù)呼叫響應消息中的加密能力信息生成密鑰，并將生成的密鑰攜帶于呼叫響應消息中。步驟515-步驟520與實施例一中步驟214~步驟220相似，其區(qū)別在于，當主叫側(cè)IMS-AS接收到呼叫響應消息時，不會再生成密鑰，而是直接轉(zhuǎn)發(fā)出去即可。步驟521~步驟529與實施例一步驟221~步驟229相似，其區(qū)別在于，當主叫側(cè)IMS-AS接收到呼叫相關消息時，將不會將密鑰攜帶于呼叫相關消息中，而是后續(xù)過程中，由被叫側(cè)將密鑰攜帶于呼叫相關消息中發(fā)送給被叫終端。方法實施例五本實施例中，主叫終端發(fā)起的呼叫請求消息不攜帶加密能力信息，即不要求加密；實際應用中，終端可以為用戶提供"加密，，、"不加密，，、"自動協(xié)商是否加密"等選項，終端根據(jù)用戶的選擇決定是否生成攜帶有加密聲明的呼叫請求消息。本實施例中，被叫側(cè)將加密業(yè)務作為增值業(yè)務，并且被叫終端已經(jīng)簽約該加密業(yè)務；本實施例中，安全應用服務器為S-CSCF中的一個功能單元，并且為了敘迷簡便，在示意圖不單獨表示安全應用服務器。圖6是本實施例的消息流示意圖。如圖6所示，本實施例包括以下步驟步驟601~步驟603:主叫終端將呼叫請求消息發(fā)送給主叫側(cè)S-CSCF,主叫側(cè)S-CSCF直接將呼叫請求消息轉(zhuǎn)發(fā)給被叫側(cè)S-CSCF;步驟604~步驟606:#1叫側(cè)S-CSCF將加密能力信息插入呼叫請求消息，再轉(zhuǎn)發(fā)給被叫終端。步驟607:被叫終端根據(jù)呼叫請求消息中的加密能力信息和自身加密能力信息，確定生成密鑰的加密能力信息，并將確定生成密鑰的加密能力信息添加到呼叫響應消息中。步驟608~步驟609:被叫終端將呼叫請求消息返回給被叫側(cè)S-CSCF，被叫側(cè)S-CSCF中的安全應用單元根據(jù)呼叫響應消息中的加密能力信息生成密鑰。步驟610~步驟612:被叫側(cè)S-CSCF繼續(xù)向主叫終端返回呼叫響應消息。實際應用中，被叫側(cè)S-CSCF還可以將之前插入的加密能力信息刪除，向主叫終端返回的是一條普通的呼叫響應消息。步驟613-步驟主叫終端向被叫終端發(fā)送呼叫相關消息，在發(fā)送的過程中，被叫側(cè)S-CSCF將生成的密鑰攜帶于呼叫相關消息中發(fā)送給被叫終端，并下發(fā)給媒體流承載設備。針對本發(fā)明提出的方法，本發(fā)明還提出一種多媒體子系統(tǒng)。圖7是本發(fā)明所述的系統(tǒng)基本結(jié)構(gòu)示意圖，該系統(tǒng)至少包括主叫終端701、安全應用服務器702、被叫終端703。其中，所述安全應用服務器702用于根據(jù)主叫終端所屬域與被叫終端所屬域的簽約情況確定加密方式，根據(jù)在呼叫過程中獲得的加密能力信息生成密鑰，并將生成的密鑰發(fā)送給終端。另夕卜，本發(fā)明所述的安全應用服務器702可以為IMS-AS,或者為CSCF的功能模塊，或者為第三方服務器。系統(tǒng)實施例一圖8是本發(fā)明系統(tǒng)實施例一的基本結(jié)構(gòu)圖。如圖8所示，由于呼叫過程中同時涉及主叫側(cè)和被叫側(cè)，安全應用服務器702可以為主叫側(cè)安全應用服務器和被叫側(cè)安全應用服務器，本實施例還包括主叫終端701、主叫側(cè)S-CSCF704、被叫側(cè)S-CSCF705、被叫終端703。其中，主叫終端701用于發(fā)起呼叫，并從呼叫流程中獲取從主叫側(cè)安全應用服務器或被叫側(cè)安全應用服務器返回的密鑰；安全應用服務器702生成密鑰并將密鑰發(fā)送給終端；主叫側(cè)S-CSCF704和被叫側(cè)S-CSCF轉(zhuǎn)發(fā)呼叫流程中的消息，并將攜帶有加密能力信息的呼叫請求消息發(fā)送給對應的安全應用服務器。實際應用中，系統(tǒng)中還包括主叫側(cè)P-CSCF706、被叫側(cè)P-CSCF707、主叫側(cè)媒體流承載設備708、被叫側(cè)媒體流承載設備709。其中，主叫側(cè)P-CSCF706用于轉(zhuǎn)發(fā)呼叫消息，并將獲得的密鑰發(fā)送給主叫側(cè)媒體流承載設備708;被叫側(cè)P-CSCF706用于轉(zhuǎn)發(fā)呼叫消息，并將獲得的密鑰發(fā)送給被叫側(cè)媒體流承載設備709。實際應用中，安全應用服務器702可以為S-CSCF中的功能模塊，或者為P-CSCF中的功能模塊，或者為IMS-AS，或者為第三方服務器。當然，圖8僅僅是一個系統(tǒng)基本結(jié)構(gòu)圖，每一個實體的功能與終端獲取密鑰的方式相關，此處不再贅述。本發(fā)明是以含有IMS的網(wǎng)絡，并且在IMS網(wǎng)絡中信令鏈路可以提供安全保障的情況為例進行說明的。實際應用中，還可以將本發(fā)明方法應用于其他類型的網(wǎng)絡中，如基于軟交換的下一代網(wǎng)絡，其方法與本發(fā)明類似，此處不再——列舉。應用本發(fā)明方案，主叫終端和被叫終端自身不生成密鑰，而是由安全應用服務器生成密鑰，無需進行時鐘同步，也無需PKI體系的支持，可以大大降低媒體流密鑰協(xié)商的復雜度，便于媒體流加密業(yè)務的推廣。進一步地，如果采用端到端加密，可以從安全應用服務器中獲取密鑰，從而滿足合法監(jiān)聽的實際需求；如果采用分段加密，由于主叫側(cè)媒體流承載設備和被叫側(cè)媒體流承栽設備之間采用明文傳輸，也可以滿足合法監(jiān)聽的實際需求。綜上所述，以上僅為本發(fā)明的較佳實施例而已，并非用于限定本發(fā)明的保護范圍。凡在本發(fā)明的精神和原則之內(nèi)，所作的任何修改、等同替換、改進等，均應包含在本發(fā)明的保護范圍之內(nèi)。權利要求1.一種分配媒體流密鑰的方法，其特征在于，預先設置生成密鑰的安全應用服務器，當主叫終端發(fā)起呼叫時，該方法包括A、安全應用服務器根據(jù)呼叫請求消息判斷主叫終端所屬域與被叫終端所屬域是否已簽署密鑰分發(fā)協(xié)議，如果已經(jīng)簽署，執(zhí)行步驟B后退出本流程；否則執(zhí)行步驟C；B、安全應用服務器根據(jù)在呼叫過程中獲得的加密能力信息生成密鑰，并將生成的同一個密鑰分配給主叫終端和被叫終端；C、安全應用服務器根據(jù)在呼叫過程中獲得的加密能力信息生成密鑰，并將生成的密鑰分配給自身所在一側(cè)的終端。2、根據(jù)權利要求1所述的方法，其特征在于，步驟B所述安全應用服務器為主叫側(cè)安全應用服務器，所述步驟B具體為bl、被叫終端接收主叫終端的呼叫請求消息，所述呼叫請求消息攜帶有主叫終端的加密能力信息；b2、被叫終端根據(jù)主叫終端的加密能力信息和自身的加密能力信息，確定生成密鑰的加密能力信息，再返回攜帶有生成密鑰的加密能力信息的呼叫響應消息；b3、主叫側(cè)安全應用服務器根據(jù)呼叫響應消息中的加密能力信息生成密鑰，并將生成的密鑰發(fā)送給主叫終端；b4、主叫終端再向被叫終端發(fā)送呼叫相關消息，主叫側(cè)安全應用服務器將生成的密鑰攜帶于所述呼叫相關消息發(fā)送給^皮叫終端。3、根據(jù)權利要求2所述的方法，其特征在于，所述呼叫請求消息中攜帶有端到端加密標識，在步驟bl所述被叫終端接收到呼叫請求消息之前，該方法進一步包括主叫側(cè)安全應用服務器將主叫側(cè)生成密鑰標識攜帶于呼叫請求消息中，被叫側(cè)安全應用服務器才艮據(jù)所述呼叫請求消息確定加密方式為端到端加密，并確定密鑰由主叫側(cè)安全應用服務器生成。4、根據(jù)權利要求1所述的方法，其特征在于，步驟C所述安全應用服務器為主叫側(cè)安全應用服務器和被叫側(cè)安全應用服務器，所述步驟C具體為c1、主叫側(cè)安全應用服務器記錄來自主叫終端呼叫請求消息中的主叫終端加密能力信息；c2、被叫終端在接收到呼叫請求后，返回攜帶有自身加密能力信息的呼叫響應消息，被叫側(cè)安全應用服務器從呼叫響應消息中獲取并記錄被叫終端的加密能力信息；c3、主叫側(cè)安全應用服務器將根據(jù)主叫終端加密能力信息生成的密鑰發(fā)送給主叫終端，并下發(fā)給主叫側(cè)媒體流承栽設備；c4、被叫側(cè)安全應用服務器將根據(jù)被叫終端加密能力信息生成的密鑰發(fā)送給被叫終端，并將生成的密鑰下發(fā)給被叫側(cè)媒體流承載設備。5、根據(jù)權利要求4所述的方法，其特征在于，所述媒體流承載設備為媒體代理MP,步驟c3所述主叫側(cè)安全應用服務器將生成的密鑰下發(fā)給主叫側(cè)MP的方法為主叫側(cè)安全應用服務器將生成的密鑰通過主叫側(cè)呼叫會話控制功能實體CSCF發(fā)送給主叫側(cè)MP;步驟c4所述被叫側(cè)安全應用服務器將密鑰下發(fā)給被叫側(cè)MP的方法為被叫側(cè)安全應用服務器將生成的密鑰通過被叫側(cè)CSCF將密鑰發(fā)送給被叫側(cè)MP。6、根據(jù)權利要求4所述的方法，其特征在于，所述被叫終端接收到呼叫請求之前，該方法進一步包括被叫側(cè)安全應用服務器查詢事先設置的加密業(yè)務簽約信息，根據(jù)用戶標識判斷出被叫終端是否已經(jīng)簽約，如果已經(jīng)簽約，則繼續(xù)執(zhí)行；否則，執(zhí)行步驟X;所述步驟X具體為在凈皮叫終端返回呼叫響應消息過程中，主叫側(cè)安全應用服務器將根據(jù)主叫終端加密能力信息生成的密鑰發(fā)送給主叫終端，并下發(fā)給主叫側(cè)媒體流承載設備。7、根據(jù)權利要求4所述的方法，其特征在于，所述呼叫請求消息攜帶有端到端加密標識，步驟cl進一步包括主叫側(cè)安全應用服務器將端到端加密標識更改為分段加密標識；步驟c2所述被叫終端接收呼叫請求之前，該方法進一步包括被叫側(cè)安全應用服務器才艮據(jù)呼叫請求消息確定加密方式為分段加密。8、根據(jù)權利要求7所述的方法，其特征在于，所述呼叫響應消息攜帶有分段加密標識，所述步驟c3進一步包括主叫側(cè)安全應用服務器將分段加密標識恢復為端到端加密標識。9、根據(jù)權利要求1所述的方法，其特征在于，所述步驟A進一步包括主叫側(cè)安全應用服務器查詢事先設置的加密業(yè)務簽約信息，根據(jù)用戶標識判斷主叫終端是否已經(jīng)簽約，如果已經(jīng)簽約，則繼續(xù)執(zhí)行；否則，執(zhí)行步驟Y;所述步驟Y為yl、被叫終端接收來自主叫終端的呼叫請求消息，所述呼叫請求消息攜帶有主叫終端的加密能力信息；y2、被叫終端根據(jù)主叫終端的加密能力信息和自身的加密能力信息，確定生成密鑰的加密能力信息，返回攜帶有生成密鑰的加密能力信息的呼叫響應消息；y3、被叫側(cè)安全應用服務器根據(jù)呼叫響應消息中的加密能力信息生成密鑰，并將生成的密鑰發(fā)送給主叫終端；y4、主叫終端再向被叫終端返回呼叫相關消息，被叫側(cè)安全應用服務器通過所迷呼叫相關消息將生成的密鑰發(fā)送給被叫終端。10、根據(jù)權利要求9所述的方法，其特征在于，步驟yl所述被叫終端接收到呼叫響應消息之前，該方法進一步包括主叫側(cè)安全應用服務器根據(jù)呼叫請求消息判斷出主叫終端所屬域與被叫終端所屬域已簽署密鑰分發(fā)協(xié)議。11、根據(jù)權利要求9所述的方法，其特征在于，所述呼叫請求消息攜帶有端到端加密標識，步驟yl所述被叫終端接收到呼叫請求消息之前，該方法進一步包括主叫側(cè)安全應用服務器將被叫側(cè)生成密鑰標識攜帶于呼叫請求消息中，被叫側(cè)安全應用Jil務器根據(jù)呼叫請求消息確定加密方式為端到端加密，并且密鑰由#皮叫側(cè)安全應用服務器生成。12、根據(jù)權利要求9所述的方法，其特征在于，步驟yl所述被叫終端接收到呼叫請求消息之前，該方法進一步包括被叫側(cè)安全應用服務器查詢事先設置的加密業(yè)務簽約信息，根據(jù)用戶標識判斷出被叫終端已經(jīng)簽約。13、根據(jù)權利要求9所述的方法，其特征在于，所述主叫側(cè)安全應用服務器查詢加密業(yè)務簽約信息之前，該方法進一步包括主叫側(cè)安全應用服務器判斷呼叫請求消息是否包含加密能力信息，如杲有，則繼續(xù)執(zhí)行；否則，執(zhí)行步驟Z;所述步驟Z為zl、被叫終端接收到呼叫請求消息后，返回攜帶有加密能力信息的呼叫響應消息；z2、被叫側(cè)安全應用服務器從呼叫響應消息中獲得并記錄被叫終端的加密能力信息；z3、當主叫終端接收到呼叫響應消息后，再向被叫終端發(fā)送呼叫相關消息，在發(fā)送的過程中，被叫側(cè)安全應用服務器將根據(jù)加密能力信息生成的密鑰通過呼叫相關消息發(fā)送給被叫終端，并下發(fā)給被叫側(cè)媒體流承載設備。14、根據(jù)權利要求13所述的方法，其特征在于，步驟zl所述被叫終端接收到呼叫請求消息之前，該方法進一步包括被叫側(cè)安全應用服務器將加密能力信息插入呼叫請求消息；步驟zl所述被叫終端返回呼叫響應消息之前，該方法進一步包括被叫終端根據(jù)呼叫請求消息中的加密能力信息和自身加密能力信息，確定生成密鑰的加密能力信息，并將確定生成密鑰的加密能力信息添加到呼叫響應消息中。15、根據(jù)權利要求13所述的方法，其特征在于，步驟zl被叫終端接收到呼叫請求消息之前，該方法進一步包括被叫側(cè)安全應用服務器查詢事先設置的加密業(yè)務簽約信息，根據(jù)用戶標識判斷出被叫終端已經(jīng)簽約。16、根據(jù)權利要求1所述的方法，其特征在于，所述呼叫流程中主叫終端和被叫終端之間交互的消息包括獲取密鑰狀態(tài)標識，該方法進一步包括如果主叫終端/被叫終端沒有獲取密鑰，則將發(fā)送給被叫終端/主叫終端消息中的獲取密鑰狀態(tài)標識設置為未獲取密鑰標識；否則，設置為已獲取密鑰標識。17、一種多々某體子系統(tǒng)，至少包括主叫終端和凈皮叫終端，其特征在于，該系纟充還包4舌安全應用服務器，用于根據(jù)主叫終端所屬域與被叫終端所屬域的簽約情況確定加密方式，才艮據(jù)在呼叫過程中獲得的加密能力信息生成密鑰，并將生成的密鑰發(fā)送給終端。18、根據(jù)權利要求17所述的系統(tǒng)，其特征在于，所述安全應用服務器為多媒體子系統(tǒng)應用服務器IMS-AS，或者為呼叫會話控制功能實體CSCF的功能模塊，或者為第三方服務器。全文摘要本發(fā)明提供一種分配媒體流密鑰的方法和多媒體子系統(tǒng)，具體為預先設置生成密鑰的安全應用服務器，當主叫終端發(fā)起呼叫時，安全應用服務器根據(jù)呼叫請求消息判斷主叫終端所屬域與被叫終端所屬域是否已簽署密鑰分發(fā)協(xié)議，如果已經(jīng)簽署，安全應用服務器根據(jù)在呼叫過程中獲得的加密能力信息生成密鑰，并將生成的同一個密鑰分配給主叫終端和被叫終端；如果沒有簽署，安全應用服務器根據(jù)在呼叫過程中獲得的加密能力信息生成密鑰，并將生成的密鑰分配給自身所在一側(cè)的終端。應用本發(fā)明方案，主叫終端和被叫終端自身并不生成密鑰，而是由安全應用服務器生成密鑰，可以大大降低端到端媒體流密鑰協(xié)商的復雜度，便于媒體流加密業(yè)務的推廣。文檔編號H04L9/08GK101232368SQ20071000271公開日2008年7月30日申請日期2007年1月23日優(yōu)先權日2007年1月23日發(fā)明者濤孔,愷孫,高江海,靜黎申請人:華為技術有限公司