具有窗口监视/叠加检测的WebRTC API重定向

摘要

一种计算系统包括至少一个视频源、虚拟桌面服务器和客户端计算设备。虚拟桌面服务器包括用以提供实时通信（RTC）的实时媒体应用、原生RTC引擎、几何形状跟踪模块和API代码重定向模块，该API代码重定向模块用以基于注入到实时媒体应用中的重定向代码来重定向实时媒体应用的旨在用于原生RTC引擎的所拦截API。所注入的重定向代码定义占位符以指示视频流在RTC窗口内的定位几何形状。几何跟踪模块检测所注入的重定向代码内的占位符。客户端计算设备包括显示合成模块，以接收视频流和占位符的定位几何形状，并基于定位几何形状将视频流叠加在所显示的RTC窗口内的占位符之上。

说明书

相关申请

本申请要求2018年5月4日提交的临时申请序列号62/667,013的权益，特此将该临时申请通过引用以其整体并入本文。

技术领域

本公开总体上涉及一种应用虚拟化平台，其允许虚拟化浏览器和桌面应用使用标准Web实时通信（Web Real-Time Communication ，WebRTC）API来交付优化的实时通信。

背景技术

传统上，个人计算机包括操作系统、应用和用户设置的组合，其中每个由所有者或管理员持续单独管理。然而，许多组织现在正在使用桌面虚拟化来提供更灵活的选项，以解决其用户的不同需求。在桌面虚拟化中，用户的计算环境（例如，操作系统、应用和/或用户设置）可以与用户的物理计算设备（例如，智能电话、膝上型计算机、台式计算机）分离。通过使用客户端-服务器技术，“虚拟化桌面”可以存储在远程服务器中并由其管理，而不是存储在客户端计算设备的本地存储装置中。

存在几种不同类型的桌面虚拟化系统。作为示例，虚拟桌面基础架构（VDI）指代在驻留在服务器上的虚拟机内运行用户桌面的过程。VDI和其他基于服务器的桌面虚拟化系统可以为每个用户提供个性化的桌面，同时允许集中式管理和安全性。这样的系统中的服务器可以包括用于虚拟桌面图像和系统配置信息的存储装置，以及用以提供虚拟桌面并允许用户与其互连的软件组件。例如，VDI服务器可以包括用以创建和维护多个虚拟机的一个或多个虚拟机监视器（虚拟机管理器）、用以管理（一个或多个）虚拟机监视器的软件、连接代理、以及用以供应和管理虚拟桌面的软件。

桌面虚拟化系统可以使用单个虚拟化服务器或互连为服务器网格的服务器组合来实现。例如，云计算环境或云系统可以包括计算资源池（例如，桌面虚拟化服务器）、存储磁盘、联网硬件和可以用于供应虚拟桌面的其他物理资源、连同用以为云系统提供管理和客户门户的附加计算设备。

云系统可以通过网络为客户动态创建和管理虚拟机，从而为远程客户提供计算资源、数据存储服务、联网能力以及计算机平台和应用支持。例如，云系统中的客户可能请求具有指定处理器速度和存储器以及指定磁盘存储量的新虚拟机。在云系统中，资源管理器可以从云资源池（例如，服务器、存储磁盘）中选择可用的物理资源集合，并且可以根据客户指定的计算参数来供应和创建新的虚拟机。云计算服务可以用私有和/或公共组件为多个客户服务，并且可以被配置为提供各种特定服务，包括web服务器、安全系统、开发环境、用户接口等。

发明内容

一种计算系统包括用以提供至少一个视频流的至少一个视频源、虚拟桌面服务器和客户端计算设备。虚拟桌面服务器包括：应用框架，包括用以提供实时通信（RTC）的实时媒体应用、当实时媒体应用的一部分被原生RTC引擎接收时执行所述部分的原生RTC引擎；以及API代码重定向模块。API代码重定向模块基于注入到实时媒体应用中的重定向代码来重定向实时媒体应用的旨在用于原生RTC引擎的所拦截API，使得实时媒体应用的所述部分被重定向。所注入的重定向代码定义至少一个占位符，以指示所述至少一个视频流在RTC窗口内的定位几何形状。虚拟桌面服务器进一步包括几何形状跟踪模块，以检测所注入的重定向代码内的所述至少一个占位符，并提供与其相关联的定位几何形状。

客户端计算设备包括用以显示RTC窗口的显示器，以及通过虚拟通道与API代码重定向模块通信以执行实时媒体应用的重定向部分的客户端RTC API引擎。客户端计算设备进一步包括显示合成模块，以接收所述至少一个视频流和所述至少一个占位符的定位几何形状，并基于定位几何形状将所述至少一个视频流叠加在所显示的RTC窗口内的所述至少一个占位符之上。

为了实现WebRTC功能性的无缝重定向，虚拟桌面服务器上的应用框架有利地标识和跟踪几个视频元素以及叠加实况视频的任何其他元素的可见性和几何形状。当该信息可用时，客户端计算设备上的WebRTC重定向代码将使用它来创建、定位和裁剪本地视频渲染窗口，并且可能在该窗口的顶部上渲染不透明或透明的叠加来表示对应的应用UI元素。

WebRTC应用中视频和其他UI元素的定位和渲染通常由嵌入在应用框架中的渲染引擎处理，并且通常不容易通过API而可用。为了克服该限制并标识多个视频区域并跟踪它们的几何形状，所注入的重定向代码定义占位符来指示不同视频流在RTC窗口内的定位几何形状。

几何形状跟踪模块然后检测所注入的重定向代码内的占位符，并提供与其相关联的定位几何形状。定位几何形状提供了视频流将被放置之处的x-y坐标连同分辨率。

几何形状跟踪模块基于颜色检测占位符。在其他实施例中，可以用图案或条形码来检测不同的占位符。此外，不同的颜色、图案和条形码可以各自具有与其相关联的对应于相应视频流的ID。此外，占位符颜色可以在被几何形状跟踪模块检测到之后改变为与呈现在客户端计算设备上的窗口相混合的更中性的颜色。

客户端计算设备内的显示合成模块基于与视频流相关联的指定位置几何形状来渲染所述视频流。在由显示合成模块合成之后，视频流以正确的形状出现在正确的位置中。

另一方面涉及一种用于操作如上所述的计算系统的方法。所述方法包括：从至少一个视频源提供至少一个视频流；以及基于实时媒体应用的操作提供实时通信（RTC），其中实时媒体应用的一部分将在被原生RTC引擎接收时由原生RTC引擎执行。API代码重定向模块基于注入到实时媒体应用中的重定向代码来重定向实时媒体应用的旨在用于原生RTC引擎的所拦截API，使得实时媒体应用的所述部分被重定向。所注入的重定向代码定义至少一个占位符，以指示所述至少一个视频流在RTC窗口内的定位几何形状。

几何形状跟踪模块检测所注入的重定向代码内的所述至少一个占位符，并提供与其相关联的定位几何形状。显示RTC窗口，并且客户端RTC API引擎通过虚拟通道与API代码重定向模块通信，以执行实时媒体应用的重定向部分。显示合成模块接收所述至少一个视频流和所述至少一个占位符的定位几何形状，并基于定位几何形状将所述至少一个视频流叠加在所显示的RTC窗口内的所述至少一个占位符之上。

又一方面涉及一种用于在如上所述的计算系统内操作虚拟桌面服务器的非暂时性计算机可读介质。所述非暂时性计算机可读介质具有多个计算机可执行指令，用于引起虚拟桌面服务器执行也如上所述的步骤。

附图说明

专利或申请文件包含至少一幅用彩色绘制的附图。本专利或专利申请公开的具有（一幅或多幅）彩色附图的副本将由办事处根据要求提供，并支付必要的费用。

图1是其中可以实现本公开的各个方面的计算设备的网络环境的框图。

图2是对于实践图1中图示的客户端机器或远程机器的实施例有用的计算设备的框图。

图3是图示了应用虚拟化平台的架构的框图，该应用虚拟化平台在虚拟桌面服务器上提供WebRTC API，并在其中可以实现本公开的各个方面的客户端计算设备上执行WebRTC API功能性。

图4-7是图示了具有图3中图示架构的示例窗口监视/叠加检测场景的各种窗口。

图8-9是基于服务器端窗口的移动对图7中图示窗口的更新。

图10-11是基于裁剪视频流的经渲染服务器端应用对图9中图示窗口的更新。

图12是图3中图示架构的简化框图，其图示了利用WebRTC API重定向的屏幕共享。

图13是图示了检测半透明叠加的方法的表格图，该方法可以与图3中图示的架构一起使用。

图14-17是图示了检测半透明叠加的方法的测试运行的样本图像，该方法可以与图3中图示的架构一起使用。

图18是图3中图示架构的框图，该架构被修改以支持包括半透明叠加的任何加速图形媒体。

具体实施方式

参考附图进行本描述，其中示出了示例性实施例。然而，可以使用许多不同的实施例，并且因此该描述不应当被解释为限于本文阐述的特定实施例。而是，提供这些实施例使得本公开将透彻且完整。贯穿全文，相同的数字指代相同的元素，并且在替代实施例中，撇号用于指示相似的元素。

如本领域技术人员在阅读以下公开内容后将领会的，本文描述的各个方面可以体现为设备、方法或计算机程序产品（例如，具有用于执行所指出操作或步骤的计算机可执行指令的非暂时性计算机可读介质）。因此，那些方面可以采取完全硬件实施例、完全软件实施例或组合软件和硬件方面的实施例的形式。

此外，这样的方面可以采取由一个或多个计算机可读存储介质存储的计算机程序产品的形式，所述计算机可读存储介质具有体现在存储介质中或其上的计算机可读程序代码或指令。可以利用任何合适的计算机可读存储介质，包括硬盘、CD-ROM、光存储设备、磁存储设备和/或其任何组合。

初始参考图1，其中可以实现本公开的各个方面的非限制性网络环境101包括一个或多个客户端机器102A-102N、一个或多个远程机器106A-106N、一个或多个网络104、104’以及安装在计算环境101内的一个或多个器具108。客户端机器102A-102N经由网络104、104’与远程机器106A-106N通信。

在一些实施例中，客户端机器102A-102N经由居间器具108与远程机器106A-106N通信。图示的器具108位于网络104、104’之间，并且可以被称为网络接口或网关。在一些实施例中，器具108可以作为应用交付控制器（ADC）来操作，以向客户端提供对部署在数据中心、云中或者作为软件即服务（SaaS）跨一系列客户端设备交付的业务应用和其他数据的访问，和/或提供诸如负载平衡等其他功能性。在一些实施例中，可以使用多个器具108，并且（一个或多个）器具108可以被部署为网络104和/或104’的部分。

客户端机器102A-102N一般可以被称为客户端机器102、本地机器102、客户端102、客户端节点102、客户端计算机102、客户端设备102、计算设备102、端点102或端点节点102。远程机器106A-106N一般可以被称为服务器106或服务器群106。在一些实施例中，客户端设备102可以具有既作为寻求访问由服务器106提供的资源的客户端节点又作为为其他客户端设备102A-102N提供对托管资源的访问的服务器106起作用的能力。网络104、104’一般可以被称为网络104。网络104可以被配置在有线和无线网络的任何组合中。

服务器106可以是任何服务器类型，诸如例如：文件服务器；应用服务器；web服务器；代理服务器；器具；网络器具；网关；应用网关；网关服务器；虚拟化服务器；部署服务器；安全套接层虚拟私有网络（SSL VPN）服务器；防火墙；web服务器；执行活动目录的服务器；或者执行提供防火墙功能性、应用功能性或负载平衡功能性的应用加速程序的服务器。

