TW202410678A

TW202410678A - 高可用度多媒體閘道器系統、多媒體閘道器管理方法與電腦可讀媒體

Info

Publication number: TW202410678A
Application number: TW111131503A
Authority: TW
Inventors: 姜怡楷; 鄒應殿; 朱振宏; 黃超群
Original assignee: 中華電信股份有限公司
Filing date: 2022-08-22
Publication date: 2024-03-01

Abstract

一種高可用度多媒體閘道器系統、多媒體閘道器管理方法與電腦可讀媒體，係根據多媒體閘道器的資源使用情況動態啟動或關閉多媒體閘道器，以調節系統資源。此外，若有多媒體閘道器故障或資源不足時，令另一多媒體閘道器無縫接管其進行中的呼叫會談，以保障多媒體服務和通話服務的品質。

Description

高可用度多媒體閘道器系統、多媒體閘道器管理方法與電腦可讀媒體

本發明係關於一種高可用度多媒體閘道器系統、多媒體閘道器管理方法與電腦可讀媒體，係利用呼叫自動調配機制以處理存取相同語音內容的瞬時大量呼叫，提供高可用度通話品質，並藉由高效率的呼叫會談封包分析儲存技術，以及呼叫會談重建暨接管技術，可使得不同多媒體閘道器彼此間可以配合系統資源的配置，接管或取代原先的多媒體閘道器的呼叫會談，且能維持呼叫會談不中斷及提供穩定的語音準確內容，以保障用戶撥打存取即時語音內容之品質與最佳體驗。

目前常見的多媒體閘道器為實體設備，受限於硬體的限制，無法彈性的根據呼叫量自動擴增。呼叫量不大時，會浪費其系統資源，當瞬間呼叫量提高時，又怕系統資源無法應付，可能會導致用戶端無法獲取即時的語音內容。此外，當設備故障時，會因為切換線路，而造成用戶端的通話中斷。若是在進行重要的視訊會議時中斷，會造成與會者通話中斷，而造成不便。為了兼顧系統資源使用的最佳化，及高可用度的即時呼叫會談的需求，於是開始有提供按流量自動調適之高可用度的多媒體閘道器之技術提出。

然而，當前各種習用技術均無法在後端的會談發起協議(Session Initiation Protocol,SIP)伺服器動態地接管其他SIP伺服器的通話資訊，更無法將此呼叫會談的資料任意轉移到其他SIP伺服器。因此，當流量大的時候，只能透過預先配置好的SIP伺服器進行負載平衡；反之，當流量小的時候，也無法將預先配置好的SIP伺服器的資源移作他用，實非良善之設計，而亟待加以改良。

本發明之目的係針對上述習用技術之不足，提供一種高可用度多媒體閘道器系統與多媒體閘道器管理方法。該系統不需配置大量的實體設備，而是使用雲端運算和硬體虛擬化的軟體技術，配置多媒體閘道器。

本發明根據呼叫流量閥值，來啟動預先配置好的多媒體閘道器虛擬機，動態增加或關閉在線上服務的多媒體閘道器，或將僅有少量呼叫會談數的多媒體閘道器，透過產生初始呼叫會談的模擬封包，在其他多媒體閘道器進行會談重建以進行接管，亦可將此呼叫會談無縫地轉移或集中至同一台多媒體閘道器，以減少系統資源的耗費。

達成上述發明目的之該系統係包括多媒體訊號產生系統與高可用度多媒體閘道器系統。

上述多媒體訊號產生系統，在語音方面，可由國家時間與頻率標準實驗室提供報時音源，或由其他設備商或營運商提供即時語音廣播音源。可直接透過登記第9號接頭(Registered Jack-9,RJ9)、登記第11號接頭(Registered Jack- 11,RJ11)、登記第45號接頭(Registered Jack-45,RJ45)或尼爾-康塞曼(Bayonet Neill-Concelman,BNC)接頭，將其類比音源接入多媒體閘道器；在視訊影像方面，可由多媒體影像提供端提供即時影像，透過網路介面接入多媒體閘道器。該即時影像可以是政府的宣導政策影片，也可以是企業提供的廣告影片。

上述高可用度多媒體閘道器系統，可接受多媒體系統產生的類比音源，透過進階Linux聲音體系(Advanced Linux Sound Architecture,ALSA)為音效卡提供驅動組件，以處理系統中的聲音裝置，也可接受多媒體系統產生的影像。其以訊號交換核心的SIP/即時傳輸協議(Real-time Transport Protocol,RTP)對外接收來自SIP應用伺服器的呼叫，且對內統整以下功能模組：

高可用性分配模組，用於接收外部SIP應用伺服器的會談封包，並分配其呼叫會談封包的訊務流。

訊務分析處理模組，用於存放呼叫會談重建時所需要的封包欄位資訊，以及接收管理監控模組轄下所有的多媒體閘道器的資源使用統計，以將該資訊通知高可用性分配模組。

管理監控模組，用於管轄所有的多媒體閘道器的系統資源，及動態地調適多媒體閘道器的機器數。

訊務重組模組，用於提供重建會談所需的封包。

