Kurento應用開發指南(以Kurento 5.0爲模板) 之五：kurento架構

11. Kurento 架構

和大多數的媒體通訊技術同樣，Kurento把全部的交互通訊系統的關鍵功能抽象成兩層(或平臺):
?信令平臺
系統中負責通訊管理的部分，它的組成模塊提供的功能有媒體協商，QoS參數協商，呼叫創建，
用戶註冊，用戶呈現等，都是信令層的功能；
? Media Plane 媒體平臺
包括的功能包括媒體傳輸，媒體編碼/解碼和媒體處理，它關心的是媒體的處理。
它和電話的區別在於聲音的處理以及媒體信息的處理，包括音調，響鈴等。


下圖顯示了Kurento的高級系統架構。
 
Figure 11.1: Kurento 架構. 分紅信令平臺和媒體平臺
上圖的右邊是應用服務器端，它負責信令平臺，包含有業務邏輯和特定多媒體應用的鏈接。
它能夠由像Java, Node.js, PHP, Ruby, .NET等任何一種編程技術實現。
應用服務端也可使用成熟的技術，像HTTP，SIP Servlet, Web服務，數據庫鏈接，消息服務等。
能夠這樣認爲，這一平臺給終端提供了多媒體信令協議的訪問接口，如SIP， RESTful，
和原始HTTP格式，SOAP， RMI, CORBA或JMS。這些信令協議被用於應用程序客戶端，
用來命令要求建立媒體會話，並協商各類行爲的特性。所以，它是架構的一部分，
用來和應用開發者交互。基於這個緣由，它的設計必須簡單而靈活。


上圖的左邊Kurento媒體服務器，它實現了媒體平臺功能，用以提供底層媒體功能的訪問：
媒體傳輸，媒體編碼/解碼，媒體轉碼，媒體混合，媒體處理等。
Kurento媒體服務器必須具備以最小的延遲和最大的吞吐量管理媒體流的能力。
所以，Kurento必須對效率進行優化。

 

11.1 Kurento API和接口

媒體平臺(Kurento媒體服務器)和信令平臺(應用程序服務端)的能力是經過一系列API實現的，
它提供了愈來愈多的抽象級別。依據這個方式，不一樣API的角色能夠經過下面的方式來總結分類:
? Kurento 協議: 
它是將Kurento媒體服務器能力提供給WebSocket的網絡協議。
? Kurento API: 
它是kurento協議的對象實現。這個API能夠經過引用(ids)來建立和管理媒體元素和管道。
可使用大多數的編程語言或框架訪問Kurento API。


? Kurento Java 客戶端:
它是一個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協議開發).

 

11.2 Kurento 模塊

Kurento設計實現了一個插件化的框架。
默認地，Kurento媒體服務器使用多個模塊，命名爲kms-core, kms-elements和kms-filters。
另外，Kurento媒體服務器還有一些內建模塊來提高其能力，
這些模塊分別是kms-crowddetector, kms-pointerdetector, kms-chroma, and kms-platedetector。
最後，Kurento媒體服務器還可使用定製化模塊來擴展。
 
Kurento模塊架構，Kurento媒體服務器可使用內建的模塊(crowddetector, 
pointerdetector, chroma, platedetector)和定製模塊來擴展。



 

11.3 使用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實現。

 

11.4 客戶端，服務端和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是設計爲了包括複雜媒體處理的媒體應用程序的。
所以，咱們須要創建兩個階段的機制以使得在媒體交換以前有一個協商。
這樣作的代價是，對於很簡單的應用，即使以下載一個視頻，也須要通過這兩個階段。


而後，它的優點是在建立更高級的服務時，這套一樣簡單的邏輯同樣可行。
例如，若是咱們想對視頻截圖添加虛擬現實或計算機視覺功能，
咱們只須要在協商階段選擇須要的媒體元素就能夠建立合適的管道來知足需求。
總之，從客戶端角度來看，處理過的截圖會和其它視頻同樣接收。

 

11.5 使用kurento實現實時WebRTC應用

