CN105723406B - 用于具有优化的转码的基于网页的实时通信的系统和方法 - Google Patents

Abstract

本发明提供一种允许网页浏览器应用程序和联络中心资源之间实时通信的系统和方法，其中两方支持的媒体编解码器可以不同。处理器被配置为桥接在浏览器和联络中心资源之间交换的媒体。在桥接媒体中，处理器将对发往网页浏览器应用程序和从网页浏览器应用程序来的媒体基于第一媒体编解码器转码该媒体，并还将对发往联络中心资源和从联络中心资源来的媒体基于第二媒体编解码器转码该媒体。

Description

用于具有优化的转码的基于网页的实时通信的系统和方法

技术领域

本发明的实施例涉及用于运营联络中心的系统和方法，更具体地，涉及用于使用基于网页浏览器的通信信道与用户进行通信的系统和方法。

背景技术

在客户通信和服务领域中，一个组织，例如零售公司、服务公司或者非赢利组织，可以运营网站以向顾客和客户提供信息和/或提供与联络中心通信的接入点。除了网站，该组织还可以运营联络中心(例如，顾客服务中心或销售联络中心)，它的职员通过电话或其它音频/视频通信信道、文本交互聊天系统、短信服务(SMS)、社交媒体、共同浏览、电子邮件、信件、传真等与客户通信。

通常来说，组织的网站会向访客展示用于与联络中心处的组织代表联系的信息和机会。这些机会通常表现为用于语音通信的免费号码(例如，“1-800”号码)和/或聊天信箱或集成到网页中的用于基于实时文本交流的窗口。某些情况下，会给予用户填写表格的机会以表达他们想要说的，并且提供他们的电话号码，以便组织代表使用共用交换电话网络(PSTN)呼叫用户打电话(立即或者在指定的时间)。

然而，运营免费号码和维护数量足够多的PSTN线路，对一个组织来说常常比较昂贵。另外，通过PSTN连接的语音通信通常限于音频，实质上与当前呼叫者使用的特定浏览器会话是分开的且是独立的。

许多组织在处理较大量的呼叫时常常使用数据网络电话(DNT)或者计算机模拟电话以通过使用共享的、无连接的数据网络(例如，互联网)提供增强的灵活性。在这样的DNT系统中，高负荷可以通过例如在高峰使用期间通过服务质量(QoS)机制降低通话质量来完美地解决此问题。例如，DNT系统一部分可以如所述使用基于IP语音(VoIP)协议(例如，会话初始协议(SIP))的电话和网关实现，一部分内容按照互联网工程任务组(IETF)请求评论(RFC)2543、3261和3262。

无论联络中心使用PSTN线路、DNT连接、其他类型的电话通信系统还是其组合，联络中心通常都包括用于将呼入呼叫路由到合适资源的某些系统。这样的系统可以包括交互式语音应答(IVR)系统。在呼叫到达联络中心交换机之前例如在业务控制点(SCP)层，或者在呼叫到达联络中心交换机之后例如通过联络中心路由机制，可以将呼叫连接到IVR。在IVR交互期间，语音应用(或者一系列的语音应用)会被播放给呼叫者，呼叫者与通过语音应用播放的菜单选项(例如，“新的销售请按1，产品支持请按2”)进行交互。其他IVR系统可以同时或者也可以交替地提供语音识别系统(例如，“您想了解哪班飞机的状态？您可以说出航班号或者在您的小键盘上输入航班号”)。与这种发声的语音菜单交互通常会比较困难。这种困难有一部分是由于困惑造成的，这是因为通过语音接口，许多选项被连续地朗读给了呼叫者。通常，呼叫者在选择选项前会重复播放菜单并多次倾听可用的选项。在系统中，这造成了延迟，从而导致呼叫处理的延迟、呼叫处理效率的降低，有时还会导致呼叫者由于感到挫折而放弃呼叫。

发明内容

本发明的实施例涉及用于顾客和联络中心资源之间的实时通信的系统和方法。处理器从网页浏览器应用程序接收对基于浏览器的呼叫的第一提议。第一提议包括网页浏览器应用程序所支持的第一媒体编解码器。处理器修改第一提议并生成第二提议，该第二提议具有处理器支持的第二媒体编解码器。在生成第二提议中，处理器删除第一媒体编解码器或者将第二媒体编解码器增加到包含第一媒体编解码器的列表中。处理器传送第二提议，以让联络中心资源接收。联络中心资源响应于第二提议生成应答，该应答包括对第二提议中的第二媒体编解码器的选择。处理器然后在实时通信期间桥接在网页浏览器应用程序和联络中心资源之间交换的媒体。在桥接媒体中，处理器根据第一媒体编解码器对来自和去往网页浏览器应用程序的媒体转码该媒体，并且处理器还根据第二媒体编解码器对来自和去往联络中心资源的媒体转码该媒体。

根据一个实施例，联络中心资源是联络中心代理设备。联络中心代理设备可以支持代理网页浏览器应用程序，以用于与请求基于浏览器的呼叫的网页浏览器应用程序进行基于浏览器的呼叫。

根据一个实施例，联络中心代理设备包括IP语音客户端，用于与请求基于浏览器的呼叫的网页浏览器应用程序进行IP语音呼叫。根据一个实施例，处理器根据网页信令协议与网页浏览器应用程序建立网页浏览器呼叫支路，并且根据IP语音信令协议建立与联络中心代理设备的IP语音浏览器呼叫支路。

根据一个实施例，在生成第二提议中，处理器被配置为按偏好顺序列出第二提议中的媒体编解码器，以用于联络中心资源根据已列出的偏好顺序进行选择。

根据一个实施例，如果处理器不支持第一媒体编解码器，则处理器在生成第二提议时删除第一媒体编解码器。

根据一个实施例，实时通信被转移到第二联络中心资源，以用于在网页浏览器应用程序和第二联络中心资源之间交换实时媒体，其中所述转移不改变对等连接。

根据一个实施例，处理器协商用于处理器和第二联络中心资源之间的实时通信的媒体编解码器。所述协商可以包括：通过处理器从第二联络中心资源接收提议，该提议包括第二联络中心资源所支持的第三媒体编解码器；通过处理器传送应答，所述应答包括基于对网页浏览器程序所支持的编解码器的认知所选定的媒体编解码器。根据一个实施例，获取认知不需要与网页浏览器重新协商媒体会话。

根据一个实施例，第二联络中心资源是媒体控制器，所述媒体控制器被配置成为网页浏览器应用程序交付音乐媒体服务。如果网页浏览器应用程序支持第三媒体编解码器，则媒体控制器根据第三媒体编解码器交付音乐媒体服务。如果网页浏览器应用程序不支持第三媒体编解码器，那么在向网页浏览器应用程序交付音乐媒体服务前将音乐转码成网页浏览器应用程序支持的媒体编解码器。

根据一个实施例，处理器和第二联络中心资源之间的协商没有与网页浏览器应用程序重新协商媒体会话。

根据一个实施例，实时通信从仅音频通信升级为音频及视频通信。所述升级包括：通过处理器从联络中心资源接收用于将视频加入实时通信的消息；协商处理器和网页浏览器应用程序之间的视频的属性，其中响应于协商，该网页浏览器应用程序显示联络中心资源传送的视频流，并且还显示用于接收客户对网页浏览器应用程序访问客户摄像头的同意的提示；和响应于收到客户的同意，网页浏览器应用程序将客户摄像头捕获的视频流传送到联络中心资源。

本发明的实施例还涉及一种用于客户和联络中心资源之间的实时通信的方法，其中该方法包括以下步骤：通过处理器从网页浏览器应用程序接收对基于浏览器的呼叫的第一请求，所述第一请求依附于网页信令协议；通过处理器与网页浏览器应用程序建立第一呼叫支路；通过处理器生成对IP语音呼叫的第二请求，该第二请求依附于IP语音协议；通过呼叫控制器接收第二请求，并且在响应时识别联络中心资源；通过处理器与所识别的联络中心资源建立第二呼叫支路；和通过处理器在实时通信期间桥接在网页浏览器应用程序和联络中心资源之间交换的媒体。

本领域的技术人员应该了解，本发明的实施例允许基于前提和云的联络中心将浏览器用作与联络中心的“最后一英里”连接。整个联络中心的解决方案可以在业务场所被交付给业务而不需要额外的电话设备。代理将简单地将浏览器用作桌面应用和通信设备。

根据本发明的实施例的WebRTC服务机制在将WebRTC呼叫放到联络中心前也允许业务站点收集客户数据。这允许在客户不需要通过IVR的情况下将数据附加到客户的上下文的业务。联络中心路由策略可以使用该附加的数据，以寻找具有应答呼叫的适当技能的代理。当应答呼叫时，该代理也将能够得到完整的上下文数据。