資料庫，用於在呼叫會談過程中記錄封包資訊，以及提供重建會談所需要的封包資訊欄位。

多媒體閘道器，用於將類比音源，透過快速周邊組件互連標準(Peripheral Component Interconnect Express,PCI-E)的音效卡，轉換成數位音源，也可接受影像擷取卡的影像以及網路影音影像，並具有SIP/RTP協議與訊務復原功能。

達成上述發明目的之該多媒體閘道器管理方法包括呼叫會談記錄與接管設置流程、會談重建衝突設置流程、非次序性會談重建設置流程、以及多媒體閘道器自動調適高可用度不斷話設置流程。

呼叫會談記錄與接管設置流程：用戶端開始進行呼叫，記錄呼叫會談期間的訊務封包並進行分析與處理，其中，當其多媒體閘道器故障時，藉由啟動第2台多媒體閘道器以接管第1台多媒體閘道器的呼叫會談，用戶端可維持原呼叫狀態，即完成通話不中斷的接管設置。

會談重建衝突設置流程：因多媒體閘道器配置的網路環境不盡相同，在會談重建過程中，個別的會談通話可能使用到相同的資源而發生衝突，此流程包含其資源衝突修正的設置方式。

非次序性會談重建設置流程：其不需依照原始呼叫會談順序，透過封包重組的機制亦可反向重建呼叫會談。

多媒體閘道器自動調適高可用度不斷話設置流程：多媒體閘道器根據目前呼叫會談封包的訊務流，在進行系統資源的配置時，可無縫接管原始多媒體閘道器的呼叫會談，使用戶端能維持呼叫會談不中斷，並提供穩定的語音及影像準確內容，以保障用戶撥打存取即時多媒體內容。

於另一方面，本發明提供一種高可用度多媒體閘道器系統，包括：複數多媒體閘道器，用於提供會談發起協議(SIP)呼叫會談功能；高可用性分配模組，用於在用戶端發起呼叫會談時，將該呼叫會談分配至該等多媒體閘道器中之第一多媒體閘道器；訊務分析處理模組，用於自該呼叫會談之訊務封包擷取該呼叫會談之建立資訊，以儲存該建立資訊；管理監控模組，用於在該呼叫會談期間，監測該第一多媒體閘道器之活動有無異常，以在該第一多媒體閘道器之活動有異常時，令該等多媒體閘道器中之第二多媒體閘道器接管該呼叫會談；以及訊務重組模組，用於根據該建立資訊，產生該呼叫會談之複數會談重建封包，以供該第二多媒體閘道器在接管該呼叫會談時，重建該呼叫會談之狀態。

在一實施例中，該管理監控模組復用於監測並提供該等多媒體閘道器之資源使用情況，而該高可用性分配模組係根據該資源使用情況將該呼叫會談分配至該第一多媒體閘道器。

在一實施例中，若該第一多媒體閘道器之資源已不足以處理該呼叫會談，或該第一多媒體閘道器發生故障，則該管理監控模組判斷該第一多媒體閘道器之活動有異常。

在一實施例中，該管理監控模組復用於根據該等多媒體閘道器之資源使用情況，啟動或關閉該等多媒體閘道器中之至少一者，以調節該等多媒體閘道器之資源量。

在一實施例中，該呼叫會談之該建立資訊包括該呼叫會談之主叫端與被叫端的入腳(ingress)與出腳(egress)之SIP INVITE封包、SIP 200 OK封包與SIP ACK封包的SIP欄位與會談描述協議(Session Description Protocol,SDP)欄位，以及該主叫端與該被叫端之該入腳與該出腳之間的成對關係。

在一實施例中，該呼叫會談之該建立資訊復包括SIP INVITE封包與SIP 200 OK封包之間互相轉變形式儲存之封包，以根據該等互相轉變形式儲存之封包，該第二多媒體閘道器在重建該呼叫會談之該狀態時，不需依照該呼叫會談之原始封包順序。

在一實施例中，該第二多媒體閘道器係模擬該等會談重建封包之發送與接收，以重建該呼叫會談之該狀態。

在一實施例中，該訊務重組模組復用於在該第二多媒體閘道器接管該呼叫會談時，檢查該第一多媒體閘道器分配給該呼叫會談之通訊埠是否已被該第二多媒體閘道器佔用，其中，若該通訊埠已被該第二多媒體閘道器佔用，則該訊務重組模組分配未被該第二多媒體閘道器佔用之新通訊埠給被接管後之該呼叫會談。

於又一方面，本發明提供一種多媒體閘道器管理方法，包括：在用戶端發起會談發起協議之呼叫會談時，將該呼叫會談分配至複數多媒體閘道器中之第一多媒體閘道器；自該呼叫會談之訊務封包擷取該呼叫會談之建立資訊，以儲存該建立資訊；在該呼叫會談之期間，監測該第一多媒體閘道器之活動有無異常，其中，在該第一多媒體閘道器之活動有異常時，令該等多媒體閘道器中之第二多媒體閘道器接管該呼叫會談；以及根據該建立資訊，產生該呼叫會談之複數會談重建封包，以供該第二多媒體閘道器在接管該呼叫會談時，重建該呼叫會談之狀態。

