用于从WebRTC服务器向WebRTC客户端安全且动态地重新加载附加软件的方法

文档序号:10494365阅读:287来源:国知局
用于从WebRTC服务器向WebRTC客户端安全且动态地重新加载附加软件的方法
【专利摘要】本发明涉及一种计算机装置(10)以及一种由计算机实现的、用于从WebRTC服务器向WebRTC客户端安全且动态地重新加载附加软件(SW)的方法,其特征在于,WebRTC数据通道被用来传输软件(SW)。
【专利说明】
用于从WebRTG服务器向WebRTG客户端安全且动态地重新加载附加软件的方法
技术领域
[0001 ] 本发明涉及一种由计算机实现的、用于从WebRTC服务器向WebRTC客户端安全且动态地重新加载附加软件的方法以及一种相应的计算机装置。
【背景技术】
[0002]WebRTC浏览器开发商、如Google或Moz i I Ia通常借助确定的编解码器来发行其浏览器。属于这些编解码器例如是音频编解码器,例如G.711和OPUS,以及视频编解码器,为此作为示例应该提到VP8。因此,这种编解码器是这些具有webRTC能力的浏览器的完整的组成部分。
[0003]但对于WebRTC应用的开发商而言,不能毫无困难地在其项目中以安全的方式和方法集成附加的、可能还不包含在原来的浏览器版本中的编解码器,以便由此为其用户产生附加的用处。问题的一部分在于,这种附加的编解码器经常受到商业专利权的保护,并且因此只有通过支付相应的许可费用才能获得并安装。
[0004]为了这种编解码器的重新安装,通常这样做,S卩:这些编解码器可通过所谓的浏览器插件被加载并接着被安装。但对于WebRTC浏览器,存在以下缺点:
[0005]-1ETF/W3C中的网页实时通信(WebRTC)文件规定,网页实时通信应该无插件就行。这就意味着,所涉及的编解码器应该固有地被集成在浏览器中,也就是说,应该已经通过浏览器开发商被固定地内置。
[0006]-浏览器开发商在实现上述要求时的特殊难题在于,存在商业专利权(经常也简称为知识产权或者说IPR)并且因此伴随着许可成本的编解码器不能利用开发商的免费浏览器来提供。
[0007]-浏览器插件构成了安全风险,因为不能够安全地控制由此被重新安装的编解码器的来源,并且因此浏览器插件在WebRTC应用解决方案对于许多用户的接受度方面也是额外的障碍。
[0008]编解码器的安全的重新安装的上面以音频和视频编解码器为例描述的难题也十分普遍地存在于其他应该在WebRTC客户端、例如浏览器-尤其是WebRTC浏览器-中被重新安装的软件中。

【发明内容】

