一种实时通话过程中基于测速的通道切换方法、客户端与服务器与流程

本发明属于通信技术领域，尤其涉及一种实时通话过程中基于测速的通道切换方法、客户端与服务器。

背景技术：

随着网络传输速度的加快，给互联网多媒体应用带来了机会和挑战。相对于传统通讯方式，互联网通话更加便捷和廉价。尤其是移动互联网日新月异的今天，智能手机等可联网设备已随处可见，在选择通讯方式的时候还可以使用视讯通话。基于互联网的音视频通讯在给人们生活带来极大便利的同时，也对音视频通话质量提出更高的要求。

然而，中国的互联网环境极其复杂，大运营商各建网络，小运营商租用网络，跨运营商丢包严重，在高峰期时段还有连不通的情况。在现有网络条件下，如何追求更高质量的语音通话和高清视频通讯，是对互联网音视频通讯的迫切要求。

本发明主要为了解决在现有互联网环境中，如何选择更高质量的通话，同时减轻网络带宽负载，从而达到提高音视频传输质量，提高用户体验，并且降低网络成本。

技术实现要素：

发明人在研究和实践过程中发现，目前的音视频通信过程，主要依靠服务器在客户端之间中转数据，数据经过的通道是客户端与服务器之间的中转通道。在一般情况下，中转通道的网络状况是良好的，然而，由于互联网运营商出口带宽以及在不同时段出现的网络拥堵等问题，中转通道的网络状况会出现劣化，不仅无法实现高质量通话的要求，甚至会出现丢包严重，误码率高，传输速度慢，稳定性差，安全性低，甚至还存在无法通话无法连通的问题。为解决上述问题，惯常的思路是改善网络条件，通过设置更多数量的接口机拓宽网络接口带宽，然而硬件的增加必然带来网络耗费成本和维护费用的大幅增加。发明人发现，客户终端之间可以建立直连通道，直连通道的网络状况通常劣于中转通道，但是在中转通道网络条件劣化的情况下，二者通信条件反转，直连通道的网络条件反而要优于所述中转通道。

基于发明人的上述研究，本发明提出一种实时通话过程中基于测速的通道切换方法，包括如下步骤：

经服务器建立与第二终端间的中转通道；建立与所述第二终端间的直连通道；将所述直连通道上报所述服务器；接收所述服务器下发的通道测速命令，进行直连通道测速，并向服务器上报所述测速结果；所述服务器用于根据所述通道测速结果，确定是否切换通话通道。

优选地，所述方法还包括检测所述通话是否跨互联网服务提供商(ISP)。

优选地，基于网络地址转换穿越(NAT Traversal)建立与所述第二终端间的直连通道。

优选地，所述通道测速命令至少包括测速包大小、发包间隔、发包数量和指定测速地址。

优选地，所述直连通道测速包括向指定测速地址发送测速包，基于所述测速包的收发情况计算所述测速结果。

优选地，所述测速结果至少包括计算网络抖动、丢包率和网络延时。

本发明还提出一种客户端，所述客户端包括如下模块：

中转通道建立模块，用于经服务器建立与第二终端间的中转通道；

直连通道建立模块，用于建立与所述第二终端间的直连通道；

通道上报模块，用于将所述直连通道上报所述服务器；

测速执行模块，用于接收所述服务器下发的通道测速命令，进行直连通道测速，并上报测速结果；所述服务器根据所述通道测速结果，决策是否切换通话通道。

优选地，所述直连通道建立模块基于网络地址转换穿越(NAT Traversal)建立与所述第二终端间的直连通道。

优选地，所述测速执行模块包括接收子模块，用于接收通道测速命令。

优选地，所述通道测速命令至少包括测速包大小、发包间隔、发包数量和指定测速地址。

优选地，所述测速执行模块包括测速包收发子模块，用于向指定测速地址发送测速包，并获取所述测速包的收发情况。

优选地，所述测速执行模块包括计算子模块，基于所述测速包的收发情况计算网络抖动、丢包率和网络延时。

