CN108781232A - 通话信令期间的协议回退 - Google Patents

Abstract

在发起设备与响应设备之间建立会话。根据优选的网络化协议将会话请求从发起设备发送至远程设备。如果在初始时段内没有在发起设备处接收到临时响应，则发起设备根据非优选的协议将另一会话请求发送至其他设备。如果在初始时段内接收到对请求的临时响应，则发起设备在经扩展的时段内继续监视所经过的时间。如果在经扩展的时段内没有接收到最终响应，则发起设备根据非优选的协议将另一会话请求发送至其他设备。如果在经扩展的时段内接收到最终响应，则根据优选的网络化协议在发起设备与其他设备之间建立会话。

Description

通话信令期间的协议回退

背景技术

可以在发起设备(即，主叫设备)和至少一个响应设备(即，被叫设备)之间建立通信事件。所述通信事件例如可以是通话(音频或视频通话)、屏幕或白板共享会话、其他实时通信事件等。所述通信事件可以在发起设备与多个响应设备之间，例如其可以是群组通话。

可以通过执行经由网络交换消息的初始信令过程来建立通信事件，以便提供能够通过其在所建立的通信事件中在设备之间交换媒体数据(音频和/或视频数据)的方式。该信令阶段可以根据各种协议来执行，例如SIP(会话发起协议)或定制的信令协议。有可能通过该信令阶段呈现的媒体数据交换能够使用任何合适的技术来实现，例如使用语音或IP视频(VoIP)，并且可以或可以不经由与该信令相同的网络。

可以在诸如通话控制器的通信控制器的控制之下建立通信事件。即，该通信控制器可以至少对该信令过程进行控制。例如，信令过程中被发送给主叫方和被叫方设备的所有消息都可以从通信控制器发送，以及在设备自身之间发送。例如，主叫设备可以通过向通信控制器发送初始请求来发起信令过程，但是通信控制器可以具有接受或拒绝该初始请求的自由。如果该初始请求被接受，则通信控制器自身可以向(多个)呼叫设备发出(多个)通话邀请。并且(多个)响应设备进而可以对通信控制器(而不是直接对发起设备)进行响应。

发明内容

提供了该发明内容以用简化的形式引入在以下的具体实施方式中进一步描述的概念的选择。该发明内容不旨在标识所要求保护主题的关键特征或必要特征，也不旨在用于限制所要求保护的主题的范围。

根据该主题的一些方面，在发起设备和远程设备之间建立会话。根据优选的网络化协议将会话请求从所述发起设备传输至所述远程设备。由所述发起设备监视从传输的时间开始所经过的持续初始时段的时间。如果在所述初始时段内在所述发起设备处没有接收到对所述请求的临时响应，则所述发起设备根据非优选的协议将另一会话请求发送至另一设备。如果在所述初始时段内接收到对所述请求的临时响应，则所述发起设备在经扩展的时段内继续监视所经过的时间。如果在所述经扩展的时段内没有接收到对请求的最终响应，则发起设备根据非优选的协议而将另一会话请求发送至所述另一设备。如果在所述经扩展的时段内接收到对请求的最终响应，则根据优选的协议在所述发起设备与所述另一设备之间建立会话。

另一方面针对由网络设备执行的、压缩消息以用于从网络设备发送至另一设备的方法。生成未经压缩的消息以用于经由网络发送至所述另一设备。通过对所述未经压缩的消息应用压缩功能来生成具有降低的消息大小的所述消息的经压缩的版本。

确定经压缩的版本的降低的消息大小。将所述降低的消息大小与多个传输协议中的优选的传输协议的最大传输分组大小进行比较。如果所述降低的消息大小超过所述优选的传输协议的所述最大传输分组大小，则根据所述传输协议中的非优选的传输协议而将所述消息的未经压缩的版本或所述经压缩的版本封装到一个或多个传输分组中，并且经由所述网络根据所述非优选的传输协议将所述一个或多个传输分组发送至所述另一设备。如果所述经压缩的消息大小不超过所述优选的传输协议的所述最大传输分组大小，则根据所述优选的传输协议将所述消息的所述经压缩的版本封装到单个传输分组中，并且经由所述网络根据所述优选的传输协议将所述传输分组发送至所述另一设备。

附图说明

为了更好地理解该主题并且示出其如何生效，仅作为示例对以下附图进行参考，其中：

图1示出了已知类型的通信系统；

图1A示出了可以如何使用TLS来确保TCP连接的安全；

图1B示出了可以如何使用DTLS来确保UDP通信的安全；

图2示出了可以在其中实现本主题的实施例的通信系统的框图；

图2A示出了服务器池形式的示例性通话控制器；

图3示出了用户设备的框图；

图4示出了功能可以如何由基于分组的网络的不同架构分层处的发起设备所实现；

图5A示出了针对预通话建立阶段的信令图；

图5B示出了随后的通话建立阶段的信令图；

图5C示出了针对在通话建立阶段中发送的第一请求所执行的额外信令；

图6示出了协议回退过程的流程图；

图7示出了针对应用层分组的示例性数据结构；以及

图8B和8A展示了分别在具有和没有压缩词典的情况下压缩功能的操作。

具体实施方式

除其他之外，本公开的不同方面分别针对于：

1)一种用于在提供安全通信信令(例如，通话信令)时使用的新颖的加密方法——下文的部分1；

2a)一种用于在通信信令中使用的新颖的协议回退方法——下文的部分2a；以及

2b)一种用于在通信信令中使用的新颖的数据压缩方法——下文的部分2b。

如下文所解释的，以上方法中的任何一个能够与其他方法中的一者或两者组合。在所描述的实施例的技术中，所有三者被组合以提供通过UDP的安全通信信令——这在不包括安全性的大多数情况下引起降低的通话建立时间。在整个1)和2a)中，有可能将经加密的经压缩的消息封装在单个传输层分组中，特别地在诸如UDP的不可靠的传输层协议的数据报中——这缓解了对于任何应用层重组机制的需求，并且使得UDP在大多数情况下都可用于通话信令——而2b)则确保在UDP在特定情形中不可用的情况下通话信令能够回退至TCP。该组合在尽管优选地使用诸如UDP的不可靠的传输协议的情况下提供了快速、安全、且可靠的通话信令。

1)安全通话信令

在远程通信控制器的控制下在发起设备与响应设备之间建立通信事件。该通信事件建立过程是使用预交换会话密钥数据来确保安全的。

在预通信事件建立阶段：

·在发起设备与通信控制器之间建立安全连接，

·经由该安全连接在发起设备与通信控制器之间交换会话密钥协商消息，以在该发起设备能够访问的电子存储位置中获得会话密钥数据，并且

·一旦已经获得会话密钥，则该安全连接终止。

该会话密钥数据用于由发起设备在生成经加密的消息有效载荷时使用，所述经加密的消息有效载荷能够由通信控制器解密。

在随后的通信事件建立阶段，用于传送至通信控制器的通信事件请求有效载荷由发起设备生成并且使用存储在可访问的电子存储位置中的会话密钥数据进行加密。在预建立阶段中在会话密钥数据已经被获得并且安全连接已经终止之后，响应于在发起设备处接收到通信事件建立指示，通信事件请求从发起设备被发送至通信控制器。该通信事件请求包括经加密的请求有效载荷。通信控制器能够对该经加密的请求有效载荷进行解密，这允许设备之间的通信事件得以基于该经解密的有效载荷在通信控制器的控制之下被建立。

除其他之外，该主题提供了：

(i)在通信事件的初始建立期间确保发起设备与响应设备之间的信令的安全；

(ii)不增加通话建立时间；并且

(iii)使用最少的处理资源和网络带宽。

根据该主题，信令自身不经由安全连接来进行，即通信事件请求不是经由安全连接传送的。该安全连接在接收到通信事件指令之前被终止，并且信令的安全，即(i)在通信事件建立阶段通过基于所获得的会话密钥数据的有效载荷加密来提供。由于安全连接被用于其协商，因此该会话密钥数据被安全地获得。这不增加通话建立时间，即(ii)这是因为该会话密钥数据是在指示通信事件之前例如由发起设备的用户预先协商的；其也不需要过多的处理资源或带宽，即(iii)因为一旦已经获得会话密钥，则该安全连接终止，这意味着在已经获得会话密钥数据之后就不需要处理和带宽来保持安全存续。

术语“通话建立时间”是指从通信事件建立指示被接收(其例如可以由发起设备的用户手动地开始，例如通过该用户在发起设备处选择用于呼叫响应设备或者其用户的选项)的时间到该通信事件建立请求被发送的时间的时间间隔。应当注意，术语“通话建立时间”是为了简明而关于通话以及其他类型的通信事件而使用的，所述其他类型的通信例如屏幕共享会话、共享白板会话、其他实时媒体通信事件等。

在发起设备与通信控制器之间的连接的上下文中，术语“连接”意指发起设备与控制器之间的逻辑连接，所述逻辑连接是：

·通过执行至少一个信道建立握手过程而建立的，其中，至少一个握手消息在发起设备与通信控制器之间被交换；和/或

·通过在发起设备和/或通信控制器的存储器中实现针对该连接的状态机而得以保持。

该连接在该状态机转换为断开连接状态时终止，例如当该连接：

·被拆除时：即，通过执行至少一个终止过程，其中至少一个终止消息在发起设备与通信控制器之间被交换；和/或

·到期时，即在发起设备和/或通信客户端处的非活动计时器到期之后(在该情况下，连接可以在没有任何终止握手过程的情况下终止)。

例如，该连接可以是经由具有多个网络层的网络所建立的TLS(传输层安全性)或SSL(安全套接字层)连接，所述网络层包括传输层上方的应用层和传输层。如已知的，SSL和TLS是指同一协议的较早版本——在本公开通篇中使用“TLS”作为TLS或SSL之一的简写，并且本文涉及到TLS的任何公开都等同地适用于SSL。

TLS连接是传输层处的TCP(传输控制协议)连接，其使用TLS来确保安全。在该情况下，状态机可以分别根据TCP和TLS协议来跟踪TCP和TLS状态改变。例如，在该情况下执行分别的TCP和TLS握手过程，这使得TCP和TLS状态机分别地转换。

作为另一个示例，所述连接可以是经由网络建立的DTLS(数据报TLS)连接。DTLS通过UDP进行操作。尽管UDP是一种不具有状态或握手消息的无连接传输协议(即，传输层协议)，但DTLS协议自身定义了握手过程和状态机两者。在该情况下，尽管发起设备和/或通信控制器处的状态机不直接跟踪UDP，但是其例如在DTLS握手过程进行的同时跟踪DTLS转换。

作为另一个示例，所述连接可以是诸如HTTPS(即，安全HTTP)连接之类的较高等级的连接。应当注意，在本文中HTTP/TCP意指通过TCP的HTTP；HTTPS意指通过TLS连接的HTTP，即HTTPS＝HTTP/TLS。

现有的通话建立过程不提供以上所提及的所有三种效果，即全部(i)、(ii)和(iii)。

会话密钥数据存储在其中的电子存储位置可以是任何合适类型的电子存储中的位置，所述电子存储例如易失性和/或存储器中存储，发起设备可用的长期存储(例如，硬盘)。长期存储可以被用来确保所协商的密钥在重启后留存。例如，移动电话可能失去其电力并接着可以在充电后重启，并且因为通信客户端在电话启动后没有被激活，所以可能没有机会重新协商新的安全令牌。由此，可以期望这样的实现，其希望保持先前会话密钥数据是安全的以使得即使在重启事件中用户也能够非常块地发起通信事件。