於再一方面，本發明提供一種電腦可讀媒體，應用於多媒體閘道器系統中，係儲存有指令，以執行上述之多媒體閘道器管理方法。

110:多媒體訊號產生系統

120:SIP應用伺服器

130:SIP話機

140:數位音源接收機

150:POTS話機

160:行動話機

170:類比音源接收機

200:高可用度多媒體閘道器系統

210~212:多媒體閘道器

220~222:媒體用戶代理端

230~232:訊務復原處理器

240:管理監控模組

250:訊務重組模組

260:資料庫

270:高可用性分配模組

280:訊務分析處理模組

301~319,410~450,510~560,610~650,710~780:流程步驟

圖1為本發明之高可用度多媒體閘道器系統與多媒體閘道器管理方法的多媒體閘道器與外部終端之介接示意圖。

圖2為本發明之高可用度多媒體閘道器系統的架構圖。

圖3為本發明之呼叫會談接管的封包訊務流程圖。

圖4為本發明之多媒體閘道器管理方法的呼叫會談記錄與接管設置流程圖。

圖5為本發明之多媒體閘道器管理方法的會談重建衝突設置流程圖。

圖6為本發明之多媒體閘道器管理方法的非次序性會談重建設置流程圖。

圖7為本發明之多媒體閘道器管理方法的多媒體閘道器自動調適高可用度不斷話設置流程圖。

請參閱圖1，其為本發明之按流量自動調適高可用度多媒體閘道器的介接示意圖。本發明之高可用度多媒體閘道器系統與多媒體閘道器管理方法包含多媒體訊號產生系統110及藉由用戶呼叫以存取即時語音影像的高可用度多媒體閘道器系統200，用戶端透過SIP/RTP等協議即可使用呼叫撥號以接取高可用度的即時多媒體內容。

在一實施例中，多媒體訊號產生系統110透過RJ11、RJ45或BNC等介面連接到高可用度多媒體閘道器系統200，以提供多媒體內容，俾使普通老式電話服務(plain old telephone service,POTS)話機150等用戶端透過SIP/RTP等協議即可使用呼叫撥號方式通過SIP應用伺服器120與高可用度多媒體閘道器系統200接取高可用度的即時多媒體內容。

SIP應用伺服器120負責轉送SIP訊號以提供進階服務，例如三方通話服務。高可用度多媒體閘道器系統200之用戶端可包含SIP話機130、數位音源接收機140、POTS話機150、行動話機160及類比音源接收機170。類比音源接收機170及數位音源接收機140可接收並處理多媒體音源，也包含校時服務。其他一般終端亦可透過呼叫方式接取多媒體內容。

請參閱圖2，其為本發明之高可用度多媒體閘道器系統200之架構圖。高可用度多媒體閘道器系統200包含多媒體閘道器210~212、管理監控模組240、訊務重組模組250、資料庫260、高可用性分配模組270、以及訊務分析處理模組280。要說明的是，圖2中之多媒體閘道器210~212僅為示範說明，在另一實施例中，高可用度多媒體閘道器系統200可包含任意數量的複數多媒體閘道器。

每台多媒體閘道器210~212包含媒體用戶代理端220~222及訊務復原處理器230~232。多媒體閘道器210~212通訊連接多媒體訊號產生系統110、管理監控模組240、訊務重組模組250及高可用性分配模組270。管理監控模組240通訊連接多媒體閘道器210~212及訊務分析處理模組280。訊務重組模組250通訊連接多媒體閘道器210~212的訊務復原處理器230~232及資料庫260。資料庫260通訊連接訊務重組模組250及訊務分析處理模組280。高可用性分配模組270通訊連接多媒體閘道器210~212、訊務分析處理模組280及SIP應用伺服器120。訊務分析處理模組280通訊連接管理監控模組240、資料庫260及高可用性分配模組270。

在一實施例中，多媒體閘道器210~212、管理監控模組240、訊務重組模組250、資料庫260、高可用性分配模組270、以及訊務分析處理模組280均可為單獨一台實體設備，亦可為VMware、KVM、Xen、MiscroSoft Hyper-V等虛擬化技術之虛擬機(virtual machine)，亦可為容器化技術如Docker等之容器(container)。

多媒體閘道器210~212用於將多媒體訊號產生系統110產生的類比訊號轉換成RTP協議數位訊號，以方便在網際網路上進行多媒體訊號傳輸。多媒體閘道器210~212具備小型SIP服務功能，且包含媒體用戶代理端220~221做為SIP服務端，以提供多媒體內容接取服務。另外，多媒體閘道器210~212可做為SIP伺服器，以提供用戶端之間的通話功能。多媒體閘道器210~212亦包含訊務復原處理器230~232。

