用于在呼叫者與被呼叫者之間建立呼叫的網(wǎng)絡節(jié)點和方法相關的申請本申請在35USC119或365下要求2012年6月14日提交的英國申請No.1210600.1的優(yōu)先權(quán)，該申請的公開內(nèi)容整體地合并于此。

背景技術：
存在用于通過諸如因特網(wǎng)那樣的基于分組的網(wǎng)絡建立實況的基于分組的話音或視頻呼叫的各種通信系統(tǒng)。例如，這樣的系統(tǒng)可以使用VoIP（互聯(lián)網(wǎng)上的話音協(xié)議）技術。一種流行類型的通信系統(tǒng)是構(gòu)建在對等（P2P）拓撲上。在傳統(tǒng)的P2P系統(tǒng)中，每個最終用戶在他或她各自的用戶終端（例如，臺式計算機或膝上型計算機、平板電腦或手持移動電話）上安裝通信客戶端應用。每個用戶然后向P2P提供者的服務器注冊以便得到認證證書。用戶終端中的某些也將成為分布式數(shù)據(jù)庫的節(jié)點，其將P2P通信系統(tǒng)內(nèi)用戶的用戶名映射到該系統(tǒng)在其上實施的網(wǎng)絡內(nèi)的各個用戶終端的地址（典型地是IP地址）。然后可以進行在最終用戶之間的通信，而不用在呼叫建立或認證過程中牽涉到集中式的服務器。替代地，在呼叫者的終端上的客戶端查詢分布式數(shù)據(jù)庫的一個或多個節(jié)點（即，呼叫中以任何其他方式涉及的其他最終用戶（不一定是他們自己）的一個或多個終端），以便確定預期的被呼叫者的終端的地址。然后，呼叫者使用所確定的地址來把呼叫邀請發(fā)送到被呼叫者，以及被呼叫者用呼叫接受響應來進行響應。呼叫者和被呼叫者交換他們的認證證書，以便互相認證。每個用戶還維護聯(lián)系人列表，該聯(lián)系人列表可以被存儲在P2P提供者的服務器上，以使得即使在用戶登錄到不同的終端時它也是可得到的。其它輔助信息，諸如用于每個用戶的簡檔信息（例如，化身圖像或情緒消息），也可以被存儲在服務器上。而且，客戶端應用也互相交換存在性信息。存在性信息指示用戶的可用性（availability）狀態(tài)，優(yōu)選地，它至少部分地由用戶他或她自己定義。例如，存在性可以指示用戶是離線，是在線但已選擇為不可用（“別打擾”），還是在線并已選擇為可用的。例如，每個客戶端可以周期地輪詢在它的聯(lián)系人列表中的每個聯(lián)系人，以便確定它們各自的存在性，和/或每個客戶端可以把存在性更新周期地發(fā)送到它的列表中的每個聯(lián)系人。存在性典型地根據(jù)P2P技術直接在最終用戶之間用信號通知，而不用經(jīng)由服務器。當進行呼叫時，呼叫者的客戶端根據(jù)最新的存在性信息確定被呼叫者是否可用來接受該呼叫。

