通信事件的通知的制作方法

相关申请

本申请在35 USC 119或365下要求2012年6月14日提交的英国申请No.1210596.1的优先权，该文献的公开内容全部合并于此。

背景技术：

存在各种不同的用于通过诸如因特网之类的基于分组的网络建立现场的基于分组的话音或视频呼叫的通信系统。例如，这样的系统可以使用VoIP(话音互联网协议)技术。一种普及类型的通信系统建立在对等(P2P)拓扑结构上。在传统的P2P系统中，每个最终用户在他或她各自的用户终端(例如台式或膝上型计算机、平板计算机或者手持式移动电话)上安装通信客户端应用程序。每个用户然后向P2P提供商的服务器注册以便获得认证证书。一些用户终端也将变成分布式数据库的节点，其将P2P通信系统内的用户的用户名映射到该系统通过其实现的网络内的各个不同的用户终端的地址(典型地为IP地址)。于是，最终用户之间的通信可以在呼叫设立或者认证过程中不涉及集中式服务器的情况下进行。相反地，呼叫者的终端上的客户端查询分布式数据库的一个或多个节点(即呼叫中以任何其他方式涉及的其他最终用户(不一定是他们自己)的一个或多个终端)以便确定预期的被呼叫者的终端的地址。呼叫者然后使用所确定的地址向被呼叫者发送呼叫邀请，并且被呼叫者以呼叫接受响应进行响应。呼叫者和被呼叫者交换他们的认证证书以便对彼此进行认证。

每个用户也维持联系人列表，该联系人列表可以存储在P2P提供商的服务器上，使得它即使在用户登录到不同的终端上的情况下也可用。其他诸如每个用户的简档信息(例如化身(avatar)图像或者情绪消息)之类的辅助信息也可以存储在服务器上。此外，客户端应用程序也彼此交换存在性信息。该存在性信息指示用户的可用性状态，并且至少部分地由用户他自己或她自己定义。例如，存在性可以指示用户是否离线、在线但是选择成不可用(“请勿打扰”)或者在线并且选择成可用。例如，每个客户端可以周期性地轮询其联系人列表中的每个联系人以便确定他们各自的存在性，和/或每个客户端可以周期性地向其列表中的每个联系人发送出存在性更新。存在性典型地基于P2P技术在最终用户之间直接地而不是经由服务器用信号发送。当进行呼叫时，呼叫者的客户端基于最新的存在性信息确定被呼叫者是否可用来接受呼叫。

技术实现要素：

依照本发明的实施例，提供了一种通信提供商的网络元件，该网络元件包括：收发器装置，其被设置成经由基于分组的通信网络接收来自始发端点的请求消息；以及处理装置。处理装置被配置成响应于来自始发端点的请求消息而生成与来自始发端点的预期用于目的地端点的通信有关的推送通知，该通信要通过基于分组的网络进行。收发器装置被设置成通过基于分组的网络将推送通知发送至目的地端点。处理装置进一步被配置成利用包括代表始发用户的图像的指示的有效载荷生成推送通知，以便在就所述通信通知目的地用户的用户通知中由目的地端点输出。至少所述图像的指示在所述网络元件处被确定并且插入到推送通知的有效载荷中。

依照本发明的另外的实施例，提供了一种相应的方法和计算机程序产品。

本发明内容被提供来以简化的形式引入构思的选择，这些构思在下面的具体实施方式中进一步加以描述。本发明内容并不预期识别要求保护的主题的关键特征或基本特征，也不预期限制要求保护的主题。要求保护的主题也不限于解决现有系统的所提到的缺点中的任何一个或全部的实现方式。

附图说明

图1为依照一个或多个实施例的通信系统的一个示意图。

图2为依照一个或多个实施例的通信系统的另一个示意图。

图3为依照一个或多个实施例的通信系统的另一个示意图。

图4为依照一个或多个实施例的两个用户终端的示意图，以及

图5为依照一个或多个实施例的网络元件和两个用户终端的示意图。

具体实施方式

随着能够运行诸如VoIP客户端之类的通信客户端应用程序的手持式移动电话的日益流行，存在越来越多数量的端点可用于参与通过因特网等等实现的VoIP通信系统或者其他这样的基于分组的通信系统。然而，也可能出现的一个问题是，移动电话手持送受话器典型地具有比传统台式或膝上型计算机更有限的资源，例如每单位时间能够执行更少的处理周期，每处理周期具有更少的功能，具有更有限的存储器资源(例如RAM和/或缓存)和/或具有更少的屏幕区域资源。因此，一些终端上的操作系统(OS)可以将特定应用程序置于背景状态下。这可以包括通信客户端。在背景状态下，背景化应用程序可以完全暂停，或者以不能够检测到来的呼叫邀请和/或处理传统的呼叫邀请的程度每单位时间被调度有限的处理周期。例如，这可能在另一个应用程序正在前景状态下运行的情况下，尤其是在其他应用程序在处理、存储器和/或屏幕资源方面密集，例如运行于全屏模式或者像主导应用程序那样当前具有某种其他状态的情况下发生。一个实例将是在移动电话上玩的计算机游戏。在这样的情况下，如果客户端不能够发送出存在性更新或者对来自其他用户的存在性轮询进行响应，那么用户根据他或她的存在性可能看起来是离线的。然而，用户可能仍然希望可用于接受呼叫，例如将宁愿中断视频游戏而不是错过呼叫。因此，传统的存在性概念开始被打破。类似的问题可能潜在地发生在具有能够将特定应用程序置于背景状态下以利于一个或多个其他应用程序的特征的任何终端上。因此，可能希望的是远离用于呼叫设立的P2P方法，或者至少远离纯粹的P2P方法。

