在建立RTC客户端与RTC服务器之间的RTC通信连接时穿越应用层网关防火墙的电信装置和方法

摘要

本发明涉及用于在使用专有RTC信令协议的情况下建立RTC客户端（20）与RTC服务器（30）之间的RTC通信连接时穿越应用层网关防火墙（40）的方法以及电信装置（10），其中所述防火墙（40）没有对所述专有RTC信令协议的具体知识。该方法包括如下步骤：‑所述RTC客户端（20）和所述RTC服务器（30）在建立所述RTC通信连接时进行协商：针对要通过所述RTC通信连接进行交换的数据包需要所述防火墙（40）的端口（P1、P2、P3）中的哪些端口，其方式是所述数据包将至少一个标准化消息元素用作所述专有RTC信令协议的组成部分，利用所述标准化消息元素能找到涉及所要使用的端口的那些信息；‑所述防火墙（40）在借助于所述标准化消息元素建立RTC通信连接时获悉：所述防火墙（40）的端口（P1、P2、P3）中的哪些端口已经被所述RTC客户端（20）和所述RTC服务器（30）针对要通过所述RTC通信连接进行交换的数据包协商为必需的；以及‑所述防火墙（40）根据所述协商的结果动态地开启和关闭必需的端口（P1、P2、P3）。

说明书

技术领域

本发明涉及根据权利要求1所述的一种用于在建立RTC客户端与RTC服务器之间的RTC通信连接时穿越应用层网关防火墙（Application-Layer-Gateway-Firewall）的方法，以及根据权利要求8所述的一种可用来实施前述方法的电信装置。此外，本发明还涉及根据权利要求6所述的一种相应的计算机程序产品，以及根据权利要求7所述的在其上存储有所述计算程序产品的一种机器可读的数据载体。

本发明总的来说涉及穿越应用层网关防火墙（随后一般简称“防火墙”），换句话说使数据包穿过这种防火墙，例如用于根据基于IP语音（VoIP，Voice over IP）或IP视频（Video over IP）进行通信。这些通信类型属于所谓的实时传输协议通信（Real-time-Transport-Protocol-Kommunikation）（RTP通信）。随后的描述在不限制一般性的情况下以所述RTC通信（RTC=实时通信（Real Time Communication））的特殊应用情况、即通过Web浏览器进行的WebRTC通信为出发点。

背景技术

防火墙一直以来都是通过VoIP或IP视频来传送通信的障碍。其原因是用于RTP语音包或视频包（RTP=实时传输协议（Real-Time Transport Protocol），参见[RFC3550]）的以VoIP标准（H.323，SIP[RFC3261]，...）动态协商的UDP端口号（用户数据报协议（User Datagram Protocol））。