當多媒體閘道器210~212發生異常、關閉或進行接管服務時，除負責重建SIP/RTP訊號外，另須發送異動多媒體閘道器的更新訊務通知用戶端，以避免通話中斷的情況。另外，可在兩台多媒體閘道器皆正常起動的情況下，由其中一台多媒體閘道器接管另一台多媒體閘道器的呼叫會談，例如，可在多媒體閘道器210及多媒體閘道器211皆正常起動的情況下，由多媒體閘道器211接管多媒體閘道器210的呼叫會談。

在一實施例中，呼叫會談發生於主叫端與被叫端之間，其中，主叫端與被叫端中之一者可為多媒體閘道器的媒體用戶代理端，且主叫端與被叫端中之另一者可為用戶端。或者，主叫端與被叫端可分別為不同之用戶端。

管理監控模組240用於管理各台多媒體閘道器210~212的啟動與關閉。管理監控模組240可接收訊務分析處理模組280的流量分析，若流量屬於尖峰用量時，管理監控模組240會自動啟動更多台多媒體閘道器210~212以進行負載平衡；若流量為離峰用量時，管理監控模組240會通知部分多媒體閘道器(例如多媒體閘道器211~212)進行關機，並通知欲接管的多媒體閘道器(例如多媒體閘道器210)啟用其訊務復原處理器230，以接管即將關閉的多媒體閘道器211~212的呼叫會談，讓用戶端的通話能持續進行，不會因為關閉多媒體閘道器211~212而造成通話中斷。

此外，管理監控模組240會監測各台多媒體閘道器210~212的資源使用情況，並將該資源使用情況通過訊務分析處理模組280告知高可用性分配模組270。上述資源包括多媒體閘道器的中央處理器(central processing unit,CPU)的運算時間、記憶體的儲存空間、以及網路I/O資源(例如通訊埠)。

訊務重組模組250接收到訊務復原處理器230的請求後，可將儲存在資料庫260的原先呼叫會談的封包交換內容中，被接管的多媒體閘道器211~212的網際網路協議(Internet Protocol,IP)位址及通訊埠(port)更換成接管的多媒體閘道器210的IP位址與通訊埠。若被接管的多媒體閘道器的通訊埠與接管的多媒體閘道器210的通訊埠衝突，則會更改SDP的通訊埠，並藉由SIP的再邀請(reINVITE)封包或更新(UPDATE)封包通知用戶端，以達成接管的功能。

資料庫260針對呼叫會談存放著兩種資料欄位，分別是呼叫關聯欄位遠端標籤(remote tag)及本地標籤(local tag)與關聯欄位個別之封包訊息。詳言之，每一個呼叫會談的主叫端與被叫端所發送的封包都會經過高可用度多媒體閘道器系統200中的一個多媒體閘道器，以多媒體閘道器的角度來看，主叫端與被叫端各有兩個會談腳，即入腳(ingress)與出腳(egress)，入腳與出腳對應上述之遠端標籤與本地標籤。

請參考圖3的步驟301、302及304~307，在開始呼叫會談時，主叫端會先發送邀請(INVITE)封包給被叫端，被叫端會回覆接受(200 OK)封包給主叫端，然後主叫端會發送確認(ACK)封包給被叫端，這些封包都會由居中的多媒體閘道器轉送。因此，主叫端的入腳包括上述的INVITE封包與ACK封包，主叫端的出腳包括上述的200 OK封包，被叫端的入腳包括上述的200 OK封包，被叫端的出腳包括上述的INVITE封包與ACK封包。

資料庫260儲存有主叫端與被叫端的入腳封包與出腳封包中的由第3261號評論請求(RFC 3261)所定義的SIP欄位以及由第4566號評論請求(RFC 4566)所定義之SDP欄位，上述SIP欄位包括Via、From、To、Contact、Call-ID及CSeq等欄位，上述SDP欄位則包括協議版本、會談名稱、RTP傳輸名稱和傳輸IP位置資訊、RTP/即時傳輸控制協議(Real-time Transport Control Protocol,RTCP)通訊埠、通話屬性、雙方通話編碼方式等欄位。另外，資料庫260亦儲存有同一呼叫會談的主叫端與被叫端的入腳與出腳之間的成對關係。上述的主叫端與被叫端的入腳與出腳的各封包的SIP欄位與SDP欄位，以及主叫端與被叫端的會談腳之間的成對關係，可合稱為呼叫會談的建立資訊。

高可用性分配模組270會通過訊務分析處理模組280收到來自管理監控模組240的各台多媒體閘道器的資源使用情況。當高可用性分配模組270通過SIP應用伺服器120收到來自用戶端的封包，會根據該資源使用情況決定將該封包傳送到多媒體閘道器210~212中資源使用較少或最少的多媒體閘道器，以提供負載平衡功能。此外，用戶端與多媒體閘道器210~212的媒體用戶代理端220~222之間的呼叫會談封包，以及用戶端之間的呼叫會談封包，都會通過高可用性分配模組270，高可用性分配模組270會將這些呼叫會談封包中的SIP RFC 3261所定義的邀請(INVITE)、再邀請(reINVITE)、更新(UPDATE)、確認(ACK)、接受(200 OK)、選項(OPTIONS)及訊息(INFO)等封包複製一份傳送至訊務分析處理模組280。