本发明的实施例还允许集成包括IVR的现有的联络中心媒体服务。在单个WebRTC会话中，联络中心能够交付多个媒体服务，而不需要在浏览器侧改变对等连接。WebRTC服务具有内置的转码服务，以保证端点(例如，浏览器到SIP)可以与不兼容的编解码器通信。WebRTC服务和联络中心还提供智能编解码器协商，以保证无论什么时候提供媒体服务(IVR、音乐暂停)，组件都能避免在同一会话中多次转码的问题，例如如果IVR或媒体控制器也用作转码器时也是如此。

本发明的实施例还允许客户以与联络中心仅音频的呼叫开始。当到达代理时，代理可以请求将呼叫升级为视频+音频。在这方面，代理首先显示视频流，然后请求客户授权访问代理以观看客户的视频。

联络中心代理可以使用WebRTC服务以通过联络中心对通信设备验证和授权。对于其他所有的SIP通信设备，这个机制使用同样的授权模块。

通过下文的具体介绍、所附权利要求和附图，可以理解本发明上述和其他的方面的优点和特性。当然，本发明的实际范围由所附权利要求限定。

附图说明

图1是根据本发明的一个示例性实施例的用于用户和客户联络中心之间基于网页浏览器的通信的系统的方框图；

图2A和2B是根据本发明的一个示例性实施例的用于将网页应用程序用户连接到联络中心代理的过程的流程图；

图3是根据本发明的一个示例性实施例的用于识别用于路由呼叫的合适代理的过程的流程图；

图4是根据本发明的一个示例性实施例的用于建立带外信道的过程的流程图；

图5A是根据本发明的一个示例性实施例的客户的终端用户设备上的浏览器窗口的示意图；

图5B是根据本发明的一个示例性实施例的浏览器窗口的示意图，该窗口具有显示与代理的实时视频通话的弹出窗口；

图6A和6B是根据本发明的一个示例性实施例的浏览器窗口的示意图，该窗口具有显示对来自客户的附加信息的请求的弹出窗口；

图7是根据本发明的一个示例性实施例的由客户的终端用户设备显示的浏览器窗口的示意图，该客户参与和客户服务代表的会话，并且具有多个带外信道；

图8是根据本发明的一个示例性实施例的用于具有优化的转码的WebRTC通信的系统的方框图；

图9A-9B是根据本发明的一个实施例的在处理进入联络中心的WebRTC呼叫期间交换的信令消息的方框图；

图10是根据本发明的一个实施例的用于将仅音频的呼叫升级为音频及视频呼叫来交换的信令消息的视图；

图11A是根据本发明一个实施例的计算装置的方框图；

图11B是根据本发明一个实施例的计算装置的方框图；

图11C是根据本发明一个实施例的计算装置的方框图；

图11D是根据本发明一个实施例的计算装置的方框图；以及

图11E是根据本发明一个实施例的包括多个计算装置的网络环境的方框图。

具体实施方式

在下面的详细说明中，通过举例说明的方式，仅仅显示和说明了本发明特定的示例性实施例。本领域的技术人员应该了解，本发明可以采用许多不同的形式实施，而不应该被解释为受限于在此所述的实施例。相同的附图标记表示说明书中相同的元件。

本发明的示例性实施例涉及用于使用基于网页浏览器的通信系统建立访客到网站和客户服务代表(也称为代理)的一个或多个通信信道的系统和方法。举例来说，这样的系统可以是网页实时通信(WebRTC)系统。WebRTC，也称为RTCWeb，能够使网页浏览器通过JavaScript应用程序接口(API)提供实时通信(RTC)功能，而无需用户主动下载和安装额外的软件，并且本质上是让每个浏览器中可获得双向媒体处理和媒体编码技术。WebRTC技术将媒体引擎放入浏览器或客户设备的其他元件中。媒体引擎是管理扩音器、照相机和扬声器并从互联网获取或上传音频和视频的技术。因此，网站上期望和代理通话的访客简单地致动网站上显示的呼叫按钮，例如通过互联网就能在访客和代理之间形成语音和/或视频连接，而无需访客安装任何单独的应用程序或浏览器插件。访客也不需要离开他/她的当前网页浏览会话，不需要初始化单独的呼叫会话用于与代理进行基于网页浏览器的语音通信。

在本发明的一个示例性实施例中，用户在网站上的活动是受监控的，并且从监控活动中获得的信息用于确定是否提供在线代理(例如，和客户服务代表在线通信)。如果提供在线联络，用户可以选择与代理通话(例如，通过文本聊天、电话、WebRTC或另外的电话会议服务)。在网站上，组织可以根据用户之前的活动将用户路由到代理。例如，主要查看网站上可售的特定种类的产品(例如，笔记本电脑)的第一用户可以被引导到具有该种类的专业知识的销售代理。对于另一个示例，浏览网站的与特定产品相关的故障检修问题相关联的部分的第二用户可以被路由给客户支持代理，例如技术支持代理。对于三个示例，浏览西班牙语或中文版本的网站的客户可以分别被路由给讲西班牙语或中文的客户服务代表。

根据本发明的一个示例性实施例，用户可以在例如通过电话、WebRTC或其他IP语音通信信道呼叫前、呼叫期间和/或呼叫后使用带外(OOB)或补充信道提供附加信息给代理和终端用户和从代理和终端用户接收附加信息。在一些实施例中，OOB信道由联络中心通过网页服务器动态提供，使得联络中心做出提供OOB信道的决定，并且用户被提供接受或忽略该信道的选择。根据一个示例性实施例，OOB或补充信道可以包括任何逻辑上与用于代理和终端用户之间的视频和/或音频对话的实时通信信道链接的通信信道，但是关于协议和传输可以与该实时通信信道分离。例如，OOB信道数据的显示可以与实时通信显示分离或者与实时通信显示成一组。根据本发明的一个示例性实施例，OOB信道用于显示图片、电影或者IVR选择菜单的图形化表示。在一些实施例中，可以在建立呼叫后但是该呼叫与代理连接前通过OOB信道接收附加信息。在其他实施例中，当在建立呼叫前通过OOB信道接收附加信息时，附加信息可以用于协助将用户路由给合适的代理。

在一些实施例中，当客户使用WebRTC初始化呼叫时，联络中心主动地向用户初始化或提供OOB或补充信道，以例如显示IVR菜单的图形化表示，为代理向用户推送内容。例如，根据本发明的一个示例性实施例，OOB信道还可以是文本聊天窗口，在文本聊天窗口处通过文本聊天在代理和终端用户之间交换附加信息。OOB信道还可以是例如用于将共享图片(例如，截图)、记录的视频、文档(例如，教程和订货单)、其他网页的链接的媒介、和/或用于共享屏幕的媒介(例如，使用远程桌面技术，如远程帧缓存、微软的远程桌面服务( Remote Desktop )和其他类似的技术)。如果WebRTC由于因特网连接不稳定质量较差而导致不可靠，则OOB信道还可以提供备份的通信信道。此外，OOB信道可以提供数据，而不用受限于服务质量(QoS)要求，这些要求对于带内信道(例如，WebRTC信道)中传送的数据来说是需要设置的。

在一些示例性实施例中，除了经由OOB信道提供的信息之外或取代这些信息，代理还可以有与组织网站上用户浏览历史相关的补充信息以及(如果可获得)用户对基于网页浏览器的表格的回应，以便提供给代理对用户所面对问题的更好理解。

图1是根据本发明的一个示例性实施例的用于在网页用户和客户联络中心之间基于网页浏览器的通信系统的系统的方框图。用户或客户可以使用安装在终端用户设备12中的网页浏览器11，以通过数据通信网络20(例如，因特网)访问网页服务器120。终端用户设备12可以是标准桌面或者便携式式计算机、平板、智能手机、电视、游戏机或者本领域常用的能够运行网页浏览器的任何其他设备。网页服务器120可以配置为网页应用程序或网站122的主机，提供可从组织和/或技术支持获得的诸如产品或服务的特征和规格的信息。网页服务器120还可以被配置成通过提供例如JavaScript代码驱动到网页浏览器11的WebRTC会话和OOB通信信道。

根据一个示例性实施例，联络中心10可以由组织或另外的实体运营。根据一个示例，联络中心10可以包括WebRTC/呼叫服务器或网关110和路由服务器160，所述WebRTC/呼叫服务器或网关用于接收入话请求以建立WebRTC呼叫(也可以简称为浏览器呼叫)，所述路由服务器用于将来自WebRTC/呼叫服务器110的呼入请求路由给联络中心处合适的代理。根据一个实施例，WebRTC/呼叫服务器110被配置为接收和建立WebRTC会话，并用作WebRTC和SIP之间的网关。根据一个实施例，WebRTC呼叫被转换到SIP通话中，并且被送到SIP服务器114。路由服务器160从SIP服务器接收请求以路由SIP呼叫，并且作为响应，路由服务器返回往哪里路由呼叫的指令。如果代理已经访问启用SIP的设备，则使用SIP将呼叫路由给启用SIP的设备。如果代理已经访问启用WebRTC的设备，则SIP服务器指示WebRTC/呼叫服务器110将呼叫作为WebRTC呼叫路由到代理设备。该代理可以在一个或多个代理设备112或代理电话116中，其中代理设备112可以包括例如桌面或便携式计算机、平板、智能电话或者任何其他能够运行网页浏览器的设备。例如，代理电话116可以是用于通过例如SIP服务器114进行VoIP通信的SIP电话。

