YDT 4478-2023家庭安防監(jiān)控設(shè)備聯(lián)網(wǎng)服務(wù)接入技術(shù)要求_第1頁
YDT 4478-2023家庭安防監(jiān)控設(shè)備聯(lián)網(wǎng)服務(wù)接入技術(shù)要求_第2頁
YDT 4478-2023家庭安防監(jiān)控設(shè)備聯(lián)網(wǎng)服務(wù)接入技術(shù)要求_第3頁
YDT 4478-2023家庭安防監(jiān)控設(shè)備聯(lián)網(wǎng)服務(wù)接入技術(shù)要求_第4頁
YDT 4478-2023家庭安防監(jiān)控設(shè)備聯(lián)網(wǎng)服務(wù)接入技術(shù)要求_第5頁
已閱讀5頁,還剩36頁未讀, 繼續(xù)免費(fèi)閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進(jìn)行舉報或認(rèn)領(lǐng)

文檔簡介

ICS35.100.40

CCSL79

YD

中華人民共和國通信行業(yè)標(biāo)準(zhǔn)

YD/TXXXX.4—[××××]

[代替YD/T]

家庭安防監(jiān)控設(shè)備聯(lián)網(wǎng)服務(wù)接入

技術(shù)要求

Technicalrequirementsofnetworkingserviceaccess

forhomesurveillancesystems

(送審稿)

[××××]-[××]-[××]發(fā)布[××××]-[××]-[××]實施

中華人民共和國工業(yè)和信息化部發(fā)布

YD/T×××××.4—××××

前言

本文件按照GB/T1.1-2020《標(biāo)準(zhǔn)化工作導(dǎo)則第1部分:標(biāo)準(zhǔn)化文件的結(jié)構(gòu)和起草規(guī)則》的規(guī)定起

草。

請注意本文件的某些內(nèi)容可能涉及專利。本文件的發(fā)布機(jī)構(gòu)不承擔(dān)識別專利的責(zé)任。

本文件由中國通信標(biāo)準(zhǔn)化協(xié)會提出并歸口。

本文件起草單位:中國移動通信集團(tuán)有限公司、中國信息通信研究院,華為技術(shù)有限公司、浙江大

華技術(shù)股份有限公司。

本文件主要起草人:程寶平、雷珺、吳楠、王建凱、張亞蘭、許寶亮、汪勝、王欣、徐樺、龐

帥。

II

YD/T×××××—××××

家庭安防監(jiān)控設(shè)備聯(lián)網(wǎng)服務(wù)接入技術(shù)要求

1范圍

本文件規(guī)范了家庭安防監(jiān)控設(shè)備聯(lián)網(wǎng)服務(wù)接入技術(shù)要求,包括但不限于家庭安防監(jiān)控設(shè)備與家庭

安防監(jiān)控業(yè)務(wù)平臺之間的在業(yè)務(wù)層、傳輸層的接口協(xié)議要求,以及設(shè)備與家庭安防監(jiān)控業(yè)務(wù)平臺中主

要模塊的接口功能。

本文件主要適用于指導(dǎo)基于互聯(lián)網(wǎng)的家庭安防監(jiān)控設(shè)備聯(lián)網(wǎng)接入能力的開發(fā),包括指導(dǎo)家庭安防

設(shè)備制造廠商正確設(shè)計、開發(fā)用于互聯(lián)網(wǎng)環(huán)境下的家庭安防監(jiān)控設(shè)備和家庭安防監(jiān)控業(yè)務(wù)平臺之間的

接入?yún)f(xié)議,以及與家庭安防監(jiān)控業(yè)務(wù)平臺中主要模塊的接口功能。

2規(guī)范性引用文件

下列文件中的內(nèi)容通過文中的規(guī)范性引用而構(gòu)成本文件必不可少的條款。其中,注日期的引用文

件,僅該日期對應(yīng)的版本適用于本文件;不注日期的引用文件,其最新版本(包括所有的修改單)適

用于本文件。

GA/T1400.4-2017公安視頻圖像信息應(yīng)用系統(tǒng)第4部分:接口協(xié)議要求

IETFRFC2818安全超文本傳輸協(xié)議(HTTPOverTLS)

IETFRFC3711安全實時傳輸協(xié)議(TheSecureReal-timeTransportProtocol-SRTP)

IETFRFC6455允許Web應(yīng)用程序與服務(wù)器進(jìn)行雙向通信的協(xié)議(TheWebSocketProtocol)

IETFRFC7230超文本傳輸協(xié)議-HTTP/1.1:消息(HypertextTransferProtocol-HTTP/1.1:Message

SyntaxandRouting)

3術(shù)語和定義

下列術(shù)語和定義適用于本文件。

3.1家庭安防監(jiān)控業(yè)務(wù)平臺homesurveillanceplatform

運(yùn)行在云端的家庭安防監(jiān)控業(yè)務(wù)平臺,其包含各種類型的子服務(wù)、通信協(xié)議及API接口,支持多

形態(tài)智能監(jiān)控設(shè)備的接入,實時媒體流推送、錄像切片上傳及其它功能。

3.2家庭安防監(jiān)控設(shè)備homesurveillancedevice

安裝在客戶現(xiàn)場,具有與家庭安防監(jiān)控業(yè)務(wù)平臺通信能力的視頻設(shè)備,如攝像頭,門鈴,音箱

等,通過“開放協(xié)議”接入平臺,并接受平臺的管理。

