CN104969530B

CN104969530B - 在无预定义呼叫信令协议的情况下在浏览器之间发起呼叫的机制

Info

Publication number: CN104969530B
Application number: CN201480007441.2A
Authority: CN
Inventors: 李栗; 周芜; 蔡涛
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2013-02-04
Filing date: 2014-02-07
Publication date: 2018-10-12
Anticipated expiration: 2034-02-07
Also published as: US9009741B2; US20140223453A1; CN104969530A; WO2014117749A1

Abstract

本发明提供一种装置，其包括处理器，所述处理器用于：接收用以呼叫远端用户的指令；加载通信应用程序；从服务器请求一或多个所支持通信协议的列表；从所述服务器接收一或多个所支持通信协议的所述列表；从一或多个所支持通信协议的所述列表中选择协议；在隔离的安全环境中加载所述选定通信协议；以及使用所述选定通信协议用所述远端服务器发起所述呼叫。

Description

在无预定义呼叫信令协议的情况下在浏览器之间发起呼叫的机制

相关申请案交叉申请

本发明要求李栗(Li Li)等人2013年2月4日递交的发明名称为“在无预定义呼叫信令协议的情况下在浏览器之间发起呼叫的机制(Mechanism to Initiate Callsbetween Browsers without Predefined Call Signaling Protocol)”的第13/758,250号美国非临时申请案的在先申请优先权，该在先申请的内容以引入的方式全文并入本文本中。

关于由联邦政府赞助研究或开发的声明

不适用。

参考缩微胶片附录

不适用。

技术领域

无

背景技术

使用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通信。

因此，具有冲突CSP的应用程序无法发起呼叫，除非使用先前协定的CSP用于呼叫，这在各种环境中可能存在问题。WebRTC通信发起者(“主叫”)可通常通过使用由WebRTC通信接收方(“被叫”)提供的CSP呼叫被叫来确保CSP互操作性。然而，这可能导致开放式网络中的钓鱼攻击，因为使用被叫CSP可将整个浏览器置于被叫Web应用程序的控制下，并可能使得主叫的Web浏览器难以增强安全规范。在钓鱼环境中，被叫Web应用程序要求主叫使用主叫的Jabber标识符(JID)和密码登录到XMPP服务器中。在不可信赖环境中，政府机构主叫想要提醒多个被叫有关即将发生的自然灾害或其它紧急情况。在这样的情况下，被叫可能愿意使用主叫的CSP，但并非反之亦然。

由于多种原因，使用例如统一资源标识符(URI)或接口规范等标准名称的CSP的浏览器协商可能不合需要。例如，标准名称可能不合需要，因为它们需要开发标准协议，且开发标准协议可能花费数年来开发。此外，标准名称可能需要大量的互操作性测试，即，N×N次成对协调测试，来验证功能，并且可能最终仅确保互操作性到测试情况的程度。因此，替代方案可能是优选的。

发明内容

在一个方面中，本发明包含一种装置，其包括处理器，所述处理器用于：接收用以呼叫远端用户的指令；加载通信应用程序；从服务器请求一或多个所支持通信协议的列表；从服务器接收一或多个所支持通信协议的列表；从一或多个所支持通信协议的列表中选择协议；在隔离的安全环境中加载选定通信协议；以及使用选定通信协议用远端服务器发起呼叫。

在另一方面中，本发明包含一种计算机程序产品，其包括存储在非暂时性媒体上的计算机可执行指令，所述计算机可执行指令在由处理器执行时致使所述处理器执行以下操作：在Web浏览器中加载通信应用程序；向站点发送对所支持通信协议列表的请求；从站点接收所支持通信协议列表，其中所支持通信协议列表含有通信协议；向站点发送对支持通信协议的库的请求；从站点接收支持通信协议的库；发送根据通信协议编码的通信提议；以及接收根据通信协议编码的应答。

在又另一方面中，本发明包含一种用于在无预定义CSP的情况下在浏览器之间发起呼叫的方法，所述方法包括：在第一浏览器处实施CSP状态机；从第一服务器请求针对CSP的CSP库；接收并加载CSP库；向第二服务器发送提议，其中所述提议根据CSP编码；从第二服务器接收应答，其中所述应答根据CSP编码；以及根据CSP向第二浏览器传输数据，其中所述数据包括语音数据、视频数据或这两者。

