加入調度呼叫的方法
2023-06-09 10:10:56 3
專利名稱：加入調度呼叫的方法
技術領域：
本發明涉及加入調度呼叫會話，尤其涉及邀請參與者加入調度呼叫的方法。
背景技術：
目前，大多數調度即按即說(push-to-talk)呼叫是強制類型的呼叫。也就是說，一旦始發者選擇了他要與之講話的一個或多個人，被選擇的或目標用戶的電話音頻就會即刻響亮地發出講話者的話語。由於目標或接收用戶不能控制接收語音的時間，所以該呼叫稱為強制呼叫。目標呼叫者被通信網絡的呼叫處理伺服器強制加入到呼叫中，所述呼叫處理伺服器自動將目標用戶裝置移到承載信道，並將它們連接到源自始發用戶的音頻或其他媒體。這些是強制呼叫。這種強制呼叫常常導致音頻或其他媒體在不合適的時間在目標用戶的裝置上響亮地發聲。例如，工作在要求他不能分心的項目上的工作人員不希望在他正攀登梯子或在腳手架上平衡時他的調度無線電突然響起。
而且，在如今的調度呼叫中，不可能目標單元的每一個都具有用於接收強制調度呼叫的人機工程學要求。也就是說，計算機或特定的音頻無線電話(例如典型的蜂窩電話)可能不具有高音頻性能，例如揚聲器電話，並且不能接收強制調度呼叫。
目前，調度電話沒有向目標用戶提供拒絕強制呼叫的性能。
因此，非常希望擁有向始發用戶提供以非強制模式操作的能力的方法。而且，非常希望向調度呼叫的目標用戶提供接受或拒絕這種強制或非強制呼叫的能力。
圖1是支持調度呼叫服務的通信網絡互連的框圖。
圖2是用於始發用戶的調度呼叫方法的流程圖。
圖3是用於調度呼叫中目標用戶的調度呼叫建立方法的流程圖。
具體實施例方式
圖1示出了便於調度呼叫服務的通信系統。通信系統100包括通信網絡10，它具有呼叫處理伺服器50，便於終端20-40之間的承載業務的交換和傳輸。儘管優選實施例中示出了呼叫處理伺服器50，但它是可選單元。分布式呼叫處理也是可能的，其中，終端的每一個提供必須的始發或終止呼叫處理，而不需要呼叫處理伺服器50。為說明本發明的目的，將移動單元20作為始發單元，移動單元30和/或40作為目標單元。典型地，例如，始發單元20通過網絡10和呼叫處理伺服器50發送對目標移動單元40的調度呼叫請求。伺服器50和網絡10自動將目標單元40與始發單元20連接，並且目標單元的揚聲器開始響亮發出始發單元20的通信。這稱為強制調度呼叫。
目標移動單元40可能為某用戶(未示出)所擁有，該用戶正在進行要求他不能分心的行為，例如攀登梯子。使目標單元40響亮地發出來自始發單元20的通信會驚到該用戶並造成嚴重的傷害，等等。
另一種調度呼叫是邀請調度呼叫。邀請調度呼叫要求呼叫的目標用戶在該呼叫完成並釋放承載業務之前接受該呼叫。
參考圖2，示出了用於始發單元20的調度呼叫建立的方法流程圖。該方法開始，進入框101。框101確定始發者選擇了哪種類型的呼叫開始方法。如果調度呼叫類型是強制呼叫，則框101將控制轉到框105。如果沒有實時選擇任何方法，則始發用戶可以具有默認的調度呼叫方法。
框105通過網絡10和呼叫處理伺服器50向目標移動單元30和/或40發送強制調度呼叫請求。對於群組呼叫，目標單元30和40通常將都被選擇。對於單個調度呼叫，目標單元30或40中的一個或另一個將被選擇。
接下來，框109在一段可配置的時間內等待收集來自目標單元的呼叫接受或拒絕響應，其中該段時間適於強制呼叫處理。該時間可以設置為用戶裝置中的默認值，或者它可以根據用戶偏好來控制，並且通常在呼叫之前設置。對於強制呼叫，該時間典型地設置為比較短，例如0.5到2秒，這是由於期望多數目標將立即響應強制呼叫請求。作為另一個例子，如果始發者不關心目標方的參與(如在框121中確定的)，那麼該時間可以設置為0，以加快呼叫處理。
接下來，框121確定始發單元20是否關心哪些目標單元參與該呼叫。如果始發單元20不關心目標單元中的哪些參與該調度呼叫，則框121將控制經「否」路徑轉到框113。由始發單元20進行的這種傳輸典型地是到一組目標單元的廣播消息，該組目標單元不要求實時響應。
如果始發單元20關心哪些目標參與該調度呼叫，則框121將控制經「是」路徑轉到框115。
如果選擇的調度呼叫啟動方法的類型是邀請，則框101將控制轉到框103。框103經網絡10和呼叫處理伺服器50向目標用戶或多個用戶中的每一個發送邀請請求。
接下來，框107在一段可配置的時間內等待收集來自目標單元的呼叫接受或拒絕響應，其中該段時間適於邀請呼叫處理。該時間可以設置為用戶裝置中的默認值，或者它可以根據用戶偏好來控制，並且通常在呼叫之前設置。對於邀請呼叫，該時間典型地設置為比強制呼叫的長，例如10到20秒，這是由於期望對目標用戶單元的用戶給予一些時間來與用戶單元交互並響應邀請呼叫請求。
在接收到來自目標單元的響應之後，框107將控制轉到框115。典型地，邀請調度呼叫包括來自所有目標用戶的響應，但是系統100可以配置為可選地不對強制調度呼叫提供響應，如圖3中所描述的。
接下來，框115確定是否足夠的目標用戶接受以便進行該調度呼叫。接收該呼叫的「足夠」目標用戶的閾值是可配置的。它可以設置為僅一個用戶，例如對於強制呼叫，如果始發者只希望確保至少一個目標方在接聽。或者，它可以設置為潛在群組成員的數量的百分比，例如50％。或者，它可以設置為潛在群組成員的全部(100％)，以確保所有期望的目標都包括在該呼叫中。然後，如果配置閾值(或更多)的潛在群組呼叫目標接受了該呼叫，則控制將前進到框119。如果沒有足夠用戶接受，則框115將控制經「否」路徑轉到框117。框117忽略響應並且不發送任何承載業務。然後處理結束。
如果有足夠的目標用戶響應，則框115將控制經「是」路徑轉到可選框119。可選框119將關於誰接受了該呼叫的信息呈現給始發用戶，例如多少目標接受了該呼叫，哪些具體目標接受了該呼叫，哪些具體目標拒絕了該呼叫，等等。這允許始發用戶在簡單地知道達到了框115的接受閾值之外，關於是否完成對目標的呼叫作出基於可靠信息的決定。如果始發者選擇完成該呼叫，則始發單元開始向目標單元發送承載業務，框113。然後處理結束。
參考圖3，示出了用於移動單元30和40的調度呼叫啟動方法的流程圖。該方法允許目標移動單元30和40可選地在接收到強制或邀請調度呼叫時選擇行為。該方法允許目標單元的用戶選擇目標移動單元將展示出的偏好。
方法開始，進入框125。框125確定始發單元20請求的調度呼叫啟動方法。如果始發單元20發送了強制調度呼叫，則框125將控制轉到框127。接下來，框127確定目標用戶30和40的當前偏好。如果目標用戶的偏好設置為接受強制調度呼叫，則框127將控制轉到框129。框129自動接受承載業務。也就是說，始發者的音頻將在目標單元30和/或40的高音頻輸出(典型的是揚聲器)上輸出。在框129之前，可選步驟框128向始發單元20發送接受消息。這允許始發者關於哪個(些)目標接受了該呼叫作出基於可靠信息的判斷。然而，在不由目標單元30和/或40發送接受消息的情況下，圖2中描述的始發者流能夠適當地繼續。然後處理結束。
如果目標單元的偏好設置為拒絕強制調度呼叫，則框127將控制轉到框131。框131向始發單元發送拒絕消息，並且不接受任何承載業務。然後方法結束。
如果目標移動單元30或40將它的偏好設置為轉換強制調度呼叫，則框127將控制轉到框133。框133將強制調度呼叫轉換為邀請調度呼叫，並向目標用戶顯示邀請呼叫信息。接下來，框135，目標用戶確定是接受還是拒絕該邀請呼叫。如果目標用戶接受了轉換的邀請呼叫，則框135將控制轉到框137。稍後，框137使得目標單元30或40能夠接收承載業務。稍後表示如果目標單元30或40基於其判斷對呼入的調度呼叫請求進行了轉換，那麼根據始發單元10的配置，用於該呼叫的承載業務可能在目標用戶接受該呼叫的時間之前已經開始了。因此，目標單元30或40可能沒有接收整個傳輸，但這通常是承載業務的極小部分。在框137之前，可選步驟框136向始發單元20發送接受消息。這允許始發者關於哪個(些)目標接受了該呼叫作出基於可靠信息的判斷。然而，在不由目標單元30和/或40發送接受消息的情況下，圖2中描述的始發者流能夠適當地繼續。然後方法結束。
如果目標用戶確定拒絕該轉換的調度呼叫，則框135將控制轉到框131。框131向始發單元20發送拒絕消息，並且不接受任何承載業務。然後處理結束。
如果目標單元30或40已經確定始發者請求的調度呼叫請求是邀請請求，則框125將控制轉到框139。框139確定目標單元的偏好。如果目標單元30或40的偏好設置為自動接受，則框139將控制轉到框141。框141自動接受該邀請調度呼叫，並用接受消息響應始發單元。然後，目標單元30和/或40接受承載業務。然後方法結束。
如果目標單元30或40的偏好設置為自動拒絕邀請調度呼叫，則框139將控制轉到框149。框149向始發單元發送拒絕消息，並且不接受任何承載業務。然後方法結束。
如果目標單元30或40的偏好設置為指示用戶實時控制響應，則框139將控制轉到框143。框143通知目標用戶呼入邀請調度呼叫，並顯示呼叫者ID類型信息。接下來，框145確定目標用戶是否接受了該邀請調度呼叫。如果目標用戶沒有實時接受該邀請調度呼叫，則框145將控制經「否」路徑轉到框149。框149向始發單元發送拒絕消息，並且不接受任何承載業務。如果目標用戶接受該邀請調度呼叫，則框145將控制經「是」路徑轉到框147。框147向始發單元20發送接受消息，並且當承載業務被發送時接受它。然後方法結束。
上述所有偏好都可以是臨時設置，移動單元的用戶可以根據當前的通信需要和用戶行為改變它們。而且，可以基於用作目標單元的調度平臺的性能來自動設置目標單元的行為。例如，如果該平臺不接受或支持高音頻性能，那麼可以將目標調度單元設置為永不接受強制調度呼叫。
匯總表
注該表概括說明了在不經呼叫處理伺服器轉換呼叫類型情況下的行為。
從上面的說明中可以看出，本發明提供了一種新的用於移動調戶用戶的服務水平性能。始發和目標用戶都可以靈活設置它們用於處理邀請和強制調度呼叫的偏好。這些特徵包括對呼叫啟動方法設置默認值；自動接受或拒絕強制或邀請調度呼叫；支持與顯示邀請調度呼叫相關的特定邏輯。這些優點賦予調度呼叫功能極大的靈活性，並提供更加定製的用戶體驗(例如，白領和藍領環境)，以及增強的目標用戶安全性。
權利要求
1.一種用於始發單元和至少一個目標單元之間經通信網絡的調度呼叫的調度呼叫建立方法，該調度呼叫建立方法包括以下步驟向至少一個目標單元發送調度呼叫消息；確定來自所述至少一個目標單元的響應對於所述調度呼叫是否足夠；和如果來自所述至少一個目標單元的響應是足夠的，則完成在所述始發單元和所述至少一個目標單元之間的調度呼叫。
2.如權利要求1所述的調度呼叫建立方法，其中所述調度呼叫消息包括邀請消息的所選擇調度呼叫建立類型；以及如果所述至少一個目標單元的響應是不足的，則進一步包括步驟忽略所述至少一個目標單元的響應；和結束呼叫。
3.如權利要求2所述的調度呼叫建立方法，其中，如果所述至少一個目標單元接受了所述邀請消息，則進一步包括步驟完成在所述始發單元和所述至少一個目標單元之間經通信網絡的調度呼叫；和發送承載業務。
4.如權利要求3所述的調度呼叫建立方法，其中，進一步包括步驟在發送所述邀請消息的步驟之後，接收來自所述至少一個目標單元的至少一個響應。
5.如權利要求4所述的調度呼叫建立方法，其中，進一步包括步驟確定選擇的調度呼叫建立類型。
6.如權利要求5所述的調度呼叫建立方法，其中，如果所述選擇的調度呼叫建立類型是用於邀請消息的類型，則執行步驟發送呼叫開始消息；確定是否響應；如果來自所述至少一個目標單元的響應是足夠的，則完成所述調度呼叫；所述調度消息包括；忽略所述響應；結束所述呼叫；完成所述調度呼叫；發送承載業務；接收至少一個響應；和確定選擇的調度呼叫建立類型。
7.如權利要求5所述的調度呼叫建立方法，其中，如果所述選擇的調度呼叫建立類型是用於強制消息的類型，則進一步包括步驟向所述至少一個目標單元發送強制消息。
8.如權利要求7所述的調度呼叫建立方法，其中，在所述發送強制消息的步驟之後，進一步包括步驟確定所述始發單元是否關心所述至少一個目標單元是否參與強制調度呼叫；和如果所述始發單元不關心，則進一步包括步驟完成所述調度呼叫並發送承載業務。
9.如權利要求8所述的調度呼叫建立方法，其中，如果所述始發單元關心，則進一步包括步驟確定是否足夠數量的至少一個目標單元接受調度呼叫的強制類型；如果足夠數量接受，則進一步包括業務步驟；以及如果不足的數量接受，則進一步包括步驟結束所述調度呼叫。
10.一種用於始發單元和目標單元之間經通信網絡的調度呼叫的調度呼叫建立方法，該方法包括以下步驟由所述目標單元接收用於調度呼叫的邀請消息；確定所述目標單元的預置偏好；確定是否接受所述邀請消息；和如果接受所述邀請消息，則向所述始發單元發送接受消息。
11.如權利要求10所述的調度呼叫建立方法，其中，如果確定拒絕所述邀請消息，則進一步包括步驟向所述始發單元發送拒絕消息。
12.如權利要求10所述的調度呼叫建立方法，其中，如果所述預置偏好是用於用戶控制的，則進一步包括步驟由所述目標單元通知用戶呼入邀請調度呼叫。
13.如權利要求10所述的調度呼叫建立方法，其中，如果預置偏好是自動接受，則進一步包括步驟向始發單元發送接受響應消息；和接受承載業務。
14.如權利要求10所述的調度呼叫建立方法，其中，如果預置偏好是自動拒絕邀請消息，則進一步包括步驟由所述目標單元向所述始發單元發送拒絕消息；和禁止接受承載業務。
15.如權利要求14所述的調度呼叫建立方法，其中，在向所述始發單元發送響應消息的步驟之後，進一步包括步驟接受承載業務。
全文摘要
一種調度呼叫建立方法，選擇(101)強制調度呼叫(105)或邀請調度呼叫(103)。調度呼叫的始發單元(20)可以選擇任何一種。根據所要求的目標用戶(30，40)如何響應，始發終端能夠選擇來完成該呼叫(119)。終接單元可以接受、拒絕或轉換強制調度呼叫(127)。而且，目標可以建立其接受、拒絕或允許用戶控制邀請調度呼叫的預置偏好(139)。
文檔編號H04B1/26GK1751445SQ200480004614
公開日2006年3月22日 申請日期2004年2月11日 優先權日2003年2月19日
發明者馬克·L·肖內西, 彼得·J·安布魯斯特, 詹姆斯·P·克拉科拉, 布雷德利·R·謝弗, 威廉·肖爾斯 申請人:摩託羅拉公司