4縮略語

1

YD/T×××××—××××

下列縮略語適用于本文件。

P2P:點(diǎn)對點(diǎn)(Peer-to-Peer)

RPC:遠(yuǎn)程過程調(diào)用(RemoteProcedureCall)

SRTP:安全實時傳輸協(xié)議(TheSecureReal-timeTransportProtocol)

TCP:傳輸控制協(xié)議(TransmissionControlProtocol)

TLCP:傳輸層密碼協(xié)議(TransportLayerCryptographyProtocol)

TLS:傳輸層安全協(xié)議(TransportLayerSecurity)

UDP:用戶數(shù)據(jù)報協(xié)議(UserDatagramProtocol)

WS:允許Web應(yīng)用程序與服務(wù)器進(jìn)行雙向通信的協(xié)議(WebSocket)

WSS:WebSocket安全協(xié)議(WebSocketSecure)

5概述

本接入?yún)f(xié)議規(guī)范為家庭網(wǎng)絡(luò)中的智能監(jiān)控設(shè)備與部署在互聯(lián)網(wǎng)中的平臺提供一套完整的接入準(zhǔn)

則,實現(xiàn)基于互聯(lián)網(wǎng)的家庭安防監(jiān)控系統(tǒng)。通過部署在互聯(lián)網(wǎng)中的家庭安防監(jiān)控業(yè)務(wù)平臺不僅可以向

家庭用戶提供遠(yuǎn)程實時監(jiān)控、視頻云端存儲、錄像回看等功能,還可以結(jié)合人工智能技術(shù)實現(xiàn)物體檢

測、識別等增值服務(wù)。本接入?yún)f(xié)議規(guī)范突破傳統(tǒng)家庭安防監(jiān)控系統(tǒng)的應(yīng)用邊界,創(chuàng)新并實現(xiàn)眾多家庭

安防監(jiān)控應(yīng)用場景,如老幼看護(hù)、智能門禁等。

6總體功能結(jié)構(gòu)

家庭安防設(shè)備聯(lián)網(wǎng)接入結(jié)構(gòu)見圖1,包括監(jiān)控設(shè)備(本文件中簡稱“設(shè)備”)和家庭安防監(jiān)控業(yè)

務(wù)平臺(本文件中簡稱“平臺”)。智能監(jiān)控設(shè)備通過接入?yún)f(xié)議規(guī)范接入家庭安防監(jiān)控業(yè)務(wù)平臺,實

現(xiàn)平臺對設(shè)備的調(diào)度、管理、狀態(tài)查詢、云臺控制、告警上報、媒體直播、視頻存儲、錄像回放等功

能。平臺內(nèi)部主要包括三個功能實體:控制信令服務(wù),媒體服務(wù)和錄像服務(wù)。

——控制信令服務(wù):主要負(fù)責(zé)設(shè)備通信中的控制信令部分,設(shè)備通過調(diào)度服務(wù)接口(Vs)和設(shè)備

管理接口(Vd)接入平臺;

——媒體服務(wù):主要負(fù)責(zé)設(shè)備的流媒體推送、轉(zhuǎn)碼、分發(fā)等功能,設(shè)備通過媒體服務(wù)接口(Vm)

接入平臺;

——錄像服務(wù):主要負(fù)責(zé)設(shè)備的錄像切片上傳、存儲、回放等等功能,設(shè)備通過錄像服務(wù)接口

(Vr)接入平臺。

2

YD/T×××××—××××

家庭安防監(jiān)控業(yè)務(wù)平臺

控制信令服務(wù)

Vs

調(diào)度服務(wù)

Vd

設(shè)備管理

設(shè)

媒體服務(wù)

媒體直播

Vm

錄像服務(wù)

視頻存儲

Vr

圖1家庭安防監(jiān)控設(shè)備聯(lián)網(wǎng)服務(wù)接入結(jié)構(gòu)圖

7接口協(xié)議規(guī)范

7.1協(xié)議結(jié)構(gòu)

設(shè)備接入的協(xié)議棧包括傳輸層協(xié)議、業(yè)務(wù)層協(xié)議見圖2。本協(xié)議棧自下而上定義了網(wǎng)絡(luò)傳輸、業(yè)

務(wù)服務(wù),以保障信令和數(shù)據(jù)的可達(dá)性及安全性。各個協(xié)議層要求如下:

——傳輸層采用標(biāo)準(zhǔn)的TCP/UDP協(xié)議進(jìn)行傳輸;

——業(yè)務(wù)層將規(guī)定設(shè)備與平臺之間各交互接口、字段內(nèi)容及交互流程,對信令交互采用

HTTPS+JSON和WebSocket+JSON協(xié)議,對數(shù)據(jù)媒體傳輸采用SRT和HTTP協(xié)議。業(yè)務(wù)層通過接入模

塊對設(shè)備接入進(jìn)行安全認(rèn)證及訪問控制,其中安全認(rèn)證需支持對設(shè)備進(jìn)行身份驗證、防暴力攻擊、防

重放攻擊等,確保只有認(rèn)證成功的設(shè)備才能接入到平臺,訪問控制功能應(yīng)能確保APP只能查看與其綁

定的設(shè)備,保證數(shù)據(jù)的安全性。

3

YD/T×××××—××××

VsVdVrVm接入

HTTPWebSocketHTTP

業(yè)務(wù)層

TLS/TLCP

SRTP

TCP/UDP