訊務分析處理模組280用於接收來自高可用性分配模組270的封包訊息，並將封包依據遠端標籤及本地標籤進行簡化處理後存放至資料庫260，也就是將每個呼叫會談的建立資訊存入資料庫260，以供多媒體閘道器210進行訊務復原處理器230的通話復原切換機制。另一方面，因為訊務分析處理模組280記錄著個別多媒體閘道器210~212的負載量，當負載需求有變動的時候，會通知管理監控模組240啟動更多多媒體閘道器以增加系統資源，或關閉某些多媒體閘道器以縮減系統資源，如此可以自動化地彈性調適系統資源。

以下詳述本發明之各種方法流程，其中，邀請(INVITE)、再邀請(reINVITE)、更新(UPDATE)、嘗試中(Trying)、響鈴(Ringing)、確認(ACK)與接受(200 OK)等封包，以及出現於下文中之其他各種封包，均為SIP的RFC 3261所定義之封包。

請參閱圖3，其為呼叫會談接管之封包訊務流程圖，其中，以多媒體閘道器211接管多媒體閘道器210的呼叫會談為例說明。多媒體閘道器210的媒體用戶代理端與多媒體閘道器211的媒體用戶代理端都是能透過多媒體訊號產生系統110提供同一多媒體內容的接取服務的SIP服務端。以下說明圖3流程的各步驟，其中，INVITE/SDP及200 OK/SDP等SIP通話封包後綴的「/SDP」係強調該等封包均包含前述之SDP欄位。

在步驟301，用戶端發送INVITE/SDP封包至多媒體閘道器210。多媒體閘道器210在步驟302轉送該INVITE/SDP封包至其媒體用戶代理端前，會在步驟303發送100 Trying封包告知用戶端目前正在轉送該INVITE/SDP封包。因為採用自動接聽的方式，在此並無180 Ringing封包產生。

在步驟304，由多媒體閘道器210之媒體用戶代理端直接回傳200 OK/SDP封包。在步驟305，多媒體閘道器210轉送該200 OK/SDP封包至用戶端。在步驟306，用戶端回送ACK封包至多媒體閘道器210。在步驟307，多媒體閘道器210轉送該ACK封包至其媒體用戶代理端，至此已經完成建立通話關係。

此時，可在多媒體閘道器210關機或開機的情況下，由多媒體閘道器211進行接管步驟，並重建此呼叫會談。由於在多媒體閘道器210下，雙方的封包訊息交換內容在處理後皆存放至資料庫260，故多媒體閘道器211可使用其訊務復原處理器231將資料庫260中的封包訊息進行重組。接著，多媒體閘道器211準備進行接管，會在步驟308、311及312以模擬封包的狀況復原多媒體閘道器210的呼叫會談，以避免用戶端接收到還原的訊號而影響後續的用戶端行為。以下詳述後續流程。

首先在步驟308，多媒體閘道器211模擬接收來自用戶端的INVITE/SDP封包(其內容雷同步驟301中之INVITE/SDP封包)。在步驟309，多媒體閘道器211轉送該INVITE/SDP封包(其內容雷同步驟302中之INVITE/SDP封包)至其媒體用戶代理端。接著在步驟310，多媒體閘道器211接收其媒體用戶代理端回送之200 OK/SDP封包。在步驟311，多媒體閘道器211模擬轉送該200 OK/SDP封包(其內容雷同步驟305中之200 OK/SDP封包)至用戶端。在步驟312，多媒體閘道器211模擬接收用戶端回送之ACK封包(其內容雷同步驟306中之ACK封包)。在步驟313，多媒體閘道器211轉送該ACK封包(其內容雷同步驟307中之ACK封包)至其媒體用戶代理端。此時，多媒體閘道器210與多媒體閘道器211皆有該呼叫會談的資訊。

步驟308、311與312之模擬轉送與模擬接收僅為多媒體閘道器211內部之模擬，其實與用戶端之間沒有真實的封包傳遞，這是為了使多媒體閘道器211以不影響用戶端的方式重建呼叫會談最初的狀態。因為此時用戶端正在通過多媒體閘道器210進行通話，所以不會再發送INVITE/SDP封包與ACK封包，也不會預期再收到200 OK/SDP封包，故多媒體閘道器211僅能模擬封包之轉送與接收。否則，在步驟311，若多媒體閘道器211真實地轉送步驟310的200 OK/SDP封包至客戶端，則客戶端會發送錯誤訊息，甚至可能令進行中的通話中斷。

接著，為完成接管手續，多媒體閘道器211分別在步驟314及315發送reINVITE/SDP(或UPDATE/SDP)封包以通知用戶端和多媒體閘道器211的媒體用戶代理端。然後，多媒體閘道器211依照SIP RFC 3261的規範，分別在步驟316及317接收並處理用戶端及多媒體閘道器211的媒體用戶代理端回送的200 OK/SDP封包，且分別在步驟318及319以ACK封包回應用戶端及多媒體閘道器211的媒體用戶代理端。

此外，在此說明由管理監控模組240、訊務重組模組250、多媒體閘道器、以及多媒體閘道器的訊務復原處理器共同執行的呼叫會談接管流程。