利用精确的被规定的标准信令协议（H.323/H.245 (H.323使用H.245来协商媒体数据）、SIP/SDP（会话发起协议/会话描述协议）、XMPP/Jingle（可扩展通讯和表示协议）、MGCP（媒体网关控制协议）[RFC3435]等等），防火墙制造商有可能通过实现确定的协议部分（对于协商UDP端口号重要的那些信令部分）来动态地一并读取。借此，将防火墙置于针对要传输的语音/视频RTP包开启和关闭动态协商的UDP端口的情况下。所述公知的原理也被称作防火墙应用层网关（=ALG防火墙，随后也简称防火墙）。

基于针对WebRTC的信令协议没有被标准化的事实，每个制造商都可以使用自己的专有协议，或者该制造商可替换地可以在已知的协议上进行构建。但是最后，ALG防火墙的制造商具有的问题是：他们不能像这一点例如在SIP/SDP的情况下那样地在固定信令协议上进行构建，并且因此也不能对此进行检查以便找到信令消息中的端口信息。

为了更好的理解，下面应当简短地根据图5来简述对ALG防火墙的穿越，如迄今为止对于“通过WebSockets的SIP”是可能的那样。首先，浏览器22将消息N01“HTTP请求”发送给Web服务器32，该Web服务器32用消息N02“HTTP响应”向（用于JavaScript/HTML5的）功能单元24来应答所述消息N01，由此建立HTTP连接。在升级程序的情况下、更确切地说在消息N91（WebRTC客户端20将所述消息N91发送给WebSockets服务器34，作为从HTTP连接到WebSockets连接的“WebSockets升级请求”）的情况下，协商对在WebRTC客户端20与WebSockets服务器34之间的SIP的使用。因而，防火墙40识别出：SIP被使用。这里当然也可能协商其它的标准化协议，比如XMPP（XMPP不使用SDP，而是使用Jingle，所述Jingle是允许RTC的相应的XMPP扩展）、H.323、MGCP。在从WebSockets服务器34接收到作为消息N92的升级应答之后，WebRTC客户端20将消息N93发送给WebRTC服务器30，然后防火墙40基于已知SIP/XMPP结构搜索SDP数据并且开启相应的RTP端口。这种协定以从WebRTC服务器30到WebRTC客户端20上的具有SDP应答的相应的消息N94来确认。紧接着，可以交换媒体数据，其方式是使用其它协议，比如RTP（实时协议）、STUN （NAT会话穿越工具，NAT=网络地址转换）、ICE（交互式连接建立）。

WebSockets协议可选地包含标识出所使用的信令协议（这里在本例中为SIP）的字段。这尤其是在信息框14中以“浏览器请求”和“Web服务器响应”来解释。

在该上下文中，WebRTC的问题是，WebRTC的信令协议没有被标准化。也就是说，每个WebRTC服务器的责任是它如何操作与它的WebRTC客户端的信令通信。由于在WebRTC情况下的这些专有信令方案，防火墙制造商不可能实现用于穿越或穿过防火墙、即所谓WebRTC穿越的一般的ALG防火墙解决方案。这可能在将WebRTC解决方案展开时导致问题。

WebRTC才处于商业应用的开头。但是出发点可以是，WebRTC将成为用于基于Web的实时通信的主要技术。

公知了多种用于WebRTC的防火墙技术，这些防火墙技术针对WebRTC的防火墙穿越予以讨论：

a. 如同针对SIP或H.323那样，也可以在防火墙中持久地开启针对WebRTC确定的UDP端口范围。但是这常常是具有限制性安全要求的企业所不期望的。

b. HTTP（超文本传输协议）隧道技术（HTTP Tunneling）：防火墙大多让一个端口一直开放。这是TCP端口80（TCP=传输控制协议），通过所述TCP端口80也进行HTTP数据业务[参见RFC2616]（TCP/http端口）。想法是，在WebRTC客户端与防火墙另一侧的TURN服务器（使用中继绕过NAT的穿越（Traversal Using Relays around NAT），NAT=网路地址转换，参见RFC5766）之间建立TCP隧道（“经由TCP的TURN（TURN access via TCP）“）并且将所述TCP隧道用于使UDP/RTP语音/视频包和数据包穿过防火墙。有些防火墙/企业是有限制性的，使得它们不是接受来自每个任意的客户端的HTTP通信业务，而是仅仅接受来自确定的内部服务器的HTTP通信业务（HTTP代理）。在这种情况下，WebRTC浏览器必须借助于已知HTTP连接方法[RFC2817]委托HTTP代理来建立穿过防火墙的上述TCP隧道，以便之后将其用于TURN协议。在当前讨论的在例如IETF中的另一实现形式中，可以使用穿过防火墙的“基于WebSockets的TURN”隧道（“TURN over WebSockets”-Tunnel）[draft-chenxin-behave-turn-WebSocket]。

HTTP隧道技术的所述解决方案原则上是可能的，但是要求满足各种前提条件，以便实现连续的应用。必须保证：

· WebRTC客户端（浏览器）已经实现了所描述的特征（例如HTTP连接）。就此而言，存在对浏览器制造商（Google、Microsoft、Mozilla，...）的依赖性。针对移动WebRTC客户端，比如智能电话、平板计算机（本地WebRTC应用），目前必须实现该方法本身，

· 企业已经架设并且支持必要的基础设施（HTTP代理），

·WebRTC解决方案提供商已经在防火墙之后建立了TURN服务器，作为其解决方案的一部分。

c. 防火墙/端口控制协议[RFC6887]（例如Cisco（思科公司））。想法是，WebRTC客户端在其发送语音或视频包之前通过自己的协议向防火墙给予开启确定的UDP端口的委托。防火墙控制协议从大约2003年是公知的。但是在实际中，该方案迄今为止还不曾得到实施，这尤其是由于关于安全性、认证、授权的考虑，企业（CIO，IT部门）大多不想让它们的防火墙被大量的客户端或服务器“控制”。

d. 端口复用（Port Multiplexing）：在该方案中，一个WebRTC呼叫（例如一个呼叫的所有音频和视频流）的多个或所有RTP流直至整个系统的多个或所有呼叫的全部RTP流都可以通过一个唯一UDP端口来传输。该方案通过需要较少的端口源减轻了防火墙端口问题，但是未解决首先克服限制性防火墙的基本问题。此外，不是WebRTC客户端或服务器的每个制造商都将支持与基于SIP/XMPP/H.323的系统协作的端口复用（可选）。端口复用尤其对于具有大的直至非常大的伸缩性要求（例如公共、住宅服务，例如Google，...）的WebRTC解决方案的制造商来说是一个选项。

发明内容

因此，本发明所基于的任务是，克服前述缺点并且提出一种用于穿越防火墙的方法，该方法一方面满足所有的安全性要求，而另一方面应操作简单。此外，本发明所基于的任务是，提出一种可用来实施该方法的相应的电信装置。

该任务利用根据权利要求1所述的通常计算机实现的方法、根据权利要求6所述的计算机程序或计算机程序产品、根据权利要求7所述的在其上存储有该计算机程序产品的机器可读的数据载体来解决，以及利用根据权利要求8所述的电信装置来解决。本发明的有利的改进方案是从属权利要求的主题。

根据本发明，RTC客户端和RTC服务器在RTC通信连接应当被建立时（这例如在通过HTTP请求打开网页时实现）在使用专有（即非标准化）RTC信令协议的情况下关于如下情况进行协商：为了能够传输对于RTC通信连接必要的数据包，需要ALG防火墙的端口中的哪些端口，其方式是所述数据包将至少一个标准化消息元素用在专有RTC信令协议的报文（Kontext）中、即作为专有RTC信令协议的组成部分，利用所述标准化消息元素能找到涉及所要使用的端口的那些信息。防火墙没有对所述专有RTC信令协议的具体知识，并且在使用标准化消息元素的情况下建立RTC通信连接时获悉：防火墙的端口中的哪些端口已经由RTC客户端和RTC服务器协商、即已经被认为是必需的，以便可以传输要通过RTC通信连接来交换的数据包。换句话说，防火墙可以“监听”：需要哪些端口，并且因此所述防火墙可以依据RTC客户端与RTC服务器之间的协商结果动态地开启和关闭必需的端口。

通信协议中的消息元素是一个或多个信令消息的句法片段，在所述信令消息中编码有如下信息，所述信息在通信网络的网络部件和/或终端设备中在交换技术过程的范围内被分析。在消息元素的情况下，标准化元素和制造商特定（专有）元素有区别；后者对于通信网络的基本功能不是必不可少的，并且通常被其它制造商的网络部件和/或终端设备忽略。根据本发明的标准化消息元素包含关于如下连接的标识信息，所述连接被建立用于从终端设备传送媒体数据并且将媒体数据传送到终端设备并且相应地必须由防火墙例如通过端口开启而沿发送和接收方向导通。

对这种消息元素的进一步阐述可从EP 1 317 150 A2中得知。

因此，换句话说，根据本发明的方法通过如下方式解决所基于的问题：将扩展用作RTC信令信道的组成部分，该扩展使得防火墙能够在RTC连接建立时监听：针对进行交换的语音和/或视频包动态协商了哪些端口或UDP端口，并且借此使得防火墙能够针对RTP通信业务动态地开启和关闭相应的UDP端口。在此，所提到的报文可以在建立RTC信令信道期间、在RTC信令期间或者紧接着RTC信令以附加字段的形式被提供，所述附加字段包含如下信息，所述信息在信令消息中被用于之后找到RTP端口。对如下那个扩展的确定或标准化在下文也被称作WebRTC信令或者也简称为WebRTCSig，所述扩展限定了如下RTC信令部分的报文，所述RTC信令部分在被防火墙一并读取时足以实现UDP/RTP端口控制、即所述开启和关闭。

根据本发明的方法因此提供如下多个优点：

- 不需要实现在安全性要求方面曾是高度障碍的防火墙控制协议；

- 不必在防火墙中持久地保持开启端口或者甚至端口范围，这出于安全原因可能会是令人怀疑的。对此应注意，对其中通过一个唯一的UDP端口传输多个或所有UDP流的端口复用技术的使用预计将来首要地被高伸缩性的解决方案的制造商所支持；

- 在其中不能应用基于HTTP隧道技术的解决方案的情形下，根据本发明的方法是一个相对简单但可靠地实现的替换方案，所述解决方案可以显著促进WebRTC的高度流行；通过使用本发明，例如可以实现防火墙解决方案，以便尤其是可以针对确定的WebRTC应用提供连续的解决方案；

- 此外，根据本发明的解决方案还可以以简单方式例如通过IETF被标准化，使得可以实现如下通用的实现方案，所述通用的实现方案对于基于WebRTC的解决方案和WebRTC防火墙的所有制造商来说都是开放的。

在使用安全WebSockets协议（WSS）（也就是说通过TLS（传输层安全性）的WebSockets连接）的情况下，防火墙不能毫无困难地读取包含在WSS连接中的更高的WebRTC信令部分，其中针对该问题，例如对TLS逐段报文（TLS-Hop-by-Hop-Kontext）的使用可以充当解决方案，如类似于在会话边界控制器（SBC）的情况下被执行的那样。ALG防火墙封闭了TLS，也就是说，加密仅仅进行到防火墙或从防火墙开始。TLS总归只是逐段的。因此，ALG防火墙一方面与ALG防火墙一侧的WebRTC客户端（或代理）具有TLS关系，而与ALG防火墙的另一侧的webRTC服务器（或接入节点（Access Node））具有另一TLS关系。

根据本发明的一个有利的改进方案，为了协商必需的端口、即在RTC客户端与RTC服务器之间交换关于RTC信令的信息和参数，使用事先限定的（任意编号的）信令类型，该信令类型在RTC客户端与RTC服务器之间的HTTP连接初始建立之后借助于所谓的“WebRTCSig握手”来交换。在这种情况下，一个有利的设计方案在于，WebRTCSig握手被实施为从HTTP连接到WebSockets连接的升级程序的部分，并且产生RTC信令的报文。为此，必要时在WebSockets协议中需要扩展，对此例如在报头中使用特别的或限定的（通常附加的）字段。可替换于此地，WebRTCSig握手也可以只有在HTTP连接已经被转换（或升级）成WebSockets连接之后才进行，这借助于自身的协议来执行，该协议优选地只包括几个附加的字节并且也被称作“薄层协议（Thin Layer Protocol）”或“基于WebSockets的WebRTCSig”。相对刚才提到的只有在升级程序之后才进行WebRTCSig握手的替换方案，最先被提到的其中WebRTCSig握手作为升级程序的一部分的替换方案提供如下优点，在时间上节省了一个来回（Roundtrip）。关于精确的时间点或定时，例如在RTC客户端已经从RTC服务器加载JavaScript（JS客户端）之后进行WebRTCSig握手。

根据所使用的RTC信令协议，真正的WebRTCSig信息例如可以包括信令协议的如下变型：

1) WebRTCSig类型1 = 基于WebSockets的SIP和SDP