傳輸層

IP

圖2接入?yún)f(xié)議棧

7.2接口分類

7.2.1調(diào)度服務(wù)接口Vs

設(shè)備上線后被要求向平臺發(fā)起接入請求,平臺接收請求后向設(shè)備發(fā)送接入指令,設(shè)備根據(jù)指令內(nèi)

容連接到指定的信令服務(wù)器。平臺通過該接口實現(xiàn)設(shè)備在多機(jī)房之間的設(shè)備調(diào)度和信令接入。Vs接口

采用HTTPS+JSON協(xié)議。

7.2.2設(shè)備管理接口Vd

定義設(shè)備的控制信令,包括設(shè)備管理、狀態(tài)查詢、設(shè)備控制、狀態(tài)訂閱、直播、云臺控制、告警

上報、對講等功能。Vd接口采用WebSocket+JSON協(xié)議,應(yīng)符合IETFRFC6455的規(guī)定。

7.2.3媒體直播接口Vm

該接口用于媒體直播數(shù)據(jù)的傳輸。平臺接收到用戶發(fā)起的媒體直播請求后,發(fā)送指令至設(shè)備要求

打開該接口。Vm接口采用基于UDP的SRTP協(xié)議,應(yīng)符合IETFRFC3711的規(guī)定。

7.2.4視頻錄像接口Vr

定義錄像業(yè)務(wù),包括錄像的分片存儲分配、錄像內(nèi)容上傳、錄像元數(shù)據(jù)上傳、回看等功能。Vr接

口采用HTTPS+JSON協(xié)議,應(yīng)符合IETFRFC2818的規(guī)定。

7.3接口消息描述

HTTPS+JSON類接口消息描述定義見表1。其中,方向項列出該消息的發(fā)送方向從設(shè)備到平臺還

是從平臺到設(shè)備;請求消息體包括請求方法、請求URL、請求消息頭和請求內(nèi)容;響應(yīng)消息體包括返

回狀態(tài)碼,響應(yīng)消息頭和響應(yīng)消息內(nèi)容。

表1HTTPS+JSON接口消息描述

協(xié)議類型HTTPS+JSON

方向GET/POST

請求消息體自定義

響應(yīng)消息體自定義

4

YD/T×××××—××××

WebSocket+JSON類接口描述定義見表2。其中,請求名稱表示該消息的主要作用;消息類型可

以是RemoteProcedureCall(RPC)類型或Event類型(見章節(jié)9.2.1);方向項列出該消息發(fā)送方向從

設(shè)備到平臺還是從平臺到設(shè)備;請求消息體包含具體的請求參數(shù);響應(yīng)消息體包括返回狀態(tài)碼和響應(yīng)

消息內(nèi)容。

表2Websocket+JSON接口消息描述

請求名稱自定義

消息類型RPC/EVENT

方向設(shè)備至平臺/平臺至設(shè)備

請求消息體自定義

響應(yīng)消息體自定義

7.4接入要求

接入層接口交互信息可使用REST架構(gòu)下的資源,使用URI唯一標(biāo)識。本層接口主要是實現(xiàn)對接

入設(shè)備的安全認(rèn)證及訪問控制,可使用HTTP協(xié)議進(jìn)行接口層訪問。對HTTP請求頭域中應(yīng)至少擴(kuò)展

增加<Mac-Identity>,攜帶請求者的MAC地址(Mac-ID)等信息,用于標(biāo)識請求者。另外,為了確保安

全接入認(rèn)證,設(shè)備端至少支持一種加密算法。參見ITU-TH.626和GB/T1400.4-2017《公安視頻圖像

信息應(yīng)用系統(tǒng)》。

安全認(rèn)證要求:設(shè)備與平臺建立連接過程中,要求設(shè)備與平臺之間協(xié)商加密算法并生成密鑰。設(shè)

備與平臺建立連接后,平臺根據(jù)設(shè)備MAC-ID給對應(yīng)設(shè)備分配唯一的token。注意,token的有效時長

可以根據(jù)業(yè)務(wù)應(yīng)用中實際情況進(jìn)行設(shè)定。設(shè)備與平臺之間的信令交互都需要攜帶token以驗證設(shè)備的

合法身份。而且在請求消息中,HTTP消息頭參數(shù)需要攜帶時間戳和隨機(jī)nonce值。設(shè)備或者平臺在

發(fā)送消息前,需要分別計算HTTP消息頭和消息體的內(nèi)容得到MD5,并使用密鑰對應(yīng)得到的MD5進(jìn)

行加密,再把加密后的值填入HTTP消息頭后發(fā)送。接收端收到消息后,首先使用密鑰對HTTP消息

頭中的密文進(jìn)行解密得到MD5,然后通過本地計算得到消息中HTTP消息頭和消息體的MD5。將計

算得到的MD5與解密后的MD5進(jìn)行對比,如果對比結(jié)果一致則認(rèn)為消息中數(shù)據(jù)安全;反之則丟棄該

消息。

訪問控制要求:確認(rèn)消息中數(shù)據(jù)安全后,需要檢查時間戳與當(dāng)前時間是否相近,以及檢查隨機(jī)值

nonce是否重復(fù)。如果時間戳與本地時間相近或nonce值重復(fù),則是該消息將被認(rèn)為是重放消息,丟棄

該消息。

8網(wǎng)絡(luò)傳輸層接口定義