从结合附图以及权利要求书进行的以下详细描述中将更清楚地理解这些以及其它特征。

附图说明

为了更透彻地理解本发明，现参考结合附图和具体实施方式描述的以下简要说明，其中相同参考标号表示相同部分。

图1图示了用户设备的实施例。

图2是在无预定义CSP的情况下在浏览器之间发起呼叫的机制的实例实施方案。

图3是示出由在无预定义CSP情况下在站点之间发起呼叫的机制的实施例所用的CSP协商过程的协议图。

图4A描绘了可以用于在无预定义CSP情况下在站点之间发起呼叫的机制的实施例的初始条件。

图4B描绘了可以用于在无预定义CSP情况下在站点之间发起呼叫的CSP协商过程。

图4C描绘了在使用在无预定义CSP情况下在站点之间发起呼叫的机制的实施例之后的呼叫。

图5是通信设备的实施例的示意图。

具体实施方式

首先应理解，尽管下文提供一或多个实施例的说明性实施方案，但所公开的系统和/或方法可使用任何数目的技术来实施，无论该技术是当前已知还是现有的。本发明决不应限于下文所说明的说明性实施方案、附图和技术，包含本文所说明并描述的示例性设计和实施方案，而是可在所附权利要求书的范围以及其等效物的完整范围内修改。

本发明描述保证来自不同站点的WebRTC应用程序在不存在任何标准CSP的情况下使用可互操作CSP的系统和方法。本发明描述此类机制和协议以协商CSP JavaScript编码并在隔离的安全环境中执行所述编码使得以可控安全性来保证互操作性。换句话说，本发明描述了一种架构，其用以使CSP层、资源或模块与WebRTC应用程序的其余部分分离，使用CSP层、资源或模块以在JavaScript中实施CSP状态机，并批准Web应用程序之间的数据传输。使用所公开的系统和方法可以尤其降低互操作性测试成本，因为对于N个CSP实施方案仅需要N次单独的测试(而不是N×N次成对协调测试，其中N是整数)；增大互操作性，因为应用程序可以使用相同的CSP JavaScript编码而不是相同CSP的不同实施方案；通过增强的和可控的机制增大安全性；以及提供灵活性，因为模块化设计允许CSP编码改变而不影响Web应用程序的其它部分。

图1图示了第一和第二用户设备100的实施例。用户设备100可以例如通过发送对含有URI的HTML文档的请求并接收所述HTML文档而与服务器102通信。用户设备100可以经由网络104耦合到服务器102，所述网络例如因特网协议(IP)网络、企业内部网、或局域网(LAN)等任何其它网络。用户设备100可以分别地是面向用户的固定或移动设备，例如，台式计算机、笔记本或膝上型计算机、上网本、平板计算机、智能电话、个人数字助理(PDA)、或蜂窝式电话。用户设备100可以各自包括处理块110和浏览器或搜索应用程序112。处理块110可以是允许用户配置或访问用户设备100的不同特征以及在用户设备100上安装和操作其它软件或程序的任何软件(例如，操作系统)和/或硬件，例如，图7的通用网络组件700和操作系统。处理块110可以包含操作系统Mac^TM OS和Android^TM。浏览器/搜索应用程序112可以是在处理块110上运行且允许用户在用户设备100上发送搜索查询并接收搜索结果的软件或程序。浏览器/搜索应用程序112可以使用对应编码、API、语言或接口经由第一网络(例如，因特网)与服务器通信。浏览器/搜索应用程序112可以包括可用来例如经由因特网远程访问搜索应用程序的浏览器，或可以包括整合的浏览器和搜索应用程序。浏览器/搜索应用程序112可以具有用于向用户显示搜索查询和结果的视觉用户接口。浏览器/搜索应用程序112的实例可以包含谷歌Chrome^TM、因特网摩斯拉以及微件。尽管本实施例中描绘为相同组件，但服务器102和用户设备100可以是能够实现指定目的的组件的任何合适组合。