服务器106可以执行、操作或以其他方式提供可以是以下各项中任何一种的应用：软件；程序；可执行指令；虚拟机；虚拟机监视器；web浏览器；基于网络的客户端；客户端-服务器应用；瘦客户端计算客户端；ActiveX控件；Java小程序；与互联网语音协议（VoIP）通信相关的软件，如软IP电话；用于流式传输视频和/或音频的应用；用于促进实时数据通信的应用；HTTP客户端；FTP客户端；奥斯卡客户端；远程登录客户端；或任何其他可执行指令集合。

在一些实施例中，服务器106可以执行远程呈现服务程序或使用瘦客户端或远程显示协议来捕获由在服务器106上执行的应用生成的显示输出并将应用显示输出传输到客户端设备102的其他程序。

在又其他实施例中，服务器106可以执行向客户端设备102的用户提供对计算环境的访问的虚拟机。客户端设备102可以是虚拟机。虚拟机可以由例如虚拟机监视器、虚拟机管理器（VMM）或服务器106内的任何其他硬件虚拟化技术来管理。

在一些实施例中，网络104可以是：局域网（LAN）；城域网（MAN）；广域网（WAN）；主公共网络104；和主私有网络104。附加实施例可以包括使用各种协议在移动设备间通信的移动电话网络的网络104。对于无线局域网（WLAN）内的短程通信，协议可以包括802.11、蓝牙和近场通信（NFC）。

图2描绘了对于实践客户端设备102或服务器106的实施例有用的计算设备100的框图。计算设备100包括一个或多个处理器103、易失性存储器122（例如，随机存取存储器（RAM））、非易失性存储器128、用户接口（UI）123、一个或多个通信接口118和通信总线150。

非易失性存储器128可以包括：一个或多个硬盘驱动器（HDD）或其他磁或光存储介质；一个或多个固态驱动器（SSD），例如闪存驱动器或其他固态存储介质；一个或多个混合磁和固态驱动器；和/或一个或多个虚拟存储卷（例如云存储装置），或者这样的物理存储卷和虚拟存储卷或其阵列的组合。

用户接口123可以包括图形用户接口（GUI）124（例如，触摸屏、显示器等）和一个或多个输入/输出（I/O）设备126（例如，鼠标、键盘、麦克风、一个或多个扬声器、一个或多个相机、一个或多个生物扫描仪、一个或多个环境传感器以及一个或多个加速度计等）。

非易失性存储器128存储操作系统115、一个或多个应用116和数据117，使得例如操作系统115和/或应用116的计算机指令由易失性存储器122之外的（一个或多个）处理器103执行。在一些实施例中，易失性存储器122可以包括一种或多种类型的RAM和/或高速缓冲存储器，其可以提供比主存储器更快的响应时间。可以使用GUI 124的输入设备录入数据，或者从（一个或多个）I/O设备126接收数据。计算机100的各种元件可以经由通信总线150进行通信。

所图示的计算设备100仅被示为示例客户端设备或服务器，并且可以由具有任何类型的机器或机器集合的任何计算或处理环境来实现，所述机器或机器集合可以具有能够如本文所述进行操作的合适硬件和/或软件。

（一个或多个）处理器103可以由一个或多个可编程处理器实现，以执行一个或多个可执行指令（例如计算机程序）以执行系统的功能。如本文所使用的，术语“处理器”描述了执行功能、操作或操作序列的电路。功能、操作或操作序列可以被硬编码到电路中，或者通过保存在存储器设备中并由电路执行的指令的方式进行软编码。处理器可以使用数字值和/或使用模拟信号来执行功能、操作或操作序列。

在一些实施例中，处理器可以体现在如下各项中：一个或多个专用集成电路（ASIC）、微处理器、数字信号处理器（DSP）、图形处理单元（GPU）、微控制器、现场可编程门阵列（FPGA）、可编程逻辑阵列（PLA）、多核处理器或具有相关联存储器的通用计算机。

处理器可以是模拟、数字或混合信号的。在一些实施例中，处理器可以是一个或多个物理处理器，或者一个或多个虚拟（例如，远程定位的或云）处理器。包括多个处理器核的处理器和/或多个处理器可以提供并行、同时执行指令或者并行、同时执行多于一段数据上的一个指令的功能性。

通信接口118可以包括一个或多个接口，以使得计算设备100能够通过包括蜂窝连接在内的各种有线和/或无线连接来访问计算机网络，诸如局域网（LAN）、广域网（WAN）、个人区域网（PAN）或因特网。

在所描述的实施例中，计算设备100可以代表客户端设备的用户执行应用。例如，计算设备100可以执行由虚拟机监视器管理的一个或多个虚拟机。每个虚拟机可以提供代表用户或客户端设备在其中执行应用的执行会话，例如托管桌面会话。计算设备100还可以执行终端服务会话来提供托管桌面环境。计算设备100可以提供对远程计算环境的访问，该远程计算环境包括一个或多个应用、一个或多个桌面应用以及一个或多个应用可以在其中执行的一个或多个桌面会话。

计算设备100——被配置成客户端设备102或服务器106，或者被配置成客户端设备102和服务器106居间的器具——及其操作的附加描述可以在美国专利号9,176,744和9,538,345中找到，所述美国专利通过引用以其整体并入本文。‘744和‘345专利均转让给本公开的当前受让人。

现在转到图3，将在利用拦截技术的WebRTC重定向方面讨论所图示的架构300。架构300允许虚拟化浏览器和桌面应用使用标准的WebRTC API来交付优化的实时通信（RTC）。实时通信包括语音、视频和数据协作。应用框架312在应用服务器302上提供WebRTC API，并在远程客户端304上提供WebRTC API功能性的执行。使用各种技术来使该功能性对于实时媒体应用310是可行的和透明的，并且实现高质量的用户体验和其他合期望的特征。

应用框架312包括web浏览器或桌面应用以提供实时媒体应用310，该实时媒体应用310提供实时通信。实时媒体应用310由实时媒体应用服务器320支持。架构300可以被称为计算系统300，应用服务器302可以被称为虚拟桌面服务器302，并且远程客户端304可以被称为客户端计算设备304或虚拟桌面客户端304。客户端计算设备304与至少一个其他客户端计算设备305进行对等通信。

WebRTC是API和开源项目的集合，其使能浏览器和桌面应用中的实时通信（VoIP、通过IP的视频和其他类型的实时协作）。自2011年被谷歌引入行业并被几个标准机构（W3C和IETF）采用以来，WebRTC已被包括在大多数常用的web浏览器中，以及在诸如Electron之类的桌面应用平台中可用。应用和服务供应商以及企业IT部门越来越多地使用WebRTC为现有和新的HTML5应用添加语音和视频功能性。

Electron是一个开源框架，用于使用最初为Web定义的技术构建桌面应用（在浏览器之外运行），包括HTML5和WebRTC。也见证领先的应用供应商在行业中越来越多地采用Electron。

在桌面虚拟化下，在虚拟桌面服务器302上执行WebRTC功能性具有许多众所周知的缺点。一个缺点是音频和视频设备虚拟化引入的高延迟和低媒体质量，这涉及几轮媒体压缩/解压缩和额外的网络跳跃。另一个缺点是由对等媒体通过数据中心或云基础架构的强制隧道传输以及在虚拟桌面服务器302上运行高CPU成本的音频和视频编解码器引起的网络和服务器可扩展性忧虑。

客户端计算设备304上的客户端RTC API引擎308对实时功能性（包括媒体处理流水线和联网代码两者）的执行解决了这些问题。使用原生RTC引擎316在虚拟桌面服务器302上运行剩余的实时媒体应用代码仍然是有利的，在原生RTC引擎316中其可以与其他桌面应用和其他桌面OS功能性集成。WebRTC API的重定向提供了一种使实时媒体应用代码在虚拟桌面服务器302上继续执行而同时仅将实时媒体处理和联网卸载到客户端计算设备304的方式。此外，实时媒体应用代码可能在很大程度上没有意识到WebRTC API正在被重定向的事实。这导致针对许多（如果不是全部）虚拟化应用的卓越的实时媒体优化。

将部分应用功能性从虚拟桌面服务器302重定向或远程处理到客户端计算设备304本身并不是新的，并且已经在多种技术中实现（包括诸如远程处理音频和视频扩展（RAVE）、闪存重定向、浏览器内容重定向和实时优化包的Citrix技术）。然而，新的是使用WebRTC重定向技术为HTML 5/JavaScript应用交付实时媒体优化。

WebRTC重定向技术包括许多独特的功能，诸如：用于浏览器和桌面应用的API拦截新方法；用于提供回退功能性的新技术；用于视频区域标识和几何形状跟踪的新技术：用于窗口监视/叠加检测的新技术：用于为内容共享会话选择和捕获屏幕内容的新技术；用以控制对端点媒体源的应用访问的新策略类型和应用；以及用于在虚拟化应用环境中管理实时媒体的网络连接性的新技术。下面更详细地讨论这些技术。

作为总体概述，WebRTC包括由Web实时通信工作组（W3C的一部分）维护的API规范集合，以及这些API在web浏览器和HTML5/JavaScript桌面应用平台（诸如Electron）中的实现。与此架构最相关的规范包括WebRTC 1.0：浏览器之间的实时通信（进一步称为[webrtc]）、媒体捕获和流（[媒体捕获-流]）以及屏幕捕获（[屏幕-捕获]）。以下描述引用了来自相关W3C规范的定义和API元素，而在这里不重复它们。

图3中所图示的架构300的总体思想是要通过拦截由实时媒体应用310对API进行的调用，将WebRTC API的底层功能性从虚拟桌面服务器302重定向到客户端计算设备304。所拦截API或是经由客户端RTC API引擎308在客户端计算设备304上远程执行，或是酌情经由原生RTC引擎316在虚拟桌面服务器302上本地执行。调取API回调或向实时媒体应用310生成异步API事件。

该领域中的首字母缩略词和定义包括Xen应用（XA）、XenDesktop（XD）和虚拟桌面基础架构（VDI）。VDI是一种虚拟化技术，它在数据中心中的集中式服务器上托管桌面操作系统，并提供对虚拟托管应用和桌面的远程访问。Citrix接收器和Citrix工作区应用是虚拟桌面客户端，其提供对虚拟托管应用和桌面的远程访问。

以下主要元素包括用于WebRTC重定向的系统架构300。虚拟桌面服务器302提供服务器端虚拟通道功能性并托管虚拟应用。例如，这些可以在Citrix Xen应用/XenDesktop中实现。虚拟桌面客户端304提供客户端虚拟通道功能性。例如，这可以在Citrix接收器和Citrix工作区应用中实现。虚拟化应用（或虚拟应用）是用HTML 5和JavaScript实现的第三方应用，并且使用WebRTC来交付实时语音、视频和数据功能性。诸如实时媒体应用310之类的虚拟化应用被托管在虚拟桌面服务器302上。

服务器端API代码重定向模块306包括运行在虚拟桌面服务器302上的代码库和应用，并与实时媒体应用310交互以实现WebRTC API重定向。API代码重定向模块306可以被称为WebRTC API连接器306。对于下面描述的一些技术，API代码重定向模块306可以被认为是单个系统组件，或者可以被分成两个子组件：注入的和非注入代码。