網(wǎng)絡(luò)傳輸層的接口應(yīng)支持SRT/UDP、TLS/TCP和HTTP/TLS傳輸協(xié)議接口。接口交互連接方式應(yīng)

支持HTTP長連接和短連接,實現(xiàn)機(jī)制應(yīng)符合IETFRFC7230中的相關(guān)規(guī)定。

9業(yè)務(wù)層接口規(guī)范

9.1調(diào)度服務(wù)接口Vs

9.1.1總體要求

設(shè)備管理接口Vs定義接入設(shè)備的服務(wù)調(diào)度工作,實現(xiàn)多機(jī)房的設(shè)備調(diào)度和信令接入。Vs接口采

用HTTPS+JSON協(xié)議。

9.1.2調(diào)度服務(wù)接口規(guī)范

5

YD/T×××××—××××

調(diào)度服務(wù)流程

平臺

設(shè)備調(diào)度服務(wù)設(shè)備管理

請求:設(shè)備接入視頻存儲

視頻存儲

響應(yīng):信令服務(wù)器地址、P2P服務(wù)器

地址、同步時間等信息

請求:發(fā)起連接

圖3調(diào)度服務(wù)流程

調(diào)度服務(wù)流程見圖3,步驟如下:

a)設(shè)備聯(lián)網(wǎng)成功后,通過預(yù)置地址,向平臺的調(diào)度服務(wù)模塊發(fā)送請求;

b)調(diào)度服務(wù)模塊根據(jù)請求報文中的設(shè)備Mac-ID及各服務(wù)器狀態(tài)返回信息內(nèi)容,包括信令服務(wù)

器信息、媒體直播服務(wù)器地址、P2P服務(wù)器信息、當(dāng)前系統(tǒng)時間戳;

c)設(shè)備先將接收到的系統(tǒng)時間戳跟設(shè)備系統(tǒng)時間戳比較,若相差較大(例如超過10s),則將

當(dāng)前系統(tǒng)時間重設(shè)置為接收到的時間;

d)設(shè)備根據(jù)平臺回包中信令服務(wù)器信息和P2P服務(wù)器信息,發(fā)起服務(wù)連接。

調(diào)度服務(wù)重連機(jī)制

由于網(wǎng)絡(luò)異常等原因可能導(dǎo)致設(shè)備與調(diào)度服務(wù)模塊通信失敗,需要設(shè)備進(jìn)行重連嘗試,為了防止

某一時刻大量設(shè)備訪問調(diào)度服務(wù)模塊,故設(shè)備重連需要進(jìn)行重連時間規(guī)避。重連時間應(yīng)采取以下原

則:

a)若N為重試次數(shù),當(dāng)N<=12時,設(shè)備隨機(jī)休眠0~N*5s后重試連接;

b)當(dāng)N>12時,設(shè)備休眠60s以及60s的整數(shù)倍后重試連接。一般建議當(dāng)N>15時,重新發(fā)起調(diào)

度。

重新調(diào)度要求

設(shè)備在以下情況需重新進(jìn)行服務(wù)調(diào)度請求,并調(diào)度交互成功后,重啟相關(guān)服務(wù)功能。

設(shè)備正常運(yùn)行,但因網(wǎng)絡(luò)異?;蛐帕罘?wù)器異常,導(dǎo)致設(shè)備與信令服務(wù)器不停重連,當(dāng)設(shè)備多次

重連信令服務(wù)器失?。僭O(shè)失敗次數(shù)超過15次),則設(shè)備端重新發(fā)起調(diào)度服務(wù)請求,其調(diào)度流程圖與

圖3相同。

6

YD/T×××××—××××

在平臺需要重新連接設(shè)備時,可以發(fā)出“重新調(diào)度”指令要求設(shè)備重新發(fā)起調(diào)度服務(wù)請求(注

意,此時調(diào)度服務(wù)流程是異步過程)。在調(diào)度服務(wù)流程成功前,其他工作線程正常工作,等調(diào)度服務(wù)

流程成功后,各服務(wù)器連接線程重啟。注意,重新調(diào)度請求不能用于初次調(diào)度申請。

平臺

設(shè)備調(diào)度服務(wù)設(shè)備管理

請求:重新調(diào)度

斷開連接

請求:設(shè)備接入(Mac-ID)

響應(yīng):信令服務(wù)器地址、P2P服務(wù)器

地址、同步時間等信息

請求:發(fā)起連接

圖4重新調(diào)度服務(wù)流程

重新調(diào)度服務(wù)流程見圖4,步驟如下:

a)管理平臺需要重新調(diào)度設(shè)備,則通過建立的長連接向設(shè)備發(fā)送“重新調(diào)度”指令;

b)設(shè)備收到指令后,主動斷開與平臺之間的現(xiàn)有連接;

c)設(shè)備向平臺的調(diào)度服務(wù)模塊發(fā)送請求;

d)-f)流程請參見章節(jié)調(diào)度服務(wù)流程b)-d)。

9.1.3調(diào)度服務(wù)接口消息

調(diào)度服務(wù)接口消息均為HTTPS+JSON,采用GET方式進(jìn)行。向服務(wù)器請求調(diào)度的URL格式如

下:https://<domain:port>/Vs/getServerAddr?macid=XXXXX,其中<domain:port>是設(shè)備第一次聯(lián)網(wǎng)接入

時需要連接的地址,macid即為設(shè)備的MAC地址。

接口消息定義見附錄表A.1。