本发明还提出一种服务器，所述服务器包括如下模块：

中转通道建立模块，用于与客户端建立中转通道；

测速控制模块，用于向所述客户端下发通道测速命令，并等待所述客户端上报测速结果；

测速决策模块，用于根据所述通道测速结果，决策是否切换通话通道类型。

优选地，所述测速控制模块包括网络监测模块，用于监测是否存在跨互联网服务提供商(ISP)通话或者网络质量不佳,若是，服务器进入待测速状态。

优选地，所述测速控制模块包括第一接收子模块，用接收客户端上报的直连通道信息，若存在所述直连通道信息，且服务器处于所述待测速状态，则向所述客户端下发通道测速命令，进入待接收状态。

优选地，所述服务器还包括中断子模块，用于判断服务器中的模块是否存在状态超时或异常；若存在超时或异常，则结束通道测速。

本发明的有益效果：直连通道的使用可以大大降低接口机网络负载，在客户端之间网络连接很差、或连接失败的情况下，使用中转通道进行数据传输，可以有效的提高通话质量，提升用户体验。

附图说明

下面结合附图对本发明的具体实施方式作进一步详细的说明；

图1是本发明实施一提供的方法流程图。

图2是本发明实施二提供的方法流程图。

图3是本发明实施三提供的装置原理框图。

图4是本发明实施四提供中转通道模块原理框图。

图5是本发明实施四提供的切换前后测速结果对比图。

图6是本发明实施五提供的服务器与客户端数据交互关系图。

图7是本发明实施五提供的测速过程中服务器状态图。

具体实施方式

为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

本发明涉及的技术术语解释如下：

NAT(network address translation)：NAT是作为一种解决IPv4地址短缺以避免保留IP地址困难的方案而流行起来的。也叫做网络掩蔽或者IP掩蔽(IP masquerading)，是一种在IP封包通过路由器或防火墙时重写来源IP地址或目的IP地址的技术。这种技术被普遍使用在有多台主机但只通过一个公有IP地址访问因特网的私有网络中。

NAT traversal(network address translation traversal):NAT穿越，其目的在于解决处于使用了NAT设备的私有TCP/IP网络中的主机之间建立连接的问题。

P2P(peer-to-peer):又称点对点技术，是无中心服务器、依靠用户群(peers)交换信息的互联网体系，他的作用在于，减低以往网络传输中的节点，以降低数据丢失的风险。与有中心服务器的中央网络系统不同，对等网络的每个用户端既是一个节点，也有服务器的功能，任何一个节点无法直接找到其他节点，必须依靠其户群进行信息交流。

直连通道：客户端之间实现了NAT穿越，数据通过P2P方式传输。

中转通道：客户端之间的数据传输方式通过后台服务器来中转。

通道切换：有直连通道的情况下，数据传输方式在直连和中转通道中进行选择。

实施例一：

本实施例提供一种实时通话过程中基于测速的通道切换方法，如图1所示，方法包括如下步骤：

步骤S101,经服务器建立与第二终端间的中转通道。

步骤S102,建立与所述第二终端间的直连通道。

步骤S103,将所述直连通道上报所述服务器。

步骤S104,接收所述服务器下发的通道测速命令，进行直连通道测速，并向服务器上报所述测速结果；所述服务器综合所述直连通道测速结果和所述中转通道网络状况，确定是否切换通道。

在步骤S101中，用户终端与第二终端进行通讯，通讯包括音频、音视频等，客户端之间的数据经过服务器转发。在通讯进行过程中，由于通话跨互联网服务提供商(ISP)或者网络拥塞等造成的网络状况恶化，此时不仅无法实现高质量通话的要求，甚至会出现丢包严重，误码率高，传输速度慢，稳定性差，安全性低，甚至还存在无法通话无法连通的问题。

