kurento 6.14.0文档翻译第九章 编写Kurento应用程序

目录

         编写Kurento应用程序

         全局架构

                   通讯客户端，服务器和Kurento

1. 媒体协商阶段（信令）
2. 媒体交换阶段

使用实时的WebRTC应用

媒体平面

9.1全局架构

可以按照网络的架构原理使用Kurento，即创建一个基于kurento的多媒体应用，与使用任何流行的Web开发框架创建Web应用程序类似的体验。

在最高抽象级别上，Web应用程序的体系结构由三个不同的层组成：

1. 表示层（客户端）：在这里，我们可以找到负责与最终用户进行交互的所有应用程序代码，以便以全面的方式表示信息。这经常是在HTML页面使用javascript代码。
2. 应用逻辑（服务端）：该层负责实现应用程序执行的特定功能.
3. 服务层（服务或互联网端）：这层通过应用程序的逻辑提供像数据库，通信，加密等功能。这些服务可以与应用程序托管在同一服务器上逻辑，或者可以由外部各方提供

遵循这种并行性，使用Kurento创建的多媒体应用程序也可以采用相同的架构来实现：

1. 表示层（客户端）：负责多媒体表示和多媒体捕获。它通常是基于客户端的特定内置功能，比如当创建一个基于浏览器的应用，这个表示层将使用html的<video>标签或者WebRTC javascript API.
2. 应用逻辑（服务端）：这层提供特定的多媒体逻辑，换句话说这层负责创建一个适当的管道（通过链接所需的媒体元素）应用中涉及的多媒体流将需要遍历.
3. 服务层:这层提供多媒体服务支持像媒体录制、媒体加密等应用逻辑，KMS（即Media Elements的特定Media Pipeline）负责这一层。

讨论的有趣之处在于与web开发一样，Kurento应用程序可以将表示层放在客户端，将服务层放在服务器。所有情况下的应用逻辑都可以位于任一侧，甚至可以分布在它们之间，下图表示了这个想法：

这意味着Kurento开发人员可以选择在客户端（包括使用合适的Kurento客户端或直接与kurento协议一起）包含创建其应用程序所需的特定媒体管道的代码，也可以将其放置在服务器端。

两种选择都是可以的，但是它们是不同的开发方式，话虽如此，需要注意的是，在Web开发人员中，通常倾向于尽可能简化客户端代码，将更多的逻辑放在服务上，重现这种开发经验是使用Kurento的最常用方法。

9.2 应用架构

Kurento作为大多数多媒体通信技术。使用两层（称为平面）构建，以抽象所有交互式通信系统中的关键功能：

1. 信令平面：这个系统的部分负责管理通信，这个模块提供媒体谈判，QoS参数化，呼叫建立，用户注册，用户保持等功能。被认为是信令平面的一部分。
2. 媒体平面：媒体传输，媒体加码、解码和媒体处理功能叫着媒体平面，负责处理媒体，区别来自语音处理和元信息（如音调，计费等）处理之间的电话区别。

下图显示了Kurento的高级体系结构的概念性表示：

图片的右侧显示了应用程序，该应用程序负责信令平面，并包含正在部署的特定多媒体应用程序的业务逻辑和连接器，它可以构建不同的程序语言像java、node.js、php、.net等，应要可以使用成熟的技术像HTTP、SIP Servlet、web服务，数据库链接，消息服务等。由于这个该平面提供对最终客户端常用的多媒体信令协议（例如SIP、RESTful、基于HTTP的原始格式、SOAP RMI CORRA或JMS）的访问，这些信令协议被应用程序的客户端用于命令媒体会话的创建并代表它们协商所需的特性。因此这是体系结构的一部分，与应用程序开发人员联系，因此，需要在设计时追求简单性和灵活性。

在左侧，我们有KMS它实现了媒体平面的能力提供访问低层级的媒体特性：媒体传输，媒体编码/解码，媒体转码、媒体混淆，媒体处理等，KMS必须要以最小延迟和最大的吞吐量管理多媒体流，因此KMS必须优化效率

9.2.1通讯客户端，服务器和Kurento

如下图所示，Kurento应用程序涉及三个主要模块之间的交互：

客户端应用：涉及客户端平台的本机多媒体功能以及特定的客户端应用程序逻辑，它可以使用专为客户端平台设计的Kurento客户端（例如Kurento JavaScript 客户）。

应用服务：涉及应用服务器和服务端应用逻辑，它可以使用专为服务端平台设计的Kurento（例如Kurento java 客户端，和kurento node.js）。

