WebRTC浏览器与基于SIP的会议系统之间的无缝交互外文翻译资料

英语原文共 7 页，剩余内容已隐藏，支付完成后下载完整资料

WebRTC浏览器与基于SIP的会议系统之间的无缝交互

Alessandro Amirante, Meetecho S.r.l.

Tobia Castaldi, Lorenzo Miniero, and Simon Pietro Romano, University of Napoli Federico II

摘要

近来，人们对将交互式多媒体功能集成到web应用程序中的兴趣日益浓厚，这导致了W3C WebRTC和IETF RTCWEB工作组的创建。这些团队共同定义应用程序编程接口和底层通信协议，以便在任何一对下一代web浏览器之间建立和管理可靠的通信路径。虽然正在进行的工作集中于浏览器之间的点对点通信，但工程师们也面临着一个新的问题，即基于SIP的传统系统与即将推出的支持浏览器的体系结构共存。我们在此讨论如何解决这一问题，首先确定互操作性需求，然后给出一个实际的互操作性示例，处理将RTCWEB客户端集成到现有的基于标准的协作平台中的问题。

背景、目的和基本原理

浏览器内的实时语音和视频通信是目前两个主要的互联网标准化机构，即互联网工程特别工作组（IETF）和万维网联盟（W3C）中的热门话题之一。

这两个机构的目标是标准化一个开放的框架，实现从浏览器到多媒体应用程序的无缝浏览[1]。这种方法代表了电信领域的一场真正的革命，实际上迫使我们将最近曝光的一些应用程序和系统视为“遗留”，这些应用程序和系统基于电信标准，而不是将浏览器视为一组受支持的终端设备。在这些“遗留”框架中，基于SIP的实时会话初始化协议（real-time Session Initiation Protocol，SIP）架构扮演着重要角色，代表了互联网上最广泛的实时通信解决方案。虽然目前在支持浏览器的点对点通信方面的工作还远未完成，但显然还需要解决方案，以便在现有SIP解决方案的巨大基础和即将推出的产品以及采用新定义标准的技术之间实现无缝交互。

这项工作的重点是在试图让传统的SIP世界和设想的浏览器到浏览器场景无缝互操作时必须面对的互操作性问题。当端到端原则由于中间层的存在而被破坏时，我们确定了出现的主要问题，例如在会议系统依赖于负责协调所有相关客户端之间的通信的中央服务器的情况下。然后，我们讨论了解决已确定的挑战的潜在方法，并介绍了我们旨在实现集成架构的工程活动的结果，该架构能够支持旧客户端设备和配备新定义的实时功能的浏览器。

本文的其余部分安排如下。我们简要介绍了在支持web的实时通信领域的主要标准化活动。有一节专门讨论在通信涉及某种中间人时必须面对的问题。另一部分包含了我们贡献的核心，因为它主要关注Meetecho RTCWebLite，我们提出的解决方案旨在将基于SIP的传统体系结构与支持web的实时客户端共存。对相关工作进行了简要介绍和分析。最后，通过对本文的总结，提出了本文存在的问题和今后研究的方向。

基于标准的WEB实时通信

IETF和W3C对web中实时通信的一般问题的不同而又互补的方面感兴趣。一方面，IETF社区正在研究诸如识别和定义网络相关方面的问题，包括控制协议、连接建立和管理，以及选择最合适的编码器和解码器。另一方面，W3C主要关注如何定义适当的JavaScript机制，以允许和保护对输入设备的访问，以及为通信选择的网络协议。

上述两个标准化活动在位于单个节点的应用层职责和远程节点之间的交互活动之间的边界处相交。当前围绕这些主题的争论集中在应用程序编程接口（api）的定义上，api能够清楚地分离角色和职责。这个想法是让客户端web应用程序（通常是用HTML和JavaScript混合编写的）通过一个特别定义的API与web浏览器交互，允许它们正确地利用和控制浏览器功能，并在主动式（例如查询浏览器功能）和响应（例如接收浏览器生成的通知）方式。因此，上述应用程序浏览器API应提供一系列功能，如连接管理（以对等方式）、编码/解码功能、协商、选择和控制、媒体控制以及防火墙和NAT穿越。

应用程序浏览器API的设计无疑是一个具有挑战性的问题，但它并不能解决当前的总体问题。事实上，完整的画面设想，为了一次将两个（甚至更多）浏览器直接通信，数据的连续实时流通过网络进行传输，而没有更多的中间层。因此，我们讨论的是浏览器到浏览器的通信，这是基于web的通信的革命性方法，因为它允许对等数据通信首次进入web应用程序领域。

