目錄
1，Iovzprovide簡介
2，Iovzprovide設計思路
2.1，總體
2.2，多級門戶
2.3，面向提供商
2.3，安全
3，Iovzprovide實驗
3.1關于ip配置
3.2關于呼叫
3.3關于門戶
4，經驗感受
1，Iovzprovide簡介
IvozProvider是面向 公共網絡的，面向提供商的多級 IP電話解決方案 。
IvozProvider使用知名且穩定的免費軟體項目來完成平台的不同任務，包括下圖的所有開源工程。
- Debian是ivozprovide的運作作業系統
- Kamailio負責實作sip代理、sip中繼
- Asterisk負責實作as
- Mysql負責資料庫支援
- Homer sip capture負責sip流量、通話品質測量
- Rtp proxy、Rtpengine負責媒體處理
- Graylog view負責日志部分
- Apache負責網站部分
2，Iovzprovide設計思路
2.1，總體
設計總圖如下：
- Sip信令流:
Iovzprovide内部涉及3個實體： sip代理、sip中繼、as。
其中sip代理負責和sip使用者對接，sip中繼負責和sip營運商對接；内部sip中繼、sip代理和as對接。不準許外部實體與as直接對接。
- RTP流：
Iovzprovide内部涉及2個實體： media中繼、as。
兩個外部實體直接和media中繼互動，如果需要media中繼會和as互動。同樣不準許外部實體與as直接互動。
- http流：
http主要用于提供門戶網站，配置資料、檢視狀态等。
Iovzprovide内部涉及1個實體： web portale
Iovzprovide提供四級門戶網站。
2.2，多級門戶
IvozProvider的門戶網站設計是允許同一基礎架構中含有多種角色：
- God Admin：解決方案的管理者和維護者。提供對多個品牌營運商的通路。
他們最重要的任務是建立品牌并對其進行配置，以便他們擁有足夠的自主權來正确使用該平台：
- 配置他們的網絡通路。
- 配置其品牌門戶外觀：主題，顔色等
他們的全局屬性還使他們負責：
- 監控平台，以便始終保持UP＆RUNNING
- 分析平台日志，以跟蹤可能的錯誤。
- 安全機制，以避免外部攻擊。
- 擷取通話音質的全局統計資料。
- 根據需求，增加平台的可用資源：
- 增加獨立安裝中的可用資源
- 根據需要遷移到具有多個AS，媒體中繼等的分布式安裝。
- Brand Admin：負責向多家公司營運商提供通路權限，擔保和賬單。
品牌營運商最重要的任務可以通過此門戶進行管理：建立和配置公司，以便他們可以正常工作。
由于品牌營運商也可以為其公司開票并確定外部消費者設定正确，是以還必須管理：
- 與PSTN互通性協商。
- 包含結算流程所需的所有公司資訊。
- 定價計劃及費用核算。
- 出入局路由設定。
- 為每個結算周期建立發票并将其發送給客戶。
- Company Admin：負責自己的PBX配置并管理最終的平台使用者。
公司管理者可以通路品牌營運商提供的門戶。
從它的角度來看，它在雲中有一個虛拟pbx，必須為其使用者進行配置。
- 配置終端，分機和使用者。
- 使用适當的邏輯配置DDI傳入過程：
- 直接發送給使用者
- IVR
- 轉接
- 傳真
-
- 來電轉發
- 請勿打擾
- 呼叫等待
- User：鍊中的最後一個連結，具有SIP憑證，可以通路自己的門戶以進行自定義配置。
最終使用者有兩種不同的憑證，都由其公司管理者提供：
- 使用者門戶通路憑證
- 用于将其終端（或終端）注冊到IvozProvider的SIP憑證
通過使用者門戶，它可以浏覽他們的呼叫系統資料庫并配置：
- 來電轉發
- 請勿打擾
- 呼叫等待
2.3，面向提供商
IvozProvider是一款電話解決方案，設計時考慮了橫向擴充功能， 它隻允許通過增加機器和資源來處理大量流量和使用者。
以下是IvozProvider設計成面向提供商的一些主要想法：
IvozProvider所有的子產品都可以在同一個主機上運作，也可以分離出來在單獨的機器上運作。分布式安裝可以使資源的按需配置設定到每一個任務，但需注意：
- 合理的部署子產品以保證可靠性。
- 合理的部署關鍵要素以保證盡量減少通信延遲。
- 合理的部署子產品以保證系統能夠處理成大量的并發呼叫。
限制VoIP解決方案服務的資源消耗元素是：
- 已經建立呼叫音頻管理。
- 每個公司配置（IVR，會議室，外部呼叫過濾器等）
- 配置和記錄的資料庫。
IvozProvider的設計始終牢記每個實體的可擴充行，是以它可以處理數十萬個并發呼叫。要實作這些最重要的是，根據預期的服務品質調整資源配置設定：
Media relay處理已建立呼叫的方法：
- 根據需要使用盡可能多的媒體中繼。
- 分組加入媒體中轉，并強制一些公司按需要使用群組。
- 在最終使用者附近設定媒體中繼，以盡量減少通話中的網絡延遲。
AS伺服器處理業務的方法：
- 橫向擴充：如果需要，可以安裝新的應用伺服器并将其添加到池中。
- 每個電話都由最不繁忙的Appliction Server處理
- 預設情況下，公司和應用程式伺服器之間不存在靜态配置設定關系。通過這種方式，任何應用程式伺服器的失敗并不重要：平台将在配置設定呼叫時忽略有故障的應用程式伺服器。
2.3，安全
IvozProvider旨在直接從Internet為使用者提供服務。雖然它可以在本地環境中使用，但IvozProvider旨在使用公共IP位址為其服務，進而消除了将基礎設施與最終使用者相連接配接的VPN或IPSec隧道的需求。
IvozProvider提供的一些安全機制：
- 隻有所需的服務才會暴露于網際網路。
- 不受信任的原始通路可以通過內建的防火牆過濾掉
- 可以過濾來自IP位址或網絡的通路以避免任何類型的網絡釣魚。
- 還有一種防洪機制可以避免短暫的拒絕服務攻擊。
- 每家公司的并發呼叫可以限制在固定數量。
- IvozProvider支援來自NAT後面終端的連接配接 。
- IvozProvider跟蹤那些NAT視窗并使用NAT穿透機制保持它們活着 。
3，Iovzprovide實驗
3.1關于ip配置
Iovzprovide可以根據管理節點的多少配置不同的ip，管理節點包括2.2提到的多級門戶，除過全局節點外其他節點都可以配置多個。且每個節點可以配置一個ip或者多個ip。
如果配置一個ip，可同時作為門戶通路ip和sip代理ip，也可以配置多個ip分别作為門戶ip和sip代理ip。
理論上配置的這些ip都可以是公網ip。
終端使用不同的域（ip）可以注冊到不同的節點上。
3.2關于呼叫
Iovzprovide使用者配置在公司節點上進行。可以使用使用者名注冊和通話，如zhangsan、lisi。
公司之間号碼可以相同，但公司之間号碼可以互通。如公司1有号碼1001，公司2也有1001，使用不同的公司域可以分别注冊，且可以互通電話。
理論上這種互通可以想辦法閉掉，目前沒找到。
未進行外部呼叫測試。
3.3關于門戶
從全局門戶開始逐級向使用者節點的門戶，中間節點内容的呈現是根據各級節點選擇的不同動态呈現的。
如，全局門戶建立有三個品牌B1，B2，B3。B1建立公司C1，C2，B2建立公司C3。C1建立使用者U1，U2，U3。C3建立U4。那麼管理時，下級管理子數會由上級的選擇自動生成。
4，經驗感受
1.由于不能看到該工程的具體設計，暫時沒能搞明白它所謂的橫向擴充的方式、方法。
2.看它的設計思路，感覺它設計的as是不與sip代理固定綁定的，是根據業務需求動态平衡的。
3.我認為這個工程在門戶上的設計還是有借鑒意義的。
4.它使用的一些開源工程比如業務品質監控等也可以借鑒。
5.總體感覺它的設計思路跟我們的設計還是有差別的。