图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和另一API 209，例如，aW3C WebSocket JavaScript API、服务器已发送事件API、异步JavaScript和XML(AJAX)API、或用于提供网络服务以支持传送JavaScript的其它API等，并且在另一侧上包括主叫WebRTC API 208以及可以反射其它API 209的另一API210。被叫计算机，例如图1的用户设备100，可以配备有Web浏览器205，且主叫计算机，例如图1的用户设备100，可以配备有Web浏览器206，并且每一Web浏览器205和206可以是被叫计算机和主叫计算机通过其与站点202和204交互的接口。WebRTC应用程序211和212可以分别加载到Web浏览器205和206上。被叫WebRTC应用程序211可以包括CSP层、资源或模块213；传送层、资源或模块215；以及呼叫控制层、资源或模块217。主叫WebRTC应用程序212可以包括CSP层、资源或模块214；传送层、资源或模块216；以及呼叫控制层、资源或模块218。CSP模块213和214可分别用于从站点202和204接收CSP库，且用于与呼叫控制模块217和218通信。如所描绘的，传送模块215和216可用于与呼叫控制模块217和218以及其它API 209和210通信。呼叫控制模块217和218可分别用于与CSP模块213和214、传送模块215和216以及WebRTC API 207和208通信。WebRTC应用程序211和212，并且因此CSP模块213和214、传送模块215和216以及呼叫控制模块217和218可以在JavaScript中实施。CSP模块213和214可以定义便携状态机和用于CSP的消息格式，并且可以各自包括在呼叫发起期间自例如站点204等对等站点加载的一或多个库，如在下文图3所进一步解释。CSP模块213和214可以各自在其宿主机上的例如HTML5内联帧(iframe)等隔离的安全环境中运行，以防止对存储于WebRTC应用程序211和212中的例如用户密码等敏感信息的访问。传送模块215和216可以调节信息流并提供可靠的传送，以确保数据无差错地且依序地到达，例如通过为CSP提供一致的双向连接。分别在WebRTC API207与208之间、在CSP模块215与216之间以及在传送模块217与218之间，呼叫控制模块213和214可以充当网守，可以保持呼叫，并且可以协调消息，例如，超文本标记语言5(HTML5)Web信息传送、WebIntent和跨域资源共享(CORS)。

图3是示出由在无预定义CSP情况下在站点之间发起呼叫的机制的实施例所用的CSP协商过程300的协议图。在步骤302处，第一用户301，例如图1的用户设备100，可以例如通过按下在第一用户的例如图2的Web浏览器208等浏览器303处的按钮向第二用户(未示出)发出或试图发起呼叫，由此启动WebRTC应用程序，例如，图2的WebRTC应用程序212。在步骤304处，WebRTC应用程序可以向图2的站点204等远端服务器305发送请求，例如超文本传输协议(HTTP)GET请求，从而从远端服务器305请求所支持CSP库列表。在步骤306处，远端服务器305可以发送含有所支持CSP库列表的响应。在308处，浏览器/WebRTC应用程序可以在隔离的安全环境内选择并加载来自远端服务器305例如经由图2的CSP模块214传输的所支持CSP库列表的CSP。在步骤310处，浏览器/WebRTC应用程序可以使用选定CSP经由远端站点试图发起与第二用户的呼叫。如果选定CSP不再被远端站点支持，那么在步骤312处远端站点可以向浏览器/WebRTC应用程序发送CSP不被支持的响应并且可以在响应中伴随新的所支持CSP库列表。如果接收到“不被支持的”响应，那么浏览器/WebRTC应用程序可以反复地重复例如从步骤304开始的过程。

图4A、4B和4C示出由在无预定义CSP情况下在站点之间发起呼叫的机制的实施例所用的发起过程的不同步骤或阶段的协议图。用于第一浏览器寻找第二站点的可接受的分辨率/智真系统是众所周知的，并且因此为了简明起见在此不作讨论。图4A描绘了可以用于系统，即用于在例如图1的用户设备100等设备处的两个用户401和403，采用例如Web浏览器205和206等浏览器405和407来到达例如图2的站点202和204等WebRTC站点409和411的初始条件，并且WebRTC站点409和411为浏览器405和407提供CSP库。更确切地说，在步骤404处，第一用户401使用第一浏览器405，访问例如WebRTC站点等第一站点409，并且在步骤406处发送对于第一通信协议的请求，例如HTTP GET请求。在步骤408处，第一浏览器405可以从第一站点409接收所请求协议，例如第一CSP。在410处，第二用户403使用第二浏览器407访问例如WebRTC站点等第二站点411，并且在步骤412处发送对于第二通信协议的请求，例如HTTP GET请求。在步骤414处，第二浏览器407可以从第二站点411接收所请求协议，例如第二CSP。第一和第二CSP可能冲突。这组初始条件可以紧接于过程的其余部分之前，或可以包含间隔时间。此外，一方面步骤404到408且另一方面步骤410到412可以单独地或同步地进行。

