Peer-to-Peer Internet Telephony using SIP
原作者：Kundan Singh and Henning Schulzrinne
Department of Computer Science, Columbia University
fkns10,[email protected]
譯者 汪亮宇 [email protected] 翻譯後沒有做校驗 有些地方不通順 。
基於p2p的sip電話系統
摘要
p2p系統天生擁有高擴展性、健壯性和高容錯性的特點，這些特點得益於系統沒有中央服務器並且網絡是自己管理的這種結構。本系統實現了在
p2p系統中較長的延遲的代價下定位感興趣的資源。internet 話可以被看作一個p2p架構的應用，它在一部分和另外一部分定位和通訊時在p2p
這種自組網上實現。我們的目的是構建一個基於SIP信令的純p2p架構的ip電話系統。 我們的p2psip架構支持基本的用戶註冊和呼叫建立，也提
供高級的服務 如：發送離線消息、聲音/圖像郵件 多方通話。同時我們提供一個可以實際操作的穿越防火牆NAT和安全性的p2psip。
（關鍵字 系統設計 點對點 高可靠性 擴展性 internet電話 SIP）
內容
1 介紹 2
2 背景和相關工作 3
2.1 P2P 系統: 結構化 vs 非結構化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Skype 和相關係統 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.3 基於SIP的電話 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.4 IP電話和文件共享的區別 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3 設計目標 5
4 設計取捨 5
4.1 複製註冊 vs 查詢呼叫建立 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2 什麼樣的節點組成分佈式哈希表? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.3 爲什麼註冊? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.4 P2P的選擇 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5 架構 8
5.1 節點啓動和節點查詢 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.2 用戶註冊 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.3 節點關閉和失敗 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.4 用戶定位和呼叫建立 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6 高級服務 13
6.1 NAT 和防火牆穿越 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.2 離線消息 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.3 多方會議 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.4 不依賴設備特性 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7 安全 15
1
8 執行性能預測 16
8.1 擴展性 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.2 可靠性 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.3 呼叫延遲 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9 總結和未來的工作 16
10 致謝
1 介紹
現存的internet電話的 客戶－服務器模式都是基於 IETF的SIP或者ITU-T推薦的H.323協議，在他們的工作域裏都有使用註冊服務器。用戶端（
或者 ip 電話）把他們的ip地址註冊到註冊服務器上使得其他用戶可以訪問他們。這種一服務器爲中心的系統的擴展性和可靠性都是以傳統的
冗餘和失效切換方式實現的，比如，DNS，IP 地址替換，MAC地址替換或應用層的切換。這種系統的主要成本在於系統的維護、配置，特別是需
要專業的系統管理人員。這就意味着想要迅速的建立一個在小範圍下的系統是不容易的（如 應急通訊或者一個會議）。
圖1
另外一方面，P2P系統天生就有擴展性和可靠性因爲它沒有單點故障的弱點。p2p系統，在純p2p結構中沒有服務器的概念 如圖1。所有的參與者
都是對等的，分佈式通訊，在這個潛在的不可信賴的環境裏去達到定位歌曲文件或者用戶的目的。有些文件傳送系統用中心索引服務器，比如
老的Napster就是一種混和型p2p系統。但就本文提到的"純"p2p系統是指沒有中心控制的系統。就目前存在的SIP 和 H.323的系統都有中心用
戶查詢但端到端的媒體傳送不是p2p的方式。
本文的中我們提出一種p2p架構，它是基於SIP的ip電話系統。我們定義了集中系統比如internet電話 和p2p方式的文件傳送系統的不同。我們
分析了各種可選的設計方案，並且展示了我們的sip p2p系統在基於chord的作爲底層的分佈式哈希表的設計細節。我們這種新穎的混和系統允
許傳統的sip電話可以在沒有sip服務器的情況下查找其他用戶。我們展現出SIP可以實現各種分佈式哈希表（DHT）的功能，如對等查找、用戶
註冊、節點失效檢查、用戶定位和呼叫建立來替換DNS中下一跳的sip查詢方式。就我們所知道的，我們的工作是首次基於SIP的應用p2p概念的
系統。
我們的架構得益於p2p的擴展性和可靠性。我們相信像Kazaa和Gnutella這樣的文件傳送系統之所以非常流行是因爲他們提供免費的音樂和電影
內容而不需要維護內容服務器，並且他們會自動檢測NAT和防火牆而無需人員干預。與此相同，p2p-sip除了擁有現有的internet電話所有的好
處外還有如下優點：
無需維護和配置：系統的工作更不就不需要任何煩人的服務器的安裝，包括NAT和防火牆的配置。我們的工作擴展了IETF zeroconf （零配置）
工作組關於媒體通訊和協作部分的工作。
協同工作能力： 不像其他的p2p系統如skype，我們的架構使用SIP消息作爲節點間的通訊協議。這樣它容易和已經存在的ip電話系統（比如
SIP-PSTN網關）協調工作。
這些優勢帶來一下問題如：增長的資源導致查詢延遲、安全威脅和可靠性。不像傳統的cs結構的查詢延遲算法O(1)，p2p的查詢可能會有更長的
查詢延遲（比如 chord的系統查詢延遲是O(logN) N是在對等網裏節點的數量）。一個分佈式的p2p系統更容易帶來安全危機比如信任問題（隱
私：有多少我的信息可以讓不可信的點知道？機密性：如果知道我信息的端點濫用我的個人信息怎麼辦？）和DoS攻擊（對我發起的成千的呼叫
請求是否合法？）。在沒有中心驗證單元的情況下一個可靠的驗證框架是個挑戰。另外，我們可能失去一些傳統的ip電話服務功能。比如,一些
可編程的呼叫路由技術如 SIP-CGI 可以在sip電話裏工作在p2p系統裏無法運作，因爲我們不想讓一些潛在的惡意的腳本上傳到我們的機器上。
最後，可靠性對ip電話系統來說是十分重要的。如果ip電話只是偶然通話成功而不像正常的電話系統時人們會不使用它。電話交換機被設計爲9
9%999的可靠性。
另外對基礎呼叫和註冊，我們提供了高級服務如 "遺失呼叫"通告和多方會議在p2p-sip裏。我們研究和學習了許多現存的文件共享系統。集
中型系統如多方通話需要處理一些稍許不同之處都在本文做了說明。
我們在第二部分說明的p2p的工作北京和sip的相關工作。第三部分列出了p2p架構的ip電話系統的目標。第四部分展現了各種設計的取捨。第五
部分提供了一個p2p-sip系統的概況，用戶註冊、呼叫。第六部分描述了p2p-sip系統的高級特性。第七部分分析了各種安全威脅和解決辦法。
第八部分預估了系統的在擴展性、可靠性和呼叫延遲等方面的情況。第九部分提出了我們的結論和未來的工作方向
2 背景和相關工作
在p2p系統上已經有了大量的分析和闡述的研究工作。
2.1 P2P系統結構化VS非結構化的
p2p系統可以廣泛的機密的實現非結構化（比如kazza 和 Gnutalla 那樣在節點裏保存文件）和結構化（比如使用對等哈希表DHT）。非結構化
的系統更多關注於實現一些實際的問題如NAT和防火牆的穿越問題，而對搜索策略上就是一般的典型的對鄰居節點發起大量的請求。另外一方面
，結構化系統比如Chord,Content Addressable Network(CAN)和Pastry [15]注意集中精力解決如何優化p2p的查詢延遲，加入、離開維護，來
代替大量發起請求這種低效率的模式。在結構化情況下NAT穿越卻沒有明確的解釋和說明。
我們用Chord的對等哈希表來實現查詢。Chord 有一個環行拓撲結構，在這個結構裏每個節點都保存了至少LogN個入口（或狀態）在它的查詢表
裏可以找到其他點。查詢的算法時間是O(LogN)。它的重複和遞歸查詢直接映射到SIP的重定向和代理特性。研究DHT是我們的一個補充工作，因
爲我們的架構對底層DHT會有所革新和優化。
2.2 Skype 和相關的系統
Skype是個免費的基於Kazza的p2p架構的應用，它允許Skype用戶通過internet呼叫任何Skype用戶。Skype有一些問題：
1 它的協議是私有的不是開放的標準比如 SIP
2 它提供了單一的服務 即 建立呼叫和及時消息，而不是一個針對新服務的架構
3 最重要的，它有一箇中央認證節點，這就意味着一旦這個中央節點崩潰那麼整個系統就無法工作。
在某種程度上說，Skype和典型的SIP電話系統沒有區別，此外 網索引服務器分配了一個超級節點給新加入的節點提供服務。超級節點如同SIP
註冊服務器，代理服務器或者存在服務器，它們維持着幾點的存在信息，並且通過這些超級節點去查找其他用戶。一個超級節點是那些有足夠
容量和可靠性的節點扮演的。我們相信它的查詢模式是一種變種的發送大量請求的模式，它和kazza類似，而不是基於對等哈希表查詢模式。Sk
ype實現了主要的特色功能是實現了和STUN、 TRUN服務器一樣的判斷節點NAT情況來處理NAT情況，而與SIP直接配置服務器應用不同。
人們已經開發了各種各樣的p2p媒體通訊應用，如洪泛式文本聊天或者擁有一些中心單元的給小組織用的點對點協助系統。
2.3 基於SIP的電話
圖2演示了使用代理服務器的呼叫流程
與p2p不同的是SIP電話系統是CS結構的。SIP是實現
internet會議、電話、存在狀態、事件通知和及時消息的信令協議。如圖2，當一個用戶Bob在他電腦（ip電話或手持設備）上啓動SIP終端，終
端註冊本機的ip到SIP服務器。SIP服務器保存了[email protected]和他的註冊ip地址間的映射關係。當其他用戶如，Alice發起呼叫或者發送及時消
息給[email protected]到服務器的home.com域，SIP服務器會把這些請求發送給當前Bob使用的設備上。更進一步說這種協議可以認爲是處理過的p2p
系統，這種SIP電話的通過狀態設置超級節點（即SIP服務器），他們基於DNS域名解析來發現節點而不是哈希關鍵字。這樣說來，使用一個純的
p2p架構代替現有的SIP服務器狀態設置可以提高系統的可靠性允許系統動態適應節點失效的情況。
2.4 IP電話系統和文件共享系統的區別
有3種廣義的應用：文件共享，目錄服務，集中系統。集中或者會議系統發起通訊請求時會和用戶或者組織通訊，它會激活同步不同的點激活狀
態。比如一個用戶發起SIP邀請請求給潛在的用戶讓他們參與會議，它通過建立一對多的關係捆綁這種情況。
表 1展示了這些類型的相似和不同。
表 1: p2p系統間的區別
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
Properties/Types |File sharing |directory |rendezvous systems |
--------------------------------------------------------------
Data storage | yes | no | no |
Caching | yes | yes | no |
Delay sensitive | no | no | yes |
Reliability | Multiple copies | Does not work |
----------------------------------------------------------------
特別是對集中型的internet會議來說數據保存不是問題。一個p2p sip節點可以處理很多種請求它遠比文件共享節點處理數據層面的請求多。緩
存定義信息不是很有用了，因爲比較基於pf分佈式的文件訪問模式，呼叫訪問模式更多是一致性的分佈式的。此外，很多住宅用戶是通過DHC
P方式獲得IP，對次來說緩存的定位信息都是無用的。文件共享和目錄系統的用戶可以忍耐長時間的查詢延遲，因爲用戶不必一直等着文件的下
載，而且實際上下載文件的時間遠大於查詢的延遲。另外一方面，一個Ip電話的呼叫者會一直等着被叫方的震鈴。對文件共享應用來說多個文
件拷貝存在於不同節點是可以的（如 獨立節點上的）。所以節點的可靠性是不太重要的。而對IP電話來說我們是想和一個正確的人通話而不是
類似的人通話！
3設計目標
基於前面的對現存的p2p系統的分析如Skype和 Chord，我們準備對我們的p2p sip電話架構做如下目標定義：
零配置：系統應該可以自動的配置自己，如檢測NAT和防火牆設置，發現鄰居節點和執行初始化註冊。
分化節點：它可以適應可用資源和區別節點的性能，可用性等指標。如KAzza一樣它可以區別普通節點和超級節點。
有效率的查詢：基於洪泛的盲目查詢是低效率的。系統應該用對等哈希表作爲底層查詢的方法。我們選擇Chord作爲底層的查詢模式是因爲他的
處理併發的節點加入和離開情況的健壯和有效性。
高級服務：它必須支持離線聲音消息，多方會議，呼叫轉移，呼叫轉發，高級的internet服務如 在線狀態和及時消息。
協同工作性：它應該很容易的融入現有的協議和ip電話系統框架下。我們選擇SIP作爲信令協議就是爲了協作性。
除了這些明確的目標外，它還有一些p2p系統的特有的好處如可擴展性和可靠性，這些是CS結構所沒有的。
4設計取捨
在這部分我們將評估各種設計的不同 如在用戶查詢 和 註冊等達到前面說的目標。我們開始做一個簡單的sip呼叫然後增加和擴展p2p結構的可
靠性。
4.1 複製註冊 VS 查詢呼叫建立
回到圖2的簡單呼叫的例子，一個單獨的服務器可以成爲擴展性的瓶頸。這種情況需要更多的服務器來提高性能。這有兩種可選方案:
1 複製所有的用戶定位信息到所有的服務器上如圖3所示 或
2 當有新用戶呼叫收到，查詢當前服務器保存的目標用戶的定位，如圖4顯示的
在第一種情況，圖3顯出多個註冊時一個可以選擇的情況是做數據庫複製保證用戶的數據在多服務器集羣裏的都有。在第二種情況，無論呼叫人
以一定順序嘗試所有的服務器或者首次聯繫服務器就要做查詢。
對第一種情況不利的是需要對所有服務器做好同步數據處理。它有個危險的情況是當優點的舊用戶定位數據在短時間內更新而其他服務器還沒
有更新時。當註冊在每小時爲每個人刷新時，這個結構裏傳送所有用戶同步數據的數據就會成爲系統的瓶頸。在方案二里，呼叫建立的延遲在
順序搜索時很長。一個平行的查詢將會加大帶寬的需求。這兩種情況在服務器數量加大時都將失敗。頭一個情況在文獻【4】裏已經有說明。在
本文章裏我們關注第二種情況。
4.2 節點如何構成對等哈希表?
Clients
Servers
Figure 5: Option 1:
Only servers in DHT
Route(d46a1c)
= user phone
Figure 6: Option 2: Complete P2P
overlay
Super nodes in DHT
ordinary nodes
Figure 7: Option 3: Intermediate
model
我們可以實現一些合併兩種設計的方法，使用Chord分佈式哈希表，這樣註冊只需要O(LogN)
個服務器而不是所有N個服務器，查詢也只是需要O(LogN)，代替對所有N個服務器查詢。這有三種可選的使用DHT的方案。一種情況的是，我們
可以限制DHT中服務器的數量如圖5。這種情況下，每個終端或者電話連接其中的一個服務器。這些服務器實現分佈式哈希表或者可擴展性數據
結構來定位當前用戶的位置。我們這個環假定基於Chord的DHT。架構仍然是CS結構的。終端至少需要發現一個服務器，更適宜輕量級的裝載，
然後連接那個服務器。在另外一種情況如圖6，一個終端既扮演服務器又扮演終端，但是它提供了一個可擴展和可靠的服務器羣架構。DHT用來
定位用戶。前一種選擇不需要改變終端，提供了一個可擴展和可靠的服務器羣。但是它仍然存在有些服務器需要維護和配置的問題，第二種情
況就沒有了。
對"純"的p2p結構來說不是所有的節點的運算能力和性能都一樣。例如，一個節點接入internet時是低帶寬的，或者在NAT或者防火牆後面。
無法完全實現DHT的功能，因爲他們可能只是允許 in-bound 連接，有限的帶寬給p2p消息或者有限的內存或CPUl來維護DHT狀態。這種問題可以
用一箇中間媒介來解決，如圖7。一些節點是高性能節點（帶寬，CPU，內存）並且可靠（在線時間，公網地址）就成爲超級節點。只有超級節
點構成一個DHT。一般的節點只是連接到這些超級節點上，這和Kazza很像。這和第一種情況有些像除了不區分終端和服務器，並且任何的節點
既可以成爲超級節點也可成爲普通節點（都由他們的性能決定）。
我們的目標是允許p2p sip節點可以工作在任何的上面的提到的配置的情況下。
決定成爲超級節點或者普通節點都是在本地實現。當一個節點啓動它將是個普通節點。當普通節點檢測到自己有足夠的性能和可靠性（公網地
址和上線時間），它就自己變爲超級節點。一個有高性能和可靠性的節點可能強迫成爲一個超級節點當存在的超級節點離開或者達到它的能力
極限時。此外，一些節點節點知道自己足夠強大時會在啓動時就變成超級節點。存在的節點也可以影響它的鄰居節點成爲超級節點。
現有有兩層角色，超級節點和普通節點，無法提高查找的延遲限制。查詢延遲仍然是O(LogN)，它提高了系統實現的性能因爲DHT維護的傳輸數
據的大量減少可以使得DHT更加穩定。更多層的效率和維護代價是將來研究的方向。
4.3 爲什麼註冊?
用戶註冊他們的標示到系統，這樣其他的用戶可以定位他們。如同圖8展示的，當用戶啓動它的終端應用並顯示"屏幕名字"是
[email protected]，節點計算名字變爲DHT關鍵字（用SHA1實現的哈希關鍵字編碼，如Chord實現的）通過這個用戶名字關鍵字把它當作節點關
鍵字。本例子裏Alice的關鍵字是42，對Alice說，和Bob通話，需要定位Alice，Bob的節點使用相同的哈希函數去計算相同的42 ，對應Alice，
並且在對等哈希表裏調用find(42)找Alice。DHT的算法定位了節點42，這樣Bob的應用程序可以和Alice的程序對話。
12
42
24
[email protected]=12
[email protected]=42
[email protected]=24
Figure 8: No REGISTER
REGISTER [email protected]=42
REGISTER [email protected]=12
24
56
42
12
58
32
14
Figure 9: With REGISTER
這個方案無法支持離線消息或者多個用戶用相關的SIP用戶身份註冊的情況，sip:[email protected]
例如，如果Alice不在Bob無法留下口信給她。
另外一種方法如圖9中，節點關鍵字和用戶關鍵字的計算是分開的。 SIP註冊消息是被用作註冊到DHT的身份。每個節點在DHT中都是一個註冊者
。當Alice啓動她的應用，節點使用他的IP地址計算節點關鍵字，14。（在其他的DHT算法裏如 CAN，她可以隨機選擇一個關鍵字）。它可以把
自己插入DHT，用他的節點關鍵字，來發送註冊消息。接着Alice的節點開始計算Alice的名字並且發送SIP註冊消息到其他節點,用關鍵字58，這
是對用戶關鍵字42的一個關聯。例如，Alice的節點擁有節點關鍵字14，Alice的用戶關鍵字是42，所以節點14發送了註冊消息是關鍵字42。節
點58是負責關鍵字42訪問註冊和維護狀態，即用戶Alice可以在節點14上的IP地址被發現。即使如果Alice沒有在線（節點14），Bob仍然可以留
下離線消息給節點58，它可以稍後轉交個Alice當Alice在線時。類似的，這樣可以有多個用戶可以使用相同的用戶關鍵字42，如果Alice有多個
存活的終端時。
作爲可選的SIP註冊消息，一個可以用SIP 發佈消息來發布用戶的位置和在線狀態。這兩種消息（註冊消息和發佈消息）處理在本文裏是相同的
，所以這種選擇不會影響到系統結構。
4.4 P2P的取捨
我們注意到典型的CS架構的SIP和p2p sip架構是兩種情況。例如，前一種情況有一個唯一域服務器，用DNS來定位服務器。後一種情況，p2p是
用來定位節點上保持的用戶定位信息。有些中間架構可以用DNS來定位服務器，但服務器可以通過動態DNS動態的加入和離開系統。這種情況帶
來服務供應商的模式變化，供應商銷售SIP其他供應商的服務（一部分的SIP服務器池）。DotSlash 探索了這種可能性在web"熱點"和使用服
務定位協議（SLP）去定位備份服務器。這樣的情況如同明顯的同步註冊記錄和參與的服務器類似加入 離開情況維護p2p的系統。
5 結構
基於前面提到的可選的部分，我們計劃實現我們的p2p sip系統在本節。
圖10展現了p2psip的節點的組件：
註冊： 當節點啓動並且用戶的簽到它的身份時，註冊模塊激活檢測NAT和防火牆的檢測，對等點發現和SIP註冊（5.1節）
防火牆和NAT檢測：看6.1節
用戶接口：這個模塊是和用戶交互的模塊，它保存它的"好友列表"並且調用用戶的定位模塊去定位好友。
用戶定位：這個模塊可以調用SIP模塊或者 如果節點是超級節點時，DHT模塊去定位用戶 （5.4節）
分佈式哈希表DHT：這個模塊在節點是超級節點時維護DHT的節點信息（如 Chord的查詢表）並執行DHT邏輯。這個API包括 find join 和leave
方法。
SIP：SIP是底層的協議，用來定位用戶、註冊用戶、呼叫建立、及時消息。一定用戶定位，呼叫和及時消息就可直接通過SIP模塊建立。它的AP
I允許發送和接收SIP請求的和反饋，並維護呼叫和註冊狀態。
媒體路徑： 媒體路徑（聲音設備，codecs 和傳送器）是一個很大程度上不依賴p2p sip的操作。
DHT模塊用SIP消息去在節點間通訊。
5.1 節點啓動和對等發現
實際上，終端節點可以用p2p或者sip的方式去查找用戶。當節點啓動時，用戶輸入它的身份 如[email protected]，節點找到可能的sip服務器
地址用DNS，併發送sip 註冊消息如圖11。如果註冊成功，它就可以到達標準的SIP機器除了p2p的機器外。
這個節點也嘗試發現可能的超級節點，這樣可以加入到p2p網。一旦你知道某個節點在Chord裏你可以加入基於 Chord的關鍵字的Chord 的DHT。
有大量的辦法可以重用到已經存在的的建議裏:
廣播小生命週期的包 (TTL) （如在LAN內部），可以去發現本地的其他點，通過他們發現超級節點的信息。SIP定義了廣播註冊地址 IPv4 是
224.0.1.75。多播的節點發現可能引起多個斷開連接的DHT組件。爲了避免這種情況，只有存在的DHT節點（超級節點）可以對多播請求反饋（
普通節點對發現請求不反饋）。限制多播意味這系統不能只依賴多播這一條路。
一些服務的排序發現機制，如 SLP，定位超級節點。
如果每個點地址被緩存，那麼更多的超級節點的地址可獲得，當這些超級節點被最近發現時沒有改變它的定位信息且是活躍的時候。
作爲最後手段，一些預先配置的自啓動節點可以獲得DNS查詢在已知的域裏，如 sip p2p.net，或者可預先配置一些應用軟件 如Skype一樣。
超級節點的的信息被緩存，爲了以後的註冊使用如再次的登陸註銷等。因此，這種查詢一般只是發生一次，只有當所有緩存的超級節點信息都
沒有了或者失效是才做。
5.2 用戶註冊
一旦檢測到一組超級節點，系統會找出兩個點併發送SIP註冊消息去註冊他們。兩個超級節點在這裏是爲了冗餘。對"去"和"來此"的消息頭
來定位本地用戶身份，如 sip:[email protected]。請求的URI符合超級節點的地址如 sip:192.2.1.2:5060。
圖11 節點啓動和向外註冊。
一個通常的節點是一個SIP用戶代理，所以一個超級節點對SIP用戶代理來說就是一個註冊服務員。超級節點發送註冊消息代表捆綁節點集合到
目的的超級節點的DHT網絡中。它加入其他超級節點組成的DHT並參與用戶定位查詢。普通節點週期性發送註冊消息檢測超級節點是否無效。超
級節點則在他們超級節點間週期性發送SIP選項條件的消息或者是監控綁定到它的節點的生存狀態。刷新的時間間隔可以在系統啓動時做調整。
"選項條件消息"不是發送是否這個節點和目的節點在過去的間隔裏有通訊。
當普通節點收到註冊消息後，它發送SIP重傳反饋到重傳的發送者即它的超級節點 如圖12。當一個超級節點收到註冊消息，並且發送者是註冊
到它的節點時，超級節點代理這個消息到合適的DHT節點 作爲每個用戶關鍵字的發送者。如果發送者不是這個超級節點的所屬的節點，超級節
點可以決定是否接收新節點或者拒絕這個節點。如果超級節點想要拒絕它，它會轉發這個新節點的消息到其他負載小於這個超級節點的超級節
點。發送者做循環檢測避免進入重傳循環裏。防止重傳循環的細節需要在將來研究。
Figure 12: Incoming registration
5.3 節點關閉和失效
當一個普通節點離開系統，它可發送註銷消息，到它的超級節點，這樣就會輪流把保存了它的節點關鍵字的點做註銷處理。一個失效的節點不
會影響餘下的系統。在任何情況下，超級節點都可通過週期刷新檢測到失效的普通節點。它可以通過選項條件消息發送到這些失效節點看看他
們是否還有響應。
當一個超級節點離開，所有它所屬的節點需要更新到這個超級節點的DHT鄰居超級節點上。如果超級節點關閉，它會平緩的發送它的節點的記錄
到其他p2p節點。這樣可以保障當DHT的節點關閉時，其他用戶可以定位到這些節點。它會發送SIP註冊消息到DHT節點，它會保持這些用戶記錄
知道它離開。這無需通知普通節點。所屬的普通節點將會在下次註冊刷新和查詢時連接到其他的那些保存他們記錄的超級節點。
圖13 在DHT中失效的節點
當一個超級節點意外失敗（圖13），它相鄰的DHT節點檢測到失敗並調整DHT失敗節點保留的關鍵字。這樣相關的映射就丟失了，除非原來失敗
的超級節點發起註冊刷新。註冊刷新轉到新的超級節點，可以處理相應的在DHT裏的關鍵字。這樣使得一些服務無法實現如離線消息會臨時失效
（6節）。爲了判斷一個只有SIP的應用服務和一個sip p2p應用，我們用定製的請求的頭選項條件消息 或者註冊消息來區別。
5.4 用戶定位和呼叫建立
用戶可觀察其他在好友中指定的用戶的在線狀態。如果用戶已經有了好友列表，節點去定位那些啓動的好友。最初我們假定這個好友列表保存
在本地。我們擴展了這個想法 在第六節 我們保存這些用戶信息（包括好友列表）到整個p2p網絡不依賴用戶。所有的好友ip地址都將緩存以供
將來使用。
本文最重要的目的是用定位的記錄找到最終的用戶。一旦呼叫建立完畢，媒體數據包將做端對端發送。節點分別在發送及時消息或者媒體呼叫
時用SIP消息或者邀請消息。如果目的地址被緩存，例如，這個節點做了次最近呼叫或者及時消息到目的地，接着緩存的地址被使用。如果終端
緩存的ip地址沒有反應（因爲沒有終端在允許或者非sip p2p節點），接着緩存信息刪除，節點開始重新查詢。
基於SIP的查詢和p2p的查詢是否類似的，看圖14。對p2p查詢，一個普通的節點發送邀請或者消息給所屬的節點，此時它充當一個SIP代理。一
個超級節點定位目的節點依賴域底層DHT的關鍵字。一旦映射獲得，超級節點可以代理或者轉發詳細。轉發是首選的方式它可排除超級節點的呼
叫循環情況。然而，在一些情況下比如有防火牆和NAT，代理就成爲唯一選擇了 看6.1節。
一些DHT（如 CAN）可以允許並行查詢多個點，而不像Chord的順序查找。在這種情況下超級節點扮演 連續的用戶終端back-to-back user
agent (B2BUA)傳遞SIP消息到鄰居節點上。然而，並行查詢需要避免網絡風暴，除了可能的情況如緊急呼叫路由，如在美國的911呼叫。
其他的SIP功能如第三方呼叫控制和呼叫轉移實現的方式是類似的途徑。例如，在SIP的交談消息的傳送路由和在p2p網的邀請消息很像。許多消
息處理在端對端上直接通訊而不在通過p2p網絡了。圖14 用戶定位和呼叫建立
只有對話開始的消息如邀請或者如及時消息的首次消息需要p2p的查詢服務。
6 高級服務
基本的通話功能這種服務在internet電話中是不具備競爭力的。本節會描述一些高級服務如穿越NAT和防火牆，離線消息存貯和多方會議。
6.1 穿越NAT和防火牆
在一個理想的環境裏，ISPs和合作系統的管理員應該允許他們的NAT和防火牆讓SIP通過代理和應用級的網關（ALG）。然而，實際上很少能這樣
。這迫使應用程序的開發人需要做些特別的設置去應付NAT和防火牆。
穿越NAT和防火牆有兩方面問題： 自動檢測NAT和防火牆的類型和建立穿越NAT和防火牆傳送消息的隧道。檢測節點的NAT類型在節點啓動連接超
級節點時就會完成。節點穿越NAT時實現交互式連通性建立算法（ICE）[17]。UDP協議是首選的連接模式。然而，如果UDP包無法被接收（如防
火牆阻塞UDP包），那麼一個TCP 的80端口的通道估計是建立的，這樣這個連接內部節點和外部超級節點的進出消息就可以連通。
6.2 離線消息
本節描述離線消息的問題。當Alice呼叫Bob 或者留下一個及時消息給Bob,並且此時Bob不在線，此時消息要妥善的保存直到Bob上線時轉發他。
我們可以把離線消息保存在3個地方：發送源頭，接收目的和p2p網絡中的中間媒介。傳統的PSTN網絡的語音郵件是存放在目的應答機上，應答
機對被叫人的電話做了綁定，或者把語音保存在中央語音服務器上，它再對目的的PBX做綁定。與此類似p2p sip系統的終端也可以再目的被叫
用戶沒有摘機時把相關語音消息保存到目的機上。問題是當目的用戶的電話沒有激活或者終端沒有啓動時這種辦法就不行了。一種解決辦法是
，如圖15，用DHT的對等點機制保存Bob的定位，並保存這些多媒體消息。一旦節點失效，這些離線消息隨之失效，直到它們再次在線爲止。爲
解決這個問題，這些離線消息可以保存在多個地方並保持他們的一致性如文獻[26]提到的海洋架構。對一個p2p的共享文件系統來說等待的暗示
是足夠實現離線消息的存貯的。郵寄[27]是p2p消息系統可以實現離線方式的另外一個辦法。
還有一個辦法是在呼叫人的節點上緩存消息一旦對方上線在發送消息給他。
消息的發送通知對呼叫人來說是可靠的。如果消息沒有發送或者存貯節點失效，那麼呼叫人節點會尋找新的存儲節點而無需用戶干預。當一個
節點啓動，他檢查從上次啓動以來任何沒有發送的消息，並在CPU和帶寬允許的情況下嘗試重發這些消息。不過這會有個安全問題，如網吧的機
器上會有多個不同用戶使用，會有問題。
與郵件系統不同，郵件系統有很多中間媒介郵件傳送代理，他們保障了傳送的可靠和確認性，在p2p sip網絡裏端對端是無法確認這種請求的。
我們可以考慮用第三方的服務器來保存訂閱消息的人發送發送者的消息備份。這樣一些節點在CPU和帶寬都不理想的情況下可以只緩存一些消息
梗概（如消息的名字，時間，頭）。還有些節點可能希望有加密校驗的消息發送保障，如同在郵件系統裏一樣。要接收離線消息，目的節點只
有定義消息等待喚醒事件(MWI)即可，這樣當p2p網的節點啓動時，他會收到有新離線消息發送來到。節點可以通過文件傳送或者直接呼叫到一
個URI上來獲得實時媒體（如呼叫 sip:bob-vmail@server）接收這些離線。這樣用戶可以從一些註冊到p2p網絡的中心服務供應商那裏購買消息
等待喚醒事件（MWI）這種服務，用戶可以收到他們的留言。
6.3 多方會議
在傳統的電話系統裏多方會議是通過預留撥號會議橋（或者會議服務器）來實現。這些會議服務器可以註冊已經定義的會議地址如"staff-mee
[email protected]"這樣的p2p網絡格式。然而，混音實在服務器上實現的，對大型會議這會是一個潛在的系統瓶頸。
對小範圍的特殊會議會議參與者中高性能的節點（CPU 內存 帶寬）可以成爲混音服務器，給其他用戶做混音處理。因爲混音需要訪問所有參與
人的非加密的採樣數據，所以非信任的節點無法做混音處理器。一個可選的辦法是選擇一個存在的參會人做混音器。
完全分散式的會議[28]可以在參會人間建立全互連（每個點都有聯繫關係）的信令和媒體關係。這樣就預防了單一節點做混音的問題。
代替全互連媒體，廣播媒體對等樹可以應用。他假定在某個時段只有一兩個用戶在說話，接收節點可以選擇或者混音採樣在整個會話過程中。
一些p2p應用層的多播計劃已經被提出[29,30]，其中一些可以貼近底層是DHT的這種結構[15,31]。
6.4 不依賴設備特性
就目前爲止我們假設用戶連入網絡時所有的用戶身份信息如好友列表和個人信息都保存在本地，其實和文件存儲系統和離線消息存貯消息一樣
我們也可以把用戶的信息保存在p2p網絡裏[26]，系統啓動時用戶簽到節點獲得自己可靠的用戶信息並使用他們。
7 安全性
安全是p2p系統裏最需要解決的重要問題，因爲整個系統裏有很多潛在的不可信的節點。
問題如下：
（1）驗證（防止一些未驗證的垃圾呼叫）
（2）加密（防止其他不在呼叫建立的鏈路上的人竊聽談話的內容）
（3）隱私和機密（保護髮送到不可信賴的節點的信息防止濫用信息）
（4）處理惡意節點（如當一個節點在很高興的收到一個節點呼叫時發現去了一個不想要的節點）
前兩個問題採用SIP電話的策略就可以解決。如，端對端的數字驗證，逐項傳輸層安全（TLS）或者端對端S/MIME。
有大量的"不可信"節點可能包括在用戶定位呼叫裏，而不像在SIP電話系統裏那些"可信"的服務器。在傳統的基於服務器的電話系統裏，呼
叫的雙方都對服務器是可信的，這樣就沒有安全問題。其次，雖然節點是正常的，但呼叫的日誌請求會在以後被濫用。
Freenet[6]對此解決的策略是對逐跳的路由節點上改變源頭的標示。這樣會防止中轉的機器知道呼叫的源頭是誰。類似的技術可以用戶p2p sip
架構來發展多個點協同作案（如多個惡意節點協同發現呼叫信息）。
大量的p2p系統信譽問題已經提出。然而，他們關注的是文件共享系統（非實時系統），有中心單元，假設他們共謀和多個身份信息。將來的研
究需要做的是確認對等點誰是已知的掛機或者惡意用戶無法知道不被他使用的呼叫路由信息並不允許進入底層的DHT。還有另外一個威脅來自"
搭便車"[37]。一些節點使用p2p呼叫和和收信服務，但是拒絕成爲超級節點爲他人服務。系統一個制定一些策略來阻止這類節點。例如，節點
可以通過提供服務來獲得信用等級獲得其他服務。每個節點都可以啓動初始信用帳戶。在NAT和防火牆後的節點如果不能成爲超級節點那麼需要
付出自己的信用帳戶的錢來獲得服務。那些用光了信息額度的節點、拒絕服務的節點將會降低可以獲得服務的等級，只有很少的服務可用。
如果用戶身份很容易獲得，如雅虎郵箱一樣，那麼用戶會經常註冊許多新身份來呼叫。而且他們不會長期用戶這個身份去呼叫，特別是當他們
的用戶信用等級下降和不用p2p網絡時。因此外呼時不要給用戶免費的網關和免費的PSTN呼叫（即免費的pc-phone）。
最後如果自動軟件更新合併到p2psip中，系統會很穩定，安全和分散管理。
8 性能預估
8.1 擴展性
p2psip的擴展性依賴與參與的超級節點的性能。有N個超級節點組成Chord環，驗證標示 m-bit長（如範圍 有0到2的m次方），系統用戶數量n，
（每個節點存儲的關鍵字接近 k=n/N），在環上處理和沒處理的註冊用戶刷新速率 rs, 查詢表的刷新速率 rf,呼叫到達每節點 c 符合泊松分
步，用戶是均勻分步即每個時間間隔有t個用戶，節點的離開和加入是泊松分步的朗大。因爲平均Chord的查詢傳送時間是O(Log(N))，查詢刷新
消息，呼叫到達消息，和用戶註冊刷新消息 傳送O(log(N))每跳。每節點有O(log(N))個查詢表入口。節點加入和離開有O((log(N))2)個消息。
每個節點的消息平均速率 刷新、呼叫到達。用戶註冊和節點加入、離開可如下面的計算：
M ={ rs + rf (log(N))^2}＋c.log(N)+k/tlog(N)+朗大(log(N))^2/N
節點消息的速率用來確認帶寬和CPU的利用率。如果每個節點每秒處理 c個請求，則 C=M爲最大的可能的節點數量，這個數量的節點在系統中需
要傳送 Nmax= 2的c/r+c次方的對最大N數量，這裏的r是刷新速率，c是呼叫速率。注意這裏的朗大很低，因爲節點的加入離開不會建立超級節
點。
預計節點支持每秒10次請求（比sip的代理效率要小很多[38]）使用最小的刷新間隔 如 r=1/60 ->1秒，呼叫速率是每分鐘每個節點，這種情況
下系統最大容量是 2的10*30次方。如果有更多節點加入系統，那麼超級節點將會超載，並可能拒絕一些呼叫，註冊或者代理請求。然而，最大
數量N仍然會加大呼叫延遲，下面我們會提到。
8.2 可靠性
當一個節點失效，保存在這個節點的用戶註冊信息就會丟失。爲了可靠，刷新速率可以增加（節點失敗的檢測可以更快），用戶註冊刷新速率
可以增加（這樣用戶記錄失效會很短暫）或者用戶註冊記錄保存到多個節點（如像Chord實現的保存log(N)個註冊成功的記錄到節點上）。我們
打算量化這種情況下的平均故障恢復期從節點失效到給定了用戶記錄。相等的平均速率沒有改變，如果朗大包括失效速率和節點離開和加入速
率。
8.3 呼叫建立延遲
p2p的優勢帶來了呼叫建立延遲的代價。例如，在10000個節點的Chord中，那麼平均的查詢路徑的跳數是6，所以這個p2p呼叫需要至少6次超過
傳統的cs結構的SIP建立時間。在網絡情況好的情況下，SIP單獨的查詢（邀請 反饋）小於200ms。所以這樣在一到兩秒的情況下在p2psip系統
裏等待被叫人摘機的情況是可以忍耐的。
由於p2p的同步延遲，如刷新節點加入 離開、失效都會延遲用戶的更新記錄。在這種情況下，可能在最終呼叫建立前會有更多的多播發送。這
在將來隨着呼叫的增多會增加呼叫延遲。Skype的用戶定位耗時3到8秒是比較成功的。一些混和型系統實現了許多優點和非信任p2p算法減少了
延遲和維護的代價。例如最近提出的[39]一跳查詢，假設每個節點都有足夠大的存儲空間。
9 總結和未來的工作
我們描述了一個純的p2p 構架的sip電話系統。這個系統提供了繼承與p2p系統的可擴展性和可靠性，另外它可以和SIP層面的系統協同工作。這
些優勢以增加呼叫建立延遲爲代價。
我們分析了各種可選設計，我們打算使用Chord的DHT最爲p2psip的底層，並描述了各種用戶定位註冊的詳細步驟。我們也介紹了各種高級服務
如離線消息，會議，NAT防火牆的穿越和安全問題。
我們實現了一個p2psip節點做多媒體通訊，它使用我們自己開發的SIP c++庫。我們會在我們的實際環境裏檢測它的擴展性，可靠性來代替模擬
器。因爲是基於Chord實現的p2p，許多仿真結果沒有放入已經存在的仿真結果裏。
更多的工作會集中於如大範圍的p2p廣播會議，分佈式的信譽系統，和連接到PSTN網的工作記帳和驗證工作。
需要有一個合理的激勵節點成爲超級節點給大家服務的機制。
我們正在做讓在NAT和防火牆後的節點可以成爲超級節點的工作。這會減少公網上超級節點的負載，因爲很多用戶都會在NAT和防火牆後面。可
選的，在這種情況下，域中的私有節點組成一個二級p2p網絡，聯絡公網的DHT，通過有限的連接，這樣會減少NAT設備的端口利用。
一些公開的描述的問題和p2psip系統架構是有關的[40]。如一些混和型的系統實現了低延遲和小維護的情況，如最近提出的p2p一跳查詢[39]假
設大存儲空間。這些方向的應用是p2psip的下一步研究的內容。
最後，我們認爲除非SIP服務器會大量部署，否則我們的基於p2p的ip電話系統工具是可以讓每個用戶使用的。這個架構還可以擴展到其他協議
如H.323。
10 致謝
Salman Abdul Baset helped in understanding the Skype architecture. The work is supported by a grant from SIPquest,
Inc.
References
[1] Henning Schulzrinne and J. Rosenberg, "Internet telephony: Architecture and protocols - an IETF perspective,"
Computer Networks and ISDN Systems, vol. 31, no. 3, pp. 237-255, Feb. 1999.
[2] J. Rosenberg, Henning Schulzrinne, G. Camarillo, A. R. Johnston, J. Peterson, R. Sparks, M. Handley, and
E. Schooler, "SIP: session initiation protocol," RFC 3261, Internet Engineering Task Force, June 2002.
[3] James Toga and J¨org Ott, "ITU-T standardization activities for interactive multimedia communications on packetbased
networks: H.323 and related recommendations," Computer Networks and ISDN Systems, vol. 31, no. 3,
pp. 205-223, Feb. 1999.
[4] Kundan Singh and Henning Schulzrinne, "Failover and load sharing in SIP telephony," Tech. Rep. CUCS-011-
04, Columbia University, Computer Science Department, New York, NY, USA, Mar. 2004.
[5] Haakon Bryhni, Espen Klovning, and ivind Kure, "A comparison of load balancing techniques for scalable
web servers," IEEE Network, vol. 14, no. 4, July 2000.
[6] Dejan Milojicic, Vana Kalogeraki, Rajan M Lukose, Kiran Nagaraja, Jim Pruyne, Bruno Richard, Sami Rollins,
and Zhichen Xu, "Peer-to-peer computing," technical report HPL-2002-57 20020315, Technical Publications Department,
HP Labs Research Library, Mar. 2002, http://www.hpl.hp.com/techreports/2002/HPL-2002-57.html.
[7] Ion Stoica, Robert Morris, David Karger, Frans Kaashoek, and Hari Balakrishnan, "Chord: A scalable peer-topeer
lookup service for internet applications," in SIGCOMM, San Diego, CA, USA, Aug 2001.
[8] J. Rosenberg and Henning Schulzrinne, "Session initiation protocol (SIP): locating SIP servers," RFC 3263,
Internet Engineering Task Force, June 2002.
[9] "Kazaa: peer-to-peer file sharing software application," http://www.kazaa.com.
17
[10] "Gnutella: peer-to-peer file sharing software application," http://www.gnutella.com.
[11] "Zero configuration networking (zeroconf)," http://www.ietf.org/html.charters/zeroconf-charter.html.
[12] "Skype: Free internet telephony that just works," http://www.skype.com.
[13] Zihui Ge, Daniel R. Figueiredo, Sharad Jaiswal, James F. Kurose, and Don Towsley, "Modeling peer-peer file
sharing systems," in Proceedings of the Conference on Computer Communications (IEEE Infocom), Mar. 2003.
[14] Sylvia Ratnasamy, Paul Francis, Mark Handley, Richard Karp, and Scott Shenker, "A scalable contentaddressable
network," in SIGCOMM Symposium on Communications Architectures and Protocols, San Diego,
CA, USA, Aug. 2001, ACM.
[15] Antony Rowstron and Peter Druschel, "Pastry: Scalable, distributed object location and routing for large-scale
peer-to-peer systems," in IFIP/ACM International Conference on Distributed Systems Platforms (Middleware),
Heidelberg, Germany, Nov. 2001, pp. 329-350.
[16] David Liben-Nowell, Hari Balakrishnan, and David Karger, "Analysis of the evolution of peer-to-peer systems,"
in ACM Conf. on Principles of Distributed Computing (PODC), Monterey, CA, USA, July 2002, ACM.
[17] Jonathan Rosenberg, "Interactive connectivity establishment (ICE): a methodology for nettwork address translator
(NAT) traversal for the session initiation protocol (SIP)," Internet draft, Internet Engineering Task Force,
July 2003, Work in progress.
[18] Frank Strauss and S. Schmidt, "P2P CHAT - a peer-to-peer chat protocol," Internet draft, Internet Engineering
Task Force, June 2003, Work in progress.
[19] "Groove workspace software," http://www.groove.net.
[20] "Magi p2p technology being adopted across vertical industries," http://www.endeavors.com/PressReleases/partners1.htm.
[21] Steven D. Gribble, Eric Brewer, Joseph Hellerstein, and David Culler, "Scalable, distributed data structures for
Internet service construction," in Operating Systems Design and Implementation, San Diego, CA, USA, Oct.
2000, Usenix.
[22] A. Niemi, "Session initiation protocol (SIP) extension for event state publication," Internet Draft
draft-ietf-sippublish-
02, Internet Engineering Task Force, Jan. 2004, Work in progress.
[23] Weibin Zhao and Henning Schulzrinne, "Dotslash: A scalable and efficient rescue system for handling web
hotspots," Tech. Rep. CUCS-007-04, Department of Computer Science, Columbia University, New York, New
York, Feb. 2004.
[24] Weibin Zhao, Henning Schulzrinne, and Erik Guttman, "Mesh-enhanced service location protocol (mslp)," RFC
3528, Internet Engineering Task Force, Apr. 2003.
[25] B. Ford, P. Srisuresh, and D. Kegel, "Peer-to-peer communication across middleboxes," Internet Draft draftford-
midcom-p2p-01, Internet Engineering Task Force, Oct. 2003, Work in progress.
[26] John Kubiatowicz, David Bindel, Yan Chen, Patrick Eaton, Dennis Geels, Ramakrishna Gummadi, Sean Rhea,
and Hakim Weatherspoon, "Oceanstore: An extremely wide-area storage system," technical report UCB//CSD-
00-1102, U.C. Berkeley, CA, USA, May 1999.
[27] Alan Mislove, Ansley Post, Charles Reis, Paul Willmann, Peter Druschel, Dan Wallach, Xavier Bonnaire, Pierre
Sens, Jean-Michel Busca, and Luciana Arantes-Benzerra, "Post: A secure, resilient, cooperative messaging
system," in HotOS IX: The 9th workshop on hot topics in operating systems, Lihue, Hawaii, USA, May, USENIX.
[28] Jonathan Lennox and Henning Schulzrinne, "A protocol for reliable decentralized conferencing," in ACM
NOSSDAV 2003, June 2003.
[29] Miguel Castro, Michael B. Jones, Anne-Marie Kermarrec, Antony Rowstron, Marvin Theimer, Helen Wang,
and Alec Wolman, "An evaluation of scalable application-level multicast built using peer-to-peer overlays," in
Proceedings of the Conference on Computer Communications (IEEE Infocom), Mar. 2003.