CN103401890B - 用于通信事件的通知的装置和方法 - Google Patents

Abstract

一种通信提供商的网络元件，被设置成接收来自始发最终用户终端的、邀请目的地最终用户终端参加提议的会话以便通过基于分组的网络进行话音或视频呼叫的呼叫邀请，作为响应生成推送通知，并且将推送通知发送至目的地最终用户终端。处理装置被配置成利用包括呼叫信令信息的有效载荷生成推送通知，这使得关于提议的会话的响应能够由目的地最终用户终端制定并且返回给始发最终用户终端，呼叫信令信息至少包括（i）寻求最终用户终端之间的会话的指示，以及（ii）用于对始发最终用户终端进行响应的标识符。

Description

用于通信事件的通知的装置和方法

相关申请

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

背景技术

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

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

发明内容

依照本发明的实施例，提供了一种通信提供商的网络元件，该网络元件包括：收发器装置，其被设置成接收来自始发最终用户终端的邀请目的地最终用户终端参加提议的会话以便通过基于分组的网络进行话音或视频呼叫的呼叫邀请；以及处理装置，其被配置成响应于来自始发最终用户终端的呼叫邀请生成推送通知。收发器装置被设置成将推送通知发送至目的地最终用户终端；并且处理装置被配置成利用包括会话建立信息的有效载荷生成推送通知。这使得关于提议的会话的响应能够由目的地最终用户终端制定并且返回给始发最终用户终端，会话建立信息至少包括寻求最终用户终端之间的会话的指示以及用于对始发最终用户终端进行响应的标识符。

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

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

附图说明

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

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

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

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

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

具体实施方式

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

诸如在基于分组的网络上实现的常规P2P系统之类的通信系统可能出现的另一个问题上呼叫信令的速度，尤其是在呼叫被应答之前要花费多长时间，或者要花费多长时间确定呼叫未被应答。这尤其是（但非排他性地）在被呼叫者的客户端如上面所讨论的处于后台状态下时可能是个问题，其中呼叫者可能必须在他或她被通知被呼叫者不可达之前等待企图的呼叫邀请超时。这在以下情况下对于呼叫者而言可能是特别令人失望的：超时时段长，比如30-60秒，使得即使被呼叫者的客户端起初被暂停并且从来未能接受呼叫，他们在发现呼叫不能进行之前等待达一分钟。呼叫信令延迟也可能发生在其他类型的通信系统中。

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

然而，在过去，“原始”推送通知仅仅通知目的地终端在服务器处存在等待它的某种通信。目的地终端于是仍然必须轮询服务器以便确定等待通信的性质并且响应于接收到推送通知而从服务器拉取有关信息，例如，它回头查阅服务器以取回等待IM聊天消息或者文件传输。如果这样的推送通知系统直接适于通知呼叫邀请的用户，那么一旦被呼叫者接收到通知，则被呼叫者仍然必须回头查阅服务器以确定它被通知的事件的性质，即确定正在寻求呼叫这一事实，并且获得允许它将呼叫接受响应回送给呼叫者的信息。例如，如果原始通知用来从后台状态唤醒目的地客户端应用程序，那么在唤醒时目的地客户端于是将不得不轮询服务器以便发现它为什么被唤醒（即确定提议了呼叫）并且发现使得它能够对呼叫邀请进行响应的始发终端或者呼叫者的身份。这将把不希望的延迟引入到呼叫信令中，记住呼叫者的耐心可能仅仅延长到大约30-60s或者甚至更少。

依照本发明的实施例，提供了一种诸如VoIP提供商之类的被设置成充当呼叫的端点之间的媒介物的通信提供商的网络元件。该网络元件为采取提供商的一个或多个服务器单元（不一定容纳在相同的外壳内或者位于相同的地点）以及在所述一个或多个服务器单元上运行的关联软件的形式的逻辑元件。该网络元件被设置成接收来自始发最终用户终端（呼叫者的终端）的呼叫邀请，并且作为响应生成推送通知，该网络元件将推送通知发送到目的地最终用户终端（被呼叫者的终端）以便向该终端通知到来的呼叫。提供商的网络元件被配置成生成推送通知，使其包括有效载荷，并且生成它插入到推送通知的有效载荷中的会话建立信息。