Kms:接收命令创建特别的多媒体能力（如：应用所需要的特定的管道适配器），这些模块之间维护的交互取决于每个应用程序的细节，但是，总的来说，对于大多数应用，可以简化为以下概念方案：

1. 媒体协商阶段（信令）

在第一阶段，客户端（计算机中的浏览器，移动应用程序等）向应用程序发出一条消息，请求某种多媒体功能。这个消息可以使用任何协议（HTTP、WebSocket、SIP等）例如该请求可以要求对给定视频片段进行可视化

当应用接收到请求，如果可以，它将执行特定的服务器端应用程序逻辑，可以包含认证方式，授权和帐户， CDR生成，消耗某种类型的Web服务等

之后，应用处理请求和根据开发人员编程的特定说明, 命令KMS实例化合适的媒体元素并将它们链接在合适的媒体管道中，当管道创建成功，KMS做出相应响应，并且

应用程序将成功的响应转发给客户端，向其展示如何以及在何处可以访问媒体服务。

 

在上述步骤中，实际上没有交换任何媒体数据，所有互动的目的都是就媒体交流的方式，方式，地点和时间进行协商。所以我们叫它媒体协商阶段，在此阶段仅涉及信令协议。

1. 媒体交换阶段

信令部份之后，一个新的阶段开始目的是进行实际的媒体交流，客户端使用在协商阶段收集的信息将媒体请求发送给Kurento媒体服务器

在上面提到的视频剪辑可视化示例之后，浏览器将发送一个GET请求到获取剪辑的KMS的IP地址和端口，以及HTTP响应包含媒体的信息将被接收。

接下来讨论这个简单的例子，有人可能想为什么这么复杂的方案只是为了播放视频。大多数常用方案是客户端发送一个请求到适当的视频URL并不需要任何协商，这个回答是直截了当的，kurento是为了媒体应用涉及复杂的媒体处理，所以我们需要去建立两段机制在媒体交换前启用协商。需要付出的代价是，简单的应用程序（例如仅下载视频的应用程序）也需要完成这些阶段。但是，这样做的好处是，在创建更多高级服务时，将保持相同的简单原理。例如我们想要添加增强现实或机器视觉功能到视频剪辑中，我们只需要在协商阶段创建合适的管道即可保存所需的媒体元素，之后，从客户的角度处理过的剪辑将像其他任何视频一样被接收。

9.2.2使用kurento实时WebRTC应用

客户通过SDP请求/应答协商传达其所需的媒体功能，因此kurento可以实例化适当的WebRTC端点并要求其根据自己的信息生成SDP应答功能和SDP请求，当获得SDP应答，它将交回给客户端，媒体交换可以开始。下图总结了不同模块之间的交互：

应用开发人员可以创建想要的管道在谈判阶段，所以实时的多媒体流根据应用需求进行相应处理。

根据这个例子，想象一下，您想创建一个WebRTC应用程序来记录从客户端接收到的媒体并对其进行扩充，以便在发现人脸时在其上方渲染一顶帽子。 下图示意性地显示了该管道，我们假设过滤器元素能够检测面部并添加帽子：

9.3媒体层面

从应用程序开发人员的角度，媒体元素像乐高积木：你只需要拿到应用中需要的元素并组装它们，接下来所需的拓扑，在Kurento行话，连接的媒体元素图叫着媒体管道，因此当创建一个管道，开发者需要确定使用的能力（媒体元素）和确定拓扑，媒体元素提供的与其他媒体元素（连接）连接的媒体

连接是通过在所有Kurento Client API上公开的connect原语控制的。

始终在充当源的元素中调用此原语，并按照以下方案将接收器元素作为参数：

sourceMediaElement.connect(sinkMediaElement)

例如，如果你想创建一个应用记录WebRTC媒体流到文件中，你需要两个媒体元素：WebRtcEndpoint 和 RecorderEndpoint，当一个客户端连接这个应用，你癣需要实例化两个媒体元素使得流通过WebRtcEndpoint(有能力接收WebRTC流)接收，它将被馈送到RecorderEndpoint（能够将媒体流记录到文件系统中）。最后，您将需要连接它们，以便将前者接收的流传输到后者：

WebRtcEndpoint.connect(RecorderEndpoint)

简化客户端中WebRTC流的处理，kurento提供一个工具叫着WebRtcPeer，不过标准的WebRTC API（(getUserMedia, RTCPeerConnection等）也可以用于连接WebRtcEndpoint有关更多信息，请访问“教程”部分（ps：第六章）