技術實現(xiàn)要素：
在本發(fā)明的實施例中，網(wǎng)絡節(jié)點被安排成參加通過網(wǎng)絡的在呼叫者與被呼叫者之間的呼叫建立。網(wǎng)絡節(jié)點包括發(fā)射機設備，其被安排來發(fā)送用于在呼叫者的呼叫者客戶端與實施在被呼叫者的一個或多個被呼叫者終端上的一個或多個被呼叫者客戶端之間建立呼叫的呼叫邀請的多個版本。收發(fā)器設備被安排來通過多種不同的傳遞機制發(fā)送呼叫邀請的多個版本。傳遞機制之一包括在推送信道上的推送通知。本概要被提供來以簡化的形式介紹概念的選擇，這些概念還將在下面的詳細說明段落中進行描述。本概要既不打算確認所要求保護的主題的關鍵特征或必要特征，也不打算限制所要求保護的主題。所要求保護的主題也不限于解決在前系統(tǒng)的任何或所有的已指出缺點的實現(xiàn)。附圖說明為了更好地了解本發(fā)明和顯示本發(fā)明可以如何付諸實施，作為例子，參考附圖，其中：圖1是通信系統(tǒng)的示意圖；圖2是通信系統(tǒng)的另一個示意圖；圖3是通信系統(tǒng)的再一個示意圖；圖4是兩個用戶終端的示意圖；以及圖5是兩個用戶終端和網(wǎng)絡單元的示意圖。具體實施方式隨著能夠運行諸如VoIP客戶端那樣的通信客戶端應用的手持移動電話越來越流行，有數(shù)量越來越多的端點（endpoint）可用于參與到VoIP通信系統(tǒng)或其它這樣的、通過因特網(wǎng)等等實施的基于分組的通信系統(tǒng)中。然而，也可能引發(fā)的問題是，移動電話手機典型地比傳統(tǒng)的臺式計算機或膝上型計算機具有更有限的資源，例如，每單位時間只能執(zhí)行更少的處理周期，每個處理周期具有更少的功能性，具有更有限的存儲器資源（例如，RAM和/或高速緩存器）和/或具有更少的屏幕區(qū)域資源。因此，在某些終端上的操作系統(tǒng)（OS）可能就把某些應用置于后臺狀態(tài)。這可包括通信客戶端。在后臺狀態(tài)下，后臺化的應用或者被完全掛起或者每個單位時間被調(diào)度以有限的處理周期，在某種程度上不能檢測進入的呼叫邀請和/或處理傳統(tǒng)的呼叫邀請。例如，如果另一個應用正在前臺狀態(tài)（foregroundstate）中運行，特別是如果其它應用在處理、存儲器和/或屏幕資源方面是集中的（intensive），例如運行在全屏模式或具有作為當前主要的、首要的或優(yōu)先的應用的某些其它狀態(tài)，則這可能發(fā)生。一個例子是在移動電話上玩的計算機游戲。在這樣的情形下，如果客戶端不能發(fā)出存在性更新或響應來自其它用戶的存在性輪詢，則用戶可能從他或她的存在性來看表現(xiàn)為離線。盡管如此，用戶仍舊可能希望可用于接受呼叫，例如，寧愿中斷視頻游戲也不錯過呼叫。因此，傳統(tǒng)的存在性概念開始被打破。在具有能夠把某些應用置于后臺狀態(tài)中來有利于一個或多個其它應用的特征的任何終端上可能潛在地出現(xiàn)類似的問題。對于諸如在基于分組的網(wǎng)絡上實施的常規(guī)P2P系統(tǒng)那樣的通信系統(tǒng)可能引發(fā)的另一個問題是呼叫信令的速度，特別是在呼叫被回答之前花費了多長時間，或者確定呼叫不被回答花費了多長時間。這可能當被呼叫者的客戶端處在如以上討論的后臺狀態(tài)時特別成問題，其中呼叫者在他或她被告知以被呼叫者是不可用之前可能必須等待所嘗試的呼叫邀請超時。如果該超時時段較長，比如說30-60秒，使得即使被呼叫者的客戶端被掛起且起初便根本不能接受該呼叫，呼叫者在他們發(fā)現(xiàn)呼叫不能進行之前也要等待多達一分鐘，則這對于呼叫者而言是特別令人沮喪的。呼叫信令延時也可能在其它類型的通信系統(tǒng)中出現(xiàn)。某些其它類型的通信系統(tǒng)使用推送通知來把通信事件通知給目的地用戶終端。推送通知是在服務器或另一個始發(fā)單元的激勵下，而不是在目的地終端本身的激勵下從服務器發(fā)送的通知（即，與由目的地終端拉取相反）。因此，推送通知可被看作為與目的地終端異步。當呼叫邀請被發(fā)送時，可能希望讓呼叫邀請以快速和可靠的方式傳遞到被呼叫者客戶端。呼叫建立請求（或“呼叫邀請”）可以通過多種傳遞機制提供，以便建立呼叫。傳遞機制描述呼叫邀請被傳遞的方式。例如，傳遞機制可包括借助其發(fā)送呼叫邀請的協(xié)議，和/或呼叫邀請如何通過網(wǎng)絡被路由。例如，三種類型的傳遞機制是：(i)對等機制，其中呼叫邀請是使用對等協(xié)議通過網(wǎng)絡被路由的，(ii)基于應用層的推送通知機制，呼叫邀請借助于它通過網(wǎng)絡被推送到在被呼叫者終端處的客戶端應用，和(iii)基于操作系統(tǒng)的推送通知機制，呼叫邀請借助于它通過網(wǎng)絡被推送到被呼叫者終端的操作系統(tǒng)。發(fā)送呼叫邀請的多個版本可以減少呼叫建立時間和提高呼叫邀請成功地傳遞到被呼叫者的客戶端的概率。呼叫邀請的每個版本涉及到同一個呼叫，并可以使用呼叫ID來標識呼叫。這樣，如果被呼叫者客戶端接收到呼叫邀請的多個版本，則被呼叫者客戶端可以確定呼叫邀請的每個版本包括相同的呼叫ID，因此它們都是用于該呼叫的同一個呼叫邀請的版本。呼叫邀請的每個版本可包括用來標識呼叫邀請的邀請ID。這允許呼叫邀請的每個版本與該呼叫邀請相關聯(lián)。換句話說，邀請ID允許被呼叫者客戶端確定呼叫邀請的每個版本涉及到同一個呼叫邀請。如果多個呼叫邀請是為同一個呼叫發(fā)送的，則這是特別有用的，其使得每個呼叫邀請的每個版本可以與正確的呼叫邀請相關聯(lián)。在實施例中，被呼叫者客戶端可以回答呼叫邀請的版本之一（例如，要在被呼叫者客戶端處接收的呼叫邀請的第一個版本），由此建立在呼叫者與被呼叫者之間的呼叫。為了建立呼叫，可能只需要由被呼叫者客戶端接收呼叫邀請的一個版本。由于呼叫邀請的各版本通過不同的傳遞機制被發(fā)送，所以與通過單個傳遞機制發(fā)送呼叫邀請相比較，從呼叫者客戶端發(fā)送到被呼叫者客戶端的呼叫邀請的至少一個版本所花費的時間可以減少。而且，由于呼叫邀請的各版本是通過不同的傳遞機制被發(fā)送的，所以與通過單個傳遞機制發(fā)送呼叫邀請相比較，在被呼叫者客戶端處成功接收呼叫邀請的至少一個版本的可靠性可以增加。傳遞機制可包括以下的至少兩種機制：(i)在基于操作系統(tǒng)的推送信道上的基于操作系統(tǒng)的推送通知，(ii)在應用層推送信道上的應用層推送通知，和(iii)在通過網(wǎng)絡的對等連接上的對等消息。通過在多種傳遞機制上同時發(fā)送呼叫邀請的各版本，系統(tǒng)可以在特定時間利用最有利的無論哪種傳遞機制（例如，最快的傳遞或最可靠的傳遞）。條件有可能改變，這樣使得傳遞機制中最有利的一種傳遞機制（例如，它具有最快的傳遞或它是最可靠的）可能隨時間而改變。正如所提到的，諸如手持移動電話那樣的現(xiàn)代移動設備現(xiàn)在能夠運行通信客戶端應用，來用于通過諸如因特網(wǎng)那樣的基于分組的網(wǎng)絡，而不是僅僅經(jīng)由移動電話的專用蜂窩話音信道，去執(zhí)行諸如VoIP那樣的基于分組的通信或其它基于分組的話音或視頻呼叫。通過這種能力，帶來在線的和可呼叫的用戶數(shù)量的巨大增加。然而，這樣的用戶的客戶端應用也可能潛在地被發(fā)現(xiàn)：在呼叫時處在后臺狀態(tài)中，由此，客戶端被移動設備的操作系統(tǒng)掛起或至多被調(diào)度以非常有限的資源—因此為了接收進入的呼叫，客戶端需要被喚醒。在這樣的操作系統(tǒng)體系下—其中應用不再保證能夠在后臺處理諸如進入的呼叫、聊天等那樣的事件—VoIP或其它通信提供者的結(jié)構(gòu)體系將從被進行擴展而獲益。例如，如果提供者希望能夠把呼叫（和其它）通知傳遞給他們的通信系統(tǒng)的用戶，即使所述用戶可能把相關的通信客戶端應用“后臺化”（或由操作系統(tǒng)將應用后臺化）但盡管如此用戶仍舊在線且照這樣是潛在地可呼叫的，則這將是有利的。客戶端應用的呼叫部件也可以被修改，以保證呼叫用戶的初始意圖可以可靠地傳遞到所有的端點，在那里用戶應當能夠接收呼叫—如果需要的話，經(jīng)由推送通知。例如，考慮其中被呼叫者正在手持電話或平板電腦上使用網(wǎng)絡瀏覽器或正在玩視頻游戲而同時等待他或她的朋友的呼叫（或許來自外國，所以為了費用原因而寧愿使用VoIP）的使用情形。被呼叫者根據(jù)存在性狀態(tài)檢查朋友是否在線，但當他或她不在線時被呼叫者開始瀏覽或玩游戲來打發(fā)時間。然后，朋友（呼叫者）隨后例如在臺式計算機上登錄到他或她的客戶端應用，準備呼叫被呼叫者。在實施例中，被呼叫者的客戶端可以被修改成向呼叫者顯示被呼叫者為在線，即使被呼叫者的客戶端應用由于瀏覽器或游戲需要耗費高的系統(tǒng)資源，例如由于在瀏覽器中運行flash應用或其它applet而已由被呼叫者的操作系統(tǒng)掛起或抑制。在本發(fā)明的實施例中，呼叫者點擊呼叫按鈕，發(fā)起對被呼叫者的呼叫，被呼叫者的操作系統(tǒng)被配置成提出提示，通知他或她有進入的呼叫。被呼叫者的客戶端應用被配置成使得如果被呼叫者響應于該提示而敲擊或點擊接受按鈕，則客戶端應用在被呼叫者的終端上被帶回到前臺，因此允許被呼叫者回答該呼叫（話音或視頻），且開始與他或她的朋友—呼叫者—談話。在本示例性情形下，應當注意某些單元。被呼叫者客戶端的狀態(tài)在最壞的情況下潛在地被完全掛起（終結(jié)），照這樣它不能通過常規(guī)的P2P會話建立方法來聯(lián)系到。在本發(fā)明的實施例中，被呼叫者可能不知道或沒注意到他或她的客戶端應用被掛起，因為這可能未曾被被呼叫者用戶明確地完成—事實上正好相反，這可能已經(jīng)由操作系統(tǒng)自動完成，且被呼叫者可以是在這樣的假設下：他或她的客戶端應用仍舊在運行，以及他們是在線和可聯(lián)系的。而且，在這種情景下，與用于這樣的系統(tǒng)的常規(guī)存在性機制不同，優(yōu)選地不使存在性依賴于（或不僅僅依賴于）客戶端的P2P可用性。為了支持以上的情景，提供者將優(yōu)選地實施新的呼叫部件和/或?qū)τ诂F(xiàn)有的部件做出必要的改變。一個目標是使得被呼叫者客戶端能夠在適當?shù)臅r間幀和范圍內(nèi)被喚醒和建立與呼叫者客戶端的會話（例如，P2P會話）。為了保持呼叫建立時間盡可能短，在會話與呼叫建立時的往返行程（roundtrip）優(yōu)選地應當盡可能保持為最小。正如以上的示例性情景下演示的，呼叫發(fā)起流程可以支持需要經(jīng)由非P2P消息傳遞系統(tǒng)用信號通知呼叫的意圖的使用情形，其可以在需要的場合下回退（fallback）到推送通知，以便喚醒被呼叫者客戶端。例如，這可以是經(jīng)由由所討論的操作系統(tǒng)的提供者所提供的推送通知服務。呼叫建立請求（即，呼叫邀請）通過多種傳遞機制提供，以便建立呼叫，由此減小呼叫建立時間和提高傳遞的概率。換句話說，呼叫邀請的多個版本是使用不同的傳遞機制，例如，通過網(wǎng)絡的不同路由，從呼叫者客戶端發(fā)送到被呼叫者客戶端。呼叫邀請的各版本可以在網(wǎng)絡上并行地發(fā)送。在這個意義上，呼叫邀請通過使用不同的傳遞機制而分散作為多個版本被傳遞。而且，被呼叫者可以與一個以上的用戶終端相關聯(lián)。換句話說，被呼叫者可以在一個以上的終端上安裝客戶端軟件實例，并且可以通過使用來自這些終端的客戶端軟件實例而登錄到通信系統(tǒng)。因此，被呼叫者可以是經(jīng)由在一個以上的被呼叫者終端處實施的一個以上的被呼叫者客戶端可聯(lián)系的。呼叫邀請的各版本被發(fā)送到在與被呼叫者相關聯(lián)的每個被呼叫者終端處實施的每個被呼叫者客戶端。通過經(jīng)由多種傳遞機制發(fā)送呼叫邀請的多個版本以及發(fā)送到多個被呼叫者客戶端，呼叫邀請的版本可用以傳遞到被呼叫者客戶端的速度和可靠性以及被呼叫者當前交互所用的速度和可靠性都可以提高。呼叫部件可被更新，以例如在核心庫中實施必要的客戶端部件改變，以便保證它們迎合所有需要的使用情形、互操作性和后向兼容性情景。呼叫客戶端部件可被更新來允許被呼叫者客戶端接受經(jīng)由推送通知傳遞方法接收的進入的呼叫邀請。這可包括一個或多個UI（用戶接口）API（應用編程接口）的組，允許客戶端UI層把接收的有用負荷信息傳送到呼叫部件，使得能進行P2P會話建立和呼叫建立及信令。對于要被包括在經(jīng)由消息傳遞系統(tǒng)傳遞到被呼叫者端點的消息的有用負荷中的呼叫有關的信息，呼叫功能性優(yōu)選地可以支持基于云的服務，該基于云的服務接收來自傳遞基礎設施的消息，并用呼叫特定的有用負荷信息來填充這個消息。呼叫通知優(yōu)選地包括足夠的信息，以允許被呼叫者做出是否回答該呼叫的有根據(jù)的（informed）決定。這例如可包括呼叫者名字（用戶名和/或顯示名）、呼叫者的化身、和/或呼叫邀請的時間戳。呼叫通知還可包括允許被呼叫者客戶端制定接受響應的信息，諸如握手消息和使得呼叫者在響應時能夠被聯(lián)系的信息（例如，呼叫者用戶名和/或地址）。一旦傳遞系統(tǒng)的呼叫通知器完成以上步驟，就傳送呼叫通知以便最后傳遞到被呼叫者端點。這優(yōu)選地將在被邀請到呼叫的用戶已登記去接收推送通知的場合下，或是在對于客戶端而言存在開放連接的場合下發(fā)生。通知可以是通過直接的持久連接（被呼叫者客戶端在前臺，和/或某些后臺狀態(tài)）或在需要的場合下（被呼叫者客戶端被掛起，和/或某些其它后臺狀態(tài)）是經(jīng)由到基于相關的操作系統(tǒng)的通知服務的推送通知。參加呼叫的邀請在許多情形下可以由呼叫方發(fā)出，諸如：在實際的呼叫被建立之前，作為發(fā)起的一部分；或是在正進行的呼叫期間把另一個參加者加到呼叫中。圖1是基于傳統(tǒng)的P2P范例的通信系統(tǒng)的示意圖。通信系統(tǒng)包括基于分組的網(wǎng)絡100，優(yōu)選地是廣域互聯(lián)網(wǎng)絡（互聯(lián)網(wǎng)），諸如因特網(wǎng)。通信系統(tǒng)還包括多個最終用戶終端102，每個包括收發(fā)器設備，可操作來耦合到因特網(wǎng)100，以及每個包括所討論的通信系統(tǒng)的各自的通信客戶端應用。每個最終用戶終端102例如可以取臺式計算機或膝上型計算機、平板電腦或手持移動電話（或“手機”）的形式。每個用戶終端102是在通信系統(tǒng)內(nèi)的VoIP呼叫或其他的基于分組的通信的潛在端點。圖1上圖示的是呼叫者端點102a和被呼叫者端點102b。按照常規(guī)的P2P原理，在一個或多個用戶終端102c上的客戶端應用呈現(xiàn)分布式地址查找數(shù)據(jù)庫的節(jié)點的狀態(tài)。為了確定被呼叫者的用戶終端102b的地址（例如，包括IP地址），在步驟S10，在呼叫者的用戶終端102a上的客戶端經(jīng)由因特網(wǎng)100與充當分布式數(shù)據(jù)庫的節(jié)點的用戶終端102c之一上的客戶端通信。在呼叫者的終端102a上的客戶端通過向數(shù)據(jù)庫節(jié)點102c發(fā)送在通信系統(tǒng)內(nèi)標識被呼叫者的被呼叫者的用戶名而查詢數(shù)據(jù)庫節(jié)點102c，且數(shù)據(jù)庫節(jié)點102c返回所需要的被呼叫者的用戶終端102b的地址。在步驟S12，在呼叫用戶終端102a上的客戶端然后使用這個地址來把呼叫建立請求或“邀請”（CI）用信號通知到預期的被呼叫者的終端102b上的客戶端。作為響應，如果被呼叫者選擇接受該呼叫，則被呼叫者終端102b上的客戶端用信號發(fā)回呼叫接受響應。在呼叫者和被呼叫者的終端102a和102b上的客戶端還交換認證證書以互相驗證身份?？蛻舳艘虼私⒒ハ嘀g的會話，以便在它們各自的終端102、102b上發(fā)送以來自麥克風和/或視頻攝像機的實時話音和/或視頻內(nèi)容的形式的業(yè)務量作為實況話音或視頻呼叫的一部分。因為地址查找是基于分布式數(shù)據(jù)庫，所以不需要為此而牽涉中央服務器。呼叫建立信令、認證和呼叫業(yè)務量的進行也不需要牽涉中央服務器。在實施例中，如果由于NAT（網(wǎng)絡地址翻譯）或防火墻108，呼叫者的用戶終端102a不能直接與被呼叫者的用戶終端102b進行通信，則客戶端可被安排成經(jīng)由一個或多個中繼進行通信，這些中繼也可以由在P2P通信系統(tǒng)的一個或多個其它用戶的最終用戶終端102d上運行的客戶端實施。進行中繼的最終用戶終端102d的用戶不需要是呼叫的參加者（不需要消費呼叫的話音或視頻內(nèi)容，并且事實上由于加密，也不能消費）。盡管如此，進行中繼的最終用戶終端102d的用戶當他或她簽約到P2P通信系統(tǒng)時將已同意這樣的情形，以及他或她自己可以在其它場合下從互惠安排中獲益。通信系統(tǒng)還可包括被耦合到因特網(wǎng)100的后端服務器104，其中每個客戶端可以存儲各自的聯(lián)系人列表，該聯(lián)系人列表是它的相應用戶的聯(lián)系人列表（優(yōu)選地，通信系統(tǒng)被配置成使得用戶依據(jù)共同協(xié)議成為彼此的聯(lián)系人）。后端服務器104還可以為每個用戶存儲簡檔信息，例如，用于向通信系統(tǒng)內(nèi)的其它用戶描繪相應用戶的化身圖像。每個客戶端可以訪問和顯示聯(lián)系人的簡檔，這樣使得呼叫者可以看見被呼叫者的簡檔信息，以及反之亦然。通信系統(tǒng)還可以包括被耦合在因特網(wǎng)100與電路交換網(wǎng)絡（未示出）之間的網(wǎng)關106。這樣的網(wǎng)絡可被稱為PSTN（公共交換電話網(wǎng)），例如，地面線路網(wǎng)絡或移動蜂窩網(wǎng)，諸如3GPP網(wǎng)。在用戶終端102上的客戶端由此還能夠經(jīng)由網(wǎng)關106建立與更多的傳統(tǒng)電話的呼叫。圖2圖示按照本發(fā)明的實施例的、修改的混合P2P通信系統(tǒng)。圖1的某些或所有的部件也仍舊可以與圖2的系統(tǒng)并行存在，但某些部件為了簡明起見從圖2上被省略。而且，通信系統(tǒng)包括通信服務提供者—例如VoIP提供者—的網(wǎng)絡單元204，其具有被耦合到因特網(wǎng)100并被安排成運行呼叫控制和通知軟件的一個或多個服務器單元的形式。通信系統(tǒng)還包括被耦合到因特網(wǎng)100的、一個或多個基于操作系統(tǒng)的推送通知服務（OSPNS）202。所述一個或多個基于操作系統(tǒng)的推送通知服務202的每一個與各自的操作系統(tǒng)相關聯(lián)，并優(yōu)選地由操作系統(tǒng)的制造者和/或發(fā)布者提供來支持經(jīng)由所討論的操作系統(tǒng)可提供的專用推送通知機制。所述基于操作系統(tǒng)的推送通知服務202取被安排成運行推送通知軟件的一個或多個服務器單元的形式。在圖2的示例性系統(tǒng)中，所圖示的單元102、202、204被配置成如下地運行。在步驟S20，在呼叫者的用戶終端102a上的客戶端不直接地把呼叫邀請（CI）發(fā)送到被呼叫者的用戶終端102b上的客戶端，而是把它發(fā)送到VoIP提供者的呼叫控制和通知單元204（消息CI不一定等同于相關于圖1描述的那個消息）。響應于接收到來自呼叫者的呼叫邀請，在步驟S22，VoIP提供者的呼叫控制和通知單元204生成推送通知請求（PNR），它把該推送通知請求發(fā)送到基于操作系統(tǒng)的推送通知服務202。響應于接收到來自VoIP提供者204的推送通知請求，在步驟S24，OS的推送通知服務202發(fā)送基于操作系統(tǒng)的推送通知（PN_OS）到被呼叫者的用戶終端102b上的操作系統(tǒng)?；诓僮飨到y(tǒng)的推送通知由在被呼叫者的用戶終端102b上的操作系統(tǒng)進行接收和處理，使得它在被呼叫者的用戶終端102b的屏幕上顯示彈出消息，向被呼叫者用戶指示有進入的事件。在本發(fā)明的實施例中，屏幕上消息可以關于是否接受進入的呼叫而提示被呼叫者。如果被呼叫者的客戶端應用當前被后臺化，則屏幕上消息可以關于是否把被呼叫者的客戶端應用從后臺狀態(tài)喚醒來提示用戶。在實施例中，這些動作可被組合到同一個提示中。如果作為響應，被呼叫者提供肯定的用戶輸入，則操作系統(tǒng)通過重新調(diào)度到完全操作水平或至少調(diào)度給它足夠的資源來操控該呼叫，而喚醒在被呼叫者的終端102上的被呼叫者客戶端應用。正如下面更詳細地討論的，在實施例中，推送通知PN_OS可包括有用負荷，其使得在被呼叫者的用戶終端102b上的客戶端能夠制定返回的握手消息，并且把該消息通過因特網(wǎng)100用信號通知回在呼叫者的用戶終端102a上的客戶端，優(yōu)選地，是直接通過因特網(wǎng)100，而不是經(jīng)由任何提供者的服務器或服務單元202和204。如果被呼叫者接受來自操作系統(tǒng)的用戶提示，則在被呼叫者的用戶終端102b上的操作系統(tǒng)傳遞至少部分的推送通知的有用負荷直到被呼叫者的客戶端應用，以便使得它可以制定相關的響應，并把該響應發(fā)回到呼叫者。圖3圖示按照本發(fā)明的實施例的、另一個修改的混合P2P通信系統(tǒng)。圖1和/或圖2的某些或所有的部件也仍舊可以與圖3的系統(tǒng)并行存在，但某些部件為了簡明起見從圖3上被省略。在圖3的示例性系統(tǒng)中，所示的單元102、204被配置成如下地運行。在步驟S20，在呼叫者的用戶終端102a上的客戶端再次不直接把呼叫邀請（CI）發(fā)送到被呼叫者的用戶終端102b上的客戶端，而是把它發(fā)送到VoIP提供者的呼叫控制和通知單元204（消息CI不一定等同于相關于圖1或圖2描述的那個消息）。在實施例中，這可以是與相關于圖2描述的那個步驟相同的步驟，或在其它實施例中，它可以是替換的或附加的、分開的步驟。然而，在這種情形下，VoIP提供者單元204不發(fā)送（或不僅僅發(fā)送）推送通知請求（PNR）到操作系統(tǒng)的推送通知服務202。而是，它直接制定它自己的應用層推送通知（PN_AL），它把該應用層推送通知通過因特網(wǎng)100直接發(fā)送到被呼叫者的用戶終端102b上的客戶端。在被呼叫者的用戶終端102b上的客戶端然后可以在應用層上處理該通知，以便它本身借助于應用層機制，而不是上述的操作系統(tǒng)機制，來關于進入的呼叫而提示被呼叫者用戶。正如下面更詳細地討論的，在實施例中，推送通知PN_AL包括有用負荷，其使得在被呼叫者的用戶終端102b上的客戶端能夠制定返回的握手消息，并且把該消息通過因特網(wǎng)100用信號通知回在呼叫者的用戶終端102a上的客戶端，優(yōu)選地，是直接通過因特網(wǎng)100，而不是經(jīng)由任何提供者的服務器或服務單元202和204。在這種情形下，如果在被呼叫者的終端102b上的客戶端或者處在前臺狀態(tài)（不被抑制來有利于任何其它應用），或者處在特別的后臺狀態(tài)而由此它被調(diào)度以有限的周期，但仍舊足以處理進入的呼叫，那么被呼叫者的客戶端能夠通過在由操作系統(tǒng)調(diào)度用于被呼叫者的客戶端的周期期間收聽來自網(wǎng)絡100的進入的通信，例如通過在被分配供被呼叫者的客戶端使用的、被呼叫者的終端102b的網(wǎng)絡套接字上收聽，而直接訪問推送通知的有用負荷。應當指出，圖1、2和3的兩種或更多種機制可以并行存在，并且任何的或所有的這些機制可以是可用于用信號通知呼叫邀請或通知的。在一個應用中，至少被呼叫者端點102b包括具有相對有限的資源（處理、存儲器和/或屏幕資源）的移動終端，且該移動終端具有這樣的操作系統(tǒng)，即：其易于把相應的客戶端應用后臺化，來有利于另一個應用，諸如在某種環(huán)境下的視頻游戲。圖4給出呼叫用戶（呼叫者）的始發(fā)最終用戶終端102a和被呼叫用戶（被呼叫者）的目的地最終用戶終端102b的示意性框圖，它們形成呼叫的兩個端點（或者甚至是在多方會議呼叫情景中更大數(shù)量端點中的兩個端點）。始發(fā)用戶終端102a包括相應的操作系統(tǒng)400a、VoIP通信系統(tǒng)的通信客戶端402a（以及潛在的其它應用）和用戶接口408a。VoIP客戶端402a被存儲在始發(fā)終端102a的存儲器上（以諸如電子或磁存儲設備那樣的有形存儲介質(zhì)的形式），并被安排成在始發(fā)終端102a的處理設備上執(zhí)行?？蛻舳藨?02a也被說成是在操作系統(tǒng)400a上運行，因為它被調(diào)度用于由操作系統(tǒng)400a來執(zhí)行。如果在終端102a上有多個應用存在且運行，則操作系統(tǒng)將調(diào)度它們來例如以交替的方式和/或在并行的處理資源上執(zhí)行，這樣使得每個應用在操作系統(tǒng)400a的控制下被分配以至少某些處理資源。當被調(diào)度時，客戶端應用402a能夠經(jīng)由用戶接口408a與用戶交互，并能夠經(jīng)由用戶終端102a的收發(fā)器設備在網(wǎng)絡100上通信。正如對于目的地終端102b更詳細地討論的，操作系統(tǒng)還可以掛起諸如客戶端應用那樣的應用的執(zhí)行。目的地用戶終端102b也包括相應的操作系統(tǒng)400b、VoIP通信系統(tǒng)的通信客戶端402b，諸如電子郵件客戶端404和視頻游戲406那樣的其它應用、和用戶接口408b。通信客戶端402b被存儲在目的地終端102b的存儲器（以諸如電子或磁存儲設備那樣的有形存儲介質(zhì)的形式），并被安排成在目的地終端102b的處理設備上執(zhí)行。VoIP客戶端應用402b和其它應用404、406被說成是在操作系統(tǒng)400b上運行，因為它們被調(diào)度用于由操作系統(tǒng)例如以交替的方式和/或在并行的處理資源上執(zhí)行，這樣使得每個應用在操作系統(tǒng)400b的控制下被分配以至少某些處理資源。當被調(diào)度時，VoIP客戶端402b能夠經(jīng)由用戶接口408b而與用戶交互，并能夠經(jīng)由目的地用戶終端102b的收發(fā)器設備在網(wǎng)絡100上通信。對于其它應用404和406，當它們被調(diào)度時，情況同樣如此。如上所述，操作系統(tǒng)400b還可以具有如下的能力，即掛起諸如VoIP客戶端402b那樣的應用，或把它置于某個其它后臺狀態(tài)，由此它僅僅被分配以每個單位時間非常有限的處理資源量。在實施例中，由操作系統(tǒng)400b進行的調(diào)度包括把每個應用402b、404、406置于某種前臺狀態(tài)或后臺狀態(tài)的能力。前臺狀態(tài)可包括其中前臺應用是在當前時間正在運行的主要的、占優(yōu)勢的應用的狀態(tài)。這方面的具體例子是在全屏模式下運行的應用，在其中以其它應用為代價它被分配以整個屏幕資源。例如，視頻游戲406當運行時可被給予全屏或其它占優(yōu)勢的前臺狀態(tài)，因為用戶可能需要全屏來玩游戲和/或游戲可能消耗相當大量的處理資源，使得可以使有限的處理資源或沒有處理資源可用于其它應用（諸如VoIP應用402b和電子郵件客戶端204）。這種情景特別可能在諸如手持移動電話那樣的移動終端上發(fā)生，在移動終端中比起比如說臺式計算機，資源是相對有限的。前臺狀態(tài)的另一個實例可包括其中沒有一個應用相對于任何其它應用具有優(yōu)勢狀態(tài)的狀態(tài)，例如，終端102b的用戶具有打開的桌面，沒有應用被最大化，且VoIP應用402b被操作系統(tǒng)400b允許有足夠的處理資源用于完全操作，而不受抑制來有利于諸如視頻游戲406那樣的任何其它應用。然而，當諸如視頻游戲406那樣的一個應用處在占優(yōu)勢的前臺狀態(tài)時，一個或多個其它應用402b、404可以由操作系統(tǒng)400b放置在后臺狀態(tài)。VoIP客戶端402b對此可以是特定的候選者。替換地或附加地，在其它時間，操作系統(tǒng)400b可以把諸如VoIP客戶端402b那樣的應用放置在后臺狀態(tài)，以便節(jié)省電池資源。在這樣的后臺狀態(tài)下，VoIP客戶端402b或者被掛起，這意味著它不被操作系統(tǒng)400b調(diào)度以任何處理周期，或者至多被抑制，以使得它與非抑制的前臺狀態(tài)相比只被調(diào)度有限的周期。在被抑制的狀態(tài)下，客戶端402b可能只有非常有限的功能性，其中它可能不能單方面處理進入的呼叫邀請或通知，或可能不能通過使用完全資源來處理呼叫邀請或通知，而完全資源在另外的情況下在更高的功能性狀態(tài)下將是可用的。在前臺狀態(tài)下，VoIP客戶端402b完全能夠收聽進入的邀請或通知，它通過在目的地用戶終端102b的網(wǎng)絡套接字412上進行收聽而做到這一點。網(wǎng)絡套接字是網(wǎng)絡地址與被分配供諸如VoIP客戶端402b那樣的應用使用的傳輸層端口的組合，典型地，IP套接字是IP地址與端口號的組合。例如，在前臺狀態(tài)下，VoIP客戶端402b可能能夠直接從始發(fā)終端102a接收常規(guī)的P2P呼叫邀請（CI），并隨之處理該邀請，以便接受呼叫，和/或可能能夠接收和處理來自VoIP提供者204的應用層推送通知（PN_AL）。在實施例中，在后臺狀態(tài)下，VoIP客戶端402b不具有被調(diào)度的周期，它必須依賴于基于操作系統(tǒng)的推送通知服務202，或具有太有限的周期以致于不能依賴于除了基于操作系統(tǒng)的推送通知服務之外的任何事物。在這種情形下，基于操作系統(tǒng)的推送通知（OS_PN）被操作系統(tǒng)400b接收，該操作系統(tǒng)作為響應把屏幕上提示顯示在目的地終端102b上。該提示通知被呼叫者：有通信事件請求注意，并提示用戶選擇是退出全屏模式，還是相反使得能喚醒一個或多個占優(yōu)勢的應用。屏幕上提示的格式可以由操作系統(tǒng)400b支配，可選地具有可以在推送通知中被規(guī)定的幾個參數(shù)。在一些實施例中，提示可以向用戶通知的僅僅是有未指定的（unspecified）通信事件這一事實，并通常詢問是否從全屏或待機狀態(tài)喚醒電話。在其它實施例中，提示可包括某些允許用戶作出有根據(jù)的決定的附加信息，例如，關于通信事件是進入的呼叫的指示，和/或關于呼叫者的身份的用戶看得見的信息（例如，顯示名）。這樣的附加信息可以從所接收的推送通知的有用負荷中導出。而且，如果用戶接受進入的事件，則在操作系統(tǒng)400b與VoIP客戶端402b之間的適當API410可以傳遞從推送通知有用負荷導出的某些信息直到醒來的應用402b，使得在目的地終端102b上的VoIP客戶端402b可以制定響應，并把該響應返回給始發(fā)終端102a。這個有用負荷信息可包括機器可讀的標識符信息，諸如在通信系統(tǒng)內(nèi)標識呼叫者的用戶名，和/或在網(wǎng)絡100內(nèi)標識呼叫者的終端102a的地址。在替換實施例中，可以存在有VoIP客戶端402b的后臺狀態(tài)，由此該VoIP客戶端402b被操作系統(tǒng)400b調(diào)度以有限的周期，但仍舊是足夠的周期來至少在套接字412上收聽應用層推送通知，和對所接收的通知執(zhí)行至少某些處理，甚至是潛在地以便制定接受響應，并在喚醒之前把該響應返回給始發(fā)終端（然而仍舊需要喚醒，以便實際進行呼叫，即，一旦進入的和外出的話音和/或視頻流開始就處理它們）。通過使用基于操作系統(tǒng)的推送通知服務，該通知被發(fā)送到操作系統(tǒng)400b，并至少一開始由操作系統(tǒng)處理（盡管操作系統(tǒng)400b隨后傳遞至少某些有用負荷直到應用402b）。這不同于應用層通知，其中操作系統(tǒng)400b給應用402b調(diào)度至少一些周期，這些周期足以讓它在相關的套接字上收聽推送通知，并且對所接收的通知執(zhí)行至少某些處理，而不依靠操作系統(tǒng)400b的任何專門的推送通知機制。圖5提供按照本發(fā)明的一個示例性實現(xiàn)的、VoIP提供者的呼叫控制與通知單元204的示意性框圖。網(wǎng)絡單元204包括：呼叫控制器502、被耦合到呼叫控制器502的未接呼叫寄存器504、被耦合到呼叫控制器502與基于操作系統(tǒng)的推送通知服務（OSPNS）202的推送通知中心（hub）506、使能推送的端點（PEE）寄存器508、被耦合到呼叫控制器510的解析器功能510、和用于把在始發(fā)用戶終端102a上的呼叫者客戶端402a耦合到呼叫控制器502的連接適配器512。單元502、504、506、508、510、512中的每一個可被實施為軟件的模塊，這些軟件被存儲在VoIP提供者204的一個或多個服務器單元的存儲器上（以諸如磁或電子存儲設備那樣的有形存儲介質(zhì)的形式），并被安排成在VoIP提供者204的一個或多個服務器單元上運行。所述一個或多個服務器單元包括被安排來執(zhí)行軟件的處理設備，和被安排來在因特網(wǎng)100或其它這樣的基于分組的網(wǎng)絡上執(zhí)行相關通信的收發(fā)器設備。目的地用戶終端102b可以被登記為使能推送的端點（PEE），且在目的地終端102b上的被呼叫者客戶端402b可被安排成能夠經(jīng)由IP套接字412接收來自推送通知中心506的一個或多個應用層推送通知（PN_AL），和/或操作系統(tǒng)400b可被安排成能夠接收來自基于操作系統(tǒng)的服務202的、一個或多個基于操作系統(tǒng)的推送通知（PN_OS）。在后者的情形下，在目的地終端102b上的被呼叫者客戶端402b可被安排成能夠經(jīng)由API410接收來自基于操作系統(tǒng)的推送通知（PN_OS）中的一個或多個的有用負荷信息。在運行時，在始發(fā)終端102a上的呼叫者的VoIP客戶端402a通過經(jīng)由因特網(wǎng)100和連接適配器512形成與呼叫控制器502的連接而開始。該連接可以提供可識別的連接，以使得由呼叫控制器502通過與連接適配器512的給定連接而從呼叫者客戶端402a接收的任何通信被識別為源自特定的已知源。連接適配器512可以認證呼叫者的身份，以使得通過與連接適配器512的連接而被接收的任何通信被識別為源自其身份已被安全地驗證的源。在步驟S12，呼叫邀請的一個版本作為對等消息通過網(wǎng)絡100使用對等連接從客戶端402a發(fā)送到客戶端402b。作為對等消息被發(fā)送的呼叫邀請通過使用以上相關于圖1描述的技術從客戶端402a被路由到客戶端402b。為了接收在步驟S12通過使用對等傳遞機制被發(fā)送的呼叫邀請，客戶端402b必須在被呼叫者終端102b處在前臺運行。在實施例中，連接適配器512提供前端部件，該前端部件通過使用適當?shù)恼J證機制（它可以是私有的）來認證客戶端，以及還終結(jié)客戶端的連接。連接適配器512然后可以對于服務的其余部分，特別是對于呼叫控制器，用作為客戶端身份的權(quán)威性源（參見后面相關于圖5的討論）。因此，在實施例中，呼叫者的身份不需要由呼叫者自己在有用負荷中提供，這是有益的，因為不然的話身份可以被偽造，且因而將是不可信任的。在步驟S20和/或步驟S30（對應于圖2和圖3所顯示的那些步驟），在呼叫者的用戶終端102a上的客戶端402a使用經(jīng)由連接適配器512的連接把呼叫邀請（CI）的另一個版本發(fā)送到VoIP提供者204的呼叫控制器502?？梢钥吹剑艚醒埖膬蓚€版本從客戶端402a通過不同的傳遞機制并行地被發(fā)送。在這個意義下，呼叫邀請從客戶端402a散開。為了建立呼叫，必須交換握手協(xié)議的兩個消息，它們形成握手的兩半——第一個從一個端點到另一個端點，然后第二握手消息作為回復，同意該呼叫。在實施例中，從呼叫者客戶端402a發(fā)送的呼叫邀請包括第一握手消息HS1。在實施例中，HS1可以是P2P會話建立消息。在這種情形下，它包含使該消息的接收者能夠繼續(xù)與發(fā)送者協(xié)商P2P傳輸會話的足夠信息（諸如，可被使用來進行呼叫）。它可包含呼叫者通過其可被聯(lián)系到的一個或多個IP地址，并潛在地包含一些其它信息。這個消息用作為讓P2P會話建立的邀請。一旦認證的和加密的會話被建立，呼叫信令就可以通過該會話流動。中繼信息和用戶名是與HS1分開的一些東西，且那些可以當在行進的同時HS1不可用或者到期時在回退機制中使用。然而，應當指出，本發(fā)明不限于P2P或混合P2P布置，在其它實施例中，會話建立的某些或所有的后續(xù)階段可以經(jīng)由諸如一個或多個服務器那樣的集中式單元進行。響應于接收到來自呼叫者客戶端402a的呼叫邀請，呼叫控制器506然后制定內(nèi)部推送通知請求PNR_i。在實施例中，這牽涉到在步驟S50呼叫控制器502引用解析器功能510來解析呼叫者和/或他或她的用戶終端102a的標識符信息—“用戶解析”信息（UR）。解析器510維護用戶和/或用戶終端相關的信息的列表，呼叫控制器502可以根據(jù)與連接適配器512的已識別的連接來查詢該列表。用戶解析（UR）可以歸為兩類。第一類是標識符信息，它將被使用來允許被呼叫者的客戶端402b在響應時聯(lián)系呼叫者。這可包括：標識VoIP通信系統(tǒng)內(nèi)的呼叫者的呼叫者用戶名；和/或-呼叫者的始發(fā)用戶終端102b的、在網(wǎng)絡內(nèi)標識其的地址（典型地是IP地址）；和-可選地，附加的路由信息，諸如使用來聯(lián)系呼叫者的任何一個或多個中繼的標識，例如102c。第二類UR信息（其在實施例中可以是可選的）是允許被呼叫者做出關于是否回答呼叫的有根據(jù)的決定的信息。這可包括：-呼叫者的顯示名（不同于用戶名）；-呼叫者的化身圖像；和/或-使用來向被呼叫者通知進入的呼叫的語言的指示，其可擴展到規(guī)定用于屏幕上通知消息的語法的語言模板，因為屏幕上通知消息將出現(xiàn)在被呼叫者的終端102b處。在實施例中，語言或語言模板可以根據(jù)被呼叫者和/或呼叫者的身份被解析。呼叫者的身份（例如，用戶名）也將已被包括在呼叫邀請（CI）中，并且它可被使用于這個用途以及識別目的地。在實施例中，解析器功能510還可包括許可檢查功能，它維護這樣的用戶的列表，即：被呼叫者已阻擋所述用戶聯(lián)系他或她。許可檢查起到阻擋來自在這個列表中發(fā)現(xiàn)的任何呼叫者的呼叫邀請的作用，且用于通知被呼叫者的后面的步驟僅僅在呼叫者沒有被阻擋的條件下才進行。假設這沒有發(fā)生，那么呼叫控制器502制定包括用戶解析信息、HS1消息和在呼叫邀請（CI）中接收的任何其它相關信息的有用負荷（參見下文）。在步驟S52，呼叫控制器502然后在內(nèi)部推送通知請求PNR_i中把這個有用負荷轉(zhuǎn)發(fā)到推送通知中心506。可被包括在有用負荷中的附加信息如下。-時間戳，其指示發(fā)出邀請的時間。這可被使用來檢測建立呼叫的企圖何時超時。例如，用于超時的期限可以是在30-60秒范圍內(nèi)，在一個實施例中，是50秒。時間戳可被包括在從呼叫者客戶端402a發(fā)送的呼叫邀請中，然后在有用負荷中被轉(zhuǎn)發(fā)，或者在時間戳還沒有被包括在從呼叫者的客戶端402a接收的邀請中的情況下，由呼叫控制器502生成。-密鑰交換方案的加密密鑰，其是呼叫者的公共密鑰（所以被呼叫者可以解密呼叫者的內(nèi)容）。這可被包括在從呼叫者客戶端402a發(fā)送的呼叫邀請中，然后在有用負荷中被轉(zhuǎn)發(fā)，或替換地，被存儲在解析器512，并被呼叫控制器502添加作為用戶解析信息的另一個實例。-始發(fā)端點102a的類型的指示（例如，它是移動電話、平板電腦、膝上型計算機還是臺式計算機？它運行什么操作系統(tǒng)，它運行VoIP客戶端402a的什么版本，和/或它是什么型號）。再次地，這可被包括在從呼叫者客戶端402a發(fā)送的呼叫邀請中，然后在有用負荷中被轉(zhuǎn)發(fā)，或替換地，被存儲在解析器512，并被呼叫控制器502添加作為解析的一部分。-用于呼叫的呼叫標識符（例如，會話標識符），它可被呼叫者的客戶端402a或呼叫控制器502添加。再次地，這可被包括在從呼叫者客戶端402a發(fā)送的呼叫邀請中，然后在有用負荷中被轉(zhuǎn)發(fā)，或替換地，被存儲在解析器512，并被呼叫控制器502添加。-用于呼叫的談話標題和/或其它談話標識符，它是該呼叫作為其一部分的邏輯話題或上下文的指示，例如在呼叫形成牽涉到IM消息和/或先前的呼叫的更廣泛談話的組成部分的情況下。這優(yōu)選地從來自呼叫者的客戶端402a的呼叫邀請中被取得。推送通知中心506接收內(nèi)部推送通知請求PNR_i。作為響應，在步驟S53，它查詢使能推送的端點（PEE）寄存器508，以檢查被呼叫者是否已登記接收推送通知。PEE寄存器508維護已登記接收推送通知（或等價地，如果接收推送通知是缺省的話，還沒有解除登記接收推送通知）的用戶的列表。例如，這可以是當用戶第一次啟用新的電話102b時呈現(xiàn)給他或她的選項，或是在他或她的終端102b的選項屏幕上發(fā)現(xiàn)的選項。隨后，當如在所顯示的情景下那樣試圖進行呼叫時，PEE寄存器508采取行動，以便僅僅在被呼叫者同意他或她的設備102b將能夠接收推送通知（或等價地沒有決定退出）的條件下才許可進行后面的推送通知步驟。假設被呼叫者針對推送通知被登記，推送通知中心則完成以下兩件事之一或二者：-發(fā)送外部推送通知請求PNR到基于操作系統(tǒng)的推送通知服務202（對應于圖2的步驟S22），進而又使得基于OS的推送通知服務202把基于操作系統(tǒng)的推送通知（PN_OS）發(fā)送到目的地終端102b上的操作系統(tǒng)400b（對應于圖2上的步驟S24）；和/或-制定應用層推送通知（PN_AL），并把它直接發(fā)送到目的地終端102b上的被呼叫者的客戶端402b（對應于圖3上的步驟S32）。可以看到，呼叫邀請的兩個版本從推送通知中心506通過不同的傳遞機制并行地被發(fā)送。在這種意義下，呼叫邀請從推送通知中心506散開。因此，呼叫控制器502和推送通知中心506處理在步驟S20從客戶端402a接收的呼叫邀請，以生成呼叫邀請的多個版本。另外，在步驟S53，推送通知中心可以把指示被呼叫者的端點數(shù)量的消息（NEP）發(fā)回到呼叫控制器502（被呼叫者可以使多個設備登記到PEE寄存器508）。這可被呼叫控制器使用來跟蹤它可以潛在地預期來自被呼叫者的多少個設備的考勤報告（attendancereport,AR）（參見步驟S56）。推送通知中心506采取行動來把從呼叫控制器502接收的至少某些有用負荷信息包括在推送通知中（在基于OS的推送通知PN_OS的情形下經(jīng)由OSPNS202）。在實施例中，有用負荷信息的量可以由推送通知中心506根據(jù)它要被包括到其中的推送通知的類型，是基于應用層還是基于操作系統(tǒng)，來進行選擇。在由推送通知中心506制定的應用層推送通知的情形下，這可包括多達以上討論的全部量的任何量的有用負荷信息，且包含所述全部量或更多。這可包括握手協(xié)議的第一握手消息HS1，和多達全部用戶解析信息（UR）的任何信息，包括呼叫者的用戶名、始發(fā)地址、呼叫者的顯示名、用于呼叫者的化身圖像（或到化身圖像的鏈接）和語言指示符或模板。這個有用負荷信息在應用層推送通知PN_AL中被提供給被呼叫者客戶端402b。如果在被呼叫者的終端102b上的客戶端402b接收到應用層推送通知PN_AL，則它提取有用負荷信息，并使用這個信息來向被呼叫者通知進入的呼叫。這可包括提取用戶解析信息的用戶可讀的部分，諸如顯示名、化身圖像（或到化身圖像的鏈接）和/或語言模板，并使用它來生成適當?shù)钠聊簧贤ㄖ?。例如，屏幕上消息可以示出化身圖像，并顯示例如以英語格式“youhaveanincomingcallfrom[displayname]”或以法語格式“[displayname]voustéléphoner”的寫下的消息。這個消息的語言和語法（即，語言格式）由語言模板規(guī)定。語法規(guī)定例如在句子中的什么地方包括顯示名。而且，假設被呼叫者回答該呼叫，則在被呼叫者的終端102b上的客戶端402b被配置成從推送通知的有用負荷中提取握手消息HS1和用于在響應時聯(lián)系呼叫者的那部分用戶解析信息，由此制定呼叫接受響應（CA），并把該響應用信號通知回呼叫者的終端102a上的始發(fā)客戶端402a。在接收到HS1后，被呼叫者的客戶端402b制定呼叫接受響應CA，其包括握手協(xié)議的回答的半部分，HS2消息。在步驟S58，被呼叫者的客戶端402b然后根據(jù)至少包括呼叫者的用戶名和/或呼叫者的終端102a的地址的相關用戶解析信息，把這個接受響應用信號通知回始發(fā)終端102a上的客戶端402a。優(yōu)選地，這是通過使用有用負荷信息被完成的，不需要在被呼叫者決定是否回答該呼叫之前在網(wǎng)絡100上的任何其它信令來檢索用于聯(lián)系呼叫者的終端102a的標識符信息，或檢索信息以便向他或她標識呼叫者。對于這些用途，不需要向后的對于諸如單元204或202的任何提供者或運營者基礎設施的額外指引（referral）。因此，在呼叫信令中往返行程的數(shù)量減小，這意味著用于實現(xiàn)呼叫接受的時間可以減少。在實施例中，被呼叫者的客戶端402b可以僅僅在其被發(fā)現(xiàn)在通知的時間處于前臺（f/g）狀態(tài)的情況下接收應用層推送通知PN_AL，因為在這個狀態(tài)下，它具有被調(diào)度的足夠的處理周期，而能夠在IP套接字412上收聽并且當應用層推送通知PN_AL被檢測到時處理它。然而，在某些實現(xiàn)中，有可能被呼叫者的客戶端402b可以被分配以特別的后臺狀態(tài)，由此雖然它被調(diào)度以受抑制的處理時間量，但它仍舊具有足夠的周期而能夠檢測和按照應用層推送通知PN_AL行動。在步驟S56，被呼叫者的客戶端402b還可以把考勤報告（AR）報告回呼叫控制器502，指示它已接受該呼叫。呼叫控制器502可以使用這個來跟蹤呼叫是否被回答，或在呼叫被回答之前它是否超時。在經(jīng)由服務202生成的基于操作系統(tǒng)的推送通知PN_OS的情形下，這可以包括來自以上討論的潛在有用負荷信息當中的減小的有用負荷信息量。例如，這可包括握手消息HS1，和某些選擇的用戶解析信息（UR’），優(yōu)選地至少是呼叫者的用戶名和/或呼叫者的用戶終端102a的地址。語言或語言模板仍舊可被用作為有用負荷信息。這個有用負荷信息在基于操作系統(tǒng)的推送通知PN_OS中被提供給目的地終端102b上的操作系統(tǒng)400b。如果被呼叫者的終端102b上的操作系統(tǒng)400b接收到基于操作系統(tǒng)的推送通知PN_OL，則它生成屏幕上消息來向被呼叫者通知進入的呼叫?？蛇x地，這可牽涉到從有用負荷信息提取的某些有限的參數(shù)被插入到操作系統(tǒng)400b的預定義的屏幕上消息格式中。例如，進行接收的操作系統(tǒng)400b可以從所接收的有用負荷中確定呼叫者的顯示名以及適當?shù)恼Z言模板是英語模板“youhaveanincomingcallfrom[displayname]”或法語模板“[displayname]voustéléphoner”的事實。然而，屏幕上消息格式的其它方面可由操作系統(tǒng)400b支配，例如，它的尺寸、它的“外觀和感覺”以及任何相關聯(lián)的圖形。例如，如果被呼叫者在通知的時間正在全屏或另外的占優(yōu)勢的狀態(tài)下玩視頻游戲406或使用某些其它應用，則操作系統(tǒng)可以使得小的通知消息在諸如屏幕的角落那樣的相對不引人注意的位置處彈出。由被呼叫者的操作系統(tǒng)400b生成的屏幕上消息提示被呼叫者要采取什么行動，例如，是否接電話，或是否不理會該通知并繼續(xù)玩游戲406。正如前面討論的，目的地VoIP客戶端406b在進入的通知的時間可能處在后臺(b/g)狀態(tài)。如果在響應操作系統(tǒng)提示時被呼叫者確實選擇接受該呼叫，則操作系統(tǒng)喚醒被呼叫者的VoIP客戶端402b。這可牽涉到結(jié)束先前正在前臺中運行的應用（例如，游戲406）的全屏或其它這樣的優(yōu)勢狀態(tài)。在被呼叫者的終端102b上的操作系統(tǒng)400b也將傳遞至少一定量的有用負荷信息直到新恢復（restore）的VoIP客戶端402b，優(yōu)選地是第一握手消息HS1和至少某些用于在響應時聯(lián)系呼叫者的用戶解析信息，即，呼叫者用戶名和/或始發(fā)終端地址。當被呼叫者VoIP客戶端402b醒來時，它因此能夠制定包括返回握手消息HS2的呼叫接受響應CA，并把這個響應定址回呼叫者的用戶終端102a上的始發(fā)客戶端402a。優(yōu)選地，在推送通知中接收的有用負荷信息因此仍舊足以制定呼叫接受響應（CA），而在被呼叫者決定是否回答該呼叫之前不需要網(wǎng)絡100上的任何其它信令來檢索用于聯(lián)系呼叫者的終端102a的標識符信息，或檢索用來向他或她標識呼叫者的信息。因此，再次地，在呼叫信令中往返行程的數(shù)量，因而是用于呼叫接受的時間可以減少。再次地，在步驟S56，被呼叫者的客戶端402b還可以把考勤報告（AR）報告回呼叫控制器502，指示它已接受呼叫。呼叫控制器502可以使用這個來跟蹤該呼叫是否被回答，或在呼叫被回答之前它是否超時。在步驟S60，當必要時，呼叫控制器502更新未接呼叫（missedcall）寄存器504。未接呼叫寄存器504存儲對于被呼叫者的有關未接呼叫的信息。如果呼叫邀請的各版本沒有一個被回答（例如，在它們的超時時段內(nèi)），則未接呼叫寄存器504被更新，以將有關該呼叫的信息存儲為對于被呼叫者的未接呼叫。被呼叫者可以發(fā)送查詢到網(wǎng)絡單元204，用于檢索對于該被呼叫者的關于未接呼叫的信息。如果呼叫邀請的任一個版本被回答，則阻止未接呼叫寄存器504被更新來將該呼叫的細節(jié)存儲為對于被呼叫者的未接呼叫，即使呼叫邀請的某些版本沒有被回答。這樣，如果呼叫邀請的某些版本，但不是所有版本，沒有被回答，則未接呼叫寄存器504將不指示呼叫未接。呼叫邀請的各版本中的呼叫ID和邀請ID的存在使得不同的版本能夠與同一個呼叫和同一個呼叫邀請相關聯(lián)，這樣使得未接呼叫寄存器504可以被正確地更新。未接呼叫標記可以在被呼叫者終端102b上實施，其中即使客戶端402b沒有運行在前臺，未接呼叫標記也可以在終端102b上顯示給被呼叫者。未接呼叫標記指示對于被呼叫者的、其信息被存儲在未接呼叫寄存器504中的未接呼叫的數(shù)量。網(wǎng)絡單元204可以發(fā)送消息到客戶端402b以更新未接呼叫標記。在各種實施例中，基于應用層和基于操作系統(tǒng)的推送通知機制并行存在。推送通知中心可以并行嘗試這兩種通知方法。而且，在始發(fā)用戶終端102a上的呼叫者客戶端402a仍可以用來把常規(guī)的P2P呼叫邀請（CI，步驟S10）通過因特網(wǎng)100直接發(fā)送到目的地用戶終端102b上的被呼叫者客戶端402b。不同的傳遞機制可以適用于不同的狀況。因此，通過多種傳遞機制發(fā)送呼叫邀請可以是有利的。例如，當客戶端402b在終端102b處運行在前臺時，在步驟S12通過對等連接被發(fā)送的呼叫邀請或在步驟S32通過基于應用層的推送通知系統(tǒng)被發(fā)送的呼叫邀請可以首先被客戶端402b接收。然而，當客戶端402b在終端102b處是在后臺狀態(tài)時，則它可能不能經(jīng)由對等連接或經(jīng)由基于應用層的推送通知系統(tǒng)接收呼叫邀請。因此，在這些情形下，在步驟S24通過基于操作系統(tǒng)的推送通知系統(tǒng)發(fā)送的呼叫邀請可以是對于該呼叫的、要由客戶端402b接收的第一個（并且可能是唯一的）呼叫邀請。因此，可以意識到，通過多種傳遞機制發(fā)送呼叫邀請的各版本提供了在各種條件下呼叫邀請的快速和可靠的傳遞。網(wǎng)絡條件（例如，網(wǎng)絡100上當前的負荷）也可以對在不同傳遞機制上的呼叫邀請的傳遞造成不同程度的影響。在一些實施例中，HS1可以不被包括在來自被呼叫者的呼叫邀請（CI）中（步驟S20/S30）。替代地，該交換可能要求被呼叫者在對于初始通知的響應中發(fā)送HS1給呼叫者，并且要求呼叫者然后用第二握手消息HS2進行回答，以便建立反向會話。如上所述，網(wǎng)絡節(jié)點（例如，呼叫者終端102a或控制器網(wǎng)絡單元204）可被安排來發(fā)送呼叫邀請的多個版本，以用于在呼叫者客戶端402a與一個或多個被呼叫者客戶端402b之間建立呼叫。呼叫邀請的各版本通過多種不同的傳遞機制被發(fā)送，其中呼叫邀請的多個版本的每個版本包括呼叫的標識符，以及傳遞機制之一包括在推送信道上的推送通知（例如，在步驟S24或S32）。呼叫邀請的多個版本可以全部被發(fā)送到在一個被呼叫者終端102b上實施的一個被呼叫者客戶端402b。替換地，呼叫邀請的多個版本可以被發(fā)送到在被呼叫者的不同被呼叫者終端102b上實施的不同的被呼叫者客戶端402b。例如，呼叫邀請的每個版本可被發(fā)送到在被呼叫者的不同被呼叫者終端102b上實施的不同的被呼叫者客戶端402b。當呼叫邀請的版本之一被回答時，或者在預定的超時時間（例如，30到60秒）后，呼叫邀請的任何未完成（outstanding）的版本可被取消。在一些實施例中，當呼叫邀請的版本之一被回答時，呼叫邀請的未完成的版本可能不被取消。在這種情形下，如果被呼叫者客戶端402b已經(jīng)接收到包括特定的邀請ID的呼叫邀請的某個版本并隨之做出響應（例如，向用戶通知呼叫邀請或建立呼叫），以及然后被呼叫者客戶端402b接收到也包括該特定邀請ID的呼叫邀請的另一個版本，則被呼叫者客戶端402b可以通過使用邀請ID來確定呼叫邀請的某個版本已被接收。在那種情形下，被呼叫者客戶端402b可以不必采取進一步的行動。因此，當呼叫邀請的一個版本被回答時，不是取消呼叫邀請的未完成的版本，而是可以允許呼叫邀請的未完成的版本進到被呼叫者客戶端402b，其中被呼叫者客戶端402b使用邀請ID（或在一些實施例中用呼叫ID）來確定：由于呼叫邀請的一個版本已經(jīng)由被呼叫者客戶端402b接收，所以不需要采取行動來響應于接收到呼叫邀請的新版本。這里描述的方法可以通過執(zhí)行計算機程序產(chǎn)品而被實施，所述計算機程序產(chǎn)品包括在非瞬態(tài)計算機可讀介質(zhì)上體現(xiàn)的代碼。在實施例中，一旦以上的呼叫信令被執(zhí)行，就可以通過像常規(guī)P2P方式中那樣在被呼叫者與呼叫者之間交換證書而以相互的方式進行用戶認證。替換地或附加地，當連接適配器在形成初始連接的時間驗證呼叫者的身份時，認證可以由連接適配器集中地執(zhí)行。在認證是在以上的信令之后通過交換證書而完成的情形下，應當指出，呼叫接受響應CA不是用于成功地進行呼叫的一個絕對的最后準則，而是服從于認證的臨時接受（其在大多數(shù)情形下多半不是問題，只要通信不是惡意的）。在其它實施例中，認證可以僅僅依靠由連接適配器進行的對于呼叫者的初始認證。在某些實施例中，在建立呼叫的過程中認證的兩個階段均可以使用。第一，呼叫者客戶端在連接適配器512上認證它自己，然后通過建立的已認證的傳輸把邀請發(fā)送到呼叫控制器502。這是第一次認證，且它被使用來在服務器204上認證客戶。當包含HS1的推送通知到達被呼叫者客戶端時，這是用來在客戶端之間建立被認證的直接（P2P）連接的第一個步驟，并且這是發(fā)生第二次認證的場合。第一階段是集中式認證，而相反，第二階段是P2P認證。應意識到，以上的實施例是僅僅作為例子被描述的。例如，雖然以上內(nèi)容是相對于用于執(zhí)行VoIP呼叫的混合P2P系統(tǒng)進行描述的，但這里公開的技術可應用到其它類型的基于分組的通信系統(tǒng)。因此，在替換實施例中，在通知之后，會話建立（諸如，可被使用來進行呼叫）的一個、一些或所有的另外的階段可以替換地經(jīng)由一個或多個網(wǎng)絡集中式單元——諸如一個或多個提供者或運營者的一個或多個服務器——而進行。對于其中使用某些P2P技術的實施例，還應當指出，在它最廣泛的意義下，術語P2P不是必然地限于完全去集中化的布置。例如在一些實例中，只有媒體（即，呼叫或其它會話的內(nèi)容）需要在對等體之間直接傳送，而所有其它的呼叫信令（包括地址查找和認證）經(jīng)由中央單元發(fā)生。而且，在以上依據(jù)服務器來描述任何網(wǎng)絡單元的場合下，應意識到，這不限于單個服務器單元，或者收容在同一個外殼中或位于同一個地點的服務器們。通過一個或多個單元中的任何單元被實施的任何邏輯網(wǎng)絡單元可被使用來實施按照本發(fā)明的實施例的通信提供者功能。而且，雖然以上內(nèi)容是依據(jù)因特網(wǎng)的通信進行描述的，但本發(fā)明也可以被使用于通過其它基于分組的通信網(wǎng)提供通知，和/或通過其它基于分組的通信網(wǎng)告知通信。在給出這里的公開內(nèi)容后，本領域技術人員可以明白其它變例。本發(fā)明不受所描述的實施例限制，而僅僅由所附權(quán)利要求限制。