诸如在基于分组的网络上实现的常规P2P系统之类的通信系统可能出现的另一个问题上呼叫信令的速度，尤其是在呼叫被应答之前要花费多长时间，或者要花费多长时间确定呼叫未被应答。这尤其是(但非排他性地)在被呼叫者的客户端如上面所讨论的处于背景状态下时可能是个问题，其中呼叫者可能必须在他或她被通知被呼叫者不可用之前等待企图的呼叫邀请超时。呼叫信令延迟也可能发生在其他情形中以及其他类型的通信系统中。

因此，可能希望的是提供一种改进的或者可替换的向目的地用户终端通知呼叫或者其他通信事件的方式。

一些其他类型的通信系统使用推送通知来通知通信事件的目的地用户终端。推送通知是在服务器或者另一个始发元件的指使下而不是在目的地终端本身的指使下(即与由目的地终端拉拽相反)从服务器发送的通知。因此，推送通知可以被认为与目的地终端异步。例如，常规上，这样的推送通知可以用来指示来源于始发用户终端的IM(即时消息传递)聊天消息或者文件传输在服务器处的可用性。

然而，在过去，“原始”推送通知仅仅通知目的地终端在服务器处存在等待它的某种通信。目的地终端于是仍然必须轮询服务器以便确定等待通信的性质，即确定它被通知的事件的性质，并且响应于接收到推送通知而从服务器拉拽涉及事件的性质的有关信息。因此，例如，这意味着一旦目的地终端接收到通知，那么它仍然必须向后参阅服务器以获得允许目的地用户就他或她是否希望获得所述通信做出明智决定的信息(如果这样的话，在此之前再次回去取回等待通信，例如取回等待IM聊天消息或者文件传输)。

如果例如这样的推送通知系统直接适于向用户通知呼叫邀请，使得原始通知用来从背景状态唤醒目的地客户端应用程序，那么在唤醒时目的地客户端于是将不得不轮询服务器以便发现它为什么被唤醒(即确定提议了呼叫)并且发现使得它能够对呼叫邀请进行响应的始发终端或者呼叫者的身份。这可能把不希望的延迟引入到呼叫信令中。

此外，获取的信息的性质可能仍然用途有限，并且不一定适合所述通信的特定预期接受者或者所述通信的特定发送者或者发送者和接受者的组合。

依照本发明的实施例，提供了一种扩增推送通知机制，其中推送通知包括有效载荷，该有效载荷携带使得目的地用户能够就是否接受呼叫或通信做出明智决定的信息。特别地，有效载荷信息至少包括代表始发用户——例如到来的话音或视频呼叫的情况下的呼叫者的图像的指示。

该图像可以称为始发用户(例如呼叫者)的“化身”，并且可以是例如在其他用户从VoIP提供商或者其他通信提供商的服务器观看该用户的简档时通信系统内出于其他目的用来代表该用户的相同图像。

在实施例中，所述图像的指示包括插入到推送通知的有效载荷中的图像本身，从而接受者终端(例如被呼叫者的终端)不必在确定始发用户(例如呼叫者)的身份之前执行取回图像的附加呼叫信令。

在可替换的实施例中，所述图像的指示可以包括到图像的链接，该链接允许目的地终端以最少的附加信令获取图像。

有效载荷可选地可以包括其他的信息，例如所述通信的类型的指示(例如呼叫、IM、话音邮件、文件传输)；始发用户的附加指示(例如用户名和/或显示名)；用于通知的语言或语言模板；始发终端的地址；始发终端的类型的指示；始发用户的加密密钥；时间戳；提议的通信会话的会话标识符(例如提议的呼叫的呼叫ID)；用于通信的交谈标识符；和或用于通信的任何中继器的指示。

在实施例中，由于在推送通知本身中提供了附加用户信息，因而在通知的时间，接收用户能够更好地确定他或她是否希望接受关联的通信或通信会话(例如提议的呼叫)。在特定的实施例中，这在不一定必须首先从通信提供商的网络元件中取回附加信息以便确定到来的通信的性质和/或发送者的身份的情况下实现。这有利地减少了双程的数量并且因而降低了信令延迟。

如所提到的，诸如手持式移动电话之类的现代移动设备现在能够运行通信客户端应用程序以便通过诸如因特网之类的基于分组的网络而不是仅仅经由移动电话的专用蜂窝话音通道执行诸如VoIP或者其他基于分组的话音或视频呼叫之类的基于分组的通信。利用该能力，迎来在线且可呼叫或者可联系的用户数量的急剧增加。然而，这样的用户的客户端应用程序也可能潜在地被发现在呼叫时处于背景状态下，由此客户端被暂停，或者至多被移动设备的操作系统调度非常有限的资源——从而需要被唤醒以便接收到来的呼叫。

在这样的操作系统制度下——其中应用程序不再可以保证能够在背景中处理诸如到来的呼叫、聊天等等之类的事件——VoIP或者其他通信提供商的架构将受益于扩展。例如，这在以下情况下将是有益的：提供商希望能够将呼叫(和其他)通知输送至它们的通信系统的用户，即使这些用户“背景化”了有关的通信客户端应用程序(或者让该应用程序由操作系统背景化)，但是虽然如此其仍然在线并且因此潜在地可呼叫或者可联系。也可以修改客户端应用程序的呼叫部件以确保呼叫用户的初始意图可以可靠地输送至其中用户应当能够——经由推送通知(如果需要的话)接收呼叫(或者其他通信)的所有端点。