注入的服务器端WebRTC连接器代码314（注入的API代码）包括连接器代码的部分，所述连接器代码可以用JavaScript实现，或者用不同的计算机语言实现但是提供JavaScript兼容的API。注入的API代码314被注入到实时媒体应用310中，并修改应用进程内的HTML5/JavaScript执行环境。如果用JavaScript实现，则注入代码314将直接使用WebSocket或另一种合适的进程间通信机制与非注入的连接器代码库通信，并且间接通过渲染的屏幕内容进行通信，如下面在窗口跟踪部分中所描述的。

其他服务器端连接器代码包括用任何合适的编程语言实现并且在应用进程内部或外部运行的代码库。API代码重定向模块306通过WebSocket或另一种合适的机制与注入代码314通信，并通过屏幕捕获间接通信，以及通过虚拟通道318与客户端RTC API引擎308通信。

客户端RTC API引擎308包括运行在客户端计算设备304上的代码库。客户端RTCAPI引擎308通过由虚拟桌面服务器302托管的虚拟通道318与API代码重定向模块306通信。

所图示的架构300以及通过将实时媒体应用RTC功能性的部分从虚拟桌面服务器302卸载到客户端计算设备304来优化应用虚拟化的总体思想是相当通用的，并且广泛用于实现应用或桌面虚拟化的系统中。本文的区别在于注入代码314、API代码重定向模块306和客户端RTC API引擎308的特定功能和交互，所述特定功能和交互被设计为优化实时媒体API。特别地，优化了WebRTC。

如上面指出的，计算系统300包括与另一端点设备305进行对等通信的虚拟桌面服务器302和客户端计算设备304。虚拟桌面服务器302包括应用框架312，该应用框架312包括实时媒体应用310以提供实时通信（RTC）以及包括原生RTC引擎316以在实时媒体应用310的一部分被原生RTC引擎316接收时执行该部分。API代码重定向模块306基于注入到实时媒体应用310中的重定向代码314来重定向实时媒体应用310的旨在用于原生RTC引擎316的所拦截API，使得实时媒体应用310的所述部分被重定向。客户端计算设备304中的客户端RTCAPI引擎308通过虚拟通道318与API代码重定向模块306通信，以执行实时媒体应用310的重定向部分。

应用框架312可以是web浏览器或桌面应用框架。重定向的API对应于实时媒体处理和/或与另一客户端计算设备305的对等联网。

现在将讨论各种API拦截技术。WebRTC API被定义为可用于web浏览器内或应用开发平台（诸如Electron）内的HTML 5/Java Script应用的Java Script API。Electron将HTML 5/Java Script应用引擎与附加的特定于桌面的平台功能性相组合。桌面虚拟化平台对WebRTC API的拦截需要附加的新颖技术。

下面将讨论以下API拦截技术：钩取；自定义浏览器的使用；经由代理进行JavaScript注入；经由浏览器助手对象（BHO）或浏览器扩展的JavaScript注入，经由微型VPN插件进行JavaScript注入；以及electron应用分解的使用。

对于钩取，API代码重定向模块306可以包括钩取模块，该钩取模块被配置为基于钩取来拦截实时媒体应用310的API，并且基于所拦截API将重定向代码314注入到实时媒体应用310中。

JavaScript渲染的DLL API被钩取，并且自定义的JS被插入。对于IE，JavaScript引擎DLL是jscript.dll，并且是（进程中）COM对象服务器。因此，思想将是采用标准的COM垫片技术，以作为一个“中间方”（MITM）来操作，以便插入自定义的JavaScript。在IEJavaScript引擎中，所有JavaScript对象都实现了IDispatchEx接口。替代地，可以钩取OS套接字API（例如WinSock API），解析HTTP流量和HTML内容，并且然后插入JS。

对于自定义浏览器，可以使用自定义的基于Chromium的浏览器引擎，并且发布自定义的安全浏览器，例如，作为Citrix安全浏览器云服务的部分。在Chromium引擎内使用钩子或插件来注入自定义的JS。替代地，自定义浏览器引擎可以在原生代码中实现部分或全部WebRTC重定向功能性，从而限制或移除注入自定义JavaScript代码的需要。虚拟桌面服务器302包括浏览器，该浏览器包括钩子或插件，该钩子或插件被配置为拦截实时媒体应用310的API，并基于所拦截API将重定向代码314注入到实时媒体应用310中。

对于经由代理进行JavaScript注入，代理用于拦截HTML内容。代理将经由内容重写添加附加的JS。代理可以是网络上的分离器具，或者驻留在虚拟桌面服务器302上。代理可以被显式配置（使用浏览器设置）或作为透明代理操作。

在一种方法中，计算系统300进一步包括代理服务器，该代理服务器被配置为拦截来自web服务器的将由实时媒体应用310检索的HTML内容，并且重写拦截的HTML内容，使得重写的HTML内容的执行引起实时媒体应用310的API被拦截。重定向代码314然后基于所拦截API被注入到实时媒体应用310中。

在另一种方法中，代理服务器可以被配置为拦截来自web服务器的将由实时媒体应用310检索的HTML内容，并将代码注入到拦截的HTML内容的页面中。带有注入代码的页面的执行引起实时媒体应用310的API被拦截。重定向代码314然后基于所拦截API被注入到实时媒体应用310中。

对于经由浏览器助手对象（BHO）或浏览器扩展的JavaScript注入，可以使用用于实现BHO或浏览器扩展机制的web浏览器的BHO或浏览器扩展，将用以实现WebRTC API重定向的JavaScript代码注入到基于浏览器的应用中。虚拟桌面服务器302因此包括浏览器，该浏览器包括BHO或浏览器扩展，以拦截实时媒体应用310的API，并基于所拦截API将重定向314代码注入到实时媒体应用310中。

对于经由微型VPN插件进行JavaScript注入，使用通用的windows平台（UWP）应用来实现虚拟私有网络（VPN）应用插件。UWP VPN插件应用将在应用X清单中处理VPN客户端插件能力的声明，并提供对VPN插件应用处理程序的引用。在沙箱（应用容器）内运行插件允许更高的安全性以及降低的实现复杂性。

VPN 应用插件能够结合OS VPN平台来控制VPN连接。此外，VPN 应用插件可以被配置成微型VPN，即，它可以在每个应用的基础上应用。例如，配置可以经由移动设备管理（MDM）或移动应用管理（MDM）策略来实现。

替代地，可以使用PowerShell脚本创建自定义配置文件。该配置可以指定其流量要由微型VPN插件管理的应用。特别地，微型VPN插件可以配置用于浏览器应用和基于Electron的应用。可以使得微型VPN插件能够拦截所有或特定应用的网络流量，使用本地证书存储解密TLS，解析HTTP流量和HTML内容，并且然后插入自定义JavaScript。

在一种方法中，计算系统进一步包括微型虚拟私有网络（VPN）插件，其被配置为拦截来自web服务器的将由实时媒体应用310检索的HTML内容，并重写拦截的HTML内容，使得重写的HTML内容的执行引起实时媒体应用310的API被拦截。然后重定向代码314将基于所拦截API被注入到实时媒体应用310中。

在另一种方法中，微型虚拟私有网络（VPN）插件可以被配置为拦截来自web服务器的将由实时媒体应用310检索的HTML内容，并将代码注入到拦截的HTML内容的页面中。具有注入代码的页面的执行引起实时媒体应用310的API被拦截。重定向代码314然后基于所拦截API被注入到实时媒体应用310中。

对于electron应用分解，首先通过修改electron应用的工具来运行electron应用。修改基于：分解electron应用的二进制文件以访问实时媒体应用310的API，添加钩子以基于所拦截API将重定向代码注入到实时媒体应用310中，重新打包electron应用二进制文件，以及对electron应用进行重新签名。经修改的electron应用然后被配置为基于钩取来拦截实时媒体应用310的API，并基于所拦截API将重定向代码314注入到实时媒体应用310中。换句话说，electron应用是在虚拟应用发布期间被检测到的。

然后分解electron应用二进制文件。应用内容通常位于.asar归档文件中，所述.asar归档文件位于与electron应用对应的子文件夹内。使用asar.exe（作为node.js包可用）来对该归档文件拆包以访问应用的JavaScript代码是可能的。然后添加钩子，其中钩子包含要在运行时加载并注入自定义JS的DLL或其他模块。修改主可执行文件的导入地址表，以便在进程运行时加载钩子。应用二进制文件被重新打包，并且然后electron应用包被重新签名。

使用标准WebRTC API交付优化的实时通信（RTC）的另一方面涉及一种用于操作计算系统300的方法，该计算系统300包括虚拟桌面服务器302和包含客户端RTC API引擎308的客户端计算设备304。虚拟桌面服务器302包括应用框架312和API代码重定向模块306。应用框架312包括实时媒体应用310和原生RTC引擎316。

该方法包括基于实时媒体应用310的操作提供实时通信，其中实时媒体应用310的一部分将在被原生RTC引擎316接收时由原生RTC引擎316执行。该方法进一步包括由API代码重定向模块306基于注入到实时媒体应用310中的重定向代码314，来重定向实时媒体应用310的旨在用于原生RTC引擎316的所拦截API，使得实时媒体应用310的所述部分被重定向。客户端RTC API引擎308通过虚拟通道318与API代码重定向模块306通信，以执行实时媒体应用310的重定向部分。

又一方面涉及一种用于在如上所述的计算系统300内操作虚拟桌面服务器302的非暂时性计算机可读介质。该非暂时性计算机可读介质具有多个计算机可执行指令，用于引起虚拟桌面服务器302基于实时媒体应用310的操作提供实时通信（RTC），其中实时媒体应用310的一部分将在被原生RTC引擎316接收时由原生RTC引擎316执行。该指令进一步引起虚拟桌面服务器302由API代码重定向模块306基于注入到实时媒体应用310中的重定向代码314，来重定向实时媒体应用310的旨在用于原生RTC引擎316的所拦截API，使得客户端RTC API引擎308通过虚拟通道318与API代码重定向模块306通信，以执行实时媒体应用310的重定向部分。

仍然参考图3，现在将在具有回退的WebRTC重定向方面来讨论所图示的计算系统300。现在将讨论一般的回退技术，其中在一些情况下，必要的功能性将缺失，因此在完全优化不可用时，需要使用较少优化机制的良好回退功能性来处理实时媒体。

虚拟桌面服务器302和至少一个客户端计算设备304如上面所讨论的。应用框架312包括实时媒体应用310以提供实时通信（RTC），以及原生RTC引擎316，其在实时媒体应用310的一部分被原生RTC引擎306接收时执行该部分。虚拟桌面服务器302进一步包括API代码重定向模块306，以基于注入到实时媒体应用310中的重定向代码314来重定向实时媒体应用310的旨在用于原生RTC引擎316的原始API，使得实时媒体应用310的所述部分将被重定向。

特别地，客户端计算设备304包括客户端RTC API引擎308，其通过虚拟通道318向API代码重定向模块306报告关于客户端计算设备304执行实时媒体应用310的重定向部分的能力。如果客户端计算设备304具有有限的能力，则API代码重定向模块306切换到回退模式。在回退模式下，使用至少部分原始API，使得原生RTC引擎316执行实时媒体应用310的所述部分的至少部分。

当所有系统组件都包括必要的功能性时，由这里描述的WebRTC重定向使能的实时媒体功能性将导致优化的用户体验和系统可扩展性。特别地，当虚拟桌面客户端和服务器包括具有必要能力的兼容软件和硬件模块时，其协作来交付所设计的功能性。

