呼叫重新建立的制作方法

专利名称：呼叫重新建立的制作方法
技术领域：
本发明涉及呼叫重新建立。具体来说，本发明涉及重新建立通信网络上的两个用户之间的掉落的呼叫。
背景技术：
通信系统允许在两个或更多用户终端之间通过通信网络进行呼叫。除了通过通信网络在呼叫中的用户之间传送音频数据之外，还可以在呼叫中的用户之间传送视频数据。
呼叫可以是一对一呼叫，这意味着在呼叫中仅仅涉及两个用户。在一对一呼叫中， 可以在呼叫中所涉及的两个用户之间直接传送代表呼叫数据(例如音频数据和视频数据) 的数据流。在一些通信系统中，每一个用户可以向/从通信网络中的中央服务器传送数据和接收数据。中央服务器可以控制呼叫。
或者，呼叫可以是群组呼叫(或“多方”呼叫)，这意味着在呼叫中涉及多于两个用户。在群组呼叫中，其中一个用户可以被指定为群组呼叫的主持者(主持者用户常常是发起群组呼叫的用户)。来自群组呼叫中的每一个用户的音频数据流可以被传送给主持者用户。 主持者用户随后混合这些音频流，并且将混合的音频数据流传送到群组呼叫中的每一个用户，从而使得群组呼叫中的每一个用户接收到来自群组呼叫中的每一个其他用户的音频数据。如果呼叫是群组视频呼叫，为了使得群组呼叫的每一个用户接收到来自群组呼叫中的每一个其他用户的视频数据，每一个用户可以向服务器传送视频数据流，并且服务器随后可以将各个视频流转送到群组呼叫中的每一个用户。服务器(而不是主持者用户)分发视频数据流，以免对通信网络中的主持者用户造成较大带宽负担。视频数据流通常包括比音频数据流更大的数据量。
在一个例子中，通信系统是基于分组的通信系统，其允许例如个人计算机之类的器件的用户通过例如因特网之类的通信网络进行通信。基于分组的通信系统包括互联网协议语音(“VoIP”)通信系统。这些系统有益于用户，因为其成本常常远低于固定线路或移动网络。这种情况对于长距离通信可能尤其如此。为了使用VoIP系统，用户必须在其器件上安装并执行客户端软件。客户端软件提供VoIP连接以及例如注册和认证之类的其他功能。
当建立呼叫时，建立处理涉及在用户之间传送控制信息，以便向呼叫中的(多个) 其他用户认证每一个用户，从而可以允许呼叫继续进行。呼叫可以在会话中进行，其中利用信令信道来传送用于呼叫的控制信号。举例来说，当建立呼叫时，在信令信道上在用户之间传送信令信息。当做出使得呼叫掉落的主动决定时，呼叫可以掉落。这一主动决定可以是基于关于不同类型的故障的阈值。举例来说，如果对于15秒钟没有接收到(例如语音)数据(在呼叫被认为掉落之前的时间长度可以是可配置的)，或者如果在信令信道上的命令递送方面发生超时，则可以认为呼叫掉落。用于确定呼叫掉落的另一个触发可以是接收自低层级网络协议栈的特定信号，比如如果对于信令信道上的信令使用传输控制协议(TCP)，则 OS向客户端通知TCP会话掉落。 为了重新建立呼叫，在其已掉落之后，呼叫中的用户将必须重复建立处理以便重新建立呼叫。掉落的呼叫中的至少其中一个用户可以选择与掉落的呼叫中的其他用户重新建立呼叫。当特定用户确实选择了重新建立掉落的呼叫时，呼叫中的每一个其他用户将接收到来自该特定用户的传入呼叫请求，并且如果其接受呼叫请求，则可以重新建立呼叫。
作为另一个例子，呼叫可能由于以下条件的其中之一为真而被掉落a)在过去的 15秒钟内没有接收到数据流；b)在信令信道上发送了在40秒钟内没有得到确认的命令；或者c)会话的信令信道被掉落。信令信道可以独立于逻辑层上的数据流。但是信令信道不一定独立于网络层上的数据流(例如相同的用户数据报协议(UDP)或传输控制协议(TCP) 连接可以载送数据还有信令命令)。
呼叫可能会频繁地掉落。这种情况对于具有较差网络连接的用户或者在通信网络上有大量数据传输的特定时间尤其如此。当其正在参与的呼叫掉落时，用户可能会感到沮丧。发明内容
根据本发明的第一方面，提供一种应对可由第一用户使用的第一用户终端与可由对应的至少一个其他用户使用的至少一个其他用户终端之间的通过通信网络的呼叫的方法，其中在第一用户终端处执行客户端以便参与呼叫，所述方法包括客户端确定使用在通过通信网络的第一用户终端与至少一个其他用户终端之间的呼叫中的对应的至少一个网络连接的状况；客户端确定呼叫已掉落；响应于确定呼叫已掉落，客户端根据所确定的至少一个网络连接的状况自动尝试重新建立呼叫。
根据本发明的第二方面，提供一种可由用户使用的用户终端，其被配置成应对通过通信网络对可由对应的至少一个其他用户使用的至少一个其他用户终端进行的呼叫，所述用户终端包括处理装置，所述处理装置被配置成执行客户端以便参与呼叫并且从而确定使用在通过通信网络的所述用户终端与至少一个其他用户终端当中的每一个之间的呼叫中的对应的至少一个网络连接的状况；确定呼叫已掉落；响应于确定呼叫已掉落，根据所确定的至少一个网络连接的状况自动尝试重新建立呼叫。
当呼叫掉落时，呼叫中的用户之间的通信会话结束。本发明的发明人认识到，可能有益的是使得在第一用户终端处执行的客户端响应于检测到呼叫掉落而自动尝试重新建立呼叫。这样就不需要第一用户人工地重启呼叫。这样就导致改进了第一用户所感知的呼叫质量，因为呼叫的重新建立对于第一用户是透明的。呼叫中的全部两个用户终端处的客户端都可以尝试自动重新建立呼叫。
此外，针对重新建立呼叫的自动尝试是根据所确定的用在呼叫中的网络连接的状况而施行的。这样，客户端就可以基于用在呼叫中的网络连接上的具体当前状况来确定是否要尝试重新建立呼叫。举例来说，可能确定第一用户终端通过网络连接与另一个用户终端相连，但是网络性能不足以应对呼叫的音频或视频方面。在这种情形中，客户端可以决定终止呼叫从而使得通信会话结束，并且随后客户端可以尝试重新建立呼叫。新近重新建立的网络连接可能具有比先前的网络连接更好的质量，从而在重新建立的呼叫中可以能够通过通信网络传送音频和视频数据流的至少其中之一。在另一个例子中，可能确定第一用户终端通过网络连接与另一个用户终端相连，并且网络性能足以应对呼叫的音频而非视频方面。在这种情形中，客户端可以决定终止呼叫从而使得通信会话 结束，并且随后客户端可以尝试重新建立呼叫。或者，客户端可以决定在仅有呼叫的音频方面的情况下继续。
在一些实施例中，独立于网络质量评估，所有掉落的呼叫的参与者都对于预定时间段(例如60秒)尝试重新建立掉落的呼叫。如果客户端没有在预定时间段内成功地重新建立呼叫，则认为重新建立不成功，并且最终终止呼叫。
可以看到，通过根据在用于呼叫中的网络连接上所确定的状况尝试重新建立呼叫，得到一种更加灵活的系统，其中可以对呼叫的重新建立进行适配从而适应当前网络状况。
客户端可以监测至少一个网络连接以便检测表明所述至少一个网络连接的潜在问题的事件，其中确定对应的至少一个网络连接的状况的步骤是响应于对于表明所述至少一个网络连接的潜在问题的事件的所述检测而发起的。可以向第一用户通知由所检测到的事件所表明的潜在问题。
可以在呼叫掉落之前向第一用户通知连接问题，这样他就将知道在重新建立期间的连接较差。如果用户知晓低性能水平的原因，其常常就更加愿意接受较低性能水平。因此，通过向用户通知在呼叫中使用的网络连接的潜在问题，用户对于呼叫质量就有更好的认识。
呼叫中的每一个用户终端都可以在呼叫掉落时施行尝试重新建立呼叫的步骤。在第一用户与另一个用户之间的一对一呼叫中，第一用户终端上的客户端和另一个用户终端上的客户端都可以尝试重新建立呼叫，因此每一个客户端都将接收传入呼叫请求并且传送传出呼叫请求。在这种情况下,每一个客户端可以应答传入呼叫请求并且将传入呼叫与传出呼叫请求合并，从而重新建立呼叫。
在群组呼叫中，可以在每个用户的基础上施行呼叫重新建立，从而当确定群组呼叫已掉落时，第一用户尝试单独与群组呼叫中的每一个用户重新建立呼叫。
根据本发明的第三方面，提供一种应对通过通信网络的第一用户与至少一个其他用户之间的呼叫的方法，其中在第一用户的用户终端处执行客户端以便参与呼叫，所述方法包括客户端确定呼叫已掉落；响应于确定呼叫已掉落，客户端自动尝试重新建立呼叫。
根据本发明的第四方面，提供一种应对通过通信网络的第一用户终端与至少一个其他用户终端之间的呼叫的方法，其中在第一用户终端处执行客户端以便参与呼叫，所述方法包括客户端确定呼叫已掉落；重新建立第一用户终端与至少一个其他用户终端之间的呼叫；客户端存储在呼叫已掉落之后并且在呼叫被重新建立之前的时间段内接收自第一用户终端的用户的用户输入数据；响应于重新建立呼叫，客户端将所存储的用户输入数据传送到呼叫中的至少一个其他用户终端。
根据本发明的第五方面，提供一种可由用户使用的用户终端，其被配置成应对所述用户终端与可由对应的至少一个其他用户使用的至少一个其他用户终端之间的通过通信网络的呼叫，所述用户终端包括处理装置，所述处理装置被配置成执行客户端以便参与呼叫并且从而确定呼叫已掉落；重新建立第一用户终端与至少一个其他用户终端之间的呼叫；存储在呼叫已掉落之后并且在呼叫被重新建立之前的时间段内接收自用户的用户输入数据；以及响应于呼叫的重新建立，将所存储的用户输入数据传送到呼叫中的至少一个其他用户终端。
本发明的发明人 认识到，可能有益的是记录呼叫被掉落与呼叫被重新建立之间的时间段期间的用户输入数据。所记录的该用户输入数据随后可以在重新建立呼叫时被传送到呼叫中的(多个)其他用户终端。这样就可以把在呼叫掉落期间在第一终端处接收到的用户输入数据包括在重新建立的呼叫中。可以在快于正常用户输入数据的速率下从其他用户终端处的抖动缓冲器中播放在呼叫掉落期间所接收到的用户输入数据，从而解决由于呼叫掉落而导致的接收数据的时间延迟。用户输入数据可以是音频数据或视频数据。
根据本发明的第六方面，提供一种通信网络，其被配置成应对根据本发明的第二或第五方面的用户终端与至少一个其他用户终端之间的通过所述通信网络的呼叫。
这里所使用的术语“自动”意味着“没有用户干预”。