例如，考虑其中被呼叫者在等待他或她的朋友呼叫(也许来自国外，因此出于成本的原因偏好使用VoIP)的同时正在手持式电话或者平板计算机上使用web浏览器或者玩视频游戏的使用情况。被呼叫者基于存在性状态检查朋友是否在线，但是当他或她不在线时，被呼叫者开始浏览或者玩以填补时间。接着，朋友(呼叫者)随后登录到例如台式计算机上的他或她的客户端应用程序，准备好呼叫被呼叫者。在实施例中，可以修改被呼叫者的客户端以便将被呼叫者向呼叫者显示为在线，即使被呼叫者的客户端应用程序由于浏览器或游戏需要消耗的高系统资源的原因，例如由于在浏览器中运行的flash应用程序或者其他小应用程序的原因而由被呼叫者的操作系统暂停或者抑制。在本发明的实施例中，呼叫者点击呼叫按钮以发起与被呼叫者的呼叫，并且被呼叫者的操作系统被配置成弹出向他或她通知到来的呼叫的提示。被呼叫者的客户端应用程序被配置成使得如果被呼叫者响应于提示碰触或者点击接受按钮，那么客户端应用程序在被呼叫者的终端上被带回到前景中，从而允许被呼叫者对呼叫(话音或视频)进行应答并且开始与他的朋友或者呼叫者交谈。

在该示例性方案中存在一些要指出的元素。被呼叫者客户端的状态在最坏的情况下潜在地是完全暂停的(终止)，并且因此不会由常规的P2P会话建立方法达成。在本发明的实施例中，被呼叫者可能不知道或者注意到他或她的客户端应用程序被暂停，因为这可以不由被呼叫者用户显式地完成——事实上恰恰相反，这可能由操作系统自动地完成，并且被呼叫者可能假定他或她的客户端应用程序仍然在运行，并且他们在线且可达到。此外，在此方案中，与用于这样的系统的常规存在性机制不同的是，没有使得存在性依赖于(或者不仅仅依赖于)客户端的P2P可用性。

为了支持上面的方案，提供商可以实现新的呼叫部件和/或对现有的部件做出必要的改变。

一个目标是让被呼叫者客户端唤醒并且能够在适当的时间表和范围内与呼叫者客户端建立会话(例如P2P会话)。为了保持呼叫设立时间尽可能短，只要有可能，就应当将会话和呼叫建立中的双程保持为最少。

如上面的实例方案中所示范的，呼叫发起流可以支持需要经由非P2P消息输送系统用信号发送呼叫的意图的使用情况，这可以在需要的情况下回退到推送通知以便唤醒被呼叫者客户端。例如，这可以借助于由所讨论的操作系统的提供商提供的推送通知服务。

可以更新呼叫部件以便例如在核心库中实现必要的客户端部件变化，以确保它们迎合所有需要的使用情况、互操作性和后向兼容性方案。

可以更新呼叫客户端部件以便允许被呼叫者客户端接受借助于推送通知输送方法接收的到来的呼叫邀请。这可以包括允许客户端UI(用户接口)层将接收的有效载荷信息传递至呼叫部件、使得P2P会话建立和呼叫设立及信令能够进行的一个或多个UI API(应用编程接口)的集合。

为了将呼叫有关信息包括在经由消息输送系统输送至被呼叫者端点的消息的有效载荷中，呼叫功能可以支持基于云的服务，这些服务接收来自输送基础设施的消息并且填入该呼叫特定有效载荷信息。

呼叫通知将包括足够的信息以便允许被呼叫者就是否应答呼叫做出明智的决定。这可以包括例如呼叫者姓名(用户名和/或显示名)、呼叫者的化身和/或呼叫邀请的时间戳。呼叫通知也可以包括诸如握手消息之类的允许被呼叫者客户端制定接受响应的信息，以及允许作为响应联系呼叫者的信息(例如呼叫者用户名和/或地址)。

一旦输送系统的呼叫通知器完成了以上所述，那么传递呼叫通知以便最终输送至被呼叫者端点。这将在被邀请参加呼叫的用户为接收推送通知进行了注册的情况下或者在存在到客户端的开放式连接的情况下发生。通知可以通过直接的持久连接(被呼叫者客户端处于前景中和/或一些背景状态)，或者在需要的情况下经由推送通知到达基于有关操作系统的通知服务(被呼叫者客户端被暂停和/或一些其他背景状态)。

参与呼叫的邀请在若干情况下可以由呼叫方发出，这些情况例如：在实际呼叫建立之前，作为发起的部分；或者在进行中的呼叫期间，将另一个参与者添加到呼叫。

图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上的客户端然后使用该地址向预期的被呼叫者的终端102b上的客户端用信号发送呼叫设立请求或者“邀请”(CI)。作为响应，如果被呼叫者选择接受呼叫，那么被呼叫者终端102b上的客户端向后用信号发送呼叫接受响应。呼叫者和被呼叫者的终端102a和102b上的客户端也交换认证证书以便验证彼此的身份。这些客户端因此建立彼此之间的会话以便作为现场话音或视频呼叫的一部分发送来自其各自终端102、102b上的麦克风和/或视频照相机的实时话音和/或视频内容形式的通信量。由于地址查找基于分布式数据库，因而不必涉及用于这个目的的中央服务器。呼叫设立信令、认证和呼叫通信量也在无需涉及中央服务器的情况下进行。