如果客户端计算设备304具有全部能力，则不需要回退。在该情况下，API代码重定向模块306不切换到回退模式，使得客户端RTC API引擎308执行实时媒体应用310的所有重定向部分。

然而，在现实世界的部署中，在一些情况下，必要的功能性将缺失是不可避免的。当完全优化不可用时，WebRTC远程处理解决方案必须提供良好的回退功能性，以使用其他较少优化的机制来处理实时媒体。理想情况下，该回退功能性（以及优化本身）应当对应用透明——即由应用框架312处理而不需要应用改变，并提供友好的用户体验。

为了提供回退功能性，虚拟应用解决方案需要包括一些或全部会话状态跟踪以及能力检测和协商。在会话状态跟踪中，应用进程生存期可能与到虚拟访问会话的一个或多个用户连接重叠，并且使能优化功能性或提供回退的进程可能随着会话状态改变而多次发生。

在能力检测和协商中，用于提供优化功能性的客户端-服务器协议需要支持虚拟桌面服务器302和客户端计算设备304能力的检测或协商，这使得对应的代码能够在优化和回退操作模式之间切换。

当需要回退时，那么以下技术专用于为WebRTC重定向提供回退功能性。这些技术包括1）回退到内置原生RTC引擎316；2）每模态回退；3）部分回退；以及4）会话连接/断开事件到设备可用性事件的映射。

在回退到内置原生RTC引擎316中，客户端计算设备304没有能力执行实时媒体应用310的重定向部分。在回退模式下，使用所有原始API，使得原生RTC引擎316执行实时媒体应用310的所有部分，而不是客户端RTC API引擎308。

当远程执行WebRTC不可能时（例如，当不存在客户端RTC API引擎308时），注入代码可以动态地将应用API调用分派给内置原生RTC引擎316，该内置原生RTC引擎316被包括作为应用框架312的部分。注入代码314可以使用自身作为垫片来监视这些调用，并且所得到的内置WebRTC对象被用来使得能够最终切换到远程（优化的）功能性以及对应用WebRTC使用和质量的持续监视。

在每模态回退中，取决于客户端计算设备304的能力和策略，当实时媒体应用310的未被原生RTC引擎316执行的部分的剩余部分被重定向到客户端RTC API引擎308以供执行时，应用框架312可以实现每模态回退功能性。

例如，当客户端计算设备304只能处理实时媒体会话的音频部分时，应用框架312可以实现针对音频的优化功能性和针对视频的回退功能性。为此，注入代码314可以将用于音频流的API调用远程处理到客户端计算设备304，并将针对视频流的API调用重定向到本地内置RTC引擎316，从而将结果合并在一起。由原生RTC引擎316执行的实时媒体应用310的所述部分的至少一部分对应于视频，并且由客户端RTC API引擎308执行的实时媒体应用310的所述部分的剩余部分对应于音频。

替代地，由原生RTC引擎316执行的实时媒体应用310的所述部分的至少一部分对应于音频，并且由客户端RTC API引擎308执行的实时媒体应用310的所述部分的剩余部分对应于视频。

在部分回退中，取决于虚拟桌面服务器302的能力和策略，注入代码以及服务器端代码可以实现部分回退。部分回退不涉及重定向到客户端计算设备304。取而代之地，虚拟桌面服务器302的能力被降低。

在优化模式下，WebRTC重定向框架可以支持音频、视频和数据通信。在部分回退模式下，如果多用户服务器上的服务器端CPU利用率不超过某个值，则框架可能只提供音频和视频。如果超过某个值，则在高CPU负载下自动关闭视频支持，以避免质量问题。类似的回退限制可以通过监视回退会话的媒体质量来实现，并且如果质量保持定义阈值或落到其之下，则禁用一些功能性。

换句话说，如果客户端计算设备304具有有限的能力，并且API代码重定向模块306确定虚拟桌面服务器302也具有有限的能力，则API代码重定向模块306对于实时媒体应用310的所述部分的至少一部分不切换到回退模式，并且实时媒体应用310的所述部分的所述至少一部分既不被客户端RTC API引擎308也不被原生RTC引擎316执行。

例如，既不被客户端RTC API引擎308也不被原生RTC引擎316执行的实时媒体应用310的所述部分的所述至少一部分可以对应于视频，而实时媒体应用310的所述部分的剩余部分由客户端RTC API引擎308或原生RTC引擎316在回退模式下执行，并且可以对应于音频和数据通信中的至少一个。

作为另一示例，API代码重定向模块306可以基于客户端计算设备304策略、虚拟桌面服务器302策略、虚拟桌面服务器302 CPU负载和媒体质量中的至少一个来确定虚拟桌面服务器302也具有有限的能力。

在该情况下，如果客户端计算设备304具有有限的能力，并且API代码重定向模块306确定虚拟桌面服务器302也具有有限的能力，则API代码重定向模块306不针对实时媒体应用310的所述部分的至少一部分切换到回退模式。实时媒体应用310的所述部分的所述至少一部分既不被客户端RTC API引擎308也不被原生RTC引擎316执行。

既不被客户端RTC API引擎308也不被原生RTC引擎316执行的实时媒体应用310的所述部分的所述至少一部分对应于视频，并且实时媒体应用310的所述部分的剩余部分由客户端RTC API引擎308或原生RTC引擎316在回退模式下执行，并且对应于音频和数据通信中的至少一个。

API代码重定向模块306基于客户端计算设备策略、虚拟桌面服务器策略、虚拟桌面服务器CPU负载和媒体质量中的至少一个来确定虚拟桌面服务器302也具有有限的能力。

在会话连接/断开事件到设备可用性事件的映射中，WebRTC包括API子集（NavigatorUserMedia，getUserMedia），其使得应用能够枚举本地媒体设备，请求对本地媒体设备（诸如麦克风或相机）的访问，并将其用于实时媒体会话。在WebRTC重定向下，对应的API将分别枚举物理附接到客户端计算机的设备、获得对所述设备的访问以及请求使用所述设备。

为了处理回退场景，在会话断开时，注入代码将更新内部数据结构，并生成向应用指示所有设备已经物理断开的事件。在会话重新连接时并且在成功的能力协商之后，该代码将向实时媒体应用310指示新设备现在可用。

在回退时，注入代码将遵从内置WebRTC引擎316来枚举本地设备，这进而可以调取其他虚拟通道功能性来枚举客户端设备并执行非优化重定向。例如，这可能是经由通用音频重定向或图形远程处理虚拟通道。利用该方法，被适当设计来处理本地媒体设备可用性的应用将不需要任何特殊的逻辑来处理会话连接/断开和回退事件。

在一个方面，当客户端计算设备304连接到虚拟桌面服务器302时，虚拟桌面服务器302枚举物理连接到客户端计算设备304的设备。当客户端计算设备304与虚拟桌面服务器302断开时，则注入代码314生成向实时媒体应用310指示所有设备已经物理断开的事件。

在客户端计算设备304重新连接到虚拟桌面服务器302时，注入代码314向实时媒体应用310指示新设备现在可用。在回退时，注入代码314遵从原生RTC引擎316来枚举物理连接到客户端计算设备304的设备。

用于在完全优化不可用时提供回退功能性以使用较少优化机制来处理实时媒体的另一方面涉及一种用于操作计算系统300的方法，该计算系统300包括虚拟桌面服务器302和包含客户端RTC API引擎308的客户端计算设备304。虚拟桌面服务器302包括应用框架312和API代码重定向模块306。应用框架312包括实时媒体应用310和原生RTC引擎316。

该方法包括基于实时媒体应用310的操作来提供实时通信（RTC），其中实时媒体应用的一部分将在被原生RTC引擎接收时由原生RTC引擎执行，并且由API代码重定向模块306基于注入到实时媒体应用310中的重定向代码314，来重定向实时媒体应用310的旨在用于原生RTC引擎316的原始API，使得实时媒体应用310的所述部分将被重定向。

该方法进一步包括由客户端RTC API引擎308通过虚拟通道318向API代码重定向模块306报告关于客户端计算设备304执行实时媒体应用310的重定向部分的能力。如果客户端计算设备304具有有限的能力，则操作API代码重定向模块306切换到回退模式，其中在回退模式下，使用至少部分原始API，使得原生RTC引擎316执行实时媒体应用310的所述部分的至少部分。

又一方面涉及一种用于在如上所述的计算系统300内操作虚拟桌面服务器302的非暂时性计算机可读介质。该非暂时性计算机可读介质具有多个计算机可执行指令，用于引起虚拟桌面服务器302基于实时媒体应用310的操作提供实时通信（RTC），其中实时媒体应用310的一部分将在被原生RTC引擎316接收时由原生RTC引擎316执行。该指令进一步引起虚拟桌面服务器302由API代码重定向模块306基于重定向代码314来重定向实时媒体应用310的旨在用于原生RTC引擎316的所拦截API，使得实时媒体应用310的所述部分将被重定向。API代码重定向模块306通过虚拟通道318从客户端RTC API引擎308接收客户端计算设备执行实时媒体应用310的重定向部分的能力。如果客户端计算设备304具有有限的能力，则操作API代码重定向模块306切换到回退模式，其中在回退模式下，使用至少部分原始API，使得原生RTC引擎316执行实时媒体应用310的所述部分的至少部分。

仍然参考图3，现在将在具有窗口监视/叠加检测的WebRTC重定向方面讨论所图示的计算系统300。如下面将详细讨论的，几何形状跟踪用于无缝地提供WebRTC功能性的重定向。使用WebRTC的应用通常通过将媒体流对象连接到HTML5视频元素来渲染接收到的视频流。该元素的可见性和几何形状通常由应用直接管理，或者使用CSS样式信息来管理。

应用通常创建和定位其他UI元素（例如，标签或控制按钮），使得它们在视觉上与视频重叠，并且可以使用透明度来将渲染的视频与应用UI内容混合。UI元素可以被称为非加速图形，并且视频可以被称为加速图形。诸如实时媒体应用310之类的应用可以具有同时渲染实时视频的多于一个活动视频元素（例如，来自视频会议参与者的一个或多个远程视频馈送和来自本地相机的自视图330）。

为了实现WebRTC功能性的无缝重定向，虚拟桌面服务器302上的应用虚拟化框架需要标识和跟踪几个视频元素以及叠加实况视频的任何其他元素的可见性和几何形状。当该信息可用时，客户端计算设备304上的WebRTC重定向代码将使用它来创建、定位和裁剪本地视频渲染窗口，并且可能在这些窗口的顶部上渲染不透明或透明的叠加，以表示对应的应用UI元素。

用于HTML5视频元素的几何形状跟踪可以经由颜色或图案检测。WebRTC应用中视频和其他UI元素的定位和渲染由嵌入在浏览器或应用框架中的HTML渲染引擎处理，并且通常不容易通过HTML渲染器之外的API或其他内省手段而可用。

克服该限制并标识多个HTML5视频区域并跟踪其几何形状的一种可能方式包括以下步骤。一个步骤是使用注入代码314在实时媒体应用310进行API调用以将重定向的媒体流与特定的视频元素连接的时间点，为每个视频元素分配独特的ID。此外，注入代码314引起每个视频区域被绘制有从视频元素ID导出的颜色或图案。例如，这可以包括将元素ID的比特编码在用于均匀绘制的视频区域颜色的比特中，或者编码在用于图案绘制的相邻像素的颜色中。