应当注意，下文对“存储器”的引用可以是指任何这样的电子存储，包括易失性存储器(包括或处理器存储器)和非易失性存储器(例如闪速存储器和磁存储器，包括硬盘)。

图1示出了现有类型的通信系统的示例，其包括网络106以及连接至网络106的以下项：由用户102所操作的客户端设备104，以及诸如SIP服务器110之类的服务器110。网络102是互连网络(互联网)；即，多个互相连接的个体网络。互联网102具有多个网络层级：链路层112，链路层112上方的网络层114，网络层114上方的传输层116、以及传输层116上方的应用层118。互联网102包括多个路由器108，它们在在网络层114在互联网102的个体网络之间路由数据。尽管在之后的附图中示出了网络层级112-118，但是它们没有在图1中被明确示出。互联网102例如可以是因特网(Internet，大写I)或根据TCP/IP协议组来操作的另一互联网，或者更加一般地是具有例如根据OSI模型的分层架构的任何网络。应当注意，在OSI模型的上下文中，本文对“应用层”的引用表示全部的OSI L5至L7，对“传输层”的引用表示OSI L4，对“网络层”的引用表示OSI L3，而对“链路层”的引用则表示OSI L2-L1。

如在图1A中所示，一些现有通话信令技术针对信令阶段自身使用TLS(传输层安全)。安全TLS连接117是在发起设备和服务器之间建立的，并且所有通话信令消息都是经由安全连接117发送的。即，根据诸如SIP之类的应用层信令协议，发起设备与服务器之间的信令消息是经由安全TLS连接传送的。如也在本领域中已知的，TCP是一种可靠的、面向连接的传输协议(即，在传输层116)，而TLS则在传输层116与应用层118之间进行操作——如在图1A中所示。

建立TLS连接117需要握手消息的两次交换：1)用于在发起设备与服务器之间建立TCP连接而在客户端设备102与服务器110之间的第一TCP握手，以及2)用于协商确保TCP连接的安全的TLS密钥的第二TLS握手——当以该方式确保安全时，“TLS连接”117是TCP连接。

一些这样的通话信令技术在信令阶段自身的开始处建立TLS连接117。例如，安全连接117是响应于客户端设备102的用户102在客户端设备102处选择呼叫选项而建立的。作为结果，通话建立时间是由需要多个网络往返的TLS握手所控制。即，这样的技术显著地增加了通话建立时间。

其他这样的现有信令技术利用预先建立的、到服务器110的后台TLS连接117——即，被预先建立并且即使当其不被需要时也始终保持的持久性安全连接117。尽管这能够防止通话建立时间的增加，但是保持后台连接是新的需要持续的资源——客户端设备102和服务器110两者处的网络带宽和处理资源。即，为了保持后台TLS连接117，客户端设备102需要持续地消耗处理资源和网络带宽，这是由于刷新消息需要反复地被发送至服务器110以保持连接117活跃。这例如会导致更高的电池消耗(特别是对于移动设备而言)以及浪费的带宽，并且此外在接收刷新消息的服务器上创建了显著的额外负载。

另一种通话信令方法使用未加密的UDP用于信令。即，通话信令消息使用UDP——这是一种不可靠的、无连接的传输协议——来发送，但是是以未经加密的形式。这允许快速的通话建立并且不需要保持后台连接是活跃的，然而该信令是不安全的。

如在本领域中已知的，在实践中，TLS需要TCP连接以可靠地进行操作；其不能够通过UDP正确地操作。

与TCP相比，UDP是一种无连接的传输协议，即其是无状态的，这在于两个设备能够在不需要在任一设备处保存任何传输层状态以及在没有任何相关联的传输层握手的情况下使用UDP来进行通信。即，UDP取消了TCP握手。这使得UDP在一些情况下更加快速，其代价在于就UDP数据报的传递无法被保证的意义而言UDP是不可靠的：其没有提供告知已经传输了UDP数据报的设备其是否已经被成功接收的机制(与之相比，TCP则提供了确认和重试的系统)。这意味着，可靠性在被期望的情况下必须在其他地方实现。

已经开发了被称为数据报TLS(DTLS)的一种TLS协议的修改形式，其着眼于允许SIP以及诸如RTP之类的其他协议通过DTLS和UDP进行操作——如在图1B中所示。DTLS以与TLS相同的方式在应用层118和传输层116之间进行操作。如上文所述，DTLS定义了握手和状态机。因此，尽管DTLS通过无连接传输协议(UDP)进行操作——这意味着由此在客户端设备102和服务器110之间不存在传输层连接——但在根据DTLS进行操作时，客户端设备102和服务器110之间的DTLS连接117’通过DTLS握手而被建立，并且由保存在客户端设备102和/或服务器110处的DTLS状态所定义。

SRTP/SDES(使用安全描述的安全RTP)是一种使用安全信令方式(包括安全连接)来交换用于对UDP音频/视频业务进行加密的密钥的已知协议；其具体地被应用于媒体(而非信令)并且不是无状态的：只要会话保持活动，则这两方就存储加密密钥。

在本主题的实施例中，用来预先协商会话密钥数据的安全连接是经由网络108在发起设备与响应设备之间建立的安全传输层连接。即，传输层114处的安全的、端对端连接。即，使用TLS密钥来确保安全的端对端TCP。由此，在预建立阶段的开始处在发起设备与通信控制器之间执行第一TCP握手以建立TCP连接，并且在发起设备与通信控制器之间执行第二TLS握手以协商用来确保该连接安全的TLS密钥。该TLS握手在发起设备与通信控制器之间创建会话密钥数据在其中协商的TLS会话。

两次握手都需要几个网络往返，但是由于这是在通信事件(例如，由发起设备的用户)被指示之前的预建立阶段中执行的，所以其不增加通话建立时间。

应当注意，该TLS密钥独立于并且不同于在建立时经由安全连接所协商的会话密钥数据。即，TLS密钥用来确保往返密钥协商消息的安全，但其不是作为结果获得的会话密钥数据的一部分。TLS密钥排他地用于发起设备与通信控制器之间的TLS会话，即一旦该TLS会话已经被终止，其就不被再次使用。作为对比，在该TLS会话期间所获得的会话密钥数据留存，并且在该TLS会话已经被终止之后(在通信事件建立阶段中)被使用——在一些实施例中在TLS会话已经结束之后至多数日。

一旦已经获得了会话密钥数据，并且在通信事件建立阶段之前，该TLS会话终止——在一些实施例中在数日之前。该会话密钥数据被留存在存储器中，以使得其能够用于在通信事件建立阶段期间对有效载荷进行加密。与依赖于持续地保持后台TLS连接活跃的现有技术相比，这降低了所需要的网络和处理资源的量。

通信事件建立请求不是经由安全传输层连接发送的——相反，安全性是通过使用预先协商的会话密钥数据对其有效载荷进行加密而提供的。

在所描述的实施例中，通信事件建立阶段在可能的情况下是无连接的。即，不仅通信事件建立请求是不经由安全传输层连接发送的，而且其在可能的情况下根本不是经由任何传输层连接设置的，即，其是使用诸如UDP之类的无连接传输协议来传送的。在由于一些原因而无法使用无连接传输协议的情况下，该请求是使用面向连接的传输协议经由非安全传输层连接而被发送的，例如经由TCP连接或非安全HTTP连接。尽管需要握手来建立TCP/HTTP连接，但不需要TLS握手来确保其安全，这仍然表示通话建立时间有所节省。

在以下所描述的实施例的一些中，在预建立阶段所协商的会话密钥数据包括：

·会话密钥(或者能够用来生成它的密钥对)的未经加密的版本——这(这些)是经由安全信道来传送的；和

·会话密钥的经加密的版本，其已经使用通信控制器可用的封装密钥被加密。尽管由于其已经被加密而不是必要的，但是这能够经由安全信道来传送。

在这些实施例中所提供的额外效果是：

(iv)就根本不需要在通信控制器处存储会话密钥的意义而言，允许通信控制器的无状态操作。

该封装密钥仅能够由通信控制器访问——其永不被发送至发起设备。该发起设备不能够对会话密钥的经加密的版本进行解密——其有效地代表通信控制器将其存储。在预交换阶段中经由安全信道所协商的非加密的会话密钥由发起设备用来对消息有效载荷进行加密。会话密钥的经加密的版本连同经加密的有效载荷一起被包括在随后的通信事件建立阶段中发送的每个消息中，并且从发起设备被发送至通信控制器。这允许通信控制器使用封装密钥来对会话密钥进行解密，并且接着使用经解密的会话密钥来对有效载荷自身进行解密。因此，通信控制器所需要留存的仅仅是封装密钥。

在通信会话建立阶段中不需要基于预先协商的会话密钥数据的加密之上的安全措施——经加密的会话密钥能够使用非安全方式(例如，使用UDP)或者经由另外的非安全的TCP(例如，HTTP/TCP连接)从发起设备安全地被传送至通信控制器——这是因为其已经利用封装密钥而被加密。应当注意，“另外的非安全的”连接在该上下文中意指没有使用基于预先协商的会话密钥数据对消息有效载荷的加密之外的任何方式来确保安全的连接(例如，TLS，如HTTPS)。

因为发起设备留存经加密的会话密钥并且在每个消息中发送副本，所以通信控制器并不需要存储其自己的副本。这降低了实现通信控制器所需要的后端存储的量，并且由于其避免了在通信控制器处对任何中央会话密钥库的需求而提供了额外的安全性(通信控制器通常将为多个客户端设备服务，并且在该情况下仅仅现有的会话密钥的副本是在客户端设备间分布的经加密的版本)。

在以下所描述的其他实施例中，在预建立阶段所协商的会话密钥数据包括：

·会话密钥(或者能够用来生成它的密钥对)的未经加密的版本——这(这些)是经由安全信道传送的；和

·会话密钥的标识符(ID)。

在这些实施例中，通信控制器的确与标识符相关联地留存会话密钥自身的版本。该操作在这些实施例中是类似的——然而，在该情况下，在经加密的会话密钥的位置，会话密钥ID与经加密的有效载荷一起被包括在随后的通信事件建立阶段中所发送的每个消息中。再一次，在通信事件建立阶段不需要安全连接——会话密钥ID能够使用非安全方式(例如，使用UDP或者经由另外的非安全的TCP连接)从发起设备被安全地传送至通信控制器，这是因为会话密钥标识符ID自身无法用来对有效载荷进行解密。

为了避免疑问，应当注意，如本文(包括在权利要求中)所使用的术语“未经加密的”仅是指封装密钥，而不排除其他类型的加密。即，“会话密钥的未经加密的版本”表示没有利用封装密钥加密的版本，并且因此包括由其他方式所加密的会话密钥，已知该加密能够由发起设备逆转。

会话密钥标识符可以由通信控制器生成并且被传送至发起设备，或者发起设备可以生成会话密钥标识符并且将其传送至通信控制器，例如，在预建立阶段，该标识符可以是GUID(全局唯一的标识符)。

在以下所描述的实施例中，(在通信事件建立阶段所发送的)通信事件建立请求标识响应设备，由此向通信控制器传送该通信事件请求使得该通信控制器对经加密请求有效载荷进行解密并且向在经解密的有效载荷中所标识的响应设备传送通信事件邀请。

预协商例如可以在发起设备上的通信客户端的安装期间作为安装过程的一部分而被执行；当通信客户端在发起设备的处理器上首次运行时被执行；和/或根据预先确定的会话密钥协商安排而被执行，例如以使得例如每天一次或每几天获得新鲜的会话密钥数据。在一些实施例中，会话密钥数据在通信事件已经终止之后被留存，并且被重复用于一个或多个之后的通信事件。即，同一会话密钥数据可以用于多个通信事件。会话密钥数据用于对在通信事件建立期间从发起设备向通信控制器所传送的通信事件请求的请求有效载荷进行加密。通信控制器能够对经加密的请求有效载荷进行解密，这允许设备之间的通信事件基于经解密的有效载荷而被建立。