在实施例中，如果呼叫者的用户终端102a由于NAT(网络地址转换)或者防火墙108的原因而不能直接与被呼叫者的用户终端102b通信，那么这些客户端可以被设置成经由也可以由在P2P通信系统的一个或多个其他用户的最终用户终端102d上运行的客户端实现的一个或多个中继器通信。中继最终用户终端102d的用户不必是呼叫的参与者(不必消耗呼叫的话音或视频内容，并且由于加密的原因而的确不能)。尽管如此，中继最终用户终端102d的用户在他或她签约到P2P通信系统时同意这样的情形，并且他自己或者她自己在其他场合下可以受益于互惠的安排。

通信系统可以进一步包括耦合到因特网100的后端服务器104，其中所述客户端中的每一个可以存储各自的联系人列表，该列表是其各自用户的联系人的列表(通信系统被配置成使得用户变成相互协议的联系人)。后端服务器104也可以存储用于每个用户的简档信息，例如用于向通信系统内的其他用户代表对应用户的化身图像。每个客户端可以访问和显示联系人的简档，使得呼叫者可以看见被呼叫者的简档信息，并且反之亦然。

通信系统也可以包括耦合在因特网100与电路交换网络(未示出)之间的网关106。这样的网络可以被称为PSTN(公共交换电话网络)，例如陆线网络，或者诸如3GPP网络之类的移动蜂窝网络。用户终端102上的客户端由此也能够经由网关106而与更传统的电话建立呼叫。

图2图示出依照本发明实施例的修改的混合P2P通信系统。图1的一些或者全部部件也可以仍然与图2的系统并行地存在，但是为了简明起见一些部件从图2中省略。此外，通信系统包括通信服务提供商(例如VoIP提供商)的、耦合到因特网100并且被设置成运行呼叫控制和通知软件的一个或多个服务器单元的形式的网络元件204。通信系统也包括耦合到因特网100的一个或多个基于操作系统的推送通知服务(OS PNS)202。所述一个或多个基于操作系统的推送通知服务202中的每一个与对应的操作系统关联，并且由操作系统的制造商和/或发布商提供以便支持经由所讨论的操作系统可用的专用推送通知机制。基于操作系统的推送通知服务202采取被设置成运行推送通知软件的一个或多个服务器单元的形式。

在图2的示例性系统中，图示的元件102、202、204被配置成如下操作。在步骤S20处，呼叫者的用户终端102a上的客户端将呼叫邀请(CI)不直接发送到被呼叫者的用户终端102b上的客户端，而是发送到VoIP提供商的呼叫控制和通知元件204(消息CI不一定与关于图1所描述的消息相同)。在步骤S22处，响应于接收到来自呼叫者的呼叫邀请，VoIP提供商的呼叫控制和通知元件204生成它发送至基于操作系统的推送通知服务202的推送通知请求(PNR)。在步骤S24处，响应于接收到来自VoIP提供商204的推送通知请求，操作系统的推送通知服务202将基于操作系统的推送通知(PN_OS)发送至被呼叫者的用户终端102b上的操作系统。基于操作系统的推送通知由被呼叫者的用户终端102b上的操作系统接收和处理，使得它在被呼叫者的用户终端102b的屏幕上显示向被呼叫者用户指示存在到来的事件的弹出消息。

在本发明的实施例中，屏幕上消息可以提示被呼叫者是否接受到来的呼叫。如果被呼叫者的客户端应用程序当前是背景化的，那么屏幕上消息可以提示用户是否从背景状态唤醒被呼叫者的客户端应用程序。在实施例中，可以将这些动作组合到相同的提示中。如果作为响应，被呼叫者以肯定方式提供用户输入，那么操作系统通过重新调度至完全操作水平或者至少给被呼叫者的终端102上的被呼叫者客户端应用程序调度处理呼叫的足够资源而唤醒该被呼叫者客户端应用程序。

如下文中更详细地讨论的，在实施例中，推送通知PN_OS可以包括使得被呼叫者的用户终端102b上的客户端能够直接通过因特网100而不是经由提供商或者服务元件202和204中的任何一个的服务器制定返回握手消息和信号的有效载荷，所述返回握手消息和信号通过因特网100向后通告呼叫者的用户终端102a上的客户端。如果被呼叫者接受来自操作系统的用户提示，那么被呼叫者的用户终端102b上的操作系统将推送通知的有效载荷的至少一部分向上传递至被呼叫者的客户端应用程序以便它可以制定有关响应并且向后将该响应发送至呼叫者。

图3图示出依照本发明实施例的另一个修改的混合P2P通信系统。图1和/或图2的一些或者全部部件也可能仍然与图3的系统并行地存在，但是为了简明起见一些部件从图3中省略了。

在图3的示例性系统中，图示的元件102、204被配置成如下操作。在步骤S20处，呼叫者的用户终端102a上的客户端同样地将呼叫邀请(CI)不直接发送到被呼叫者的用户终端102b上的客户端，而是发送到VoIP提供商的呼叫控制和通知元件204(消息CI不一定与关于图1所描述的消息相同)。在实施例中，这可以是与关于图2所描述的步骤相同的步骤，或者在其他实施例中，它可以是可替换的或者附加的单独步骤。然而，在这种情况下，VoIP提供商元件204不发送(或者不仅仅发送)推送通知请求(PNR)至操作系统的推送通知服务202。相反地，它直接制定它自己的应用层推送通知(PN_AL)，它直接通过因特网100将该应用层推送通知发送至被呼叫者的用户终端102b上的客户端。被呼叫者的用户终端102b上的客户端然后可以在应用层处理该通知以便自己借助于应用层机制而不是上面描述的操作系统机制就到来的呼叫提示被呼叫者用户。

