參考 kurento architecture

架構

信令部分 和 媒體部分

Kurento架構，信令和媒體層

• 信令層: 提供媒體協商能力、QoS參數化、呼叫建立、用戶注冊、用戶顯現等的一些模塊組成了信令層。（The parts of the system in charge of the management of communications, that is, the modules that provides functions for media negotiation, QoS parametrization, call establishment, user registration, user presence, etc. are conceived as forming part of the Signaling Plane.）
• 媒體層： 媒體支持、編解碼和媒體處理等組成了此層...（Functionalities such as media transport, media encoding/decoding and media processing make the Media Plane, which takes care of the handling of media. The distinction comes from the telephony differentiation between the handling of voice and the handling of meta-information such as tone, billing, etc.）

Kurento接口

• Kurento協議：websocket
• Kurento API：是從面向對象的角度使用kurento協議.
• Java 和 JS 客戶端： 簡化API使用， 分別可以在Java服務端、 NodeJS、瀏覽器里實現和KMS的交互

Kurento模塊

插件式的模塊， KMS默認使用模塊：kms-core, kms-elements, kms-filters。其他增強型的模塊如：kms-crowddetector, kms-pointerdetector, kms-chroma, 和 kms-platedetector。
用戶可通過自定義模塊擴展其功能。

模塊構架，可使用內置模塊擴展功能，也可開發自定義模塊

使用Kurento創建應用

• 展現層（客戶端）：負責媒體的展現和抓取
• 應用邏輯層：負責媒體業務邏輯。具體說， 這一層要通過控制KMS連接媒體組件Media Elements 創建恰當的媒體管道pipeline， 讓相關的媒體流從中通過
• 服務層：為了支持業務層， 負責媒體的處理，如媒體錄制、加密等，具體說就是KMS

可將展現層放在客戶端， 服務層放在服務端， 業務邏輯層放二者之一即可：

核心的兩部分交互：媒體協商和媒體交換

一般為了簡化客戶端，業務邏輯層放在服務端。當然也可以使用如 Kurento JavaScript Client將業務層放在客戶端。

客戶端、服務端及Kurento的交互

web和多媒體層架構

1. 媒體協商階段（信令）

如上圖所示，在第一階段，客戶端向應用服務請求某種媒體能力，此過程可使用任何協議（http, websocket, SIP等）。

當應用服務接到請求，可以執行其業務邏輯，可包括AAA：認證（Authentication）、授權（Authorization）和計費（Accounting）， CDR階段和web服務調用等

之后，應用服務端根據開發自定義的指令決定如何通過媒體組件連接來創建一個pipeline，一旦KMS創建成功pipeline，應用服務將成功消息發送給客戶端，告知怎樣以及去哪（How and Where）獲取媒體服務。

字啊以上的過程中都沒有媒體數據（media data）真正交換， 所有的交互都是在協商媒體交換的問題：什么、何時、何地、怎樣（whats hosts wheres and whens）。所以稱為協商階段， 顯然此階段之保護指定協議。

2. 媒體流交換階段

媒體協商過后， 真正專注于媒體數據的交換。客戶端使用在協商階段獲取的信息，向KMS獲取媒體數據。

使用Kurento做實時WebRTC應用

Kurento允許瀏覽器建通過WebRTC建立實時媒體會話。另外，可使用KMS作為不同客戶端間交互的媒體代理。所以KMS可以扮演會議橋接（conference bridge (Multi-Conference Unit, MCU)）、端到端通信系統（machine-to-machine）、視頻呼叫錄制系統等（ video call recording system）。

如下圖，客戶端通過SDP暴露自己的媒體嗯嗯管理，因此，應用服務能夠實例化恰當的WebRTC端點(endpoint)，請求KMS，KMS基于自身的和客戶端的媒體能力生成相應的SDP回應， 客戶端獲取到回應后開始媒體數據交換。總結為下圖：

在WebRTC會話中的主要交互

應用開發者可在媒體協商階段根據需要創建pipeline，如：創建一個WebRTC應用錄制客戶端音視頻，并且在識別到人臉時給戴上一個帽子：

pipeline示例

Kurento設計原則：

• 媒體和信令分離
• 媒體和應用服務可分布式水平擴展
• 適合于云 PaaS
• 媒體管道 Piplines
• 對應用開發友好：屏蔽了KMS的復雜性，可用任何平臺和語言
• End-to-End的交流能力：開發者不用處理媒體編解碼、傳輸和渲染等復制事宜
• 可全權處理的媒體流：不止普通軟件（如Skype）人與人交流，可實現人與機器、機器與機器之間的交流。
• 過程可監控：可為QoS監控、賬單、審計等生成豐富詳細的信息
• 無縫的IMS（IP Multimedia Subsystem）集成
• 透明的媒體適應層：使得不同設備（屏幕尺寸、耗電能力、傳輸速率等）的會聚成為可能