图4B描绘可以用于在无预定义CSP情况下在站点之间发起呼叫的CSP协商过程，例如，图3的过程300。因此，在步骤418处，第一主叫可以例如通过WebRTC呼叫来选择呼叫第二用户403，使得在步骤419处，第一浏览器405可以向第二站点411发送HTTP GET请求等请求，以从第二站点411请求所支持CSP库列表。在步骤420处，第二站点411可以向第一站点409发送含有所支持CSP库列表的响应。在步骤422处，第一站点409可以从检索到的列表中选择CSP，可以通知第二站点411所述选择，并且可以在步骤424处接收并加载来自第二站点411的选定CSP库。

图4C描绘了使用常规WebRTC ROAP从第一用户401到第二用户403的呼叫，并且可以在步骤428处以根据选定CSP编码的提议开始，所述提议可以接着从第一浏览器405传递到第一站点409。在步骤430处，第一站点409可以将提议传递到第二站点411，在432处，第二站点411又可以将根据选定CSP编码的提议中继转发到第二浏览器407。在步骤434处，第二浏览器407可以例如通过可听铃音、可视提醒等提醒第二用户403，并且在步骤436处，第二用户403可以使用第二浏览器407应答呼叫。在步骤438处，第二浏览器407可以根据选定CSP对应答进行编码并且将应答传递到第二站点411。在步骤440处，第二站点411可以将应答发送回第一站点409，并且在步骤442处第二站点411可以将CSP编码的应答传递到第一浏览器405。在444处，第一用户401可以从第一浏览器405接收到第二用户403已经应答呼叫的通知或提醒。最后，在步骤446和448处，第一用户401和第二用户403可以通过其浏览器交换数据。

WebRTC功能的设备、此类视频电话会议系统和/或本文中所论述的其它通信系统可在电信系统中工作，并且可是实质上同步地无线传输和接收多种类型的数据所需的。移动智能电话等通信设备可以配备有多个天线，天线可以用作传输和接收数据的发射器和/或接收器(或收发器)。通信设备的天线可以通过经由指定频率传输和/或接收数据而与网络无线地通信。图5是通信设备500的实施例的示意图，所述通信设备例如图1的用户设备100。通信设备500可以包括具有语音和数据通信能力的双向无线通信设备。在一些方面，语音通信能力是任选的。通信设备500通常具有与因特网上的其它计算机系统通信的能力。取决于所提供的精确功能性，作为实例，通信设备500可以被称为数据信息传送设备、蜂窝式电话、无线因特网设备、无线设备、智能电话、移动设备和/或数据通信设备。

通信设备500可以包括处理器520(其可以被称为中央处理器单元或CPU)，其与包含辅助存储装置521、只读存储器(ROM)522和随机存取存储器(RAM)523的存储器设备通信。处理器520可以实施为一或多个CPU芯片、一或多个核心(例如，多核心处理器)，或可以是一或多个专用集成电路(ASIC)和/或数字信号处理器(DSP)的一部分。处理器520可用于实施本文中所描述的方案中的任一者，且可以使用硬件、软件、固件或其组合来实施。

辅助存储装置521可以由一或多个固态驱动器、磁盘驱动器和/或其它存储器类型组成，且用于对数据的非易失性存储，且如果RAM 523不足以固持所有工作数据，则用作溢流数据存储设备。当加载到RAM 523中的程序经选定用于执行时，辅助存储装置521可以用来存储此类程序。ROM 522可以用于存储在程序执行期间读取的指令和可能的数据。ROM522可以是非易失性存储器设备，所述设备可以具有相对于辅助存储装置521的较大存储容量较小的存储容量。RAM 523可以用于存储易失性数据且可能用于存储指令。对ROM 522和RAM523两者的存取可能比对辅助存储装置521的存取更快。