为了更好地理解本发明并且表明如何能够将其付诸实施，下面将通过举例的方式参照附图，其中图1示出了根据一个优选实施例的通信网络；图2示出了根据一个优选实施例的用户终端的示意图；图3示出了根据一个优选实施例的第一用户终端的功能方框图；图4示出了根据一个优选实施例的第二用户终端的功能方框图；图5是根据一个优选实施例的在客户端检测到问题时向第一用户显示的用户接口的表不;图6是根据一个优选实施例的在客户端尝试重新建立呼叫时向第一用户显示的用户接口的表示；图7是根据一个优选实施例的在客户端没有成功地重新建立呼叫时向第一用户显示的用户接口的表示；图8是根据一个优选实施例的用于检测表明网络连接的潜在问题的事件的处理的流程图；图9是根据一个优选实施例的用于施行连接性测试的处理的流程图；图10是根据一个优选实施例的用于重新建立掉落的呼叫的处理的流程图；图11是根据一个优选实施例的用于在用户终端处于后呼叫状态时施行的处理的流程图；以及图12示出了根据优选实施例的用于传送用户输入数据的处理的流程图。
具体实施方式
下面将仅仅通过举例的方式来描述本发明的优选实施例。本领域技术人员将认识到，本发明不限于下面所描述的优选实施例的具体特征。在不背离本领域技术人员将认识到的本发明的范围的情况下，可以对下面描述的优选实施例做出多种修改。
首先参照图1，该图示出了一个优选实施例的基于分组的P2P通信系统100。通信系统的第一用户(用户A 102)操作用户终端104，其被示出为连接到通信网络106。通信网络100例如可以是因特网。用户终端104例如可以是移动电话、个人数字助理(“PDA”)、个人计 算机(“PC”)(其中例如包括Windows 、Mac OS 和Linux PC)、游戏器件或者能够连接到网络106的其他嵌入式器 件。用户器件104被设置成从/向器件的用户102接收及输出信息。在一个优选实施例中，用户器件104包括例如屏幕之类的显示器，以及例如小键盘、操纵杆、触摸屏、键盘、鼠标、麦克风和/或摄像头之类的输入器件。如图1中所示，用户器件104连接到网络106。
注意在替换实施例中，用户终端104可以经由图1中未示出的附加中间网络连接到通信网络106。举例来说，如果用户终端104是移动器件，则其能够经由例如GSM或UMTS 网络之类的蜂窝移动网络(图1中未示出)连接到通信网络106。
用户终端104运行通信客户端108，其由与通信系统100相关联的软件提供商提供。通信客户端108是在用户终端104中的本地处理器上执行的软件程序，其允许用户终端104通过网络106从事呼叫。
图1还示出了第二用户110 (用户B)，其具有执行客户端114的用户终端112以便通过网络106进行通信，其方式与用户终端104执行客户端108以便通过网络106进行通信相同。类似地，图1还示出了第三用户116 (用户C)，其具有执行客户端120的用户终端118以便通过网络106进行通信，其方式与用户终端104执行客户端108以便通过网络 106进行通信相同。因此，图1中示出的通信系统100中的三个用户可以通过通信网络106 彼此通信。可以有更多用户连接到通信网络106，但是为了清楚起见，在图1中仅仅示出了三个用户102、110和116连接到网络106。
图2示出了其上执行客户端108的用户终端104的详细视图。用户终端104包括中央处理单元(“CPU”)202，与之相连的有例如屏幕之类的显示器204、例如小键盘(或键盘) 206之类的输入器件、例如操纵杆(或鼠标)208之类的指示器件以及用于捕获视频数据的摄像头225。显示器204可以包括触摸屏以用于向CPU 202输入数据。输出音频器件210(例如扬声器)和输入音频器件212 (例如麦克风)连接到CPU 202。显示器204、小键盘206、操纵杆208、网络摄像头225、输出音频器件210和输入音频器件212被集成到用户终端104 中。在替换的用户终端中，显示器204、小键盘206、操纵杆208、网络摄像头225、输出音频器件210和输入音频器件212当中的一项或更多项可以不被集成到用户终端104中，而是可以经由对应的接口连接到CPU 202。这样的接口的一个例子是USB接口。CPU 202连接到例如调制解调器之类的网络接口 226以便与通信网络106进行通信，从而通过通信系统 100进行通信。网络接口 226可以被集成到用户终端104中，正如图2中所示出的那样。在替换的用户终端中，网 络接口 226不被集成到用户终端104中。
图2还示出了在CPU 202上执行的操作系统(“0S”)214。在OS 214之上运行的是用于客户端的软件栈216。所述软件栈示出了的客户端协议层218、客户端引擎层220和客户端用户接口层(“Π”)222。每一层负责特定的功能。由于每一层通常与其他两层通信， 因此其被视为设置在如图2中所示的栈中。操作系统214管理计算机的硬件资源，并且应对经由网络接口 226向/从网络传送的数据。客户端软件的客户端协议层218与操作系统 214进行通信，并且管理通信系统100上的连接。需要更高层级处理的处理被传递到客户端引擎层220。客户端引擎220还与客户端用户接口层222进行通信。客户端引擎220可以被设置成控制客户端用户接口层222，以便经由客户端的用户接口向用户呈现信息以及经由用户接口从用户处接收信息。
图3是用户终端104的表示，其中示出了当用户终端104接收用户输入数据以用在通过通信网络106的呼叫中时的用户终端104中的各个功能方框。所接收到的用户输入数据例如可以是在用户终端104处从用户102接收到的语音数据或视频数据。利用图3 中示出的各个功能方框对用户输入数据进行处理，从而可以通过通信网络106对其进行传送。
用户终端104包括用户输入器件302 (比如麦克风212)、模拟到数字转换器方框 304、编码器方框206、分组化器方框308、输出缓冲器310和网络接口 226。用户输入器件 302被设置成从用户102接收输入数据。用户输入器件302的输出耦接到模拟到数字转换器方框304的输入。模拟到数字转换器方框的输出耦接到编码器方框306的输入。编码器方框306的输出耦接到分组化器方框308的输入。分组化器方框308的输出耦接到输出缓冲器310的输入。输出缓冲器310的输出耦接到网络接口 226的输入。网络接口 226被设置成将数据传送到通信网络106。用户终端112和118也可以包括用于通过通信网络106 传送数据的等效功能方框。图3中示出的方框304到308可以被实现为终端104中的硬件， 或者运行在用户终端104中的CPU 202上的软件。这是一种实现方式优选项。
在发起呼叫之后，来自用户102的输入数据被输入到用户输入器件302，例如语音数据被输入到麦克风212中。模拟到数字转换器方框304被设置成将输入语音信号转换成数字信号。来自模拟到数字转换器方框304输出的数字信号输出被输入到编码器方框306 中。编码器方框306对信号进行编码。编码器方框306被设置成将已编码数据(其例如被设置成各帧)输出到分组化器方框308。分组化器方框308将已编码数据帧插入到数据分组中。数据分组可以包括报头部分和有效载荷部分，正如本领域内已知的那样。数据分组随后在输出缓冲器310中被排队以供传送，并且经由网络接口 226被从用户终端104通过网络106例如传送到用户终端112。所传送的数据分组构成数据流。
图4是用户终端112的表示，其中示出了当用户终端112从网络106接收呼叫数据时的用户终端112中的各个功能方框。所接收到的数据例如可以是从用户终端104通过通信网络106传送的分组化音频或视频数据。所接收到的数据分组构成数据流，利用图4 中所示的功能方框对其进行处理，从而可以将其输出给用户终端112的用户110。
用户终端112包括网络接口 402、抖动缓冲器404、去分组化器方框406、解码器方框408、数字到模拟转换器方框410和输出器件412，其在数据是音频数据的情况下例如是扬声器，或者在数据是视频数据的情况下是屏幕。网络接口被设置成从网络106接收数据流。网络接口 402的输出耦接到抖动缓冲器404的输入。抖动缓冲器404的输出耦接到去分组化器方框406的输入。去分组化器方框406的输出耦接到解码器方框408的输入。解码器方框408的输出耦接到数字到模拟转换器方框410的输入。数字到模拟转换器方框410 的输出耦接到输出器件412的输入。输出器件412被设置成将数据输出给用户110。举例来说，输出器件412可以是输出音频数据的扬声器，或者输出器件可以是输出视频数据的屏幕。用户终端104和118也可以包括用于通过通信网络10 6接收数据的等效功能方框。
图4中所示的方框406到410可以被实现为终端112中的硬件，或者运行在用户终端112中的CPU上的软件。这是一种实现方式优选项。
在网络接口 402处从网络106接收到数据分组，并且将数据分组传递到抖动缓冲器404，在输出到去分组化器方框406之前的一段时间内在该处对数据分组进行排队。可以对从抖动缓冲器404输出数据分组的输出速率进行控制，从而控制所接收到的数据的输出速率。这可以特别有用于平滑由于通过网络106传送的数据流的不同数据分组要花费不同时间量而在所接收到的数据流中造成的抖动。去分组化器方框406被设置成从数据分组的有效载荷中去除已编码帧。随后从去分组化器方框406输出已编码帧，并且将其输入到解码器方框408。解码器方框408被设置成对已编码帧进行解码，并且输出数字信号。随后通过数字到模拟转换器方框410将数字信号转换成模拟信号，并且通过输出器件412输出给用户。
因此可以看到，利用图3和4中示出的各个功能方框，用户终端104、112和118可以通过通信网络106从事呼叫。
这里所描述的方法旨在改进呼叫掉落时的用户体验。优选实施例有三个总体目的I)第一个目的是为用户提供关于呼叫的问题的早期通知。举例来说，如果呼叫正在进行，但是在呼叫中所使用的数据流中已经有了四秒钟的间隙，则可能有益的是向用户通知所述间隙，否则用户在呼叫实际被终止之前可能不会意识到呼叫存在问题(例如在音频呼叫中，用户可能不一定会注意到数据流中的间隙)。作为另一个例子，在可用带宽低于继续呼叫所需要的最小带宽的情况下，向用户通知带宽问题。在这种情况下，客户端也可能向用户提供帮助，比如建议用户关断呼叫的视频方面从而保留足够的带宽以便在仅有音频的基础上继续呼叫。如果客户端检测到用户终端利用Wifi连接与网络相连并且wifi连接上的 wif i信号较弱，则也可能提供帮助。在这种情况下，客户端可能建议用户找到更好的覆盖或者切换到线缆连接。
2)第二个目的在于，一旦呼叫掉落，向用户提供关于在何处发生了使得呼叫掉落的问题的信息。举例来说，客户端可以通知用户(例如利用对话框或可听通知)“您已离线”， 或者“对方用户已离线”。
3)第三个目的是重新建立掉落的呼叫。在不需要任何用户干预的情况下自动重新建立呼叫。
为了提供早期问题通知，使用一个触发点(“或触发事件”)集合。触发点例如可以是数据流上的四秒间隙(所述数据流可以是从用户终端传送或接收)，或者在预定义的时间量内没有在呼叫中所使用的信令信道上接收到命令的确认。一旦检测到触发点，就向用户显示消息从而向其通知关于导致触发点的问题，但是并不实际上指明发生问题的位置(例如是用户端还是呼叫远端的连接问题)。此时，客户端开始一系列连接性测试。进行连接性测试的原因是为了找到导致问题的点。作为连接性测试的一部分，客户端探通(Ping)用户自身的超级节点(位于用户本地的网络中的第三方节点)以便确定其是否具有基本因特网连接性，如果是的话，则客户端在独立于流的信道上探通呼叫中的远程用户以便确定远程用户是否具有基本因特网连接性。根据连接性测试的结果，客户端可以更新对应于呼叫中的本地和远程用户的存在状态。连接性测试是与重新建立阶段分开的一个阶段。当确定呼叫已掉落时，发起重新建立阶段。
如果在满足呼叫掉落标准之前呼叫没有自行恢复，则客户端掉落呼叫并且进入呼叫恢复模式(即重新建立阶段)。将向用户通知恢复模式，并且将为其提供关于呼叫为何被掉落的信息，例如客户端可以向用户通知“您已离线”或者“远程用户已离线”，或者可以在不知道呼叫掉落的确切原因的情况下显示一则一般性错误消息。在呼叫恢复模式下，客户端对于一段预定义时间(例如60秒)尝试 重新建立呼叫。不管哪一个用户是呼叫的发起者，呼叫中的全部两方都尝试呼叫恢复。
如果恢复不成功(即在预定义时间(例如60秒)内无法重新建立呼叫)，则终止呼叫，并且客户端进入后呼叫状态，在该状态下，如果知道的话则向用户显示呼叫掉落的原因。
现在将更加详细地描述所述方法的每一个阶段。这里所描述的方法可以被实现在一对一呼叫或多方呼叫中，其可以是音频或视频呼叫。在通信系统100中的用户(例如用户 102、110和116)之间的呼叫期间施行所述方法。在优选实施例中，用于重新建立掉落的呼叫的方法包括三个阶段(i)性能触发阶段；(ii)连接性测试阶段；以及(iii)恢复阶段。 下面将依次讨论每一个阶段I)性能触发阶段在性能触发阶段中，在掉落呼叫之前向用户告警已经检测到问题。此外，在性能触发阶段中确定需要何时实施连接性测试。
在呼叫期间，用户终端104的客户端108的呼叫管理器模块将监测用在呼叫中的网络连接，以便检测任何以下事件1、呼叫中数据流的丢失。当对于预定时间段没有通过网络106传送或接收数据流(例如音频或视频数据流)时，可以检测到数据流的丢失。所述预定时间段例如可以是四秒钟。 应当提到的是，该预定时间段被设定成小于一个时间段，其中呼叫在该时间段后掉落，下面将对此进行描述。
2、用在呼叫中的信令信道上的故障。举例来说，如果在预定时间段(例如十秒)内在呼叫的近端(例如用户终端104)处没有接收到来自呼叫的远端(例如用户终端112)的信号命令的确认。信令信道在逻辑层可以独立于数据流。但是信令信道在网络层不一定独立于数据流(例如相同的UDP或TCP连接可以载送数据和信令命令)。信号命令的确认可以独立于流丢失。信令信道上的故障的另一个例子是当被用于其中正运行呼叫的会话中的信令的TCP连接或UDP连接被掉落时的情况。还可以检测用在呼叫中的信令信道上的其他类型的故障。
3、用在呼叫中的网络连接上的可用带宽的量可能落到预定阈值带宽以下。用户终端104处的带宽管理器可以监测用在呼叫中的网络连接上的带宽，并且向客户端108报告用在呼叫中的网络信道上的可用带宽，从而使得客户端可以确定可用带宽是否已落到阈值带宽以下。
对于呼叫中的每一个参与者(即对于呼叫中的每一个用户102、110和116)将独立地监测前面描述的事件(或“触发”)。可以通过向客户端108传送更新消息来远程地更新被用来定义可接受的呼叫可以操作在其中的性能包络的参数值。所述参数值例如是在将其检测为触发事件之前所能丢失数据流的时间段，在将其检测为触发事件之前可以未接收到确认的时间段，以及前面描述的预定阈值带宽。通过改变这些参数，可以调节客户端108将负面状况检测为触发(即表明较差网络性能的事件)的敏感度。
一旦检测到性能触发，就可以向受到影响的用户(例如用户102)通知导致检测到触发的潜在问题。举例来说，客户端108可以经由显示在用户终端 104的显示器204上的对话框向用户102通知所述问题。图5示出了在显示器204上向用户102显示的客户端108 的用户接口 502的一个例子。图5示出了当用户102通过网络106与用户110进行一对一呼叫时所显示的示例用户接口 502。用户接口 502在窗格504中示出了接收自用户112的视频数据。当检测到用户终端104与用户终端112之间通过网络106的网络连接的问题时，在用户接口 502中显示对话框506。图5示出了对话框506，其向用户通知呼叫存在问题，并且在Skype尝试解决该问题的同时要求用户102不要挂断。在用户接口 502的右下方角落示出了网络呼叫质量指标508，其可以向用户通知用在呼叫中的网络连接存在问题。在图5所示的例子中，网络呼叫质量指标508表明网络呼叫质量处于四个级别当中的第一级，从而向用户102表明用在呼叫中的网络连接存在问题。除了在用户接口 502上显示关于所检测到的网络问题的通知之外，还可以例如利用用户终端104的扬声器210向用户102输出可听通知。通过向用户102通知客户端108已经检测到网络上的潜在问题，使得用户102针对呼叫质量的下降做好准备。这样可以在呼叫确实掉落或者呼叫质量确实下落到不可接受的水平的情况下减轻对于用户102所导致的沮丧感。由于在性能触发阶段中检测到的事件是表明网络上的问题的事件而不是导致呼叫掉落的事件，因此前面描述的向用户102通知网络上的问题是在呼叫掉落之前发生的。就允许用户102针对即将发生的呼叫掉落做好准备。图8示出了根据一个优选实施例的用于检测表明网络连接的潜在问题的事件的处理的流程图。所述处理开始于步骤S802，其中呼叫正在进行。与前面描述的例子中一样，呼叫可以是通过网络106进行的用户102与110之间的一对一视频呼叫。在步骤S804中，确定呼叫是否已被终止。如果呼叫已被终止，则图8中所示的处理在步骤S806中结束。但是如果呼叫尚未被终止，则所述方法继续到步骤S808，其中确定用在呼叫中的数据流是否已经丢失了至少四秒。如前所述，如果数据流已经丢失了至少四秒，则将其检测为表明网络上的问题的事件，并且应当向用户102通知。但是如果用在呼叫中的数据流还没有丢失至少四秒，则所述方法继续到步骤S810，其中确定TCP连接上是否发生了故障。在步骤S810中，还可能确定用在呼叫中的 任何其他信令信道上(例如UDP连接上)是否发生了故障。如果在独立于流的信令信道上没有这样的故障，则确定用在呼叫中的网络连接没有应当向用户102通知的问题，，从而所述方法回到步骤S802并且呼叫继续。但是如果在步骤S808中确定数据流已经丢失了至少四秒，或者如果在步骤S810中确定在独立于流的信令信道上发生了故障，则所述方法继续到步骤S812，其中将客户端108的用户接口 502中所示的网络呼叫质量指标508改变为指示一个红格。这样就向用户102通知了呼叫的潜在问题。随后在步骤S814中，客户端108将所述事件(即流故障超过四秒或者独立于流的信令信道上的故障)检测为性能触发，随后在步骤S816中可以进一步向用户102通知潜在问题。该进一步通知可以是如前所描述的音频和/或视觉通知。可以利用如前所述的对话框506提供视觉通知，并且可以利用如前所述的用户终端104的扬声器210提供音频通知。由于在步骤S814中已经检测到性能触发，因此在步骤S818中所述方法将继续到连接性测试阶段，后面将对此进行更加详细的描述。具体来说，所述方法可以继续到图9中所示的步骤S902，后面将对此进行更加详细的描述。2)连接性测试阶段
在连接性测试阶段期间，客户端108的连接性测试模块诊断已经通过性能触发检测到的网络连接的问题。连接性测试的结果被输出给用户102。该信息向用户通知所述问题，并且允许用户在可能的情况下采取校正行动。当检测到至少一个触发时，用于每一个受影响参与者的客户端的连接性测试模块都将诊断因特网连接。举例来说，客户端108的连接性测试模块将首先通过向网络106中的本地第三方节点发送一则消息来检查用户终端104的本地连接。这样，用户终端104就检查其是否可以连接到网络106。为了施行这一检查，用户终端104向本地第三方节点(其例如可以是在网络106处在用户终端104本地的网络106中的超级节点或服务器)发送探测信号(例如TCP和/或UDP信号)。如果在给定时限内响应于向本地第三方节点传送探测信号而接收到探测确认信号，则客户端108得出的结论是用户终端可以连接到网络106。举例来说，客户端108可以确认其具有(至少基本的)因特网连接性，并且可以确定其对于哪种协议具有连接性(例如对于TCP和/或UDP)。如果在给定时限内没有接收到探测确认信号，则客户端108确定其无法连接到网络106，并且这是通过触发检测到的问题的成因。当确定其没有连接到网络106时，可以相应地更新网络106中的用户102的存在状态(例如可以把用户的存在状态设定为离线)。如果呼叫随后进入将在后面更加详细地描述的重新建立阶段，则可以向用户102通知呼叫处于重新建立阶段，这是因为用户终端104不具有互联网连接性。此外，根据探测信号往返于本地第三方节点的往返时间(RTT)，客户端108可以得到关于用户终端104所具有的与网络106的网络连接的质量的指示。举例来说，如果探测信号的RTT〈1000ms，则可以确定用户终端104与网络106的连接为OK (良好)，如果探测信号的RTT处于1000到2000ms之间，则可以确定用户终端104到网络106的连接为POOR(较差)，并且如果探测信号的RTT>2000ms，则可以确定用户终端104到网络106的连接为CRITICAL (临界)。关于用户终端104与网络106之间的网络连接的质量的指示可以被用于向用户102通知网络问题的成因。客户端108的连接性测试模块随后将通过经由单独的信道向用户终端112传送消息来测试呼叫远端的连接性(例如用户终端112的连接)。这样，客户端108可以确定呼叫的问题是否由另一个用户终端(例如用户终端112)与网络106的网络连接造成。可以按照前面对于本地连接性测试所描述的相同方式来施行该测试。换句话说，如果客户端108确定其可以连接到网络106而没有任何问题，则客户端108可以向另一个用户终端112发送探测信号。如果在给定时限内没有返回探测确认信号，则客户端108可以确定该另一个用户终端(例如用户终端112)在连接到网络106方面存在问题。在这种情况下，对用户110的存在状态进行更新(例如将其设定到离线)，以便反映出用户终端112连接到网络106的问题。如果呼叫随后进入将在后面更加详细地描述的重新建立阶段，则可以向用户102通知呼叫处于重新建立阶段，因为另一个用户110似乎是离线的。如果群组呼叫的主持者决定在连接性测试阶段期间终止呼叫(而不管其是否被测试)，则所述处理将完全停止并且呼叫将被终止。但是如果呼叫中的另一个用户尝试在连接性测试阶段期间终止呼叫，则主持者用户仍然可以尝试重新建立到该用户以及到群组呼叫中的每一个其他用户的呼叫。 应当认识到，主持者将尝试单独地重新建立与群组呼叫中的每一个呼叫参与者的连接。如果用户终端104无法连接到网络106，则客户端108将只能够报告关于用户102的状态，而无法关于呼叫中的其他参与者的连接性状态进行报告。换句话说，当用户终端104无法连接到网络106时，客户端108无法确定呼叫中的其他用户的连接性状态。如果可以与呼叫中的至少一个其他用户继续进行呼叫，则连接性测试将被认为是成功的。举例来说，如果呼叫是一对一呼叫，则如果可以实现呼叫的两个参与者之间的低层连接，则认为连接性测试是成功的。在另一个例子中，如果呼叫是群组呼叫，并且可以在用户终端104与原始群组呼叫中的至少一个其他用户终端之间实现底层连接，则客户端108将确定连接性测试是成功的。如果只能在用户终端104与一个其他用户终端(例如用户终端112 )之间实现连接，则先前的群组呼叫可以被恢复成一对一呼叫。这表明在群组呼叫中，与群组呼叫中的每一个其他用户的网络连接的连接性被单独地测试。如果 连接性测试是成功的并且呼叫已被掉落，则客户端108将尝试通过任何可能的技术手段来重新建立呼叫，如后面描述的恢复模式的一部分。当呼叫被成功地重新建立时，用户110的先前可用性状态将被复原。举例来说，如果用户112在呼叫期间被设定为“离开”并且随后在用户终端112的网络连接性故障期间被改变到“离线”，则在成功地重新建立呼叫时所述状态将被回复到“离开”。当重新建立呼叫时，将对于呼叫中的所有用户重新评估网络呼叫质量指标508并且相应地更新。在连接性测试结束时，对于呼叫中的每一个用户更新其在通信网络中的存在状态。呼叫中的每一个参与者用户将处于四种可能状态的其中之一1、状态#1——用户与呼叫中的至少一个其他参与者连接，并且它们的网络性能令人满意。在这种情况下，连接性测试被认为是成功的，并且用在呼叫中的网络连接上的可用带宽(其由带宽管理器决定)高于针对在呼叫中同时可接受地传送音频和视频数据流所需要的预定上限阈值。2、状态#2——用户与呼叫中的至少一个其他参与者连接，但是它们的网络性能太差以至于无法应对呼叫的所有方面。状态#2被划分成两个子类别
状态#2a——网络性能太差以至于无法继续呼叫的视频方面，但是呼叫的音频方面能够继续。在这种情况下，连接性测试是成功的，并且用在呼叫中的网络连接上的可用带宽低于针对可接受地传送视频数据流所需要的上限阈值，但是高于针对传送音频数据流所需要的下限阈值。状态#2b—网络性能太差以至于完全无法继续呼叫，在这种情况下，连接性测试是成功的，但是带宽低于下限阈值，从而在呼叫中既无法以可接受的带宽传送视频数据流也无法以可接受的带宽传送音频数据流。3、状态#3——用户终端104无法连接到网络106。换句话说，本地网络连接不可用。在这一状态下，客户端108不获取关于呼叫中的其他参与者的连接性的任何信息。4、状态#4——用户终端104连接到网络106，也就是说用户终端104具有本地连接，但是呼叫中的其他参与者没有连接到网络106。客户端108所能获得的关于呼叫中的远程用户的连接性状态的细节将受到可用数据的精确性的限制，并且将与可用的网络信息一样精确。如前所述，呼叫中的每一个用户可以施行连接性测试，从而使得每一个用户确定其所处的状态。如果呼叫中的所有参与者都处于状态#1，则呼叫返回到正常，并且所有恢复UI元件都将消失。在这种情况下，呼叫没有问题，并且呼叫不被掉落。如果呼叫中的任何参与者处于状态#2a，则就受到影响的那些用户而言，将向其通知呼叫可以在只有音频的基础上继续，并且呼叫的视频方面将被停止以便允许呼叫在只有音频的基础上继续进行。呼叫中的处于状态#1的其他参与者可以同时继续呼叫的视频和
音频方面。可以向处于状态#2a下的用户提供在只有音频的基础上继续呼叫或者尝试重新建立呼叫的视频方面或终止呼叫的选项。这些选项可以经由用户终端的显示器上的对话框提供。如果用户决定在只有音频的基础上继续呼叫，则可能不需要完全的重新建立的处理(即终止并重拨)，并且客户端可以在呼叫继续的同时返回问题前触发阶段。如果任何参与者处于状态#2b，则将对呼叫中的各个参与者的状态进行更新。如果呼叫由于网络上的可用带宽较低而掉落，则将作为后面更加详细地描述的恢复阶段的一部分重新建立呼叫。

