Kurento架构
2019獨角獸企業重金招聘Python工程師標準>>>
Kurento架構
Kurento和大多數的媒體通信技術一樣，它把所有的交互通信系統的關鍵功能抽象成兩層(或平臺)：
-
信令平臺： 負責系統通信管理部分，它的組成模塊提供的功能有媒體協商，QoS參數協商，呼叫建立，用戶注冊，用戶呈現等，都是信令層的功能。
-
媒體平臺： 功能包括媒體傳輸，媒體編碼/解碼和媒體處理，它關心的是媒體的處理。它和電話的區別在于聲音的處理以及媒體信息的處理，包括音調，響鈴等。
下圖顯示了Kurento的高級系統架構。
上圖的右邊是應用服務器端，它負責信令平臺，包含有業務邏輯和特定多媒體應用的連接。它可以由像Java, Node.js, PHP, Ruby, .NET等任何一種編程技術實現。應用服務端也可以使用成熟的技術，像HTTP，SIP Servlet, Web服務，數據庫連接，消息服務等。可以這樣認為，這一平臺給終端提供了多媒體信令協議的訪問接口，如SIP， RESTful，和原始HTTP格式，SOAP， RMI, CORBA或JMS。這些信令協議被用于應用程序客戶端，用來命令要求創建媒體會話，并協商各種行為的特性。因此，它是架構的一部分，用來和應用開發者交互。基于這個原因，它的設計必須簡單而靈活。
上圖的左邊Kurento媒體服務器，它實現了媒體平臺功能，用以提供底層媒體功能的訪問：媒體傳輸，媒體編碼/解碼，媒體轉碼，媒體混合，媒體處理等。Kurento媒體服務器必須具有以最小的延遲和最大的吞吐量管理媒體流的能力。因此，Kurento必須對效率進行優化。
Kurento APIs and interfaces
媒體平臺( Kurento媒體服務器 )和信令平臺(應用程序服務端)的能力是通過一系列API實現的，它提供了越來越多的抽象級別。
依據這個方式，不同API的角色可以通過下面的方式來總結分類：
-
Kurento 協議: 它是通過WebSocket網絡協議展現Kurento媒體服務器能力。
-
Kurento API: 它是kurento協議的對象實現。這個API可以通過引用(ids)來創建和管理媒體元素和管道。 可以使用大多數的編程語言或框架訪問Kurento API。
-
Kurento Java Client：它是一個Java SE層，它用來消費Kurento API，它通過一個基于Java POJO的簡單易用并模塊化表示媒體元素和媒體管道的方式暴露它的功能。這個API的抽象了Kurento內部協議運作中所有非直觀的復雜性，使得開發人員在創建應用程序時，不需要處理這些媒體情況。使用Kurento Java客戶端只需要請求對maven項目添加一個合適的依賴并下載對應的jar包到應用程序開發者的CLASSPATH。需要提醒的是，Kurento Java客戶端只是一個媒體平臺控制的API。換句話說，它是目標是暴露管理媒體對象的能力，它并沒有提供任何信令平臺的能力。
-
Kurento JavaScript Client：它是一個JavaScript層，用來消費Kurento API并將其能力暴露給JavaScript開發者。它可以用來創建node.js和瀏覽器的基本應用。在未來，會創建更多的Kurento客戶端并以同樣的模塊的方式提供給其它語言，如Python, C/C++, PHP等。
從架構的角度來說，應用程序開發人員唯一要關心的是如何使用Kurento客戶端或Kurento API直接創建他們的多媒體應用程序。 從頁面應用(使用Kurento JavaScript客戶端開發)， 桌面應用(使用Kurento Java客戶端開發)，分布式應用(使用Kurento協議開發) 為它的潛在應用場景打開了一個廣闊的空間。
Kurento 模塊
Kurento設計實現了一個插件化的框架。默認地，Kurento媒體服務器使用多個模塊，命名為kms-core, kms-elements 和 kms-filters。另外，Kurento媒體服務器還有一些內建模塊來提升其能力， 這些模塊分別是 kms-crowddetector, kms-pointerdetector, kms-chroma, and kms-platedetector。最后，Kurento媒體服務器還可以使用定制化模塊來擴展。
更多模塊請參考 Kurento Modules 頁面。
使用Kurento創建應用程序
Kurento可以按照 WWW 的架構原則使用。也就是說，可以使用創建網頁應用程序的經驗和框架來創建媒體應用。
在最高級的抽象層面上，網頁應用架構由三個不同的層構成:
-
表示層(客戶端): 在這一層上，我們可以找到所有負責終端用戶交互的應用程序代碼，因此，這些信息都要表示成用戶可以理解的方式。它通常由HTML頁面組成。
-
應用程序邏輯層(服務端): 這一層負責給應用程序執行的指定功能的實現。
-
服務層(服務端或網絡端): 這一層提供應用程序邏輯需要使用的能力，應用程序邏輯包括數據庫，通信，安全等。這些服務可以部署在同一臺服務器，也可以由外部提供。
類似的，使用Kurento創建的多媒體應用也是以同樣的架構實現:
-
表示層(客戶端): 負責媒體表示和媒體捕捉。它通常是基于客戶端特定的內建的能力。例如，我們可以創建一個基于瀏覽器的應用程序，它的表示層可以使用<video> HTML標簽或WebRTC JavaScript API。
-
應用程序邏輯: 這一層提供了指定的媒體邏輯。換句話說，這一層負責創建合適的管道(通過鏈接希望的媒體元素),它包括應用程序需要都遍歷到的媒體流。
-
服務層: 這一層提供了用來支持應用程序邏輯的媒體服務，包括媒體錄制，媒體加密等。Kurento媒體服務器( 如特定媒體元素組成的管道 )負責這一層。
這個討論有興趣的方面在于，對WWW開發來說，Kurento應用程序可以將表示層部署在客戶端， 把服務層部署在服務端。然而，應用邏輯層，在這兩種應用中，可以部署在這兩端或分布式服務端， 如下圖所示:
頁面和媒體應用的層級架構。使用Kurento(右邊)創建的應用程序和標準WWW應用(左邊)類似。兩種類型的應用程序都可以將應用程序邏輯層部署在客戶端或服務端。
這意味著Kurento開發者可以在客戶端(使用合適的Kurento客戶端或直接使用Kurento協議)通過請求應用程序來創建指定的媒體管道，也可以部署在服務端。
上述這兩個選擇都是可行的，但是它們代表了不同的開發風格。需要注意的是，WWW開發者通常傾向于維護盡可能簡單的客戶端，而將大多數的應用程序邏輯層部署在服務端。Kurento通常也會復用這種經驗而將媒體應用邏輯層部署服務端。因此，可以為你想要的語言使用Kurento客戶端來創建指定的媒體管道。
NOTE: 下面的章節是將Kurento的處理都部署在服務端，這是Kurento比較通用的方式。但也可以把媒體邏輯在客戶端使用 Kurento JavaScript Client實現。
客戶端，服務端和Kurento的通信
如上圖所示，Kurento應用程序的交互在主要的三個模塊之間:
-
客戶端應用程序: 它包括客戶端平臺原生的媒體能力加上指定的客戶端的應用程序邏輯層。它可以在客戶端平臺使用Kurento客戶端(例如，Kurento JavaScript客戶端)設計實現。
-
應用程序服務端: 它包括一個應用程序服務端和服務端的應用程序邏輯層。它可以在服務端平臺使用Kurento 客戶端(如Kurento Java Client for Java EE and Kurento JavaScript Client for Node.js)設計實現。
-
Kurento媒體服務器: 它接收命令，用來創建指定的媒體能力(如指定的管道以適應于特定應用的需要)。
保持這些模塊間的交互要視特定的應用程序而定。然而，通常來說，大多數的應用都可以精簡到如下的概念框架:
在架構模塊間的主要交互。主要的交互分為兩個階段: 協調和媒體交換。不同的箭頭和顏色都有不同的示意。紅色的是和Kurento媒體服務器有關，綠色是和應用程序相關。
1. 媒體協商階段 (信令)
如圖所示，在第一步上，一個客戶端(一個PC上的瀏覽器，或一個移動端應用等)提交給應用程序一個消息來請求某種媒體能力。這個消息可以使用任何協議(http, websocket, SIP等)實現。例如，這個請求可以是對給定視頻片斷的可視化。
當應用程序收到這個請求后，如果合適，它將交付給指定的服務端應用程序邏輯層，它包含身份驗證，授權和統計(AAA)，CDR生成，某些Web服務的消費等。
這之后，應用程序處理這個請求，并依據由開發者指定的程序，命令kurento媒體服務器實例化合適的媒體元素并組成合適的媒體管道。當管道創建成功后，Kurento媒體服務器會回應給應用程序，應用程序會再回應給客戶端。
上面的過程沒有實際的媒體數據的交換。所有的交互都是協商要交換什么，如何，在哪，什么時候的媒體。因此，我們可以稱之為協商階段。因此，這個階段只包含有信令協議。
2 . 媒體交換階段
上一階段之后，新的階段開始實現實際的媒體數據交換。在協商階段，客戶端使用信息收集向Kurento媒體服務器發送了媒體請求。正如上面提到的視頻截圖可視化示例中，瀏覽器將向Kurento媒體服務器的IP地址和端口發送一個GET請求，在Kurento媒體服務器上可以獲得這個截圖，然后，就可以收到這個媒體的HTTP響應。
下面的討論是和一個簡單的例子相關，有些人可能會奇怪，為什么如此復雜的主題只是為了播放一個視頻，在一些很常見的場景中，客戶端只需要對視頻的合適的URL發送一個請求就可以了，而不需要請求任何協商。答案很簡單，因為Kurento是設計為了包括復雜媒體處理的媒體應用程序的。答案很簡單，因為Kurento是設計為了包括復雜媒體處理的媒體應用程序的。這樣做的代價是，對于很簡單的應用，即便如下載一個視頻，也需要經過這兩個階段。
然后，它的優勢是在創建更高級的服務時，這套同樣簡單的邏輯一樣可行。例如，如果我們想對視頻截圖添加虛擬現實或計算機視覺功能，我們只需要在協商階段選擇需要的媒體元素就可以創建合適的管道來滿足需求。總之，從客戶端角度來看，處理過的截圖會和其它視頻一樣接收。
使用kurento實現實時WebRTC應用
Kurento可以在瀏覽器和Kurento媒體服務器間，通過使用WebRTC創建實時媒體會話。另外，Kurento媒體服務器可以被用作媒體代理，以實現不同客戶端間的通信，它們都通過Kurento設備做為中轉站。因此，Kurento媒體服務器可以用作會議橋(Multi-Conference Unit, MCU)，如用在機器到機器的通信系統，視頻呼叫系統等。
如下圖所示，客戶端通過SDP(Session Description Protocol)發請求來暴露其媒體能力。因此，應用程序可以實例化合適的WebRTC終端，并請求以獲得一個相應的SDP。當獲得SDP回答時，它就返回給客戶端。
應用程序開發人員可以在協商階段創建想要的管道，因此實時媒體流會依據應用需要被處理。 舉例來說，我們想創建一個WebRTC應用程序來錄制從客戶端收到的媒體流并判斷其中是否有需要尋找的人臉，并且找到人臉后就會給他戴上一頂帽子。這個管道的主體框架如下圖所示，其中我們假設濾鏡元素可以進行面部識別并添加一頂帽子。
一個WebRTC會話的示例管道。在協商階段，應用程序開發人員可以創建一個管道來提供想要的功能。例如，這個管道使用WebRtcEndpoint 來和客戶端通信，同時，它還連接有一個RecorderEndpoint 用來存儲收到的媒體流，對于一個增強現實濾鏡來說，它將媒體流返回給客戶端。結果是，終端用戶將收到它自己的圖像濾鏡(如添加帽子的頭像)并且流被紀錄到了存儲系統并可以為以后使用。
Kurento 設計原則
Kurento的設計基于下面的原則:
獨立的媒體和信令平臺：
信令和媒體是兩個獨立的平臺，Kurento設計成這樣是為了應用程序能獨立地進行媒體處理。
分布式的媒體和應用服務：
Kurento Media Server and applications can be collocated, scalated or distributed among different machines.
A single application can invoke the services of more than one Kurento Media Server. The opposite also applies, that is, a Kurento Media Server can attend the requests of more than one application.
** 適合于云處理方式 **
Kurento is suitable to be integrated into cloud environments to act as a PaaS (Platform as a Service) component.
** 媒體管道 **
Chaining Media Elements via Media Pipelines is an intuitive approach to challenge the complexity of multimedia processing.
** 應用程序開發 **
Developers do not need to be aware of internal Kurento Media Server complexities, all the applications can deployed in any technology or framework the developer like, from client to server. From browsers to cloud services.
** 端到端的通信能力 **
Kurento provides end-to-end communication capabilities so developers do not need to deal with the complexity of transporting, encoding/decoding and rendering media on client devices.
** 完全可處理的媒體流 **
Kurento enables not only interactive interpersonal communications (e.g. Skype-like with conversational call push/reception capabilities), but also human-to-machine (e.g. Video on Demand through real-time streaming) and machine-to-machine (e.g. remote video recording, multisensory data exchange) communications.
** 模塊化的媒體處理 **
Modularization achieved through media elements and pipelines allows defining the media processing functionality of an application through a “graph-oriented” language, where the application developer is able to create the desired logic by chaining the appropriate functionalities.
** 審查處理 **
Kurento is able to generate rich and detailed information for QoS monitoring, billing and auditing.
** IMS無縫集成 **
Kurento is designed to support seamless integration into the IMS infrastructure of Telephony Carriers.
** 透明媒體適配層 **
Kurento provides a transparent media adaptation layer to make the convergence among different devices having different requirements in terms of screen size, power consumption, transmission rate, etc. possible.
轉載于:https://my.oschina.net/997155658/blog/839895
總結
- 上一篇： 阿尔法狗要逆天！韩专家称其故意输李世石一
- 下一篇： 《算法设计手册》面试题解答 第三章：数据