根据一个示例性实施例，联络中心还包括用于监控客户在网页服务器120上的活动的网页监控器140。在其他的实施例中，网页监控器140可以是组织托管的，并且可以是运行在网页服务器120或一个单独的服务器上的软件模块。用于监控客户或网页访问者的系统和方法更详细地记载在例如2011年11月10日在美国专利及商标局申请的名称为“SYSTEMFOR INTERACTING WITH A WEB VISITOR”的美国申请第13/293,575号，该申请的全部公开内容在此并入本文作为参考。

联络中心还可以包括数据库服务器150，所述数据库服务器用于存储与客户和他们与组织和联络中心的交互相关的信息。这种信息可以包括例如由之前代理收集的关于之前呼叫和之前问题或请求的历史数据、联络信息(例如，姓名、地址和电话号码)、客户拥有的产品列表和类似信息。

在一些示例性实施例中，联络中心还包括OOB应用服务器130，所述OOB应用服务器与被配置为向客户的终端用户设备12提供OOB或补充通信信道的网页服务器120是分开的。举例来说，在一些实施例中，在OOB应用服务器130被配置成提供与带外通信信道相关联的代码和/或媒体时，网页服务器120被配置成处理和提供与网页浏览器11和WebRTC/呼叫服务器110之间的WebRTC呼叫相关的功能。在其它实施例中，带外通信信道功能可以由网页服务器120提供。这些带外通信信道可以包括但不限于提供基于网页浏览器的表格、文本聊天、视频和其他类型媒体(通常可以经由网页服务器通过网页浏览器向客户表达)的信道。举例来说，基于文本的聊天可以用于提高交流地址、邮件地址和信用卡付款信息时的准确率，并且将URL提供给网页页面以回答用户问题。OOB信道还可以用于演示应用所使用的视频教程、官方文件编制和屏幕共享。OOB信道还可以在实时通信信道中连接比较差的情况下提供一些冗余。在这点上，WebRTC/呼叫服务器110可以帮助在客户的终端用户设备12和带外应用服务器130和/或代理设备112之间建立套接字连接。

根据本发明的一个示例性实施例，正在查看网页应用122提供的网站的终端用户(被称为网站访客)可以决定与代理通话来询问关于网站上看到的产品的问题，参与特定事务，或者接收任何来自代理的其他帮助。初始化此对话的传统方法是拨电话号码(例如，免费号码或“1-800”号码)。用户还可以请求(例如通过电子邮件)代理以特定的电话号码与客户通话，或者可以通过网页浏览器11与代理进行基于文本的聊天。根据本发明的例示性实施例，除了这些传统的联络机制之外的或代替这些传统的联络机制，终端用户可以通过网页浏览器与代理建立WebRTC呼叫。使用WebRTC允许用户参与和代理的实时语音对话，从而增加他们的参与感，同时降低与运营依赖于标准PSTN(公共交换电话网络)电话系统的联络中心相关联的成本。另外，WebRTC呼叫可以与特定的浏览器会话相关联，从而简化将OOB信道与“带内”音频/视频信道相关联的任务。