Kurento能夠在瀏覽器和Kurento媒體服務器間，經過使用WebRTC建立實時媒體會話。
另外，Kurento媒體服務器能夠被用做媒體代理，以實現不一樣客戶端間的通訊，
它們都經過Kurento設備作爲中轉站。所以，Kurento媒體服務器能夠用做會議橋(Multi-Conference Unit, MCU)，
如用在機器到機器的通訊系統，視頻呼叫系統等。
As shown in the picture, the client exposes its media capabilities through an SDP 
(Session Description Protocol) sent in a request. Hence, the application is able
to instantiate the appropriate WebRTC endpoint, and to require it to generate a response 
SDP based on its own capabilities and on the offered SDP. When the answer SDP is obtained, 
it is given back to the client and the media
以下圖所示，客戶端經過SDP(Session Description Protocol)發請求來暴露其媒體能力。
所以，應用程序能夠實例化合適的WebRTC終端，並請求以得到一個相應的SDP。
當得到SDP回答時，它就返回給客戶端。
 
Main interactions in a WebRTC session. Interactions taking place 
in a Real Time Communications (RTC) session. During the negotiation phase, 
a Session Description Protocol (SDP) message is exchanged offering the 
capabilities of the client. As a result, Kurento Media Server generates 
an SDP answer that can be used by the client for extablishing the media exchange.


應用程序開發人員能夠在協商階段建立想要的管道，所以實時媒體流會依據應用須要被處理。
舉例來講，咱們相建立一個WebRTC應用程序來錄製從客戶端收到的媒體流並判斷其中是否有須要尋找的人臉，
而且找到人臉後就會給他戴上一頂帽子。這個管道的主體框架以下圖所示，
其中咱們假設濾鏡元素能夠進行面部識別並添加一頂帽子。
 
Example pipeline for aWebRTC session. During the negotiation phase, 
the application developer can create a pipeline providing the desired specific functionality.
For example, this pipeline uses a WebRtcEndpoint for communicating with the client, 
which is connected to a RecorderEndpoint storing the received media streamd and to 
an augmented reality filter, which feeds its output media stream back to the client. 
As a result, the end user will receive its own image filtered (e.g. with a hat added onto her head) 
and the stream will be recorded and made available for further recovery into a repository (e.g. a file).
一個WebRTC會話的示例管道。在協商階段，應用程序開發人員能夠建立一個管道來提供想要的功能。
例如，這個管道使用WebRtcEndpoint 來和客戶端通訊，
同時，它還鏈接有一個RecorderEndpoint 用來存儲收到的媒體流，
對於一個加強現實濾鏡來講，它將媒體流返回給客戶端。
結果是，終端用戶將收到它本身的圖像濾鏡(如添加帽子的頭像)而且流被紀錄到了存儲系統並能夠爲之後使用。

 

11.6 Kurento 設計原則

Kurento的設計基於下面的原則:
Separate Media and Signaling Planes 
獨立的媒體和信令平臺
Signaling and Media are two separate planes and Kurento is designed 
so that applications can handle separately those facets of multimedia processing.
信令和媒體是兩個獨立的平臺，Kurento設計成這樣是爲了應用程序能獨立地進行媒體處理
Distribution of Media and Application Services 
分佈式的媒體和應用服務
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.


Suitable for the Cloud 
適合於雲處理方式
Kurento is suitable to be integrated into cloud environments to act as a PaaS
(Platform as a Service) component.


Media Pipelines 
媒體管道
Chaining Media Elements via Media Pipelines is an intuitive approach 
to challenge the complexity of multimedia processing.


Application development
應用程序開發
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.


End-to-end Communication Capability 
端到端的通訊能力
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.


Fully Processable Media Streams 
徹底可處理的媒體流
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.


Modular Processing of Media 
模塊化的媒體處理
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.


Auditable Processing
Kurento is able to generate rich and detailed information for QoS monitoring,billing and auditing.


Seamless IMS integration 
Kurento is designed to support seamless integration into the IMS infrastructure of Telephony Carriers.


Transparent Media Adaptation Layer 
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.