2) WebRTCSig类型2 = 基于WebSockets的XMPP和Jingle

3) WebRTCSig类型3=“嵌入SDP的专有WebSockets信令（偏移（Offset））”

也就是说，具有SDP协议消息的WS信令报告（WS=WebSockets）（例如具有SDP提议的WS安装；具有SDP应答的WS连接）。对此，为了防火墙找到SDP提议/应答消息的开头，可以/必须一并给出偏移值，该偏移值对SDP提议消息的开头进行编址。

为此应注意，SDP出于两个原因适于作为会话信令：

a）版本1中的WebRTC浏览器API（在W3C=万维网联盟（World Wide Web Consortium）中被标准化）是基于SDP的。

b）SDP也是以SIP的会话描述协议。

在RFC 3264中，作为示例性的标准化消息元素，提议-应答模型是以行“m=video 53000 RTP/AVP 32”来说明的，所述行“m=video 53000 RTP/AVP 32”说明视频应通过端口53000来传输。

因此，SDP一方面使与SIP界的协作变得容易，而另一方面使在会话信令与WebRTC-API之间的客户端侧的协作变得容易。

如果制造商使用专有信令协议，则他非常可能仍然使用具有专有消息的SIP，因为WebRTC-API同样使用SDP。在根据本发明的WebRTCSig类型3的情况下，例如将会一并用信号通知ALG防火墙应在字节77处开始并且应被解释为SDP协议（因为其确实重新被标准化），作为附加信息。在这之前的全部字节、即直至并包括字节76为止都是“专有安装消息”的一部分。