9.2設(shè)備管理接口Vd

9.2.1總體要求

設(shè)備管理接口Vd定義設(shè)備的控制信令,包括設(shè)備管理、狀態(tài)查詢、設(shè)備控制、狀態(tài)訂閱、直

播、云臺控制、告警上報、對講等功能。Vd接口使用WebSocket+JSON協(xié)議,即底層基于TCP/IP的

WebSocket,應(yīng)用層基于JSON的自定義協(xié)議。由于WebSocket協(xié)議支持兩種框架,一種是非安全的

(WS),一種是安全的(WSS)。如果設(shè)備支持加密傳輸,則協(xié)議為WSS,否則為WS。

9.2.2設(shè)備管理消息類型

7

YD/T×××××—××××

RPC類型消息

RPC為一應(yīng)一答模式,通信中的兩個端點(diǎn)均可以發(fā)起RPC請求;在單一方向上,請求接收/回應(yīng)

方必須根據(jù)請求到達(dá)的順序來處理并回應(yīng)請求。RPC消息模板見表3,通信流程見圖5。

表3RPC消息模板

請求消息體{

"req":<請求名稱,字符串,必填>,

"params":<請求內(nèi)容,JSON對象,可選,RPC方法的參數(shù);當(dāng)方法沒有參數(shù)時,此域

不存在>,

"seq":<RPC消息的序列號,整數(shù),必填;每發(fā)送一次請求,+1>

}

返回狀態(tài)碼200:正常

400~499:用戶輸入錯誤

500~599:服務(wù)器異常

響應(yīng)消息內(nèi)容{//成功調(diào)用實例

"seq":<RPC的序列號,整數(shù),必填;與對應(yīng)的RPC請求的序列號一致>,

"resp":<應(yīng)答內(nèi)容,JSON對象,必選>

}

響應(yīng)消息內(nèi)容{//失敗調(diào)用示例

"seq":<RPC的序列號,整數(shù),必填;與對應(yīng)的RPC請求的序列號一致>,

"err":{

"code":<錯誤碼,整數(shù),必填>,

"msg":<錯誤信息,字符串,必填>

}

}

平臺

設(shè)備設(shè)備管理

Websocket連接建立

請求#1

設(shè)備發(fā)起

平臺響應(yīng)

響應(yīng)#1

請求#2

平臺發(fā)起

設(shè)備響應(yīng)

響應(yīng)#2

圖5RPC消息類型通信流程

8

YD/T×××××—××××

Event類型消息

事件通知無應(yīng)答模式;通信中的兩個端點(diǎn)均可以給對方發(fā)送事件通知。EVENT消息模板見表4,

通信流程見圖6。

表4Event消息形式

請求消息體{

"event":<請求名稱,字符串,必填>,

"params":<請求內(nèi)容,JSON對象,可選,參數(shù);當(dāng)沒有參數(shù)時,該域不存在>

}

平臺

設(shè)備設(shè)備管理

Websocket連接建立

VdVd

設(shè)備發(fā)起請求#1設(shè)備管理設(shè)備管理

請求#2平臺發(fā)起

圖6Event消息類型通信流程

9.2.3設(shè)備管理接口消息

總體要求

建立WebSocket連接時,WebSocketURL形式如下,wss://<domain:port>/Vd?login_code=<設(shè)備

ID>&login_passwd=<接入密碼>&hardware_model=<硬件型號>&firmware_model=<固件版本

號>&sdk=<SDK版本號>&reconnect=<接連是否重連>(optional)。字段內(nèi)容說明見表5。

9

YD/T×××××—××××

表5字段內(nèi)容說明

字段名稱字段類型字段內(nèi)容

login_code字符串必填:設(shè)備ID

login_passwd字符串必填:設(shè)備登陸密碼,如果URL中給定的設(shè)備ID與接入密碼與

平臺配置不符,登錄會失敗

hardware_model字符串必填:硬件型號,由廠家自定義,主要用于后期問題追蹤,以

及用于支持平臺遠(yuǎn)程固件升級

firmware_model字符串必填:固件版本號,由廠家自定義,主要用于后期問題追蹤,

以及用于支持平臺遠(yuǎn)程固件升級

sdk字符串選填:當(dāng)前使用的SDK的版本號,由SDK內(nèi)部填寫,沒有使用

SDK可以不提供此參數(shù),默認(rèn)值為空

reconnect整數(shù)選填:本次連接是否為重連。0表示本次連接是啟動后首次連

接,1表示本次連接是是連接斷開后重連,默認(rèn)為0

設(shè)備心跳上報

利用上報心跳方式定期向平臺報告工作狀態(tài),平臺以此作為設(shè)備仍然在線的依據(jù),同時設(shè)備通過

等待平臺的應(yīng)答來判斷與平臺的連接狀態(tài)。平臺在一定時間內(nèi)(建議30秒)內(nèi)沒有收到設(shè)備的信息則

認(rèn)為設(shè)備下線,為保障業(yè)務(wù)穩(wěn)定建議10秒左右上報一個心跳。

設(shè)備心跳上報的消息采用RPC消息類型。具體定義見附錄表B.1。

獲取服務(wù)器信息

使用該方法獲取平臺的相關(guān)地址信息。

獲取服務(wù)器信息的消息采用RPC消息類型。具體定義見附錄表B.2。

綁定信息上報

設(shè)備使用該方法向平臺發(fā)送用戶的綁定請求。