通信事件建立请求是在对通信事件建立指示的直接响应中被传送的。对于UDP(没有握手)而言，这意味着在通信事件建立指示之后从发起设备传送至通信控制器的第一个分组是对该请求的至少一部分，并且在一些情况下该请求的整体进行封装的UDP数据报(因为没有例如DTLS握手是必需的)。针对非安全TCP而言，要在发起设备与通信客户端之间交换的第一个分组是TCP握手消息——然而，一旦用于在发起设备与控制器之间建立非安全TCP连接的TCP握手已经完成，则所要发送的下一个分组就是对该请求的至少一部分进行封装的TCP分组(因为没有例如TLS握手是必需的)。

通信事件建立指示可以由响应设备处的用户输入手动地发动，由此通信事件建立消息是在对该用户输入的直接响应中传送的。

在通信事件建立阶段，包括经加密的有效载荷的请求在可能的情况下是使用非可靠传输协议(例如，UDP)来传送的，并且此外，是使用下文所描述的新颖的压缩技术在所述非可靠传输协议的单个数据报中(例如，单个UDP数据报)传送的。

除其他之外，本公开提供了一种基于具有定制的数据加密和认证协议的新颖的信令协议以针对通话发起而实现零RTT(往返时间)。

图2示出了根据本主题的各种实施例的通信系统。所述通信系统包括互联网108；由第一用户202a所操作并且执行通信客户端205a的第一用户设备204a；由第二用户202b所操作并且执行通信客户端205b的第二用户设备204b；以及在该实施例中是通话控制器210的通信控制器。尽管所述通话控制器在该示例中是服务器池(参见下文)，但其可以是服务器。

每个用户设备204a、204b经由相应的物理层连接209a、209b连接至互联网102，这允许客户端204a/204b在互联网102的链路层102(具体地，链路层102中的物理层，其对应于OSI L1)访问网络102——例如Wi-Fi、蜂窝、以太网连接、或者任何其他类型的物理连接。物理连接提供了各种等级的安全性(例如，密码保护vs开放Wi-Fi)——假设该安全等级是不足够的。即，本技术不依赖于任何形式的链路层安全。

网络108是分组路由网络。分组路由通过该物理连接可获得，并且由路由器108在网络层104提供。例如，使用IP(互联网协议)。实际上，IP的使用十分广泛，从而网络层304经常被称之为IP层。

为了在用户设备204a、204b之间建立通话，在通话建立阶段(“通话信令阶段”)在以下设备之间发送和接收各种消息：客户端205a与通话控制器210，以及通话控制器210与客户端205b。在所描述的实施例中，在通话信令阶段不在用户设备205a、205b之间直接交换消息。该通话信令阶段的目的是要协商媒体参数，允许音频和/或视频数据在随后的媒体流阶段在客户端205a、205b之间发送和接收——例如使用VoIP(IP语音)。在通话信令阶段，没有音频或视频数据在用户设备204a、204b之间被交换。

在第一用户202a使用其用户设备204a向第二用户202b进行呼叫的上下文中对实施例进行描述。在该上下文中，第一用户设备204a被称为发起设备或主叫设备，而第二用户设备204b被称为响应设备或被叫设备；第一用户202a是主叫方，而第二用户202b是被叫方。

如以上所指出的，在通话信令阶段之前，主叫客户端202a在预通话建立阶段获得会话密钥数据，其用于对在通话信令阶段发送至通话控制器110的消息进行加密。预通话建立阶段例如可以在客户端202a首次在主叫设备202a上安装时被执行，并且随后根据密钥轮转安排(会话密钥协商安排)而被执行，例如每天一次或者每几天一次。

图2中仅示出了通信系统的两个用户202a、202b，但是将容易理解的是，可以存在该通信系统的更多的用户，他们中的每个操作其自己的(多个)设备和(多个)客户端以使其能够经由通信网络2来与其他用户进行通信。

图2a示出了通话控制器210的一种示例性配置，其在该示例中是服务器池，其等同地被称为服务器集群。即，通话控制器210包括每个都连接至负载平衡器522的多个服务器524a、524b、524c。作为示例示出了三个服务器，但是通话控制器可以包括任何数量的服务器。服务器524a、524b、524c可以是物理服务器(即，不同的服务器设备)或者是在相同或不同的物理设备上运行的虚拟服务器。例如，服务器中的每个可以是诸如WindowsAzure之类的云平台上的服务器实例。服务器524a、524b、524c能够访问共享的电子存储526。共享的电子存储526可以是任何形式的分布式存储，它能够由集群/池中的所有服务器524a、524b、524c访问。针对通话控制器210的请求由负载平衡器602接收，并且能够针对服务器524a、524b、524c中的任何一个。服务器中的任何一个能够处理任何请求，这是因为它们全部共享同一高速缓存528。

图3示出了用户设备202(例如，202a、202b)的框图。用户设备202是能够采用多种形式的计算设备，所述形式例如台式或膝上型计算设备、移动电话(例如，智能电话)、平板计算设备、可穿戴计算设备(头戴式耳机、智能手表等)、电视(例如，智能TV)或其他墙壁安装设备(例如，视频会议设备)、机顶盒、游戏控制器等。用户设备202包括由一个或多个处理单元(例如，CPU、GPU、定制的处理单元等)形成的处理器304，以及连接至处理器304的以下组件：在一个或多个存储器单元(例如，RAM单元、直接存取存储器单元等)上形成的存储器308；以及(多个)网络接口306。用户设备202经由其网络接口306而连接至网络106，以使得处理器304能够往来于网络106而发送和接收数据。网络接口306可以是有线接口(例如，以太网、火线、雷电、USB等)或无线接口(例如，Wi-Fi、蓝牙、NFC等)。这些组件中的任何一个可以被集成在用户设备6中，或者是经由合适的外部接口而连接至用户设备6的外部组件。

存储器308保存通信客户端205(例如，205a、205b)以用于在处理器304上执行。客户端205可以是例如独立的通信客户端应用，在其他应用所提供的执行环境中在处理器上运行的另一个应用(例如，Web浏览器等)的插件。客户端205具有用户界面(UI)，其用于往来于设备204的用户而接收信息和输出信息。所述用户界面例如可以包括经由显示器302输出信息的图形用户界面(GUI)和/或使得用户能够以“自然的”方式与设备进行交互的自然用户界面(NUI)，而没有由诸如鼠标、键盘、遥控器等之类的某些输入设备所施加的人为约束。NUI方法的示例包括利用触摸感应显示器、语音和话音识别、意图和目标理解、使用深度相机(例如，立体或飞行时间相机系统、红外相机系统、RGB相机系统、以及这些的组合)的运动手势检测、使用加速计/陀螺仪的运动手势检测、面部识别、3D显示器、头部、眼睛和视线跟踪、沉浸式增强现实和虚拟显示系统等的那些方法。

图4给出了对某些过程何时以及在哪里由主叫客户端205a实现的高等级概览。这些中的一些是已知协议，而其他则是由本公开所提供的新颖过程。图4中相同的附图标记表示与在图1A和1B中的那些特征相对应的特征。

框402在主叫设备202a的应用层308处被示出，其表示在预通话建立阶段由主叫客户端205a所执行的应用层密钥交换。如所示出的，应用层密钥交换402是通过TLS和TCP执行的。

在应用层密钥交换402中，IP用于在传输层306建立逻辑的网络层连接407(例如，TCP连接)以用于预通话建立阶段；该连接是客户端205a与通话控制器210之间的端对端连接。端对端连接407需要时间和分组往返来建立，并且在实践中在大多数网络中需要定期维护。

通过网络层连接407，在该示例中使用TLS来增加安全性，尽管也可以替代地使用其他类型的安全协议。如所提及的，这样的安全协议在传输层306与应用层308之间进行操作，如在图4中所示。这些在连接建立之后增加了更多的网络往返，但是即使在底层物理层网络是不安全的情况下也提供了交换中的机密性和数据完整性。

在以该方式确保安全时，传输层连接被称为安全连接(例如，TLS连接)。确保连接连接的安全涉及密钥交换阶段以及可选地作为连接建立的一部分的认证阶段，这产生了用来确保通过该连接发送的数据的安全的连接加密密钥(例如，TLS密钥)。

如上文所提及的，一些现有通话信令技术依赖于使用长时间保持活动的TLS的长期存活的安全连接(与该主题相比)，以使得能够通过该连接进行通话信令。该连接在后台被维持，这需要分组每隔几分钟或几秒钟被发送。底层物理连接在任何时候发生改变(例如，在电话从Wi-Fi切换至蜂窝时)，TLS连接都被重新建立。

在本文中所描述的本主题的实施例也通过执行例如标准TLS密钥交换、认证验证等来建立安全连接407，从而获得连接加密密钥，例如TLS密钥。

安全连接407在预通话建立阶段被建立，并且应用等级的密钥交换402是通过连接407执行的(生成另一个密钥(“会话密钥”)以及包含会话密钥的经加密的版本或该会话密钥的ID的权证(ticket)(参见下文))，而不是将该连接用于信令本身，这些被存储在主叫设备104a的存储器308中，由此客户端205a能够在其要发起通话信令时对其进行访问。即，连接407不在会话密钥已经被获得之后被维持或者保持其活跃——这意味着没有后台业务且没有电池消耗。

为了避免疑问，再次应当注意，“连接加密密钥”(例如，TLS)独立于且不同于在通话信令阶段所使用的“会话密钥”。一旦利用连接加密密钥被确保安全，则连接407就用来预协商会话密钥；但是用来在通话信令阶段中对消息进行加密的是所获得的会话密钥，截至该时间，连接407已经被拆除以节省资源。一旦连接407已经被拆除，则连接加密密钥就变得多于并且可以被完全丢弃。

图4中的框404也在呼叫设备202a的应用层308处被示出，并且表示基于通过框402的应用层密钥交换所获得的预协商的会话密钥、在通话信令阶段随后由客户端205所执行的新颖的通话信令过程。框404的过程包括响应于结合诸如UDP之类的无连接传输协议使用预协商的密钥和权证的通话建立指示(例如，通过主叫方202a经由客户端205a的UI选择用于呼叫被叫方202b的选项所发动的)，在客户端205a与通话控制器210之间发送和接收经加密的消息。

UDP直接建立在IP顶端，并且因此能够在物理连接可用时立即工作；不需要为其建立传输层连接。例如，在UDP不可用的情况下，能够替代UDP而使用不安全的网络层连接(TCP或者诸如HTTP之类的更高等级的协议)。使用预协商的会话密钥以相同方式来对消息进行加密——这提供了一种形式的不安全连接，其在建立标准不安全传输层连接(例如，没有TLS的TCP，例如HTTP而不是HTTPS)所需要的之上不需要额外的往返。UDP在用户的网络环境由于多种原因之一而阻塞UDP通信时可能不可用，或者由于非常差的网络条件下的极端分组丢失而实际上不可用。

在发起设备202a的应用层308处所示出的框406表示媒体数据交换过程，其可以用于在信令过程已经完成之后基于通话信令期间所协商的媒体参数而在主叫方客户端205a与被叫方客户端205b之间发送和接收音频和/或视频数据。例如，基于使用UDP的VoIP。

图5A示出了根据第一实施例的针对预通话建立阶段的信令图，其中框402的应用层密钥交换在后台中定期地执行以建立共享的“会话密钥”，这是将在通话建立期间被使用的共享密钥。最新近的会话密钥直到该过程下一次被执行之前都保持有效。