图1中不同的服务器110、114、130、150、160和网页监控器每一个都可以包括一个或多个处理器，所述处理器执行计算机程序指令和与其他系统部件交互，以执行此处所述的各种功能。计算机程序指令存储在存储器中，所述存储器使用标准存储设备(例如，随机存取存储器(RAM)来实现。计算机程序指令还可以存储在其他非易失性计算机可读介质中，例如CD-ROM、闪存驱动器或类似的介质。另外，虽然每一个服务器的功能都像描述的那样由特定服务器提供，但本领域的技术人员应该了解在不脱离本发明实施例范围的情况下，各种服务器的功能可以合并或集成于单个服务器上，或者一个特定服务器的功能可以分布在一个或多个其他服务器上。

图2A和2B是根据本发明的一个示例性实施例的用于将网页应用用户连接到联络中心代理的过程的流程图。可以根据一个或多个软件程序来说明该过程，一个或多个处理器基于存储在存储器中的计算机程序指令来执行软件程序。然而，本领域的技术人员应该了解，所述过程也可以通过硬件、固件(例如，通过ASIC)或者由软件、固件和/或硬件的组合来执行。更进一步，进程的执行顺序不是固定的，就像本领域的技术人员所理解的那样，可以修改为任何想要的顺序。

所述过程开始，并且在步骤200中，网页监控器140追踪网页应用上的用户会话，例如网页服务器120提供的网页应用122上的用户会话。在这点上，用户在终端用户设备12中调用浏览器11访问网页应用122。如本领域的技术人员所清楚知道的，用户可以通过经由网站的页面导航、选择不同的链接、提交信息、初始化事务或者执行其他动作与网站/应用来交互。监控器140追踪不同页面的导航和访问网站时执行的动作，就像上面引用的美国申请第13/293,575号中进一步详细讨论的内容。举例来说，在使用网页应用122时，会话标识符(“会话ID”、“会话令牌”或者可选地与用户帐号相关联的登录信息)可以被授权并关联于客户的终端用户设备12和/或在其上运行的网页浏览器，从而允许网页应用122和组织和/或联络中心运行的其他服务器识别用户并追踪用户的活动。

根据一个示例性实施例，网页监控器140监控/追踪网页应用122上用户的活动，以在使用网站时确定用户的意图或目的(例如，确定用户对哪类产品或服务有购买兴趣或确定用户希望解决的问题是什么)，并且将该计算结果与用户会话标识符相关联。根据一个示例性实施例，网页监控器140向路由服务器160提供与特定会话标识符关联的监控到的用户活动相关联的信息。

当在网站上仔细查看信息时，用户可以做出与客户服务代表通话的决定，以获得信息或者寻求有关正在查看的产品或服务的帮助。根据一个示例，访客可以通过选择“呼叫”按钮来发送初始化呼叫的命令。根据一个示例性实施例，网页应用将该命令译为初始化基于浏览器的实时通信信道(也称为WebRTC呼叫)的命令。

在步骤202中，WebRTC/呼叫服务器110接收初始化与客户服务代表的WebRTC呼叫的请求。根据一个示例性实施例，初始化该呼叫的请求包括例如会话描述协议(SDP)提议(如互联网工程任务组(IETF)请求评论(RFC)3264中所述)，所述会话描述协议提议可以包括交互式连接建立(ICE)候选(如IETFRFC5245中所述)。该提议可以包括诸如用于识别已经请求的会话的会话标识符和发请求的终端用户设备的IP地址的信息。

在步骤203中，WebRTC/呼叫服务器110使用SIP协议将WebRTC呼叫译为SIP呼叫，并向SIP服务器114发送请求(例如，通过INVITE消息)。虽然SIP呼叫只用作一个示例，但本领域的技术人员应该知道，用于VoIP通信的不同协议都可以被使用而代替SIP，例如H.323。

在本发明的其他实施例中，网页服务器120可以提供JavaScript来驱动WebRTC功能到网页浏览器。当用户激活WebRTC会话时，其他参与者就会被匹配到WebRTC/呼叫服务器110。WebRTC/呼叫服务器110用作代理或网关，以用于连接到用户的WebRTC会话的实际(终端)参与者，其中实际参与者可以是例如支持WebRTC的代理或支持SIP的代理。

在步骤204中，路由服务器160由用于识别合适的代理来路由呼叫的SIP服务器114调用。

在步骤206中，由例如与路由器相结合的SIP服务器114做出识别出的代理是否与支持WebRTC的浏览器相关联的判定。如果答案为否，则在步骤214中，SIP服务器向选定代理传送SIP呼叫。例如，SIP服务器114向选定的代理的SIP设备(例如，电话116)传送SIPINVITE消息。当网站访客通过网页浏览器111与选定代理通信时，选定代理就由此通过他或她的SIP设备与网站访客通信。在一些示例性实施例中，该WebRTC呼叫(被称为带内连接)只用于语音(例如，只有音频)。在其他示例性实施例中，所述连接包括音频和视频。再次参考步骤206，如果做出判定选定代理具有支持WebRTC的浏览器，则SIP服务器114向WebRTC/呼叫服务器110传送用于代理的SIP呼叫。在这点上，SIP服务器114传送包括选定代理的地址的SIP INVITE消息。

在步骤210中，WebRTC/呼叫服务器110将SIP呼叫转换为WebRTC呼叫。在这点上，WebRTC/呼叫服务器110用作WebRTC呼叫和SIP呼叫之间的双向网关。

在步骤212中，WebRTC/呼叫服务器110向选定的代理设备112中的浏览器发送WebRTC呼叫。因此，代理和网站访客都通过他们各自的网页浏览器进行通信。

图3是根据本发明的一个示例性实施例的用于选择用于路由呼入呼叫的合适代理的图2A中的步骤204的更加详细的流程图。在步骤302中，路由服务器160从网页监控器140接收路由信息(例如，用户在网页应用上的位置)，以帮助将呼叫路由给合适的客户服务代表。在步骤304中，路由服务器160试图判定用户的意图(例如，购买产品、技术支持等)。在步骤306中，路由服务器160判定路由信息是否足够确定用户的意向。如果有足够的信息，则在步骤312中，路由服务器选择合适的代理，并且在步骤314中将识别选定代理的信息，例如代理标识符、电话号码和/或IP地址，发送给WebRTC/呼叫服务器110。

再次参考步骤306，如果路由服务器判定收到的信息不足以路由呼叫，则可以在步骤308中从网站访客中收集附加的路由信息。根据一个示例性实施例，路由服务器调用OOB应用服务器130以获得附加信息。在本发明的一个例示性实施例中，OOB应用服务器130通过OOB信道显示一个或多个提示(例如，向导中的网页表单或一系列提示)以获得附加信息。举例来说，可以向对于呼叫要求额外细节的网站访客显示网页，额外细节例如为呼叫的原因、偏好的特定语言和类似细节。

根据一个示例性实施例，除了实时通信信道(例如，WebRTC连接)外(例如，同时地)，OOB应用服务器130还在浏览器中提供一个或多个OOB通信信道。

根据一个示例性实施例，OOB应用服务器130将附加信息发送到路由服务器160或呼叫服务器114，以将呼叫路由给合适的客户服务代表。

在本发明的包括网页监控器140的实施例中，可以根据网页监控器140判定的信息的充足性来选择用于附加信息的一个或多个提示。举例来说，因为用户已经浏览过了故障检修网页，网页监控器140可以判定用户对获得产品支持有兴趣。然而，在有些情况下，网页监控器140可能没有足够的信息来判定用户有疑问的特定产品。因此，当用户请求与客户服务代表建立实时通信信道时，带外应用服务器130可以首先提示用户指明它认为用户正在寻找客户支持，并且可以让用户从产品列表中识别用户需要获得帮助的产品。

根据本发明的一个示例性实施例，与对WebRTC呼叫的请求一起传送的会话标识符用于将网站用户与网页应用的特定会话、用户的呼叫请求和用户对基于网页浏览器的提示的响应相关联。

附加路由信息可以与之前收集的路由信息相结合，并在步骤304中重新评估以判定信息是否足够判定用户的意图。这个过程可以重复执行，直到接收到足够的信息为止。用户也可以选择取消呼叫请求，而不是继续通过网页提示回答问题，在这种情形下，在步骤310中，呼叫请求结束。

图4是根据本发明的一个示例性实施例的用于在客户的终端用户设备12和代理设备112之间建立OOB信道连接的过程的方框图。根据一个示例性实施例，一个或多个带外信道可以关联于会话标识符，该会话标识符与如关于例如图2A和2B所述建立的相应的基于浏览器的实时通信信道相关联。如上所述，带外信息可以包括但不限于文本聊天、屏幕共享、共享文档和用于显示网页的内部框架和类似信息。

在步骤402中，带外应用服务器130接收建立带外信道的请求。用户或者客户服务代表(CSR)可以通过他们终端用户设备上的网页浏览器产生该请求，并且带外信道可以在联络中心处被激活。所述请求可以识别要建立的一种或多种类型的带外信道(例如，文本聊天、屏幕共享等)。带外应用服务器130也使用会话标识符以识别404要连接的用户和CSR。带外应用服务器130然后使用他们各自的会话标识符在用户和CSR之间建立连接(例如，网页套接字连接)。该连接可以用于提供用于在用户和CSR之间通信带外信息的信道。

如上所述，根据本发明的一个示例性实施例，带外信道和带外信息用于通过提供了额外的通信信道，例如文本聊天、屏幕共享和类似信道，补充基于“带内”WebRTC的语音和/或视频通信信道。

在本发明的一些实施例中，可以对没有请求带外信道的参与者(例如，用户或CSR)进行提示，以确认或拒绝建立带外信道的请求。此外，在本发明的一些实施例中，在用户和CSR(例如，用户和CSR使用的网页浏览器)之间为每种带外信道建立单独的连接(例如，单独的网页套接字连接)，或者这些连接中的部分或全部可以被所使用类型的带外信道共享。

图5A是根据本发明的一个示例性实施例的显示在客户的终端用户设备12上的示例性浏览器窗口100的示例性屏幕截图，其中使用客户终端用户设备12的客户在“ACME产品”网站上购物。在仔细看过网站后，用户可能想和客户服务代表通话，以获得干预用户正在查看的产品或服务的信息或者请求帮助。根据一个示例性实施例，网站提供按钮101来初始化和相关的联络中心进行WebRTC呼叫的请求以和代理通话。在其它实施例中，可以通过网页上的弹出窗口、覆盖图或另外的对象指示建立通话的机会。

在所述的示例中，建立WebRTC呼叫的请求由浏览器111响应于用户对按钮101所做的选择来传送。在网站访客和代理之间建立的WebRTC呼叫可以仅是音频或者是音频和视频。图5B是具有弹出窗口102的浏览器窗口100的示例性屏幕截图，所述弹出窗口显示与代理的实时视频通话。

图6A和6B是根据本发明的一个示例性实施例的弹出窗口103、105的示例性屏幕截图，显示了由网站访客请求附加信息。弹出窗口可以用于提示用户从语言的选择中选择语言，以表明呼叫是否涉及销售、支持或其他客户服务，和/或识别呼叫涉及的产品类别。

图7是根据本发明的一个示例性实施例的通过客户的终端用户设备12显示且具有多个带外信道的浏览器窗口100的示例性屏幕截图，该客户在与客户服务代表进行通信会话。在图7的示例中，用户的浏览器窗口可以包括多个子窗口102-108，其中这些子窗口提供了附加的带外信息和通信信道，包括但不限于视频聊天窗口102、文本聊天窗口104、文档查看窗口106和视频窗口108。本发明的实施例并不限于已列出的窗口，而可以包括用于显示其他类型内容的窗口，例如用于画图、显示图像、显示账单信息、显示客户服务代表的计算机屏幕的实时取景或其一部分的数字“白板”或类似窗口，以用于展示产品或服务的用途。另外，如图5B的示例中所示，在本发明的一些实施例中，子窗口102a可以浮动在单独的浏览器窗口中。

具有优化的转码的WebRTC通信

在通常的术语中，当浏览器想与另一个浏览器初始化实时信道时，也称为对等连接，浏览器使用JavaScript获得必需的资源并打包信令信息给另一个浏览器/对端。信令信息如何转送到另一个浏览器或者对端完全取决于应用。通常，浏览器仅支持HTTP，某些情况下支持WebSocket，信令信息需要使用通过网页应用中定义的机制被转送到另一对端。

在信令中，对等浏览器之间具有协商过程，以确定传输属性和媒体属性。像这里写的，媒体属性以会话描述协议(SDP)格式压缩。协商过程使用与SDP提议/回答模式类似的模式，被称为JavaScript会话建立协议(JSEP)。

一旦JSEP完成媒体协商，则媒体通过安全实时传输协议(SRTP)在对等连接之间传输。为了允许在现有VoIP设备之间能够互操作，媒体网关被配置为将信令和媒体桥接到SIP电话。

在WebRTC端点与传统端点(例如，SIP端点)通信的一些情况下，可能两点之间没有共用的编解码器来编码和解码“在配线上”传输的音频/视频。举例来说，传统的SIP端点可能只支持H.263/4视频编解码器，而WebRTC浏览器(例如，Google Chrome)可能仅支持VP8视频编解码器。即使两个端点支持同样的编解码器，也可能产生特定的情况：任何一个端点都不可以使用该编解码器。例如，即使两端点都支持G.711音频编解码器，具有带宽要求的特定部署还可能会强制使用低比特率的编解码器(例如，G.729编解码器)，而不是高比特率的G.711编解码格器。低比特率的编解码器可能不被例如WebRTC浏览器支持。

为了解决上面提及的问题，本发明的实施例提供了转码服务，所述转码服务即使在两个端点不共享共用的媒体编解码器的情况下也能桥接两个端点并允许在端点之间交换媒体。根据一个实施例，优化转码，从而避免不必要的转码；反之，在认为需要转码的情况下再进行转码。根据一个实施例，转码对于用户来说是透明的。

图8是根据本发明的一个实施例的具有优化的转码的WebRTC通信的系统的方框图。图8的系统包括一个或多个访问网关500a、500b(共同由附图标记500引用)，所述访问网关被配置为与客户和代理设备(也称为端点)502、504交互。根据一个实施例，访问网关500可以是运行在一个或多个计算设备中的处理器上的一个或多个进程或线程。根据一个实施例，访问网关500被配置成桥接客户和代理设备之间不同类型的实时媒体会话。

客户设备502可以类似于图1的终端用户设备12，并且可以采用标准桌面或便携式电脑、平板、智能电话、标准电话或蜂窝电话、电视、游戏机、和/或具有处理器、存储器和提供实时音频和/或视频通信能力的输入/输出单元的任何其他设备的形式。例如，根据客户设备的能力，设备可以通过网页浏览器应用程序506进行WebRTC呼叫、通过SIP客户端应用程序508进行VoIP呼叫、或者通过PSTN线和连接510进行的传统电话呼叫。

代理设备504可以类似于图1的代理112和116，并且可以采用标准桌面或便携式电脑、平板、智能电话、标准电话或蜂窝电话、电视、游戏机、和/或具有处理器、存储器和提供实时音频和/或视频通信能力的输入/输出单元的任何其他设备的形式。像客户设备一样，根据代理设备的能力，代理设备可以通过网页浏览器应用程序512进行WebRTC呼叫，通过SIP客户端应用程序514进行VoIP呼叫，或者通过PSTN线和连接516进行传统电话呼叫。一个代理可以同时使用一个或多个代理设备，以与客户进行实时媒体通信。举例来说，当该代理通过SIP电话进行电话呼叫时，代理桌面528可以显示在桌面计算机上以提供客户相关的数据。

浏览器和SIP客户端应用程序506、508、512、514可以用软件程序指令实现，这些指令存储在存储器或任何其他非易失性的存储介质中，当相应的处理器执行指令时，使得处理器提供WebRTC或VoIP电话呼叫功能，本领域的技术人员能够理解这些功能。

根据一个实施例，访问网关500被配置成允许客户设备和代理设备使用不同类型的实时通信协议和编解码器通信。在这方面，访问网关包括WebRTC服务网关518a,518b(共同由518引用)、VoIP网关520a,520b(共同由520引用)和PSTN/媒体网关522a,522b(共同由522引用)中的一个或多个。PSTN/媒体网关522允许客户和代理进行PSTN呼叫。VoIP网关520允许客户和代理通过在SIP支路/呼叫路径534a、534b上的SIP信令进行VoIP呼叫。WebRTC服务网关518允许客户和代理通过任何依托于网页信令协议的应用消息，例如超文本传输协议(HTTP)，进行WebRTC到WebRTC的呼叫(也称为浏览器到浏览器的呼叫)。这样的应用消息可以例如依附于ROAP(Rtcweb提议/应答协议)。当然，本发明不限于ROAP，而除了ROAP之外或代替ROAP可以使用任何其它协议。

根据一个实施例，如果客户和代理设备都包括启用WebRTC的浏览器506、512，则通过支路532a、532b上的网页信令建立基于浏览器的呼叫。如果用客户或代理不都支持WebRTC，则WebRTC服务网关允许参与者中的一个进行WebRTC呼叫/会话，同时其他参与者进行SIP呼叫/会话。访问网关500用作WebRTC会话和SIP会话的共用端点。在这方面，在访问网关和SIP客户端之间建立SIP呼叫/会话时，网页浏览器和访问网关之间建立WebRTC呼叫/会话。

WebRTC服务网关518可以类似于图1中的WebRTC/呼叫服务器110。在这方面，WebRTC服务网关518被配置为建立WebRTC会话并用作WebRTC和SIP之间的网关。在这点上，WebRTC服务网关518连接到SIP服务器524,所述SIP服务器可以类似于图1中的SIP服务器114。虽然SIP用作一个示例，但本领域的技术人员应该理解，任何其他SIP之外的或代替SIP的VoIP协议都可以使用。

根据一个实施例，WebRTC服务网关被配置成将WebRTC呼叫转换为SIP呼叫，并在SIP支路530a、530b上使用SIP信令消息与SIP服务器525通信。用这样的方式，WebRTC呼叫可以类似于SIP呼叫被处理和路由。SIP服务器524能够访问各种联络中心系统组件，例如可以类似于图1中的路由服务器160的路由服务器，以便提供联络中心通常都有的路由和其他功能。

根据一个实施例，SIP服务器524也连接到媒体控制器526，媒体控制器526被配置为将媒体服务提供到客户和/或代理设备502、504。这些媒体服务可以包括例如音乐媒体服务器，其中当呼叫正在被路由到联络中心资源时向客户(或代理)播放音乐。

根据一个实施例，WebRTC服务网关518桥接在浏览器到浏览器呼叫和浏览器到SIP呼叫期间交换的媒体。这么做的时候，网关518被配置成如果网关检测到参与双方没有共享的共用编解码器则自动在不同的媒体编解码器之间转码。在这方面，WebRTC服务网关518包括配置用于对配线上的不同媒体进行转码的媒体栈。就像本领域技术人员应该了解的那样，媒体栈是处理两端点之间实际的媒体传输的协议栈。实时传输协议(RTP)可以用作用于交付实时媒体的基区传输。

根据一个实施例，WebRTC服务网关518在存储器中存储了支持的用于WebRTC的编解码器的列表和支持的用于SIP的编解码器的列表。示例性的音频编解码器包括但不限于G.711、Opus、G.729和类似编解码器。示例性的视频编解码器包括但不限于VP8、H.264、H.263和类似编解码器。根据一个实施例，由于转码步骤在实时媒体交换中可能会引入延迟，因此在可能的时候要优化/最小化编解码器之间的转码。在一个示例中，WebRTC服务网关给出会话提议者/初始化者所提供的编解码器的偏好，使得应答设备支持了该编解码器，那么这个编解码器就被用于媒体交换，从而避免了不必要的转码。

在另一个例中，可以基于呼叫期间可以调用的不同参与者的推测来选择编解码器。举例来说，对与呼叫客户之前的交互的分析可以反映出具体类型的代理补入呼叫中。例如，不讲英文的客户通常可能会要求在通话中增加翻译，或者比较难缠的客户经常会要求将主管加入通话。根据一个实施例，对呼叫期间可以调用的不同参与者的考虑或推测以及被推测方所支持的编解码器会影响当前编解码器的选择。根据一个实施例，WebRTC服务网关518会选择和优先处理大部分被推测的参与方共有的编解码器。

图9A-9B是根据本发明的一个实施例的在处理进入联络中心的WebRTC呼叫期间交换的信令信息的视图。在动作600中，客户的浏览器应用程序506通过网页信令协议(例如，HTTP/ROAP信令协议)请求WebRTC呼叫。在请求中包括用于协商用于呼叫者和被呼叫者之间建立的媒体信道的媒体属性和传输的SDP提议。浏览器506支持的音频和视频编解码器的列表与属性一样被包括在SDP提议中。举例来说，SDP提议可以包括下面编解码器的信息：音频：G.711Opus，Opus，ISAC；视频：VP8。

WebRTC服务518处理请求，并继续下去以建立与网页浏览器应用程序506的WebRTC会话/呼叫。这么做的时候，WebRTC服务判定是否应该从SDP请求中增加或移除/替换编解码器。在这一点上，服务518检索它支持的编解码器列表，如果需要就修改SDP提议来匹配支持的编解码器列表。在一个示例中，WebRTC服务移除ISAC音频编解码器，增加G.729音频编解码器和H.264、H.263视频编解码器。这样，修改后的SDP提议可以指示：音频：G.711，Opus，G.729；视频：VP8，H.264，H.263。

根据一个实施例，修改后的SDP提议中的编解码器按优先级/偏好的顺序列出，首先列出最优选的编解码器，以在SDP应答中做好选择。根据一个实施例，偏好被提供给由也被WebRTC服务支持的请求的网页浏览器提供的编解码器。在这点上说，为了保证选择由进行请求的网页浏览器506所支持的编解码器，首先从进行请求的网页浏览器中列出编解码器，任何由WebRTC服务518增加的新编解码器都加到列表的末端。

在动作602中，WebRTC服务器518将SIP邀请消息连同获得修改后的SDP提议数据的新的SDP提议一起传送到SIP服务器524。

响应于SIP邀请消息，SIP服务器524进行用于识别路由呼叫到哪个资源的传统处理和路由处理。在这点上来说，SIP服务器可以调用路由服务器，所述路由服务器执行用于识别合适资源的合适的路由逻辑。根据一个实施例，路由逻辑在选择路由呼叫到哪个代理时可以考虑代理的能力。举例来说，如果SDP提议用于音频和视频，那么可以选择访问能够同时用于音频和视频的设备的代理。能力信息可以甚至被指定到编解码器级别。在这点上，SIP服务器和/或路由服务器可以访问各种代理设备504所支持的各种编解码器。假定有两个具有相同的技能组和可以处理呼叫的能力的代理，那么具有与SDP提议共享同一个编解码器的代理可以被选中用于处理呼叫。在这种方式下，可以避免不同编解码器之间不必要的转码。

在图9A-9B所示的实施例中，仅配置用于SIP呼叫的第一代理被选择用于处理呼叫。因此，在动作604中，SIP服务器将SIP消息传送到选定的第一代理，以用于建立和第一代理的SIP会话，该消息然后由代理的SIP客户应用程序514a处理。SIP消息包括从WebRTC服务518接收的SDP提议。

在动作606中，第一代理的SIP客户应用程序514a通过第一代理设备支持的一个或多个编解码器返回SDP应答。在图示的示例中，第一代理不支持任何来自浏览器的编解码器，并且通过由WebRTC服务518加入的编解码器应答。

WebRTC服务518处理来自SIP服务器的SDP应答，并识别出在发起呼叫的浏览器应用程序506和选定的第一代理设备之间没有共用的编解码器。然而，给出了WebRTC服务的转码能力使得该服务允许网页浏览器506和SIP客户514a之间的媒体会话。因此，在动作608中，WebRTC服务518响应SDP应答，该应答同意网页浏览器506提供的SDP提议。

在动作610中，如本领域技术人员能够理解的那样，网页浏览器506和WebRTC服务518参与用于决定到网页浏览器506的网络路径的ICE(交互连接建立)连接检查。限定在RFC5245中的ICE协议解决了处理网络地址转换(NAT)问题，这个问题的产生是因为具有私有IP地址的网页浏览器506在WebRTC呼叫期间使用UDP协议发送实时媒体流。ICE使用NAT会话穿透工具(STUN)协议作为用于发现被共用服务器见到的服务器反射地址的机制。一旦浏览器发现共用服务器见到的所有地址，则浏览器使用ICE协商与对端的连接。

根据一个实施例，在存在另一个代理或联络中心资源传移或者增加到呼叫的情况下，WebRTC服务应用程序518记录与网页浏览器506商定的媒体属性、决定好的网络路径信息和关于当前媒体会话的其他信息，以避免重新协商媒体会话(并且避免在网页浏览器侧修改对端连接)。这样帮助避免用在重新协商上所花费的时间和额外处理，包括ICE连接检查。在这点上，WebRTC服务518像一个对等端点，浏览器通过其引导会话协商(不考虑会话期间可能发生的代理或多个到其他代理的转移)，并且通过其根据商定的媒体参数建立对等连接。根据一个实施例，虽然要尽可能避免重新协商，但不可能杜绝，例如向呼叫中加入新的媒体流(例如，呼叫从音频升级到音频及视频)的情况。

在动作612a和612b中，当第一代理接收和传送通过与代理的SIP客户应用程序514a协商好的第二类编解码器编码的媒体时,网页浏览器506传送和接收通过与该网页浏览器协商好的第一类编解码器编码的媒体。当编解码器不兼容时，在动作614中，WebRTC服务被配置为在第一类编解码器和第二类编解码器之间进行转码。也就是说，WebRTC服务接收在第一类编解码器中编码的媒体，并根据存储中储存的常规转码算法根据第二类编解码器对媒体再次编码，反之亦然。

在图9A-9B的示例中，与动作616所述相同，呼叫转移到第二代理，该代理配置有支持WebRTC的浏览器512a。当呼叫转移时，SIP服务器524通过动作618向媒体控制器526请求媒体服务，例如音乐/视频暂停。

在动作620中，媒体控制器526响应于所述请求传送SDP提议，所述SDP提议包括媒体控制器所支持的媒体编解码器。媒体控制器可以支持也可以不支持与网页浏览器506相同的编解码器。

如动作622-626中所述，媒体编解码器的协商使得WebRTC服务518被用作一个端点。具体地，在步骤624中，在与网页浏览器的初始会话协商期间，WebRTC服务518根据已经获得的关于网页浏览器506的信息为媒体控制器526生成SDP应答。这样，根据本发明的实施例，不需要和呼叫者的网页浏览器重新协商会话，除非例如增加了新的媒体信道。因此，为与第一代理呼叫而商定的对等连接参数由网页浏览器侧维护。

根据一个实施例，如果来自媒体控制器的SDP提议包括网页浏览器支持的媒体编解码器，那么该媒体编解码器会被WebRTC服务518选中并被包括在返回给媒体控制器的SDP应答中。在这种方式下，避免对媒体控制器526向网页浏览器提供的媒体进行不必要的转码。

如果网页浏览器在传送其媒体中不支持媒体控制器使用的本地媒体编解码器，那么媒体控制器被配置为在向网页浏览器传送媒体前先将媒体转码为网页浏览器所支持的编解码器。因此，根据这个实施例，当在呼叫期间调用媒体控制器526来传送媒体时，WebRTC服务518的转码会被禁用。

根据一个实施例，转码的媒体存储在媒体控制器526的缓存中，用来与其他不兼容的浏览器通信。这种缓存是有好处的，这是因为媒体控制器(例如音乐暂停)提供的媒体类型不可能变化很大。当这种缓存功能启用的时候，媒体控制器被配置为在进行转码过程前首先为已经转码成特定编解码器的媒体检查缓存。

在动作628中，由媒体控制器526提供的音乐和/或视频通过WebRTC服务518桥接并被传送到网页浏览器506。

在动作630中，SIP服务器524将SIP请求传送到第二代理的网页浏览器512a，以实行呼叫到第二代理的转移。

在动作632中，第二代理的网页浏览器512a传送具有该网页浏览器所支持的编解码器的信息的SDP提议。

在动作634中，WebRTC服务518通过识别和选择最小化转码的编解码器来参与SDP的协商。例如，WebRTC服务选择呼叫者的网页浏览器506和代理的网页浏览器512a可以共用的编解码器。如果多个参与方被调用，则WebRTC服务可以选择大多数调用的参与者共用的编解码器。再说一下，与呼叫者的网页浏览器506的媒体会话的重新协商不会执行(除非增加了新的媒体流)，这是因为WebRTC服务518会从初始会话协商看出编解码器和与呼叫相关的其他会话参数。因此，呼叫者的网页浏览器处的对等连接参数不会改变。

在动作636中，在网页浏览器506和512a之间交换的实时媒体通过WebRTC服务518桥接。

本发明的实施例允许媒体流加入WebRTC会话或被从WebRTC会话移除。媒体流的加入可以发生在例如当代理希望将呼叫从仅音频会话升级到除了音频还交换视频的音频及视频会话时。根据现有浏览器的私有要求，客户必须给出对网页浏览器应用程序明确的同意才能访问客户的网络摄像机或扩音器。假定联络中心处理的大多数呼叫都是仅使用音频来进行的，那么除了用户的扩音器之外要求他或她提供对客户网络摄像机的访问就是不必要的，而且还会造成与联络中心代理进行网页浏览器呼叫的客户感到过分的不舒服。因此，根据本发明的一个实施例，对于仅音频的呼叫，客户初始仅授权对网页浏览器506的扩音器访问。如果代理希望升级到视频，他或她可以通过向呼叫中增加视频流这样做。根据一个实施例，安排新的SDP提议/应答，以将代理的视频流提供给客户。只要新的SDP提议/应答完成，客户就可以看见代理的视频流。在这点上，JavaScript库可以提供网页应用选项来询问在呼叫期间客户是否要授权访问网络摄像机。如果用户授权访问网络摄像机，则单独的SDP提议/应答会包括客户的视频。

图10是根据本发明的一个实施例的用于将仅为音频的呼叫升级为音频及视频呼叫所交换的信令消息的视图。在该消息图中，在动作700中假定已经在代理的SIP客户端514b和客户的网页浏览器506之间建立了仅为音频的呼叫。当然，在其他实施例中，如果代理已经访问启用WebRTC的浏览器512，那么呼叫也可以是浏览器到浏览器的呼叫。

在动作702中，代理生成引导到客户的新的INVITE SIP消息以增加视频媒体流。在动作704中，WebRTC服务器518接收SIP消息并生成具有对视频的SDP提议的ROAP消息。WebRTC服务器支持的视频编解码器在SDP提议中传送。

通过整体由附图标记706表示的信令消息在WebRTC服务518和客户的网页浏览器应用程序506之间协商视频编解码器。根据一个实施例，选定的视频编解码器目的是要最小化转码，就像上面讨论的那样。

当视频属性已经被协商好时，在动作708中，代理的视频流通过客户的网页浏览器显示出来。根据一个实施例，虽然显示了代理的视频流，但访问客户的视频是不允许的，直到客户授权同意网页浏览器应用程序访问客户的摄像头/网络摄像机，才开始交付客户网络摄像机捕获的视频。在这点上，在呼叫期间，网页浏览器应用程序506显示用于接收客户的同意以访问网络摄像机的提示。响应于客户指示，通过用户输入、授权访问网络摄像机例如经由“获取用户媒体”Javascript功能提供对客户的摄像头的访问。

客户同意会导致在客户的网页浏览器应用程序506和WebRTC服务518之间单独协商视频属性，以包括客户的视频。在这点上，在动作710中，网页浏览器应用程序506生成单独的SDP提议。该SDP提议被传送到WebRTC服务518，WebRTC服务518接着生成适当的SIP消息并与代理的SIP客户端514b交换该SIP消息(如整体通过附图标记712所表示)，以将网络摄像机捕获的视频流传送到代理设备以用于在该代理设备上显示。

前述图中的各种服务器、控制器、交换机和/或网关中的每一个都可以是进程或线程，该进程或线程运行在一个或多个计算设备1500(例如，图11A、图11B)中的一个或多个处理器上，执行计算机程序指令和与其他系统组件交互以用于执行此处描述的各种功能。计算机程序指令存储在存储器中，所述存储器在计算设备中可以使用标准存储器设备来实现，例如随机存取存储器(RAM)。计算机程序指令也可以存储在其他非易失性计算机可读介质中，例如CD-ROM、闪存驱动器或类似介质。而且，本领域的技术人员应该了解到计算设备可以通过固件(例如应用型专用集成电路)、硬件、或者软件、固件和硬件的组合来实现。本领域的技术人员也应该知道，在不脱离本发明的示例性实施例的范围的情况下，各种计算设备的功能可以组合或集成在单个的计算设备中，或者特定计算设备的功能可以分布在一个或多个其他计算设备上。服务器可以是软件模块，所述软件模块也可以简称为模块。联络中心中的模块组可以包括服务器和其他模块。

图11A和图11B描绘了本发明的示例性实施例中可以采用的计算设备1500的方框图。每个计算设备1500都包括中央处理单元1521和主存储单元1522。如图11A中所示，计算机设备1500还可以包括存储设备1528、可移除媒体接口1516、网络接口1518、输入/输出(I/O)控制器1523、一个或多个显示设备1530c、键盘1530a和指向装置1530b，例如鼠标。存储设备1528可以包括但不限于用于操作系统和软件的存储器。如图11B所示，每个计算设备1500还可以包括附加的可选元件，例如存储器端口1503、桥接器1570、一个或多个附加的输入/输出设备1530d、1530e和与央处理单元1521通信的缓存存储器1540。输入/输出设备1530a、1530b、1530d和1530e在此可以共同使用附图标记1530来引用。

中央处理单元1521是响应和处理从主存储单元1522取来的指令的任何逻辑电路。这可以例如在集成电路中实现，形式为微处理器、微控制器或者图形处理单元(GPU)，或者在现场可编程门阵列(FPGA)或应用型专用集成电路(ASIC)中实现。主存储单元1522可以是能够存储数据并允许中央处理单元1521直接访问任何存储位置的一个或多个存储芯片。如图11A所示，中央处理单元1521通过系统总线1550与主存储器1522通信。如图11B所示，中央处理单元1521还可以通过存储器端口1503直接与主存储器1522通信。

图11B显示了一个实施例，其中中央处理单元1521通过二级总线直接与缓存存储器1540通信，二级总线有时也被称为后端总线。在其它实施例中，中央处理器1521使用系统总线1550与缓存存储器1540通信。缓存存储器1540通常具有比主存储器1522更快的响应时间。如图11A所示，中央处理单元1521通过局部系统总线1550与各种I/O设备1530通信。各种总线都可以用作局部系统总线1550，包括视频电子标准协会(VESA)局部总线(VLB)、工业标准结构(ISA)总线、扩展工业标准结构(EISA)总线、微信道体系结构(MCA)总线、外围组件互联(PCI)总线、PCI扩展(PCI-X)总线、快速PCI总线或网络用户总线(NuBus)。有些实施例中，I/O设备是显示设备1530c，中央处理单元1521可以通过高级图形端口(AGP)与显示设备1530c通信。图11B显示了计算机1500的一个实施例，其中中央处理单元1521直接与I/O设备1530e通信。图11B还示出了一个实施例，其中局部总线和直接通信被混合：中央处理单元1521使用局部系统总线1550和I/O设备1530d通信，同时也直接和I/O设备1530e通信。

计算设备1500中可以存在各种各样的I/O设备1530。输入设备包括一个或多个键盘1530a、鼠标、触控板、轨迹球、扩音器和画板。输出设备包括视频显示设备1530c、扬声器和打印机。如图11A中所示，I/O控制器1523可以控制I/O设备。I/O控制器可以控制一个或多个I/O设备，例如键盘1530a和指向装置1530b，例如鼠标或光笔。

再参照图11A，计算设备1500可以支持一个或多个可移除媒体接口1516，例如软盘驱动器、CD-ROM驱动器、DVD-ROM驱动器、各种格式的磁带驱动器、USB端口、安全数字或COMPACT FLASH^TM存储卡端口、或者适合从只读介质读取数据或从读写介质读写数据的其他任何设备。I/O设备1530可以是系统总线1550和可移除媒体接口1516之间的桥接。

举例来说，可移除媒体接口1516可以用于安装软件和程序。计算设备1500可以还包括存储设备1528，例如一个或多个硬盘驱动器或硬盘驱动器阵列，所述存储设备用于存储操作系统和其他相关软件并用于存储应用软件程序。可选地，可移除媒体接口1516还可以用作存储设备。例如，操作系统和软件可以由可启动介质(例如，可启动CD)运行。

在一些实施例中，计算设备1500可以包括由多个显示设备1530c或连接到多个显示设备1530c，这些显示设备每一个可以是相同或不同的类型和/或形式。因此，I/O设备1530和/或I/O控制器1523中的任何一个可以包括任何类型和/或形式的合适的硬件、软件或者硬件、软件的组合，以通过计算设备1500支持、实现或提供到多个显示设备1530c的连接和所述多个显示设备的使用。举例来说，计算设备1500可以包括任何类型和/或形式的视频适配器、视频卡、驱动器和/或库，以接合、通信、连接或用其他方式使用显示设备1530c。在一个实施例中，视频适配器可以包括多个连接器，以连接到多个显示设备1530c。在其他实施例中，计算设备1500可以包括多个视频适配器，每个视频适配器连接到显示设备1530c中的一个或多个。在一些实施例中，计算设备1500的操作系统的任何部分都可以被配置用于使用多个显示设备1530c。在其他实施例中，显示设备1530c中的一个或多个可以由通过网络例如连接到计算设备1500的一个或多个其它计算设备提供。这些实施例可以包括设计和构造成使用另外的计算设备的显示设备作为用于计算设备1500的第二显示设备1530c的任何类型的软件。本领域的普通技术人员应该知道和领会不同的方法和实施例中，计算设备1500可以配置为具有多个显示设备1530c。

图11A和11B所示类型的计算设备1500可以在操作系统的控制下操作，操作系统控制任务计划和系统资源的访问。计算设备1500可以运行任何操作系统、任何嵌入式操作系统、任何实时操作系统、任何开源操作系统、任何专有操作系统、用于移动计算设备的任何操作系统或者能够运行在计算设备上和执行此处所述的操作的任何其它操作系统。

计算设备1500可以是任何工作站、桌面计算机、膝上型电脑或笔记本电脑、服务器机器、掌上电脑、移动电话或其他便携式通信设备、媒体播放设备、游戏系统、移动计算设备或任何其他类型和/或形式的能够通信并具有足够的处理器能力和存储器容量来执行这里所描述的操作的计算设备、电信设备或媒体设备。在一些实施例中，计算设备1500可以有不同的处理器、操作系统和输入设备，只要与所述计算设备相符就可以。

在其他实施例中，计算设备1500是移动设备，例如启用Java的蜂窝电话或个人数字助手(PDA)、智能手机、数字音频播放器或便携式媒体播放器。在一些实施例中，计算设备1500包括设备的组合，例如与数字音频播放器或便携式媒体播放器相组合的移动电话。

如图11C所示，中央处理单元1521可以包括多个处理器P1、P2、P3、P4，并且可以提供同时执行指令或者同时在多于一个的数据块上执行一个指令的功能。在一些实施例中，计算设备1500可以包括具有单核或多核的并行处理器。在这些实施例中的一个中，计算设备1500是共享存储器的并行设备，具有多个处理器和/或多个处理器核，能像访问单个的全局地址空间那样，访问所有可用的存储器。在这些实施例中的另一个中，计算设备1500是有多个处理器的分布式存储器并行设备，每个处理器只能访问本地存储器。在这些实施例中的另一个实施例中，计算设备1500既有共享的一些存储器，又有只可以被特定处理器或处理器的子集访问的一些存储器。在这些实施例中的又一个实施例中，中央处理单元1521包括多核微处理器，该微处理器将两个或更多个独立的处理器组合成单个封装，例如单个集成电路(IC)。在图11D所示的示例性实施例中，计算设备1500包括至少一个中央处理单元1521和至少一个图形处理单元1521’。

在一些实施例中，中央处理单元1521提供单个指令、多数据(SIMD)功能，例如同时在多条数据上执行单个指令。在其他实施例中，中央处理单元1521中的多个处理器可以提供在多条数据上同时执行多个指令(MIMD)的功能。在其它的实施例中，中央处理单元1521可以在单个设备中使用SIMD核和MIMD核的任何组合。

计算设备可以是通过网络连接的多个机器中的一个，或者可以包括多个这样连接的机器。图11E显示一个例示性的网络环境。该网络环境包括通过一个或多个网络1504与一个或多个远程机器1506a、1506b、1506c(通常也称为服务器机器1506或远程机器1506)通信的一个或多个本地机器1502a、1502b(通常也称为本地机器1502、客户端1502、客户端节点1502、客户端机器1502、客户端计算机1502、客户端设备1502、端点1502或端点节点1502。在一些实施例中，本地机器1502具有下面两个功能：作为客户端节点，寻求访问服务器机器提供的资源；作为服务器机器，为其他客户1502a、1502b提供对托管资源的访问。虽然图11E中只显示两个客户端1502和三个服务器机器1506，但通常每一个可以具有任意数量。网络1504可以是例如为诸如公司互联网的私人网络的局域网(LAN)、城域网(MAN\)或者例如为互联网或其他公共网络的广域网(WAN)或它们的组合。

计算设备1500可以包括网络接口1518，以通过各种连接与网络1504连接，所述各种连接包括但不限于标准电话线、局域网(LAN)或广域网(WAN)链接、宽带连接、无线连接或上述中的任何一个或全部的组合。可以使用各种通信协议建立连接。在一个实施例中，计算设备1500与其他计算设备1500通过任何类型和/或形式的网关或隧道协议通信，例如安全套接字层(SSL)或传输层安全(TLS)。网络接口1518可以包括内置的网络适配器，例如网络接口卡，适用于将计算设备1500连接到能够通信和执行此处描述的操作的任何类型的网络。I/O设备1530可以是系统总线1550和外围通信总线之间的桥接。

虽然本发明已经在特定示例性实施例中进行了描述了，但是应该理解本发明并不限于已公开的实施例，相反，在所附权利要求的精神和范围内，本发明意在覆盖各种变形和等效设置。例如，本发明的一些实施例可以提供多方呼叫，涉及例如通过WebRTC和OOB通信信道多个代理与客户的交互、代理之间的呼叫转移、管理者无声监控或耳语指导(例如，管理者和代理说话但客户听不到)，终端用户或客户可以通过WebRTC利用其他参与方召开会议。

虽然本发明实施例说明了呼叫服务器和通过该呼叫服务器路由呼叫，但在本发明的一些实施例中，客户服务代表与用户直接通过WebRTC连接通信而不用介入的呼叫服务器。在其他实施例中，为了呼叫控制，例如转移、会议或者管理者无声监控和耳语指导，要在循环中包括SIP服务器。

另外，虽然本发明实施例已经在上面WebRTC上下文中描述，但本发明的其他实施例可以使用其他的基于网页浏览器的会议技术，例如CU-RTC-网页，类似于不用依靠安装另外的插件，例如或 Talk插件。

Claims (15)

1.一种用于客户和联络中心资源之间的实时通信的方法，所述方法包括以下步骤：

通过处理器从网页浏览器应用程序接收对基于浏览器的呼叫的第一提议，所述第一提议包括所述网页浏览器应用程序所支持的第一媒体编解码器；

通过所述处理器修改所述第一提议并生成具有所述处理器支持的第二媒体编解码器的第二提议，其中在生成所述第二提议中，所述处理器删除所述第一媒体编解码器或者将所述第二媒体编解码器增加到包含所述第一媒体编解码器的列表中；

通过所述处理器传送所述第二提议，以用于所述联络中心资源接收，其中所述联络中心资源响应于所述第二提议生成应答，所述应答包括对所述第二提议中的所述第二媒体编解码器的选择；和

在实时通信期间通过所述处理器桥接在所述网页浏览器应用程序和所述联络中心资源之间交换的媒体，其中在桥接所述媒体中，所述处理器对从所述网页浏览器应用程序来的和到所述网页浏览器应用程序的媒体根据所述第一媒体编解码器进行媒体转码，并且还对从所述联络中心资源来的和到所述联络中心资源的媒体根据所述第二媒体编解码器进行媒体转码。

2.根据权利要求1所述的方法，其中，所述联络中心资源是联络中心代理设备。

3.根据权利要求2所述的方法，其中，所述联络中心代理设备支持代理网页浏览器应用程序通过所述网页浏览器应用程序发起基于浏览器的呼叫，所述网页浏览器应用程序请求所述基于浏览器的呼叫。

4.根据权利要求2所述的方法，其中，所述联络中心代理设备包括用于通过请求所述基于浏览器的呼叫的所述网页浏览器应用程序进行IP语音呼叫的IP语音客户端。

5.根据权利要求4所述的方法，其中，所述处理器根据网页信令协议建立与所述网页浏览器应用程序的网页浏览器呼叫支路，并且根据IP语音信令协议建立与所述联络中心代理设备的IP语音呼叫支路。

6.根据权利要求1所述的方法，其中，在生成所述第二提议中，所述处理器被配置为按偏好顺序排列出所述第二提议中的媒体编解码器，以用于所述联络中心资源根据已列出的所述偏好顺序进行选择。

7.根据权利要求1所述的方法，其中，如果所述处理器不支持所述第一媒体编解码器，则所述处理器在生成所述第二提议中删除所述第一媒体编解码器。

8.根据权利要求1所述的方法，还包括以下步骤：

将所述实时通信转移到第二联络中心资源，以用于交换所述网页浏览器应用程序和所述第二联络中心资源之间的实时媒体，其中所述转移不改变对等连接。

9.根据权利要求8所述的方法，还包括以下步骤：

通过所述处理器协商用于所述处理器与所述第二联络中心资源之间的实时通信的媒体编解码器。

10.根据权利要求9所述的方法，其中，所述协商步骤包括以下步骤：

通过所述处理器从所述第二联络中心资源接收包括所述第二联络中心资源支持的第三媒体编解码器的提议；和

通过所述处理器传送应答，所述应答包括根据对所述网页浏览器应用程序所支持的媒体编解码器的认知选定的媒体编解码器。

11.根据权利要求10所述的方法，其中，所述认知的获得不需要与所述网页浏览器重新协商媒体会话。

12.根据权利要求10所述的方法，其中，所述第二联络中心资源是媒体控制器，所述媒体控制器被配置成为所述网页浏览器应用程序交付音乐媒体服务，所述方法还包括以下步骤：

如果所述网页浏览器应用程序支持所述第三媒体编解码器，则所述媒体控制器根据所述第三媒体编解码器交付所述音乐媒体服务；和

如果所述网页浏览器应用程序不支持所述第三媒体编解码器，则在向所述网页浏览器应用程序交付所述音乐媒体服务前，所述媒体控制器将音乐转码为所述网页浏览器应用程序支持的媒体编解码器。

13.根据权利要求9所述的方法，其中，所述处理器与所述第二联络中心资源之间的所述协商没有与所述网页浏览器应用程序重新协商媒体会话。

14.根据权利要求1所述的方法，还包括以下步骤：

将所述实时通信从仅音频通信升级到音频及视频通信，其中，所述升级步骤包括：

通过所述处理器从所述联络中心资源的接收用于增加视频到所述实时通信的消息；

协商所述处理器和所述网页浏览器应用程序之间的视频的属性，其中响应于所述协商，所述网页浏览器应用程序显示所述联络中心资源传送的视频流，并进一步显示用于接收客户对所述网页浏览器应用程序访问客户摄像头的同意的提示；和

响应于收到客户的同意，所述网页浏览器应用程序将客户摄像头捕获的视频流传送到所述联络中心资源。

15.一种用于客户和联络中心资源之间的实时通信的方法，所述方法包括以下步骤：

通过处理器从网页浏览器应用程序接收对基于浏览器的呼叫的第一请求，所述第一请求依附于网页信令协议；

通过所述处理器与所述网页浏览器应用程序建立第一呼叫支路；

通过所述处理器修改所述第一请求并生成对IP语音呼叫的第二请求，所述第二请求依附于IP语音协议；

通过呼叫控制器接收所述第二请求，并且在响应时识别联络中心资源；

通过所述处理器与所识别的联络中心资源建立第二呼叫支路；和

通过所述处理器在所述实时通信期间桥接所述网页浏览器应用程序和所述联络中心资源之间交换的媒体，其中在桥接所述媒体中，所述处理器对到所述网页浏览器应用程序的和从所述网页浏览器应用程序来的媒体根据第一媒体编解码器进行媒体转码，并还对到所述联络中心资源的和从所述联络中心资源来的媒体根据第二媒体编解码器进行媒体转码。