第三章、 研究方法
3.2. 系統設計
3.2.1. SIP 訊息交換
由於 Master 與 Slave 伺服器皆為獨立的 SIP 伺服器或代理伺服器，由於 Master 伺服器不具有傳輸 RTP 的能力，當 UA 建立會議時 Master 必須藉由 Slave 擔任 RTP 的傳輸的角色，因此 Master 與 Slave 之間必須共同完成會議的初始化，而 SIP 伺服器之間的訊息交換可分為由 SIP 伺服器轉送(Forward)與由 UA 傳送之重 新導向(Redirect)二種方式。
1. SIP Redirect
根據RFC 3261 [1] 規範中定義了重新導向的回覆碼(3XX)，透過SIP代理伺 服器當接收到邀請(INVITE)訊息時，回覆重新導向碼告知邀請者重新發送邀請訊 息的位址，如圖 20，UA分別註冊到不同的資料庫，透過重新導向的方式可將原 本發送到Master的邀請訊息，經由 3XX回覆碼告知邀請者重新發送請求的SIP伺 服器位址，透過Master伺服器的分配可將UA分散所規劃的Slave。然而並非所有 的SIP UA都支援重新導向能力，有些SIP硬體電話可能基於成本考量並未將所有 SIP規範中的功能實作於硬體電路，因此重新導向的方式對於SIP軟體電話的支援 性較高，但對於硬體電話相容性較低。
圖 20 SIP Redirect
2. SIP Forward
A. UA 位於不同資料庫
在SIP所定義的Via欄位中可記錄每個請求所經過的SIP節點資訊，因此 透過轉送(Forward)的方式可由Master決定轉送的Slave伺服器，從中分配 Slave的網路負擔。如圖 21當UA傳送邀請訊息時，Master會將本身節點的資
訊存入Via欄位中，UA或Slave伺服器可由Via欄位得知訊息回覆時的傳輸路 徑與順序，當Slave伺服器收到邀請訊息時會由本身的Location伺服器尋找受 邀者(640)資訊，然而當受邀者初始化完成後Master會回覆 200 OK訊息給邀 請者(642)，此時Master必須修改 200 OK中SDP的「c (Connect)」參數為Slave 伺服器的IP位址，邀請者將根據SDP資訊傳送RTP訊息到指定的IP位址。
圖 21 SIP Forward (UA 位於不同資料庫)
B. UA 位於相同資料庫
將 UA 分散註冊於不同資料庫會提高系統管理的複雜度，並且含有以下 缺點，第一 Master 必需負責尋找受邀者的位置，並隨著 Slave 伺服器增加影 響搜尋與會議初始化的時間，第二當 UA 位於不同 Slave 伺服器時，UA 所 傳送的邀請訊息並不能直接透過 Master 伺服器分配，使得 Master 與 Slave 必需同時擁有處理 UA 如何分散的規則，造成系統不易維護，因此將使用者 資訊交由 Master 伺服維護，並且由 Master 負責指派與分配 UA 的會議初始 化過程與 RTP 傳輸路徑，Slave 只需擔任服務的提供即可。
如圖 22當Slave接收到邀請訊息I(2)時，由於Slave伺服器本身並無儲存 UA資訊，因此透過I(3)將邀請訊息轉送回Master，由Master負責找尋受邀者 傳送位置，當Slave傳送I(3)訊息時將修改Contact、SDP 「c」與「m (Media)」
為Slave本身的IP位址與RTP連接埠，而Master在傳送 200 OK給邀請者時同樣 修改SDP資訊，使邀請者與受邀者將RTP傳送到Slave伺服器，而Slave從中提 供其它額外服務。
圖 22 SIP Forward (UA 位於相同資料庫)
3.2.2. Slave 伺服器群組 1.
單一 Slave 群組由圖 22 SIP轉送的方式可整合其它SIP伺服器擔任RTP訊息的轉送或其它額 外服務的支援，如圖 23將多個Slave伺服器集合成單一群組，Master利用轉送的 方式順序分配UA的SIP會議到群組中的每一個Slave伺服器，由Slave擔任UA在傳 送多媒體訊息時的中間角色，將UA所產生的網路流量分擔到群組中的每一個伺 服器達到分散的功能。
圖 23 單一群組架構
2.
多重服務群組Master 伺服器藉由下列所定義的 Slave 伺服器進行群組，每一類的群組由開 頭編號表示群組的代碼，群組中的伺服器可能為一個完整的 SIP 伺服器或以 SIP
提供某類的服務，Master 將根據所定義的號碼計劃或資料庫的設定而有所不同的 分配，例如 UA 位於防火牆或 NAT 後時使用第一個群組，群組中定義了三個不 同的伺服器，Master 會依序分配 UA 到這一群組並分散每一個伺服器的網路負 擔，其它提供額外服務之 Slave 可依據服務類型定義為同一群組，例如合法監聽、
語音信箱或整合 PSTN 服務等，每個使用相同類型的 UA 會經由 Master 的分配 而在定義相同類型服務的群組中依序指派。
# RTP load sharing
1 sip:s1.voip.nuk.edu.tw:5060 1 sip:s2.voip.nuk.edu.tw:5060 1 sip:s3.voip.nuk.edu.tw:5060
# PSTN Gateways
2 sip:gw.voip.nuk.edu.tw:5060 2 sip:192.168.1.42:5060
# Voice Mail
3 sip:vm1.voip.nuk.edu.tw:5070 3 sip:vm2.voip.nuk.edu.tw:5070
# Lawful Intercept
4 sip:li1.voip.nuk.edu.tw:5080 4 sip:li2.voip.nuk.edu.tw:5080
如圖 24由於Master透過SIP與Slave伺服器交換會議建立的訊息，因此Slave 可為SIP IP PBX擁有傳統電話交換機功能，提供如轉接分機、語音信箱等功能或 將Slave視為PSTN閘道器整合PSTN於系統中，或其它以SIP作為交換訊息的服 務，而經由Master所規劃之號碼計劃，系統可在某一服務群組內分散UA傳送RTP 訊息對伺服器所造成的網路負擔。
圖 24 多重服務群組架構
3.2.3. Master 路由規則虛擬程式碼(Route Rule Pseudo code)
由於每個 SIP 請求都會經由 Master 伺服器檢查與導向的動作，並依 UA 的 網路環境而不同，因此系統檢查的路由虛擬程式碼(Pseudo code)如下，檢查的過 程分為三個階段，首先系統會檢查 UA 在系統的資料庫中是否被設置為特殊的旗 標，或是 RURI(Request Uniform Resource Identifier)中是否指定特殊號碼，例如 GSM 業者設置 123 表示進入語言信箱等，當符合上述任何一項時，表示 UA 必