GB35114—⑤、附 录C
生活随笔
收集整理的這篇文章主要介紹了
GB35114—⑤、附 录C
小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.
附 錄 C （規(guī)范性附錄） 流程和協(xié)議
C.１ 用戶身份認證
B/S客戶端基于數(shù)字證書的用戶身份認證流程應按照GB/T15843.3-2008執(zhí)行。C/S客戶端應采用基于SIP協(xié)議的雙向身份認證模式進行用戶身份認證。具體流程參照C2.2.2內(nèi)容。
C.２ 設備接入認證
C.2.1 SIP服務器認證FDWSF的單向身份認證
C.2.1.1 單向身份認證說明
FDWSF和SIP服務器進行單向認證。對RFC3261 中定義的方法REGISTER進行如下頭域
擴展：
- a) Authorization的值增加Capability項用來描述FDWSF 的安全能力。當Authorization 的值為Capability時，攜帶參數(shù)algorithm、keyversion。參數(shù)algorithm的值分為四部分，中間以分號分割。第一部分定義為“Ａ”，為非對稱算法描述，取值為設備支持的非對稱算法／模式／填充方式，多種算法之間用逗號分隔。例如：A:SM2；第二部分定義為“Ｈ”，為雜湊算法描述，取值為設備支持的雜湊算法，多種算法之間用逗號分隔。例如：H:SM3；第三部分定義為“Ｓ”，為對稱算法的描述，取值為設備支持的對稱算法／模式／填充方式，多種算法之間用逗號分隔。例如：S:SM1/OFB/PKCS5, SM1/ECB/PKCS5。第四部分定義為“SI”，為簽名算法的描述。例如：SI:SM3-SM2。keyversion為密鑰版本號，取值為FDWSF 的本地時間，16位數(shù)字字符，例如：keyversion＝＂1970-01-01T9:18:43＂。
- b) ＷＷＷ-Authenticate的值為Unidirection。攜帶參數(shù)random1、algorithm。random1 取值為隨機數(shù)。algorithm 的值為SIP服務器使用的安全算法，該算法由SIＰ服務器從設備上報的安能力算法中選擇獲得，包括非對稱算法、雜湊算法、對稱算法，用分號分隔。例如：A:SM2；H:SM3；S:SM1/OFB/PKCS5；SI:SM3-SM2。
- c) Authorization 的值為Unidirection，攜帶驗證具有安全功能的前端設備的數(shù)據(jù)。攜帶random1、random2、serverid、sign1、algorithm。random2 為具有安全功能的前端設備產(chǎn)生的隨機數(shù)，random1為SIP服務器產(chǎn)生的隨機數(shù)，serverid為SIP服務器設備ID，sign1為用具有安全功能的前端設備私鑰對random2＋random1＋SIP服務器ID做數(shù)字簽名后的結果，algorithm為采用的安全算法。
C.2.1.2 單向身份認證流程
單向身份認證流程見圖C.1，消息示范參見D.1。
圖C.1 SIP服務器認證FDWSF的單向身份認證注冊流程示意圖信令流程描述如下:
- a) 1:FDWSF向SIP服務器發(fā)送REGISTER請求。增加Authorization頭字段，Authorization的值為Capability，攜帶參數(shù)algorithm、keyversion。參數(shù)algorithm的值分為四部分，中間以分號分割。第一部分定義為“A”，為非對稱算法描述，取值為設備支持的非對稱算法/模式/填充方式，多種算法之間用逗號分隔。例如:A:SM2；第二部分定義為“H”，為雜湊算法描述，取值為設備支持的雜湊算法，多種算法之間用逗號分隔。例如:H:SM3；第三部分定義為“SM3”，為對稱算法的描述，取值為設備支持的對稱算法/模式/填充方式，多種算法之間用逗號分隔。例如:S:SM1/OFB/PKCS5，SM1/CBC/PKCS5，SM4/OFB/PKCS5，SM4/CBC/PKCS5。第四部分定義為“SI”，為簽名算法的描述。例如:SI:SM3-SM2。keyversion為密鑰版本號。
- b) 2:SIP 服務器產(chǎn)生隨機數(shù)R1，向FDWSF發(fā)送一個挑戰(zhàn)響應401，響應的消息頭域WWW-Authenticate取值為為UnIDirection，用來攜帶驗證SIP 服務器身份的數(shù)據(jù)。攜帶參數(shù)random1、algorithm。random1取值為R1。algorithm 的值為SIP 服務器使用的安全算法。
- c) 3:FDWSF收到401 響應后，得到random1和algorithm 的值。產(chǎn)生隨機數(shù)Ｒ2；用FDWSF私鑰對random2+ random1+SIP 服務器ID 做數(shù)字簽名，得到結果sign1。FDWSF 重新向SIP服務器發(fā)送REGISTER 請求，Authorization 取值為UnIDirection，攜帶random1、random2、serverid、sign1、algorithm。random2為FDWSF產(chǎn)生的隨機數(shù)Ｒ2，random1為SIP 服務器產(chǎn)生的隨機數(shù)R1，serverid 為SIP 服務器設備ID，sign1 為用FDWSF 私鑰對random2+random1+SIP 服務器ID 做數(shù)字簽名后的結果，algorithm 為采用的安全算法。
- d) 4:SIP 服務器收到請求后，校驗FDWSF簽名的有效性(是否被驗證過)；校驗R1有效性(只能1次+時效性)；校驗SIP 服務器ID 與自身是否相符；用設備證書校驗sign1簽名結果；校驗成功，證明FDWSF身份合法。用FDWSF公鑰對VKEK 加密做Base64編碼后得到cryptkey，向FDWSF發(fā)送成功響應200 OK消息，攜帶cryptkey參數(shù)、algorithm 參數(shù)。如果校驗失敗則發(fā)送拒絕服務應答。FDWSF 收到200 OK后用FDWSF 私鑰解密cryptkey，即可獲得VKEK 的值。
C.2.2 SIP服務器與FDWSF間的雙向身份認證
C.2.2.1 雙向身份認證說明
FDWSF和SIP 服務器進行雙向認證。對RFC3261 中定義的方法REGISTER 進行如下頭域擴展:
- a) Authorization 的值增加Capability 項用來描述FDWSF 的安全能力。當Authorization 的值為Capability時，攜帶參數(shù)algorithm、keyversion。參數(shù)algorithm 的值分為四部分，中間以分號分割。第一部分定義為“A”，為非對稱算法描述，取值為設備支持的非對稱算法/模式/填充方式，多種算法之間用逗號分隔。例如:A:SM2；第二部分定義為“H”，為雜湊算法描述，取值為設備支持的雜湊算法，多種算法之間用逗號分隔。例如:H:SM3；第三部分定義為“SM3”，為對稱算法的描述，取值為設備支持的對稱算法/模式/填充方式，多種算法之間用逗號分隔。例如:S:SM1/OFB/PKCS5，SM1/ＥＣＢ/ＰＫＣSM35。第四部分定義為“SI”，為簽名算法的描述。例如:SI:SM3-SM2。keyversion為密鑰版本號，取值為FDWSF 的本地時間，16位數(shù)字字符，例如:keyversion＝"1970-01-01T9:18:43"。
- b) WWW-Authenticate的值為BIDirection。攜帶參數(shù)random1、algorithm。random1取值為隨機數(shù)。algorithm 的值為SIP 服務器使用的安全算法，該算法由SIP服務器從設備上報的安全能力算法中選擇獲得，包括非對稱算法、雜湊算法、對稱算法，用分號分隔。例如:A:SM2；H:SM3；S:SM1/OFB/PKCS5；SI:SM3-SM2。
- c) Authorization 的值為BIDirection。攜帶驗證FDWSF 的數(shù)據(jù)。攜帶random1、random2、serverid、sign1、algorithm。random2為FDWSF 產(chǎn)生的隨機數(shù)，random1 為SIP 服務器產(chǎn)生的隨機數(shù)，serverid為SIP 服務器設備ID，sign1為用FDWSF 私鑰對random2+ random1+SIP 服務器ID 做數(shù)字簽名后的結果，algorithm 為采用的安全算法。
C.2.2.2 雙向身份認證流程
雙向身份認證流程見圖C.2，消息示范參見D.2。
圖C.2 SIP服務器與FDWSF間雙向認證注冊流程示意圖信令流程描述如下:
- a) 1:FDWSF向SIP服務器發(fā)送REGISTER請求，消息頭域中攜帶FDWSF 的安全能力。增加Authorization頭字段，Authorization的值為Capability，攜帶參數(shù)algorithm、keyversion。參數(shù)algorithm 的值分為四部分，中間以分號分割。第一部分定義為“A”，為非對稱算法描述，取值為設備支持的非對稱算法/模式/填充方式，多種算法之間用逗號分隔。例如:A:SM2；第二部分定義為“H”，為雜湊算法描述，取值為設備支持的雜湊算法，多種算法之間用逗號分隔。例如:H:SM3；第三部分定義為“SM3”，為對稱算法的描述，取值為設備支持的對稱算法/模式/填充方式，多種算法之間用逗號分隔。例如:S:SM1/OFB/PKCS5，SM1/ECB/PKCS5。第四部分定義為“SI”，為簽名算法的描述。例如:SI:SM3-SM2。keyversion為密鑰版本號。
- b) 2:SIP 服務器產(chǎn)生隨機數(shù)R1，向FDWSF發(fā)送一個挑戰(zhàn)響應401，響應的消息頭域WWW-Authenticate取值為為BIDirection，用來攜帶驗證SIP 服務器身份的數(shù)據(jù)。攜帶參數(shù)random1、algorithm。random1取值為R1。algorithm 的值為SIP 服務器使用的安全算法。
- c) 3:FDWSF收到401 響應后，得到random1和algorithm 的值。產(chǎn)生隨機數(shù)R2；用FDWSF私鑰對random2+ random1+SIP 服務器ID做數(shù)字簽名，得到結果sign1。FDWSF 重新向SIP服務器發(fā)送REGISTER請求，Authorization取值為Bidirection，攜帶random1、random2、serverid、sign1、algorithm。random2為FDWSF產(chǎn)生的隨機數(shù)R2，random1為SIP 服務器產(chǎn)生的隨機數(shù)R1，serverid為SIP 服務器設備ID，sign1 為用FDWSF 私鑰對random2+random1+SIP 服務器ID做數(shù)字簽名后的結果algorithm 為采用的安全算法。
- d) 4:SIP 服務器收到請求后，校驗FDWSF簽名的有效性(是否被驗證過)；校驗R1有效性(只能1次+時效性)；校驗SIP 服務器ID與自身是否相符；用設備證書校驗sign1簽名結果；校驗成功，證明FDWSF 身份合法。用FDWSF 公鑰對VKEK 加密得到cryptkey，用管理平臺私鑰對random1+random2+DeviceID+cryptkey做數(shù)字簽名，得到結果sign2。向FDWSF發(fā)送成功響應200 OK消息，攜帶random2、random1、DeviceID、sign2、algorithm。cryptkey 參數(shù)。random2為FDWSF產(chǎn)生的隨機數(shù)R2，random1為SIP 服務器產(chǎn)生的隨機數(shù)R1，DeviceID為FDWSF的ID，cryptkey為FDWSF 公鑰對VKEK 加密結果經(jīng)Base64 編碼后的值，sign2 為用管理平臺私鑰對random1+random2+DeviceID+cryptkey做數(shù)字簽名后的結果，algorithm為采用的安全算法。FDWSF 收到200 OK后，校驗SIP 服務器簽名的有效性(是否被驗證過)；校驗R2有效性(只能1次+時效性)；校驗DeviceID與自身是否相符；用SIP 服務器證書校驗sign2簽名結果；校驗成功，證明SIP 服務器身份合法。用FDWSF私鑰解密cryptkey，即可獲得VKEK 的值。如果校驗失敗則發(fā)送拒絕服務應答。
C.3 管理平臺間認證
C.3.1 管理平臺間認證說明
管理平臺間認證分為互聯(lián)認證和級聯(lián)認證，下面以信令安全路由網(wǎng)關1向信令安全路由網(wǎng)關2發(fā)起認證為例進行說明。
C.3.2 管理平臺間認證流程
管理平臺間認證流程見圖C.3，消息示范參見D.2。
圖C.3 管理平臺間雙向認證注冊流程示意圖信令流程描述如下:
- a) 1:信令安全路由網(wǎng)關1向信令安全路由網(wǎng)關2發(fā)送REGISTER請求，消息頭域中攜帶信令安全路由網(wǎng)關1的安全能力。增加Authorization頭字段，Authorization的值為Capability，攜帶參數(shù)algorithm、keyversion。參數(shù)algorithm 的值分為四部分，中間以分號分割。第一部分定義為“A”，為非對稱算法描述，取值為設備支持的非對稱算法/模式/填充方式，多種算法之間用逗號分隔。例如:A:SM2；第二部分定義為“H”，為雜湊算法描述，取值為設備支持的雜湊算法，多種算法之間用逗號分隔。例如:H:SM3；第三部分定義為“SM3”，為對稱算法的描述，取值為設備支持的對稱算法/模式/填充方式，多種算法之間用逗號分隔。例如:S:SM1/OFB/PKCS5，SM1/ECB/PKCS5。第四部分定義為“SI”，為簽名算法的描述。例如:SI:SM3-SM2。keyversion為密鑰版本號。
- b) 2:信令安全路由網(wǎng)關2產(chǎn)生隨機數(shù)R1，向信令安全路由網(wǎng)關1發(fā)送一個挑戰(zhàn)響應401，響應的消息頭域WWW-Authenticate取值為為BIDirection，用來攜帶驗證信令安全路由網(wǎng)關1身份的數(shù)據(jù)。攜帶參數(shù)random1、algorithm。random1取值為R1。algorithm 的值為信令安全路由網(wǎng)關2使用的安全算法。
- c) 3:信令安全路由網(wǎng)關1收到401響應后，得到random1和algorithm的值。產(chǎn)生隨機數(shù)R2；用信令安全路由網(wǎng)關1私鑰對random2+random1+信令安全路由網(wǎng)關2ID做數(shù)字簽名，得到結果sign1。信令安全路由網(wǎng)關1重新向信令安全路由網(wǎng)關2發(fā)送REGISTER請求，Authorization取值為BIDirection，攜帶random1、random2、serverid、sign1、algorithm。random2為信令安全路由網(wǎng)關1產(chǎn)生的隨機數(shù)R2，random1為信令安全路由網(wǎng)關2產(chǎn)生的隨機數(shù)R1，serverid為信令安全路由網(wǎng)關2 設備ID，sign1 為用信令安全路由網(wǎng)關1 私鑰對random2+random1+信令安全路由網(wǎng)關2ID做數(shù)字簽名后的結果，algorithm 為采用的安全算法。
- d) 4:信令安全路由網(wǎng)關22收到請求后，校驗信令安全路由網(wǎng)關21簽名的有效性(是否被驗證過)；校驗R1有效性(只能1次+時效性)；校驗信令安全路由網(wǎng)關2ID與自身是否相符；用信令安全路由網(wǎng)關1證書校驗sign1簽名結果；校驗成功，證明信令安全路由網(wǎng)關1身份合法。用信令安全路由網(wǎng)關1公鑰對VKEK加密得到cryptkey1，用信令安全路由網(wǎng)關1公鑰對VEMK及VEMK版本號加密得到cryptkey2，用信令安全路由網(wǎng)關2私鑰對random1+ random2+信令安全路由網(wǎng)關1ID+cryptkey1+cryptkey2做數(shù)字簽名，得到結果sign2。向信令安全路由網(wǎng)關1發(fā)送成功響應200OK消息，攜帶random2、random1、DeviceID、sign2、algorithm。cryptkey1、cryptkey2參數(shù)。random2為信令安全路由網(wǎng)關1產(chǎn)生的隨機數(shù)R2，random1為信令安全路由網(wǎng)關2產(chǎn)生的隨機數(shù)R1，DeviceID為信令安全路由網(wǎng)關1ID，cryptkey1為信令安全路由網(wǎng)關1公鑰對VKEK加密結果經(jīng)Base64編碼后的值，cryptkey2為用信令安全路由網(wǎng)關1公鑰對VEMK及VEMK版本號加密結果經(jīng)Base64編碼后的值，sign2為用信令安全路由網(wǎng)關2私鑰對random1+random2+信令安全路由網(wǎng)關1ID+cryptkey1+cryptkey2做數(shù)字簽名后的結果，algorithm 為采用的安全算法。如果校驗失敗則發(fā)送拒絕服務應答。信令安全路由網(wǎng)關1收到200 OK后用信令安全路由網(wǎng)關1私鑰解密cryptkey1，即可獲得VKEK的值，解密cryptkey2，即可獲得VEMK 的值。
C.4 控制信令認證
C.4.1 控制信令認證說明
注冊成功后，信令發(fā)送方與信令接收方進行交互時，采用基于帶密鑰的雜湊方式保障信令來源安全。對除REGISTER消息以外的消息做帶密鑰的雜湊。啟用Date字段，擴展信令消息頭域，在頭域中增加Note 字段(值為Digest，有兩個參數(shù)nonce，algorithm)。Note＝ (Digest nonce＝""，algorithm＝)，nonce的值為algorithm［METHOD+From+to+Call-ID+Date+VKEK+消息體］雜湊是經(jīng)過Base64編碼后的值，algorithm 的值為雜湊的算法名稱，“+”為字符串連接運算。Date比對有效時間范圍可設，初設值為10 min，應在校時精度范圍內(nèi)。Date精確到秒。
C.4.2 控制信令認證流程
基于帶密鑰的雜湊運算的信令認證會話的流程見圖C.4，消息示范參見D.3。
圖C.4 基于帶密鑰的雜湊運算的控制信令認證交互流程示意圖信令流程描述如下:
- a) 1:信令發(fā)送方發(fā)送信令前，需要對信令消息頭域中的METHOD、From、To、Call-ID、Date、密鑰和消息體做雜湊運算，得到結果1，并將結果1作為Note字段的參數(shù)nonce的值，本次使用的雜湊算法作為Note字段的參數(shù)algorithm 的值。
- b) 2:信令發(fā)送方將信令發(fā)至信令接收方。
- c) 3:信令接收方接收信令，比對Date 與當前時間，如果時間之差在有效區(qū)間內(nèi)則提取METHOD、From、To、Call-ID，Date、消息體、結果1、雜湊算法，使用雜湊算法對METHOD、From、To、Call-ID，Date、密鑰和消息體做雜湊運算，得到結果1′，匹配結果1和結果1′。如果匹配成功，則信令認證通過，否則認證失敗，丟棄該信令并終止該信令會話過程。
- d) 4:若信令接收方對收到的信令認證通過，則生成響應信令，并將即將發(fā)出的信令消息中的METHOD、From、To、Call-ID，Date、密鑰、消息體做雜湊運算，得到結果2。
- e) 5:得到結果2作為Note字段的參數(shù)nonce的值，本次使用的雜湊算法作為Note字段的參數(shù)algorithm 的值，將響應信令發(fā)送給信令發(fā)送方。
- f) 6:信令發(fā)送方接收到響應信令，提取METHOD、From、To、Call-ID，Date、消息體、結果2，比對Date與當前時間，如果時間之在差在有效區(qū)間內(nèi)，則將這些參數(shù)和密鑰一起做雜湊運算，得到結果2′，匹配結果2和2′，如果匹配成功，則信令認證通過，否則失敗，丟棄該信令。
C.5 視頻源簽名及完整性校驗
C.5.1 視頻數(shù)據(jù)簽名數(shù)據(jù)的封裝格式
C.5.1.1 總則
視頻編碼、簽名數(shù)據(jù)的封裝符合GB/T25724-2017要求。
C.5.1.2 NAL單元語法
按照GB/T25724-2017的規(guī)定，使用NAL 單元參數(shù)中的authentication_idc標注其是否認證。NAL 單元語法符合標準GB/T25724-2017中5.2.3.1的要求。
C.5.1.3 安全參數(shù)集RBSP語法
碼流簽名采用的算法由NAL 單元安全參數(shù)集RBSP 約定。安全參數(shù)集RBSP 語法的格式符合標準GB/T25724-2017中5.2.3.2.3的要求。安全參數(shù)集語義應符合標準GB/T25724-2017中5.2.4.4.3的要求。其中簽名中所采用的雜湊算法依據(jù)表C.1。
表C.1 hash_type與算法的對應關系| 0 | SM3 | 32 |
| 1…3 | 保留 | 保留 |
簽名中所采用的非對稱算法依據(jù)Signature＿type，其取值依據(jù)表C.2。
表C.2 Signature＿type與算法的對應關系| 0 | SM2 |
| 1…3 | 保留 |
C.5.1.4 認證數(shù)據(jù)的封裝
認證數(shù)據(jù)的封裝語法符合GB/T25724-2017中5.2.3.2.6的要求。簽名數(shù)據(jù)應經(jīng)過Base64編碼，Base64編碼方法應符合RFC3548的要求。
C.5.2 視頻數(shù)據(jù)簽名規(guī)則
視頻數(shù)據(jù)簽名規(guī)則如下:
- a) 應保證解碼器或驗簽服務器在收到攜帶認證數(shù)據(jù)的NAL 之前，已收到攜帶設備信息的安全參數(shù)集NAL。
- b) 攜帶設備信息的安全參數(shù)集NAL，以GOP整數(shù)倍為周期輸出。
- c) 認證數(shù)據(jù)單元NAL 中的frame_num，表示應包含認證數(shù)據(jù)的圖像，該圖像為在認證數(shù)據(jù)NAL 單元之前最臨近的frame_num 與認證數(shù)據(jù)的frame_num 相同的圖像。successIVe_hash_pictures_minus1等于0時，frame_num 指示認證數(shù)據(jù)對應的圖像。successIVe_hash_pictures_minus1大于0時，frame_num 指示連續(xù)SuccessIVeHashPictures個圖像的最后一個。
- d) 攜帶視頻認證數(shù)據(jù)的認證數(shù)據(jù)NAL，從首個對應圖像算起，最多延后一個GOP周期輸出?？尚乓曨l驗簽時，從攜帶視頻認證數(shù)據(jù)的認證數(shù)據(jù)單元NAL 開始，最多向前搜索一個GOP，定位首個對應圖像。
- e) 編碼比特流中必須攜帶絕對時間擴展信息，用于標識認證時間。
- f) 認證數(shù)據(jù)應經(jīng)過Base64編碼。
C.5.3 前端設備視頻數(shù)據(jù)簽名控制
C.5.3.1 前端設備視頻數(shù)據(jù)簽名控制基本要求
管理平臺發(fā)送命令控制FDWSF啟動、停止視頻數(shù)據(jù)簽名。
C.5.3.2 流程
前端設備視頻數(shù)據(jù)簽名控制流程見圖C.5，消息示范參見D.4。
圖C.5 前端設備視頻數(shù)據(jù)簽名控制流程示意圖命令流程描述如下:
- a) 1:源設備向SIP服務器發(fā)送設備控制命令，設備控制命令采用MESSAGE 方法攜帶；
- b) 2:SIP服務器收到命令后返回200 OK，該響應無消息體；
- c) 3:SIP服務器向目標設備發(fā)送設備控制命令，設備控制命令采用MESSAGE 方法攜帶；
- d) 4:目標設備收到命令后返回200 OK，該響應無消息體；
- e) 5:目標設備向SIP 服務器發(fā)送設備控制響應命令，設備控制響應命令采用MESSAGE 方法攜帶；
- f) 6:SIP服務器收到命令后返回200 OK，該響應無消息體；
- g) 7:SIP服務器向源設備轉發(fā)設備控制響應命令，設備控制響應命令采用MESSAGE 方法攜帶；
- h) 8:源設備收到命令后返回200 OK，該響應無消息體。
C.5.3.3 協(xié)議接口
C.5.3.3.1 請求命令消息體
請求命令消息體應符合下列要求:
- a) MESSAGE 消息頭Content type頭域為Content type:Application/MANSCAP + xml。
- b) 設備控制命令應采用GB/T28181-2016中4.3.4中規(guī)定的MANSCAP協(xié)議格式定義。前端設備視頻數(shù)據(jù)簽名控制命令包括命令類型(CmdType)、命令序列號(SN)、設備編碼(DeviceID)、子命令等，采用MESSAGE 方法的消息體攜帶。
- c) 設備在收到MESSAGE 消息后，應立即返回應答，應答均無消息體。
- d) 消息體定義如下:
C.5.3.3.2 應答命令消息體
應答命令消息體應符合下列要求:
- a) 設備控制應答命令應包括命令類型(CmdType)、命令序列號(SN)、設備編碼(DeviceID)、執(zhí)行結果(Result)，采用MESSAGE 方法的消息體攜帶。
- b) 設備控制應答命令應采用GB/T28181-2016中4.3.4中規(guī)定的MANSCAP協(xié)議格式定義。
- c) MESSAGE 消息頭Content type頭域為Content type:Application/MANSCAP + xml。
- d) 設備在收到MESSAGE 消息后，應立即返回應答，應答均無消息體。
- e) 消息體定義如下:
C.5.4 視頻數(shù)據(jù)簽名
視頻數(shù)據(jù)簽名應符合下列要求:
- a) 讀取待認證的一個或多個NAL 單元數(shù)據(jù)；
- b) 按安全參數(shù)集約定的算法和方式對NAL 單元進行雜湊計算，生成初次或二次雜湊值；
- c) 按安全參數(shù)集Signature＿type約定的算法和方式用設備私鑰對一或多個圖像的樹頂雜湊結果進行簽名計算，生成視頻認證數(shù)據(jù)；
- d) 將視頻認證數(shù)據(jù)封裝到認證數(shù)據(jù)單元中，以獨立的NAL 形式封裝。
C.5.5 視頻驗簽
視頻數(shù)據(jù)驗簽應符合下列要求:
- a) 從安全參數(shù)集NAL 中獲取源端設備信息，找到對應源端設備的公鑰；
- b) 用Signature＿type中指定的簽名算法，用源端設備公鑰解密認證數(shù)據(jù)，生成驗證雜湊值；
- c) 在視頻碼流中定位認證數(shù)據(jù)對應圖像的首個認證NAL 單元；
- d) 按安全參數(shù)集約定的算法和方式對從首個認證NAL 單元開始的一或多組認證NAL 單元進行初次雜湊計算或樹頂雜湊計算，計算結果作為比對雜湊值；
- e) 比較驗證雜湊值和比對雜湊值，如完全相同，則視頻認證數(shù)據(jù)對應的圖像通過驗證，否則未通過驗證。
C.6 視頻加密
C.6.1 視頻加密數(shù)據(jù)的封裝格式
C.6.1.1 安全參數(shù)集RBSP語法
安全參數(shù)集RBSP語法應符合下列要求:
- a) 碼流的加密算法由NAL 單元安全參數(shù)集RBSP 約定。安全參數(shù)集RBSP 語法應符合標準GB/T25724-2017中5.2.3.2.3的要求。安全參數(shù)集語義應符合標準GB/T25724-2017中5.2.4.4.3的要求。
- b) 加密所采用的算法依據(jù)entryption_type，entryption_type見表C.3。
| 0 | SM1 |
| 1 | SM4 |
| 2…15 | 保留 |
C.6.1.2 NAL單元語法
按照GB/T25724-2017的規(guī)定，使用NAL 單元參數(shù)中的entryption_idc標注其攜帶的RBSP 是否加密。
C.6.2 視頻加密規(guī)則
視頻加密規(guī)則如下:
- a) 不對安全參數(shù)集加密處理，解碼端收到新密鑰和參數(shù)后及時激活，取代當前密鑰和參數(shù)；
- b) VEK 的長度為16個字節(jié)，由FDWSF 隨機生成，VEK 更新的最小周期為一個GOP，一般采用30或60個GOP周期；
- c) 攜帶更新VEK、IV 的安全參數(shù)集NAL，應先于新密鑰激活后的加密VCL NAL 的傳輸；攜帶設備信息的安全參數(shù)集NAL，應先于或同時攜帶認證數(shù)據(jù)傳輸；
- d) 新的VEK 在下一個GOP開始時使用，同一個GOP 使用相同的VEK，GOP 周期內(nèi)不變更加密運算的VEK；
- e) 編碼片RBSP的最后1個字節(jié)不加密；
- f) 采用分組加密OFB模式加密時，每個加密GOP使用不同的IV，IV 由編碼器隨機生成。
C.6.3 前端視頻加密控制
C.6.3.1 前端視頻加密控制基本要求
管理平臺發(fā)送命令控制FDWSF啟動、停止視頻數(shù)據(jù)加密。
C.6.3.2 流程
前端視頻加密控制流程見圖C.6，消息示范參見D.5。
圖C.6 前端視頻加密控制流程示意圖命令流程描述如下:
- a) 1:源設備向SIP服務器發(fā)送設備控制命令，設備控制命令采用MESSAGE 方法攜帶；
- b) 2:SIP服務器收到命令后返回200 OK，該響應無消息體；
- c) 3:SIP服務器向目標設備發(fā)送設備控制命令，設備控制命令采用MESSAGE 方法攜帶；
- d) 4:目標設備收到命令后返回200 OK，該響應無消息體；
- e) 5:目標設備向SIP 服務器發(fā)送設備控制響應命令，設備控制響應命令采用MESSAGE 方法攜帶；
- f) 6:SIP服務器收到命令后返回200 OK，該響應無消息體；
- g) 7:SIP服務器向源設備轉發(fā)設備控制響應命令，設備控制響應命令采用MESSAGE 方法攜帶；
- h) 8:源設備收到命令后返回200 OK，該響應無消息體。
C.6.3.3 協(xié)議接口
C.6.3.3.1 請求命令消息體
請求命令消息體應符合下列要求:
- a) MESSAGE 消息頭Content type頭域為Content type:Application/MANSCAP + xml。
- b) 設備控制命令采用MANSCAP 協(xié)議格式定義。前端視頻加密控制命令包括命令類型(Cmd_Type)、命令序列號(SN)、設備編碼(DeviceID)、子命令等，采用MESSAGE 方法的消息體攜帶。
- c) 設備在收到MESSAGE 消息后，應立即返回應答，應答均無消息體。
- d) 消息體定義如下:
C.6.3.3.2 應答命令消息體
應答命令消息體應符合下列要求:
- a) 前端視頻加密控制應答命令應包括命令類型(CmdType)、命令序列號(SN)、設備編碼(DeviceID)、執(zhí)行結果(Result)，采用MESSAGE 方法的消息體攜帶。
- b) 設備控制應答命令采用MANSCAP協(xié)議格式定義。
- c) MESSAGE 消息頭Content type頭域為Content type:Application/MANSCAP + xml。
- d) 設備在收到MESSAGE 消息后，應立即返回應答，應答均無消息體。
- e) 消息體定義如下:
C.6.4 視頻加密
視頻加密應符合下列要求:
- a) 編碼器周期隨機生成128 bit的VEK。
- b) 讀取待加密的編碼片RBSP數(shù)據(jù)。
- c) 同時滿足下述兩個條件時，作廢當前VEK，激活新的VEK，否則繼續(xù)使用當前VEK:
● 此RBSP是GOP開始的第一個編碼片數(shù)據(jù)；
● 有新的VEK 可用。 - d) 編碼器隨機生成128 bit的IV。
- e) 采用約定的分組加密算法的OFB模式，用VEK 和IV 生成流密鑰。
- f) 加密流密鑰與待加密的編碼片RBSP數(shù)據(jù)按位對齊，進行異或運算，得到加密的編碼片RBSP數(shù)據(jù)。
- g) 封裝此加密RBSP的VCLNAL，entryption_idc＝1。
- h) 如激活了新的VEK 或使用了新的IV，應封裝安全擴展信息NAL，并先于此VCLNAL 輸出。
C.6.5 視頻解密視頻解密應符合下列要求:
- a) 從安全參數(shù)集NAL 中獲取IV、VEK 的密文，記作Ｅ(VEK)，用VKEK 解密Ｅ(VEK)，得到VEK。
- b) 讀取待解密的編碼片RBSP數(shù)據(jù)。
- c) 同時滿足下述兩個條件時，作廢當前VEK，激活新的VEK，否則繼續(xù)使用當前VEK:
● 此RBSP是GOP開始的第一個編碼片數(shù)據(jù)；
● 有新的VEK 可用。 - d) 采用約定的分組加密算法的OFB模式，用VEK 和IV 生成流密鑰。
- e) 流密鑰與待解密的編碼片RBSP 數(shù)據(jù)按位對齊，進行異或運算，得到解密后的編碼片RBSP數(shù)據(jù)。
C.6.6 實時加密視頻點播
C.6.6.1 基本要求
實時加密視頻點播的基本要求如下:
- a) 實時加密視頻點播的SIP消息應通過本域或其他域的具有安全功能的SIP 服務器進行路由、轉發(fā)，目標設備的實時視頻流應通過本域內(nèi)的具有安全功能的媒體服務器進行轉發(fā)。
- b) 實時加密視頻點播采用SIP 協(xié)議(RFC3261)中的INVITE 方法實現(xiàn)會話連接，采用RTP/RTCP協(xié)議(RFC3550)實現(xiàn)媒體傳輸。在實時點播的信令控制過程中具有安全功能的SIP服務器將視頻解密密鑰安全傳送到媒體接收者。
- c) 實時加密視頻點播的信令流程分為客戶端主動發(fā)起和第三方呼叫控制兩種方式，系統(tǒng)可選擇其中一種或兩種結合的實現(xiàn)方式。第三方呼叫控制的第三方控制者宜采用背靠背用戶代理實現(xiàn)，有關第三方呼叫控制見RFC3725。
C.6.6.2 客戶端主動發(fā)起流程
客戶端主動發(fā)起的實時加密視頻點播流程見圖C.7，消息示范參見D.6。
其中，信令1、8、9、10、11、12 為具有安全功能的SIP 服務器接收到客戶端的呼叫請求后通過B2BUA 代理方式建立媒體流接收者與具有安全功能的媒體服務器之間的媒體流信令過程，信令27為具有安全功能的SIP服務器通過三方呼叫控制建立具有安全功能的媒體服務器與媒體流發(fā)送者之間的媒體流信令過程，信令13、14為SIP服務器向媒體流接收者發(fā)送密鑰通知的過程，信令15~18為媒體流接收者斷開與具有安全功能的媒體服務器之間的媒體流信令過程，信令19~22 為具有安全功能的SIP服務器斷開具有安全功能的媒體服務器與媒體流發(fā)送者之間的媒體流信令過程。
命令流程描述如下:
- a) 1:媒體流接收者向具有安全功能的SIP 服務器發(fā)送INVITE消息，消息頭域中攜帶Subject字段，表明點播的視頻源ID、發(fā)送方媒體流序列號、媒體流接收者ID、接收端媒體流序列號等參數(shù)，SDP消息體中SM3字段為“Play”代表實時點播，消息頭域中攜帶Monitor-User-Identity 字段，表明用戶身份信息。
- b) 2:具有安全功能的SIP服務器收到INVITE請求后，通過三方呼叫控制建立具有安全功能的媒體服務器和媒體流發(fā)送者之間的媒體連接。向具有安全功能的媒體服務器發(fā)送INVITE消息，此消息不攜帶SDP消息體。
- c) 3:具有安全功能的媒體服務器收到具有安全功能的SIP服務器的INVITE請求后，回復200 OK響應，攜帶SDP消息體，消息體中描述了具有安全功能的具有安全功能的媒體服務器接收媒體流的IP、端口、媒體格式等內(nèi)容。
- d) 4:具有安全功能的SIP服務器收到具有安全功能的媒體服務器返回的200 OK響應后，向媒體流發(fā)送者發(fā)送INVITE請求，請求中攜帶消息3中具有安全功能的媒體服務器回復的200 OK響應消息體，并且修改SM3字段為“Play”代表實時點播，增加ｙ字段描述SSRC 值，ｆ字段描述媒體參數(shù)。
- e) 5:媒體流發(fā)送者收到具有安全功能的SIP 服務器的INVITE請求后，回復200 OK響應，攜帶SDP消息體，消息體中描述了媒體流發(fā)送者發(fā)送媒體流的IP、端口、媒體格式、SSRC字段等內(nèi)容。
- f) 6:具有安全功能的SIP服務器收到媒體流發(fā)送者返回的200 OK響應后，向具有安全功能的媒體服務器發(fā)送ACK 請求，請求中攜帶消息5中媒體流發(fā)送者回復的200 OK響應消息體，完成與具有安全功能的媒體服務器的INVITE會話建立過程。
- g) 7:具有安全功能的SIP服務器收到媒體流發(fā)送者返回的200 OK響應后，向媒體流發(fā)送者發(fā)送ACK 請求，請求中不攜帶消息體，完成與媒體流發(fā)送者的INVITE會話建立過程。
- h) 8:完成三方呼叫控制后，具有安全功能的SIP 服務器通過B2BUA 代理方式建立媒體流接收者和具有安全功能的媒體服務器之間的媒體連接。在消息1中增加SSRC 值，轉發(fā)給具有安全功能的媒體服務器。
- i) 9:具有安全功能的媒體服務器收到INVITE請求，回復200 OK響應，攜帶SDP 消息體，消息體中描述了具有安全功能的媒體服務器發(fā)送媒體流的IP、端口、媒體格式、SSRC 值等內(nèi)容。
- j) 10:具有安全功能的SIP 服務器在消息9的SDP 消息體基礎上增加當前媒體流發(fā)送者的VKEK 的版本號和VKEK 密文描述，用于媒體接收者對加密視頻流解密。格式為“A＝ VKEK:<空格>”，其中encryptedVKEK 為用戶公鑰加密VKEK 的結果，轉發(fā)給媒體流接收者。
- k) 11:媒體流接收者收到200 OK響應后，回復ACK 消息，完成與具有安全功能的SIP服務器的INVITE會話建立過程。
- l) 12:具有安全功能的SIP服務器將消息11轉發(fā)給具有安全功能的媒體服務器，完成與具有安全功能的媒體服務器的INVITE會話建立過程。
- m) 13:在實時點播過程中出現(xiàn)FDWSF的VKEK 改變情況下，SIP服務器通過會話內(nèi)的MESSAGE消息將新的VKEK密文和VKEK的版本號通知媒體流接收者，信令格式見C.6.6.4協(xié)議接口描述。
- n) 14:媒體流接收者收到MESSAGE消息后回復200 OK響應。
- o) 15:媒體流接收者向具有安全功能的SIP服務器發(fā)送BYE 消息，斷開消息1、10、11建立的同媒體流接收者的INVITE會話。
- p) 16:具有安全功能的SIP服務器收到BYE 消息后回復200 OK響應，會話斷開。
- q) 17:具有安全功能的SIP服務器收到BYE 消息后向具有安全功能的媒體服務器發(fā)送BYE 消息，斷開消息8、9、12建立的同具有安全功能的媒體服務器的INVITE會話。
- r) 18:具有安全功能的媒體服務器收到BYE 消息后回復200 OK響應，會話斷開。
- s) 19:具有安全功能的SIP服務器向具有安全功能的媒體服務器發(fā)送BYE 消息，斷開消息2、3、6建立的同具有安全功能的媒體服務器的INVITE會話。
- t) 20:具有安全功能的媒體服務器收到BYE 消息后回復200 OK響應，會話斷開。
- u) 21:具有安全功能的SIP服務器向媒體流發(fā)送者發(fā)送BYE 消息，斷開消息4、5、7建立的同媒體流發(fā)送者的INVITE會話。
- v) 22:媒體流發(fā)送者收到BYE 消息后回復200 OK響應，會話斷開。
C.6.6.3 第三方呼叫控制流程
第三方呼叫控制的實時加密視頻點播流程見圖C.8，消息示范參見D.7。
圖C.8 第三方呼叫控制的實時加密視頻點播流程示意圖其中，信令1～6為具有安全功能的SIP服務器通過三方呼叫控制建立具有安全功能的媒體服務器與媒體流發(fā)送者之間的媒體鏈接信令過程，信令7～12為具有安全功能的SIP 服務器通過三方呼叫控制建立媒體流接收者與具有安全功能的媒體服務器之間的媒體鏈接信令過程，信令13、14為SIP 服務器向媒體流接收者發(fā)送密鑰通知的過程，信令15～18為斷開媒體流接收者與具有安全功能的媒體服務器之間的媒體鏈接信令過程，信令19～22為斷開具有安全功能的媒體服務器與媒體流發(fā)送者之間的媒體鏈接信令過程。
命令流程描述如下:
- a) 1:具有安全功能的SIP服務器向具有安全功能的媒體服務器發(fā)送INVITE消息，此消息不攜帶SDP消息體。
- b) 2:具有安全功能的媒體服務器收到具有安全功能的SIP服務器的INVITE請求后，回復200 OK響應，攜帶SDP消息體，消息體中描述了具有安全功能的媒體服務器接收媒體流的IP、端口、媒體格式等內(nèi)容。
- c) 3:具有安全功能的SIP服務器收到具有安全功能的媒體服務器返回的200 OK響應后，向媒體流發(fā)送者發(fā)送INVITE請求，請求中攜帶消息2中具有安全功能的媒體服務器回復的200 OK響應消息體，并且修改SM3字段為“Play”代表實時點播，增加ｙ字段描述SSRC 值，ｆ字段描述媒體參數(shù)。
- d) 4:媒體流發(fā)送者收到具有安全功能的SIP 服務器的INVITE請求后，回復200 OK響應，攜帶SDP消息體，消息體中描述了媒體流發(fā)送者發(fā)送媒體流的IP、端口、媒體格式、SSRC 字段等內(nèi)容。
- e) 5:具有安全功能的SIP服務器收到媒體流發(fā)送者返回的200 OK響應后，向具有安全功能的媒體服務器發(fā)送ACK 請求，請求中攜帶消息4中媒體流發(fā)送者回復的200 OK響應消息體，完成與具有安全功能的媒體服務器的INVITE會話建立過程。
- f) 6:具有安全功能的SIP服務器收到媒體流發(fā)送者返回的200 OK響應后，向媒體流發(fā)送者發(fā)送ACK 請求，請求中不攜帶消息體，完成與媒體流發(fā)送者的INVITE會話建立過程。
- g) 7:具有安全功能的SIP服務器向媒體流接收者發(fā)送INVITE消息，此消息不攜帶SDP消息體。
- h) 8:媒體流接收者收到具有安全功能的SIP 服務器的INVITE請求后，回復200 OK響應，攜帶SDP消息體，消息體中描述了媒體流接收者接收媒體流的IP、端口、媒體格式等內(nèi)容。
- i) 9:具有安全功能的SIP服務器收到媒體流接收者返回的200 OK響應后，向具有安全功能的媒體服務器發(fā)送INVITE請求，請求中攜帶消息8中媒體流接收者回復的200 OK響應消息體，并且并且修改SM3字段為“Play”代表實時點播，增加ｙ字段描述SSRC 值。
- j) 10:具有安全功能的媒體服務器收到具有安全功能的SIP 服務器的INVITE請求后，回復200 OK響應，攜帶SDP消息體，消息體中描述了具有安全功能的媒體服務器發(fā)送媒體流的IP、端口、媒體格式、SSRC 字段等內(nèi)容。
- k) 11:具有安全功能的SIP服務器收到具有安全功能的媒體服務器返回的200 OK響應后，向媒體流接收者發(fā)送ACK 請求，請求中攜帶內(nèi)容為在消息10中具有安全功能的媒體服務器回復的200 OK響應消息體基礎上，增加當前媒體流發(fā)送者的VKEK 版本號和VKEK 密文描述，用于媒體接收者對加密視頻流解密，格式為“A＝VKEK:<空格>”，其中encryptedVKEK 為用用戶公鑰加密VKEK 的結果。發(fā)給媒體流接收者完成與媒體流接收者的INVITE會話建立過程。
- l) 12:具有安全功能的SIP服務器收到具有安全功能的媒體服務器返回的200 OK響應后，向具有安全功能的媒體服務器發(fā)送ACK 請求，請求中不攜帶消息體，完成與具有安全功能的媒體服務器的INVITE會話建立過程。
- m) 13:在實時點播過程中出現(xiàn)FDWSF 的VKEK 改變情況下，SIP 服務器通過會話內(nèi)的MESSAGE消息將新的VKEK 密文和VKEK 的版本號通知媒體流接收者，信令格式見C.6.6.4協(xié)議接口描述。
- n) 14:媒體流接收者收到MESSAGE消息后回復200 OK響應。
- o) 15:具有安全功能的SIP服務器向媒體流接收者發(fā)送BYE 消息，斷開消息7、8、11建立的同媒體流接收者的INVITE會話。
- p) 16:媒體流接收者收到BYE 消息后回復200 OK響應，會話斷開。
- q) 17:具有安全功能的SIP 服務器向具有安全功能的媒體服務器發(fā)送BYE 消息，斷開消息9、10、12建立的同具有安全功能的媒體服務器的INVITE會話。
- r) 18:具有安全功能的媒體服務器收到BYE 消息后回復200 OK響應，會話斷開。
- s) 19:具有安全功能的SIP服務器向具有安全功能的媒體服務器發(fā)送BYE 消息，斷開消息1、2、5建立的同具有安全功能的媒體服務器的INVITE會話。
- t) 20::具有安全功能的媒體服務器收到BYE 消息后回復200 OK響應，會話斷開。
- u) 21:具有安全功能的SIP服務器向媒體流發(fā)送者發(fā)送BYE 消息，斷開消息3、4、6建立的同媒體流發(fā)送者的INVITE會話。
- v) 22:媒體流發(fā)送者收到BYE 消息后回復200 OK響應，會話斷開。
C.6.6.4 協(xié)議接口
協(xié)議接口應符合下列要求:
- a) SIP 消息頭域(如TO，FROM，Cseq，Call-ID，MaxForwards，Via等)的詳細定義符合相關SIP消息的RFC 文檔的規(guī)定。
- b) 消息頭域Allow 字段應支持INVITE，ACK，INFO，CANCEL，BYE，OPTIONS，MESSAGE方法，不排除支持其他SIP和SIP擴展方法。
- c) 消息頭Content type字段應表示消息體采用SDP 協(xié)議格式定義。例如:Content type:application/SDP。
- d) 源設備應在SDP協(xié)議格式的消息體中包括ｔ行(見RFC4566的5.9)，ｔ行的開始時間和結束時間均設置成0，表示實時視頻點播。
- e) 發(fā)送給具有安全功能的媒體服務器的消息的消息頭應包括Subject字段。實時視頻圖像點播流程中攜帶的請求和應答消息體采用SDP 協(xié)議格式定義。有關SDP 的詳細描述見RFC4566。
- f) SDP文本信息包括:會話名稱和意圖，會話持續(xù)時間，構成會話的媒體，有關接收媒體的信息(地址等)。
- g) SDP協(xié)議格式消息體應包括ｏ行(見RFC4566的5.2)，ｏ行中的UserｎAｍｅ應為本設備的設備編碼，設備編碼應符合6.1.1的規(guī)定；ｃ行中應包括設備或系統(tǒng)IP 地址；ｍ 行中應包括媒體接收端口號。
- h) 實時點播過程中，FDWSF碼流的密鑰版本改變后，通知媒體流接收者的MESSAGE消息攜帶消息體格式定義如下:
C.6.7 歷史加密視頻的回放
C.6.7.1 基本要求
歷史加密視頻的回放應符合下列要求:
- a) 應采用SIP協(xié)議(RFC3261)中的INVITE 方法實現(xiàn)會話連接，采用SIP擴展協(xié)議(RFC2976)INFO 方法的消息體攜帶加密視頻回放控制命令，采用RTP/RTCP 協(xié)議(RFC3550)實現(xiàn)媒體傳輸。媒體回放控制命令引用MANSRTSP協(xié)議中的PLAY，PAUSE，TEARDOWN 的請求消息和應答消息。
- b) 歷史加密視頻回放的信令流程分為客戶端主動發(fā)起和第三方呼叫控制兩種方式，系統(tǒng)可選擇其中一種或兩種結合的實現(xiàn)方式。第三方呼叫控制的第三方控制者宜采用背靠背用戶代理實現(xiàn)，有關第三方呼叫控制見RFC3725。
- c) 媒體流接收者可以是具有安全功能的SIP 客戶端、具有安全功能的SIP 設備(如視頻解碼器)等，媒體流發(fā)送者可以是具有安全功能的SIP設備、具有安全功能的媒體服務器等。
C.6.7.2 客戶端主動發(fā)起流程
客戶端主動發(fā)起的歷史加密視頻回放流程見圖C.9，消息示范參見D.8。
圖C.9 客戶端主動發(fā)起的歷史加密視頻回放流程示意圖其中，信令1、8、9、10、11、12 為具有安全功能的SIP 服務器接收到客戶端的呼叫請求后通過B2BUA 代理方式建立媒體流接受者與具有安全功能的媒體服務器之間的媒體鏈接信令過程，信令2～7為具有安全功能的SIP服務器通過三方呼叫控制建立具有安全功能的媒體服務器與媒體流之間的媒體鏈接信令過程，信令13～16為媒體流接收者進行回放控制信令過程，信令17～20:為媒體流發(fā)送者回放、下載到文件結束向媒體接收者發(fā)送通知消息過程，信令21～24為斷開媒體流接收者與具有安全功能的媒體服務器之間的媒體鏈接信令過程，信令25～28為具有安全功能的SIP服務器斷開具有安全功能的媒體服務器與媒體流發(fā)送者之間的媒體鏈接信令過程。
命令流程描述如下:
- a) 1:媒體流接收者向具有安全功能的SIP 服務器發(fā)送INVITE消息，消息頭域中攜帶Subject字段，表明點播的視頻源ID、發(fā)送方媒體流序列號、媒體流接收者ID、接收端媒體流序列號標識等參數(shù)，SDP消息體中SM3字段為“PlayｂACK”代表歷史回放，ｕ字段代表回放通道ID和回放類型，ｔ字段代表回放時間段，消息頭域中攜帶Monitor-User-Identity字段，表明用戶身份信息。
- b) 2:具有安全功能的SIP服務器收到INVITE請求后，通過三方呼叫控制建立具有安全功能的媒體服務器和媒體流發(fā)送者之間的媒體連接。向具有安全功能的媒體服務器發(fā)送INVITE消息，此消息不攜帶SDP消息體。
- c) 3:具有安全功能的媒體服務器收到具有安全功能的SIP服務器的INVITE請求后，回復200 OK響應，攜帶SDP消息體，消息體中描述了具有安全功能的媒體服務器接收媒體流的IP、端口、媒體格式等內(nèi)容。
- d) 4:具有安全功能的SIP服務器收到具有安全功能的媒體服務器返回的200 OK響應后，向媒體流發(fā)送者發(fā)送INVITE請求，請求中攜帶消息3中具有安全功能的媒體服務器回復的200 OK響應消息體，并且修改SM3字段為“Playback”代表歷史回放，ｕ字段代表回放通道ID和回放類型，ｔ字段代表回放時間段，增加ｙ字段描述SSRC 值，ｆ字段描述媒體參數(shù)。
- e) 5:媒體流發(fā)送者收到具有安全功能的SIP 服務器的INVITE請求后，回復200 OK響應，攜帶SDP消息體，消息體中描述了媒體流發(fā)送者發(fā)送媒體流的IP、端口、媒體格式、SSRC 字段等內(nèi)容。
- f) 6:具有安全功能的SIP服務器收到媒體流發(fā)送者返回的200 OK響應后，向具有安全功能的媒體服務器發(fā)送ACK 請求，請求中攜帶消息5中媒體流發(fā)送者回復的200 OK響應消息體，完成與具有安全功能的媒體服務器的INVITE會話建立過程。
- g) 7:具有安全功能的SIP服務器收到媒體流發(fā)送者返回的200 OK響應后，向媒體流發(fā)送者發(fā)送ACK 請求，請求中不攜帶消息體，完成與媒體流發(fā)送者的INVITE會話建立過程。
- h) 8:完成三方呼叫控制后，具有安全功能的SIP 服務器通過B2BUA 代理方式建立媒體流接收者和具有安全功能的媒體服務器之間的媒體連接。在消息1中增加SSRC 值，轉發(fā)給具有安全功能的媒體服務器。
- i) 9:具有安全功能的媒體服務器收到INVITE請求，回復200 OK響應，攜帶SDP 消息體，消息體中描述了具有安全功能的媒體服務器發(fā)送媒體流的IP、端口、媒體格式、SSRC 值等內(nèi)容。
- j) 10:具有安全功能的SIP服務器將消息9轉發(fā)給媒體流接收者，同時擴展多個A字段攜帶歷史文件的VKEKVersion 和VKEK。用于客戶端對加密視頻流解密播放，格式為“A＝ VKEK:”，其中encryptedVKEK 為用戶公鑰加密VKEK 的結果，根據(jù)錄像時間段中的VKEK 數(shù)量，可攜帶多個VKEKVersion和VKEK 密文。當請求的歷史加密視頻包含多個密鑰時，媒體流接收者依據(jù)歷史加密視頻的密鑰版本選擇A屬性中所攜帶的對應密鑰。
- k) 11:媒體流接收者收到200 OK響應后，回復ACK 消息，完成與具有安全功能的SIP服務器的INVITE會話建立過程。
- l) 12:具有安全功能的SIP服務器將消息11轉發(fā)給具有安全功能的媒體服務器，完成與具有安全功能的媒體服務器的INVITE會話建立過程。
- m) 13:在回放過程中，媒體流接收者通過向具有安全功能的SIP 服務器發(fā)送會話內(nèi)INFO消息進行回放控制，包括視頻的暫停、播放、快放、慢放、隨機拖放播放等操作。
- n) 14:具有安全功能的SIP服務器收到消息13后轉發(fā)給媒體流發(fā)送者。
- o) 15:媒體流發(fā)送者收到消息14后回復200 OK響應。
- p) 16:具有安全功能的SIP服務器將消息15轉發(fā)給媒體流接收者。
- q) 17:媒體流發(fā)送者在文件回放結束后發(fā)送會話內(nèi)MESSAGE消息，通知具有安全功能的SIP 服務器回放已結束。
- r) 18:具有安全功能的SIP服務器收到消息17后轉發(fā)給媒體流接收者。
- s) 19:媒體流接收者收到消息18后回復200 OK響應，進行鏈路斷開過程。
- t) 20::具有安全功能的SIP服務器將消息19轉發(fā)給媒體流發(fā)送者。
- u) 21:媒體流接收者向具有安全功能的SIP服務器發(fā)送BYE 消息，斷開消息1、10、11建立的同媒體流接收者的INVITE會話。
- v) 22:具有安全功能的SIP服務器收到BYE 消息后回復200 OK響應，會話斷開。
- w) 23:具有安全功能的SIP服務器收到BYE 消息后向具有安全功能的媒體服務器發(fā)送BYE 消息，斷開消息8、9、12建立的同具有安全功能的媒體服務器的INVITE會話。
- x) 24:具有安全功能的媒體服務器收到BYE消息后回復200 OK響應，會話斷開。
- y) 25:具有安全功能的SIP服務器向具有安全功能的媒體服務器發(fā)送BYE 消息，斷開消息2、3、6建立的同具有安全功能的媒體服務器的INVITE會話。
- z) 26:具有安全功能的媒體服務器收到BYE 消息后回復200 OK響應，會話斷開。
- aa) 27:具有安全功能的SIP服務器向媒體流發(fā)送者發(fā)送BYE 消息，斷開消息4、5、7建立的同媒體流發(fā)送者的INVITE會話。
- bb) 28:媒體流發(fā)送者收到BYE 消息后回復200 OK響應，會話斷開。
C.6.7.3 第三方呼叫控制流程
第三方呼叫控制的歷史加密視頻回放流程見圖C.10，消息示范參見D.9。
其中，信令1～6為具有安全功能的SIP服務器通過三方呼叫控制建立具有安全功能的媒體服務器與媒體流發(fā)送者之間的媒體鏈接信令過程，信令7～12為具有安全功能的SIP 服務器通過三方呼叫控制建立媒體流接收者與具有安全功能的媒體服務器之間的媒體鏈接信令過程，信令13～14為回放控制信令過程，信令15～16為媒體流發(fā)送者回放、下載到文件結束向媒體接收者發(fā)送的回放結束通知消息，信令17～20:為斷開媒體流接收者與具有安全功能的媒體服務器之間的媒體鏈接信令過程，信令21～24為斷開具有安全功能的媒體服務器與媒體流發(fā)送者之間的媒體鏈接信令過程。
命令流程描述如下:
- a) 1:具有安全功能的SIP服務器向具有安全功能的媒體服務器發(fā)送INVITE消息，此消息不攜帶SDP消息體。
- b) 2:具有安全功能的媒體服務器收到具有安全功能的SIP服務器的INVITE請求后，回復200 OK響應，攜帶SDP消息體，消息體中描述了具有安全功能的媒體服務器接收媒體流的IP、端口、媒體格式等內(nèi)容。
- c) 3:具有安全功能的SIP服務器收到具有安全功能的媒體服務器返回的200 OK響應后，向媒體流發(fā)送者發(fā)送INVITE請求，請求中攜帶消息2中具有安全功能的媒體服務器回復的200 OK響應消息體，并且修改SM3字段為“PlayｂACK”代表歷史回放，ｕ字段代表回放通道ID和回放類型，ｔ字段代表回放時間段，增加ｙ字段描述SSRC 值，ｆ字段描述媒體參數(shù)。
- d) 4:媒體流發(fā)送者收到具有安全功能的SIP 服務器的INVITE請求后，回復200 OK響應，攜帶SDP消息體，消息體中描述了媒體流發(fā)送者發(fā)送媒體流的IP、端口、媒體格式、SSRC 字段等內(nèi)容。
- e) 5:具有安全功能的SIP服務器收到媒體流發(fā)送者返回的200 OK響應后，向具有安全功能的媒體服務器發(fā)送ACK 請求，請求中攜帶消息4中媒體流發(fā)送者回復的200 OK響應消息體，完成與具有安全功能的媒體服務器的INVITE會話建立過程。
- f) 6:具有安全功能的SIP服務器收到媒體流發(fā)送者返回的200 OK響應后，向媒體流發(fā)送者發(fā)送ACK 請求，請求中不攜帶消息體，完成與媒體流發(fā)送者的INVITE會話建立過程。
- g) 7:具有安全功能的SIP服務器向媒體流接收者發(fā)送INVITE消息，此消息不攜帶SDP消息體。
- h) 8:媒體流接收者收到具有安全功能的SIP 服務器的INVITE請求后，回復200 OK響應，攜帶SDP消息體，消息體中描述了媒體流接收者接收媒體流的IP、端口、媒體格式等內(nèi)容。
- i) 9:具有安全功能的SIP服務器收到媒體流接收者返回的200 OK響應后，向具有安全功能的媒體服務器發(fā)送INVITE請求，請求中攜帶消息8中媒體流接收者回復的200 OK響應消息體，并且修改SM3字段為“PlayｂACK”代表歷史回放，增加ｙ字段描述SSRC 值。
- j) 10:具有安全功能的媒體服務器收到具有安全功能的SIP 服務器的INVITE請求后，回復200 OK響應，攜帶SDP消息體，消息體中描述了具有安全功能的媒體服務器發(fā)送媒體流的IP、端口、媒體格式、SSRC 字段等內(nèi)容。
- k) 11:具有安全功能的SIP服務器收到具有安全功能的媒體服務器返回的200 OK響應后，向媒體流接收者發(fā)送ACK 請求，請求中攜帶消息10 中具有安全功能的媒體服務器回復的200 OK響應消息體，同時擴展A字段攜帶歷史文件的VKEKVersion和VKEK，用于客戶端對加密視頻流解密播放，格式為“A＝ VKEK:<空格>”，其中encryptedVKEK 為用用戶公鑰加密VKEK 的結果，根據(jù)錄像時間段中的VKEK 數(shù)量，可攜帶多個VKEKVersion和VKEK 密文，完成與媒體流接收者的INVITE會話建立過程。
- l) 12:具有安全功能的SIP服務器收到具有安全功能的媒體服務器返回的200 OK響應后，具有安全功能的媒體服務器發(fā)送ACK 請求，請求中不攜帶消息體，完成與具有安全功能的媒體服務器的INVITE會話建立過程。
- m) 13:在回放過程中，具有安全功能的SIP服務器通過向媒體流發(fā)送者發(fā)送INFO消息進行回放控制，包括視頻的暫停、播放、定位、快放、慢放等操作。
- n) 14:媒體流發(fā)送者收到INFO消息后回復200 OK響應。
- o) 15:媒體流發(fā)送者在文件回放結束后發(fā)送會話內(nèi)MESSAGE消息，通知具有安全功能的SIP 服務器回放已結束。
- p) 16:具有安全功能的SIP服務器收到MESSAGE消息后回復200 OK響應，進行鏈路斷開過程。
- q) 17:具有安全功能的SIP服務器向媒體流接收者發(fā)送BYE 消息，斷開消息7、8、11建立的同媒體流接收者的INVITE會話。
- r) 18:媒體流接收者收到BYE 消息后回復200 OK響應，會話斷開。
- s) 19:具有安全功能的SIP 服務器向具有安全功能的媒體服務器發(fā)送BYE 消息，斷開消息9、10、12建立的同帶有安全功能的媒體服務器的INVITE會話。
- t) 20::帶有安全功能的媒體服務器收到BYE 消息后回復200 OK響應，會話斷開。
- u) 21:具有安全功能的SIP服務器向帶有安全功能的媒體服務器發(fā)送BYE 消息，斷開消息1、2、5建立的同帶有安全功能的媒體服務器的INVITE會話。
- v) 22:帶有安全功能的媒體服務器收到BYE 消息后回復200 OK響應，會話斷開。
- w) 23:具有安全功能的SIP服務器向媒體流發(fā)送者發(fā)送BYE 消息，斷開消息3、4、6建立的同媒體流發(fā)送者的INVITE會話。
- x) 24:媒體流發(fā)送者收到BYE 消息后回復200 OK響應，會話斷開。
C.6.7.4 協(xié)議接口
C.6.7.4.1 會話控制協(xié)議
會話控制協(xié)議應符合下列要求:
- a) SIP 消息頭域(如TO，FROM，Cseq，Call-ID，MaxForwards，Via等)的詳細定義符合相關SIP消息的RFC 文檔的規(guī)定。
- b) 消息頭域Allow 字段應支持INVITE，ACK，INFO，CANCEL，BYE，OPTIONS，MESSAGE方法，不排除支持其他SIP和SIP擴展方法。
- c) 消息頭Content type字段為Content type:application/SDP。
- d) 歷史視頻回放流程中攜帶消息體的請求和響應的消息體應采用SDP 協(xié)議格式定義。有關SDP的詳細描述見RFC4566。
- e) SDP文本信息包括:會話名稱和意圖，會話持續(xù)時間，構成會話的媒體，有關接收媒體的信息(地址等)。INVITE 請求以時間段方式獲取加密歷史圖像。
- f) 定位歷史加密視頻數(shù)據(jù)的信息在SDP 協(xié)議格式的消息體中攜帶，應包含設備名和時間段信息，規(guī)定如下:
● 媒體流接收者應在SDP協(xié)議格式的消息體中包括ｕ行(見RFC4566的5.5)，ｕ行應填寫產(chǎn)生歷史媒體的媒體源(如某個攝像頭)的設備URI，應符合6.1.2 的規(guī)定。設備URI應包含媒體源設備編碼，媒體源設備編碼成為檢索歷史媒體數(shù)據(jù)的設備名信息；
● 媒體流接收者應在SDP 協(xié)議格式的消息體中包括ｔ行(見RFC4566的5.9)，ｔ行的開始時間和結束時間組成檢索歷史媒體數(shù)據(jù)的時間段信息。
C.6.7.4.2 視頻回放控制協(xié)議
視頻回放控制協(xié)議應符合下列要求:
- a) 視頻回放控制流程是采用SIP消息INFO 實現(xiàn)視頻播放、暫停、進/退和停止等視頻回放控制命令的過程。視頻回放控制請求消息在INFO 方法的消息體中攜帶，回放控制請求消息應符合MANSRTSP協(xié)議的請求消息的部分定義，包括PLAY、PAUSE、TEARDOWN；視頻回放控制應答消息在INFO 方法的200 OK響應消息體中攜帶，回放控制應答消息應符合MANSRTSP協(xié)議的應答消息定義。
- b) 攜帶MANSRTSP 請求和應答命令的INFO 消息頭Content type字段為Content type:Application/MANSRTSP。
C.6.8 加密視頻的下載
C.6.8.1 基本要求
具有安全功能的SIP服務器接收到媒體接收者發(fā)送的視頻文件下載請求后向媒體流發(fā)送者發(fā)送媒體文件下載命令，媒體流發(fā)送者采用ＲＴＰ將視頻流傳輸給媒體流接收者，媒體流接收者直接將視頻流保存為加密媒體文件。媒體流接收者可以是帶有安全功能的用戶終端或安全視頻監(jiān)控管理平臺，媒體流發(fā)送者可以是安全媒體設備或安全視頻監(jiān)控管理平臺。
C.6.8.2 客戶端主動發(fā)起流程
客戶端主動發(fā)起的媒體文件下載流程見圖C.11，消息示范參見D.10。
圖C.11 客戶端主動發(fā)起的視頻文件下載流程示意圖其中，信令1、8、9、10、11、12 為具有安全功能的SIP 服務器接收到客戶端的呼叫請求后通過B2BUA 代理方式建立媒體流接受者與帶有安全功能的媒體服務器之間的媒體鏈接信令過程，信令2～7為具有安全功能的SIP服務器通過三方呼叫控制建立帶有安全功能的媒體服務器與媒體流之間的媒體鏈接信令過程，信令13～16為媒體流發(fā)送者回放、下載到文件結束向媒體接收者發(fā)送下載完成的通知消息過程，信令17～20為斷開媒體流接收者斷開與帶有安全功能的媒體服務器之間的媒體鏈接信令過程，信令21～24為具有安全功能的SIP服務器斷開帶有安全功能的媒體服務器與媒體流發(fā)送者之間的媒體鏈接信令過程。
命令流程描述如下:
- a) 1:媒體流接收者向具有安全功能的SIP 服務器發(fā)送INVITE消息，消息頭域中攜帶Subject字段，表明點播的視頻源ID、發(fā)送方媒體流序列號、媒體流接收者ID、接收端媒體流序列號標識等參數(shù)，SDP消息體中SM3字段為“Download”代表文件下載，ｕ字段代表下載通道ID和下載類型，ｔ字段代表下載時間段，消息頭域中攜帶Monitor-User-Identity字段，表明用戶身份信息。
- b) 2:具有安全功能的SIP服務器收到INVITE請求后，通過三方呼叫控制建立具有安全功能的媒體服務器和媒體流發(fā)送者之間的媒體連接。向具有安全功能的媒體服務器發(fā)送INVITE消息，此消息不攜帶SDP消息體。
- c) 3:具有安全功能的媒體服務器收到具有安全功能的SIP服務器的INVITE請求后，回復200 OK響應，攜帶SDP消息體，消息體中描述了具有安全功能的媒體服務器接收媒體流的IP、端口、媒體格式等內(nèi)容。
- d) 4:具有安全功能的SIP服務器收到具有安全功能的媒體服務器返回的200 OK響應后，向媒體流發(fā)送者發(fā)送INVITE請求，請求中攜帶消息3中具有安全功能的媒體服務器回復的200 OK響應消息體，并且修改SM3字段為“Download”代表文件下載，ｕ字段代表下載通道ID和下載類型，ｔ字段代表下載時間段，增加ｙ字段描述SSRC 值，ｆ字段描述媒體參數(shù)。
- e) 5:媒體流發(fā)送者收到具有安全功能的SIP 服務器的INVITE請求后，回復200 OK響應，攜帶SDP消息體，消息體中描述了媒體流發(fā)送者發(fā)送媒體流的IP、端口、媒體格式、SSRC 字段等內(nèi)容。
- f) 6:具有安全功能的SIP服務器收到媒體流發(fā)送者返回的200 OK響應后，向具有安全功能的媒體服務器發(fā)送ACK 請求，請求中攜帶消息5中媒體流發(fā)送者回復的200 OK響應消息體，完成與具有安全功能的媒體服務器的INVITE會話建立過程。
- g) 7:具有安全功能的SIP服務器收到媒體流發(fā)送者返回的200 OK響應后，向媒體流發(fā)送者發(fā)送ACK 請求，請求中不攜帶消息體，完成與媒體流發(fā)送者的INVITE會話建立過程。
- h) 8:完成三方呼叫控制后，具有安全功能的SIP 服務器通過B2BUA 代理方式建立媒體流接收者和具有安全功能的媒體服務器之間的媒體連接。在消息1中增加SSRC 值，轉發(fā)給具有安全功能的媒體服務器。
- i) 9:具有安全功能的媒體服務器收到INVITE請求，回復200 OK響應，攜帶SDP 消息體，消息體中描述了具有安全功能的媒體服務器發(fā)送媒體流的IP、端口、媒體格式、SSRC 值等內(nèi)容。
- j) 10:具有安全功能的SIP服務器將消息9轉發(fā)給媒體流接收者，同時擴展A字段攜帶歷史文件的VKEKVersion和VKEK，用于客戶端對加密視頻流解密播放，格式為“A＝VKEK:<空格>”，其中encryptedVKEK 為用戶公鑰加密VKEK 的結果，根據(jù)錄像時間段中的VKEK 數(shù)量，可攜帶多個VKEKVersion和VKEK 密文。當請求的歷史加密視頻包含多個密鑰時，媒體流接收者依據(jù)歷史加密視頻的密鑰版本選擇A屬性中所攜帶的對應密鑰。
- k) 11:媒體流接收者收到200 OK響應后，回復ACK 消息，完成與具有安全功能的SIP服務器的INVITE會話建立過程。
- l) 12:具有安全功能的SIP服務器將消息11轉發(fā)給具有安全功能的媒體服務器，完成與具有安全功能的媒體服務器的INVITE會話建立過程。
- m) 13:媒體流發(fā)送者在文件下載結束后發(fā)送會話內(nèi)MESSAGE消息，通知具有安全功能的SIP 服務器下載已結束。
- n) 14:具有安全功能的SIP服務器收到消息17后轉發(fā)給媒體流接收者。
- o) 15:媒體流接收者收到消息18后回復200 OK響應，進行鏈路斷開過程。
- p) 16:具有安全功能的SIP服務器將消息19轉發(fā)給媒體流發(fā)送者。
- q) 17:媒體流接收者向具有安全功能的SIP服務器發(fā)送BYE 消息，斷開消息1、10、11建立的同媒體流接收者的INVITE會話。
- r) 18:具有安全功能的SIP服務器收到BYE 消息后回復200 OK響應，會話斷開。
- s) 19:具有安全功能的SIP服務器收到BYE 消息后向具有安全功能的媒體服務器發(fā)送BYE 消息，斷開消息8、9、12建立的同具有安全功能的媒體服務器的INVITE會話。
- t) 20::具有安全功能的媒體服務器收到BYE 消息后回復200 OK響應，會話斷開。
- u) 21:具有安全功能的SIP服務器向具有安全功能的媒體服務器發(fā)送BYE 消息，斷開消息2、3、6建立的同具有安全功能的媒體服務器的INVITE會話。
- v) 22:具有安全功能的媒體服務器收到BYE 消息后回復200 OK響應，會話斷開。
- w) 23:具有安全功能的SIP服務器向媒體流發(fā)送者發(fā)送BYE 消息，斷開消息4、5、7建立的同媒體流發(fā)送者的INVITE會話。
- x) 24:媒體流發(fā)送者收到BYE 消息后回復200 OK響應，會話斷開。
C.6.8.3 第三方呼叫控制流程
第三方呼叫控制的媒體文件下載流程見圖C.12，消息示范參見D.11。
其中，信令1～6為具有安全功能的SIP服務器通過三方呼叫控制建立具有安全功能的媒體服務器與媒體流發(fā)送者之間的媒體鏈接信令過程，信令7～12為具有安全功能的SIP 服務器通過三方呼叫控制建立媒體流接收者與具有安全功能的媒體服務器之間的媒體鏈接信令過程，信令13～14為媒體流發(fā)送者回放、下載到文件結束向媒體接收者發(fā)送下載完成通知消息，信令15～18為斷開媒體流接收者與具有安全功能的媒體服務器之間的媒體鏈接信令過程，信令19～22為斷開具有安全功能的媒體服務器與媒體流發(fā)送者之間的媒體鏈接信令過程。
命令流程描述如下:
- a) 1:具有安全功能的SIP服務器向具有安全功能的媒體服務器發(fā)送INVITE消息，此消息不攜帶SDP消息體。
- b) 2:具有安全功能的媒體服務器收到具有安全功能的SIP服務器的INVITE請求后，回復200 OK響應，攜帶SDP消息體，消息體中描述了具有安全功能的媒體服務器接收媒體流的IP、端口、媒體格式等內(nèi)容。
- c) 3:具有安全功能的SIP服務器收到具有安全功能的媒體服務器返回的200 OK響應后，向媒體流發(fā)送者發(fā)送INVITE請求，請求中攜帶消息2中具有安全功能的媒體服務器回復的200 OK響應消息體，并且修改SM3字段為“Download”代表下載，ｕ字段代表下載通道ID和下載視頻類型，ｔ字段代表下載時間段，增加ｙ字段描述SSRC 值，ｆ字段描述媒體參數(shù)。
- d) 4:媒體流發(fā)送者收到具有安全功能的SIP 服務器的INVITE請求后，回復200 OK響應，攜帶SDP消息體，消息體中描述了媒體流發(fā)送者發(fā)送媒體流的IP、端口、媒體格式、SSRC 字段等內(nèi)容。
- e) 5:具有安全功能的SIP服務器收到媒體流發(fā)送者返回的200 OK響應后，向具有安全功能的媒體服務器發(fā)送ACK 請求，請求中攜帶消息4中媒體流發(fā)送者回復的200 OK響應消息體，完成與具有安全功能的媒體服務器的INVITE會話建立過程。
- f) 6:具有安全功能的SIP服務器收到媒體流發(fā)送者返回的200 OK響應后，向媒體流發(fā)送者發(fā)送ACK 請求，請求中不攜帶消息體，完成與媒體流發(fā)送者的INVITE會話建立過程。
- g) 7:具有安全功能的SIP服務器向媒體流接收者發(fā)送INVITE消息，此消息不攜帶SDP消息體。
- h) 8:媒體流接收者收到具有安全功能的SIP 服務器的INVITE請求后，回復200 OK響應，攜帶SDP消息體，消息體中描述了媒體流接收者接收媒體流的IP、端口、媒體格式等內(nèi)容。
- i) 9:具有安全功能的SIP服務器收到媒體流接收者返回的200 OK響應后，向具有安全功能的媒體服務器發(fā)送INVITE請求，請求中攜帶消息8中媒體流接收者回復的200 OK響應消息體，并且修改SM3字段為“PlayｂACK”代表歷史回放，增加ｙ字段描述SSRC 值。
- j) 10:具有安全功能的媒體服務器收到具有安全功能的SIP服務器的INVITE請求后，回復200 OK響應，攜帶SDP消息體，消息體中描述了具有安全功能的媒體服務器發(fā)送媒體流的IP、端口、媒體格式、SSRC 字段等內(nèi)容。
- k) 11:具有安全功能的SIP服務器收到具有安全功能的媒體服務器返回的200 OK響應后，向媒體流接收者發(fā)送ACK請求，請求中攜帶消息10中具有安全功能的媒體服務器回復的200 OK響應消息體，同時擴展A字段攜帶歷史文件的VKEKVersion和VKEK，用于客戶端對加密視頻流解密播放，格式為“A＝VKEK: <空格>”，其中encryptedVKEK為用用戶公鑰加密VKEK的結果，根據(jù)錄像時間段中的VKEK 數(shù)量，可攜帶多個VKEKVersion和VKEK 密文，完成與媒體流接收者的INVITE會話建立過程。
- l) 12:具有安全功能的SIP服務器收到具有安全功能的媒體服務器返回的200 OK響應后，向具有安全功能的媒體服務器發(fā)送ACK 請求，請求中不攜帶消息體，完成與具有安全功能的媒體服務器的INVITE會話建立過程。
- m) 13:媒體流發(fā)送者在文件回放結束后發(fā)送會話內(nèi)MESSAGE消息，通知具有安全功能的SIP 服務器下載已結束。
- n) 14:具有安全功能的SIP服務器收到MESSAGE消息后回復200 OK響應，進行鏈路斷開過程。
- o) 15:具有安全功能的SIP服務器向媒體流接收者發(fā)送BYE 消息，斷開消息7、8、11建立的同媒體流接收者的INVITE會話。
- p) 16:媒體流接收者收到BYE 消息后回復200 OK響應，會話斷開。
- q) 17:具有安全功能的SIP 服務器向具有安全功能的媒體服務器發(fā)送BYE 消息，斷開消息9、10、12建立的同具有安全功能的媒體服務器的INVITE會話。
- r) 18:具有安全功能的媒體服務器收到BYE 消息后回復200 OK響應，會話斷開。
- s) 19:具有安全功能的SIP服務器向具有安全功能的媒體服務器發(fā)送BYE 消息，斷開消息1、2、5建立的同具有安全功能的媒體服務器的INVITE會話。
- t) 20::具有安全功能的媒體服務器收到BYE 消息后回復200 OK響應，會話斷開。
- u) 21:具有安全功能的SIP服務器向媒體流發(fā)送者發(fā)送BYE 消息，斷開消息3、4、6建立的同媒體流發(fā)送者的INVITE會話。
- v) 22:媒體流發(fā)送者收到BYE 消息后回復200 OK響應，會話斷開。
C.6.8.4 協(xié)議接口協(xié)議接口應符合下列要求: - a) SIP 消息頭域(如TO，FROM，Cseq，Call-ID，MaxForwards，Via等)的詳細定義符合相關SIP消息的RFC 文檔的規(guī)定。
- b) 消息頭域Allow 字段應支持INVITE，ACK，INFO，CANCEL，BYE，OPTIONS，MESSAGE方法，不排除支持其他SIP和SIP擴展方法。
- c) 消息頭Content type字段為Content type:application/SDP。
- d) 歷史媒體下載流程中攜帶消息體的請求和響應的消息體應采用SDP 協(xié)議格式定義。有關SDP的詳細描述見RFC4566。
- e) SDP文本信息包括:會話名稱和意圖，會話持續(xù)時間，構成會話的媒體，有關接收媒體的信息(地址等)。INVITE 請求以時間段方式獲取歷史圖像。
- f) 定位歷史媒體數(shù)據(jù)的信息在SDP 協(xié)議格式的消息體中攜帶，應包含設備名和時間段信息，規(guī)定如下:
- 媒體流接收者應在SDP協(xié)議格式的消息體中包括ｕ行(見RFC4566的5.5)，ｕ行表明視頻文件的URI；
- 媒體流接收者應在SDP 協(xié)議格式的消息體中包括ｔ行(見RFC4566的5.9)，ｔ行的開始時間和結束時間組成檢索歷史媒體數(shù)據(jù)的時間段信息。
C.7 數(shù)字證書服務數(shù)字證書服務協(xié)議應遵循GM/T0014-2012中5.4 以及5.6的規(guī)定。
總結
以上是生活随笔為你收集整理的GB35114—⑤、附 录C的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： linux 开机密码忘了,linux系统
- 下一篇： 艾诺novo7极光版 使用心得