在无预定义呼叫信令协议的情况下在浏览器之间发起呼叫的机制的制作方法
【专利说明】在无预定义呼叫信令协议的情况下在浏览器之间发起呼叫 的机制 相关申请案交叉申请
[0001] 本发明要求李栗（LiLi)等人2013年2月4日递交的发明名称为"在无预定义 呼叫信令协议的情况下在浏览器之间发起呼叫的机制（MechanismtoInitiateCalls betweenBrowserswithoutPredefinedCallSignalingProtocol) " 的第 13/758, 250 号美国非临时申请案的在先申请优先权，该在先申请的内容以引入的方式全文并入本文本 中。 关于由联邦政府赞助研宄或开发的声明
[0002] 不适用。 参考缩微胶片附录
[0003] 不适用。
技术领域 无
【背景技术】
[0004] 使用Web浏览器等Web应用程序的多媒体呼叫和电话会议，例如视频电话、视频聊 天以及对等（P2P)文件共享会话，正在日益普及。Web应用程序可以毫不费力地使用同一呼 叫信令协议（CSP)基于万维网联盟（W3C)Web实时通信（WebRTC)应用程序编程接口（API) 发起对彼此的呼叫。然而，存在多个非标准化CSP协议，并且因此一些Web应用程序可能尝 试使用冲突CSP的WebRTC，例如，WebRTC提议/应答协议（ROAP)、WebSocket(WS)、可扩展的 信息和呈现协议（XMPP)/Jingle、会话发起协议（SIP)、H. 323、媒体网关控制协议（MGCP)、 或特定于通信网站的CSP。冲突CSP通常导致不能进行WebRTC通信。
[0005] 因此，具有冲突CSP的应用程序无法发起呼叫，除非使用先前协定的CSP用于呼 口H，这在各种环境中可能存在问题。WebRTC通信发起者（"主叫"）可通常通过使用由WebRTC 通信接收方（"被叫"）提供的CSP呼叫被叫来确保CSP互操作性。然而，这可能导致开放 式网络中的钓鱼攻击，因为使用被叫CSP可将整个浏览器置于被叫Web应用程序的控制下， 并可能使得主叫的Web浏览器难以增强安全规范。在钓鱼环境中，被叫Web应用程序要求 主叫使用主叫的Jabber标识符（JID)和密码登录到XMPP服务器中。在不可信赖环境中， 政府机构主叫想要提醒多个被叫有关即将发生的自然灾害或其它紧急情况。在这样的情况 下，被叫可能愿意使用主叫的CSP，但并非反之亦然。
[0006] 由于多种原因，使用例如统一资源标识符（URI)或接口规范等标准名称的CSP的 浏览器协商可能不合需要。例如，标准名称可能不合需要，因为它们需要开发标准协议，且 开发标准协议可能花费数年来开发。此外，标准名称可能需要大量的互操作性测试，即， NXN次成对协调测试，来验证功能，并且可能最终仅确保互操作性到测试情况的程度。因 此，替代方案可能是优选的。
【发明内容】
[0007] 在一个方面中，本发明包含一种装置，其包括处理器，所述处理器用于：接收用以 呼叫远端用户的指令；加载通信应用程序；从服务器请求一或多个所支持通信协议的列 表；从服务器接收一或多个所支持通信协议的列表；从一或多个所支持通信协议的列表中 选择协议；在隔离的安全环境中加载选定通信协议；以及使用选定通信协议用远端服务器 发起呼叫。
[0008] 在另一方面中，本发明包含一种计算机程序产品，其包括存储在非暂时性媒体上 的计算机可执行指令，所述计算机可执行指令在由处理器执行时致使所述处理器执行以下 操作：在Web浏览器中加载通信应用程序；向站点发送对所支持通信协议列表的请求；从 站点接收所支持通信协议列表，其中所支持通信协议列表含有通信协议；向站点发送对支 持通信协议的库的请求；从站点接收支持通信协议的库；发送根据通信协议编码的通信提 议；以及接收根据通信协议编码的应答。
[0009] 在又另一方面中，本发明包含一种用于在无预定义CSP的情况下在浏览器之间发 起呼叫的方法，所述方法包括：在第一浏览器处实施CSP状态机；从第一服务器请求针对 CSP的CSP库；接收并加载CSP库；向第二服务器发送提议，其中所述提议根据CSP编码；从 第二服务器接收应答，其中所述应答根据CSP编码；以及根据CSP向第二浏览器传输数据， 其中所述数据包括语音数据、视频数据或这两者。
[0010] 从结合附图以及权利要求书进行的以下详细描述中将更清楚地理解这些以及其 它特征。
【附图说明】
[0011] 为了更透彻地理解本发明，现参考结合附图和【具体实施方式】描述的以下简要说 明，其中相同参考标号表不相同部分。
[0012] 图1图示了用户设备的实施例。
[0013] 图2是在无预定义CSP的情况下在浏览器之间发起呼叫的机制的实例实施方案。
[0014] 图3是示出由在无预定义CSP情况下在站点之间发起呼叫的机制的实施例所用的 CSP协商过程的协议图。
[0015] 图4A描绘了可以用于在无预定义CSP情况下在站点之间发起呼叫的机制的实施 例的初始条件。
[0016] 图4B描绘了可以用于在无预定义CSP情况下在站点之间发起呼叫的CSP协商过 程。
[0017] 图4C描绘了在使用在无预定义CSP情况下在站点之间发起呼叫的机制的实施例 之后的呼叫。
[0018] 图5是通信设备的实施例的示意图。
【具体实施方式】
[0019] 首先应理解，尽管下文提供一或多个实施例的说明性实施方案，但所公开的系统 和/或方法可使用任何数目的技术来实施，无论该技术是当前已知还是现有的。本发明决 不应限于下文所说明的说明性实施方案、附图和技术，包含本文所说明并描述的示例性设 计和实施方案，而是可在所附权利要求书的范围以及其等效物的完整范围内修改。
[0020] 本发明描述保证来自不同站点的WebRTC应用程序在不存在任何标准CSP的情况 下使用可互操作CSP的系统和方法。本发明描述此类机制和协议以协商CSPJavaScript 编码并在隔离的安全环境中执行所述编码使得以可控安全性来保证互操作性。换句话说， 本发明描述了一种架构，其用以使CSP层、资源或模块与WebRTC应用程序的其余部分分离， 使用CSP层、资源或模块以在JavaScript中实施CSP状态机，并批准Web应用程序之间的 数据传输。使用所公开的系统和方法可以尤其降低互操作性测试成本，因为对于N个CSP 实施方案仅需要N次单独的测试（而不是NXN次成对协调测试，其中N是整数）；增大互 操作性，因为应用程序可以使用相同的CSPJavaScript编码而不是相同CSP的不同实施方 案；通过增强的和可控的机制增大安全性；以及提供灵活性，因为模块化设计允许CSP编码 改变而不影响Web应用程序的其它部分。
[0021] 图1图示了第一和第二用户设备100的实施例。用户设备100可以例如通过发 送对含有URI的HTML文档的请求并接收所述HTML文档而与服务器102通信。用户设备 100可以经由网络104耦合到服务器102,所述网络例如因特网协议（IP)网络、企业内部 网、或局域网（LAN)等任何其它网络。用户设备100可以分别地是面向用户的固定或移动 设备，例如，台式计算机、笔记本或膝上型计算机、上网本、平板计算机、智能电话、个人数字 助理（PDA)、或蜂窝式电话。用户设备100可以各自包括处理块110和浏览器或搜索应用 程序112。处理块110可以是允许用户配置或访问用户设备100的不同特征以及在用户设 备100上安装和操作其它软件或程序的任何软件（例如，操作系统）和/或硬件，例如，图7 的通用网络组件700和操作系统。处理块110可以包含操作系统Windows?、Mac?OS和 Android?。浏览器/搜索应用程序112可以是在处理块110上运行且允许用户在用户设备 100上发送搜索查询并接收搜索结果的软件或程序。浏览器/搜索应用程序112可以使用 对应编码、API、语言或接口经由第一网络（例如，因特网）与服务器通信。浏览器/搜索应 用程序112可以包括可用来例如经由因特网远程访问搜索应用程序的浏览器，或可以包括 整合的浏览器和搜索应用程序。浏览器/搜索应用程序112可以具有用于向用户显示搜索 查询和结果的视觉用户接口。浏览器/搜索应用程序112的实例可以包含谷歌Chrome?、 因特网Explorer'、摩斯拉巧-也^以及微件。尽管本实施例中描绘为相同组件，但服务 器102和用户设备100可以是能够实现指定目的的组件的任何合适组合。
[0022] 图2示出在无预定义CSP的情况下在浏览器之间发起呼叫的机制的实施方案。图 2含有站点202和站点204,其可以是例如在由用户的Web浏览器采用时向网站用户提议 WebRTC服务等通信服务的任何网站。站点202和204可以在图1的服务器102等单独的服 务器上单独地托管。站点202可以是主叫所用的WebRTC服务并且站点204可以是被叫所用 的WebRTC服务。图2另外含有被叫Web浏览器205和主叫Web浏览器206,例如，图1的浏 览器/搜索应用程序112,其在一侧上包括被叫WebRTC应用程序编程接口（API) 207和另一 API209,例如，aW3CWebSocketJavaScriptAPI、服务器已发送事件API、异步JavaScript 和XML(AJA