綁定信息上報消息采用EVENT消息類型。具體定義見附錄表B.3。

指定通道重啟

平臺使用該方法請求設(shè)備重啟指定通道。若設(shè)備不支持單獨(dú)重啟某個通道,可以實現(xiàn)為重啟設(shè)備

則該方法將重啟設(shè)備。

指定通道重啟的消息采用EVENT消息類型。具體定義見附錄表B.4。

設(shè)備重啟

平臺使用該方法請求重啟設(shè)備。

設(shè)備重啟的消息采用EVENT消息類型。具體定義見附錄表B.5。

設(shè)備重新接入

平臺使用該方法要求設(shè)備重新獲取平臺接入URL。首先,平臺下發(fā)設(shè)備重新接入消息。設(shè)備收到

后,重新發(fā)起服務(wù)調(diào)度請求,從平臺獲取URL并根據(jù)提示信息接入。

設(shè)備重新接入的消息采用EVENT消息類型。具體定義見附錄表B.6。

固件升級

平臺使用該方法通知設(shè)備升級固件,收到該事件后設(shè)備自行執(zhí)行下載升級工作。

固件升級消息采用EVENT消息類型。具體定義見附錄表B.7。

10

YD/T×××××—××××

查詢升級狀態(tài)

平臺使用該方法查詢設(shè)備當(dāng)前的升級狀態(tài),以及進(jìn)度百分比。

查詢升級狀態(tài)的消息采用RPC消息類型。具體定義見附錄表B.8。

0設(shè)置設(shè)備時間

平臺使用該方法設(shè)置設(shè)備的日歷時間。

設(shè)置設(shè)備時間采用RPC消息類型。具體定義見附錄表B.9。

1查詢設(shè)備時間

平臺使用該方法查詢設(shè)備當(dāng)前日歷時間。

查詢設(shè)備時間的消息采用RPC消息類型。具體定義見附錄表B.10。

2查詢設(shè)備運(yùn)行信息

平臺使用該方法查詢設(shè)備當(dāng)前運(yùn)行信息。

查詢設(shè)備運(yùn)行信息的消息采用RPC消息類型。具體定義見附錄表B.11。

3重置設(shè)備配置

平臺使用該方法對設(shè)備的配置進(jìn)行重置。設(shè)備收到該請求后,應(yīng)該將所有配置恢復(fù)到出廠狀態(tài)

(包括wifi配置),但不能斷開當(dāng)前網(wǎng)絡(luò)連接,并返回成功應(yīng)答。平臺稍后會再下發(fā)一個重啟指令將

設(shè)備重啟,默認(rèn)配置生效。

重置設(shè)備配置消息采用RPC消息類型。具體定義見附錄表B.12。

4視頻推送

平臺可以通過該方法請求設(shè)備端推送一條實時媒體流到指定URL。同一個通道同一時間只應(yīng)該推

送一條流。推流過程中,如果再次收到平臺的推流請求,如果推流ID號(stream_id)和正在推送的碼

流ID號(data_id)一致,則直接返回成功;否則,應(yīng)該停止當(dāng)前的推流然后根據(jù)新的參數(shù)重新推流。

通道一旦開始推流,則需在發(fā)送的設(shè)備心跳上報(Keepalive)消息中將通道(channel)的狀態(tài)改

為直播中,同時將其推流ID號置為請求中的stream_id參數(shù)。

視頻推送消息采用RPC消息類型。具體定義見附錄表B.13。

5視頻停止

平臺可以通過該方法請求設(shè)備端停止推送實時媒體流。

視頻停止消息采用RPC消息類型。具體定義見附錄表B.14。

6錄像云存啟動

平臺使用該方法請求設(shè)備啟動錄像并上傳錄像至云存儲。同一個通道同一時間只應(yīng)該進(jìn)行一個云

錄像會話。在云錄像進(jìn)行過程中,如果再次收到平臺的云錄像請求,且會話ID號(session_id)和正

在執(zhí)行的云錄像會話ID號(record_id)一致,則表示重復(fù)請求,直接返回成功;否則,應(yīng)該停止當(dāng)前

的云錄像會話,然后根據(jù)新的參數(shù)重新創(chuàng)建。通道一旦開始云錄像,則需在發(fā)送的Keepalive中將

channel的會話ID號置為請求中的session_id參數(shù)。

錄像云存啟動消息采用RPC消息類型。具體定義見附錄表B.15。

11

YD/T×××××—××××

7錄像云存停止

平臺使用該方法請求設(shè)備結(jié)束錄像。

錄像云存停止消息采用RPC消息類型。具體定義見附錄表B.16。

8報警通知

設(shè)備使用該方法向平臺上報告警事件的開始(和結(jié)束)通知。部分類型的告警事件分為開始/結(jié)束

兩個狀態(tài),設(shè)備應(yīng)該在狀態(tài)發(fā)生變化時,向平臺發(fā)送一次通知,并攜帶最新的狀態(tài)(因此,該類型告

警事件存在兩次通知,一次為開始通知,一次為結(jié)束通知)。部分類型的告警事件為單狀態(tài),該類型

告警事件發(fā)生時,設(shè)備只需即時向平臺發(fā)送一次通知。

報警通知消息采用RPC消息類型。具體定義見附錄表B.17。

9云臺控制消息

平臺使用該方法操作設(shè)備的云臺。

云臺控制消息無需應(yīng)答,采用EVENT消息類型。具體定義見附錄表B.18。