在步骤S502处，在客户端205a与通话控制器210之间建立TLS连接407。

在步骤S504处，客户端205a从通话控制器210请求会话权证。作为响应，通话控制器210生成会话密钥，这是256位加密的强随机序列(“SessionKey”)。

在步骤S506处，通话控制器210从在共享存储器526中实现的密钥存储500请求当前封装密钥(“WrappingKey”)以及当前封装密钥的封装密钥标识符(“WrappingKeyID”)。

在步骤S510处，通话控制器210在具有零初始化向量(IV)的CBC模式中使用AES-256利用WrappingKey对SessionKey进行加密(尽管在其他实施方式中可以使用不同算法)，并且创建包括WrappingKeyID和经加密的SessionKey的权证(“Ticket”)。该权证还可以包括表示信令协议的当前版本的版本标识符(“TicketVersion”)以提供对新版本的支持。

在步骤S512处，通话控制器210向客户端发送SessionKey、当前服务器时间戳、以及Ticket。即，通话控制器210发送(权证中的)会话密钥的经加密的版本以及会话密钥的未经加密的版本两者以由客户端205a使用。至少会话密钥的未经加密的版本是经由安全TLS连接407传送的，并且在该实施例中该权证和服务器时间戳也是如此。一旦在客户端205a处接收到这些，则连接407被拆除。服务器时间戳表示如在通话控制器210处所测量的当前时间。

在步骤S514处，客户端205a计算服务器时间与当前客户端时间之间的时间差。客户端205a将SessionKey、Ticket、和所计算的时间差存储在存储器308中，其在那里保留以供在之后的通话信令中需要时使用。

SessionKey仅用来保护一个客户端(即205a)与通话控制器210的通信。通话控制器210是集中管理的实体，并且能够被信任以在没有任何安全风险的情况下选择SessionKey。Ticket对于客户端205a是完全不透明的，因为客户端205a绝不能够访问封装密钥。

Ticket的有效期由WrappingKey轮转安排确定并且例如处于数日的量级。该有效期在通信场景中是由应用的安全性约束所确定的。例如，在军用实施例中，其可能处于数小时而非数日的量级。

在该有效期结束时，WrapperKey例如在几天之后(或者根据情形而更少)被完全销毁，服务器将无权访问拆包Ticket的内容所必需的密钥素材，因此使得Ticket无法使用。一种确保封装密钥能够被永久删除的方式是将其仅存储在易失性存储器中(从易失性存储器删除的永久性是被保证的，这不同于容易受到数据取回方法的影响从而恢复被删除的数据的非易失性存储器)。这为通话信令提供了正向保密性(即，即使被恶意记录，历史的通话信令消息也绝不会在封装密钥已经被删除的情况下被解锁)。

WrapperKey在有效期结束时的完全销毁能够通过始终仅将其存储在易失性存储器中而被确保。因此，在一些实现中，密钥存储500的至少一部分在易失性存储器中实现。即，共享电子存储526的至少一部分可以是能够在其中保存封装密钥的存储器内存储(即，易失性存储器)。

如果其为每个消息选择了随机IV，则客户端能够将相同的Ticket重复用于多个通话(见下文)。如在本领域中已知的，有时被称为起始变量的初始化向量(IV)是对提供唯一性的密码算法的输入。IV的基本属性在于其对于给定的密钥是唯一的。即，没有IV针对相同的密钥被使用两次。IV常常被随机化(即，随机或为随机)，但取决于密码算法其不是总是必要的。

可替代地，客户端205a可以在每个通话/会话之后使得Ticket无效(销毁)，并且在指示下一个通话之前所执行的另一个预建立阶段中，在准备下一个通话时获得新的Ticket。该机制使得攻击者更加难以通过观察分组而获得任何有价值的内容。

即使客户端205a的执行被终止，并且即使发起设备204a断电，该Ticket也能够留存在存储器308中。可替代地，客户端205a每次被执行时，即客户端205a的新实例每次在处理器304上被创建时，图5A的过程都可以被执行。

图5B示出了针对随后的通话信令过程的信令图。

为了与通话控制器210进行通信，客户端执行以下步骤。

在步骤S516处，客户端205a从存储器308加载Ticket、SessionKey和时间差。

在步骤S518处，客户端205a生成请求内容，其包括：

·随机请求标识符(“RequestID”)

·表示在主叫设备504处所测量的本地当前时间的当前时间戳(“TimeStamp”)，其针对客户端与服务器时间之间的差进行调节；

·针对用户202a的用户认证令牌；以及

·请求消息有效载荷(“RequestPayload”)。

在步骤S520处，客户端205a使用密钥推导函数(KDF)从SessionKey得出加密密钥(“EncryptionKey”)。即，从会话密钥的未经加密的版本。为此，可以使用任何合适的密钥推导函数。客户端205a生成密码强随机的128位IV，并且利用设置为IV的初始化向量以及设置为EncryptionKey的密钥在CBC模式中使用AES来对请求内容进行加密。这得出经加密的密文串(“Encrypted”)。应当注意，如同步骤S510的加密，在遵循在该文档中所描述的流程的同时，其他实现可以在这里使用不同的密码算法。

客户端205a还使用KDF从会话密钥得出单独的认证密钥(“AuthenticationKey”)，连接[Ticket,IV,Encrypted]，并且利用被设置为AuthenticationKey的密钥来将HMAC(“HMAC”)计算为经连接的[Ticket,IV,Encrypted]字符串的HMAC-SHA256。如本领域中已知的，HMAC意指带有密钥的散列消息认证码，并且提供了消息的完整性保护，即它们可以用来确定消息何时在不将其解密的情况下被篡改或者以其他方式被改变。

在步骤S522处，客户端204a向服务器发送请求消息，其包括：

·Ticket，

·IV，

·Encrypted，和

·HMAC。

即，全部四个要素被单独地包括在请求消息中。

在步骤S524处，通话控制器210从Ticket提取WrapperKeyID，并且

从在共享高速缓存中实现的密钥存储500中获得与WrapperKeyID相对应的WrapperKey(S526)。如果没有这样的密钥，则不执行进一步的处理且不发送错误消息。例如如果有效期已经结束并且相关的封装密钥由此被永久删除，则可能不存在这样的封装密钥。

在步骤S528处，通话控制器通过利用在步骤S526处获得的WrapperKey对Ticket中的加密会话进行解密而获得SessionKey。

通话控制器210接着从经解密的SessionKey得出EncryptionKey和AuthenticationKey，并且通过使用从SessionKey所得出的其自己的AuthenticationKey计算预期的HMAC来验证HMAC值。如果预期的HMAC不匹配于从客户端205a所接收的请求消息的HMAC，则不执行进一步的处理且不发送错误消息。

如果预期的HMAC匹配于请求HMAC，则在步骤S530处，通话控制器210进行以利用被设置为IV的初始化向量以及被设置为EncryptionKey的密钥在CBC模式中使用AES来解密Encrypted。

通话控制器210接着读取所描述的TimeStamp，并且在TimeStamp与在服务器处所测量的当前时间相差超过第一时间间隔(T1)的情况下丢弃请求消息。如所提及的，TimeStamp是由客户端205a将客户端205a与通话控制器210之间的时间差考虑在内而生成的。

通话控制器210包括响应高速缓存消息处理程序(handler)211，其在共享存储器526中保存覆盖第二时段(T2)——即最后的T2秒——的最近处理的请求的共享高速缓存，并且在其RequestID已经处于该存储器中的情况下丢弃该请求，其中T2>＝T1。当请求的多个副本被发送时(为了可靠性——见下文)，RequestID可以用于确保仅有一个被实施动作而重复的则被丢弃。

在步骤S534处，已知该请求在T1内被接收并且还没有具有RequestID的请求已经处于共享存储器中，则通话控制器210处理经解密的请求内容，包括RequestPayload，并且(已知某些时间约束被满足(参见下文))生成包括来自该请求内容的RequestID、Timestamp、以及响应消息有效载荷(“ResponsePayload”)的响应消息(“Response”)。将RequestID包括在响应中允许客户端205a在可能为了可靠性而被发送的响应的多个副本间进行区分(见下文)。

通话控制器210还生成密码强随机128位的IV并且利用被设置为IV2的初始化向量以及被设置为EncryptionKey的密钥在CBC模式中使用AES来对Response进行加密。这得出另一个经加密的密文串(“Encrypted2”)。通话控制器210将另一个HMAC(“HMAC2”)计算为[IV2,Encrypted2]的HMAC-SHA256。通话控制器210接着将HMAC2和Encrypted2发送至客户端(S536)。

客户端205a以同一方式认证并解密数据。

所有请求都包含对请求的源进行认证的用户认证令牌。

基于以下来重演(replay)保护。

通话控制器210利用共享的暂时存储(例如，Redis)来保存必要数量的新近WrappingKey-s。所有通话控制器210的每个服务器被供应以非对称的秘钥对(RSA，2048位)。暂时存储中的WrappingKey是利用服务器的公钥(RSA-OAEP补充)来加密的。对暂时存储的网络访问仅经由TSL进行，并且认证是基于客户端TLS证书或Azure Active Directory的(作为示例)。额外地，存在用于自动和定期安排的密钥轮转的专用机制。执行密钥轮转的服务使用服务器的公钥来对新生成的密码安全随机256位密钥进行加密，并且将结果放入到暂时存储中。还可以可选地向服务器通知关于密钥轮转，或者服务器能够通过定期地轮询暂时存储来自行对此进行通知。密钥例如可以每一至四个小时进行轮转，并且保留覆盖最后7天的那些密钥。

注意：不尝试明确地认证Ticket值。经解密的SessionKey被立即使用——以所得出的AuthenticationKey的形式——以验证请求密文上的HMAC。如果Ticket已经被修改，则HMAC验证将会失败并且密钥将不会用来解密消息正文。

如果消息HMAC校验在未来被修改，则必须采取特殊措施来确保经解密的Payload在其使用之前得到认证。

在第一实施例的变化形式中，权证获取被提前执行并且在客户端与服务器之间的合适的TLS连接上进行。该过程包括以下步骤：

1.客户端205a生成256位的密码强随机序列(ClientSecret)并且将其发送至通话控制器(通过TLS连接407)。

2.通话控制器210生成256位的密码强随机序列(ServerSecret)并且将其与ClientSecret进行XOR(异或)以获得SessionKey。

3.通话控制器210获得当前的WrappingKey及其WrappingKeyID。

4.通话控制器210使用WrappingKey来封装(即，加密)SessionKey并且创建包含KeyID和经封装的SessionKey的Ticket。

5.通话控制器210向客户端205a发送ServerSecret、当前服务器时间戳、和Ticket(通过TLS连接407)。

6.客户端205a通过对ClientSecret和ServerSecret进行XOR来计算SessionKey，计算服务器时间与当前客户端时间之间的时间差；其接着存储SessionKey、Ticket和所计算的时间差。

即，在第二实施例中，SessionKey是通过组合来自双方的熵来计算的以防止潜在问题。此后，随后的通话信令阶段以相同方式进行。

以上步骤是针对在客户端205a与通话控制器210之间交换的每个请求和响应所执行的。

如图5C中所示，针对从客户端205a发送至通话控制器210的第一请求，RequestPayload标识响应设备204b。例如，其可以包括第二用户202b的用户标识符，第二设备204b的设备标识符或网络地址，或者允许通话控制器210识别响应设备204b的任何其他标识符。第一请求直接响应于由发起设备205a例如从主叫方202a所接收的通话建立指示S520而被传送。根据上文所给出的步骤S524-S534，通话控制器——除了在步骤S536向主叫客户端205传送响应之外——还向在第一请求的有效载荷中所标识的响应设备204b上的客户端205b传送通话邀请(在步骤S538)。这使得响应客户端205b进入响铃状态(S540)以向被叫方202b通知到来的通话。