另一种可能性是使用编码视频元素ID的一维或二维条形码来绘制视频区域。在图形捕获和远程处理代码（应用虚拟化代码的部分）中，使用用于像素颜色或区域图案匹配或条形码扫描的任何可用技术，通过颜色、图案或条形码来检测视频叠加区域。

检测到的区域可能是非矩形的，或者可能被部分裁剪。为了实现正确的几何形状跟踪，将有必要把从注入代码中检索的信息（视频元素ID和像素大小）与上色或图案化区域检测的结果相组合，以确定每个单独视频元素的大小和裁剪几何形状。为了改进性能，可以缓存视频区域检测的结果，并且只对后续帧进行部分重新计算。

如上面所讨论的，图示的计算系统300包括用以提供至少一个视频流的至少一个视频源330、虚拟桌面服务器302和至少一个客户端计算设备304。虚拟桌面服务器302包括应用框架312，该应用框架312包括实时媒体应用310以提供实时通信（RTC），以及包括原生RTC引擎316以在实时媒体应用310的一部分被原生RTC引擎316接收时执行该部分。

API代码重定向模块306基于注入到实时媒体应用310中的重定向代码314来重定向实时媒体应用310的旨在用于原生RTC引擎316的所拦截API，使得实时媒体应用310的所述部分被重定向。特别地，注入的重定向代码314定义至少一个占位符，以指示至少一个视频流在RTC窗口内的定位几何形状。几何形状跟踪模块332检测注入的重定向代码314内的至少一个占位符，并提供与其相关联的定位几何形状。

客户端计算设备304包括显示器334以显示RTC窗口。客户端RTC API引擎308通过虚拟通道318与API代码重定向模块306通信，以执行实时媒体应用310的重定向部分。该虚拟通道318提供加速图形。

特别地，客户端计算设备304进一步包括显示合成模块336，以接收至少一个视频流和至少一个占位符的定位几何形状，并基于定位几何形状将至少一个视频流叠加在所显示的RTC窗口内的至少一个占位符之上。

来自几何形状跟踪模块332的定位数据可以通过两个不同的路径被提供给显示合成模块336。在第一路径中，几何形状跟踪模块332向API代码重定向模块306提供定位几何形状，以便被包括在实时媒体应用310到客户端RTC API引擎308的重定向部分中。客户端RTC API引擎308然后向显示合成模块336提供定位数据。在第二路径中，几何形状跟踪模块332通过不同的虚拟通道319直接向显示合成模块336提供定位几何形状。该虚拟通道319用于非加速图形。

由显示器334所提供的RTC窗口是包括非加速图形和加速图形的合成显示器。例如，非加速图形包括UI元素、标签和控制按钮。图示实施例中的加速图形由本地网络摄像头馈送330提供的视频流定义。显示合成模块336可以诸如从另一个端点设备（诸如客户端计算设备305）接收附加的视频流。

注入的重定向代码314生成非加速图形，但不生成加速图形。这意味着几何形状跟踪模块332分析至少一个占位符的非加速图形。虚拟桌面服务器302还包括非加速图形产生器340，其通过虚拟通道319向客户端计算设备304中的非加速图形模块342提供非加速图形。

现在参考图4-7，将讨论示例窗口监视/叠加检测场景。在该场景下，存在两个视频流源。一个视频流源来自第一客户端计算设备304上的本地网络摄像头馈送330，并且另一个视频流源来自与第一客户端计算设备304进行对等通信的第二客户端计算设备305。

当拦截API时，虚拟桌面服务器302枚举两个视频流源。当调用开始时，客户端计算设备304向实时媒体应用310报告存在来自本地网络摄像头馈送330的第一视频流。类似地，第二客户端计算设备305经由实时媒体应用服务器320向实时媒体应用310报告它具有提供第二视频流的相机。

实时媒体应用310取得两个视频流已经到达的通知，如在所拦截API内检测到的事件所反映的。由于实时媒体应用310不接收实际的视频流，所以它为每个事件创建占位符。每个占位符被绘制在对应视频流当被显示在客户端计算设备304上时将被放置之处。

现在参考图4-7，将讨论图示了具有图3中所图示架构的示例窗口监视/叠加检测场景的各种显示。如窗口400中所示，虚拟桌面服务器302中注入的重定向代码314在来自第二客户端计算设备305的对等视频将被放置之处渲染绿色矩形402，并且在来自本地网络摄像头馈送330的画中画预览视频将被放置之处渲染红色矩形404。

注入的重定向代码314用不同的颜色绘制，其中每种颜色被分配给相应的视频流。ID也可以与每种颜色相关联，以标识相应的视频流。叠加在窗口400上的控件406被正常渲染。

由于窗口400是WebRTC应用框架的一部分，因此实时媒体应用310需要知道视频流将被渲染在何处。几何形状跟踪模块332有利地检测注入的重定向代码314内的不同占位符，并且向显示合成模块336提供与每个占位符相关联的定位几何形状。定位几何形状提供了视频流将放置之处的x-y坐标连同分辨率。

例如，几何形状跟踪模块332基于颜色（诸如绿色和红色）检测不同的占位符。在其他实施例中，可以用图案或条形码来检测不同的占位符。此外，不同的颜色、图案和条形码可以各自具有与其相关联的对应于相应视频流的ID。此外，占位符颜色可以在被几何形状跟踪模块检测到之后改变为与呈现在客户端计算设备304上的窗口相混合的更中性的颜色。

窗口400被发送到客户端计算设备304。客户端计算设备304内的显示合成模块336渲染来自第二客户端计算设备305的视频流412，这基于与其相关联的指定位置几何形状，如图5中的窗口410中所示。渲染的视频流412包括用于控件406的剪切部分414和用于来自本地网络摄像头馈送330的视频流的剪切部分416。

客户端计算设备304内的显示合成模块336还渲染来自本地网络摄像头馈送330的视频流422，这基于与其相关联的指定位置几何形状，如图6中的窗口420中所示。渲染的视频流422不像渲染的视频流412那样需要任何剪切部分。

在由显示合成模块336合成之后，视频流以正确的形状出现在正确的位置中。图7中的窗口410包括位于绿色占位符402之上的来自第二客户端计算设备305的视频流412、位于红色占位符404之上的来自本地网络摄像头馈送330的视频流422、以及由虚拟桌面服务器302所提供的控件406。

使用由虚拟桌面服务器302发送的图形，在客户端计算设备304的显示器334上绘制虚拟桌面连同托管的实时媒体应用的非加速内容406（控件）和其他托管的应用窗口。加速内容后面的屏幕区域、诸如该示例中的绿色矩形402和红色矩形404也渲染在客户端计算设备304的显示器334上，但是它们对于用户不是可见的，因为它们分别被来自第二客户端计算设备305的对等视频412和来自本地网络摄像头馈送330的画中画预览视频422的加速本地渲染内容叠加。

现在参考图8中的窗口410和420，底层服务器端窗口400已经被移动到不同的位置。虚拟桌面服务器302中注入的重定向代码314在新位置中渲染占位符。特别地，绿色矩形402被渲染在将放置来自第二客户端计算设备305的对等视频之处，并且红色矩形404被渲染在将放置来自本地网络摄像头馈送330的画中画预览视频之处。例如控件406的非加速图形通常由非加速图形产生器340渲染在新位置中。

作为视频的结果，几何形状和非加速图形异步更新，先接收到的任何一个在另一个之前被更新。作为结果，视频叠加412、422可能看起来与底层占位符断开。这可以被认为是暂时的伪像。

在该示例中，首先更新服务器端窗口400的定位和非加速图形。客户端计算设备304然后从虚拟桌面服务器302接收占位符的更新的定位几何形状，并且然后用更新的定位几何形状渲染相应的视频流412、422。在合成之后，窗口410和420在新位置中，如图9中所图示的。

现在参考图10中的窗口410，重叠应用430由虚拟桌面服务器302渲染在窗口400之上，窗口400进而裁剪客户端计算设备304上的视频流412。尽管视频流412的位置将不会改变，但是视频流412的形状将会改变。因此，虚拟桌面服务器302中的几何形状跟踪模块332向客户端计算设备304中的显示合成模块336提供定位几何形状更新。

由于视频流412和422、几何形状和非加速图形406是异步更新的，几何形状可以被更改以适应叠加窗口430的早或晚。在该示例中，首先更新视频流412和422以及非加速图形406，并且应用的底部不是可见的，直到客户端计算设备304处理了几何形状更新。

客户端计算设备304从虚拟桌面服务器302接收占位符的更新的定位几何形状，并且然后用更新的定位几何形状渲染相应的视频流412、422，而同时窗口430看起来无遮挡。在合成之后，视频流412出现在相同的位置中但是具有正确的形状，从而显露出叠加窗口430的非加速图形，如图11中所图示的。

具有窗口监视/叠加检测的WebRTC重定向的另一方面涉及一种用于操作计算系统300的方法，该计算系统300包括至少一个视频源330、虚拟桌面服务器302和客户端计算设备304，该客户端计算设备304包括客户端RTC API引擎308、显示器334和显示合成模块336。虚拟桌面服务器302包括几何形状跟踪模块332、应用框架312和API代码重定向模块306。应用框架312包括实时媒体应用310和原生RTC引擎316。

该方法包括提供来自至少一个视频源330的至少一个视频流412，以及基于实时媒体应用310的操作提供实时通信（RTC），其中实时媒体应用310的一部分将在被原生RTC引擎316接收时由原生RTC引擎316执行。

该方法进一步包括由API代码重定向模块306基于注入到实时媒体应用310中的重定向代码314来重定向实时媒体应用310的旨在用于原生RTC引擎的所拦截API，使得实时媒体应用310的所述部分被重定向。注入的重定向代码314定义至少一个占位符402，以指示至少一个视频流412在RTC窗口410内的定位几何形状。

操作几何形状跟踪模块332以检测注入的重定向代码314内的至少一个占位符402，并提供与其相关联的定位几何形状。RTC窗口被显示在显示器334上。客户端RTC API引擎308被操作来通过虚拟通道318与API代码重定向模块306通信，以执行实时媒体应用310的重定向部分。

操作显示合成模块336以接收至少一个视频流412和至少一个占位符402的定位几何形状，并基于定位几何形状将至少一个视频流412叠加在所显示RTC窗口410内的至少一个占位符402之上。

又一方面涉及一种用于在如上所述的计算系统300内操作虚拟桌面服务器302的非暂时性计算机可读介质。该非暂时性计算机可读介质具有多个计算机可执行指令，用于引起虚拟桌面服务器302基于实时媒体应用310的操作提供实时通信（RTC），其中实时媒体应用310的一部分将在被原生RTC引擎316接收时由原生RTC引擎316执行。

这些步骤进一步包括由API代码重定向模块306基于注入到实时媒体应用310中的重定向代码314来重定向实时媒体应用310的旨在用于原生RTC引擎316的所拦截API，使得客户端RTC API引擎308通过虚拟通道318与API代码重定向模块306通信，并执行实时媒体应用310的重定向部分。注入的重定向代码314定义至少一个占位符402，以指示至少一个视频流412在RTC窗口410内的定位几何形状。

操作几何形状跟踪模块332以检测注入的重定向代码314内的至少一个占位符402，并提供与其相关联的定位几何形状，使得客户端计算设备304操作客户端RTC API引擎308通过虚拟通道318与API代码重定向模块306通信，以执行实时媒体应用310的重定向部分。操作显示合成模块336以接收至少一个视频流412和至少一个占位符402的定位几何形状，并基于定位几何形状将至少一个视频流412叠加在所显示RTC窗口410内的至少一个占位符402之上。