通信设备500可以经由网络接入点650与网络无线地传送数据(例如，包)。因而，通信设备500可以包括接收器(Rx)512，其可配置用于从其它组件接收数据(例如，无线包或帧)。接收器512可以耦合到处理器520，所述处理器可用于处理数据且确定将数据发送到哪些组件。通信设备500还可以包括发射器(Tx)532，所述发射器耦合到处理器520并配置用于例如通过使用IEEE802.11、IEEE 802.16、第三代移动通信标准化伙伴项目(3GPP)、全球移动通信系统(GSM)或类似无线协议等协议向其它组件传输数据。接收器512和发射器532可以耦合到多个天线530，所述天线可用于接收和传输无线射频(RF)信号。在一些实施例中，Tx 532和Rx 512可以由包括Tx 532和Rx 512两者的功能性的收发器替代。

通信设备500还可以包括耦合到处理器520的显示器540，所述显示器向用户显示其输出。在一些实施例中，显示器540是远离通信设备500的显示站。通信设备500和显示器540可以用于向用户显示数据的表示。设备显示器520可以包括彩色超扭曲向列型(CSTN)显示器、薄膜晶体管(TFT)显示器、薄膜二极管(TFD)显示器、有机发光二极管(OLED)显示器、有源矩阵OLED显示器或任何其它显示屏幕。显示器540可以彩色或单色显示且可以配备有基于电阻和/或电容技术的触摸传感器。

通信设备500可以进一步包括耦合到处理器520的输入设备541，其可以允许用户将命令输入到通信设备500。在显示器设备540包括触摸传感器的情况下，显示器设备540也可以被考虑为输入设备541。除替代方案之外和/或在替代方案中，输入设备541可以包括鼠标、轨迹球、内置键盘、外部键盘、和/或用户可以用来与通信设备500交互的任何其它设备。在视频电话会议等多媒体通信的背景下，输入设备541可以是摄像机。

本发明公开至少一个实施例，且所属领域的普通技术人员对所述实施例和/或所述实施例的特征作出的变化、组合和/或修改均在本发明公开的范围内。因组合、合并和/或省略所述实施例的特征而得到的替代性实施例也在本发明的范围内。在明确说明数字范围或限制的情况下，此类表达范围或限制应被理解成包含在明确说明的范围或限制内具有相同大小的迭代范围或限制(例如，从约为1到约为10包括2、3、4等；大于0.10包括0.11、0.12、0.13等)。例如，只要公开具有下限R_l和上限R_u的数字范围，则明确公开了此范围内的任何数字。具体而言，在所述范围内的以下数字是明确公开的：R＝R₁+k*(R_u-R₁)，其中k为从1％到100％范围内以1％递增的变量，即，k为1％、2％、3％、4％、5％……50％、51％、52％……95％、96％、97％、98％、99％或100％。此外，由上文所定义的两个数字R定义的任何数字范围也是明确公开的。除非另有说明，否则术语“约”是指随后数字的±10％。相对于权利要求的任一元素使用术语"任选地"意味着所述元素是需要的，或者所述元素是不需要的，两种替代方案均在所述权利要求的范围内。使用如“包括”、“包含”和“具有”等较广术语应被理解为提供对如“由……组成”、“基本上由……组成”以及“大体上由……组成”等较窄术语的支持。本文所述的所有文档都以引入的方式并入本文中。

虽然本发明中已提供若干实施例，但应理解，在不脱离本发明的精神或范围的情况下，本发明所公开的系统和方法可以以许多其它特定形式来体现。本发明的实例应被视为说明性而非限制性的，且本发明并不限于本文本所给出的细节。例如，各种元件或组件可以在另一系统中组合或合并，或者某些特征可以省略或不实施。

此外，在不脱离本发明的范围的情况下，各种实施例中描述和说明为离散或单独的技术、系统、子系统和方法可以与其它系统、模块、技术或方法进行组合或合并。展示或论述为彼此耦合或直接耦合或通信的其它项也可以采用电方式、机械方式或其它方式通过某一接口、设备或中间组件间接地耦合或通信。其它变化、替代和改变的实例可以由所属领域的技术人员在不脱离本文所公开的精神和范围的情况下确定。

Claims

1.一种用于在无预定义呼叫信令协议(CSP)的情况下在浏览器之间发起呼叫的通信装置，其特征在于，包括：