第一实施例中的框402的密钥交换机制的特征在于其在通话控制器210上是无状态的：通话控制器210不需要存储会话密钥或者任何每用户数据；其所需要的仅是独立于用户的封装密钥。这允许密钥分布服务器容易地扩充至大量用户。

在第二实施例中，通话控制器210不存储其自己的会话密钥版本。不同于向客户端发送经加密的会话密钥，客户端502a或通话控制器210生成会话密钥的会话密钥ID，例如GUID(全局唯一标识符)，并且该会话密钥ID替代Ticket中的会话密钥的经加密的版本而被使用。

存储在服务器处的会话密钥的版本可以是经加密的版本(利用封装密钥所加密)，在该情况下，能够通过仅在易失性存储器中存储封装密钥来提供正向保密性，以使得一旦该封装密钥从易失性存储器被删除，则会话密钥的经加密的版本无论其存储在那里都永久地变为不可用。可替代地，存储在服务器的版本可以是未经加密的版本，在该情况下，能够通过仅在易失性存储器中存储会话密钥的未经加密的版本来提供正向保密性，以使得其能够被永久删除。

如所提及的，以上所描述的技术提供了：

·认证——利用用户令牌在用户层面以及通过HMAC所提供的完整性包含而在消息层面。

·机密性——由于基于会话密钥的加密，不可能通过观察分组来识别被叫方或读取会话参数，或者提取它们所携带的媒体加密密钥。此外，保留了正向保密性。

UDP在该上下文中是优选的，原因在于其由于没有握手而提供了最快速的信令。然而，如所提及的，其是不可靠的——以下所给出的技术使用数据压缩和协议回退的组合对此进行补偿。

2)数据压缩和协议回退

除了以上加密之外，数据压缩和协议回退的组合被用来确保可靠性——甚至是在使用诸如UDP的不可靠传输协议时。即，为了确保信令能够在存在适量的分组丢失的情况下或者在DUP连通性完全不可用的情况下工作。

UDP分片(fragmentation)不总是可用的(例如，它在Windows Azure中不可用)。当UDP分片不可用时，将需要开发者实现其自己的应用等级消息分片和重组机制。这是麻烦且资源密集的，然而本技术通过压缩每个消息以使其只要可能都适配在单个UDP数据报中而缓解了对此的需求，以使得不需要应用层分片和重组机制。路径MTU(最大传送单元)定义了能够被封装在单个UDP数据报中的消息的最大大小。

在以下情况中：

·UDP不可用(例如，由于防火墙中的UDP拦截)，或者

·任何消息都无法被压缩以适配单个UDP分组

系统回退至针对信令的非优选协议，例如：

·TCP，例如HTTP/TCP。

为了应对在使用UDP时的分组丢失，每个请求和响应都被多次发送，例如可以传送每个请求和每个响应的2-3个副本。所描述的RequestID用来复制请求并且避免多次处理它们；响应始终都与共享存储526中的未解决的请求的表格相匹配从而重复响应将自动被忽略。

如果请求在诸如UDP的优选协议上超时，则客户端205a将自动地使用非优选协议来重新尝试发送相同的请求，所述非优选协议例如：

·TCP，例如使用预协商会话密钥数据所确保安全的HTTP——以用于建立TCP连接的TCP握手为代价。

在使用以上所描述的加密技术时，TCP能够在没有TLS的情况下被使用，例如通过没有额外加密的HTTP，这是因为消息有效载荷已经使用预协商会话密钥进行了加密。然而，在其他实施方式中，以TCP握手和额外的TLS握手为代价而回退至TLS(例如，HTTPS)可能是合适的。

可替换的实现可以在每次回退时与UDP信令并行地建立例如TLS连接。在该情况下，握手的代价仅在TLS信道在协议改变的时间内并未准备就绪的情况下才会引发。在正常情况下，这通常将是浪费(且具有带宽竞争性)的，并且在网络条件受限的情况下可能使得网络突然无法被设备所使用。然而，在一些有限情况下可能是适宜的。

如果响应在先前丢失，则无论用来发送它的传输层协议如何，通话控制器的响应高速缓存消息处理程序211都将允许客户端在重新尝试时取回该响应。消息处理程序211被配置为使得在发生从UDP到HTTP(S)的回退时，在原始UDP消息实际上没有到达服务器的事件中，则该服务器将正确地理解要重新尝试的HTTP消息，并且利用其将通过UDP发送的相同响应来进行响应，在需要的情况下适当地将其转换为有效的HTTP有效载荷。换句话说，消息处理程序211被配置为(基于请求ID)将消息标识为彼此的副本，而无论它们是在何种传输协议上发送的。通话控制器210将尝试使用优选协议(例如，UDP)来对请求进行响应，除非其由于响应的大小(见下文)而无法这样做或者直到使用非优选协议接收到该请求的副本为止——响应于任一事件，通话控制器210都将回退至非优选协议(例如，HTTP(S))。

2a)协议回退

在所描述的实施例中，通过在任何可行的时候将UDP用于初始通信信令阶段来使得通话建立时间平均地降低，其中，利用鲁棒的回退机制来在通过UDP的通话信令不可用的任何时候都确保最小中断。

UDP是无连接的并且因此固有地比面向连接的TCP更快，这是因为UDP弃用了建立TCP连接所需的耗时的握手。然而，就所发送的UDP数据报的安全接收无法被保证的意义而言，UDP是不可靠的。这是因为UDP同样弃用了使得TCP成为可靠协议的TCP内置的确认和重试机制。

在当前使用UDP的许多上下文中，这种不可靠性是可接受的。例如，在通话的随后的媒体流阶段通过UDP向接收设备发送音频或视频数据的情况下，已知这在接收设备处的音频/视频输出中产生的失真的量对于用户而言是可容忍的，则一些音频和视频数据在传送中无可改变地丢失是可接受的。

然而，先前的通话信令阶段在根本上不同于媒体流阶段——在该上下文中，每个通话信令消息的至少一个副本使得对于预期的实体是重要的，所述预期实体是发起设备、响应设备或通话控制器。如果任何消息一起丢失，则通话信令阶段都容易显著被延迟或者甚至一同失败，除非消息丢失被适当地处理。出于该原因，经常优选TCP用于通话信令，并且TCP是SIP的最常使用的传输协议。

本公开认识到，在没有适当管理的情况下，UDP的内在快速性将无法转换成全真实世界场景中的减少的通话建立时间。即，本公开认识到，无法以普遍有所减少的通话建立时间的随便预期而简单地通过UDP来执行通话信令：尽管在许多情况下，通过UDP执行通话信令是可行的并且将由于其内在快速性而产生明显有所减少的通话建立时间，但是存在许多通过UDP尝试通话信令的不可行的情况，即因为其会显著地增加通话建立时间或者导致通话信令一起失败——这导致不佳的用户体验。

由此，本公开提供了各种机制，一方面确保UDP在任何可行的时候都用于通话信令(产生更快的通话建立)，并且在另一方面快速地确定UDP何时不可行从而防止在该事件中通话建立时间的显著增加或者通话信令失败。

在所描述的实施例中，最初总是使用UDP来尝试通话信令——然而，几个层级的鲁棒性被内置到系统中以平衡UDP信令在有所减少的通话建立时间方面的好处与其潜在缺陷：

·第一层级的鲁棒性可选地可以由消息复制来提供，由此消息的多个副本使用UDP在非常快的序列(每隔～100ms的量级)反复地重新发送。这使得通话信令对于轻度至中度的UDP数据报丢失是鲁棒的。在许多情况下，该第一层级的鲁棒性足以确保通过UDP能够成功地完成通话信令，并且因此显著地减少通话建立时间。

·第二层级的鲁棒性是由基于临时响应(确认)的快速协议回退提供的，所述临时响应在所描述实施例中在应用层被发送。这些允许被叫方设备关于UDP是否可用于给定通话信令进行非常快速的临时校验。临时响应是由通话控制器响应于来自主叫方设备的请求而立即发送至主叫方设备，在其已经完成生成最终响应之前，以使得在一般条件下，发起设备能够预期在例如大约1-2秒的短时间间隔内发送对任何请求的临时响应。如果没有在该短时间间隔内接收到临时响应(例如，由于重度分组丢失或UDP阻塞)，则主叫方设备能够立即回退至可靠的TCP并且通过TCP重新发送其请求。在该情况下，通话建立时间有所增加——但是仅是少量增加，即增加大约1-2秒。

·如果在该短时间间隔内接收到临时响应，则发起设备临时断定UDP是可行的，并且继续UDP。实际上作为一种故障-安全机制的第三层级的鲁棒性确保了发起设备在假设其发现UDP不可行的事件中仍然能够以时间上合理的方式(10-15秒的量级)回退至TCP。

尽管在本文中使用TCP和UDP作为优选和非优选的网络协议的示例，但是本公开不在该方面进行限制，并且本教导的底层原理更一般地适用于其他网络协议。就这一点而言，术语“优选的网络协议”一般是指最初根据其尝试基于会话的通信但是其在某些情况下容易失效的任何网络层级的任何网络协议。术语“非优选的协议”一般是指能够替代优选的协议并且在那些情况的至少一些中更可能成功的任何网络协议。

优选的协议例如可以是任何无连接和/或不可靠的传输协议，并且非优选的协议例如可以是任何其他面向连接和/或可靠的传输协议，但是本教导不限于此。

图6示出了将请求从客户端205a发送至通话控制器210的方法的流程。

在步骤S602处，客户端205a根据图5B的步骤S516-S520生成包括经加密的有效载荷的请求以用于发送至通话控制器，并且如图5B中的步骤S522将其传送至通话控制器210。

在步骤S604处，在存储器308中初始化：

·重试传送计时器，以及

·协议回退时间，其最初被设置为比重试传送计时器更长的起始时间间隔。

该计时器倒数，并且在其相应的时间间隔结束时超时。以该方式，客户端205a根据对UDP数据报中的请求的感应来监视自其发送起所经过的时间。

例如，重试传送计时器可以被设置为大约100ms，并且协议回退计时器最初被设置为例如大约1-2秒，但是在一些情况下小于1秒可能是合适的。

如果且当重试计时器超时时(S606)，客户端205a使用优选的协议来重新传送请求(S608)。

如果且当协议回退时间超时时(S612)，客户端根据非优选的协议冲来重新传送请求，所述非优选的协议例如TCP，例如HTTP/TCP(S616)。

为了加速回退至非优选的协议(例如TCP，例如HTTP)，除了请求和响应消息之外还使用两个特殊消息：

·临时确认(临时响应)——由通话控制器210在从客户端205a接收到包含请求的UDP数据报时立刻发送。在处理已经完成之前并且无论请求是被接受还是被拒绝，这都并行于开始请求本身而被发送。

·快速回退消息——由通话控制器210在无法将其对客户端的请求的响应适配到单个UDP分组中的情况下被发送。

为了可靠性，这两个特殊消息就如同请求和响应消息一样利用小的间隔(例如，～100ms)被多次传送。

临时确认分组向客户端205指示请求被接收，并且提供两种功能。如果且当客户端的请求的临时确认在客户端205a被接收(S608)，该方法进行至步骤S610，其中客户端205a停止请求重新传送计时器，这确保了不使用优选的协议(例如，UDP)来尝试更多重试——因为客户端现在知道通话控制器已经接收，并且因此知道其能够向通话控制器210发送UDP消息，所以不需要更多的使用UDP的重复的请求分组。