几何形状跟踪包括半透明叠加的检测和重新绘制。上述技术可以对在视频元素顶部上使用任意不透明UI叠加的应用起作用。为了解决半透明叠加，相同的方法可以如下扩展。

通过注入代码对视频区域的绘制可以以如下方式设计：即使在由于半透明叠加所致的颜色变换之后也将允许鲁棒的图案检测。例如，元素ID可以使用具有高度区分颜色的像素进行编码，而检测代码可以被设计为接受像素颜色中小得多或经偏移的差异（由于颜色混合）。预定义的图像图案和信息冗余技术（诸如条形码中使用的各种校验和）可以用于改进视频区域的可检测性。

此外，视频区域的绘制可以被设计成对每个像素使用两种或更多种不同的颜色而随时间变化。

检测代码可以被扩展以从捕获的屏幕像素中导出关于半透明叠加的信息。为此，检测代码将会把预期的像素颜色与实际捕获的像素进行比较。对于具有两种交替颜色的最简单的实现，并假设在两个时间实例处的线性混合模型：

1）（时间1处的像素颜色）=（1–阿尔法）*（时间1处的底层颜色）+ 阿尔法 *（叠加颜色）

2）（时间2处的像素颜色）=（1–阿尔法）*（时间2处的底层颜色）+ 阿尔法 *（叠加颜色）

阿尔法和叠加颜色两者可以以可接受的精度损失恢复：

阿尔法 = 1–（时间2处的像素颜色–时间1处的像素颜色）/（时间2处的底层颜色–时间1处的底层颜色）

叠加颜色=（像素颜色–（ 1-阿尔法）*底层颜色）/阿尔法。

图13是上述检测半透明叠加的方法的说明性表格图500。输入列510指定在红色（R）、绿色（G）和蓝色（B）像素颜色值和不透明度或阿尔法值方面描述的叠加颜色的不同组合。混合列520指定了两种不同的颜色，在该示例中是黑色混合522和白色混合524，它们可以由注入代码在两个不同的时间（例如时间1和时间2）处使用，如上面所讨论的。

捕获/恢复列530指定由图形捕获和远程处理代码恢复的阿尔法和像素颜色的相应计算值。例如，当阿尔法值为零（0）时，叠加完全不可见。在该特定情况下，由于被零除的错误，叠加颜色不能被检测到，如检测到的颜色像素中的零所图示的。然而，这甚至是不必要的，因为在不透明度为零（0）的情况下，叠加反正也不是可见的。在另一个示例中，并且在阿尔法值为一（1）的另一个极端情况下，叠加完全遮蔽混合颜色。

图14是在上述检测半透明叠加的方法的测试运行中使用的样本色带图像540。

图15是上述检测半透明叠加的方法的测试运行的说明性图像比较图。特别地，图15提供了上述方法在图14的样本图像上的测试运行的视觉图示，该样本图像包含具有不同颜色和不透明度的色带。

左上角的图像550是原始（之前）图像，而右上角的图像552是计算或检测的（之后）图像。在两个图像之间没有可感知的差异。然而，在不透明度的极值处，例如，当阿尔法值接近于零（0）或接近于一（1）时，由于像素颜色值舍入不准确，前和后图像可能开始略有不同。这在底部图像554中图示，底部图像554渲染检测到的色带图像的灰色标度版本。出于严格说明的目的，提供以下内容。

原始（之前）图像和检测到的（之后）图像两者中具有相同颜色值的像素以该共享颜色值的灰色标度表示进行渲染。

在原始（之前）图像和检测到的（之后）图像中具有不同颜色值的像素（其中差异在预设阈值以下）以检测到的颜色值的蓝色标度表示进行渲染。

在原始（之前）图像和检测到的（之后）图像中具有不同颜色值的像素（其中差异在预设阈值以上）以检测到的颜色值的红色标度表示进行渲染。

在该示例中，阈值已经被定义为255个单位总数中的5个单位的差异，或近似2个百分数的差异。

图16是上述检测半透明叠加的方法中的步骤的说明性图像560。特别地，图16图示了在与图14的色带图像组合地应用黑色混合之后，在时间一（1）处由检测代码观察到的图像560。

图17是上述检测半透明叠加的方法中的另一步骤的另一说明性图像570。特别地，图17图示了在与图14的色带图像组合地应用白色混合之后，在时间二（2）处由检测代码观察到的图像570。更多的交替颜色可以用来改进准确性和解决临界情况。

如下面将参考图18进一步详细讨论的，通过提供从检测代码到注入代码的反馈通道，可以改进该过程的准确性。通过使用该反馈通道，检测代码将能够使用特定的或自适应的颜色或图案来请求视频区域绘制，以改进检测过程的鲁棒性和准确性。

空间滤波技术也可以用来改进该过程。例如，相同的阿尔法值很可能将用于半透明叠加的大的相邻区域。考虑到这一点，可以使用滤波器来对恢复的每像素阿尔法值进行平均，并接受更准确的滤波值用于进一步的计算。

包括阿尔法和像素颜色值在内的关于半透明叠加的信息可以从服务器302’传输到客户端304’，并渲染在客户端本地视频的顶部上，从而导致应用UI的准确再现。

在服务器端的HTML渲染引擎的监测（instrumentation）中，上述两种技术使得在不监测HTML渲染引擎的情况下检测视频区域几何形状成为可能。渲染引擎的直接监测提供了实现相同目的的另一种方式。对于该技术，浏览器或应用框架312’中的HTML渲染引擎可以被钩取或部分替换，使得可以直接检索关于视频元素定位和叠加的信息。

作为又一种方法，可以使用自定义的基于Chromium的浏览器引擎来监测HTML渲染。例如，作为Citrix安全浏览器云服务的一部分。

如上面所讨论的，图3中所图示的架构300支持如针对WebRTC API重定向的半透明叠加406的检测和重新绘制。在其他实施例中，可以修改架构300以支持包括半透明叠加406的任何加速图形媒体。在图18中提供了这样的架构300’。

在所图示的架构300’中，应用框架312’现在包括代替实时媒体应用310的媒体应用311’、代替注入重定向代码模块314和原生RTC引擎316的加速内容重定向模块315’，以及代替RTC API代码重定向模块306的主机端虚拟通道重定向模块307’。在客户端计算设备304’上，RTC API引擎308被与主机端虚拟通道重定向模块307’通信的客户端虚拟通道重定向模块309’替换。

加速内容重定向模块315’基于以下各项中至少一个来重定向媒体流式传输的部分：DirectShow（直接示出）滤波器、DirectX媒体对象（DMO）滤波器、媒体基础滤波器、HTML5视频重定向模块、Flash视频重定向模块、浏览器助手对象（BHO）和浏览器扩展。CitrixRAVE（远程处理音频和视频扩展）技术使用DirectShow滤波器、DirectX媒体对象（DMO）滤波器和媒体基础滤波器。Citrix HTML5视频重定向技术使用HTML5视频重定向模块。CitrixFlash视频重定向技术使用Flash视频重定向模块。

对于用以播放文件的媒体应用311’，考虑到各种因素，诸如文件的源、文件格式和文件内部的媒体格式。基于这些因素，可以注册一个或多个滤波器。滤波器包括源滤波器、转换滤波器和渲染滤波器，它们允许文件的解压缩和渲染被重定向到客户端计算设备304’。

主机端滤波器将来自虚拟桌面服务器302’的仍然压缩的视频和音频数据代理到客户端计算设备304’。在客户端计算设备304’处，加载一个或多个客户端本地滤波器来解压缩视频和音频数据、渲染视频和播放音频。包括窗口定位信息和附加流控制信息的控制信息也由一个或多个主机端滤波器提供。

仍然参考图18和架构300’，加速内容重定向模块315’生成非加速图形，但不生成加速图形。这意味着几何形状跟踪模块332’分析至少一个占位符的非加速图形。虚拟桌面服务器302’还包括非加速图形产生器340’，其通过虚拟通道319’向客户端计算设备304’中的非加速图形模块342’提供非加速图形。

架构300’包括至少一个视频源305’，以提供至少一个视频流313’。视频源305’可以被称为加速内容媒体源。虚拟桌面服务器302’包括应用框架312’，应用框架312’包括媒体应用311以提供媒体流式传输。媒体流包括至少一个视频流313’，具有至少一个叠加406将定位在该至少一个视频流313’上。加速内容重定向模块315’将通过提供占位符402来重定向媒体流式传输的一部分，以指示至少一个视频流313’在媒体窗口334’内的定位几何形状。占位符402将包括叠加406。

提供占位符402包括在第一时间处为占位符402的底层提供第一颜色522，以及在第二时间处为占位符402的底层提供第二颜色524。

几何形状跟踪模块332’将检测占位符402并确定与其相关联的定位几何形状，并基于涉及占位符402的底层在第一时间处的第一颜色522和占位符402的底层在第二时间处的第二颜色524的计算，来确定叠加406的颜色和阿尔法混合因子。该计算如上所述，使用等式一（1）和二（2）。

叠加406的所确定的颜色和阿尔法混合因子被说明性地提供在图13中的捕获/恢复列530中。Comp.A是阿尔法混合因子。红色（R）、绿色（G）和蓝色（B）像素颜色值中的每一个由Comp.R、Comp.G和Comp.B表示。

客户端计算设备304’包括用以显示媒体窗口334’的显示器。客户端上的虚拟通道重定向模块309’通过虚拟通道318’与加速内容重定向模块315’通信，以执行媒体应用的重定向部分。

显示合成模块336’将接收视频流313’、占位符402的定位几何形状以及叠加406的每个像素的颜色和阿尔法混合因子，以便基于定位几何形状将视频流313’叠加在显示窗口334’内的占位符402之上，并且以与叠加406相关联的颜色和阿尔法混合因子来叠加该叠加406。

如上文在一个示例中所讨论的，虚拟桌面服务器302中的API代码重定向模块306在来自第二客户端计算设备305的对等视频将被放置之处上渲染绿色矩形402（作为占位符）。类似地，在图18中所图示的架构300’的上下文中，虚拟桌面服务器302’中的主机端重定向模块307’可以在来自第二客户端计算设备305’的对等视频将被放置之处上渲染绿色矩形402（作为占位符）。由于位于绿色矩形402之上的叠加406具有零（0）的不透明度，所以不需要确定叠加的阿尔法混合因子和颜色。

对于半透明叠加406，将生成两（2）种或更多种混合颜色，而不是单个颜色。占位符402（其包括叠加颜色）中的每个像素颜色值由几何形状跟踪模块332’确定。

对于图18中所图示的架构300’，加速内容重定向模块315’在时间一（1）处生成具有底层颜色522的占位符402，并且然后在时间二（2）处生成具有底层颜色524的占位符402。加速内容重定向模块315’告诉几何形状跟踪模块332’在时间一（1）和二（2）处使用的底层颜色。几何形状跟踪模块332’使用如上所讨论的等式（1）和（2）来计算叠加406的每个像素的阿尔法混合因子和颜色。由于存在两个等式和两个未知数，所以这两个未知数（即，阿尔法混合因子和叠加颜色）。

在一些情况下，黑和白底层颜色可能太接近叠加406的颜色。为了改进底层颜色和叠加颜色之间的颜色对比度，几何形状跟踪模块332’向加速内容重定向模块315’提供反馈，以变化第一和第二底层颜色。例如，黄色和绿色可以用来代替黑色和白色来提供更好的颜色对比度。

