用于在呼叫者与被呼叫者之间建立呼叫的网络节点和方法与流程

用于在呼叫者与被呼叫者之间建立呼叫的网络节点和方法相关的申请本申请在35USC119或365下要求2012年6月14日提交的英国申请No.1210600.1的优先权，该申请的公开内容整体地合并于此。

背景技术：
存在用于通过诸如因特网那样的基于分组的网络建立实况的基于分组的话音或视频呼叫的各种通信系统。例如，这样的系统可以使用VoIP（互联网上的话音协议）技术。一种流行类型的通信系统是构建在对等（P2P）拓扑上。在传统的P2P系统中，每个最终用户在他或她各自的用户终端（例如，台式计算机或膝上型计算机、平板电脑或手持移动电话）上安装通信客户端应用。每个用户然后向P2P提供者的服务器注册以便得到认证证书。用户终端中的某些也将成为分布式数据库的节点，其将P2P通信系统内用户的用户名映射到该系统在其上实施的网络内的各个用户终端的地址（典型地是IP地址）。然后可以进行在最终用户之间的通信，而不用在呼叫建立或认证过程中牵涉到集中式的服务器。替代地，在呼叫者的终端上的客户端查询分布式数据库的一个或多个节点（即，呼叫中以任何其他方式涉及的其他最终用户（不一定是他们自己）的一个或多个终端），以便确定预期的被呼叫者的终端的地址。然后，呼叫者使用所确定的地址来把呼叫邀请发送到被呼叫者，以及被呼叫者用呼叫接受响应来进行响应。呼叫者和被呼叫者交换他们的认证证书，以便互相认证。每个用户还维护联系人列表，该联系人列表可以被存储在P2P提供者的服务器上，以使得即使在用户登录到不同的终端时它也是可得到的。其它辅助信息，诸如用于每个用户的简档信息（例如，化身图像或情绪消息），也可以被存储在服务器上。而且，客户端应用也互相交换存在性信息。存在性信息指示用户的可用性（availability）状态，优选地，它至少部分地由用户他或她自己定义。例如，存在性可以指示用户是离线，是在线但已选择为不可用（“别打扰”），还是在线并已选择为可用的。例如，每个客户端可以周期地轮询在它的联系人列表中的每个联系人，以便确定它们各自的存在性，和/或每个客户端可以把存在性更新周期地发送到它的列表中的每个联系人。存在性典型地根据P2P技术直接在最终用户之间用信号通知，而不用经由服务器。当进行呼叫时，呼叫者的客户端根据最新的存在性信息确定被呼叫者是否可用来接受该呼叫。