推送通知的有效载荷中的会话建立信息至少包括将提议了会话这一事实传送至（被呼叫者的）目的地终端的指示。推送通知有效载荷中的会话建立信息也至少包括允许目的地终端联系始发者（呼叫者）以便进行响应的某种标识符信息。推送通知的有效载荷因此足以使得目的地终端能够制定关于提议的会话的响应、至少临时地接受呼叫的接受响应并且将其返回始发终端（在实施例中，前行的呼叫可能依赖于一个或多个另外的阶段，比如在始发与目的地用户终端之间交换认证证书）。然后，建立的会话用来进行呼叫。由于目的地进行响应所需的会话建立信息包含在提议呼叫的推送通知的有效载荷中，因而这可以有利地降低呼叫设立中涉及的呼叫信令。

会话建立信息可以包括作为握手的第一阶段的消息。推送通知的有效载荷因此足以使得目的地终端能够在接受响应中制定握手的第二应答部分并且将其返回始发终端。可替换地，推送通知可以要求目的地终端回送第一握手消息以便建立反向会话。

在一些实施例中，使用推送通知的有效载荷中接收的会话建立信息，被呼叫者的客户端应用程序因此能够制定关于提议的会话的响应，而不必通过网络执行另外的呼叫信令来从通信提供商（或者任何其他运营商或提供商）的网络元件取回关于通知的性质（即目的）的信息，并且不必通过网络执行另外的呼叫信令来从这样的运营商或提供商取回用于识别呼叫用户或者他或她的终端的信息。

可替换地或者此外，在其他实施例中，通过使用接收的有效载荷信息，可以将关于提议的呼叫的响应直接从目的地端点（被呼叫者）返回到始发端点（呼叫者），而不经由通信提供商（或者任何其他运营商或提供商）的网络元件。

基于以上特征中的任何一个或全部或者其变型，双程（roundtrip）或者其他呼叫信令的数量减少，因此可以在没有由于呼叫信令而引起的过度延迟的情况下在端点（始发与目的地）之间同意提议的呼叫。

在实施例中，呼叫的一个或多个另外的阶段可以直接在始发与目的地之间进行，而不另外涉及通信生产商（或者其他这样的提供商或运营商）的网络元件。例如，基于推送通知有效载荷和响应中的初始握手，始发终端和目的地终端上的客户端应用程序可以类似于更传统的P2P系统，继续在没有中间服务器的情况下直接在彼此之间交换它们各自的认证证书。和/或呼叫通信量（话音和/或视频）可以在没有介入的服务器的情况下直接在始发与目的地终端之间进行。在这个意义上，本发明的一些实现方式可以被认为提供了一种混合对等系统。然而，在其他实施例中，一种更加以服务器为中心的实现方式也是可能的。

各个不同的实施例可以利用操作系统的现有推送通知服务，但是将扩增的有效载荷信息包括在通知的有效载荷中。可替换地或者此外，各个不同的实施例可以实现新应用层推送通知服务。

在一些实现方式中，与直接通过P2P相反的是，可能需要各个不同的实施例通过服务器侧部件——并且在许多情况下，通过所讨论的通信提供商（例如VoIP提供商）对其没有控制的第三方推送系统路由信令唤醒——因此一旦被呼叫者醒来以接受呼叫，则需要尽可能地“前载（frontload）”该邀请以便加快连接时间。“前载”的信息使得会话能够被建立（例如P2P会话建立或者其他类型的会话），有效载荷允许实现更快的会话建立。也可以在有效载荷中示出该意图（呼叫邀请）。

如所提到的，诸如手持式移动电话之类的现代移动设备现在能够运行通信客户端应用程序以便通过诸如因特网之类的基于分组的网络而不是仅仅经由移动电话的专用蜂窝话音通道执行诸如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返回被呼叫者的用户终端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。相反地，它直接制定它直接通过因特网100发送至被呼叫者的用户终端102b上的客户端的、它自己的应用层推送通知（PN_AL）。被呼叫者的用户终端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处显现时，其可以扩展到指定用于屏幕上通知消息的语法的语言模板。

在实施例中，解析器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可以根据接收的有效载荷确定呼叫者的显示名，以及适当的语言模板为英语模板“you have an incoming call from [显示名]”或者法语模板“[显示名] vous téléphoner”这一事实。然而，屏幕上消息格式的其他方面可以由操作系统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不一定限于完全去集中化布置。在例如一些实施例中，只有介质（即呼叫或者其他会话的内容）需要直接在对等体之间传输，所有其他的呼叫信令（包括地址查找和认证）经由中央元件发生。

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

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