如果任何参与者处于状态#3或#4，则可以重复连接性测试。对于连接性尝试的次数将没有限制，但是将会有测试要进行的最大时间(最大时限将是可配置的参数)。如果连接性测试在最大时间段之后不成功，则在本发明的一个实施例中，所述处理将前进到后呼叫阶段(后面描述)。在本发明的一个替换实施例中，客户端108将确定呼叫是否已由于连接性问题而掉落，如果是的话，则将尝试重新建立呼叫而不是继续到后呼叫阶段。将分别对于每一个呼叫参与者全部在客户端侧施行连接性测试。图9是根据一个优选实施例的用于施行连接性测试的处理的流程图，其对前面关于连接性测试阶段的描述做了概括。图9的方法开始于步骤S902，该步骤从如前所述的图8的触发检测方法继续。所述方法继续到步骤S904，其中如前所述地施行连接性测试，从而客户端108确定呼叫中的每一个用户连接到网络106的程度。在步骤S906中，对呼叫中的用户的存在状态进行更新，以便反映出在步骤S904中施行的连接性测试的结果。通过更新呼叫中的用户的存在状态，向用户102通知呼叫中的每一个用户的连接性状态。应当提到的是，如果用户终端104无法连接到网络106，则客户端108无法确定呼叫中的其他用户的存在状态，正如前面所描述的那样。所述方法随后继续到步骤S908，其中确定是否已经达到了针对施行连接性测试的时限。如果已经达到该时限，则所述方法继续到步骤S910，其中处理继续到将在后面更加详细地描述的后呼叫状态。但是如果在步骤S908中确定还没有达到时限，则所述方法继续到步骤S912，其中确定用户终端104是否处于状态#1。如果确定用户终端104处于状态#1，则所述方法继续到步骤S914，其中由于用户终端104已连接并且具有足以参与呼叫的所有方面的带宽，从而呼叫继续。随后在步骤S916中，确定呼叫中的任何其他参与者是否受到连接性测试，如果是的话则所述方法回到步骤S904以便施行进一步的连接性测试。但是如果呼叫中的其他参与者没有受到连接性测试，则呼叫继续，并且在步骤S918中，所述方法返回图8中所示的步骤S802以便检测任何后续的触发事件。回到步骤S912，如果确定用户终端104不处于状态#1，则所述方法继续到步骤S920,其中确定用户终端104是否处于状态#2a。如果用户终端104处于状态#2a’则在步骤S922中向用户通知呼叫状态以及呼叫只能在只有音频的呼叫的基础上继续。可以向用户给出继续只有音频的呼叫、终止呼叫或者尝试重新建立呼叫的所有方面的选项。在图9所示的例子中，所述方法通过在只有音频的基础上恢复呼叫而在步骤S924中继续进行，并且在步骤S926中，所述方法回到图8中所示的步骤S802以便检测任何后续的触发事件。
回到步骤S920，如果确定用户终端104不处于状态#2a，则所述方法继续到步骤S928，其中确定用户终端104是否处于状态#2b。如果用户终端104处于状态#2b，则所述方法继续到步骤S930，其中向用户102通知呼叫状态，也就是说用户终端104连接到网络106，但是网络性能太差以至于无法继续呼叫(不管是作为视频呼叫还是音频呼叫)。随后在步骤S934中呼叫继续，直到发生了使得呼叫掉落的状况为止。回到步骤S928，如果确定用户终端不处于状态#2b，则所述方法继续到步骤S936，其中确定用户终端104是否处于状态#3。如果用户终端104处于状态#3，则所述方法继续到步骤S940，其中重复连接性测试，从而方法回到步骤S906。但是如果在步骤S936中确定用户终端104不处于状态#3，则所述方法继续到步骤S938，其中确定用户终端是否处于状态#4。如果确定用户终端104处于状态#4,则所述方法继续到步骤S940，从而重复连接性测试。重复连接性测试的这一循环将继续到用在步骤S908中的时限到期或者在连接性测试中确定用户终端104不再处于状态#3或#4为止。如果在步骤S938中确定用户终端104不处于状态#4，则所述方法如前所述地继续到步骤S930，从而向用户通知用户终端处于状态#4，并且在步骤S934中，呼叫继续到发生了使得呼叫掉落的状况为止，正如后面将更加详细地描述的那样。3)恢复阶段(或“重新建立阶段”)
呼叫的重新建立涉及终止当前呼叫(如果其还没有被终止的话)以及随后发起与掉落的呼叫的参与者的新的呼叫。在本文献中提到掉落呼叫时是指使得呼叫掉落的主动决定。通过终止呼叫，客户端掉落呼叫，从而可以再度重新建立呼叫。在下列情况下会发生呼叫的终止(即使得呼叫“掉落”):1、当数据流丢失(在任一方向上)的时间段超出预定时间段(例如15秒)时，则呼叫管理器将终止呼叫。数据流可 以是视频数据流或音频数据流。当数据流丢失超过15秒时，客户端108终止呼叫从而可以重新建立呼叫，而不再等待数据流的传送恢复。应当提到的是，性能触发使用四秒的时间段，即该时间段小于在其后确定呼叫将要掉落的时间段。2、当在例如20-40秒的预定时间段内没有从呼叫的远端确认信令信道上的命令时，呼叫将掉落。这种情况可以独立于流丢失。其可能在没有流丢失的情况下发生，或者与流丢失同时发生(在这种情况下流丢失超时将通常首先发生，从而导致呼叫被掉落)。如果呼叫被掉落，则呼叫管理器将通过自动请求呼叫中的用户之间的新连接来尝试重新建立呼叫。在本发明的一个实施例中，呼叫管理器将尝试重新建立所有掉落的呼叫。在本发明的一个替换实施例中，只有在用户终端104处于状态#2b的情况下，呼叫管理器才仅将尝试重新建立呼叫。图6示出了当发生呼叫的重新建立时，客户端108的用户接口 602的外观的表示。用户接口 602具有示出了从呼叫中的远程用户最后接收到的视频数据的窗格604，以及向用户102通知客户端108正在试图修复网络问题的对话框606。通过向用户102通知存在问题以及客户端108正在尝试修复该问题，与其中简单地掉落呼叫的情况相t匕，用户对于呼叫质量的感知得到改进。用户接口 602还示出了网络呼叫质量指标608，其表明当前在呼叫中的用户之间没有连接性。在呼叫中的近端和远端客户端(例如客户端108和114)都处于重新建立阶段的情况下，远端客户端和近端客户端都将尝试重新建立呼叫。因此，每一个客户端都将接收传入呼叫请求并且传送传出呼叫请求。在这种情况下，每一个客户端都将应答传入呼叫请求，并且将传入呼叫与传出呼叫请求合并以便重新建立呼叫。有利的是，呼叫重新建立自动发生(即没有用户干预)。此外，在呼叫重新建立阶段期间，所述处理本身对于用户将是不可见的。在可能的情况下，将向呼叫中的每一个用户通知影响了其他呼叫参与者的问题(例如通过在客户端108的用户接口上的对话框中显示“用户X未连接”)。在成功地重新建立掉落的呼叫之后，重新建立的呼叫中的用户终端可以处于状态#1，在这种情况下呼叫将继续到检测出另一个性能触发事件为止。除了通过终止呼叫之外，用户将不能取消呼叫重新建立的发起。对于重新建立呼叫，将有X秒的时限(其中X的默认值可以是45，但其是系统的一个可配置参数)。如果在该时限内没有重新建立呼叫，则所述处理将前进到后面所描述的后呼叫状态。如果呼叫重新建立成功，则呼叫参与者将不需要采取任何进一步的行动，并且呼叫可以继续。这就使得所述方法特别有利，因为完全不需要用户施行任何行动，并且如果呼叫重新建立处理成功则呼叫可以继续。对于未被设置成自动应答重新建立呼叫设立请求的老版本的客户端，这些版本的客户端将作为新的传入呼叫而经历重新建立。类似地，针对陆线的重新建立呼叫设立请求将被视为新的传入呼叫。这样即使在呼叫中的一些用户终端实施可能不知晓由客户端108实施的重新建立处理的早前的或不同的技术时，也允许施行所述重新建立方法。如果某一参与者在发起重新建立处理期间失败，则将对于该参与者停止重新建立处理，并且所述处理将前进到后呼叫状态。