在步骤S102中，服务器会指挥用户终端建立直连通道，直连通道可以使用诸如NAT穿越来实现，如果穿越成功，则用户之间建立了直连通道。在通常情况下，中转通道的网络质量是优于直连通道的，但当中转通道的网络劣化到一定程度，中转通道和直连通道之间的网络质量则发生了反转，直连通道的网络质量反而要优于中转通道，在此情况下，使用直连通道进行通话可以解决中转通道网络劣化的问题。但是，究竟选择中转通道还是选择直连通道并不容易决定，因为存在虽然中转通道网络条件劣化，但是中转通道网络情况仍然优于直连通道的情况。

在步骤S103中，客户端将第二通道上报服务器，服务器在接收到用户上报的直连通道情况后，服务器得知用户的通道信息，根据用户自身的情况，向客户端发送测速指令。通道测速命令至少包括测速包大小、发包间隔、发包数量和指定测速地址等测速参数信息。

在步骤S104中,客户端接收服务器下发的通道测速命令，进行直连通道测速，所述直连通道测速包括向指定测速地址发送带时戳的测速包，根据发包和收包的时间计算出网络抖动、丢包率和网络时延。测速结束后，客户端向服务器上报测速结果；所述服务器综合所述直连通道测速结果和所述中转通道网络状况，确定是否切换通道。

实施例二：

本实施例提供一种实时通话过程中基于测速的通道切换方法，如图2所示，方法包括如下步骤：

步骤S201,建立与客户端之间的中转通道，中转客户端之间的通讯数据。

步骤S202,接收客户端上报的直连通道情况，并下发测速命令。

步骤S203,接收客户端上传的通道测速结果，根据测速结果确定是否切换通话通道。

在步骤S201中，服务器建立与客户端之间的中转通道，中转客户端之间的通讯数据。在通讯进行过程中，由于通话跨互联网服务提供商(ISP)或者网络拥塞等造成的网络状况恶化，此时不仅无法实现高质量通话的要求，甚至会出现丢包严重，误码率高，传输速度慢，稳定性差，安全性低，甚至还存在无法通话无法连通的问题。

在步骤S202中，服务器会接收客户端上报的直连通道情况，如果存在直连通道，则下发通道测速命令。通道测速命令至少包括测速包大小、发包间隔、发包数量和指定测速地址等测速参数信息。

在步骤S203中，服务器接收客户端上传的通道测速结果，根据测速结果确定是否切换通话通道。

实施例三：

本实施例提供一种客户端，如图3所示，所述客户端包括如下模块：

中转通道建立模块，用于经服务器建立与第二终端间的中转通道；

直连通道建立模块，用于建立与所述第二终端间的直连通道；

通道上报模块，用于将所述直连通道上报所述服务器；

测速控制模块，用于接收所述服务器下发的通道测速命令，进行直连通道测速，并上报测速结果；所述服务器根据所述通道测速结果，决策是否切换通话通道。

中转通道建立模块，用于客户端与第二终端建立中转通道，中转通道用于传输包括音频、音视频等数据流，客户端之间的数据经过服务器转发。在通讯进行过程中，由于通话跨互联网服务提供商(ISP)或者网络拥塞等造成的网络状况恶化，此时不仅无法实现高质量通话的要求，甚至会出现丢包严重，误码率高，传输速度慢，稳定性差，安全性低，甚至还存在无法通话无法连通的问题。

直连通道建立模块，用于客户端与第二终端建立直连通道。直连通道通常是由服务器指挥用户终端建立，直连通道可以使用诸如NAT穿越来实现，如果穿越成功，则用户之间建立了直连通道。在通常情况下，中转通道的网络质量是优于直连通道的，但当中转通道的网络劣化到一定程度，中转通道和直连通道之间的网络质量则发生了反转，直连通道的网络质量反而要优于中转通道，在此情况下，使用直连通道进行通话可以解决中转通道网络劣化的问题。但是，究竟选择中转通道还是选择直连通道并不容易决定，因为存在虽然中转通道网络条件劣化，但是中转通道网络条件仍然优于直连通道的情况，在此情况下，如果将中转通道切换为直连通道，无疑不会改善用户的通话质量，甚至可能会造成不良的用户体验。因此，需要对中转通道和直连通道的网络状况进行综合评价，以确定是否进行通道的切换操作。