首先，管理監控模組240會隨時監看轄下的多媒體閘道器的資源是否有過剩的情況，並通知資源過剩的多媒體閘道器關閉。若資源過剩的多媒體閘道器目前還有呼叫會談進行中，這些正在進行的呼叫會談在貿然關閉的情況下，會造成用戶的通話中斷。因此，由管理監控模組240告知另一多媒體閘道器(以下稱為接管者多媒體閘道器)啟動其訊務復原處理器。訊務重組模組250自資料庫260取得資源過剩的多媒體閘道器(以下稱為被接管多媒體閘道器)的呼叫會談建立資訊。訊務重組模組250會將該呼叫會談建立資訊重新組合成分屬入腳與出腳的INVITE、200 OK與ACK等三個會談重建封包(圖3中步驟308、311及312即使用這樣的會談重建封包)。由於接管者多媒體閘道器與被接管多媒體閘道器的IP位址不同，在重組會談重建封包時，訊務重組模組250會將這些封包中的被接管多媒體閘道器的IP位址更新為接管者多媒體閘道器的IP位址。然後，接管者多媒體閘道器的訊務復原處理器使用前述會談重建封包，以模擬方式，在接管者多媒體閘道器重建與被接管多媒體閘道器相同的呼叫會談建立資訊。此時，用戶端並不知道要跟接管者多媒體閘道器進行通話，因為多媒體串流還是在被接管多媒體閘道器這一邊，因此會由接管者多媒體閘道器發送真實的reINVITE/SDP或UPDATE/SDP封包告知用戶端，請用戶端跟接管者多媒體閘道器進行多媒體串流，在此，reINVITE或UPDATE封包的SDP欄位必須包含接管者多媒體閘道器的IP位址，以便用戶端切換多媒體串流至接管者多媒體閘道器。

請參閱圖4，其為本發明之多媒體閘道器管理方法的呼叫會談記錄與接管設置流程圖。在呼叫會談的過程中，當第1台多媒體閘道器發生異常時，可啟動第2台多媒體閘道器進行會談重建並以通話不中斷的方式進行接管，其步驟詳述如下。

在步驟410，用戶端開始進行呼叫會談，在建立呼叫會談的過程中，訊務分析處理模組280將所有的訊務封包進行分析處理並存放至資料庫260。

在步驟420，由管理監控模組240根據目前的呼叫流量及多媒體閘道器可負擔的範圍進行資源監測。若多媒體閘道器運行正常，則返回步驟410持續接收新的呼叫。若觀察到正在進行呼叫會談的多媒體閘道器因資源不足而出現異常，則進入步驟430。

上述資源包括多媒體閘道器的CPU運算時間、記憶體的儲存空間、以及網路I/O資源(例如通訊埠)，其中，網路I/O資源不足將導致無法正常處理進線呼叫，CPU運算及記憶體資源耗盡會因為無運算資源進行聲音編碼處理而導致聲音斷斷續續，影響通話品質。管理監控模組240可監測各多媒體閘道器的資源使用情況，以判斷各多媒體閘道器是否具有充足資源以處理目前進行中的呼叫會談。

在步驟430，由管理監控模組240進行資源的分配，即新增啟動第2台多媒體閘道器，並復原呼叫會談狀態，其經由訊務重組模組250復原步驟410存放在資料庫260中的呼叫會談訊務。

在步驟440，第2台多媒體伺服器會在圖3流程最後發送reINVITE/SDP或UPDATE/SDP封包至用戶端與第2台多媒體閘道器之媒體用戶代理端，以完成接管。

在步驟450，第1台多媒體閘道器之呼叫會談已被第2台多媒體閘道器接管，故第1台多媒體閘道器可釋放該呼叫會談的資源並清除該呼叫會談的資料。

請參閱圖5，其為本發明之多媒體閘道器管理方法的會談重建衝突設置流程圖。由於每一台多媒體閘道器都有其各自獨立建立的呼叫會談，也可能會使用到相同的RTP/RTCP通訊埠，為解決重建呼叫會談時，接管的多媒體閘道器使用到相同RTP/RTCP通訊埠的問題，其設置的步驟如下。

在步驟510，會談進行中，第1台多媒體閘道器與第2台多媒體閘道器皆使用相同的RTP/RTCP通訊埠讓用戶端與多媒體閘道器的媒體用戶代理端進行呼叫會談。一般情況下，RTP使用偶數的通訊埠，RTCP則使用RTP的下一個埠號，或使用RTP的下一個通訊埠，例如，RTP使用的通訊埠號為20000埠號，RTCP使用的通訊埠號則為20001埠號。

在步驟520，第2台多媒體閘道器準備接管第1台多媒體閘道器的呼叫會談，並復原第1台多媒體閘道器的會談資訊。

在步驟540，復原呼叫會談的SDP資訊時，訊務重組模組250檢查第2台多媒體閘道器是否已佔用新接管的第1台多媒體閘道器的呼叫會談所使用的RTP/RTCP通訊埠。若訊務重組模組250發現該RTP/RTCP通訊埠已被第2台多媒體閘道器佔用，則進入步驟530；若否，則進入步驟560。