同时，在步骤S611处，客户端205a延长协议回退计时器。如果没有在短时间内(例如，1-2秒或者<1秒)接收到临时确认，则客户端将在UDP连接无法工作的假设下回退至非优选的协议(例如TCP，例如HTTP/TCP)。该回退计时比针对某些请求的最大服务器侧处理时间更短，因此接收到临时确认提高了客户端对于UDP连通性的信心并且将计时器延长至HTTPS超时的典型值(例如，10-15秒)。这意味着客户端现在将在S612处在回退至非优选的协议之前等待更久。

已经接收到临时确认的事实意味着客户端能够确信其UDP请求中的至少一个已经在通话控制器210处被接收。然而，这不保证将从通话控制器向客户端作出完整的(即非临时的)响应，因为完整响应也由通话控制器使用不可靠的UDP来发送。例如，出于某些原因可能在从通话控制器到客户端的方向经历更为严重的分组丢失，或者可能在客户端与通话控制器之间的某处存在某一形式的单向UDP阻塞。延长的计时器因此提供了一种故障-安全——如果延长的计时器超时，则客户端将重新例如经由HTTP(S)发送请求的副本，如上文所提及的，这进而将引起通话控制器210回退至HTTP(S)并且经由HTTP(S)重新发送其最终响应，这使得其到达由于TCP的内置重试机制而在客户端处得到保证。

如果在任何时间从通话控制器210接收到快速回退消息(S614)，则客户端205a在接收到该快速回退请求消息之后立即停止所有计时器并且使用非优选的协议(例如TCP，例如HTTP/TCP)来重试该请求。这允许通话控制器210取回已经高速缓存在通话控制器210的响应高速缓存消息处理程序中的响应。

如果客户端205a在任何时间接收到对客户端的请求的完整响应(S618)，则客户端205a停止所有计时器，因为其知道响应现在已经被通话控制器210接收和处理。

2b)数据压缩

为了避免实现复杂的应用层重组机制以及潜在地降低可靠性，每个请求和响应都在可能的情况下被封装在单个UDP分组中，该单个UDP分组小于最常观察到的路径MTU值(例如，1200-1400字节)。某些请求相对较大，使用专门的压缩方案来压缩它们——例如具有定制的、预先定义的词典(“压缩词典”)的Deflate(GZIP)。即，使用具有定制的预先定义的压缩词典的已知压缩功能。

图8A和8B示出了由框802所表示的示例性压缩功能的操作。图8A示出了压缩功能802在没有预定义词典的情况下可以如何操作。在该情况下，压缩功能在生成消息814的压缩版本时识别被输入到压缩功能802中的输入消息804的相匹配的字符串。字符串(在该简化示例中为“xyz”和“abc”)随后每次在消息中重复时，所重复的串都用对该串的首次出现的引用来替代——在该示例中，“[#1]”和“[#2]”表示对“xyz”和“abc”在压缩消息814中的首次出现的引用。如将会容易意识到的，以该方式用引用来替代串能够通过避免重复编码来降低消息的大小。

图8B展示了压缩功能能够如何基于预先定义的压缩词典216进行操作以实现更大的大小降低。在该示例中，词典216被示为包括例如字符串“xyz”和“abc”，这允许这些串在压缩消息214’的每次出现(包括首次出现)时都用对词典802中的对应的串的引用所替代，所述对应的串分别被表示为“[#1’]”和“[#2’]”。能够访问匹配词典的另一设备能够使用该匹配词典来将消息214’解压缩。压缩功能802是由客户端和通话控制器210实现的，它们还实现对应的解压缩功能。因此，经压缩的消息能够在客户端与通话控制器之间在两个方向上进行被传送。

以该方式操作的压缩功能在本领域有时被称为词典编码器压缩功能，或者等同地被称为替代编码器压缩功能。

返回图2，图2还示出了连接至网络106的词典服务器212和词典数据存储214。词典数据存储在数据存储214的可寻址存储器位置中保存定制的压缩词典216，由此该词典能够由用户设备204a访问。

所述词典包含一个或多个样本请求(例如，一个或多个请求消息模板)，并且帮助Deflate算法高效地压缩JSON和SDP，因为其能够引用来自该词典的名称和子串。该方法已经展示了显著优于常规的Gzip/deflate的压缩，并且已经表明该方法是可行的。

无论何时客户端205a所生成的请求或者通话控制器210所生成的响应过大而无法适配在单个UDP数据报中，甚至是当经压缩时，客户端/通话控制器都回退至非优选的协议(例如TCP，例如HTTP/TCP)。

HTTPS在某些情形下允许消息压缩。然而，在HTTPS中，压缩必须作为HTTPS会话建立的一部分进行协商：客户端必须在其初始请求中指示支持哪种(哪些)压缩方案(如果有)，并且服务器将在其对该请求的响应中指示其是否也支持这些中的任何一个。因此不可能在HTTPS中压缩初始请求。HTTPS响应例如可以包括指向由客户端和服务器双方所支持的压缩方案的压缩词典的链接(例如，作为统一资源指示符的URI)，以使得客户端能够使用该链接来访问词典从而压缩其随后的消息。

作为对比，本文中指向定制压缩词典216的链接(例如，URL)被词典服务器212预先分配给客户端205a。即，甚至在客户端205a尝试发起通话信令之前。即，在图5C中的步骤S520的通信事件建立指示已经由客户端205a例如从用户202a接收之前。

例如，该链接可以：

·由客户端502a：

○在安装之后从词典服务器212下载

○在处理器304上每次创建客户端502a的新的实例时下载

○定期地下载

·由词典服务器212推送至客户端，例如在词典216被更新的任何时候。

客户端可以从词典存储216预先下载该词典。

可替代地，该词典自身例如可以在其被更新的任何时候从数据存储214被推送至客户端205a。

服务器在向客户端发送通知时将使用等同的机制。服务器将从到来的请求推断用于客户端的IP地址和端口，并且在回退至HTTPS之前将首先尝试通过UDP来联系客户端(例如，经由能够经过其连接至客户端205a的代理服务器)。

分组格式

图7示出了示例性应用层分组。

明文(即，未经压缩的)分组702被示出为包括应用层报头702以及可变长度的有效载荷。该报头仅由一个字节的类型字段构成，其表示分组的类型。在该示例中，存在由不同字节所表示的多种类型的非压缩分组。分组702的剩余字节构成其有效载荷。尽管有效载荷具有可变长度，但是其长度并不在报头中被标识。这可以是请求有效载荷(如果由客户端205a所生成)或响应有效载荷(如果由通话控制器所生成)。

经压缩的分组704，其有效载荷是通过向明文分组702应用基于词典212的压缩功能而获得的。经压缩的分组704具有它自己的类型报头705，其被设置为将其标识为经压缩的分组。在该示例中，仅有一种类型的经压缩的分组，但是在其他实现中，可以使用多种经压缩的类型以例如表示不同的压缩词典和/或不同的压缩功能。再一次，经压缩的分组的有效载荷是可变的，但是不使用长度字段。

示出了经加密的分组706，其有效载荷包括利用会话密钥加密的经压缩的分组704(包括其报头704)的经加密的版本。至少针对客户端205所生成的阻抗(resist)，该有效载荷还包括：

·初始化向量

·会话密钥(第一实施例)的经加密的版本或者会话密钥ID(第二实施例)。

该经加密的分组也具有其自己的类型字段707，以将其标识为经加密的分组。在该示例中，仅有单个类型的经加密的分组，但其他实现可以定义多种类型的经加密的分组。

在任何地方都没有定义“长度”字段——仅有类型字段。假设该过程从整个分组开始，并且递归地将其解析为经加密的分组(如果类型如此指示)，接着为经压缩的分组，以及最终为明文分组。整个UDP分组仅包含可能被多次封装的一个消息。

如果需要在一个分组中发送多个消息，则可以定义另一种封套(envelope)类型(例如64)，其后跟有2字节的长度字段，并且接着是在下一个类型的封套中封装的数据。

在相关信息无法在剩余类型值中被编码的情况下可以增加更多字段(例如，用于识别压缩算法等)。

重播保护

重播保护确保重复发送先前所捕获的消息的攻击者应当无法代表客户端开始另一个通话并且执行任何其他动作。

重要的通话请求——尤其是通话建立请求——需要针对分组重播得到保护。有两种共同工作的机制来防止UDP协议上的重播攻击。

短期重播保护

通话控制器在缓冲器中保存对最近数分钟内的所有请求的响应，所述请求按客户端生成的RequestID来索引。所述缓冲器主要用于在客户端重新尝试请求的情况下(由于超时或连通性丢失)提供幂等性(idempotency)，但是其也自动地针对重播攻击而进行防护。当响应在缓冲器中被找到时，其被发送回客户端并且不执行动作。该缓冲器被保存在针对服务器机器524a、524b、524c的集群的共享存储526中，以使得该重播保护策略对整个集群进行保护而不仅是对集群中的个体机器进行保护(尽管不排除个体服务器保存其自己的缓冲器的可能性)。

有关单个通话的大多数请求通过将每个通话与具体机器进行关联的代理层而被保证最终到达同一机器。

简而言之，响应缓冲器提供了短期重播保护(在5分钟的量级)。

长期重播保护

当客户端生成会话权证时，其还使用来自响应的日期报头来估计客户端与服务器时钟之间的大致时间差。所有UDP请求都包括针对时间偏移所调整的时间戳，并且如果实际服务器时间与时间戳之间的不匹配大于响应缓冲器持续时间(5分钟)，则该请求被丢弃并且否定确认分组被发送至针对该请求ID的客户端。

如果客户端的时钟在权证取回及其使用之间被调节超过5分钟，则存在错误肯定的可能性，但是这由于UDP协议仅是一种优化而是可接受的——在该事件中，客户端将仅是在接收到否定ACK之后或者在经过短的回退超时(1-2秒)之后回退至例如TCP(例如，HTTP/TCP)。

如以上所提到的，本公开的部分1)、2a)和2b)的各种方法能够被组合以实现以上所给出的效果。然而，所述技术是可分离的。即，例如，本公开的1)的加密技术在其他上下文中能够在没有2a)的数据压缩技术和/或没有2b)的协议回退技术的情况下被实现，反之亦然。

通常而言，本文所描述的任何功能都可以使用软件、固件、硬件(例如，固定逻辑电路)或者这些实现的组合来实施。如在本文所使用的术语“模块”、“功能”、“组件”和“逻辑”一般表示软件、固件、硬件，或者其组合。在软件实现的情况下，所述模块、功能、组件或逻辑表示在处理器(例如，一个或多个CPU)上执行时执行指定任务的程序代码。所述程序代码可以存储在一个或多个计算机可读存储器设备中。以下所描述的技术的特征是独立于平台的，这意味着该技术可以在具有多种处理配置的多种商业计算平台上实现。

例如，用户设备(用户终端)还可以包括使得该用户终端的硬件执行操作的实体(例如，软件)，例如处理器功能块等。例如，用户终端可以包括计算机可读介质，其可以被配置为保存使得所述用户终端，更具体地所述用户终端的操作系统和相关联硬件，执行操作的指令。因此，所述指令用于配置操作系统和相关联的硬件以执行操作并且以该方式引起操作系统和相关联硬件的转换从而执行功能。所述指令可以由计算机可读介质通过多种不同的配置提供至用户终端。

计算机可读介质的一种这样的配置是信号承载介质，并且因此其被配置为例如经由网络而将指令(例如，作为载波)传送至计算设备。计算机可读介质还可以被配置为计算机可读存储介质，并且因此不是信号承载介质。计算机可读存储介质的示例包括随机访问存储器(RAM)、只读存储器(ROM)、光盘、闪速存储器、硬盘存储器，以及可以使用磁性、光学和其他技术来存储指令和其他数据的其他存储器设备。