通道上报模块，用于将所述直连通道上报所述服务器。客户端将第二通道上报服务器，服务器在接收到用户上报的直连通道情况后，服务器得知用户的通道信息，根据用户自身的情况，向客户端发送测速指令。通道测速命令至少包括测速包大小、发包间隔、发包数量和指定测速地址等测速参数信息。

测速执行模块，用于接收所述服务器下发的通道测速命令，进行直连通道测速，并上报测速结果。客户端接收服务器下发的通道测速命令，进行直连通道测速，所述直连通道测速包括向指定测速地址发送带时戳的测速包，根据发包和收包的时间计算出网络抖动、丢包率和网络时延。测速结束后，客户端向服务器上报测速结果；所述服务器综合所述直连通道测速结果和所述中转通道网络状况，确定是否切换通道。

本实施例还提供一种服务器，配合客户端使用，如图3所示，

测速控制模块，服务器接收客户端上报的直连通道情况，在得知用户的通道信息后，根据用户自身的情况，向客户端发送测速指令并等待所述客户端端上报测速结果。通道测速命令至少包括测速包大小、发包间隔、发包数量和指定测速地址等测速参数信息。

客户端用于接收服务器下发的通道测速命令，进行直连通道测速，所述直连通道测速包括向指定测速地址发送带时戳的测速包，根据发包和收包的时间计算出网络抖动、丢包率和网络时延。

服务器的测速决策模块，等待客户端上报的测速结果，根据所述通道测速结果情况，决策是否切换通话通道类型。

实施例四：

客户端接收服务器下发的通道测速命令，进行直连通道测速，所述直连通道测速包括向指定测速地址发送带时戳的测速包，根据发包和收包的时间计算出网络抖动、丢包率和网络时延。测速结束后，客户端向服务器上报测速结果；服务器用于根据所述通道测速结果，确定是否切换通话通道。

网络抖动是指数据包在网络中传输延时的变化，如果网络出现拥塞，网络上的节点设备队列增大，将导致数据包的传输延时变大，而网络条件变好将导致网络传输延时变小。

实际音视频通话过程中，网络抖动对通话效果影响明显，严重影响到用户的体验。在本实施例中，在中转通道设置可变的抖动缓冲区(Jitter Buffer)，这种缓冲区的大小动态可变，引入的延时可变化，在抖动小的时候延迟低，抖动大时延时大，这种可变大小的缓冲区虽然复杂度高，但是适应能力强，能够动态适应网络条件的变化。

如图4所示的中转通道网络结构中，包括如下模块：

网络模块：负责处理网络接入，房间逻辑，数据收发。另外ARQ模块负责丢包重传，FEC模块负责FEC解包处理。经过网络模块处理后的数据包主动送入Jitter模块。

Jitter模块：音频抗抖动的核心模块，根据网络延时，缓冲延时，网络是否丢包等数据，使用PLC、变速算法等，动态调整Jitter Buffer的大小，在保证延迟的情况下，确保最好的语音质量。

Jitter Buffer：负责缓冲网络数据包，去除乱序处理，提供接口判断是否丢包。

算法模块：包括解码器、PLC(丢包隐藏)、正常、加速、减速处理模块，解码器模块负责语音数据包的解码，PLC模块在丢包时对丢包数据进行恢复，变速模块负责对解码后的语音数据进行变速处理。变速模块主要使用平均幅度差函数(AMDF)算法从短时语音信号中检测基音周期，如果需要加速则将30ms数据中Skip一个基音周期到达加速效果；如果需要减速，30ms数据中Insert一个复制的基音周期，达到拉升效果。

Play Buffer：缓存经过解码、PLC、变速处理之后的PCM数据，等待播放模块来取数据播放。