可替换地，浏览器也可以将WebRTC-API的SDP映射到一些其它的（例如H.245、Jingle或专有格式）上并且将WebRTC-API的SDP用于RTC信令。于是，这将会由另一WebRTCSig类型来表征。该变型对应于根据本发明的方法的一个有利的改进方案，根据所述改进方案，使用具有信令报告的信令协议，在所述信令报告中使用具有被嵌入的偏移的会话描述协议提议消息，其中所述偏移对该消息的开头进行编址。

4) WebRTCSig类型4=显性SDP协议

可以显性地将用于WebRTC的SDP协议标准化。

5) WebRTCSig类型5=具有根据本发明的、预先限定的并且通信的句法的经协商的端口。

6) WebRTCSig类型6=以REST样式（REST=表述性状态传输（Representational State Transfer））的经协商的端口：具有包含所述端口的被限定的（子）结构的已知的URI（统一源标识符）。

7) WebRTCSig类型7=以REST样式的经协商的端口：已知的URI，其具有指向要从那里获得端口的源（服务器）的指针或指示器。

这两种刚才提到的变型又对应于根据本发明的方法的一个有利的改进方案，根据所述改进方案，在RTC信令报告中限定以REST样式的经协商的端口。

8) WebRTCSig类型8=一个文本串（Textstring）作为参数被插入，所述参数表征SDP在信令消息中的开头。该文本串本身是任意的，它只是不应当在所述消息的其余部分中再次出现。