处理器，其用于：

接收用以呼叫远端用户的指令；

加载通信应用程序；

从服务器请求包括一或多个所支持通信协议的列表；

从所述服务器接收包括一或多个所支持通信协议的所述列表；

从包括一或多个所支持通信协议的所述列表中选择协议；

在隔离的安全环境中加载所述选定通信协议；以及

使用所述选定通信协议发起与所述远端用户的所述呼叫；

所述通信应用程序在JavaScript中实施。

2.根据权利要求1所述的装置，其特征在于，所述处理器进一步用于从所述服务器接收与所述选定通信协议相关联的通信协议库。

3.根据权利要求1所述的装置，其特征在于，所述处理器初始地用于使用第一协议通信，其中所述远端用户初始地用于使用第二协议通信，并且其中所述选定通信协议与所述第二协议相同。

4.根据权利要求1所述的装置，其特征在于，所述通信应用程序是Web实时通信(WebRTC)应用程序。

5.根据权利要求1所述的装置，其特征在于，所述呼叫选自由以下项组成的群组：视频电话、视频聊天以及对等(P2P)文件共享会话。

6.根据权利要求1所述的装置，其特征在于，所述通信应用程序加载在浏览器中，并且其中所述浏览器在承载所述处理器的机器上实例化。

7.一种处理器从非暂时性媒体上调取可执行指令的方法：

在Web浏览器中加载通信应用程序；

向站点发送对所支持通信协议列表的请求；

从所述站点接收所述所支持通信协议列表，其中所述所支持通信协议列表含有通信协议；

向所述站点发送对支持所述通信协议的库的请求；

从所述站点接收支持所述通信协议的所述库；

发送根据所述通信协议编码的通信提议；以及

接收根据所述通信协议编码的应答；

所述通信应用程序包括呼叫信令协议(CSP)模块，其中所述CSP模块在JavaScript中实例化，并且其中所述CSP模块JavaScript在隔离的安全环境中运行。

8.根据权利要求7所述的方法，其特征在于，所述隔离的安全环境是超文本标记语言5(HTML5)内联帧(iframe)。

9.根据权利要求7所述的方法，其特征在于，所述通信应用程序是Web实时通信(WebRTC)应用程序。

10.根据权利要求7所述的的方法，其特征在于，根据特定于所述站点的CSP或根据选自由以下项组成的群组的CSP进行发送所述提议和接收所述应答：WebRTC提议/应答协议(ROAP)、Jingle、会话发起协议(SIP)、H.323以及媒体网关控制协议(MGCP)。

11.根据权利要求7所述的方法，其特征在于，所述通信应用程序初始地用于使用第二通信协议通信，并且其中所述通信协议和所述第二通信协议是冲突通信协议。

12.一种用于在无预定义呼叫信令协议(CSP)的情况下在浏览器之间发起呼叫的方法，其特征在于，包括：

在第一浏览器处实施CSP状态机；

从第一服务器请求针对CSP的CSP库；

接收并加载所述CSP库；

向第二服务器发送提议，其中所述提议根据所述CSP编码；

从所述第二服务器接收应答，其中所述应答根据所述CSP编码；以及

根据所述CSP向第二浏览器传输数据，其中所述数据包括语音数据、视频数据或这两者；

所述CSP状态机在JavaScript中实例化。

13.根据权利要求12所述的方法，其特征在于，所述CSP状态机初始地用于使用第二CSP通信。

14.根据权利要求12所述的方法，其特征在于，所述CSP状态机在隔离的安全环境中运行。

15.根据权利要求14所述的方法，其特征在于，所述隔离的安全环境是超文本标记语言5(HTML5)内联帧(iframe)。

16.根据权利要求12所述的方法，其特征在于，根据特定于站点的CSP或根据选自由以下项组成的群组的CSP进行发送所述提议和接收所述应答：WebRTC提议/应答协议(ROAP)、Jingle、会话发起协议(SIP)、H.323以及媒体网关控制协议(MGCP)。

17.根据权利要求12所述的方法，其特征在于，所述方法进一步包括：

从所述第一服务器请求所支持CSP列表；

从所述第一服务器接收所述所支持CSP列表；以及

从所述所支持CSP列表中选择所述CSP库。