网络统计：负责统计网络抖动产生的网络延时，参考播放时间戳，统计数据包到达间隔，提前达到(0)、正常到达(1)、延时到达(2、3、4……)，把统计出0、1、2、3、4……到达间隔的概率分布函数，计算涵盖一定百分比概率的最大到达间隔为网络的抖动延时，例如93％。

Buffer统计：负责统计Jitter模块中缓存数据延时，使用简单低通滤波器进行统计。

策略决策：它是抗抖动算法的核心模块，根据Buffer统计得出的缓存延时、网络统计的网络抖动延时、当前数据包接收状况以及历史的PLC、加速、减速处理状态，决策当前是否从Jitter Buffer中提取数据进行解码，决策解码后的数据是否需要正常、PLC、加速、加速，从而让缓存延时趋近于网络延时，这就是可变Jitter Buffer的核心原理。

播放模块：定时20ms从Jitter模块的播放缓冲区取数据播放，由于播放线程都在系统的播放回调函数中实现，由于系统不同，20ms取包的间隔精度也不同。

语音抗抖动算法，在800ms网络抖动情况下的延时变化、变速曲线如下，延时变大情况下，进行加速处理，延时突然变小情况下进行减速，策略决策很快，很好的适应了网络抖动的变化。

在切换进行过程中，中转通道的网络条件是重要的参数，这些网络参数通过，Jitter模块、Jitter Buffer模块、网络统计模块、Buffer统计模块、策略决策模块、播放模块来综合获得，参数至少包括：通道用户数、接收码率、发送码率、发送丢包率、接收丢包率和上行时延和总时延。上述网络参数的获得是实时的，受到用户总数量，测速时间段等因素影响。例如，在具体的测试过程中，通话用户总数为30万时与通话用户总数为60万的服务器拒包率不同，而导致较好的测试结果。当用户通话跨ISP或者由于网络拥塞导致网络劣化时，会由接收码率、发送码率、发送丢包率、接收丢包率和上行时延和总时延都会体现。

当中转通道网络质量劣化时，则服务器根据终端上报的直连通道情况发出测速指令。通道测速命令至少包括测速包大小、发包间隔、发包数量和指定测速地址等测速参数信息。客户端则向指定测速地址发送带时戳的测速包，根据发包和收包的时间计算出丢包率、上行网络抖动、下行网络抖动、上行时延和总延时。

此时，根据中转通道的网络状况和直连通道的测速结果进行综合判断，当直连通道的测速结果满足进行音视频通话质量的基本条件，既切换条件时，且测速结果表明直连通道的网络条件接近或者优于所述中转通道时，进行通道切换。这样可以节省中转通道的带宽并且同时获得较优的通话质量，达到网络资源的合理分配，同时在一定程度上解决网络拥堵问题。综合判断的条件，包括综合比较切换直连通道与中转通道的用户数量，两通道的丢包率，不同标准差条件下两通道的网络抖动情况，上行时延和总时延。

在具体的判断过程中，当直连通道的丢包率、网络抖动和网络延时满足阈值条件时，则可以认为满足了通道切换的基本条件。该阈值条件与网络通话质量有一定的关系，例如为了保证一般质量的实时音视频通话，直连通道的测速结果需满足：丢包率<5％，上行抖动<200ms，下行抖动<200ms，上行时延<100ms，总时延<200ms，如果直连通道中的某网络参数不满足上述条件，则不进行切换。如果对于通话质量要求较高，则丢包率、上行抖动、下行抖动和延时等参数还要设定得相对更低。

在具体的比较过程中，各条件之间也存在比较的先后顺序，在丢包率相同或者接近的情况下，由于网络抖动是影响音视频通话质量的重要因素，因此可以网络抖动作为综合比较的优先因素，当直连通道与中转通道的网络抖动在同一置信区间接近时，则继续比较网络时延迟。当然，这三项网络参数各有细分，网络抖动包括上行抖动和下行抖动，网络延时则包括上行时延和总时延。在某些条件下，还引入中转通道在线用户数量作为参考。