如果针对通过通信网络106重新建立呼叫的尝试失败，则客户端108可以继续尝试通过不同的通信网络与用户112建立连接。举例来说，在本发明的一个实施例中，通信系统100是Skype通信系统，并且通信网络106是因特网。如果针对通过Skype系统100重新建立呼叫的尝试失败，则可以使用用户简档中的非Skype号码来重新建立呼叫。非skype号码例如可以是PSTN号码或移动通信系统中的号码。在本发明的一个实施例中，如果重新建立先前是视频呼叫的呼叫，则将其重新建立为音频呼叫。这可以取决于可用来进行视频呼叫的带宽是否有限(例如如果在连接性测试之后确定用户终端处于状态#2b的话)。在重新建立之后，用户将在其希望的情况下自由地将呼叫人工转换回视频呼叫。图10是用于重新建立掉落的呼叫的处理的流程图。图10中所示出的重新建立处理开始于步骤S1002，其中确定已经发生了使得呼叫“掉落”的状况。所述方法继续到步骤S1004，其中确定是否呼叫中的任何用户已挂断，即终止其在呼叫中的参与。如果呼叫中没有用户挂断，则所述方法继续到步骤S1010。但是如果呼叫中的一些用户已挂断，则所述方法继续到步骤S1006，其中确定在呼叫中是否仍留有足够的用户以重新建立呼叫。如果在呼叫中没有留有足够的用户以重新建立呼叫，则所述方法继续到步骤S1008，其中呼叫被终止，并且所述方法继续到在图11中示出并且将在后面更加详细地描述的步骤S1102。但是如果在步骤S1006中确定在呼叫中留有足够的用户以重新建立呼叫，则所述方法继续到步骤 SlOlOo在步骤S1010中，客户端108呼叫仍留在呼叫中的用户。在步骤S1012中，客户端108确定呼叫是否成功。当呼叫成功时，则建立到至少一个其他用户的呼叫。如果呼叫成功，则所述方法继续到步骤S1014，其中向呼叫中的用户通知成功的呼叫状态，以及在步骤1016中呼叫继续，并且所述方法回到图8中所示的步骤S802，从而客户端108监测用在呼叫中的网络连接以便检测任何后续的性能触发事件，正如前面所描述的那样。如果在步骤S1012中确定呼叫尝试没有成功，则所述方法继续到步骤S1018，其中确定是否达到了针对重新建立呼叫的时限。如果还没有达到时限，则所述方法回到步骤S1010从而再次对呼叫中的各个参与者进行呼叫，从而再次尝试重新建立呼叫。这样客户端108就重复尝试重新建立呼叫，直到呼叫尝试成功或者达到步骤S1018中的时限为止。如果在步骤S1018中确定已经达到针对重新建立呼叫的时限，则所述方法继续到步骤S1020，其中停止针对重新建立呼叫的尝试，并且所述方法继续到后呼叫状态。后呼叫状态
当呼叫已被终止并且没有在施行针对重新建立的尝试时，用户终端104处于后呼叫状态。如果一对一呼叫由于没有参与者在线而被终止，则将为用户102给出以下选项1、当已终止呼叫中的另一用户(例如用户110)下一次在线出现时，可以对用户102提
出告警。这可以是可配置的设定。该通知将仅仅对于呼叫终止之后的预定时间(例如I小时)是相关的(即如果远程用户在掉落呼叫两个小时之后在线，则将不会通知本地用户)。如果掉落的呼叫是群组呼叫，则可以分别向本地用户通知每一个先前参与者的在线恢复。如果其表明不希望当联系人在线时被通知，则该通知将推翻本地用户的通知设定。2、用户终端104可以利用通信系统100立即重拨呼叫。3、如果呼叫中的(多个)其他用户在其简档中具有电话号码并且用户102具有足以拨叫通信系统100之外的号码的余额，则用户终端104可以将所述呼叫重拨为SkypeOut呼叫(即利用与通信系统100不同的通信系统)。4、如果远程用户在其简档中具有电话号码但是本地用户(即用户102)没有余额，则可以为用户102提供充满其帐户并且随后人工尝试所述呼叫以作为SkypeOut呼叫的选项。5、如果远程用户在其简档中没有电话号码但是本地用户有余额，则用户102可以填充远程用户的电话号码，从而允许用户102作为SkypeOut呼叫来呼叫远程用户。图7示出了用于在用户终端104处于后呼叫状态时显示给用户102的后呼叫屏幕的用户接口 702的一个例子。用户接口 702向用户102通知呼叫已结束，并且包括按钮704，用户102可以使用该按钮来关闭用户接口 702，从而不会发起针对联系掉落的呼叫的用户的进一步尝试。用户接口 702向用户102给出信息，从而表明对应于用户102可能能够联系掉落的呼叫的用户的方式的其他各种选项，并且用户接口包括按钮706，用户102可以点击该按钮以便关于这些各种选项获知更多。用户接口 702还包括按钮710和712，用户102可以使用这些按钮来尝试与掉落的呼叫的用户建立新的呼叫(作为音频呼叫或视频呼叫)。网络呼叫质量指标708表明由用户终端104体验的当前网络质量。用户接口 702还包括按钮714，用户102可以点击该按钮以 便输入新的电话号码，从而按照另一种方式联系掉落的呼叫的用户。图11是用于在用户终端104处于后呼叫状态时施行的处理的流程图。所述处理开始于步骤S1102，该步骤接在图10中所示的步骤S1008之后。所述处理随后继续到步骤S1104，其中确定无法连接到网络106的掉落的呼叫中的用户(即掉落的呼叫中的离线用户)在其简档中是否具有PSTN或移动号码。如果这些离线用户在其简档中不具有PSTN或移动号码，则所述方法继续到步骤S1106，其中向用户102显示用户接口 702并且不重新建立呼
口 H。但是如果在步骤S1104中确定离线用户在其简档中确实具有PSTN或移动号码，则所述方法继续到步骤S1108,其中确定用户102是否希望经由SkypeOut呼叫来呼叫离线用户，如果是的话，则所述方法继续到步骤Sll 10，其中利用来自离线用户的简档的PSTN号码或移动号码经由SkypeOut呼叫发起用户102与离线用户之间的呼叫。所述方法随后继续到步骤S1112，其中，掉落的呼叫处理结束，并且随后将呼叫作为正常SkypeOut呼叫来应对。但是如果在步骤SlllO中确定用户102不希望经由SkypeOut呼叫连接到离线用户，则所述方法继续到步骤S1106，其中向用户102显示用户接口 102并且不重新建立呼叫。图12示出了根据优选实施例的用于传送用户输入数据的处理的流程图。在步骤S1202中，客户端108确定呼叫已被掉落。这可以按照前面描述的那样来施行，例如当数据流已被丢失至少15秒或者在呼叫中使用的独立于流的信令信道上有故障时。在呼叫被掉落的同时，用户终端104可以存储接收自用户102的用户输入数据。举例来说，用户输入数据可以是在麦克风212处接收到的语音数据(或“话音数据”)，或者由网络摄像头225捕捉到的视频数据。在步骤S1206中重新建立呼叫。可以如前所述地重新建立呼叫，即由客户端108自动重新建立。当呼叫已被重新建立时，将所存储的用户输入数据从用户终端104传送到重新建立的呼叫中的其他用户终端。这样就允许在呼叫被掉落与呼叫被重新建立之间的时间段期间在用户终端104处接收用户输入数据，并且随后将该用户输入数据传送到重新建立的呼叫中的其他用户。正如前面关于图4所描述的那样，在用户终端112处通过网络106接收到的呼叫数据被输入到抖动缓冲器404。可以对在呼叫被掉落与呼叫被重新建立之间的时间段期间在用户终端104处从抖动缓冲器404接收到的数据的输出速率进行调节，从而使其高于在呼叫中接收到的正 常数据的输出速率。这样就可以比通常更快地输出所述数据，从而随后可以在没有任何额外延迟的情况下输出在呼叫中传送的其他数据。图12中所示的方法在与前面描述的自动重新建立处理相组合时特别有用，这是因为其允许用户102在客户端重新建立呼叫的同时继续输入用于呼叫的数据(例如继续说话)，并且尽管在呼叫中发生了暂时性掉落，并不会从呼叫中丢失任何用户输入数据。由于不需要用户102施行任何行动来重新建立掉落的呼叫，因此如果可以成功地重新建立呼叫的话则用户可以继续呼口4，实际仿佛呼叫中的掉落未曾发生一样(这在呼叫掉落的时间段较短时是可能的，即呼叫掉落的时间段低于阈值时间段)。如果呼叫掉落的时间段长于阈值时间段，则前面参照图12描述的缓冲数据的方法不足以允许用户像实际仿佛呼叫中的掉落未曾发生那样继续呼叫。当呼叫被掉落时，可以向用户102通知接收自他的话音数据将被不同地应对，从而为用户102给出相应地调节对话的机会。对于长掉落(即呼叫掉落持续时间长于阈值时间段)，例如通过延迟通知(比如前面描述的那些通知，其可以向用户102通知呼叫被掉落，或者针对呼叫的重新建立处理正在进行)可以缩短用户102对于掉落的“体验持续时间”。但是一些通知(例如显示网络状况很差的那些通知)则不应当被延迟。掉落的呼叫的“体验持续时间”是用户102感知到的呼叫掉落的持续时间。即使当呼叫掉落的持续时间长于阈值时间段从而使得用户无法像实际仿佛呼叫中的掉落未曾发生那样继续呼叫时，(前面参照图12描述的)缓冲输入数据的方法也可用于缩短呼叫掉落的“体验持续时间”，从而使其低于呼叫掉落的实际持续时间。举例来说，如果当呼叫掉落时被输出给用户102的通知旨在向用户通知呼叫掉落从而使其可以适应于呼叫掉落(例如所述通知可以声明“请不要说话”或“呼叫已掉落”或“请不要挂断”)，则可以通过在呼叫掉落时在发送侧进行缓冲(如前所述)并且故意不立即通知用户102呼叫掉落而缩短呼叫掉落的体验持续时间，相反只在由于呼叫掉落的持续时间过长从而无法再向用户102隐藏呼叫掉落时才在后来的某一时间向用户102通知呼叫掉落。但是如果在呼叫掉落时被输出给用户102的通知旨在防止体验到呼叫掉落(例如所述通知可以声明“您的网络质量正在降低，请移到信号强度更好的位置”)，则可能有益的是在呼叫掉落时例如向用户立即输出该通知。可以根据呼叫被掉落与呼叫被重新建立之间的时间量来调节从抖动缓冲器404输出用户输入数据的速率。举例来说，当在呼叫被掉落与呼叫被重新建立之间有大量时间时，则与在呼叫被掉落与呼叫被重新建立之间的时间量较小的情况相比，可以将抖动缓冲器404的输出速率增大更多。这样就允许根据在用户终端104处记录所存储的用户输入数据的时间长度来调节从抖动缓冲器404输出所存储的用户输入数据所花费的时间。因此，前面描述了用于自动(即没有用户干预)重新建立掉落的呼叫的方法。虽然前面参照优选实施例示出并描述了本发明，但是本领域技术人员将理解的是，在不背离由所附权 利要求书所限定的本发明的范围的情况下可以在形式和细节方面做出许多改变。
权利要求
1.一种应对可由第一用户使用的第一用户终端与可由对应的至少一个其他用户使用 的至少一个其他用户终端之间的通过通信网络的呼叫的方法，其中在第一用户终端处执行 客户端以便参与呼叫，所述方法包括客户端确定使用在通过通信网络的第一用户终端与至少一个其他用户终端之间的呼 叫中的对应的至少一个网络连接的状况；客户端确定呼叫已掉落；响应于确定呼叫已掉落，客户端根据所确定的至少一个网络连接的状况自动尝试重新 建立呼叫。
2.权利要求I的方法，其还包括客户端监测所述至少一个网络连接以便检测表明所 述至少一个网络连接的潜在问题的事件，其中确定对应的至少一个网络连接的状况的步骤 是响应于对于表明所述至少一个网络连接的潜在问题的事件的所述检测而发起的。
3.权利要求2的方法，其还包括向第一用户通知由所检测到的事件所表明的潜在问题。
4.权利要求3的方法，其中，在所述潜在问题导致呼叫掉落之前向第一用户通知所述 潜在问题。
5.权利要求3或4的方法，其中，所述通知第一用户包括在第一用户终端的显示器上 显示对话框。
6.权利要求3到5当中的任一条的方法，其中，所述通知第一用户包括在第一用户终 端处播放可听通知。
7.权利要求3到6当中的任一条的方法，其中，所述通知第一用户包括改变显示在第 一用户终端的显示器上的网络呼叫质量指标。
8.权利要求2到7当中的任一条的方法，其中，所述事件是以下各项的其中之一(i)与呼叫相关联的数据流丢失预定时间段；( )用在呼叫中的信令信道上的故障；以及(iii)所述至少一个网络连接上的可用带宽量落到预定阈值带宽以下。
9.权利要求2到8当中的任一条的方法，其中，所述至少一个其他用户终端监测通 过通信网络用在呼叫中的其他网络连接，以便检测表明其他网络连接的潜在问题的其他事 件。
10.任一条在前权利要求的方法，其中，所述确定对应的至少一个网络连接的状况包 括检查第一用户终端是否可以连接到通信网络。
11.任一条在前权利要求的方法，其中，所述确定对应的至少一个网络连接的状况包 括检查所述至少一个其他用户终端是否可以连接到通信网络。
12.任一条在前权利要求的方法，其中，所确定的至少一个网络连接的状况被用来将 第一用户终端归类到五个分类的其中之一。
13.权利要求12的方法，其中，所述五个分类当中的第一个表明第一用户终端与呼叫 中的至少一个其他用户终端连接，并且网络性能足以同时继续呼叫的音频和视频方面。
14.权利要求12或13的方法，其中，所述五个分类当中的第二个表明第一用户终端与 呼叫中的至少一个其他用户终端连接，并且网络性能足以应对呼叫的音频方面而无法应对 视频方面。
15.权利要求12到14当中的任一条的方法，其中，所述五个分类当中的第三个表明第一用户终端与呼叫中的至少一个其他用户终端连接，但是网络性能不足以应对呼叫的音频或视频方面。
16.权利要求15的方法，其中，当第一用户终端处于第三分类时，客户端终止呼叫从而导致确定呼叫已掉落的所述步骤。
17.权利要求12到16当中的任一条的方法，其中，所述五个分类当中的第四个表明第一用户终端无法连接到通信网络。
18.权利要求12到17当中的任一条的方法，其中，所述五个分类当中的第五个表明所述至少一个其他用户终端无法连接到通信网络。
19.权利要求17或18的方法，其中，当第一用户终端处于第四或第五分类时，重复确定对应的至少一个网络连接的状况的步骤，直到预定时间长度到期或者第一用户终端被归类到第一、第二和第三分类的其中之一为止。
20.权利要求19的方法，其中，确定呼叫已掉落的所述步骤包括确定所述预定时间长度已到期。
21.权利要求19的方法，其中，如果所述预定时间长度到期，则终止呼叫，并且第一用户终端进入其中停止针对重新建立呼叫的所述尝试的后呼叫状态。
22.任一条在前权利要求的方法，其中，如果针对重新建立呼叫的所述尝试在预定重新建立时间段内没有成功，则第一用户终端进入其中停止针对重新建立呼叫的所述尝试的后呼叫状态。
23.权利要求1到21当中的任一条的方法，其中，如果针对重新建立呼叫的所述尝试在预定重新建立时间段内没有成功，则所述方法还包括确定与所述至少一个其他用户相关联的对应的至少一个其他号码；以及客户端拨叫所确定的至少一个其他号码的至少其中之一。
24.权利要求23的方法，其中，所述至少一个其他号码是所述通信网络中的号码。
25.权利要求23的方法，其中，所述至少一个其他号码是另一个通信网络中的号码。
26.任一条在前权利要求的方法,其还包括客户端检测表明不可接受的呼叫性能的特定终止事件；以及当检测到特定终止事件时客户端终止呼叫，其中呼叫的终止导致客户端确定呼叫已掉落的所述步骤。
27.权利要求26的方法，其中，所述终止事件是以下各项的其中之一(i)与呼叫相关联的数据流丢失预定的终止时间段；以及(ii)用在呼叫中的信令信道上的故障。
28.任一条在前权利要求的方法，其中，存在多于一个其他用户终端，并且尝试重新建立呼叫的步骤包括尝试分别建立到每一个其他用户终端的网络连接。
29.任一条在前权利要求的方法，其中，客户端成功地重新建立呼叫，并且所述方法还包括客户端存储在呼叫已掉落之后并且在呼叫被重新建立之前的时间段内接收自第一用户的用户输入数据；以及响应于呼叫的重新建立，客户端将所存储的用户输入数据传送到呼叫中的所述至少一个其他用户终端。
30.权利要求29的方法，其中，所述用户输入数据是语音数据。
31.权利要求29的方法，其中，所述用户输入数据是视频数据。
32.权利要求29到31当中的任一条的方法，其还包括在所述至少一个其他用户终端的抖动缓冲器处接收所存储的用户输入数据；在所述至少一个其他用户终端处输出所存储的用户输入数据，其中从抖动缓冲器输出所存储的用户输入数据的速率被控制成高于针对呼叫中的正常话音数据的输出速率。
33.权利要求32的方法，其中，从抖动缓冲器输出所存储的用户输入数据的速率取决于在呼叫已掉落之后并且在呼叫被重新建立之前的所述时间段的长度。
34.一种可由用户使用的用户终端，其被配置成应对通过通信网络到可由对应的至少一个其他用户使用的至少一个其他用户终端进行的呼叫，所述用户终端包括处理装置，所述处理装置被配置成执行客户端以便参与呼叫并且从而确定使用在通过通信网络的所述用户终端与至少一个其他用户终端当中的每一个之间的呼叫中的对应的至少一个网络连接的状况；确定呼叫已掉落；响应于确定呼叫已掉落，根据所确定的至少一个网络连接的状况自动尝试重新建立呼叫。
35.一种应对通过通信网络的第一用户与至少一个其他用户之间的呼叫的方法，其中在第一用户的用户终端处执行客户端以便参与呼叫，所述方法包括客户端确定呼叫已掉落；响应于确定呼叫已掉落，客户端自动尝试重新建立呼叫。
36.权利要求35的方法，其中，所述呼叫已经由于通过通信网络的第一用户与至少一个其他用户之间的对应的至少一个网络连接的问题而掉落。
37.一种应对通过通信网络的第一用户终端与至少一个其他用户终端之间的呼叫的方法，其中在第一用户终端处执行客户端以便参与呼叫，所述方法包括客户端确定呼叫已掉落；重新建立第一用户终端与至少一个其他用户终端之间的呼叫；客户端存储在呼叫已掉落之后并且在呼叫被重新建立之前的时间段内接收自第一用户终端的用户的用户输入数据；响应于重新建立呼叫，客户端将所存储的用户输入数据传送到呼叫中的至少一个其他用户终端。
38.一种可由用户使用的用户终端，其被配置成应对所述用户终端与可由对应的至少一个其他用户使用的至少一个其他用户终端之间的通过通信网络的呼叫，所述用户终端包括处理装置，所述处理装置被配置成执行客户端以便参与呼叫并且从而确定呼叫已掉落；重新建立第一用户终端与至少一个其他用户终端之间的呼叫；存储在呼叫已掉落之后并且在呼叫被重新建立之前的时间段内接收自用户的用户输入数据；以及响应于重新建立呼叫，将所存储的用户输入数据传送到呼叫中的至少一个其他用户终端。
39.一种通信网络，其被配置成应对在如权利要求34或38所要求保护的用户终端与至少一个其他用户终端之间通过所述通信网络进行的呼叫。
40.权利要求39的通信网络，其中，所述通信网络是因特网。
全文摘要
用于应对可由第一用户使用的第一用户终端与可由对应的至少一个其他用户使用的至少一个其他用户终端之间的通过通信网络的呼叫的方法和用户终端，其中在第一用户终端处执行客户端以便参与呼叫。客户端确定使用在通过通信网络的第一用户终端与至少一个其他用户终端之间的呼叫中的对应的至少一个网络连接的状况。客户端还确定呼叫已掉落，并且响应于确定呼叫已掉落，客户端根据所确定的至少一个网络连接的状况自动尝试重新建立呼叫。
文档编号H04L29/14GK103069775SQ201180042623
公开日2013年4月24日 申请日期2011年8月25日 优先权日2010年9月2日
发明者D.利克, M.奥鲁亚斯, S.斯特罗默, M.韦伦科 申请人:斯凯普公司