在步驟530，訊務重組模組250分配新通訊埠，以供第2台多媒體閘道器新接管的呼叫會談使用，該新通訊埠與第2台多媒體閘道器既有的呼叫會談不會有衝突。

在步驟550，第2台多媒體閘道器發送更新SDP資訊(即SDP欄位)後的reINVITE或UPDATE封包，以分別通知用戶端及第2台多媒體閘道器的媒體用戶代理端將呼叫會談切換至第2台多媒體閘道器的該新通訊埠。該reINVITE或UPDATE封包的SDP欄位中包含第2台多媒體閘道器的IP位址和該新通訊埠的埠號。最後完成通話不中斷接管流程。

在步驟560，若新接管的呼叫會談所使用的RTP/RTCP通訊埠未被佔用，則循正常機制，第2台多媒體閘道器發送reINVITE或UPDATE封包以分別通知用戶端及第2台多媒體閘道器的媒體用戶代理端將呼叫會談切換至第2台多媒體閘道器。該reINVITE或UPDATE封包的SDP欄位中包含第2台多媒體閘道器的IP位址。最後完成通話不中斷接管流程。

請參閱圖6，其為本發明之多媒體閘道器管理方法的非次序性呼叫會談重建設置流程圖，其主要在復原重建會談封包訊息時，可不用按照原始封包的順序依序重組，除了可增加通話重建的效率，也可以減少網路傳輸的封包，其步驟如下。

在步驟610，高可用性分配模組270開始接收呼叫會談的封包訊務，一個完整可復原的呼叫會談主要有INVITE、200 OK、ACK等三個封包，100 Trying封包或者180 Ringing封包可以忽略，不用特別去處理，會談進度(183 Session Progress)封包攜帶有SDP資訊，則需保留其SDP內容。

在步驟630，訊務分析處理模組280判斷是否收到告別(BYE)封包；若收到BYE封包，則進入步驟620，若沒收到BYE封包，則進入步驟640。

在步驟620，訊務分析處理模組280根據呼叫會談的遠端標籤及本地標籤的資訊，刪除資料庫260中的該呼叫會談的相關資料以及成對關連資訊，完成後流程結束。

在步驟640，訊務重組模組250進行非次序性封包處理。由於進行復原重建會談時，是根據遠端標籤與本地標籤進行重建，但有可能最初建立會談是由用戶端發起INVITE封包，在重建時，可能由多媒體閘道器之媒體用戶代理端模擬發起INVITE封包，因此，由用戶端收到之INVITE封包，除了將該INVITE封包存成INVITE資訊外，也可以200 OK形式儲存；相對地，由多媒體閘道器媒體之用戶代理端回應的200 OK封包，除了可存成200 OK的封包資訊外，亦可當成INVITE封包來儲存。

在步驟650，訊務重組模組250將每次呼叫的用於重建會談的本地標籤的INVITE封包、200 OK封包與遠端標籤的INVITE封包、200 OK封包存放在資料庫260。然後，完成非次序性封包復原設置。

例如，進行呼叫會談重建時，若採用次序性重建，則需要從主叫端的入腳發起模擬INVITE封包給被叫端，才能正常重建。若要採用非次序性重建，從被叫端發起模擬INVITE封包，則會發現無法從被叫端的入腳開始發送模擬INVITE封包給主叫端，而僅能從被叫端的出腳開始發送模擬。對此，可採用步驟640的雙重形式封包儲存。依此儲存方式，主叫端的入腳與被叫端的出腳不僅包括INVITE封包與ACK封包，還包括根據INVITE封包轉變形式儲存的200 OK封包，且主叫端的出腳與被叫端的入腳不僅包括200 OK封包，還包括根據200 OK封包轉變形式儲存的INVITE封包與ACK封包。

藉此，除了依照原始封包順序從主叫端的入腳發起模擬INVITE封包給被叫端，以進行重建會談外，亦可從主叫端的出腳發起模擬，或從被叫端發起模擬INVITE封包，無論從被叫端的入腳或出腳發起模擬，皆可進行重建。

又例如，若主叫端發起呼叫至被叫端，資料庫260中的封包記錄會從主叫端的入腳出腳一路記錄至被叫端的出腳入腳。若採用次序性還原，則需要從主叫端的入腳出腳按照記錄的順序還原到被叫端的出腳入腳。若採用非次序性還原，則不需依照該順序即可還原。