0獲取設(shè)備預(yù)置點(diǎn)列表

平臺使用該命令獲取設(shè)備的預(yù)置點(diǎn)列表。

獲取設(shè)備預(yù)置點(diǎn)列表的消息采用RPC消息類型。具體定義見附錄表B.19。

1獲取設(shè)備配置

平臺使用該命令獲取設(shè)備的配置。

獲取設(shè)備配置的消息采用RPC消息類型。具體定義見附錄表B.20。

2設(shè)置設(shè)備配置

平臺使用該命令遠(yuǎn)程設(shè)置設(shè)備的配置,參數(shù)中只需要包含修改的配置,不需要修改的配置不需要

包含。

設(shè)置設(shè)備配置消息采用RPC消息類型。具體定義見附錄表B.21。

3截圖消息

平臺使用該方法控制設(shè)備截取當(dāng)前的視頻畫面。設(shè)備完成截圖圖片上傳成功后,返回應(yīng)答。平臺

收到應(yīng)答時,相應(yīng)的截圖圖片已經(jīng)上傳的服務(wù)器。

截圖消息采用RPC消息類型。具體定義見附錄表B.22。

4啟動設(shè)備播放

平臺使用該命令啟動設(shè)備播放視頻。

啟動設(shè)備播放的消息無需設(shè)備應(yīng)答,采用EVENT消息類型。具體定義見附錄表B.23。

5控制設(shè)備播放

平臺使用該命令控制設(shè)備播放視頻。

控制設(shè)備播放的消息無需設(shè)備應(yīng)答,采用EVENT消息類型。具體定義見附錄表B.24。

6查詢設(shè)備播放狀態(tài)

12

YD/T×××××—××××

平臺使用該命令查詢設(shè)備播放狀態(tài)。

查詢設(shè)備播放狀態(tài)的消息采用RPC消息類型。具體定義見附錄表B.25。

7休眠控制

平臺使用該方法阻止設(shè)備(及指定通道)在指定時間內(nèi)休眠,或者喚醒設(shè)備(及指定通道)當(dāng)前

所有休眠的部件。

設(shè)備收到此指令后,應(yīng)該在指定的過期時間內(nèi),保證設(shè)備(及指定通道)能夠完全正常上電工

作。

休眠控制采用RPC消息類型。具體定義見附錄表B.26。

8電量變化上報

設(shè)備使用該方法向平臺上報當(dāng)前的電量,一般電量百分比變化時可以發(fā)送該通知事件。

電量變化上報的消息采用EVENT消息類型。具體定義見附錄表B.27。

9獲取設(shè)備能力集

平臺使用該命令獲取設(shè)備的能力集。

獲取設(shè)備能力集的消息采用RPC消息類型。具體定義見附錄表B.28。

0上傳設(shè)備日志

平臺使用該命令控制設(shè)備上傳相關(guān)本地日志,供調(diào)試分析使用。設(shè)備收到該指令后,通過異步方

式將指定時間范圍日志上傳到相應(yīng)的URL。

若指定范圍的日志已經(jīng)滾動刪除,則使用盡力原則上傳剩余的日志。若指定范圍沒有任何日志記

錄,應(yīng)上傳一個長度為0的日志文件。

日志文件通過PUT方法上傳。

上傳設(shè)備日志的消息采用RPC消息類型。具體定義見附錄表B.29。

1設(shè)備日志上傳完成消息

設(shè)備使用該方法通知平臺日志文件上傳完成。

設(shè)備日志上傳的消息無需平臺應(yīng)答,采用EVENT消息類型。定義見附錄表B.30。

2獲取設(shè)備SD卡狀態(tài)

平臺使用該命令獲取設(shè)備上SD卡狀態(tài)。

獲取設(shè)備SD卡狀態(tài)采用RPC消息類型。定義見附錄表B.31。

3格式化SD卡

平臺使用該方法對設(shè)備的SD卡進(jìn)行格式化。設(shè)備收到此命令后,應(yīng)該立即返回應(yīng)答,然后再啟

動格式化過程。

平臺將通過周期輪詢格式化結(jié)果。

格式化SD卡采用RPC消息類型。定義見附錄表B.32。

9.3媒體直播接口Vm

9.3.1媒體直播服務(wù)接口規(guī)范

13

YD/T×××××—××××

本接口只負(fù)責(zé)流媒體數(shù)據(jù)傳輸。關(guān)于數(shù)據(jù)傳輸?shù)目刂凭ㄟ^設(shè)備管理接口(Vd)傳達(dá)和實現(xiàn)。

9.3.2媒體直播服務(wù)接口消息

視頻直播服務(wù)流程

平臺

設(shè)備設(shè)備管理媒體直播用戶APP

直播請求

視頻推送

建立連接

上傳視頻

推送視頻

...

停止直播

視頻停止

斷開連接

圖7視頻直播服務(wù)流程

視頻直播服務(wù)流程見圖7,步驟如下:

a)用戶通過APP查看設(shè)備的直播視頻;

b)平臺收到APP的直播請求后,向設(shè)備發(fā)送“視頻推送”指令;

c)設(shè)備利用與平臺建立連接時接收到的“媒體直播服務(wù)器地址”,向媒體直播服務(wù)器發(fā)起連接;

d)連接建立后,設(shè)備通過SRT協(xié)議向媒體直播服務(wù)發(fā)送實時視頻流,媒體直播服務(wù)把視頻流推