显示的媒体窗口334’包括非加速图形和加速图形的合成显示，其中加速图形由视频流313’定义。媒体流式传输的重定向部分仅生成非加速图形，并且几何形状跟踪模块332’分析占位符402和叠加406的非加速图形。

视频源可以是耦合到客户端计算设备304的相机330，如图3中所图示的。替代地或除此之外，视频源可以是耦合到与客户端计算设备304’进行对等通信的不同客户端计算设备305’的相机。

视频源是加速内容媒体源。加速内容媒体源是以下各项中的至少一个：视频流式传输网站、视频内容交付网络（CDN）、视频文件共享、DVD。

视频源可以包括耦合到与客户端计算设备304’对等通信的不同客户端计算设备305’的共享显示表面。这覆盖屏幕共享，其中共享的显示表面可以用半透明叠加406叠加。

半透明叠加406的检测和重新绘制的另一方面涉及一种用于操作包括至少一个视频源305’和虚拟桌面服务器302’的计算系统300的方法，其中虚拟桌面服务器302’包括几何形状跟踪模块332’、应用框架312’和加速内容重定向模块315’。应用框架312’包括媒体应用311’。该方法包括从至少一个视频源305’提供至少一个视频流313’，并基于媒体应用的操作提供媒体流式传输，其中媒体流式传输包括至少一个视频流313’和至少一个视频流313’上的至少一个叠加406。

通过提供占位符402来指示至少一个视频流313’在媒体窗口334’内的定位几何形状，来重定向媒体流式传输的一部分，其中占位符402用以包括至少一个叠加406。

提供占位符402包括在第一时间处为占位符402的底层提供第一颜色522，以及在第二时间处为占位符402的底层提供第二颜色524。

该方法进一步包括操作几何形状跟踪模块332’来检测占位符402并确定与其相关联的定位几何形状，并且基于涉及占位符402的底层在第一时间处的第一颜色522和占位符402的底层在第二时间处的第二颜色524的计算，来确定至少一个叠加406的颜色和阿尔法混合因子。

又一方面涉及一种用于在包括至少一个视频源305’的计算系统300’内操作虚拟桌面服务器302’的非暂时性计算机可读介质，其中虚拟桌面服务器302’包括几何形状跟踪模块332’、应用框架312’和加速内容重定向模块315’。应用框架312’包括媒体应用311’。

该非暂时性计算机可读介质具有多个计算机可执行指令，用于引起虚拟桌面服务器302’基于媒体应用311’的操作提供媒体流式传输，其中媒体流式传输包括至少一个视频流313’和至少一个视频流313’上的至少一个叠加406。

通过提供占位符402来指示至少一个视频流313’在媒体窗口334’内的定位几何形状，来重定向媒体流式传输的一部分，其中占位符402用以包括至少一个叠加406。

提供占位符402包括在第一时间处为占位符402的底层提供第一颜色522，以及在第二时间处为占位符402的底层提供第二颜色524。

操作几何形状跟踪模块332’来检测占位符402并确定与其相关联的定位几何形状，并且基于涉及占位符402的底层在第一时间处的第一颜色522和占位符402的底层在第二时间处的第二颜色524的计算，来确定至少一个叠加406的颜色和阿尔法混合因子。

现在参考图3和12，将在用以实现WebRTC功能性的无缝重定向的屏幕共享功能性方面讨论所图示的计算系统300。WebRTC包括在[屏幕捕获]中定义的API（getDisplayMedia）和其他相关的API元素，其允许应用共享本地浏览器窗口、不同应用的单个窗口、特定应用的所有窗口、单个监视器或包括整个桌面的监视器集合的视觉内容。

桌面虚拟化下的屏幕共享呈现特定挑战，这是由于完整的用户可见桌面如何由运行在一个或多个虚拟桌面服务器上以及本地桌面上的部分组成的复杂性。运行在任何特定物理或虚拟计算机上的应用或框架代码可能能够枚举用户可能感兴趣的或者可能没有对特定窗口或监视器的像素的访问的可共享屏幕内容的全部源。WebRTC重定向框架可以被设计来处理该复杂性，同时为屏幕共享提供优化的用户体验。

于2018年1月26日作为美国专利申请号15/880938提交的Citrix专利申请ID1167US“Virtual Computing System Providing Local Screen Sharing from HostedCollaboration Applications and Related Methods”通过引用以其整体并入本文。ID1167US中讨论的方法完全适用于WebRTC重定向。本公开提供了下面讨论的附加增量提升：1）可共享内容源的分布式枚举，以及2）内容共享媒体和网络流水线的优化。

在可共享内容源的分布式枚举中，WebRTC重定向框架的元素（连接器、引擎以及可能的虚拟桌面服务器和客户端代码）可以被设计成在虚拟桌面服务器302和客户端计算设备304、305上并行枚举可能的内容共享源（应用及其窗口、监视器和桌面）。桌面虚拟化系统内部的信息可以用于创建这些源的正确描述（例如，将窗口与对应的应用正确关联）。组件间协议可以用于将该信息整合到单个列表中，并在应用调用getDisplayMedia()时向用户呈现所得列表。

在内容共享媒体和网络流水线的优化中，当用户选择特定的屏幕共享源时，WebRTC重定向代码可以选择对于捕获该源的内容的最佳位置。例如，如果用户选择虚拟应用窗口，则应当在虚拟桌面服务器302上捕获该窗口的内容，因为该窗口在客户端计算设备304上可能被遮蔽。替代地，如果选择整个客户端桌面进行共享，则因为图形反正已经被交付到客户端计算设备，并且为了避免虚拟桌面服务器302上的附加负载，因此应当在客户端计算设备304上捕获桌面的像素。

进一步的优化可以将虚拟桌面客户端应用中的屏幕渲染流水线与用于屏幕内容共享的WebRTC重定向捕获流水线相组合。

除了选择用于捕获可共享屏幕内容的最佳位置之外，WebRTC重定向代码还可以选择用于使用合适的视频编解码器压缩该内容的最佳位置和方法，以及用于将该内容传输到远程目的地的网络端点。例如，在虚拟桌面服务器302上捕获的屏幕内容可以在虚拟桌面服务器302上被适当地压缩，从虚拟桌面服务器302流式传输到客户端计算设备304，并从客户端计算设备304传输到网络。

替代地，相同的屏幕内容可以仅在虚拟桌面服务器302上被适度压缩，并在客户端计算设备304上实现最终压缩。替代地，可以从虚拟桌面服务器302压缩和传输相同的屏幕内容，根本不涉及客户端计算设备304。这些选择呈现了不同的服务器和网络可扩展性以及网络连接性权衡，并且可以基于策略或其他准则进行选择。

如图12中所图示的，计算系统300有利地提供了与第二客户端计算设备305共享第一客户端计算设备304上的本地和虚拟客户端表面331、335两者。注入的重定向代码314用于枚举来自客户端计算设备304（本地客户端表面331）和来自虚拟桌面服务器302（虚拟桌面会话355）的共享表面，并将它们组合在一起成为单个列表。虚拟桌面服务器302包括监视器353以生成虚拟桌面会话355。

虚拟桌面会话355的一个或多个元素在第一客户端计算设备304处被渲染为第一监视器333上的虚拟客户端表面335，第一监视器333说明性地包括虚拟会话用户接口（UI）337。然而，第一客户端计算设备304这里在第二监视器329上还生成其自己的本地客户端图形表面331。本地图形表面331可以包括本地安装在客户端计算设备304处的应用（web浏览器、文档处理应用等）。

应当指出，在不同的实施例中，本地和虚拟客户端表面331、335两者可以显示在同一监视器上，即，它们不需要在所有实施例中都在多个监视器上。如上面指出的，在实时媒体应用310的情况下，对于第一客户端计算设备304的用户而言，当前没有方法共享本地图形表面331。

然而，一旦实时媒体应用310被启动，虚拟桌面服务器302就使用注入的重定向代码314来枚举来自客户端计算设备304（本地客户端表面331）和来自虚拟桌面服务器302（虚拟客户端表面335）的共享表面，并将它们组合在一起成为呈现给第一客户端计算设备304的用户的单个列表。

这是在不需要虚拟桌面服务器302处的虚拟网络摄像头和虚拟即插即用（PnP）监视器（如上面引用的Citrix专利申请ID1167US中所需要的）的情况下完成的。在Citrix专利申请ID1167US中，客户端表面在虚拟桌面服务器环境中被枚举。这里，所图示的计算系统300正在相反地进行。计算系统300枚举客户端表面（本地的和/或虚拟的），并将它们投影到第一客户端计算设备304，因此它们可以更高效地被对等发送到第二客户端计算设备305。

第二客户端计算设备305在第一监视器363上生成虚拟客户端共享表面365。第二客户端计算设备305这里在第二监视器359上还生成其自己的本地客户端图形共享表面361。

实时媒体应用310提供枚举表面的单个列表。第一客户端计算设备304的用户可以点击按钮或提示来共享表面（例如，窗口、监视器或桌面）并且这触发了那些表面的枚举。由于getDisplayMedia API元素被拦截，所以可以组合枚举的本地和虚拟客户端表面331、335。

更特别地，所图示的计算系统300包括用以显示本地客户端表面331和虚拟客户端表面335的第一客户端计算设备304，其中本地客户端表面331和虚拟客户端表面335将与具有与第一客户端计算设备304的对等通信的第二客户端计算设备305共享。

虚拟桌面服务器302通过虚拟通道318与第一客户端计算设备304通信以提供虚拟客户端表面335，并且包括应用框架312，该应用框架312包括：实时媒体应用310，用以提供实时通信（RTC）；和原生RTC引擎316，用以在实时媒体应用310的一部分被原生RTC引擎316接收时执行该部分。

虚拟桌面服务器302内的API代码重定向模块306基于注入到实时媒体应用310中的重定向代码314来重定向实时媒体应用310的旨在用于原生RTC引擎316的所拦截API，使得实时媒体应用310的所述部分被重定向，其中注入的重定向代码314枚举本地和虚拟客户端表面331、335。

第一客户端计算设备304包括客户端RTC API引擎308，其通过虚拟通道318与API代码重定向模块306通信，以执行实时媒体应用310的重定向部分，并基于枚举本地和虚拟客户端表面331、335的所拦截API与第二客户端计算设备305共享本地和虚拟客户端表面331、335。

如上面指出的，可能存在用于捕获源内容的最佳位置。例如，虚拟客户端表面335可以包括重叠窗口。如果重叠窗口之一被选择与第二客户端计算设备305共享，则从虚拟桌面服务器302获得所选窗口的像素。作为另一个示例，虚拟桌面服务器302的整个虚拟桌面会话355将被共享。在该情况下，虚拟桌面会话355的像素在第一客户端计算设备304上被捕获，以被交付到第二客户端计算设备305。

还如上面所指出的，屏幕渲染流水线和RTC重定向捕获流水线可以被组合。例如，虚拟桌面会话355可以包括将与第二客户端计算设备305共享的至少一个窗口。然后共享窗口的像素将由虚拟桌面服务器302提供给第二客户端计算设备305。

在压缩方面，可以选择用于压缩可共享屏幕内容的最佳位置。例如，虚拟桌面服务器302可以压缩至少一个窗口的像素。如果要与第二客户端计算设备305共享该窗口，则共享窗口的压缩像素被发送到第一客户端计算设备304，以便与第二客户端计算设备305共享。