如下文中更详细地讨论的，在实施例中，推送通知PN_AL包括使得被呼叫者的用户终端102b上的客户端能够直接通过因特网100而不是经由提供商或者服务元件202和204中的任何一个的服务器制定返回握手消息和信号的有效载荷，所述返回握手消息和信号通过因特网100向后通告呼叫者的用户终端102a上的客户端。在这种情况下，如果被呼叫者的终端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和电子邮件客户端404之类的其他应用程序。这种方案尤其可能发生在诸如手持式移动电话之类的移动终端上，在该移动终端处，资源与比如台式计算机相比相对有限。

前景状态的另一个实例可以包括这样的状态，其中没有一个应用程序相对于任何其他应用程序具有主导状态，例如，终端102b的用户具有没有应用程序被最大化的开放式台式机，并且操作系统400b允许VoIP应用程序402b具有足够的处理资源以进行完全操作、不受抑制以利于诸如视频游戏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)。目的地客户端402b可以为此目的让持久连接对于提供商的网络元件204开放。

在实施例中，在背景状态下，VoIP客户端402b没有调度的周期，并且必须依赖于基于操作系统的推送通知服务202，或者具有太有限的周期而不能依赖于除了基于操作系统的推送通知服务之外的任何事物。在这种情况下，基于操作系统的推送通知(OS_PN)由操作系统400b接收，作为响应该操作系统在目的地终端102b上显示屏幕上提示。该提示通知被呼叫者存在请求注意的通信事件，并且提示用户选择是否退出全屏模式或者以其他方式允许唤醒一个或多个休眠的应用程序。屏幕上提示的格式可以由操作系统400b决定，可选地具有可以在推送通知中指定的少数参数。在一些实施例中，该提示可以向用户通知仅仅存在未指定的通信事件这一事实，并且通常询问是否从全屏或者待机状态唤醒电话。在其他实施例中，该提示可以包括一些允许用户做出明智的决定的附加信息，例如通信事件为到来的呼叫的指示，和/或涉及呼叫者身份的用户可观看信息(例如显示名和/或化身图像)。这样的附加信息可以从接收的推送通知的有效载荷中导出。

此外，如果用户接受，那么操作系统400b与VoIP客户端402b之间的适当API 410可以将从推送通知有效载荷中导出的特定信息向上传递到唤醒的应用程序402b，使得目的地终端102b上的VoIP客户端402b可以制定响应并且向后将该响应返回始发终端102a。该有效载荷信息可以包括机器可读标识符信息，例如识别通信系统内的呼叫者的用户名和/或识别网络100内的呼叫者的终端102a的地址。

在可替换的实施例中，可以存在VoIP客户端402b的背景状态，其中它被操作系统400b调度有限的周期，但是这些周期仍然足以至少侦听套接字412上的应用层推送通知并且对接收的通知执行至少某种处理，甚至潜在地以便制定接受响应并且在唤醒之前将其返回到始发终端(尽管可能仍然需要唤醒来实际地进行呼叫，即一旦到来和出去的话音和/或视频流开始，则处理这些流)。

使用基于操作系统的推送通知服务，通知被发送至操作系统400b并且至少初始时由操作系统处理(即使操作系统400b随后将有效载荷中的至少一些向上传递至应用程序402b)。这不同于应用层通知，其中操作系统400b给应用程序402b调度至少一些周期，这些周期足够该应用程序侦听有关套接字上的推送通知并且在不依赖于操作系统400b的任何特殊推送通知机制的情况下对接收的通知执行至少某种处理。

图5提供了依照本发明一个实例实现方式的VoIP提供商的呼叫控制和通知元件204的示意性框图。网络元件204包括：呼叫控制器502，耦合到呼叫控制器502的未接呼叫注册器504，耦合到呼叫控制器502和基于操作系统的推送通知服务(OS PNS)202的推送通知中心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可以被设置成能够经由API 410接收来自基于操作系统的推送通知(PN_OS)中的一个或多个的有效载荷信息。

在操作中，始发终端102a上的呼叫者的VoIP客户端402a通过经由因特网100和连接适配器512与呼叫控制器502形成连接而开始。该连接可以提供可识别的连接，使得由呼叫控制器502通过与连接适配器512的给定连接接收来自呼叫者客户端402a的任何通信被识别为源于特定的已知来源。连接适配器512可以认证呼叫者的身份，使得通过与连接适配器512的连接接收的任何通信都被识别为源于其身份被安全地验证的来源。

在实施例中，连接适配器512提供前端部件，该前端部件使用适当的认证机制(其可以是专有的)对客户端认证并且也终止客户端的连接。连接适配器512于是可以用作针对其余服务以及尤其是呼叫控制器502而言的客户端身份的权威来源(参见以后的讨论)。在实施例中，因此，不必由呼叫者自己在有效载荷中提供呼叫者的身份，这是有利的，因为否则的话身份可能被伪造并且因而不被信任。

在步骤S20和/或步骤S30(与图2和图3中所示的步骤相应)处，呼叫者的用户终端102a上的客户端402a经由连接适配器512使用所述连接将呼叫邀请(CI)发送至VoIP提供商204的呼叫控制器502。

为了建立用于进行诸如呼叫之类的通信的会话，有必要交换形成握手的两半的两个握手协议消息——第一个从一个端点到另一个端点，并且然后第二个握手消息作为回报同意呼叫。在实施例中，从呼叫者客户端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处显现时其可以扩展到指定用于屏幕上通知消息的句法的语言模板。