技术实现要素：
在本发明的实施例中，网络节点被安排成参加通过网络的在呼叫者与被呼叫者之间的呼叫建立。网络节点包括发射机设备，其被安排来发送用于在呼叫者的呼叫者客户端与实施在被呼叫者的一个或多个被呼叫者终端上的一个或多个被呼叫者客户端之间建立呼叫的呼叫邀请的多个版本。收发器设备被安排来通过多种不同的传递机制发送呼叫邀请的多个版本。传递机制之一包括在推送信道上的推送通知。本概要被提供来以简化的形式介绍概念的选择，这些概念还将在下面的详细说明段落中进行描述。本概要既不打算确认所要求保护的主题的关键特征或必要特征，也不打算限制所要求保护的主题。所要求保护的主题也不限于解决在前系统的任何或所有的已指出缺点的实现。附图说明为了更好地了解本发明和显示本发明可以如何付诸实施，作为例子，参考附图，其中：图1是通信系统的示意图；图2是通信系统的另一个示意图；图3是通信系统的再一个示意图；图4是两个用户终端的示意图；以及图5是两个用户终端和网络单元的示意图。具体实施方式随着能够运行诸如VoIP客户端那样的通信客户端应用的手持移动电话越来越流行，有数量越来越多的端点（endpoint）可用于参与到VoIP通信系统或其它这样的、通过因特网等等实施的基于分组的通信系统中。然而，也可能引发的问题是，移动电话手机典型地比传统的台式计算机或膝上型计算机具有更有限的资源，例如，每单位时间只能执行更少的处理周期，每个处理周期具有更少的功能性，具有更有限的存储器资源（例如，RAM和/或高速缓存器）和/或具有更少的屏幕区域资源。因此，在某些终端上的操作系统（OS）可能就把某些应用置于后台状态。这可包括通信客户端。在后台状态下，后台化的应用或者被完全挂起或者每个单位时间被调度以有限的处理周期，在某种程度上不能检测进入的呼叫邀请和/或处理传统的呼叫邀请。例如，如果另一个应用正在前台状态（foregroundstate）中运行，特别是如果其它应用在处理、存储器和/或屏幕资源方面是集中的（intensive），例如运行在全屏模式或具有作为当前主要的、首要的或优先的应用的某些其它状态，则这可能发生。一个例子是在移动电话上玩的计算机游戏。在这样的情形下，如果客户端不能发出存在性更新或响应来自其它用户的存在性轮询，则用户可能从他或她的存在性来看表现为离线。尽管如此，用户仍旧可能希望可用于接受呼叫，例如，宁愿中断视频游戏也不错过呼叫。因此，传统的存在性概念开始被打破。在具有能够把某些应用置于后台状态中来有利于一个或多个其它应用的特征的任何终端上可能潜在地出现类似的问题。对于诸如在基于分组的网络上实施的常规P2P系统那样的通信系统可能引发的另一个问题是呼叫信令的速度，特别是在呼叫被回答之前花费了多长时间，或者确定呼叫不被回答花费了多长时间。这可能当被呼叫者的客户端处在如以上讨论的后台状态时特别成问题，其中呼叫者在他或她被告知以被呼叫者是不可用之前可能必须等待所尝试的呼叫邀请超时。如果该超时时段较长，比如说30-60秒，使得即使被呼叫者的客户端被挂起且起初便根本不能接受该呼叫，呼叫者在他们发现呼叫不能进行之前也要等待多达一分钟，则这对于呼叫者而言是特别令人沮丧的。呼叫信令延时也可能在其它类型的通信系统中出现。某些其它类型的通信系统使用推送通知来把通信事件通知给目的地用户终端。推送通知是在服务器或另一个始发单元的激励下，而不是在目的地终端本身的激励下从服务器发送的通知（即，与由目的地终端拉取相反）。因此，推送通知可被看作为与目的地终端异步。当呼叫邀请被发送时，可能希望让呼叫邀请以快速和可靠的方式传递到被呼叫者客户端。呼叫建立请求（或“呼叫邀请”）可以通过多种传递机制提供，以便建立呼叫。传递机制描述呼叫邀请被传递的方式。例如，传递机制可包括借助其发送呼叫邀请的协议，和/或呼叫邀请如何通过网络被路由。例如，三种类型的传递机制是：(i)对等机制，其中呼叫邀请是使用对等协议通过网络被路由的，(ii)基于应用层的推送通知机制，呼叫邀请借助于它通过网络被推送到在被呼叫者终端处的客户端应用，和(iii)基于操作系统的推送通知机制，呼叫邀请借助于它通过网络被推送到被呼叫者终端的操作系统。发送呼叫邀请的多个版本可以减少呼叫建立时间和提高呼叫邀请成功地传递到被呼叫者的客户端的概率。呼叫邀请的每个版本涉及到同一个呼叫，并可以使用呼叫ID来标识呼叫。这样，如果被呼叫者客户端接收到呼叫邀请的多个版本，则被呼叫者客户端可以确定呼叫邀请的每个版本包括相同的呼叫ID，因此它们都是用于该呼叫的同一个呼叫邀请的版本。呼叫邀请的每个版本可包括用来标识呼叫邀请的邀请ID。这允许呼叫邀请的每个版本与该呼叫邀请相关联。换句话说，邀请ID允许被呼叫者客户端确定呼叫邀请的每个版本涉及到同一个呼叫邀请。如果多个呼叫邀请是为同一个呼叫发送的，则这是特别有用的，其使得每个呼叫邀请的每个版本可以与正确的呼叫邀请相关联。在实施例中，被呼叫者客户端可以回答呼叫邀请的版本之一（例如，要在被呼叫者客户端处接收的呼叫邀请的第一个版本），由此建立在呼叫者与被呼叫者之间的呼叫。为了建立呼叫，可能只需要由被呼叫者客户端接收呼叫邀请的一个版本。由于呼叫邀请的各版本通过不同的传递机制被发送，所以与通过单个传递机制发送呼叫邀请相比较，从呼叫者客户端发送到被呼叫者客户端的呼叫邀请的至少一个版本所花费的时间可以减少。而且，由于呼叫邀请的各版本是通过不同的传递机制被发送的，所以与通过单个传递机制发送呼叫邀请相比较，在被呼叫者客户端处成功接收呼叫邀请的至少一个版本的可靠性可以增加。传递机制可包括以下的至少两种机制：(i)在基于操作系统的推送信道上的基于操作系统的推送通知，(ii)在应用层推送信道上的应用层推送通知，和(iii)在通过网络的对等连接上的对等消息。通过在多种传递机制上同时发送呼叫邀请的各版本，系统可以在特定时间利用最有利的无论哪种传递机制（例如，最快的传递或最可靠的传递）。条件有可能改变，这样使得传递机制中最有利的一种传递机制（例如，它具有最快的传递或它是最可靠的）可能随时间而改变。正如所提到的，诸如手持移动电话那样的现代移动设备现在能够运行通信客户端应用，来用于通过诸如因特网那样的基于分组的网络，而不是仅仅经由移动电话的专用蜂窝话音信道，去执行诸如VoIP那样的基于分组的通信或其它基于分组的话音或视频呼叫。通过这种能力，带来在线的和可呼叫的用户数量的巨大增加。然而，这样的用户的客户端应用也可能潜在地被发现：在呼叫时处在后台状态中，由此，客户端被移动设备的操作系统挂起或至多被调度以非常有限的资源—因此为了接收进入的呼叫，客户端需要被唤醒。在这样的操作系统体系下—其中应用不再保证能够在后台处理诸如进入的呼叫、聊天等那样的事件—VoIP或其它通信提供者的结构体系将从被进行扩展而获益。例如，如果提供者希望能够把呼叫（和其它）通知传递给他们的通信系统的用户，即使所述用户可能把相关的通信客户端应用“后台化”（或由操作系统将应用后台化）但尽管如此用户仍旧在线且照这样是潜在地可呼叫的，则这将是有利的。客户端应用的呼叫部件也可以被修改，以保证呼叫用户的初始意图可以可靠地传递到所有的端点，在那里用户应当能够接收呼叫—如果需要的话，经由推送通知。例如，考虑其中被呼叫者正在手持电话或平板电脑上使用网络浏览器或正在玩视频游戏而同时等待他或她的朋友的呼叫（或许来自外国，所以为了费用原因而宁愿使用VoIP）的使用情形。被呼叫者根据存在性状态检查朋友是否在线，但当他或她不在线时被呼叫者开始浏览或玩游戏来打发时间。然后，朋友（呼叫者）随后例如在台式计算机上登录到他或她的客户端应用，准备呼叫被呼叫者。在实施例中，被呼叫者的客户端可以被修改成向呼叫者显示被呼叫者为在线，即使被呼叫者的客户端应用由于浏览器或游戏需要耗费高的系统资源，例如由于在浏览器中运行flash应用或其它applet而已由被呼叫者的操作系统挂起或抑制。在本发明的实施例中，呼叫者点击呼叫按钮，发起对被呼叫者的呼叫，被呼叫者的操作系统被配置成提出提示，通知他或她有进入的呼叫。被呼叫者的客户端应用被配置成使得如果被呼叫者响应于该提示而敲击或点击接受按钮，则客户端应用在被呼叫者的终端上被带回到前台，因此允许被呼叫者回答该呼叫（话音或视频），且开始与他或她的朋友—呼叫者—谈话。在本示例性情形下，应当注意某些单元。被呼叫者客户端的状态在最坏的情况下潜在地被完全挂起（终结），照这样它不能通过常规的P2P会话建立方法来联系到。在本发明的实施例中，被呼叫者可能不知道或没注意到他或她的客户端应用被挂起，因为这可能未曾被被呼叫者用户明确地完成—事实上正好相反，这可能已经由操作系统自动完成，且被呼叫者可以是在这样的假设下：他或她的客户端应用仍旧在运行，以及他们是在线和可联系的。而且，在这种情景下，与用于这样的系统的常规存在性机制不同，优选地不使存在性依赖于（或不仅仅依赖于）客户端的P2P可用性。为了支持以上的情景，提供者将优选地实施新的呼叫部件和/或对于现有的部件做出必要的改变。一个目标是使得被呼叫者客户端能够在适当的时间帧和范围内被唤醒和建立与呼叫者客户端的会话（例如，P2P会话）。为了保持呼叫建立时间尽可能短，在会话与呼叫建立时的往返行程（roundtrip）优选地应当尽可能保持为最小。正如以上的示例性情景下演示的，呼叫发起流程可以支持需要经由非P2P消息传递系统用信号通知呼叫的意图的使用情形，其可以在需要的场合下回退（fallback）到推送通知，以便唤醒被呼叫者客户端。例如，这可以是经由由所讨论的操作系统的提供者所提供的推送通知服务。呼叫建立请求（即，呼叫邀请）通过多种传递机制提供，以便建立呼叫，由此减小呼叫建立时间和提高传递的概率。换句话说，呼叫邀请的多个版本是使用不同的传递机制，例如，通过网络的不同路由，从呼叫者客户端发送到被呼叫者客户端。呼叫邀请的各版本可以在网络上并行地发送。在这个意义上，呼叫邀请通过使用不同的传递机制而分散作为多个版本被传递。而且，被呼叫者可以与一个以上的用户终端相关联。换句话说，被呼叫者可以在一个以上的终端上安装客户端软件实例，并且可以通过使用来自这些终端的客户端软件实例而登录到通信系统。因此，被呼叫者可以是经由在一个以上的被呼叫者终端处实施的一个以上的被呼叫者客户端可联系的。呼叫邀请的各版本被发送到在与被呼叫者相关联的每个被呼叫者终端处实施的每个被呼叫者客户端。通过经由多种传递机制发送呼叫邀请的多个版本以及发送到多个被呼叫者客户端，呼叫邀请的版本可用以传递到被呼叫者客户端的速度和可靠性以及被呼叫者当前交互所用的速度和可靠性都可以提高。呼叫部件可被更新，以例如在核心库中实施必要的客户端部件改变，以便保证它们迎合所有需要的使用情形、互操作性和后向兼容性情景。呼叫客户端部件可被更新来允许被呼叫者客户端接受经由推送通知传递方法接收的进入的呼叫邀请。这可包括一个或多个UI（用户接口）API（应用编程接口）的组，允许客户端UI层把接收的有用负荷信息传送到呼叫部件，使得能进行P2P会话建立和呼叫建立及信令。对于要被包括在经由消息传递系统传递到被呼叫者端点的消息的有用负荷中的呼叫有关的信息，呼叫功能性优选地可以支持基于云的服务，该基于云的服务接收来自传递基础设施的消息，并用呼叫特定的有用负荷信息来填充这个消息。呼叫通知优选地包括足够的信息，以允许被呼叫者做出是否回答该呼叫的有根据的（informed）决定。这例如可包括呼叫者名字（用户名和/或显示名）、呼叫者的化身、和/或呼叫邀请的时间戳。呼叫通知还可包括允许被呼叫者客户端制定接受响应的信息，诸如握手消息和使得呼叫者在响应时能够被联系的信息（例如，呼叫者用户名和/或地址）。一旦传递系统的呼叫通知器完成以上步骤，就传送呼叫通知以便最后传递到被呼叫者端点。这优选地将在被邀请到呼叫的用户已登记去接收推送通知的场合下，或是在对于客户端而言存在开放连接的场合下发生。通知可以是通过直接的持久连接（被呼叫者客户端在前台，和/或某些后台状态）或在需要的场合下（被呼叫者客户端被挂起，和/或某些其它后台状态）是经由到基于相关的操作系统的通知服务的推送通知。参加呼叫的邀请在许多情形下可以由呼叫方发出，诸如：在实际的呼叫被建立之前，作为发起的一部分；或是在正进行的呼叫期间把另一个参加者加到呼叫中。图1是基于传统的P2P范例的通信系统的示意图。通信系统包括基于分组的网络100，优选地是广域互联网络（互联网），诸如因特网。通信系统还包括多个最终用户终端102，每个包括收发器设备，可操作来耦合到因特网100，以及每个包括所讨论的通信系统的各自的通信客户端应用。每个最终用户终端102例如可以取台式计算机或膝上型计算机、平板电脑或手持移动电话（或“手机”）的形式。每个用户终端102是在通信系统内的VoIP呼叫或其他的基于分组的通信的潜在端点。图1上图示的是呼叫者端点102a和被呼叫者端点102b。按照常规的P2P原理，在一个或多个用户终端102c上的客户端应用呈现分布式地址查找数据库的节点的状态。为了确定被呼叫者的用户终端102b的地址（例如，包括IP地址），在步骤S10，在呼叫者的用户终端102a上的客户端经由因特网100与充当分布式数据库的节点的用户终端102c之一上的客户端通信。在呼叫者的终端102a上的客户端通过向数据库节点102c发送在通信系统内标识被呼叫者的被呼叫者的用户名而查询数据库节点102c，且数据库节点102c返回所需要的被呼叫者的用户终端102b的地址。在步骤S12，在呼叫用户终端102a上的客户端然后使用这个地址来把呼叫建立请求或“邀请”（CI）用信号通知到预期的被呼叫者的终端102b上的客户端。作为响应，如果被呼叫者选择接受该呼叫，则被呼叫者终端102b上的客户端用信号发回呼叫接受响应。在呼叫者和被呼叫者的终端102a和102b上的客户端还交换认证证书以互相验证身份。客户端因此建立互相之间的会话，以便在它们各自的终端102、102b上发送以来自麦克风和/或视频摄像机的实时话音和/或视频内容的形式的业务量作为实况话音或视频呼叫的一部分。因为地址查找是基于分布式数据库，所以不需要为此而牵涉中央服务器。呼叫建立信令、认证和呼叫业务量的进行也不需要牵涉中央服务器。在实施例中，如果由于NAT（网络地址翻译）或防火墙108，呼叫者的用户终端102a不能直接与被呼叫者的用户终端102b进行通信，则客户端可被安排成经由一个或多个中继进行通信，这些中继也可以由在P2P通信系统的一个或多个其它用户的最终用户终端102d上运行的客户端实施。进行中继的最终用户终端102d的用户不需要是呼叫的参加者（不需要消费呼叫的话音或视频内容，并且事实上由于加密，也不能消费）。尽管如此，进行中继的最终用户终端102d的用户当他或她签约到P2P通信系统时将已同意这样的情形，以及他或她自己可以在其它场合下从互惠安排中获益。通信系统还可包括被耦合到因特网100的后端服务器104，其中每个客户端可以存储各自的联系人列表，该联系人列表是它的相应用户的联系人列表（优选地，通信系统被配置成使得用户依据共同协议成为彼此的联系人）。后端服务器104还可以为每个用户存储简档信息，例如，用于向通信系统内的其它用户描绘相应用户的化身图像。每个客户端可以访问和显示联系人的简档，这样使得呼叫者可以看见被呼叫者的简档信息，以及反之亦然。通信系统还可以包括被耦合在因特网100与电路交换网络（未示出）之间的网关106。这样的网络可被称为PSTN（公共交换电话网），例如，地面线路网络或移动蜂窝网，诸如3GPP网。在用户终端102上的客户端由此还能够经由网关106建立与更多的传统电话的呼叫。图2图示按照本发明的实施例的、修改的混合P2P通信系统。图1的某些或所有的部件也仍旧可以与图2的系统并行存在，但某些部件为了简明起见从图2上被省略。而且，通信系统包括通信服务提供者—例如VoIP提供者—的网络单元204，其具有被耦合到因特网100并被安排成运行呼叫控制和通知软件的一个或多个服务器单元的形式。通信系统还包括被耦合到因特网100的、一个或多个基于操作系统的推送通知服务（OSPNS）202。所述一个或多个基于操作系统的推送通知服务202的每一个与各自的操作系统相关联，并优选地由操作系统的制造者和/或发布者提供来支持经由所讨论的操作系统可提供的专用推送通知机制。所述基于操作系统的推送通知服务202取被安排成运行推送通知软件的一个或多个服务器单元的形式。在图2的示例性系统中，所图示的单元102、202、204被配置成如下地运行。在步骤S20，在呼叫者的用户终端102a上的客户端不直接地把呼叫邀请（CI）发送到被呼叫者的用户终端102b上的客户端，而是把它发送到VoIP提供者的呼叫控制和通知单元204（消息CI不一定等同于相关于图1描述的那个消息）。响应于接收到来自呼叫者的呼叫邀请，在步骤S22，VoIP提供者的呼叫控制和通知单元204生成推送通知请求（PNR），它把该推送通知请求发送到基于操作系统的推送通知服务202。响应于接收到来自VoIP提供者204的推送通知请求，在步骤S24，OS的推送通知服务202发送基于操作系统的推送通知（PN_OS）到被呼叫者的用户终端102b上的操作系统。基于操作系统的推送通知由在被呼叫者的用户终端102b上的操作系统进行接收和处理，使得它在被呼叫者的用户终端102b的屏幕上显示弹出消息，向被呼叫者用户指示有进入的事件。在本发明的实施例中，屏幕上消息可以关于是否接受进入的呼叫而提示被呼叫者。如果被呼叫者的客户端应用当前被后台化，则屏幕上消息可以关于是否把被呼叫者的客户端应用从后台状态唤醒来提示用户。在实施例中，这些动作可被组合到同一个提示中。如果作为响应，被呼叫者提供肯定的用户输入，则操作系统通过重新调度到完全操作水平或至少调度给它足够的资源来操控该呼叫，而唤醒在被呼叫者的终端102上的被呼叫者客户端应用。正如下面更详细地讨论的，在实施例中，推送通知PN_OS可包括有用负荷，其使得在被呼叫者的用户终端102b上的客户端能够制定返回的握手消息，并且把该消息通过因特网100用信号通知回在呼叫者的用户终端102a上的客户端，优选地，是直接通过因特网100，而不是经由任何提供者的服务器或服务单元202和204。如果被呼叫者接受来自操作系统的用户提示，则在被呼叫者的用户终端102b上的操作系统传递至少部分的推送通知的有用负荷直到被呼叫者的客户端应用，以便使得它可以制定相关的响应，并把该响应发回到呼叫者。图3图示按照本发明的实施例的、另一个修改的混合P2P通信系统。图1和/或图2的某些或所有的部件也仍旧可以与图3的系统并行存在，但某些部件为了简明起见从图3上被省略。在图3的示例性系统中，所示的单元102、204被配置成如下地运行。在步骤S20，在呼叫者的用户终端102a上的客户端再次不直接把呼叫邀请（CI）发送到被呼叫者的用户终端102b上的客户端，而是把它发送到VoIP提供者的呼叫控制和通知单元204（消息CI不一定等同于相关于图1或图2描述的那个消息）。在实施例中，这可以是与相关于图2描述的那个步骤相同的步骤，或在其它实施例中，它可以是替换的或附加的、分开的步骤。然而，在这种情形下，VoIP提供者单元204不发送（或不仅仅发送）推送通知请求（PNR）到操作系统的推送通知服务202。而是，它直接制定它自己的应用层推送通知（PN_AL），它把该应用层推送通知通过因特网100直接发送到被呼叫者的用户终端102b上的客户端。在被呼叫者的用户终端102b上的客户端然后可以在应用层上处理该通知，以便它本身借助于应用层机制，而不是上述的操作系统机制，来关于进入的呼叫而提示被呼叫者用户。正如下面更详细地讨论的，在实施例中，推送通知PN_AL包括有用负荷，其使得在被呼叫者的用户终端102b上的客户端能够制定返回的握手消息，并且把该消息通过因特网100用信号通知回在呼叫者的用户终端102a上的客户端，优选地，是直接通过因特网100，而不是经由任何提供者的服务器或服务单元202和204。在这种情形下，如果在被呼叫者的终端102b上的客户端或者处在前台状态（不被抑制来有利于任何其它应用），或者处在特别的后台状态而由此它被调度以有限的周期，但仍旧足以处理进入的呼叫，那么被呼叫者的客户端能够通过在由操作系统调度用于被呼叫者的客户端的周期期间收听来自网络100的进入的通信，例如通过在被分配供被呼叫者的客户端使用的、被呼叫者的终端102b的网络套接字上收听，而直接访问推送通知的有用负荷。应当指出，图1、2和3的两种或更多种机制可以并行存在，并且任何的或所有的这些机制可以是可用于用信号通知呼叫邀请或通知的。在一个应用中，至少被呼叫者端点102b包括具有相对有限的资源（处理、存储器和/或屏幕资源）的移动终端，且该移动终端具有这样的操作系统，即：其易于把相应的客户端应用后台化，来有利于另一个应用，诸如在某种环境下的视频游戏。图4给出呼叫用户（呼叫者）的始发最终用户终端102a和被呼叫用户（被呼叫者）的目的地最终用户终端102b的示意性框图，它们形成呼叫的两个端点（或者甚至是在多方会议呼叫情景中更大数量端点中的两个端点）。始发用户终端102a包括相应的操作系统400a、VoIP通信系统的通信客户端402a（以及潜在的其它应用）和用户接口408a。VoIP客户端402a被存储在始发终端102a的存储器上（以诸如电子或磁存储设备那样的有形存储介质的形式），并被安排成在始发终端102a的处理设备上执行。客户端应用402a也被说成是在操作系统400a上运行，因为它被调度用于由操作系统400a来执行。如果在终端102a上有多个应用存在且运行，则操作系统将调度它们来例如以交替的方式和/或在并行的处理资源上执行，这样使得每个应用在操作系统400a的控制下被分配以至少某些处理资源。当被调度时，客户端应用402a能够经由用户接口408a与用户交互，并能够经由用户终端102a的收发器设备在网络100上通信。正如对于目的地终端102b更详细地讨论的，操作系统还可以挂起诸如客户端应用那样的应用的执行。目的地用户终端102b也包括相应的操作系统400b、VoIP通信系统的通信客户端402b，诸如电子邮件客户端404和视频游戏406那样的其它应用、和用户接口408b。通信客户端402b被存储在目的地终端102b的存储器（以诸如电子或磁存储设备那样的有形存储介质的形式），并被安排成在目的地终端102b的处理设备上执行。VoIP客户端应用402b和其它应用404、406被说成是在操作系统400b上运行，因为它们被调度用于由操作系统例如以交替的方式和/或在并行的处理资源上执行，这样使得每个应用在操作系统400b的控制下被分配以至少某些处理资源。当被调度时，VoIP客户端402b能够经由用户接口408b而与用户交互，并能够经由目的地用户终端102b的收发器设备在网络100上通信。对于其它应用404和406，当它们被调度时，情况同样如此。如上所述，操作系统400b还可以具有如下的能力，即挂起诸如VoIP客户端402b那样的应用，或把它置于某个其它后台状态，由此它仅仅被分配以每个单位时间非常有限的处理资源量。在实施例中，由操作系统400b进行的调度包括把每个应用402b、404、406置于某种前台状态或后台状态的能力。前台状态可包括其中前台应用是在当前时间正在运行的主要的、占优势的应用的状态。这方面的具体例子是在全屏模式下运行的应用，在其中以其它应用为代价它被分配以整个屏幕资源。例如，视频游戏406当运行时可被给予全屏或其它占优势的前台状态，因为用户可能需要全屏来玩游戏和/或游戏可能消耗相当大量的处理资源，使得可以使有限的处理资源或没有处理资源可用于其它应用（诸如VoIP应用402b和电子邮件客户端204）。这种情景特别可能在诸如手持移动电话那样的移动终端上发生，在移动终端中比起比如说台式计算机，资源是相对有限的。前台状态的另一个实例可包括其中没有一个应用相对于任何其它应用具有优势状态的状态，例如，终端102b的用户具有打开的桌面，没有应用被最大化，且VoIP应用402b被操作系统400b允许有足够的处理资源用于完全操作，而不受抑制来有利于诸如视频游戏406那样的任何其它应用。然而，当诸如视频游戏406那样的一个应用处在占优势的前台状态时，一个或多个其它应用402b、404可以由操作系统400b放置在后台状态。VoIP客户端402b对此可以是特定的候选者。替换地或附加地，在其它时间，操作系统400b可以把诸如VoIP客户端402b那样的应用放置在后台状态，以便节省电池资源。在这样的后台状态下，VoIP客户端402b或者被挂起，这意味着它不被操作系统400b调度以任何处理周期，或者至多被抑制，以使得它与非抑制的前台状态相比只被调度有限的周期。在被抑制的状态下，客户端402b可能只有非常有限的功能性，其中它可能不能单方面处理进入的呼叫邀请或通知，或可能不能通过使用完全资源来处理呼叫邀请或通知，而完全资源在另外的情况下在更高的功能性状态下将是可用的。在前台状态下，VoIP客户端402b完全能够收听进入的邀请或通知，它通过在目的地用户终端102b的网络套接字412上进行收听而做到这一点。网络套接字是网络地址与被分配供诸如VoIP客户端402b那样的应用使用的传输层端口的组合，典型地，IP套接字是IP地址与端口号的组合。例如，在前台状态下，VoIP客户端402b可能能够直接从始发终端102a接收常规的P2P呼叫邀请（CI），并随之处理该邀请，以便接受呼叫，和/或可能能够接收和处理来自VoIP提供者204的应用层推送通知（PN_AL）。在实施例中，在后台状态下，VoIP客户端402b不具有被调度的周期，它必须依赖于基于操作系统的推送通知服务202，或具有太有限的周期以致于不能依赖于除了基于操作系统的推送通知服务之外的任何事物。在这种情形下，基于操作系统的推送通知（OS_PN）被操作系统400b接收，该操作系统作为响应把屏幕上提示显示在目的地终端102b上。该提示通知被呼叫者：有通信事件请求注意，并提示用户选择是退出全屏模式，还是相反使得能唤醒一个或多个占优势的应用。屏幕上提示的格式可以由操作系统400b支配，可选地具有可以在推送通知中被规定的几个参数。在一些实施例中，提示可以向用户通知的仅仅是有未指定的（unspecified）通信事件这一事实，并通常询问是否从全屏或待机状态唤醒电话。在其它实施例中，提示可包括某些允许用户作出有根据的决定的附加信息，例如，关于通信事件是进入的呼叫的指示，和/或关于呼叫者的身份的用户看得见的信息（例如，显示名）。这样的附加信息可以从所接收的推送通知的有用负荷中导出。而且，如果用户接受进入的事件，则在操作系统400b与VoIP客户端402b之间的适当API410可以传递从推送通知有用负荷导出的某些信息直到醒来的应用402b，使得在目的地终端102b上的VoIP客户端402b可以制定响应，并把该响应返回给始发终端102a。这个有用负荷信息可包括机器可读的标识符信息，诸如在通信系统内标识呼叫者的用户名，和/或在网络100内标识呼叫者的终端102a的地址。在替换实施例中，可以存在有VoIP客户端402b的后台状态，由此该VoIP客户端402b被操作系统400b调度以有限的周期，但仍旧是足够的周期来至少在套接字412上收听应用层推送通知，和对所接收的通知执行至少某些处理，甚至是潜在地以便制定接受响应，并在唤醒之前把该响应返回给始发终端（然而仍旧需要唤醒，以便实际进行呼叫，即，一旦进入的和外出的话音和/或视频流开始就处理它们）。通过使用基于操作系统的推送通知服务，该通知被发送到操作系统400b，并至少一开始由操作系统处理（尽管操作系统400b随后传递至少某些有用负荷直到应用402b）。这不同于应用层通知，其中操作系统400b给应用402b调度至少一些周期，这些周期足以让它在相关的套接字上收听推送通知，并且对所接收的通知执行至少某些处理，而不依靠操作系统400b的任何专门的推送通知机制。图5提供按照本发明的一个示例性实现的、VoIP提供者的呼叫控制与通知单元204的示意性框图。网络单元204包括：呼叫控制器502、被耦合到呼叫控制器502的未接呼叫寄存器504、被耦合到呼叫控制器502与基于操作系统的推送通知服务（OSPNS）202的推送通知中心（hub）506、使能推送的端点（PEE）寄存器508、被耦合到呼叫控制器510的解析器功能510、和用于把在始发用户终端102a上的呼叫者客户端402a耦合到呼叫控制器502的连接适配器512。单元502、504、506、508、510、512中的每一个可被实施为软件的模块，这些软件被存储在VoIP提供者204的一个或多个服务器单元的存储器上（以诸如磁或电子存储设备那样的有形存储介质的形式），并被安排成在VoIP提供者204的一个或多个服务器单元上运行。所述一个或多个服务器单元包括被安排来执行软件的处理设备，和被安排来在因特网100或其它这样的基于分组的网络上执行相关通信的收发器设备。目的地用户终端102b可以被登记为使能推送的端点（PEE），且在目的地终端102b上的被呼叫者客户端402b可被安排成能够经由IP套接字412接收来自推送通知中心506的一个或多个应用层推送通知（PN_AL），和/或操作系统400b可被安排成能够接收来自基于操作系统的服务202的、一个或多个基于操作系统的推送通知（PN_OS）。在后者的情形下，在目的地终端102b上的被呼叫者客户端402b可被安排成能够经由API410接收来自基于操作系统的推送通知（PN_OS）中的一个或多个的有用负荷信息。在运行时，在始发终端102a上的呼叫者的VoIP客户端402a通过经由因特网100和连接适配器512形成与呼叫控制器502的连接而开始。该连接可以提供可识别的连接，以使得由呼叫控制器502通过与连接适配器512的给定连接而从呼叫者客户端402a接收的任何通信被识别为源自特定的已知源。连接适配器512可以认证呼叫者的身份，以使得通过与连接适配器512的连接而被接收的任何通信被识别为源自其身份已被安全地验证的源。在步骤S12，呼叫邀请的一个版本作为对等消息通过网络100使用对等连接从客户端402a发送到客户端402b。作为对等消息被发送的呼叫邀请通过使用以上相关于图1描述的技术从客户端402a被路由到客户端402b。为了接收在步骤S12通过使用对等传递机制被发送的呼叫邀请，客户端402b必须在被呼叫者终端102b处在前台运行。在实施例中，连接适配器512提供前端部件，该前端部件通过使用适当的认证机制（它可以是私有的）来认证客户端，以及还终结客户端的连接。连接适配器512然后可以对于服务的其余部分，特别是对于呼叫控制器，用作为客户端身份的权威性源（参见后面相关于图5的讨论）。因此，在实施例中，呼叫者的身份不需要由呼叫者自己在有用负荷中提供，这是有益的，因为不然的话身份可以被伪造，且因而将是不可信任的。在步骤S20和/或步骤S30（对应于图2和图3所显示的那些步骤），在呼叫者的用户终端102a上的客户端402a使用经由连接适配器512的连接把呼叫邀请（CI）的另一个版本发送到VoIP提供者204的呼叫控制器502。可以看到，呼叫邀请的两个版本从客户端402a通过不同的传递机制并行地被发送。在这个意义下，呼叫邀请从客户端402a散开。为了建立呼叫，必须交换握手协议的两个消息，它们形成握手的两半——第一个从一个端点到另一个端点，然后第二握手消息作为回复，同意该呼叫。在实施例中，从呼叫者客户端402a发送的呼叫邀请包括第一握手消息HS1。在实施例中，HS1可以是P2P会话建立消息。在这种情形下，它包含使该消息的接收者能够继续与发送者协商P2P传输会话的足够信息（诸如，可被使用来进行呼叫）。它可包含呼叫者通过其可被联系到的一个或多个IP地址，并潜在地包含一些其它信息。这个消息用作为让P2P会话建立的邀请。一旦认证的和加密的会话被建立，呼叫信令就可以通过该会话流动。中继信息和用户名是与HS1分开的一些东西，且那些可以当在行进的同时HS1不可用或者到期时在回退机制中使用。然而，应当指出，本发明不限于P2P或混合P2P布置，在其它实施例中，会话建立的某些或所有的后续阶段可以经由诸如一个或多个服务器那样的集中式单元进行。响应于接收到来自呼叫者客户端402a的呼叫邀请，呼叫控制器506然后制定内部推送通知请求PNR_i。在实施例中，这牵涉到在步骤S50呼叫控制器502引用解析器功能510来解析呼叫者和/或他或她的用户终端102a的标识符信息—“用户解析”信息（UR）。解析器510维护用户和/或用户终端相关的信息的列表，呼叫控制器502可以根据与连接适配器512的已识别的连接来查询该列表。用户解析（UR）可以归为两类。第一类是标识符信息，它将被使用来允许被呼叫者的客户端402b在响应时联系呼叫者。这可包括：标识VoIP通信系统内的呼叫者的呼叫者用户名；和/或-呼叫者的始发用户终端102b的、在网络内标识其的地址（典型地是IP地址）；和-可选地，附加的路由信息，诸如使用来联系呼叫者的任何一个或多个中继的标识，例如102c。第二类UR信息（其在实施例中可以是可选的）是允许被呼叫者做出关于是否回答呼叫的有根据的决定的信息。这可包括：-呼叫者的显示名（不同于用户名）；-呼叫者的化身图像；和/或-使用来向被呼叫者通知进入的呼叫的语言的指示，其可扩展到规定用于屏幕上通知消息的语法的语言模板，因为屏幕上通知消息将出现在被呼叫者的终端102b处。在实施例中，语言或语言模板可以根据被呼叫者和/或呼叫者的身份被解析。呼叫者的身份（例如，用户名）也将已被包括在呼叫邀请（CI）中，并且它可被使用于这个用途以及识别目的地。在实施例中，解析器功能510还可包括许可检查功能，它维护这样的用户的列表，即：被呼叫者已阻挡所述用户联系他或她。许可检查起到阻挡来自在这个列表中发现的任何呼叫者的呼叫邀请的作用，且用于通知被呼叫者的后面的步骤仅仅在呼叫者没有被阻挡的条件下才进行。假设这没有发生，那么呼叫控制器502制定包括用户解析信息、HS1消息和在呼叫邀请（CI）中接收的任何其它相关信息的有用负荷（参见下文）。在步骤S52，呼叫控制器502然后在内部推送通知请求PNR_i中把这个有用负荷转发到推送通知中心506。可被包括在有用负荷中的附加信息如下。-时间戳，其指示发出邀请的时间。这可被使用来检测建立呼叫的企图何时超时。例如，用于超时的期限可以是在30-60秒范围内，在一个实施例中，是50秒。时间戳可被包括在从呼叫者客户端402a发送的呼叫邀请中，然后在有用负荷中被转发，或者在时间戳还没有被包括在从呼叫者的客户端402a接收的邀请中的情况下，由呼叫控制器502生成。-密钥交换方案的加密密钥，其是呼叫者的公共密钥（所以被呼叫者可以解密呼叫者的内容）。这可被包括在从呼叫者客户端402a发送的呼叫邀请中，然后在有用负荷中被转发，或替换地，被存储在解析器512，并被呼叫控制器502添加作为用户解析信息的另一个实例。-始发端点102a的类型的指示（例如，它是移动电话、平板电脑、膝上型计算机还是台式计算机？它运行什么操作系统，它运行VoIP客户端402a的什么版本，和/或它是什么型号）。再次地，这可被包括在从呼叫者客户端402a发送的呼叫邀请中，然后在有用负荷中被转发，或替换地，被存储在解析器512，并被呼叫控制器502添加作为解析的一部分。-用于呼叫的呼叫标识符（例如，会话标识符），它可被呼叫者的客户端402a或呼叫控制器502添加。再次地，这可被包括在从呼叫者客户端402a发送的呼叫邀请中，然后在有用负荷中被转发，或替换地，被存储在解析器512，并被呼叫控制器502添加。-用于呼叫的谈话标题和/或其它谈话标识符，它是该呼叫作为其一部分的逻辑话题或上下文的指示，例如在呼叫形成牵涉到IM消息和/或先前的呼叫的更广泛谈话的组成部分的情况下。这优选地从来自呼叫者的客户端402a的呼叫邀请中被取得。推送通知中心506接收内部推送通知请求PNR_i。作为响应，在步骤S53，它查询使能推送的端点（PEE）寄存器508，以检查被呼叫者是否已登记接收推送通知。PEE寄存器508维护已登记接收推送通知（或等价地，如果接收推送通知是缺省的话，还没有解除登记接收推送通知）的用户的列表。例如，这可以是当用户第一次启用新的电话102b时呈现给他或她的选项，或是在他或她的终端102b的选项屏幕上发现的选项。随后，当如在所显示的情景下那样试图进行呼叫时，PEE寄存器508采取行动，以便仅仅在被呼叫者同意他或她的设备102b将能够接收推送通知（或等价地没有决定退出）的条件下才许可进行后面的推送通知步骤。假设被呼叫者针对推送通知被登记，推送通知中心则完成以下两件事之一或二者：-发送外部推送通知请求PNR到基于操作系统的推送通知服务202（对应于图2的步骤S22），进而又使得基于OS的推送通知服务202把基于操作系统的推送通知（PN_OS）发送到目的地终端102b上的操作系统400b（对应于图2上的步骤S24）；和/或-制定应用层推送通知（PN_AL），并把它直接发送到目的地终端102b上的被呼叫者的客户端402b（对应于图3上的步骤S32）。可以看到，呼叫邀请的两个版本从推送通知中心506通过不同的传递机制并行地被发送。在这种意义下，呼叫邀请从推送通知中心506散开。因此，呼叫控制器502和推送通知中心506处理在步骤S20从客户端402a接收的呼叫邀请，以生成呼叫邀请的多个版本。另外，在步骤S53，推送通知中心可以把指示被呼叫者的端点数量的消息（NEP）发回到呼叫控制器502（被呼叫者可以使多个设备登记到PEE寄存器508）。这可被呼叫控制器使用来跟踪它可以潜在地预期来自被呼叫者的多少个设备的考勤报告（attendancereport,AR）（参见步骤S56）。推送通知中心506采取行动来把从呼叫控制器502接收的至少某些有用负荷信息包括在推送通知中（在基于OS的推送通知PN_OS的情形下经由OSPNS202）。在实施例中，有用负荷信息的量可以由推送通知中心506根据它要被包括到其中的推送通知的类型，是基于应用层还是基于操作系统，来进行选择。在由推送通知中心506制定的应用层推送通知的情形下，这可包括多达以上讨论的全部量的任何量的有用负荷信息，且包含所述全部量或更多。这可包括握手协议的第一握手消息HS1，和多达全部用户解析信息（UR）的任何信息，包括呼叫者的用户名、始发地址、呼叫者的显示名、用于呼叫者的化身图像（或到化身图像的链接）和语言指示符或模板。这个有用负荷信息在应用层推送通知PN_AL中被提供给被呼叫者客户端402b。如果在被呼叫者的终端102b上的客户端402b接收到应用层推送通知PN_AL，则它提取有用负荷信息，并使用这个信息来向被呼叫者通知进入的呼叫。这可包括提取用户解析信息的用户可读的部分，诸如显示名、化身图像（或到化身图像的链接）和/或语言模板，并使用它来生成适当的屏幕上通知消息。例如，屏幕上消息可以示出化身图像，并显示例如以英语格式“youhaveanincomingcallfrom[displayname]”或以法语格式“[displayname]voustéléphoner”的写下的消息。这个消息的语言和语法（即，语言格式）由语言模板规定。语法规定例如在句子中的什么地方包括显示名。而且，假设被呼叫者回答该呼叫，则在被呼叫者的终端102b上的客户端402b被配置成从推送通知的有用负荷中提取握手消息HS1和用于在响应时联系呼叫者的那部分用户解析信息，由此制定呼叫接受响应（CA），并把该响应用信号通知回呼叫者的终端102a上的始发客户端402a。在接收到HS1后，被呼叫者的客户端402b制定呼叫接受响应CA，其包括握手协议的回答的半部分，HS2消息。在步骤S58，被呼叫者的客户端402b然后根据至少包括呼叫者的用户名和/或呼叫者的终端102a的地址的相关用户解析信息，把这个接受响应用信号通知回始发终端102a上的客户端402a。优选地，这是通过使用有用负荷信息被完成的，不需要在被呼叫者决定是否回答该呼叫之前在网络100上的任何其它信令来检索用于联系呼叫者的终端102a的标识符信息，或检索信息以便向他或她标识呼叫者。对于这些用途，不需要向后的对于诸如单元204或202的任何提供者或运营者基础设施的额外指引（referral）。因此，在呼叫信令中往返行程的数量减小，这意味着用于实现呼叫接受的时间可以减少。在实施例中，被呼叫者的客户端402b可以仅仅在其被发现在通知的时间处于前台（f/g）状态的情况下接收应用层推送通知PN_AL，因为在这个状态下，它具有被调度的足够的处理周期，而能够在IP套接字412上收听并且当应用层推送通知PN_AL被检测到时处理它。然而，在某些实现中，有可能被呼叫者的客户端402b可以被分配以特别的后台状态，由此虽然它被调度以受抑制的处理时间量，但它仍旧具有足够的周期而能够检测和按照应用层推送通知PN_AL行动。在步骤S56，被呼叫者的客户端402b还可以把考勤报告（AR）报告回呼叫控制器502，指示它已接受该呼叫。呼叫控制器502可以使用这个来跟踪呼叫是否被回答，或在呼叫被回答之前它是否超时。在经由服务202生成的基于操作系统的推送通知PN_OS的情形下，这可以包括来自以上讨论的潜在有用负荷信息当中的减小的有用负荷信息量。例如，这可包括握手消息HS1，和某些选择的用户解析信息（UR’），优选地至少是呼叫者的用户名和/或呼叫者的用户终端102a的地址。语言或语言模板仍旧可被用作为有用负荷信息。这个有用负荷信息在基于操作系统的推送通知PN_OS中被提供给目的地终端102b上的操作系统400b。如果被呼叫者的终端102b上的操作系统400b接收到基于操作系统的推送通知PN_OL，则它生成屏幕上消息来向被呼叫者通知进入的呼叫。可选地，这可牵涉到从有用负荷信息提取的某些有限的参数被插入到操作系统400b的预定义的屏幕上消息格式中。例如，进行接收的操作系统400b可以从所接收的有用负荷中确定呼叫者的显示名以及适当的语言模板是英语模板“youhaveanincomingcallfrom[displayname]”或法语模板“[displayname]voustéléphoner”的事实。然而，屏幕上消息格式的其它方面可由操作系统400b支配，例如，它的尺寸、它的“外观和感觉”以及任何相关联的图形。例如，如果被呼叫者在通知的时间正在全屏或另外的占优势的状态下玩视频游戏406或使用某些其它应用，则操作系统可以使得小的通知消息在诸如屏幕的角落那样的相对不引人注意的位置处弹出。由被呼叫者的操作系统400b生成的屏幕上消息提示被呼叫者要采取什么行动，例如，是否接电话，或是否不理会该通知并继续玩游戏406。正如前面讨论的，目的地VoIP客户端406b在进入的通知的时间可能处在后台(b/g)状态。如果在响应操作系统提示时被呼叫者确实选择接受该呼叫，则操作系统唤醒被呼叫者的VoIP客户端402b。这可牵涉到结束先前正在前台中运行的应用（例如，游戏406）的全屏或其它这样的优势状态。在被呼叫者的终端102b上的操作系统400b也将传递至少一定量的有用负荷信息直到新恢复（restore）的VoIP客户端402b，优选地是第一握手消息HS1和至少某些用于在响应时联系呼叫者的用户解析信息，即，呼叫者用户名和/或始发终端地址。当被呼叫者VoIP客户端402b醒来时，它因此能够制定包括返回握手消息HS2的呼叫接受响应CA，并把这个响应定址回呼叫者的用户终端102a上的始发客户端402a。优选地，在推送通知中接收的有用负荷信息因此仍旧足以制定呼叫接受响应（CA），而在被呼叫者决定是否回答该呼叫之前不需要网络100上的任何其它信令来检索用于联系呼叫者的终端102a的标识符信息，或检索用来向他或她标识呼叫者的信息。因此，再次地，在呼叫信令中往返行程的数量，因而是用于呼叫接受的时间可以减少。再次地，在步骤S56，被呼叫者的客户端402b还可以把考勤报告（AR）报告回呼叫控制器502，指示它已接受呼叫。呼叫控制器502可以使用这个来跟踪该呼叫是否被回答，或在呼叫被回答之前它是否超时。在步骤S60，当必要时，呼叫控制器502更新未接呼叫（missedcall）寄存器504。未接呼叫寄存器504存储对于被呼叫者的有关未接呼叫的信息。如果呼叫邀请的各版本没有一个被回答（例如，在它们的超时时段内），则未接呼叫寄存器504被更新，以将有关该呼叫的信息存储为对于被呼叫者的未接呼叫。被呼叫者可以发送查询到网络单元204，用于检索对于该被呼叫者的关于未接呼叫的信息。如果呼叫邀请的任一个版本被回答，则阻止未接呼叫寄存器504被更新来将该呼叫的细节存储为对于被呼叫者的未接呼叫，即使呼叫邀请的某些版本没有被回答。这样，如果呼叫邀请的某些版本，但不是所有版本，没有被回答，则未接呼叫寄存器504将不指示呼叫未接。呼叫邀请的各版本中的呼叫ID和邀请ID的存在使得不同的版本能够与同一个呼叫和同一个呼叫邀请相关联，这样使得未接呼叫寄存器504可以被正确地更新。未接呼叫标记可以在被呼叫者终端102b上实施，其中即使客户端402b没有运行在前台，未接呼叫标记也可以在终端102b上显示给被呼叫者。未接呼叫标记指示对于被呼叫者的、其信息被存储在未接呼叫寄存器504中的未接呼叫的数量。网络单元204可以发送消息到客户端402b以更新未接呼叫标记。在各种实施例中，基于应用层和基于操作系统的推送通知机制并行存在。推送通知中心可以并行尝试这两种通知方法。而且，在始发用户终端102a上的呼叫者客户端402a仍可以用来把常规的P2P呼叫邀请（CI，步骤S10）通过因特网100直接发送到目的地用户终端102b上的被呼叫者客户端402b。不同的传递机制可以适用于不同的状况。因此，通过多种传递机制发送呼叫邀请可以是有利的。例如，当客户端402b在终端102b处运行在前台时，在步骤S12通过对等连接被发送的呼叫邀请或在步骤S32通过基于应用层的推送通知系统被发送的呼叫邀请可以首先被客户端402b接收。然而，当客户端402b在终端102b处是在后台状态时，则它可能不能经由对等连接或经由基于应用层的推送通知系统接收呼叫邀请。因此，在这些情形下，在步骤S24通过基于操作系统的推送通知系统发送的呼叫邀请可以是对于该呼叫的、要由客户端402b接收的第一个（并且可能是唯一的）呼叫邀请。因此，可以意识到，通过多种传递机制发送呼叫邀请的各版本提供了在各种条件下呼叫邀请的快速和可靠的传递。网络条件（例如，网络100上当前的负荷）也可以对在不同传递机制上的呼叫邀请的传递造成不同程度的影响。在一些实施例中，HS1可以不被包括在来自被呼叫者的呼叫邀请（CI）中（步骤S20/S30）。替代地，该交换可能要求被呼叫者在对于初始通知的响应中发送HS1给呼叫者，并且要求呼叫者然后用第二握手消息HS2进行回答，以便建立反向会话。如上所述，网络节点（例如，呼叫者终端102a或控制器网络单元204）可被安排来发送呼叫邀请的多个版本，以用于在呼叫者客户端402a与一个或多个被呼叫者客户端402b之间建立呼叫。呼叫邀请的各版本通过多种不同的传递机制被发送，其中呼叫邀请的多个版本的每个版本包括呼叫的标识符，以及传递机制之一包括在推送信道上的推送通知（例如，在步骤S24或S32）。呼叫邀请的多个版本可以全部被发送到在一个被呼叫者终端102b上实施的一个被呼叫者客户端402b。替换地，呼叫邀请的多个版本可以被发送到在被呼叫者的不同被呼叫者终端102b上实施的不同的被呼叫者客户端402b。例如，呼叫邀请的每个版本可被发送到在被呼叫者的不同被呼叫者终端102b上实施的不同的被呼叫者客户端402b。当呼叫邀请的版本之一被回答时，或者在预定的超时时间（例如，30到60秒）后，呼叫邀请的任何未完成（outstanding）的版本可被取消。在一些实施例中，当呼叫邀请的版本之一被回答时，呼叫邀请的未完成的版本可能不被取消。在这种情形下，如果被呼叫者客户端402b已经接收到包括特定的邀请ID的呼叫邀请的某个版本并随之做出响应（例如，向用户通知呼叫邀请或建立呼叫），以及然后被呼叫者客户端402b接收到也包括该特定邀请ID的呼叫邀请的另一个版本，则被呼叫者客户端402b可以通过使用邀请ID来确定呼叫邀请的某个版本已被接收。在那种情形下，被呼叫者客户端402b可以不必采取进一步的行动。因此，当呼叫邀请的一个版本被回答时，不是取消呼叫邀请的未完成的版本，而是可以允许呼叫邀请的未完成的版本进到被呼叫者客户端402b，其中被呼叫者客户端402b使用邀请ID（或在一些实施例中用呼叫ID）来确定：由于呼叫邀请的一个版本已经由被呼叫者客户端402b接收，所以不需要采取行动来响应于接收到呼叫邀请的新版本。这里描述的方法可以通过执行计算机程序产品而被实施，所述计算机程序产品包括在非瞬态计算机可读介质上体现的代码。在实施例中，一旦以上的呼叫信令被执行，就可以通过像常规P2P方式中那样在被呼叫者与呼叫者之间交换证书而以相互的方式进行用户认证。替换地或附加地，当连接适配器在形成初始连接的时间验证呼叫者的身份时，认证可以由连接适配器集中地执行。在认证是在以上的信令之后通过交换证书而完成的情形下，应当指出，呼叫接受响应CA不是用于成功地进行呼叫的一个绝对的最后准则，而是服从于认证的临时接受（其在大多数情形下多半不是问题，只要通信不是恶意的）。在其它实施例中，认证可以仅仅依靠由连接适配器进行的对于呼叫者的初始认证。在某些实施例中，在建立呼叫的过程中认证的两个阶段均可以使用。第一，呼叫者客户端在连接适配器512上认证它自己，然后通过建立的已认证的传输把邀请发送到呼叫控制器502。这是第一次认证，且它被使用来在服务器204上认证客户。当包含HS1的推送通知到达被呼叫者客户端时，这是用来在客户端之间建立被认证的直接（P2P）连接的第一个步骤，并且这是发生第二次认证的场合。第一阶段是集中式认证，而相反，第二阶段是P2P认证。应意识到，以上的实施例是仅仅作为例子被描述的。例如，虽然以上内容是相对于用于执行VoIP呼叫的混合P2P系统进行描述的，但这里公开的技术可应用到其它类型的基于分组的通信系统。因此，在替换实施例中，在通知之后，会话建立（诸如，可被使用来进行呼叫）的一个、一些或所有的另外的阶段可以替换地经由一个或多个网络集中式单元——诸如一个或多个提供者或运营者的一个或多个服务器——而进行。对于其中使用某些P2P技术的实施例，还应当指出，在它最广泛的意义下，术语P2P不是必然地限于完全去集中化的布置。例如在一些实例中，只有媒体（即，呼叫或其它会话的内容）需要在对等体之间直接传送，而所有其它的呼叫信令（包括地址查找和认证）经由中央单元发生。而且，在以上依据服务器来描述任何网络单元的场合下，应意识到，这不限于单个服务器单元，或者收容在同一个外壳中或位于同一个地点的服务器们。通过一个或多个单元中的任何单元被实施的任何逻辑网络单元可被使用来实施按照本发明的实施例的通信提供者功能。而且，虽然以上内容是依据因特网的通信进行描述的，但本发明也可以被使用于通过其它基于分组的通信网提供通知，和/或通过其它基于分组的通信网告知通信。在给出这里的公开内容后，本领域技术人员可以明白其它变例。本发明不受所描述的实施例限制，而仅仅由所附权利要求限制。