Claims (8)

1.一种通信提供商的网络元件（204），包括：

收发器装置，其被配置成接收来自始发最终用户终端（102a）的、邀请目的地最终用户终端（102b）参加提议的会话以便通过基于分组的网络（100）进行话音或视频呼叫的呼叫邀请；以及

处理装置，其被配置成响应于来自始发最终用户终端（102a）的呼叫邀请生成推送通知；

其中收发器装置被进一步配置成将推送通知发送至目的地最终用户终端（102b）；

其中处理装置被配置成利用包括会话建立信息的有效载荷生成推送通知，这使得关于提议的会话的响应能够由目的地最终用户终端（102b）制定并且返回给始发最终用户终端（102a），会话建立信息至少包括寻求最终用户终端之间的会话的指示，以及用于对始发最终用户终端（102a）进行响应的标识符，

其中所述标识符包括下列中的至少一个：

始发终端的用户的用户名；或

始发最终用户终端的地址，并且

其中，响应于呼叫邀请不包含用户的用户名或者始发最终用户终端的地址，所述处理装置被进一步配置成：

解析下列中的至少一个：

始发终端的用户的用户名；或

始发最终用户终端的地址，并且

将至少所解析的地址或所解析的用户名添加到推送通知的有效载荷中。

2.权利要求1的网络元件，其中会话建立信息进一步包括握手协议的第一个握手消息（HS1），使得来自目的地最终用户终端（102b）的接受响应将包括握手协议的应答握手消息（HS2）。

3.权利要求2的网络元件，其中在来自始发最终用户终端（102a）的呼叫邀请中接收第一个握手消息（HS1），并且网络元件（204）的处理装置被配置成在推送通知的有效载荷中将第一个握手消息（HS1）转发至目的地最终用户终端（102b）。

4.权利要求1的网络元件，其中目的地最终用户终端（102b）包括有时被发现处于后台状态下的客户端应用程序（402b），在该后台状态下，该客户端应用程序被目的地最终用户终端（102b）的操作系统（400b）暂停或者调度受抑制数量的处理周期，其中推送通知发起客户端（402b）从后台状态的唤醒，并且推送通知的有效载荷中的会话建立信息使得所述响应能够由目的地最终用户终端（102b）上的客户端（402b）制定，并且在唤醒时返回到始发最终用户终端（102a）。

5.权利要求1的网络元件，其中推送通知包括基于操作系统的推送通知；

网络元件（204）的处理装置和收发器装置被配置成经由基于操作系统的推送通知服务的单独的网络元件（202）将基于操作系统的推送通知发送至目的地最终用户终端（102b）；并且

基于操作系统的推送通知在目的地终端（102b）的用户接受操作系统（400b）的用户提示的条件下经由该提示唤醒客户端应用程序（402b）。

6.权利要求1-5中任何一项的网络元件，其中推送通知包括应用层推送通知。

7.权利要求5的网络元件，其中在目的地最终用户终端（102b）上的客户端应用程序（402b）运行在前台状态下的其他时间，处理装置和收发器装置被配置成将基于操作系统的推送通知和应用层推送通知二者发送至目的地最终用户终端，并且处理装置被配置成选择不同程度的会话建立信息以便包含在基于操作系统的推送通知的有效载荷中而不是包含在应用层推送通知的有效载荷中。

8.一种在目的地最终用户终端（102b）上执行的方法，包括：

接收推送通知，该推送通知基于来自始发最终用户终端（102a）的、邀请目的地最终用户终端（102b）参加提议的会话以便通过基于分组的网络（100）进行话音或视频呼叫的呼叫邀请而生成；

从推送通知消息的有效载荷中提取会话建立信息，该会话建立信息至少包括寻求最终用户终端之间的会话的指示，以及用于对始发最终用户终端（102a）进行响应的标识符，所述标识符包括下列中的至少一个：

始发终端的用户的用户名；或

始发最终用户终端的地址；

基于推送通知的有效载荷，制定关于提议的会话的响应，而不通过基于分组的网络执行另外的信令来从通信提供商的网络元件首先取回关于推送通知的性质的附加信息，并且不通过基于分组的网络执行另外的信令来从通信提供商的网络元件确定始发最终用户终端的身份；以及

基于推送通知的有效载荷中接收的标识符，将所述响应返回给始发最终用户终端（102a）。