[0009]因此,本发明所基于的任务是,克服这些缺点,并且说明一种用于从WebRTC服务器向WebRTC客户端安全且动态地重新加载附加软件的方法以及一种相应的计算机装置。
[0010]该任务借助一种根据权利要求1所述的方法以及借助一种根据权利要求9所述的计算机装置来解决。此外,一种相应的根据权利要求7所述的计算机程序或计算机程序产品以及一种根据权利要求8所述的机器可读取的、相应的计算机程序被保存在其上的数据载体也有助于解决这一难题,它们应该同样被看作为隶属于本发明。
[0011]本发明的有利扩展方案是从属权利要求的主题。
[0012]根据本发明,一种由计算机实现的、用于从WebRTC服务器向WebRTC客户端安全且动态地重新加载附加软件的方法以以下步骤进行:在WebRTC客户端与WebRTC服务器之间建立WebRTC连接的过程中,通过以下方式传输所需的软件,即为此使用WebRTC数据通道。通过这种方式,就可以以安全且动态的方式和方法重新加载并重新安装所需的软件,而不必动用浏览器插件。WebRTC数据通道另外也被称作为WebRTC数据信道。这种WebRTC数据通道本身由IETF/W3C标准化,并且立足于安全的基于IP/UDP/DTLS/SCTP的传输。
[0013]根据本发明方法的一种有利的实施方式,所述软件被确定用于实时应用。尤其是这种软件是一种编解码器,例如一种音频或视频编解码器。
[0014]能够有利的是,所述WebRTC数据通道在软件传输后保持并且没有立即被再次取消,以便由此例如能够实现没有时间延迟而快速重新加载其他所需的软件。
[0015]此外可能有利的是,自动地在WebRTC客户端与WebRTC服务器之间建立WebRTC连接的时间点上传输软件,使得用户不必特意担心这一方面。对于电话呼叫或会议的示例而言,这可能就意味着,自动在达成电话呼叫或达成会议的时间点上进行音频编解码器的下载。但替代地,也可设置,专门由用户触发的编解码器的下载。于是为此将优选设置安装区域(install button)。作为付费模式,为此例如将可以考虑所谓的“使用才支付(pay as you
V,
use) ο
[0016]如果软件在WebRTC客户端仅临时被加载并且只有在预先确定的时间段期间才保持可用,则可带来其他优点。这在上述示例的情况下就意味着,重新加载的编解码器仅供电话呼叫期间或者会议期间使用,并且只能够使用那么长,直到WebRTC客户端(尤其是WebRTC浏览器)重新启动。这种做法同样支持“使用才支付”的计价模式。替代地,所重新加载的编解码器当然也可被永久安装并且保持可用,由此,即使在WebRTC客户端或者WebRTC浏览器重启后,该编解码器仍可供用户使用。
[0017]根据本发明的方法有利地被实现为计算机程序或计算机程序产品,并且能够被保存在机器可读取的数据载体上。因此,这两种设计方案同样可被看作为隶属于本发明。
[0018]一种根据本发明的计算机装置包括WebRTC客户端在其上运行的第一计算机,其适用于执行上述方法以用于安全且动态地从WebRTC服务器向WebRTC客户端重新加载附加软件。此外,根据本发明的计算机装置包括第二计算机,其用作为WebRTC服务器,并且所要传输的软件借助该第二计算机是准备好的或可访问的,使得所述软件可以根据查询通过WebRTC客户端来调用或被传输到该客户端上。为了连接这两个计算机,设置一种相应的网络,所述网络必须必然地被实现为,使得其能够提供WebRTC数据通道(连同RTC客户端与WebRTC服务器之间的WebRTC连接)。很明显,借助根据本发明的计算机装置,能够实现与结合根据本发明的方法所描述的相同的优点。
【附图说明】
[0019]由下面参照附图对有利的实施方式所进行的描述得出本发明的其他优点、特征和特点。其中:
[0020]图1示出根据本发明的计算机装置的一种实施方式的示意性概览图;以及
[0021]图2示出一种示意性图示,说明根据本发明的方法如何基于标准化的WebRTC-协议栈来实施。
【具体实施方式】
[0022]所述计算机装置10又包括第一计算机12、用作为WebRTC服务器的第二计算机14以及网络16,所述网络连接所述第一计算机12和所述第二计算机14并且此外被构型为,使得该网络能够提供WebRTC连接-WebRTC数据通道也属于WebRTC连接。只要这被达成,所述软件SW就可从服务器14传输到所述第一计算机12中的客户端上,这通过相应的箭头被形象地示出。
[0023]在所述第一计算机12中,示意性地示出了⑶-ROM90,作为数据载体的示例,计算机程序或计算机程序产品92可被保存在该数据载体上,所述计算机程序或计算机程序产品又示意性地作为具有程序代码的页面被示出。在所述第一计算机12上安装了所述计算机程序90后,在该计算机12上运行的WebRTC客户端可以以根据本发明的方式继续运行,以便执行根据本发明的方法。为了说明根据本发明的方法,随后以以下为出发点,即:WebRTC客户端作为WebRTC浏览器(下面简称为“浏览器”)存在,该浏览器为了电话呼叫(简称为“呼叫”)需要从WebRTC服务器(下面简称为“服务器”)14加载音频编解码器,因为根据标准被集成在浏览器内的音频编解码器(例如G.711或OPUS)被视为不充分。这种具有扩展功能范围的音频编解码器例如基于H.264或H.265。
[0024]对于本发明的应用,自然还要提到语音编解码器、如G.729的下载。
[0025]根据下面的示例,向用户在其用户界面(例如通过菜单项“调节”)上在其所安装或者所使用的浏览器内提供加载附加编解码器的选项。替代地,这也可以自动进行,对此作为示例可以列举WebRTC客户端或浏览器的安装、第一电话呼叫的时间点等等。
[0026]根据本发明,首先进行信令,用于建立连接以及用于建立浏览器的相应能力。这在图2左边的柱体中示出。因为这里所使用的命名和简称本身是公知的,所以放弃详细描述。这一左边的柱体以及在右侧旁边所示的右边的柱体为所谓的WebRTC协议栈的部分。在信令后,建立从浏览器到预定义的服务器地址的WebRTC-有效数据连接,其中,在此使用WebRTC-会话信令。在此,WebRTC数据通道的建立以及在所述浏览器与所述服务器应用之间的该数据通道的特性达成例如通过SDP(会话描述协议)提议/应答法进行。在标准WebRTC中,使用SCTP(流控制传输协议)通道,该SCTP通道通过为加密协议的DTLS(数据报传输层安全Datagramm Transport Layer Security)来保护。通过这种安全的、动态地在浏览器与服务器之间达成的数据通道,编解码器文件被安全地传输给浏览器。在浏览器侧,通过浏览器-API (API =Applicat1n Programming Interface应用编程接口)实现编解码器的安装。在此,所述浏览器-API对于浏览器开发商可以是特别的,但也可以是标准化的。WebRTC数据通道的这种构建以及用来传输编解码器的应用基本构成了根据本发明的方法,并且在图2右边的柱体中,通过以虚线示出的方框来表示。由虚线的方框可以看出,数据通道使用了SCTP,该SCTP又通过DTLS来保护。这些协议属于标准化的WebRTC,因此它们不需要详细地描述和解释。然后,在使用重新加载的软件或重新加载的编解码器的情况下,通过图2中右边柱体的左边部分,也就是通过RTC对等连接和SRTP(安全实时传输协议Secure Real-TimeTransport Protocol)、即用来传输数据、尤其是例如通过自有的WebRTC连接所传输的如音频和/或视频数据的媒体数据的“真正的”有效通道,实现真正的通信。
[0027]在该附加的编解码器的成功下载和本地安装后,终端或者说浏览器与服务器之间的数据连接可被取消。替代地,WebRTC数据通道也可保留,以便例如能够更快地重新加载其他编解码器或其他软件。自该时间点起,用于WebRTC音频应用和/或WebRTC视频应用、如电话呼叫或会议的浏览器既可利用已经被集成在浏览器内的、不伴随着专利权的编解码器(例如6.711、(^1^、¥?8),又可利用刚才所述的附加地被重新加载的编解码器(浏览器开发商在开发浏览器时不能把所述被重新加载的编解码器集成到浏览器中,因为它们享有商业专利权,并且伴随着相应的许可成本)。
[0028]根据应用可规定,自动在达成的呼叫或引入的会议的时间点上进行编解码器下载。但也可规定,编解码器下载根据用户提出的明确要求来引入并执行。
[0029]如果所重新加载的编解码器被永久安装,那么其在浏览器重启后继续可供使用。针对该应用方式,例如可能发生相关编解码器的相当高的许可支付。因此,如果所重新加载的编解码器仅被临时加载(也就是说保持在RAM内)并且仅在呼叫期间或者会议期间可供使用或者仅那么长地可用地保持,直到浏览器重启,就能够带来优点。对此例如另一种付款模式是可以的,在这种付款模式下,只有具体的使用需要支付。在极少使用编解码器的情况下,这可能对于用户而言是大的优点。
[0030]总之可理解的是,根据本发明,借助所重新加载的软件(例如编解码器)可实现WebRTC客户端、例如浏览器的扩展,利用该软件该WebRTC客户端的配置变为可能。借助根据本发明的方法,该被重新加载的软件不仅取自安全的来源-也就是说WebRTC服务器,而且通过安全的WebRTC数据通道形式的路径来传输。因此,能够以十分安全的方式实现WebRTC客户端的功能的扩展。因为该扩展可随时使用并且也可任意改变,所以该扩展也是非常动态的。
[0031 ]本发明也可被用于其他应用,如即时通讯或E-mail交流中。
[0032]可以理解的是,本发明的参照所示实施方式描述的特征、例如计算机装置的各个组件的类型和设计方案或者所述方法的各个步骤的顺序也可存在于其他实施方式中,除非另作说明或者出于技术的原因而本身被禁用。
[0033]附图标记列表
[0034]10计算机装置
[0035]12第一计算机
[0036]14第二计算机/WebRTC服务器
[0037]16 网络
[0038]90数据载体
[0039]92计算机程序
[0040]Sff 软件
【主权项】
1.由计算机实现的、用于从WebRTC服务器向WebRTC客户端安全且动态地重新加载附加软件(SW)的方法,其特征在于,为了传输所述软件(SW),使用WebRTC数据通道,并且所述软件(SW)被用于扩展WebRTC客户端的功能。2.根据权利要求1所述的方法, 其特征在于,所述软件(SW)是一种用于实时应用的软件。3.根据权利要求1或2所述的方法, 其特征在于,所述软件(SW)是一种编解码器,尤其是一种音频或视频编解码器。4.根据上述权利要求中任一项所述的方法, 其特征在于,所述WebRTC数据通道在传输所述软件(SW)后被保留。5.根据权利要求1至4中任一项所述的方法, 其特征在于,所述软件(SW)的传输自动在所述WebRTC客户端与所述WebRTC服务器之间建立WebRTC连接的时间点上进行。6.根据权利要求1至5中任一项所述的方法, 其特征在于,所述软件(Sff)仅被临时加载在WebRTC客户端中,并且只有在预先确定的时间段期间才保持可用。7.—种计算机程序产品(92),用于执行根据上述权利要求中任一项所述的方法。8.—种机器可读取的数据载体(90),具有被保存在其上的、根据权利要求7所述的计算机程序产品(92)。9.一种计算机装置(10),包括: -第一计算机(12),WebRTC客户端在第一计算机上运行,所述WebRTC客户端适合于执行根据权利要求1至5中任一项所述的方法; -第二计算机(14),所述计算机用作为WebRTC服务器,并且软件(SW)以可调用的方式被保存在第二计算机上;以及 -网络(16),所述网络将所述第一计算机(12)与所述第二计算机(14)连接并且适合于提供WebRTC数据通道。
【文档编号】G06F9/445GK105849693SQ201480061235
【公开日】2016年8月10日
【申请日】2014年11月3日
【发明人】K·克拉格霍费尔, V·兰斯迈尔
【申请人】统有限责任两合公司, 统一有限责任两合公司
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1