依照本发明的实施例，插入到推送通知的有效载荷中的UR信息包括代表呼叫者(或者更一般地为始发用户，即始发端点的用户)的图像。为此目的，解析器510包括对着所讨论的通信系统的多个用户的身份绘制的代表性图像的数据库。于是，解析器510被配置成基于呼叫者的身份解析有关图像的指示，并且将该图像插入到有效载荷(或者可替换地，可以在通知时由被呼叫者访问的到图像的链接)中。

在一个或多个实施例中，图像为化身图像，其通常与也由呼叫者(或者始发用户)在所讨论的通信系统内(例如在VoIP系统内)更广泛地用来代表他们自己的图像基本上相同(就图像内容而言)。例如，化身图像也可以可由被呼叫者或者其他联系人从通信提供商的服务器104访问。元件204的解析器510可以与提供简档的后端服务器104集成，使得解析器510访问用户在其他情况下通常轮询呼叫者的简档时访问的图像的相同实例(相同拷贝)。可替换地，解析器510可以被设置成访问相同图像的不同实例(相同内容的不同拷贝)。在实施例中，不管哪种方式，如插入到有效载荷中的实例都可以是图像的尺寸减小的实例(就比特和/或屏幕上尺寸而言)。

在实施例中，解析器510进一步包括对着所讨论的通信系统的多个用户的身份绘制的民族、住所和/或语言的列表。于是，解析器510被配置成基于被呼叫者和/或呼叫者的身份解析语言或语言模板。呼叫者的身份(例如用户名)也可以包含在呼叫邀请(CI)中，并且可以用于这个目的以及识别目的地。在一个或多个实施例中，选择的语言(以及可选地语言模板)基于被呼叫者(或者更一般地接受者)的民族、语言和/或住所而被选择，因为这是所述通知预期要通知的人。然而，如果这不可用，那么最佳的猜测可以是，被呼叫者或者接受者理解呼叫者(或者更一般地发送者)的语言。

在一些实施例中，解析器510被配置成基于呼叫者和被呼叫者二者的身份而通过确定这两个用户的共同的语言来解析语言或语言模板。

在实施例中，解析器功能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的呼叫邀请。

如果通知系统可以用于不同类型的通信(除了话音和视频呼叫之外，例如IM消息、话音邮件和/或文件传输)，那么有效载荷也可以包括通信类型的指示。

推送通知中心506接收内部推送通知请求PNR_i。在步骤S53处，作为响应，它查询推送使能端点(PEE)注册器508以便检查被呼叫者是否已经注册以接收推送通知。PEE注册器508维持已经注册以接收推送通知(或者在接收推送通知为缺省的情况下，等效地说没有取消注册以免接收推送通知)的用户列表。例如，这可以是向用户呈现何时他或她初次启动新电话102b的选项，或者他或她的终端102b的选项屏幕中发现的选项。随后，当像在图示出的方案中那样企图进行呼叫时，PEE注册器508起作用以便仅仅许可以下推送通知步骤在被呼叫者同意他或她的设备102b将能够接收推送通知(或者等效地说没有决定退出)的条件下进行。

假设被呼叫者为推送通知进行了注册，那么推送通知中心做两件事情中的一件或者两件：

将外部推送通知请求PNR发送至基于操作系统的推送通知服务202(与图2的步骤S22相应)，这进而造成基于操作系统的推送通知服务202将基于操作系统的推送通知(PN_OS)发送至目的地终端102b上的操作系统400b(与图2中的步骤S24相应)；和/或

制定应用层推送通知(PN_AL)并且将其发送至目的地终端102b上的被呼叫者的客户端402b(与图3中的步骤S32相应)。

此外，在步骤S53处，推送通知中心可以向后将指示被呼叫者的端点数量的消息(NEP)发送至呼叫控制器50(被呼叫者可能具有向PEE注册器508注册的多个设备)。这可以由呼叫控制器用来跟踪可以潜在地期望来自被呼叫者的多少设备的出席报告(AR)(参见步骤S56)。

推送通知中心506作用来将接收自呼叫控制器502的有效载荷信息中的至少一些包含在推送通知中(在基于操作系统的推送通知PN_OS的情况下，经由OS PNS 202)。在实施例中，有效载荷信息的数量可以由推送通知中心506根据要将该信息包含于其中的推送通知的类型(基于应用层的还是基于操作系统的)进行选择。

在推送通知中心506制定应用层推送通知的情况下，这可以包括任何数量的有效载荷信息，直到且包括上面讨论的全数或者更多。这可以包括握手协议的第一握手消息HS1以及直到全用户解析信息(UR)的任何事物，包括呼叫者的用户名、始发地址、呼叫者的显示名、用于呼叫者的化身图像(或者到化身图像的链接)以及语言指示器或模板。该有效载荷信息在应用层推送通知PN_AL中被提供给被呼叫者客户端402b。

如果被呼叫者的终端102b上的客户端402b接收到应用层推送通知PN_AL，那么它提取有效载荷信息并且使用该信息向被呼叫者通知到来的呼叫。这可以包括提取用户解析信息的用户可读部分，例如显示名、化身图像和/或语言模板，并且使用它生成屏幕上通知消息形式的适当用户通知。例如，屏幕上消息可以示出化身图像并且显示格式为“您有来自[显示名]的到来的呼叫”的书面消息。可替换地，用户通知可以采取来自目的地终端102b的扬声器的可听口语消息的形式。