这是电信通信领域的一个重大突破，因此需要考虑到许多问题，其中信任和安全起着基础性的作用。关于这最后一点，只要我们允许浏览器之间的直接通信，新的安全威胁就会显现出来。目前实施的基本网络安全策略实际上是基于隔离原则，允许用户保护自己的计算机不受恶意脚本和跨站点内容引用的影响。一旦我们将范围扩大到浏览器到浏览器的通信，一般安全问题的新方面就暴露出来了。首先也是最重要的是，必须以与其他网络协议（如SIP）相同的方式考虑通信安全，允许在任何两个端点之间进行直接通信，除非我们设想继电器作为透明中介的压力。其次，也与第一点相关，在任何两个浏览器之间直接交互的情况下，必须建立适当的机制，以便在实际数据交换阶段开始之前核实同意。在所描述的方案中，浏览器必须执行同意验证，以启动与潜在对等方的通信。我们还注意到，基于web的实时通信要求浏览器与安装它的节点有严格的交互（例如，在与目标对等方进行多媒体呼叫之前访问本地音频和视频设备）。这需要定义涉及某种形式的最终用户同意的访问策略。

我们刚刚勾画的高度动态的背景代表了国际研究界的现状。所确定的问题，甚至所提及的潜在解决方案，实际上代表了本报告撰写之时正在全面展开的研究和工程工作的当前成果，因此，随着我们在该子项目上获得更多经验，在不久的将来可能会发生变化和重新思考。

RTCWEB中间件的问题

如前一节所述，W3C/IETF在WebRTC/RTCWEB标准化工作方面的联合工作目标是两个或多个用户通过使用浏览器进行交互，也就是说，不需要任何插件或任何第三方应用程序。这两个套件目前都是为了针对对等场景进行优化而设计的，应用服务器负责信令、安全和隐私实施，但不负责协商流本身的交付。尽可能假设数据传输直接发生在用户之间（即，如果认为没有必要通过TURN服务器或任何其他类似中介进行中继）。

不过，这并不妨碍一个或多个相关方不是利用实际浏览器的最终用户的可能性。在RTCWEB工作组的用例草案[2]中也记录了一些场景，其中一个用户可能实际与一个应用程序而不是另一个用户交互。这包括连接到交互式语音响应（IVR）系统、公共交换电话网（PSTN）网关或会议服务器等场景。

虽然这本身不被认为是一个问题（新的应用程序可以在一开始就构想出来，并嵌入对RTCWEB框架/协议套件的支持），但如果这些方案中的任何一个涉及遗留系统，例如基于不同的IP语音（VoIP）协议（如SIP）的系统，则可能会成为一个问题。事实上，尽管RTCWEB套件主要基于现有的标准技术，但为了使符合RTCWEB的实现能够与遗留系统正确交互，可能需要填补任何一方的空白。具体地说，一个针对这种集成的应用服务器，因此需要与两个世界进行对话，可能需要注意：

• 信令和/或媒体协商的差异
• 支持安全实时传输协议（SRTP）和交互式连接建立（ICE）（如果缺少）
• 如果没有共同的或更多的编解码器，则对媒体进行转码

悬而未决的问题

当然，首先需要面对的问题是信号。考虑到WebRTC端点和遗留系统可能正在使用不同的语言，可能需要设置一个信令网关。这意味着需要实现一个RTCWEB桥梁（一个能够与两个世界无缝交互的组件，同时充当它们之间的桥梁）。幸运的是，考虑到上述标准技术的重用，这只是部分问题。WebRTC和RTCWEB目前基于JSEP[3]来处理web应用程序和应用服务器之间的信令。不过，需要注意的是，JSEP不是一个信令协议，而是提供了一种在web应用程序中处理信令/协商状态的方法，从而允许在其上部署实际的信令协议（SIP、Jingle等）。协商本身是基于会话描述协议（SDP）提供/应答模型的。这意味着，如果遗留系统使用SDP协商媒体流（在基于SIP的系统中就是这种情况），那么很容易将两个世界连接起来。然而，这也意味着可能涉及两个不同的信令状态机。假设遗留系统基于SIP，则web客户端的第一个提议将需要转换为对统一资源标识符（URI）的邀请，web客户端的进一步更新将需要映射到重新邀请（反之亦然），相应地需要处理关闭任一侧的会话，依此类推。

当任何一方在另一方不支持的媒体级别使用特定功能时，这就变得更加复杂。例如，正如RTCWEB WG中RTP用法草案[4]中所指定的，WebRTC端点被设计为支持创新功能，如SRTP、RTCP的视听配置文件反馈（AVPF）配置文件、RTP/RTCP多路复用、RTP会话多路复用等。如果遗留系统没有实现所有这些功能，而只实现普通RTP，那么可能还需要部署一个合适的RTP网关。事实上，虽然一些协商的特性可能会被拒绝（例如，RTP/RTCP多路复用），但必须实现一些其他特性。例如，这就是SRTP的情况：IETF中达成共识，出于安全原因，明确禁止在WebRTC套件中使用纯RTP。这意味着任何愿意与WebRTC端点交互的实体都必须支持SRTP。因此，仅支持普通RTP的系统需要依赖媒体网关才能满足这一要求。上述媒体网关的部署将由之前引入的RTCWEB Janus负责，因为需要操纵媒体协商，以便将媒体网关沿着WebRTC端点和遗留系统之间的RTP路径放置。