在一个具体的切换过程中，需要综合所述中转通道的网络状况和所述直连通道的测速情况，通过Jitter模块、Jitter Buffer模块、网络统计模块、Buffer统计模块、策略决策模块获得中转通道丢包率为3.05％，通话200ms上行抖动，下行抖动0.55标准差区间用户数量为88％，上行网络延迟为90ms，总网络延迟为190ms。通过直连通道测速获得的直连通道丢包率为3.0％，通话200ms上行抖动，下行抖动0.55标准差区间用户数量为100％，上行网络延迟为90ms，总网络延迟为180ms。可见，直连通道的网络状况略优于中转通道，因此，服务器确定进行通道切换。

在一个具体的切换过程中，需要综合所述中转通道的网络状况和所述直连通道的测速情况，通过Jitter模块、Jitter Buffer模块、网络统计模块、Buffer统计模块、策略决策模块获得中转通道丢包率为3.05％，通话200ms上行抖动，下行抖动0.55标准差区间用户数量为88％，上行网络延迟为90ms，总网络延迟为190ms。通过直连通道测速获得的直连通道丢包率为5.5％，通话200ms上行抖动，下行抖动0.55标准差区间用户数量为100％，上行网络延迟为90ms，总网络延迟为180ms。虽然，直连通道的其他网络参数优于中转通道，但是由于直连通道有较大的丢包率，为了保证通话质量，服务器不对通话通道进行切换。

在一个具体的切换过程中，需要综合所述中转通道的网络状况和所述直连通道的测速情况，通过Jitter模块、Jitter Buffer模块、网络统计模块、Buffer统计模块、策略决策模块获得中转通道丢包率为2.05％，通话200ms上行抖动，下行抖动0.55标准差区间用户数量为100％，上行网络延迟为50ms，总网络延迟为100ms。通过直连通道测速获得的直连通道丢包率为2.15％，通话200ms上行抖动，下行抖动0.55标准差区间用户数量为75％，上行网络延迟为40ms，总网络延迟为80ms。直连通道与中转通道的丢包率接近，且直连通道的网络延时较小，但是由于中转通道的网络抖动较小，具有更好的通话质量，服务器选择不对通话通道进行切换。当然，如果延时过大，例如大于200ms的延时，则会严重影响到通话质量，此时即使网络抖动小，也要对通道进行切换。

在一个具体的切换过程中，需要综合所述中转通道的网络状况和所述直连通道的测速情况，通过Jitter模块、Jitter Buffer模块、网络统计模块、Buffer统计模块、策略决策模块获得中转通道丢包率为3.01％，通话200ms上行抖动，下行抖动0.55标准差区间用户数量为88％，上行网络延迟为90ms，总网络延迟为180ms。通过直连通道测速获得的直连通道丢包率为3.0％，通话200ms上行抖动，下行抖动0.55标准差区间用户数量为90％，上行网络延迟为90ms，总网络延迟为180ms。可见，直连通道与中转通道的网络状况基本相同，此时，服务器引中转通道用户数作为参考，当中转通道用户数量较大时，服务器确定进行切换，以减轻中转通道的网络负担。

如图5所示，在对120余万用户的线上测试过程中，对跨ISP业务的中转通道和直连通道进行测速，A为满足切换条件并切直连通道的用户，B为满足切换条件未切直连通道的用户。两组用户数量分别为674656和67796获得的，测速结果表明，切直连的用户质量并没有因为切换通道影响通话质量，并且由中转通道切到直连通道从而节省了中转通道的带宽。

实施例五：

本实施例提供一种实时通话过程中基于测速的通道切换方法，包括如下步骤：

步骤UD101，第一终端与服务器建立第一通道，所述服务器用于中转第一通道内传输的数据。

步骤SV101，服务器响应第一终端的请求，与所述第一终端之间建立第一通道，并转发客户端之间的数据。

步骤UD102，第一终端与所述第二终端建立第二通道，基于所述第二通道与所述第二终端直接交互数据。

步骤UD103，第一终端将所述第二通道上报所述服务器，并接收所述服务器的测速指令。