用户通知消息的语言(换句话说，书面或口头语言，即语感语言)基于推送通知的有效载荷中接收的指示来确定。例如，这可以从包括以下中的两个或更多的组中指定语言：英语，法语，德语，荷兰语，西班牙语，葡萄牙语，意大利语，希腊语，罗马尼亚语，匈牙利语，保加利亚语，捷克语，波兰语，瑞典语，芬兰语，挪威语，爱沙尼亚语，拉脱维亚语，立陶宛语，乌克兰语，俄语，土耳其语，阿拉伯语，普通话，粤语，日语，越南语，韩语，台语，泰语，印地语，乌尔都语，孟加拉语，旁遮普语，马拉地语，泰卢固语，普什图语，爪哇语，南非荷兰语，手语等等。

在本发明的实施例中，用户通知消息的形式基于推送通知的有效载荷中接收的语言模板所限定的句法来确定。句法的至少一个功能是指定语句中(或者更一般地，文本或语音的部分中)包括显示名的位置。其他的语言格式化信息也可以包含在句法中，例如何处放置到来的通信事件类型的指示(呼叫、话音呼叫、视频呼叫、IM、话音邮件、文件传输等等)。

例如，在英语中，用户通知可以采取形式“you have an incoming call from[显示名]”，呼叫者或者发送者的姓名处于语句的结尾，而在法语中，例如它可以采取形式“[显示名]vous téléphoner”，呼叫者或者发送者的姓名处于语句的开头。要在字符串中插入姓名的位置可以是解析器510选择的语言的函数，并且因此句法与语言相应。语言和句法(即语言格式)由语言模板指定。

此外，假设被呼叫者应答呼叫，那么被呼叫者的终端102b上的客户端402b被配置成从推送通知的有效载荷中提取诸如握手消息HS1之类的会话建立信息以及用于作为响应联系呼叫者的用户解析信息的部分，并且从而制定呼叫接受响应(CA)且向后将该响应用信号发送至呼叫者的终端102a上的始发客户端402a。呼叫接受响应接受会话的建立，意图是使用该会话进行呼叫。例如，接收HS1之后，被呼叫者的客户端402b制定呼叫接受响应CA，该呼叫接受响应包括握手协议的半应答，HS2消息。然后，在步骤S58处，被呼叫者的客户端402b基于至少包括呼叫者的用户名和/或呼叫者的终端102a的地址的有关用户解析信息，向后将该接受响应用信号发送至始发终端102a上的客户端402a。

通过使用有效载荷信息，这在无需在他或她决定是否应答呼叫之前通过网络100的任何其他信令以获取用于联系呼叫者的终端102a的标识符信息，或者获取向被呼叫者识别呼叫者和/或确定用户通知的格式的信息的情况下完成。为了这些目的，无需向后对于诸如元件204或202之类的任何提供商或者运营商基础设施的额外引用。因此，呼叫信令中双程的数量减少，这意味着用于实现呼叫接受的时间可以减少。

在实施例中，被呼叫者的客户端402b可以在其被发现在通知的时间处于前景(f/g)状态的情况下仅仅接收应用层推送通知PN_AL，因为在这种状态下，它具有被调度的足够处理周期，能够在IP套接字412上侦听并且在检测到时处理应用层推送通知PN_AL。然而，在某些实现方式中，有可能被呼叫者的客户端402b可能被分配特殊背景状态，其中尽管它被调度受抑制数量的处理时间，但是它仍然具有足够的周期，能够检测并且作用于应用层推送通知PN_AL。

被呼叫者的客户端402b也可以在步骤S56处向后向呼叫控制器502报告指示它已经接受了呼叫的出席报告(AR)。呼叫控制器502可以使用该报告跟踪呼叫是否被应答，或者呼叫在其被应答之前是否超时。可替换地，出席报告(AR)可以在始发者接收到来自目的地的响应时由该始发者发送。后一选项可以在以下情况下使用：呼叫在目的地侧由未利用发送出席报告的功能更新的旧版客户端应答。

在基于操作系统的推送通知PN_OS经由服务202生成的情况下，这可以包括来自上面讨论的潜在有效载荷信息之中的数量减少的有效载荷信息。例如，这可以包括握手消息HS1以及某些选择的用户解析信息(UR’)，至少呼叫者的用户名和/或呼叫者的用户终端102a的地址。如果通知的格式允许足够的比特对适度尺寸的图像编码，那么化身图像也可以仍然用作基于操作系统的通知中的有效载荷信息。该有效载荷信息在基于操作系统的推送通知PN_OS中被提供给目的地终端102b上的操作系统400b。

如果被呼叫者的终端102b上的操作系统400b接收到基于操作系统的推送通知PN_OL，那么它生成屏幕上消息以便向被呼叫者通知到来的呼叫。可选地，这可以涉及从插入到操作系统400b的预定义屏幕上消息中的有效载荷信息提取的某些有限的参数。例如，接收操作系统400b可以根据接收的有效载荷确定呼叫者的显示名，以及呼叫者的代表性图像，并且可以将这些插入到屏幕上通知的预定格式中。然而，屏幕上消息格式的其他方面可以由操作系统400b决定，例如其尺寸、其“观感”以及任何关联的图形。

例如，如果被呼叫者在通知时间正在全屏或者其他情况下的主导状态下玩视频游戏406或者使用某个其他的应用程序，那么操作系统可以使得小的通知消息在诸如屏幕角落之类的相对不显眼的位置弹出。

被呼叫者的操作系统400b生成的屏幕上消息提示被呼叫者采取什么动作，例如是否接听呼叫，或者是否拒绝通知并且继续玩游戏406。