该主题的第一方面针对于一种在远程通信控制器的控制下在发起设备与响应设备之间建立通信事件的方法，所述方法包括由所述发起设备来实现以下步骤：

在预通信事件建立阶段：在所述发起设备与所述通信控制器之间建立安全连接，经由所述安全连接在所述发起设备与所述通信控制器之间交换会话密钥协商消息，以在所述发起设备能够访问的电子存储位置中获得会话密钥数据，从而由所述发起设备在生成能够由所述通信控制器解密的经加密的消息有效载荷时使用，其中，一旦已经获得了所述会话密钥数据，则所述安全连接终止；

在随后的通信事件建立阶段：

生成通信事件请求有效载荷以用于发送至所述通信控制器；

使用存储在所述能够访问的电子存储位置中的所述会话密钥数据来对所述请求有效载荷进行加密；并且

响应于在所述预建立阶段中在所述会话密钥数据已经被获得并且所述安全连接已经终止之后在所述发起设备处接收到通信事件建立指示，从所述发起设备向所述通信控制器传输包括所述经加密的请求有效载荷的通信事件请求，从而使得所述通信控制器对所述经加密的请求有效载荷进行解密，由此设备之间的所述通信事件是基于经解密的有效载荷而在所述通信控制器的控制下建立的。

在实施例中，所述请求有效载荷标识所述响应设备，由此向所述通信控制器传输所述通信事件请求使得所述通信控制器将所述经加密的请求有效载荷解密，并且向在经解密的有效载荷中标识的所述响应设备传输通信事件邀请。

例如，所述请求可以包括：响应设备的设备标识符，和/或远程设备的用户的用户标识符，和/或响应设备的网络地址，并且因此标识该响应设备。

所述安全连接可以是TLS或HTTPS连接。

所述TLS连接可以使用诸如TCP之类的(可靠的)面向连接的传输协议来建立。

作为比较，所述通信事件请求消息可以使用例如UDP的无连接传输协议来发送。可替代地，其可以使用另外的不安全的连接来发送，例如，诸如TCP的不安全的传输层连接和/或诸如HTTP连接的不安全的较高层的连接。

所述会话密钥协商消息可以在网络的传输层上方的网络的应用层经由安全连接进行交换。

所述会话密钥数据可以包括在预建立阶段从通信控制器所接收的会话密钥的经加密的版本，该会话密钥已经由通信控制器使用该通信控制器可用的封装密钥进行了加密。

如上文所提到的，这允许通信控制器的无状态操作。

可替代地(或除此之外)，会话密钥数据可以包括用于向通信控制器标识会话密钥的会话密钥标识符。

该会话密钥数据还可以包括：

·没有利用封装密钥加密的会话密钥版本，和/或

·用于生成会话密钥的未经加密的版本的客户端机密和服务器机密。

发起设备可以使用会话密钥来对请求有效载荷进行加密，其中所述请求还可以包括：

·会话密钥的经加密的版本，由此所述请求使得所述通信控制器使用封装密钥来对会话密钥进行解密，并且使用经解密的会话密钥来对请求有效载荷进行解密，和/或

·会话密钥标识符。

发起设备可以使用从会话密钥得出的加密密钥来对有效载荷进行加密。

例如，发起设备可以通过对会话密钥的未经加密的版本应用密钥推导函数来生成加密密钥，并且使用所得出的加密密钥来对有效载荷进行加密。

可替代地，发起设备可以通过对会话密钥的经加密的版本应用密钥推导函数来生成加密密钥，并且使用所得出的加密密钥来对有效载荷进行加密。在该情况下，会话密钥可以不是经由安全连接进行交换的。例如，可以使用诸如已知的Diffie-Hellman算法之类的密钥交换机制，以允许发起设备与通信控制器以使得任何窥探者都不可能猜测出最终对称密钥的方式在没有曾经交换过所协定的对称会话密钥的情况下关于对称会话密钥达成共识。然而，即使在该情况下，在本上下文中，安全连接仍然被用来交换一些非加密的密钥推导输入数据，即使其不是会话密钥本身。由此，非加密的密钥推导输入数据可以经由安全连接来交换并且在生成加密密钥时被用作对密钥推导函数的输入(例如，作为Diffie-Hellman算法的输入)。

会话密钥可以由通信控制器所生成，并且会话密钥的未经加密的版本可以在预建立阶段经由安全连接从通信控制器接收。

会话密钥可以由通信控制器独立于由发起设备提供至通信控制器的任何信息而生成。

可替代地，发起设备可以生成客户端机密并且在预建立阶段将其传送至通信控制器，并且在预建立阶段从通信控制器接收服务器机密，其中，机密中的至少一个(即，所述机密之一或二者)经由安全连接进行传送；发起设备可以通过将客户端机密与服务器机密组合来生成会话密钥的未经加密的版本，并且使用会话密钥的未经加密的版本来对有效载荷进行加密。

会话密钥数据可以包括会话密钥标识符，并且会话密钥的版本可以关联于会话密钥标识符被存储在通信控制器所能够访问的存储器位置中。

存储在通信控制器所能够访问的存储器位置中的会话密钥的版本可以是利用封装密钥进行加密的会话密钥的经加密的版本。可替代地，存储在通信控制器所能够访问的存储器位置中的会话密钥的版本可以是没有利用封装密钥进行加密的会话密钥的版本，其仅被存储在易失性存储器中。

会话密钥标识符可以由发起设备从通信控制器接收，或者会话密钥标识符是由发起设备生成并且被传送至通信控制器(例如，GUID)的。

所述请求还可以包括由发起设备生成的随机化的初始化向量，由此该发起设备能够利用不同的初始化向量将会话密钥数据反复用于随后的通信事件。

发起设备可以通过在被加密时至少向有效载荷应用散列函数来生成完整性校验数据，其中，所述请求还可以包括该完整性校验数据，由此通信控制器能够在对加密有效载荷进行解密之前使用该完整性校验数据来检测对其的任何改变。

该散列函数可以使用从会话密钥得出的认证密钥而被应用。

该散列函数可以被应用于经加密的有效载荷与初始化向量的组合(例如，连接)。

该会话密钥数据还可以包括从通信控制器所接收的封装密钥的标识符，其中，传送至通信控制器的请求还可以包括封装密钥的标识符，由此该控制器能够识别要利用哪个封装密钥来解密会话密钥。

该封装密钥可以仅被存储在通信控制器所能够访问的易失性存储器中。

该预建立阶段可以包括在发起设备处从通信控制器接收表示在通信控制器处远程测量的时间的时间戳，其中，发起设备可以存储对该远程测量的时间与在发起设备处本地测量的时间之间的差异的指示。

该请求还可以包括由发起设备考虑到本地测量的时间与远程测量的时间之间的差异而生成的时间戳。

该通信控制器可以确定请求中的时间戳与在通信控制器处接收该请求的时间之间的差异，并且可以被配置为在该差异超过第一时段的情况下拒绝该请求。

该通信控制器可以是包括至少两个能够访问共享的电子存储的服务器的服务器池，由此该池中的任何服务器都能够对该请求进行响应。

该请求还可以包括由发起设备所生成的随机化请求标识符。

该请求可以在服务器中的一个处被接收，并且作为响应，该服务器可以可以至少将其请求标识符的副本存储在共享存储中，其在那里保留第二时段，其中，如果在该第二时段内在所述服务器中的另一个处接收到包括相匹配的请求标识符的任何随后的请求，则该服务器可以忽略该随后的请求。

该通信事件建立指示可以是由发起设备的用户手动地发动的。例如，该通话建立指示可以由发起设备的用户发动：选择发起设备上用来呼叫响应设备和/或响应设备的用户的选项，或者向发起设备提供表示响应设备和/或响应设备的用户的语音或手势输入。

通信客户端可以被安装在发起设备上，并且该预建立阶段可以作为该客户端的安装的一部分被执行或者响应于所安装的客户端在发起设备的处理器上运行达第一时间而被执行。

可替代地，该预建立阶段可以在由预先确定的会话密钥协商安排所指定的时间被触发。例如，该会话密钥协商安排可以指定应当在每隔预先确定的天数时获得新的会话密钥数据。即，可以在该安排所指定的每个时机获得新鲜的会话密钥数据。

可替代地，该预建立阶段可以在通信客户端每次在发起设备的处理器上被实例化时被执行。即，可以在客户端每次被实例化时获得新鲜的会话密钥数据。

根据该主题的第二方面，一种在发起设备与远程设备之间建立会话的方法，所述方法包括在所述发起设备处实现以下步骤：

根据优选的网络化协议将会话请求从所述发起设备发送至所述远程设备；

由所述发起设备在从发送的时刻开始的初始时段内监视所经过的时间；

如果在所述初始时段内在所述发起设备处没有接收到对所述请求的临时响应，则所述发起设备根据非优选的协议将另一会话请求发送至另一设备；

如果在所述初始时段内接收到对所述请求的临时响应，则所述发起设备在经扩展的时段内继续监视所经过的时间；

其中，如果在所述经扩展的时段内没有接收到对所述请求的最终响应，则所述发起设备根据非优选的协议而将另一会话请求发送至所述另一设备；

其中，如果在所述经扩展的时段内接收到最终响应，则根据所述优选的网络化协议在所述发起设备与所述另一设备之间建立会话。

由此，仅在分别在初始时段和经扩展的时段内在发起设备处从远程设备接收到临时响应和最终响应二者的情况下，才根据优选的协议来在发起设备与远程设备之间建立会话。否则，根据非优选的协议对会话请求的传送使得替代地根据非优选的协议在发起设备与远程设备之间建立会话。

在实施例中，会话请求可以包括请求标识符，而所述另一会话请求包括匹配的请求标识符。

多个会话请求根据所述优选的网络化协议而从所述发起设备被发送至所述远程设备。

优选的协议可以是不可靠的传输协议，并且非优选的协议可以是可靠的传输协议。例如，优选的协议可以是UDP而非优选的协议可以是TCP。例如，其他会话请求可以是使用通过TCP的HTTP发送的。

如果在所述初始时段或所述经扩展的时段期间的任何时间处由所述发起设备从所述远程设备接收到协议回退消息，则所述发起设备作为响应而根据所述非优选的协议将会话请求发送至所述远程设备。

所述远程设备可以是通信控制器，其中，基于在所述发起设备与所述通话控制器之间所建立的会话，在所述通话控制器的控制下，在所述发起设备与响应设备之间建立通信事件。

例如，所述会话请求中的每个会话请求可以标识所述响应设备，其中，响应于接收到所述会话请求中的任何一个会话请求，所述通信控制器能够向在其中标识的所述响应设备发送通信事件邀请。

该通信事件可以是通话、屏幕共享会话、或共享白板会话。

所述发起设备被配置为在发送所述会话请求之前对其应用压缩功能以降低其大小，并且所述会话请求一旦被压缩，就在所述优选的协议的单个分组中被发送至所述远程设备。

所述发起设备被配置为：如果所述会话请求在被压缩后不能够被封装在所述优选的协议的单个分组中，则替代地根据所述非优选的协议将所述会话请求发送至所述远程设备。

所述初始时段可以是自会话请求根据优选的协议的传送起的2秒或更短；和/或所述经扩展的时段可以是自会话请求根据优选的协议的传送起或者自临时响应的接收起的15秒或更短。

根据本发明的第三方面，一种在发起设备与远程设备之间建立会话的方法包括在远程设备处实现以下步骤：

根据优选的网络协议从发起设备接收会话请求；