此外，本发明所基于的任务还利用一种电信装置来解决，所述电信装置具有至少一个RTC客户端、至少一个RTC服务器和至少一个具有多个端口的防火墙。根据本发明，防火墙具有控制装置，所述控制装置被设计为使得可以实施前述方法。

此外，一种用于执行前述方法的计算机程序以及一种在其上存储有这种计算机程序的机器可读的数据载体被视为属于本发明。

根据目前的理解，IETF将不会像例如已经针对SIP或H3.323所做的那样对完整的WebRTC信令协议进行标准化。因而，当在所有环境下都必须动态地理解信令协议时，ALG防火墙必须实现WebRTC应用的所有制造商的WebRTC信令协议，以便找到在其上发送真正的RTP包的经协商的UDP端口。这可以通过将所选的信令协议编组成类别（即例如任意编号）来避免。如果ALG防火墙获悉或一并读取到：涉及WebRTC信令类型1，则该 ALG防火墙得知：该ALG防火墙必须根据SIP/SDP进行解析。而如果ALG防火墙一并读取到：使用了具有偏移77的WebRTC信令类型3，则该ALG防火墙得知：该ALG防火墙必须将从字节77开始的消息作为SDP协议来解析，等等。接着，WebRTC信令类型4是从字节1开始的SDP协议。WebRTC信令类型5加上显性的源和目的地UDP端口说明会将UDP端口准确地通知给ALG防火墙，其中在这种情况下不使用SDP协议。

附图说明

本发明的其它优点、特征和特点从随后参考附图对有利的实施方式的描述中得出。其中：

图1示意性地示出了关于根据本发明的电信装置的一个实施方式的示意性概况；

图2至4示意性地示出了根据本发明的用于穿越防火墙的方法的三个实施方式的示意性流程图；以及

图5示意性地示出了已经公知的用于穿越防火墙的方法的示意性流程图。

具体实施方式

在图1中示出的根据本发明的电信装置10包括RTC客户端20、RTC服务器30和防火墙40。消息在防火墙40与一方面客户端20和另一方面服务器30之间的交换由少数几个箭头来表示。此外，还示意性地示出了：防火墙40具有多个端口，所述多个端口纯示意性地用P1、P2和P3来表示。防火墙40包含控制装置42、例如CPU或处理器组，所述控制装置42实现防火墙40的功能。此外，还示意性地说明了CD-ROM 90，作为数据载体的例子，在所述数据载体上存储有计算机程序或计算机程序产品92，其中具有相应的计算机程序92的数据载体90被提供给所述控制装置42，以便实现根据本发明的方法。