WebRTC终结点强制要求的另一个功能是ICE支持。ICE是大多数现有VoIP部署所采用的标准技术套件，用于处理网络地址转换器（NAT）的遍历。该套件包括两个对等点收集可能到达的候选地址（直接或通过中继）的方法，协商这些地址，并通过会话遍历实用程序（STUN）协议检查它们的可达性。虽然ICE现在已经广泛部署，但仍有一些遗留系统没有实现它。此外，实现它的系统可能支持不同版本或风格的ICE（例如，就如何构建STUN连接检查而言），这意味着即使在这种情况下，也可能存在互操作性问题。考虑到ICE与正在协商和使用的媒体通道严格相关，如果遗留系统不完全符合WebRTC端点的期望，上述媒体网关可能也需要填补这一空白。

当信令、协商和RTP/ICE问题得到解决，仍然无法保证WebRTC遗留端点交互的成功。事实上，很明显，WebRTC端点和遗留端点需要共享对至少一个编解码器的支持，如果它们希望能够相互通信的话。如果两个端点还希望将视频添加到通信中，则需要支持另一个通用编解码器。如果找不到两个端点都支持的编解码器，则会迫使RTCWEB网关也提供转码功能。转码通常是网关实现者试图避免的一种选择；事实上，它是一种CPU密集型功能，可能会影响网关同时提供的交互次数。此外，考虑到部署了一个中间组件来桥接媒体并使它们适应双方，它还增加了交互的延迟。为了尽可能减少需要转码的机会，RTCWEB工作组迄今已就G.711作为强制为所有WebRTC端点实现（MTI）编解码器达成共识。G、 711是VoIP端点和系统中部署最广泛的编解码器，因此，如果想要避免转码，可以安全地将其视为可依赖的编解码器。RTCWEB工作组（WG）还就采用Opus作为MTI高质量音频编解码器达成了共识。相反，关于视频编解码器的共识还没有达成，一场激烈的争论仍在进行。

如下一节所述，在尝试设计WebRTC端点与我们基于传统标准的会议平台之间无缝交互的混合体系结构时，上面描述的所有需求都被证明是有用的。

推动该领域的研究：MEETECHO RTCWEBLITE

上一节中的分析促使我们设计了一个WebRTC切入点到我们的会议平台，称为Meetecho[5]。Meetecho是一种基于标准的会议体系结构，它使用标准协议（例如，可扩展消息和状态协议[XMPP]、SIP和二进制楼层控制协议[BFCP]等）来提供协作功能。因此，特别是对于使用SIP/SDP和RTP来提供音频和视频，可以将其视为WebRTC端点可能希望与之交互的“遗留”系统。对于Meetecho和浏览器，我们已经设计了一个完全基于web的界面来实现所提供的功能，称为WebLite。Meetecho WebLite允许参与者从浏览器访问会议室。这意味着对上述所有标准协议和功能的访问是通过网关提供的，该网关允许用户以透明的方式与本机客户端交互。虽然对于大多数设想的功能来说，只使用HTML和JavaScript来实现这一点相对简单，但是对于音频和视频，我们目前不得不依赖一种不同的方法：一个由JavaScript中的应用程序逻辑指导的Java Applet，它负责处理用户设备（麦克风、网络摄像头）以及编码和解码与会议服务器交换的RTP流的功能和管理，如图1所示。

这是一个必要的步骤，因为如前几节所述，浏览器目前无法提供本地方式来访问音频/视频捕获功能和双向流，如果没有Java小程序、Flash/Silverlight应用程序或专门设计的Netscape插件API（NPAPI）插件的话。当然，这正是RTCWEB/WebRTC联合工作试图提供的解决方案，因此，这为我们提供了一个极好的机会，试图为我们的“传统”会议系统提供一个完全基于web的界面，如图2所示。

为了验证我们的互操作性，我们使用Chrome Canary作为WebRTC端点，这是当时唯一一个提供随时可用、几乎完整的WebRTC堆栈的浏览器。

遵循上一节中介绍的指导原则，第一步当然是处理信号。正如预期的那样，Meetecho使用SIP作为其信令协议来协商媒体流。SIP也用于设置与参与者建立一个BFCP渠道，以提供楼层控制功能。我们选择使用RTCWeb提供/应答协议（ROAP）[6]，一种基于JSON的信令协议，作为在web界面中提供信令的简单而快速的解决方案。ROAP是RTCWEB工作组中提出的在Web

剩余内容已隐藏，支付完成后下载完整资料

资料编号：[234107]，资料为PDF文档或Word文档，PDF文档可免费转换为Word