直接响应于该会话请求，根据优选的协议向发起设备传送对该会话请求的临时响应；

处理该会话请求以生成针对第二请求的最终响应，其中临时响应在所述处理已经完成且最终响应确定之前被传送至发起设备；并且

一旦根据优选的协议确定了所生成的响应，则将其传输至发起设备；

其中，如果根据非优选的协议从发起设备接收到相匹配的会话请求，则该远程设备作为响应根据该非优选的协议向发起设备重新传送最终响应的版本。

根据本发明的第四方面，一种在发起设备与远程设备之间建立会话的方法包括在该远程设备处实现以下步骤：

根据优选的网络协议从发起设备接收会话请求；

处理该请求以生成针对该会话请求的响应(例如，最终响应)；

确定所生成的响应是否能够被封装在优选的网络协议的单个分组中；

如果是，则在优选的协议的单个分组中根据该优选的协议将所生成的响应传送至发起设备；

如果否，则向发起设备传送协议回退消息，由此使得发起设备根据非优选的协议向远程设备传送另一个会话请求。

在第三方面的实施例中，所述远程设备可以在可访问的电子存储位置中存储所生成的响应，并且响应于根据非优选的协议从发起设备接收到其他会话请求，所述远程设备可以从该可访问的电子存储位置取回所存储的响应并且根据非优选的协议将其传送至发起设备。

在第二或第三方面的实施例中，所述远程设备可以是通信控制器和/或服务器(例如，通信控制器的服务器集群中的服务器)。

在实施例中，所述优选的网络协议可以是不可靠的(例如，无连接的)传输协议(例如，UDP)。

所述非优选的网络协议可以是可靠的(例如，面向连接的)传输协议(例如，TCP)。

本主题的第五方面针对于选择多种传输协议中的一个以供网络设备使用的方法，所述方法包括由网络设备实施以下步骤：

生成未经压缩的消息以用于经由网络传送至另一个设备；

通过对所述未经压缩的消息应用压缩功能来生成具有降低的消息大小的所述消息的经压缩的版本；

确定所述经压缩的版本的降低的消息大小；

将所述降低的消息大小与多个传输协议中的优选的传输协议的最大传输分组大小进行比较；

如果所述降低的消息大小超过所述优选的传输协议的所述最大传输分组大小，则根据所述传输协议中的非优选的传输协议将所述消息的未经压缩的版本或所述经压缩的版本封装到一个或多个传输分组中，并且经由所述网络根据所述非优选的传输协议将所述一个或多个传输分组发送至所述另一设备；并且

如果所述经压缩的消息大小不超过所述优选的传输协议的所述最大传输分组大小，则根据所述优选的传输协议将所述消息的所述经压缩的版本封装到单个传输分组中，并且经由所述网络根据所述优选的传输协议将所述传输分组发送至所述另一设备。

在实施例中，所述优选的网络协议可以是不可靠的(例如，无连接的)传输协议(例如，UDP)，由此该单个分组是所述不可靠的传输协议的单个数据报(例如，UDP数据报)。

所述非优选的网络协议可以是可靠的(例如，面向连接的)传输协议(例如，TCP)，由此该一个或多个传输分组是所述可靠的传输协议的(多个)分组(例如，(多个)TCP分组)。

所述压缩功能可以是词典编码器压缩功能。

所述网络设备可以是服务器设备，例如通信控制器中的服务器设备。

可替代地，所述网络设备可以是客户端设备，例如用户设备或其他计算机设备，其中所述步骤可以由在该设备的处理器上执行的通信客户端来实现。

本主题的第六方面针对一种在远程通信控制器(例如，具有共享的高速缓存的服务器集群中的服务器)的控制下在发起设备与响应设备之间建立通信事件的方法，所述方法包括由发起设备实施以下步骤：

在预会话建立阶段：在发起设备处接收压缩词典或者标识压缩词典保存在那里的可寻址存储器位置的词典链接；

将所接收的压缩词典或者所接收的词典链接存储在发起设备的电子存储中；

生成初始会话建立请求消息以用于传送至通信控制器；

使用所存储的压缩词典或者通过使用所存储的词典链接来访问压缩词典，基于该压缩词典来对该初始会话建立请求消息应用压缩以降低其大小；并且

响应于在词典或词典链接已经被接收并存储在发起设备之后在发起设备接收到通信事件建立指示，由发起设备向通信控制器传送经压缩的初始会话建立消息以在发起设备与通信控制器之间建立会话；

其中，基于在发起设备与通信控制器之间所建立的会话来在发起设备与响应设备之间建立通信事件。

在实施例中，所述通信事件建立指示可以由发起设备的用户发动，由此该词典或词典链接在用户已经发起该通信事件建立指示之前被接收。

所述通话建立指示例如可以由发起设备的用户发动：选择发起设备的显示器上用来呼叫响应设备和/或响应设备的用户的选项，或者向发起设备提供表示响应设备和/或响应设备的用户的语音或手势输入。发起设备可以包括经由其发起该指令的用户界面。

所述初始会话建立请求消息可以标识响应设备，由此将其传送至通信控制器可以使得该通信控制器向其中所标识的响应设备传送通信事件邀请。

所述初始会话建立请求消息可以包括响应设备的设备标识符，和/或远程设备的用户的用户标识符，和/或响应设备的网络地址，并且因此标识该响应设备。

所述会话可以在不从发起设备向通信控制器传送任何未经压缩的消息的情况下被建立。

所述词典链接可以是URI。

在经压缩的初始会话建立请求能够被封装在优选传输协议的单个分组中的情况下，经压缩的初始会话建立消息可以仅根据优选传输协议而被传送至通信控制器，其中发起设备可以被配置为另外地根据非优选传输协议而将初始会话建立请求传送至通信控制器。

所述优选的网络协议可以是不可靠的传输协议(例如，UDP)，而所述非优选的网络协议可以是可靠的传输协议(例如，TCP)。

在实施例中，所述词典链接可以是标识可寻址的存储器位置的URI。

即，发起设备与通信控制器之间的会话在发起设备非必须向通信控制器发送任何未经压缩消息的情况下被建立。这与需要至少从客户端向服务器发送的第一消息要不被压缩(以考虑到不支持压缩的设备)的HTTPS形成对比。

本文所提到的任何通信事件例如可以是通话(例如呼叫)、屏幕共享会话、共享白板会话等。

根据本主题的另一个方面，一种网络设备(例如，发起设备或者诸如服务器设备的远程设备)包括被配置为保存可执行代码的电子存储，以及连接至所述电子存储并且被配置为执行所述代码的处理器，其中，所述可执行代码当在所述处理器上执行时被配置为实施在本文中所公开的方法步骤中的任何一项。

根据本主题的另一个方面，一种计算机程序产品包括可执行代码，所述可执行代码被存储在计算机可读存储介质上并且当在网络设备(例如，发起设备或者诸如服务器设备的远程设备)的处理器上被执行时被配置为实现在本文中所公开的方法步骤中的任何一项。

尽管已经用特定于结构特征和/或方法动作的语言对主题进行了描述，但是所要理解的是，所附权利要求中所限定的主题并不一定限于以上所描述的具体特征或动作。相反，以上所描述的具体特征和动作是作为实现权利要求的示例形式而公开的。

Claims (15)

1.一种在发起设备与远程设备之间建立会话的方法，所述方法包括在所述发起设备处实现以下步骤：

根据优选的网络化协议将会话请求从所述发起设备发送至所述远程设备；

由所述发起设备在从发送的时刻开始的初始时段内监视所经过的时间；

如果在所述初始时段内在所述发起设备处没有接收到对所述请求的临时响应，则所述发起设备根据非优选的协议将另一会话请求发送至另一设备；

如果在所述初始时段内接收到对所述请求的临时响应，则所述发起设备在经扩展的时段内继续监视所经过的时间；

其中，如果在所述经扩展的时段内没有接收到对所述请求的最终响应，则所述发起设备根据非优选的协议而将另一会话请求发送至所述另一设备；

其中，如果在所述经扩展的时段内接收到最终响应，则根据所述优选的网络化协议在所述发起设备与所述另一设备之间建立会话。

2.根据权利要求1所述的方法，其中，所述会话请求包括请求标识符，而所述另一会话请求包括匹配的请求标识符。

3.根据权利要求1或2所述的方法，其中，在所述初始时段内，多个会话请求根据所述优选的网络化协议而从所述发起设备被发送至所述远程设备。

4.根据权利要求1、2或3所述的方法，其中，所述优选的协议是不可靠的传输协议，而所述非优选的协议是可靠的传输协议。

5.根据权利要求4所述的方法，其中，所述优选的协议是UDP而所述非优选的协议是TCP。

6.根据权利要求5所述的方法，其中，所述另一会话请求是使用通过TCP的HTTP发送的。

7.根据先前任一项权利要求所述的方法，其中，如果在所述初始时段或所述经扩展的时段期间的任何时间处由所述发起设备从所述远程设备接收到协议回退消息，则所述发起设备作为响应而根据所述非优选的协议将会话请求发送至所述远程设备。

8.根据先前任一项权利要求所述的方法，其中，所述远程设备是通信控制器，其中，基于在所述发起设备与所述通话控制器之间所建立的会话，在所述通话控制器的控制下，在所述发起设备与响应设备之间建立通信事件。

9.根据权利要求8所述的方法，其中，所述会话请求中的每个会话请求标识所述响应设备，其中，响应于接收到所述会话请求中的任何一个会话请求，所述通信控制器能够向在其中标识的所述响应设备发送通信事件邀请。

10.根据先前任一项权利要求所述的方法，其中，所述发起设备被配置为在发送所述会话请求之前对其应用压缩功能以降低其大小，并且所述会话请求一旦被压缩，就在所述优选的协议的单个分组中被发送至所述远程设备。

11.根据权利要求10所述的方法，其中，所述发起设备被配置为：如果所述会话请求在被压缩后不能够被封装在所述优选的协议的单个分组中，则替代地根据所述非优选的协议将所述会话请求发送至所述远程设备。

12.一种对消息进行压缩以用于从网络设备发送至另一设备的方法，所述方法包括在所述网络设备处实现以下步骤：

生成未经压缩的消息以用于经由网络发送至所述另一设备；

通过对所述未经压缩的消息应用压缩功能来生成具有降低的消息大小的所述消息的经压缩的版本；

确定所述经压缩的版本的降低的消息大小；

将所述降低的消息大小与多个传输协议中的优选的传输协议的最大传输分组大小进行比较；

如果所述降低的消息大小超过所述优选的传输协议的所述最大传输分组大小，则根据所述传输协议中的非优选的传输协议将所述消息的未经压缩的版本或所述经压缩的版本封装到一个或多个传输分组中，并且经由所述网络根据所述非优选的传输协议将所述一个或多个传输分组发送至所述另一设备；并且

如果所述经压缩的消息大小不超过所述优选的传输协议的所述最大传输分组大小，则根据所述优选的传输协议将所述消息的所述经压缩的版本封装到单个传输分组中，并且经由所述网络根据所述优选的传输协议将所述传输分组发送至所述另一设备。

13.根据权利要求12所述的方法，其中，所述网络设备是服务器设备或客户端设备。

14.一种网络设备，包括：

网络接口；

保存可执行代码的电子存储；以及

处理器，所述处理器连接至所述电子存储并且被配置为执行所述代码，其中，所述代码当在所述处理器上被执行时被配置为实现先前任一项权利要求所述的方法。

15.一种包括可执行代码的计算机程序产品，所述可执行代码被存储在计算机可读存储介质上，并且当在网络设备的处理器上被执行时被配置为实现先前任一项权利要求所述的方法。