送到用戶APP;

e)用戶APP關(guān)閉視頻直播;

f)平臺收到指令后,向設(shè)備發(fā)送“視頻停止”指令;

g)設(shè)備收到指令后,停止向媒體直播服務(wù)推送實時視頻流,并斷開連接。

視頻直播開始

平臺通過Vd接口將“視頻推送”的指令發(fā)給設(shè)備。設(shè)備接收到指令后,通過SRT協(xié)議上傳流媒

體到指令中規(guī)定的URL地址。關(guān)于視頻推送消息請見章節(jié)3.

視頻直播停止

平臺通過Vd接口將“視頻停止”的指令發(fā)給設(shè)備。設(shè)備接收到指令后,通過SRT協(xié)議控制停止

上傳流媒體。關(guān)于視頻停止消息請見章節(jié)4.

14

YD/T×××××—××××

9.4視頻錄像接口Vr

錄像服務(wù)接口Vr實現(xiàn)錄像的分片存儲分配、錄像內(nèi)容上傳、錄像元數(shù)據(jù)上傳、回看等功能。設(shè)備

在Vd接口接收到“開始云端錄制”命令后,將視頻上傳到存儲設(shè)備;收到“停止云端錄制”后停止

上傳。上傳視頻分片對于不同的存儲設(shè)備有不同的協(xié)議,設(shè)備需要按照不同的存儲設(shè)備要求完成視頻

數(shù)據(jù)的上傳和存儲。錄像服務(wù)接口Vr采用HTTPS+JSON協(xié)議。

9.4.1視頻錄像接口規(guī)范

視頻錄像流程

平臺

設(shè)備錄像服務(wù)存儲設(shè)備

視頻分片

1.請求視頻文件上傳地址

2.上一視頻文件的元數(shù)據(jù)

返回視頻文件上傳地址

上傳視頻分片

圖8視頻存儲流程

視頻存儲流程見圖8,步驟如下:

a)設(shè)備準(zhǔn)備好一個視頻分片后,先通過HTTPS協(xié)議向平臺中錄像服務(wù)模塊請求視頻文件上傳的

地址,并上報上一條視頻分片的元數(shù)據(jù)(如果有上一視頻分片);

b)平臺返回上傳地址,記錄上一視頻分片的元數(shù)據(jù);

c)設(shè)備向存儲設(shè)備上傳視頻分片。

d)重復(fù)a)-c)流程。

異常處理

由于網(wǎng)絡(luò)異常等原因可能會導(dǎo)致分片上傳失敗,設(shè)備應(yīng)該盡力進(jìn)行多次重試。若最終重試無效,

應(yīng)該向直存服務(wù)發(fā)送失敗請求,表示分片上傳失敗。平臺將清理殘留信息。

合并確認(rèn)

在正常流程中,由于采用了兩階段提交策略,每個分片上傳需要調(diào)用Vr兩次(一次創(chuàng)建,一次保

存),開銷較大。考慮到錄像分片一般是連續(xù)上傳的情況,在直存服務(wù)的創(chuàng)建請求中,支持同時對上

15

YD/T×××××—××××

一次分片進(jìn)行確認(rèn),由此可減免保存請求。

9.4.2視頻錄像接口消息

創(chuàng)建視頻分片消息

視頻分片消息定義見附錄表C.1。

確認(rèn)視頻分片消息

確認(rèn)視頻分片消息定義見附錄表C.2。

取消視頻分片消息

取消視頻分片消息定義見附錄表C.3。

獲取服務(wù)器當(dāng)前日歷時間消息

獲取服務(wù)器當(dāng)前日歷時間消息定義見附錄表C.4。

上報統(tǒng)計數(shù)據(jù)消息

上報統(tǒng)計數(shù)據(jù)消息定義見附錄表C.5。

16

YD/T×××××—××××

附錄A

(資料性)

調(diào)度服務(wù)接口規(guī)范

A.1調(diào)度服務(wù)接口示例

表A.1調(diào)度服務(wù)接口示例

協(xié)議類型HTTPS+JSON

方向設(shè)備至平臺

請求方法GET

請求URLhttps://<domain:port>/Vs/getServerAddr?macid=XXXXX

請求消息頭{

"mac_id":<必填,字符串;標(biāo)記此設(shè)備的MAC地址,檢驗唯一性>

}

返回狀態(tài)碼:200:正常

400~499:用戶輸入錯誤

500~599:服務(wù)器異常

響應(yīng)消息內(nèi)容{//成功響應(yīng)

"PassDomain":"",//信令服務(wù)器地址

"P2p_passDomain":"",//P2P服務(wù)器地址

"TurnDomain":"",//turn服務(wù)器地址

"HibernationDomain":"",//休眠服務(wù)器地址

"PassPort":xxxx,//信令服務(wù)器ws接口(非加密接口)

"Secure_PassPort":xxxx,//信令服務(wù)器wss接口(若設(shè)備支持wss協(xié)議,且下發(fā)非0值)

"P2p_passPort":xxxx,//P2P接口

"TurnPort":xxxx,//turn服務(wù)器端口

"SyncTime":xxxxx//平臺當(dāng)前系統(tǒng)時間(單位為毫秒)

}

響應(yīng)消息內(nèi)容{//失敗響應(yīng)

"info":<字符串,必填:錯誤描述>

}

17

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

最新文檔

評論

0/150

提交評論