如先前所讨论的，目的地VoIP客户端406b可以在到来的通知的时间处于背景(b/g)状态下。如果响应于操作系统提示，被呼叫者的确选择接受呼叫，那么操作系统唤醒被呼叫者的VoIP客户端402b。这可以涉及结束先前在前景下运行的应用程序(例如游戏406)的全屏或者其他这样的主导状态。

被呼叫者的终端102b上的操作系统400b也将至少一定数量的有效载荷信息向上传递至新恢复的VoIP客户端402b，传递第一握手消息HS1，以及用于作为响应联系呼叫者的用户解析信息中的至少一些，即呼叫者用户名和/或始发终端地址。当被呼叫者VoIP客户端402b唤醒时，它因此能够制定包括返回握手消息HS2的呼叫接受响应CA并且向后将该响应送达呼叫者的用户终端102a上的始发客户端402a。

在推送通知中接收的有效载荷信息因此仍然足以在无需在他或她决定是否应当呼叫之前通过网络100的任何其他信令以获取用于联系呼叫者的终端102a的标识符信息或者获取向被呼叫者识别呼叫者的信息的情况下制定呼叫接受响应(CA)。因此，同样地，双程的数量以及因此用于呼叫接受的时间可以减少。

再一次地，被呼叫者的客户端402b也可以在步骤S56处向后向呼叫控制器502报告指示它已经接受了呼叫的出席报告(AR)。可替换地，出席报告(AR)可以在始发者接收到来自目的地的响应时由该始发者发送。呼叫控制器502可以使用该报告跟踪呼叫是否被应答或者呼叫在其被应答之前是否超时。

在一些实施例中，基于应用层的和基于操作系统的推送通知机制二者并行地存在。推送通知中心可以并行地尝试这两种通知方法。

此外，始发用户终端102a上的呼叫者客户端402a可以仍然可操作来直接通过因特网100将常规P2P呼叫邀请(CI，步骤S10)发送至目的地用户终端102b上的被呼叫者客户端402b。

在可替换的实施例中，可以不将HS1包含在来自被呼叫者的呼叫邀请(CI)中(步骤S20/S30)。相反地，交换可能要求被呼叫者响应于初始通知而将HS1发送至呼叫者，并且呼叫者然后利用第二握手消息HS2答复以便建立反向会话。

在实施例中，一旦执行了上面的呼叫信令，那么用户的认证可以通过像常规P2P方式中那样在被呼叫者与呼叫者之间交换证书而以相互的方式进行。可替换地或者此外，当连接适配器在形成初始连接的时间验证呼叫者的身份时，认证可以由连接适配器集中地执行。在其中在上面的信令之后通过交换证书完成认证的情况下，应当指出的是，呼叫接受响应CA不是一个用于成功进行呼叫的绝对最终标准，而是建立会话的临时接受，认证可以首先通过其进行——实际的呼叫遭受该认证的影响(只要通信不是恶意的，那么这在大多数情形中不太可能成为问题)。在其他实施例中，认证可能仅仅依赖于连接适配器对于呼叫者的初始认证。

在某些实施例中，可以在建立会话的过程中使用认证的这两个阶段。首先，呼叫者客户端在连接适配器512上认证自己并且然后通过建立的经过认证的传输将邀请发送至呼叫控制器502。这是第一次认证并且它用来在服务器204上认证客户端。当包含HS1的推送通知到达被呼叫者客户端时，这是在客户端之间建立认证的直接(P2P)连接的第一步并且这是第二次认证发生的地方。第一阶段为集中式认证，而形成对照的是，第二阶段为P2P认证。

在另外的实施例中，可替换地或者此外，上面关于呼叫邀请所讨论的通知特征可以用来就其他通信事件通知目的地终端的用户，这些事件例如IM聊天消息、话音邮件或者文件传输，发送者(始发终端102a的用户，类似于上面的呼叫者)企图将这些事件发送至预期的接受者(目的地终端102b的用户，类似于上面的被呼叫者)。如果接受者接受，那么他们的客户端402b可以或者获取来自服务器(例如元件204的部分)的等待通信，或者直接从发送者的终端102a获取它。

应当领会的是，上面的实施例仅仅通过实例加以描述。

例如，尽管以上所述在上文中关于用于执行VoIP呼叫的混合P2P系统加以描述，但是本文公开的技术可以适用于其他类型的基于分组的通信系统。因此，在可替换的实施例中，在通知之后，会话建立的一个、一些或者所有另外的阶段(例如可以用来进行呼叫)可替换地可以经由诸如一个或多个提供商或运营商的一个或多个服务器之类的一个或多个网络集中式元件进行。关于其中使用了一些P2P技术的实施例也应当注意，在其最广泛的意义上，术语P2P不一定限于完全去集中化布置。在例如一些实施例中，只有介质(即呼叫或者其他会话的内容)需要直接在对等体之间传输，所有其他的呼叫信令(包括地址查找和认证)经由中央元件发生。

此外，在上文中在服务器方面描述了任何网络元件的情况下，应当领会的是，这并不限于容纳在相同外壳内或者位于相同地点的单个服务器单元或者服务器。依照本发明的实施例，通过一个或多个单元中的任何一个实现的任何逻辑网络元件都可以用来实现通信提供商功能。此外，尽管以上所述在因特网通信方面加以描述，但是各个不同的实施例也可以用于通过其他基于分组的通信网络提供通知和/或通过其他基于分组的通信网络通知通信。

给定本文的公开内容，其他的变型对于本领域技术人员可以变得清楚明白。