步骤SV102，接收所述客户端上报的第二通道信息，并发通道测速命令。

步骤UD104，第一终端基于所述测速指令，进行第二通道测速。

步骤SV103，接收用户反馈的第二通道测速结果。

步骤UD105，第一终端上传所述测速结果。

步骤SV104，服务器根据所述测速结果，决策是否切换通道。

步骤UD101描述实时通话中的基础实现形态，用户终端与服务器建立连接，并通过服务器与第二终端进行数据交互，用户终端与第二终端之间的数据通过服务器中转到达对方。二者之间的数据传输方式通过服务器来中转，二者之间的通道为中转通道。然而，由于互联网运营商出口带宽以及在不同时段出现的网络拥堵等问题，中转通道不仅无法实现高质量通话的要求，甚至会出现丢包严重，甚至无法通话无法连通的问题。

步骤UD102中，用户终端直接与第二终端建立第二通道，基于所述第二通道与所述第二终端直接交互数据。

在具体的实施过程中，可以使用包括但不限于NAT traversal技术(NAT穿越技术)，在不同的私有网络之间建立终端之间的联系，以及基于Peer to Peer技术保持用户终端之间的直接联系。

在步骤UD101和步骤UD102中，用户之间建立了直连通道和中转通道，在通常情况下，中转通道的网络平均网络质量高于直连通道。在此情况下，通话从接通到挂断的过程中可以仅使用中转通道。但是当网络带宽占用多，接口机服务器网络负载高时，网络质量劣化。发明人发现，当网络质量劣化时，中转通道质量未必优于直连通道。此时，使用直连通道进行通话会获得更好通话预期效果。然而，在何时选择将中转通道切换为直连通道是一个需要解决的问题，这也就需要了解中转通道和直连通道的通话质量。

步骤UD103中，客户端将第二通道上报服务器，并接收服务器的测速指令。

建立了直连通道的用户会将自身的通道情况上报给服务器。服务器得知用户的通道信息，根据用户自身的情况，下发通道测速命令，该命令包含了测速包的大小、发包间隔、发包数量、待测速地址等参数信息。

步骤UD104，用户终端收到指挥通道测速的命令后，根据参数，向指定测速地址发送带时间戳的测速包，根据发包和收包的时间计算出网络抖动、丢包率和网络时延等网络质量情况。

在本实施例中，实时通话是指双方或者多方之间进行的音频、音视频通话，图6简明地示出了服务器与客户端之间的数据包交互关系。

第一客户端接收服务器发送的通道预测命令，并返回确认。

第一客户端响应服务器的通道预测命令，向第二客户端发送探测包，并接收探测回包。

第一客户端将测速结果包发送给服务器，并接收服务器发送的测速结果回包。

就服务器侧而言，由于服务器下发通道测速命令、通道测速过程、指挥切换通道是异步的。服务器将建立连接每组客户端视为一个房间，并维护了一个状态来标识每个房间的通道测速情况。如图7所示，服务器包括如下状态：

初始化状态(INIT)：每个房间在初始化时都是INIT状态，当满足音视频通话跨网络服务供应商(ISP)时，进入READY状态，处于待测速状态。

预备状态(READY):表示该房间满足通道测速逻辑条件，当用户上报了直连通道给服务器时，即可触发服务器下发通道测速命令，状态转换为SEND_CMD并记录下发时间戳。

发送等待状态(SEND_CMD)：在该状态下的房间，服务器已经下发了通道测速命令，等待用户上报通道测速结果，同时检测状态是否超时。

接收等待状态(RECV_CMD)：在该状态下的房间，服务器已经收到了用户支持通道测速的命令，等待用户上报通道测速结果，更新状态时间戳，同时检测状态是否超时。

收到测速结果状态(GET_INFO)：服务器收到用户的通道测速结果。

在上述状态中，如果检测到超时或者异常，则进入中断，停止通道测速过程。

在上述过程中，如果在SEND_CMD状态下提前收到通道测速结果，则跳过RECV_CMD状态，直接进入GET_INFO状态。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。