具有屏幕共享的WebRTC重定向的另一方面涉及一种用于操作计算系统300的方法，计算系统300包括虚拟桌面服务器302和包含客户端RTC API引擎308的第一客户端计算设备304，如上面所讨论的。该方法包括操作第一客户端计算设备304来显示本地客户端表面331和虚拟客户端表面335，其中本地客户端表面331和虚拟客户端表面335将与具有与第一客户端计算设备304的对等通信的第二客户端计算设备305共享。

操作虚拟桌面服务器302以通过虚拟通道318与第一客户端计算设备304通信，以提供虚拟客户端表面335。实时通信（RTC）是基于实时媒体应用310的操作来提供的，其中实时媒体应用310的一部分将在被原生RTC引擎316接收时由原生RTC引擎316执行。

API代码重定向模块306基于被注入到实时媒体应用310中的重定向代码314来重定向实时媒体应用310的旨在用于原生RTC引擎316的所拦截API，使得实时媒体应用310的所述部分被重定向，其中注入的重定向代码314枚举本地和虚拟客户端表面331、335。

操作客户端RTC API引擎308以通过虚拟通道318与API代码重定向模块306通信，以执行实时媒体应用310的重定向部分。进一步操作客户端RTC API引擎308来基于枚举本地和虚拟客户端表面331、335的所拦截API，与第二客户端计算设备305共享本地和虚拟客户端表面331、335。

又一方面涉及一种用于在如上所述的计算系统300内操作虚拟桌面服务器302的非暂时性计算机可读介质。该非暂时性计算机可读介质具有多个计算机可执行指令，用于引起虚拟桌面服务器302通过虚拟通道318与第一客户端计算设备304通信，以提供虚拟客户端表面335，并基于实时媒体应用310的操作提供实时通信（RTC）。实时媒体应用310的一部分将在被原生RTC引擎316接收时由原生RTC引擎316执行。

API代码重定向模块306基于注入到实时媒体应用310中的重定向代码314拦截实时媒体应用310的旨在用于原生RTC引擎316的API，使得客户端RTC API引擎308通过虚拟通道318与API代码重定向模块306通信以执行实时媒体应用310的重定向部分。注入的重定向代码314枚举本地和虚拟客户端表面331、335，使得第一客户端计算设备304基于枚举本地和虚拟客户端表面331、335的所拦截API，与第二客户端计算设备305共享本地和虚拟客户端表面331、335。

在瘦客户端资源管理中，WebRTC可能在多于一个浏览器选项卡中是活动的，例如诸如用于视频渲染。浏览器可以决定在非活动选项卡中暂停视频回放。可推测，这将反映到与托管应用的非活动选项卡中的HTML5视频元素相连接的MediaStream对象上。实时媒体应用310可能在多个浏览器选项卡中是活动的，并且客户端计算设备304在非活动浏览器选项卡中暂停视频回放和/或停止在非可见区域中的渲染。

此外，独立于托管应用的非活动浏览器选项卡的动作，接收器可以决定在非可见区域中自动停止WebRTC渲染。这可以有条件地——例如在可能资源缺乏的瘦客户端设备上完成，或者在带宽有限的情况下完成——这可以改进其他活动选项卡和WebRTC通道中的UX。

现在将讨论安全策略。浏览器应用中的实时媒体支持涉及非常大量的安全和隐私考虑。这样的考虑的不完整示例列表包括：通过得到对用户工作区或家中的麦克风和相机的未经授权访问而侵犯用户隐私的可能性；由于未经授权的内容共享所致的安全漏洞；以及通过枚举连接的设备对用户或他们的端点进行不期望的采指纹的可能性。例如，虚拟桌面服务器302包括至少一个安全策略，并且客户端RTC API引擎308对实时媒体应用的重定向部分的至少一部分的执行基于该至少一个安全策略。WebRTC重定向需要解决这些忧虑，并且还可以在安全和隐私领域中实现多个附加的策略和监视特征，包括以下内容。

使得管理员能够为WebRTC重定向总体和为WebRTC功能性的特定子集（例如，对麦克风、相机、扬声器或屏幕内容以及回退场景中的所有相同功能的访问）定义“自动允许”、“自动拒绝”或“询问用户”策略。

允许将用户身份、安全组中的成员身份或其他用户属性用作到WebRTC相关策略的输入。

允许将应用身份用作到WebRTC相关策略的输入。例如，应用虚拟化框架可以自动检测特定的SaaS应用，并应用特定于该应用的策略。

允许端点位置（物理或网络）用作到WebRTC相关策略的输入。例如，对于在安全位置中的端点，该框架可能自动禁止视频和内容共享，只允许音频会话。

现在将讨论网络连接性控制、ICE扩展和SDP重写。WebRTC功能性中的大部分在于使能实时媒体的对等网络连接性。以下简要标识用于这点的技术：

WebRTC实现ICE（交互式连接性建立）程序，以标识两个实时媒体端点之间所有可能的连接性选项。

作为ICE程序的部分，WebRTC收集所有连接性候选——可用于通信的本地网络端点（传输/IP地址/端口元组）。

WebRTC可以与一个或多个连接性服务器（替代地称为媒体中继服务器、STUN服务器、TURN服务器或ICE服务器）——通过允许端点针对NAT的存在探测网络（使用STUN协议），并在服务器上创建媒体中继点，并将这些端口用作替代连接性候选（使用TURN协议）来促进连接性的网络服务器——来一起工作。

WebRTC使用SDP协议（会话描述协议）来编码和交换网络连接性细节。SDP消息（会话描述）包含媒体会话的完整描述，包括关于连接性候选的信息。

缺乏网络连接性或受损的网络连接性是桌面虚拟化部署的典型忧虑。为了解决这些，WebRTC重定向框架可以使用以下新颖技术：1）隧道传输服务器端传输回退，以及2）改变ICE服务器集合。

在隧道传输服务器端传输回退中，理想情况下，端点应当能够直接通过UDP交换媒体流，并且如果这不可能，则使用TURN服务器来中继媒体分组。如果这些选项中没有一个可用，则实时连接性将是不可能的。

WebRTC重定向具有在虚拟桌面服务器上和客户端上运行的组件，从而提供附加的连接性选项。也就是说，可能的是：通过专用或共享虚拟通道在客户端和服务器之间隧道传输媒体分组流，并使用服务器上的端口或端口集合作为网络端点。该传输选项可能在许多场景下非常有用，例如当直接连接性或中继服务器都不可用时。

为了实现该选项，WebRTC重定向框架必须a）实现按需从连接器打开服务器端UDP端口并通过虚拟通道在它和客户端引擎之间中继媒体分组的功能性，b）使用服务器端IP地址和端口作为ICE过程的附加候选。ICE要求对其中附加连接性必要的所有媒体流重复这点。

在改变ICE服务器集合中，WebRTC应用通常从应用特定的源（例如，应用的服务器端部分）接收ICE服务器集合。WebRTC重定向框架可以用一个或多个服务器的框架特定集合来扩展、改变或替换应用定义的ICE服务器集合，以实现各种类型的流量控制功能性。

例如，与桌面虚拟化框架集成的多用途网关或分支器具可以充当附加的ICE（媒体中继）。WebRTC重定向框架可以使该服务器自动可用于由虚拟化WebRTC应用管理的媒体流量。替代地，WebRTC框架可以用不同的集合替换应用旨在使用的ICE服务器集合。这可以使用网络连接性探测、动态DNS或其他类似技术来确定，以通过最佳媒体流路由来改进媒体质量。

在WebRTC活动和质量监视中，WebRTC重定向框架对实时媒体活动具有完全的可见性，并且可以实现各种类型的活动和质量监视。例如，实时媒体监视统计量可以与桌面虚拟化框架产生的其他资源使用和质量指标相组合，并且用于向系统和应用管理员以及其他决策制定者呈现更全面的视图。

在虚拟应用/桌面会话协作中，将讨论共享的HDX会话用例。在HDX虚拟会话共享或协作期间，将存在发起者和任何数量的协作者。发起者将始终拥有HDX会话。发起者邀请协作者加入或共享会话。所有协作者将在接收器处具有独立的协议栈。

在虚拟桌面服务器处，所有协作者都可以共享协议栈。包括策略、邀请、认证、安全、输入仲裁以及与共享HDX会话生存期相关的其他核心机制在内的协作会话的管理在本公开的范围之外。

服务器连接器代码可以聚合来自所有端点的设备。例如，网络摄像头可以从发起者和所有协作者中枚举，并在应用的上下文中呈现给获取用户媒体WebRTC API（NavigatorUserMedia，getUserMedia()）。此后，所有信息（网络摄像头名称）将被发送给发起者和协作者，因此接收器可以实现加速的对等（P2P）叠加。每个客户端端点应当滤掉它们自己的网络摄像头。

在发起者或协作者中的任何一个不支持加速WebRTC功能性的情况下，虚拟桌面服务器连接器代码可以在“双重”模式下操作——即，在可能的情况下的远程WebRTC，并出于远程处理到不支持WebRTC重定向的客户端端点的目的而回退到主机端渲染。

在回退时，注入代码将遵从内置的WebRTC引擎来枚举本地设备，这可以进而调取其他虚拟通道功能性来枚举客户端设备并执行非优化重定向，例如经由通用音频重定向或图形远程处理虚拟通道。共享会话中对非优化重定向的支持是VC特定的，并且在本公开的范围之外。替代的方法将是对所有协作者禁用WebRTC远程处理，但这更具限制性。

在发起者或协作者有意或无意地从共享会话断开（例如，由于网络中断）的情况下，服务器连接器代码将引发断开事件。这进而将经由WebRTC API通知托管应用：来自断开的端点的媒体设备不再可用。此后，该事件将被发送到其他客户端端点（剩余的发起者或协作者），因此接收器可以更新加速对等（P2P）叠加的列表。

功能背景可以在以下参考文献中提供，所有这些文献都转让给本申请的当前受让人，并且所有这些文献都通过引用以其整体并入：

- Remoting Audio and Video Extensions (RAVE)；Methods and Apparatus forGenerating Graphical and Media Displays at a Client：美国专利号8,131,816；美国专利号8,671,213；和美国专利号 9,325,759。

- Reverse RAVE (Webcam Redirection)；Systems and Methods for RemotelyPresenting a Multimedia Stream：美国专利号9,191,425；和美国专利号9,203,883。

- Flash Redirection； Systems and methods for remoting multimediaplugin calls：美国专利号8,296,357。

- HTML5 Video Redirection；Multimedia redirection in a virtualizedenvironment using a proxy server：美国专利号9,124,668；和美国专利号9,571,599。

- Browser Content Redirection；Redirection of Web Content：临时– ID1340(B&W ref 007737.00826)； Managing Browser Session Navigation Between One orMore Browsers：临时– ID1368US (B&W ref 007737.00827)。

- 涵盖Citrix HDX实时优化包组件架构的几项专利包括：美国专利号 8,949,316；美国专利号8,869,141；美国专利号8,799,362；和美国专利号8,601,056，它们共享标题“Scalable high-performance interactive real-time media architectures forvirtual desktop environments”。

然而，如上面详细解释的，本公开的新颖性在于注入代码、连接器和引擎模块的特定功能和交互，所述特定功能和交互被设计为优化实时媒体API，并且特别是WebRTC。

受益于前述描述和相关联附图中呈现的教导，本领域技术人员将想到许多修改和其他实施例。因此，应理解，本公开将不限于所公开的特定实施例，并且修改和实施例旨在包括在本公开的范围内。