Kurento应用开发指南(以Kurento 6.0为模板) 之六：kurento架构
12.1 Kurento 架构
和大多数的多媒体通信技术方案一样，Kurento把交互通信系统中的所有关键功能抽象成两层(或叫平面):>>> 信令平面
系统中负责通信管理的部分，
它由提供媒体协商，QoS参数协商，呼叫建立，用户注册，用户呈现等功能的模块组成；
>>> 媒体平台
包括的功能包括媒体传输，媒体编码/解码和媒体处理，
它关心的是媒体的处理。
它和电话的区别在于声音的处理以及媒体信息的处理，包括音调，响铃等。
Figure 12.1: Kurento Architecture.
Kurento architecture follows the traditional separation between signaling and media planes.
上图的右边是应用服务器，
它负责信令平面，还包含有业务逻辑和特定多媒体应用的连接。
它可以由像Java, Node.js, PHP, Ruby, .NET等任何一种编程技术实现。
应用服务端也可以使用成熟的技术，像HTTP，SIP Servlet, Web服务，数据库连接，消息服务等。
可以这样认为，这一平台给终端提供了多媒体信令协议的访问接口，如SIP， RESTful，
和原始HTTP格式，SOAP， RMI, CORBA或JMS。这些信令协议被用于应用程序客户端，
用来命令要求创建媒体会话，并协商各种行为的特性。因此，它是架构的一部分，
用来和应用开发者交互。基于这个原因，它的设计必须简单而灵活。
上图的左边Kurento媒体服务器，
它实现了媒体平台功能，用以提供底层媒体功能的访问：
媒体传输，媒体编码/解码，媒体转码，媒体混合，媒体处理等。
Kurento媒体服务器必须具有以最小的延迟和最大的吞吐量管理媒体流的能力。
因此，Kurento必须对效率进行优化。
12.1.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客户端开发)，
12.1.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)和定制模块来扩展。
Fig 12-2
12.1.3 使用Kurento创建应用程序
Kurento可以按照WWW的架构原则使用。也就是说，可以使用创建网页应用程序的经验和框架来创建媒体应用。在最高级的抽象层面上，网页应用架构由三个不同的层构成:
>>> 表示层(客户端):
在这一层上，我们可以找到所有负责终端用户交互的应用程序代码，
因此，这些信息都要表示成用户可以理解的方式。它通常由HTML页面组成。
>>> 应用程序逻辑层(服务端):
这一层负责给应用程序执行的指定功能的实现。
>>> 服务层(服务端或网络端):
这一层提供应用程序逻辑需要使用的能力，应用程序逻辑包括数据库，通信，安全等。
这些服务可以部署在同一台服务器，也可以由外部提供。
类似的，使用Kurento创建的多媒体应用也是以同样的架构实现:
>>> 表示层(客户端):
负责媒体表示和媒体捕捉。它通常是基于客户端特定的内建的能力。
例如，我们可以创建一个基于浏览器的应用程序，它的表示层可以使用<video> HTML标签或WebRTC JavaScript API。
>>> 应用程序逻辑:
这一层提供了指定的媒体逻辑。
换句话说，这一层负责创建合适的管道(通过链接希望的媒体元素),
它包括应用程序需要都遍历到的媒体流。
>>> 服务层:
这一层提供了用来支持应用程序逻辑的媒体服务，包括媒体录制，媒体加密等。
Kurento媒体服务器(如特定媒体元素组成的管道)负责这一层。
这个讨论有兴趣的方面在于，对WWW开发来说，Kurento应用程序可以将表示层部署在客户端，
把服务层部署在服务端。然而，应用逻辑层，在这两种应用中，可以部署在这两端或分布式服务端，
如下图所示:
Fig 12-3
页面和媒体应用的层级架构。
使用Kurento(右边)创建的应用程序和标准WWW应用(左边)类似。
两种类型的应用程序都可以将应用程序逻辑层部署在客户端或服务端。
这意味着Kurento开发者可以在客户端(使用合适的Kurento客户端或直接使用Kurento协议)
通过请求应用程序来创建指定的媒体管道，也可以部署在服务端。
上述这两个选择都是可行的，但是它们代表了不同的开发风格。需要注意的是，
WWW开发者通常倾向于维护尽可能简单的客户端，而将大多数的应用程序逻辑层部署在服务端。
Kurento通常也会复用这种经验而将媒体应用逻辑层部署服务端。
因此，可以为你想要的语言使用Kurento客户端来创建指定的媒体管道。
NOTE: 下面的章节是将Kurento的处理都部署在服务端，这是Kurento比较通用的方式。
但也可以把媒体逻辑在客户端使用 Kurento JavaScript Client实现。
12.1.4 客户端，服务端和Kurento的通信
如上图所示，Kurento应用程序的交互在主要的三个模块之间:>>> 客户端应用程序:
它包括客户端平台原生的媒体能力加上指定的客户端的应用程序逻辑层。
它可以在客户端平台使用Kurento客户端(例如，Kurento JavaScript客户端)设计实现。
>>> 应用程序服务端:
它包括一个应用程序服务端和服务端的应用程序逻辑层。
它可以在服务端平台使用Kurento 客户端(如Kurento Java Client for Java EE
and Kurento JavaScript Client for Node.js)设计实现。
>>> Kurento媒体服务器:
它接收命令，用来创建指定的媒体能力(如指定的管道以适应于特定应用的需要)。
保持这些模块间的交互要视特定的应用程序而定。然而，通常来说，大多数的应用都可以精简到如下的概念框架:
Fig 12-4 在架构模块间的主要交互。
主要的交互分为两个阶段:协调和媒体交换。
不同的箭头和颜色都有不同的示意。
红色的是和Kurento媒体服务器有关，绿色是和应用程序相关。
1. 媒体协商阶段 (信令)
如图所示，在第一步上，一个客户端(一个PC上的浏览器，或一个移动端应用等)
提交给应用程序一个消息来请求某种媒体能力。这个消息可以使用任何协议(http, websocket, SIP等)实现。
例如，这个请求可以是对给定视频片断的可视化。
当应用程序收到这个请求后，如果合适，它将交付给指定的服务端应用程序逻辑层，
它包含身份验证，授权和统计(AAA)，CDR生成，某些Web服务的消费等。
这之后，应用程序处理这个请求，并依据由开发者指定的程序，
命令kurento媒体服务器实例化合适的媒体元素并组成合适的媒体管道。
当管道创建成功后，Kurento媒体服务器会回应给应用程序，应用程序会再回应给客户端。
上面的过程没有实际的媒体数据的交换。所有的交互都是协商要交换什么，
如何，在哪，什么时候的媒体。因此，我们可以称之为协商阶段。因此，这个阶段只包含有信令协议。
2. 媒体交换阶段
上一阶段之后，新的阶段开始实现实际的媒体数据交换。
在协商阶段，客户端使用信息收集向Kurento媒体服务器发送了媒体请求。
正如上面提到的视频截图可视化示例中，浏览器将向Kurento媒体服务器的IP地址和端口发送一个GET请求，
在Kurento媒体服务器上可以获得这个截图，然后，就可以收到这个媒体的HTTP响应。
下面的讨论是和一个简单的例子相关，有些人可能会奇怪，为什么如此复杂的主题只是为了播放一个视频，
在一些很常见的场景中，客户端只需要对视频的合适的URL发送一个请求就可以了，而不需要请求任何协商。
答案很简单，因为Kurento是设计为了包括复杂媒体处理的媒体应用程序的。
因此，我们需要建立两个阶段的机制以使得在媒体交换之前有一个协商。
这样做的代价是，对于很简单的应用，即便如下载一个视频，也需要经过这两个阶段。
然后，它的优势是在创建更高级的服务时，这套同样简单的逻辑一样可行。
例如，如果我们想对视频截图添加虚拟现实或计算机视觉功能，
我们只需要在协商阶段选择需要的媒体元素就可以创建合适的管道来满足需求。
总之，从客户端角度来看，处理过的截图会和其它视频一样接收。
12.1.5 使用kurento实现实时WebRTC应用
Kurento可以在浏览器和Kurento媒体服务器间，通过使用WebRTC创建实时媒体会话。另外，Kurento媒体服务器可以被用作媒体代理，以实现不同客户端间的通信，
它们都通过Kurento设备做为中转站。因此，Kurento媒体服务器可以用作会议桥(Multi-Conference Unit, MCU)，
如用在机器到机器的通信系统，视频呼叫系统等。
如下图所示，客户端通过SDP(Session Description Protocol)发请求来暴露其媒体能力。
因此，应用程序可以实例化合适的WebRTC终端，并请求以获得一个相应的SDP。
当获得SDP回答时，它就返回给客户端。
Fig 11-4
应用程序开发人员可以在协商阶段创建想要的管道，因此实时媒体流会依据应用需要被处理。
举例来说，我们相创建一个WebRTC应用程序来录制从客户端收到的媒体流并判断其中是否有需要寻找的人脸，
并且找到人脸后就会给他戴上一顶帽子。这个管道的主体框架如下图所示，
其中我们假设滤镜元素可以进行面部识别并添加一顶帽子。
Fig 11-6
一个WebRTC会话的示例管道。
在协商阶段，应用程序开发人员可以创建一个管道来提供想要的功能。
例如，这个管道使用WebRtcEndpoint 来和客户端通信，
同时，它还连接有一个RecorderEndpoint 用来存储收到的媒体流，
对于一个增强现实滤镜来说，它将媒体流返回给客户端。
结果是，终端用户将收到它自己的图像滤镜(如添加帽子的头像)并且流被纪录到了存储系统并可以为以后使用。
12.1.6 Kurento Design Principles
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.