图2示出了根据本发明的用于穿越防火墙的方法的第一实施方式，利用所述方法来实现根据上面阐述的RTC信令类型3。首先，浏览器22将消息N01“HTTP请求”发送给Web服务器32，所述Web服务器32用消息N02“HTTP响应”向（用于JavaScript/HTML5的）功能单元24来应答所述消息N01，由此建立HTTP连接。然后，功能单元24在WebSockets升级程序的过程中将相应的消息N11发送给Web服务器32中的WebSockets服务器34，其中所述消息N11包含WebRTC信令类型和SDP偏移标记。WebSockets服务器34用消息N12向WebRTC客户端20确认升级程序。最后，WebRTC客户端20向WebRTC服务器发送消息N13，该消息N13包含信令消息始于SDP偏移为255的信息。因此，防火墙40在字节255处找到SDP。通过从WebRTC服务器30到WebRTC客户端20（它们二者都使用提议/应答协议）上的相应的消息N14来结束具有SDP偏移标记的信令。通过这种类型的信令，防火墙40可以“一并读取到”：在哪里可找到对于这些防火墙重要的信息（这里从字节255开始）。该信息在新的报头字段中被传送，在该报头字段中说明了类型和SDP偏移，如在信息框11中以标题“浏览器请求”作为最后一行被标出的那样。如在信息框11中以在最后一行中的标题“Web服务器响应”来解释的那样，WebRTC服务器30向WebRTC客户端20确认：所协商的信令类型是编号3，并且给出“OK”以识别出信令利用协商的SDP偏移标记来实现。

其余的、在图2中示出的名称对应于在本技术领域中的常见名称，并且因而不需要加以特别阐述。

在成功结束信令之后，媒体数据可以被传输穿过防火墙40，为此使用其它协议，诸如RTP（实时协议）、STUN（NAT会话穿越工具，NAT=网络地址转换）、ICE（交互式连接建立）。

如已经提及的那样，根据本发明来传送WebRTC信令的类型（在本例中，类型具有（任意分配的）编号3），并且在具有名称SDP偏移（SDP_Offset）的位置上有文本串，该文本串表征指向信令消息中的SDP的指针或指示器。所述文本串本身是任意的，它只是不应当在所述消息的其余部分中再次出现。替代于在本例中所说明的名称“SDP偏移”，例如足够长度的随机字符序列也可能满足所述要求。

根据本发明的方法的在图3中示出的第二实施方式与第一实施方式的区别在于，在升级到WebSockets连接的升级程序中，利用消息N21和N22来传输另一信令类型（在本例中：5）以及防火墙40应当开启的端口值。换句话说，信令消息N23包含在本例中用“开启_端口：62255、62256、31234、31235”来表示的组分，并且跟随着确认消息N24。与此相应，防火墙40开启相应的端口。因此，在新报头字段中，记录有信令类型编号5以及对“开启_端口”的说明。在最后的位置上有文本串，该文本串表征用于信令消息中的媒体的RTP端口。所述文本串本身虽然是任意的，但是它不应当在所述消息的其余部分中再次出现。替代于在信息框12中以标题“浏览器请求”、最后一行来说明的例子“开启_端口”，例如足够长度的随机字符序列也可能满足所述要求。以相应的方式，WebRTC服务器30对WebRTC客户端20的应答包含对协商的编号5的信令类型的确认以及对端口已经被开启的（可选的）确认（同样参见信息框12）。因此，执行具有端口值的信令。

根据本发明的方法的在图4中示出的第三实施方式与所述两个在先的实施方式的区别在于，在升级到WebSockets连接的升级程序中，利用消息N31和N32传送另一WebRTC信令类型、即编号8以及传送文本串，该文本串表征在信令消息N33和N34中的SDP的开头。因而，防火墙40识别出使用了具有嵌入的SDP的未知协议，而且搜索文本串“这里_开始_SDP（Here_starts_SDP）”，并且开启已经包含在SDP中的那些RTP端口。这导致：在新引入的报头字段中，将编号8称为信令类型，并且文本串“这里_开始_SDP”被包含在根据信息框13的“浏览器请求”中。因此，WebRTC服务器30对WebRTC客户端20的相应的应答也（在消息N34中）包含协定的信令类型8以及对用SDP_开始_串执行信令的确认。替代于作为例子提到的文本串“这里_开始_SDP”，也可以使用足够长度的其它随机字符序列，只要所述随机字符序列不在所述消息的其余部分中再次出现。

要理解的是：除非另行说明或者出于技术原因不可行，本发明的参考所示出的实施方式描述的特征，诸如所使用的客户端、服务器、连接和协议的类型和设计方案也可以存在于其它的实施方式中。此外，在各个实施方式的这样的以组合描述来的特征中，不一定必须总是在一个有关的实施方式中实现所有特征。

附图标记列表

10=电信装置

11-14 =信息框

20=（Web）RTC客户端

22=浏览器

24=功能单元

30=（Web）RTC服务器

32=Web服务器

34=WebSockets服务器

40=防火墙

42=控制装置

90=数据载体

92=计算机程序产品

N01-N94 =消息

P1-P3 =端口