- 论坛徽章:
- 0
|
基于p2p的sip电话系统
版权声明
：转载时请以超链接形式标明文章原始出处和作者信息及
本声明
http://dolfcao.blogbus.com/logs/4086671.html
文章来源:
http://blog.csdn.net/lengxingfei/archive/2006/01/18/583227.aspx
摘要
p2p系统天生拥有高扩展性、健壮性和高容错性的特点，这些特点得益于系统没有中央服务器并且网络是自己管理的这种结构。本系统实现了在
p2p系统中较长的延迟的代价下定位感兴趣的资源。internet 话可以被看作一个p2p架构的应用，它在一部分和另外一部分定位和通讯时在p2p
这种自组网上实现。我们的目的是构建一个基于SIP信令的纯p2p架构的ip电话系统。 我们的p2psip架构支持基本的用户注册和呼叫建立，也提
供高级的服务 如：发送离线消息、声音/图像邮件 多方通话。同时我们提供一个可以实际操作的穿越防火墙NAT和安全性的p2psip。
（关键字 系统设计 点对点 高可靠性 扩展性 internet电话 SIP）
Peer-to-Peer Internet Telephony using SIP
原作者：Kundan Singh and Henning Schulzrinne
Department of Computer Science, Columbia University
fkns10,hgsg@cs.columbia.edu
译者 汪亮宇
wlywly@sina.com
翻译后没有做校验 有些地方不通顺 。
基于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服务器保存了
bob@home.com
和他的注册ip地址间的映射关系。当其他用户如，Alice发起呼叫或者发送及时消
息给
bob@home.com
到服务器的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展示的，当用户启动它的终端应用并显示"屏幕名字"是
alice@office.com
，节点计算名字变为DHT关键字（用SHA1实现的哈希关键字编码，如Chord实现的）通过这个用户名字关键字把它当作节点关
键字。本例子里Alice的关键字是42，对Alice说，和Bob通话，需要定位Alice，Bob的节点使用相同的哈希函数去计算相同的42 ，对应Alice，
并且在对等哈希表里调用find(42)找Alice。DHT的算法定位了节点42，这样Bob的应用程序可以和Alice的程序对话。
12
42
24
bob@home.com=12
alice@office.com=42
sam@work.org=24
Figure 8: No REGISTER
REGISTER
alice@office.com=42
REGISTER
bob@home.com=12
24
56
42
12
58
32
14
Figure 9: With REGISTER
这个方案无法支持离线消息或者多个用户用相关的SIP用户身份注册的情况，sip:alice@home.com
例如，如果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的方式去查找用户。当节点启动时，用户输入它的身份 如
alice@example.com
，节点找到可能的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:alice@home.com。请求的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
t@columbia.edu
"这样的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.
本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u1/43391/showart_494415.html |
|
免费注册
发表于 2008-03-12 12:32