詳言之，有下列多種方式可重建主叫端與被叫端的會談腳(入腳/出腳)：(1)依記錄順序重建主叫端的入腳，再重建其出腳，接著重建被叫端的出腳，再重建其入腳；(2)依記錄順序重建被叫端的出腳，再重建其入腳，接著重建主叫端的入腳，再重建其出腳(以上兩種方式等同，都是同方向)；(3)非順序性先重建主叫端的入腳，再重建其出腳，接著重建被叫端的入腳，再重建其出腳；(4)非順序性先重建被叫端的入腳，再重建其出腳，接著重建主叫端的入腳，再重建其出腳(以上兩種方式等同，都是同方向)；(5)非順序性先重建主叫端的出腳，再重建其入腳，接著重建被叫端的出腳，再重建其入腳；(6)非順序性先重建被叫端的出腳，再重建其入腳，接著重建主叫端的出腳，再重建其入腳(以上兩種方式等同，都是同方向)；(7)非順序性先重建主叫端的出腳，再重建其入腳，接著重建被叫端的入腳，再重建其出腳；(8)非順序性先重建被叫端的入腳，再重建其出腳，接著重建主叫端的出腳，再重建其入腳(以上兩種方式等同，都是同方向)。非次序性重建的優點是，不需要以整個呼叫會談的觀點依序重建，而是能以多媒體閘道器的角度個別重建主叫端或被叫端的呼叫會談，可以不按照原始封包的順序依序重組，藉此，除了可增加通話重建的效率，因為將所有複雜的封包都簡化成INVITE/SDP、200 OK/SDP及ACK三個封包，也可以減少網路傳輸的封包。

請參閱圖7，其為本發明之多媒體閘道器管理方法的多媒體閘道器自動調適高可用度不斷話設置流程圖，其可根據現有的系統資源及訊務流量，主動新增或減少多媒體閘道器的系統資源，以達成系統資源最佳化，其步驟如下。

在步驟710，管理監控模組240定期監測所有多媒體閘道器的資源使用情形。

在步驟720，管理監控模組240偵測多媒體閘道器的活動是否有異常；若檢查多媒體閘道器為系統故障導致異常或系統資源使用狀態異常，則進入步驟740；若沒有異常，則進入步驟730。

上述系統資源可包括多媒體閘道器的CPU運算時間、記憶體儲存空間、以及網路I/O資源(例如通訊埠)。管理監控模組240可監測轄下所有多媒體閘道器的系統資源是否因為呼叫會談數量過多而不敷使用，並透過SIP查詢方式檢查所有多媒體閘道器是否正常回覆訊息。若有多媒體閘道器的資源不敷使用，或未回覆SIP查詢，則管理監控模組240判斷該多媒體閘道器的活動有異常。

在步驟740，管理監控模組240啟動新的多媒體閘道器，準備接管異常的多媒體閘道器的呼叫會談。

在步驟760，異常的多媒體閘道器或被管理監控模組240要求關閉的多媒體閘道器檢查該多媒體閘道器自身是否有正在進行的呼叫會談需要被新啟動的多媒體閘道器接管；若有需要接管之呼叫會談，則流程進入步驟770；若無，則流程進入步驟780。

在步驟770，新啟動的多媒體閘道器的訊務復原處理器進行通話非次序性呼叫會談重建設置流程，且通知被接管的多媒體閘道器可以關機以減少資源浪費；完成後，進入步驟780。

在步驟730，管理監控模組240判斷是否需要減少系統資源。若多媒體閘道器均正常且正在進行的呼叫會談數量不多，則需減少系統資源，流程進入步驟750；否則，進入步驟780。

在步驟750，管理監控模組240可關閉多餘的多媒體閘道器，例如，管理監控模組240可令呼叫會談數量最低的多媒體閘道器關機以釋放資源。然後，流程進入步驟760。

在步驟780，多媒體閘道器等待用戶主動結束通話，然後即可釋放呼叫會談資源，結束此流程。

本發明另提供一種電腦可讀媒體，例如集中或分散之記憶體、軟碟、硬碟或光碟。該電腦可讀媒體應用於多媒體閘道器系統中，係儲存有指令，以執行上述之多媒體閘道器管理方法。

本發明之技術方案與其他習用技術相互比較時，更具備下列優點：

本發明具有自動調適資源的技術，不須佈建大量的多媒體閘道器，即能應付短時間的尖峰用量，以免在離峰用量時，造成機器資源的浪費，也可有效地降低後端維運的人力，以及減少機器設備的成本。

本發明提供通話SIP封包分析技術，針對每次發起的同一SIP會談的封包進行整合並保存至資料庫，用以提供服務重啟或切換其他多媒體閘道器時的不斷話功能，可無縫接續通話，提升用戶體驗。

本發明提供通話SIP封包非次序性復原重建分析技術，若用戶端有經過複雜的呼叫情境，比如三方通話，可以不用遵照主叫端、被叫端發起的順序，也可以直接模擬從被叫端發起INVITE封包以重建會談內容，且能更快速且更正確地重建會談，並以模擬封包的形式進行重建，不會影響現有用戶端的呼叫狀態。

本發明提供呼叫會談的接管技術，可同時在兩台多媒體閘道器都啟動的情況下，可用其中一台多媒體閘道器接管另一台多媒體閘道器的呼叫會談，達成呼叫會談不中斷的轉移功能。

綜上所述，本發明不僅於技術思想上確屬創新，並具備習用之傳統方法所不及之上述多項功效，已充分符合新穎性與進步性之法定發明專利要件，爰依法提出申請，懇請貴局核准本件發明專利申請案，以勵發明，至感德便。