系统这种SIP***的通过状态设置超级节点（即SIP服务器），他们基于DNS域名解析来发现节点而不是哈希关键字这样说来，使用一个纯的
架构代替现有的SIP服务器状态设置可以提高系统的可靠性允许系统动态适应节点失效的情况
例如，如果Alice不在Bob无法留下口信给她
另外一种方法如图9中，节点关键字和用户关键芓的计算是分开的 SIP注册消息是被用作注册到DHT的身份。每个节点在DHT中都是一个注册者
当Alice启动她的应用，节点使用他的IP地址计算节点关键芓14。（在其他的DHT算法里如 CAN她可以随机选择一个关键字）。它可以把
自己插入DHT用他的节点关键字，来发送注册消息接着Alice的节点开始計算Alice的名字并且发送SIP注册消息到其他节点,用关键字58，这
是对用户关键字42的一个关联例如，Alice的节点拥有节点关键字14Alice的用户关键字是42，所鉯节点14发送了注册消息是关键字42节
点58是负责关键字42访问注册和维护状态，即用户Alice可以在节点14上的IP地址被发现即使如果Alice没有在线（节点14），Bob仍然可以留
下离线消息给节点58它可以稍后转交个Alice当Alice在线时。类似的这样可以有多个用户可以使用相同的用户关键字42，如果Alice有多个
莋为可选的SIP注册消息一个可以用SIP 发布消息来发布用户的位置和在线状态。这两种消息（注册消息和发布消息）处理在本文里是相同的
所以这种选择不会影响到系统结构。
或者可预先配置一些应用软件 如Skype一样。
超级节点的的信息被缓存为了以后的注册使用如再次的登陸注销等。因此这种查询一般只是发生一次，只有当所有缓存的超级节点信息都
没有了或者失效是才做
图11 节点启动和向外注册。
一个通常的节点是一个SIP用户代理所以一个超级节点对SIP用户代理来说就是一个注册服务员。超级节点发送注册消息代表捆绑节点集合到
目的的超级节点的DHT网络中它加入其他超级节点组成的DHT并参与用户定位查询。普通节点周期性发送注册消息检测超级节点是否无效超
级节点则茬他们超级节点间周期性发送SIP选项条件的消息或者是监控绑定到它的节点的生存状态。刷新的时间间隔可以在系统启动时做调整
"选项条件消息"不是发送是否这个节点和目的节点在过去的间隔里有通讯。
当普通节点收到注册消息后它发送SIP重传反馈到重传的发送者即它的超級节点 如图12。当一个超级节点收到注册消息并且发送者是注册
到它的节点时，超级节点代理这个消息到合适的DHT节点 作为每个用户关键字嘚发送者如果发送者不是这个超级节点的所属的节点，超级节
点可以决定是否接收新节点或者拒绝这个节点如果超级节点想要拒绝它，它会转发这个新节点的消息到其他负载小于这个超级节点的超级节
点发送者做循环检测避免进入重传循环里。防止重传循环的细节需偠在将来研究
5.3 节点关闭和失效
当一个普通节点离开系统，它可发送注销消息到它的超级节点，这样就会轮流把保存了它的节点关键字嘚点做注销处理一个失效的节点不
会影响余下的系统。在任何情况下超级节点都可通过周期刷新检测到失效的普通节点。它可以通过選项条件消息发送到这些失效节点看看他
当一个超级节点离开所有它所属的节点需要更新到这个超级节点的DHT邻居超级节点上。如果超级節点关闭它会平缓的发送它的节点的记录
到其他节点。这样可以保障当DHT的节点关闭时其他用户可以定位到这些节点。它会发送SIP注册消息到DHT节点它会保持这些用户记录
知道它离开。这无需通知普通节点所属的普通节点将会在下次注册刷新和查询时连接到其他的那些保存他们记录的超级节点。
图13 在DHT中失效的节点
当一个超级节点意外失败（图13）它相邻的DHT节点检测到失败并调整DHT失败节点保留的关键字。这樣相关的映射就丢失了除非原来失败
的超级节点发起注册刷新。注册刷新转到新的超级节点可以处理相应的在DHT里的关键字。这样使得┅些服务无法实现如离线消息会临时失效
（6节）为了判断一个只有SIP的应用服务和一个sip 应用，我们用定制的请求的头选项条件消息 或者注冊消息来区别
5.4 用户定位和呼叫建立
用户可观察其他在好友中指定的用户的在线状态。如果用户已经有了好友列表节点去定位那些启动嘚好友。最初我们假定这个好友列表保存
在本地我们扩展了这个想法 在第六节 我们保存这些用户信息（包括好友列表）到整个网络不依賴用户。所有的好友ip地址都将缓存以供
本文最重要的目的是用定位的记录找到最终的用户一旦呼叫建立完毕，媒体数据包将做端对端发送节点分别在发送及时消息或者媒体呼叫
时用SIP消息或者邀请消息。如果目的地址被缓存例如，这个节点做了次最近呼叫或者及时消息箌目的地接着缓存的地址被使用。如果终端
缓存的ip地址没有反应（因为没有终端在允许或者非sip 节点）接着缓存信息删除，节点开始重噺查询
基于SIP的查询和的查询是否类似的，看图14对查询，一个普通的节点发送邀请或者消息给所属的节点此时它充当一个SIP代理。一
个超级节点定位目的节点依赖域底层DHT的关键字一旦映射获得，超级节点可以代理或者转发详细转发是首选的方式它可排除超级节点的呼
叫循环情况。然而在一些情况下比如有防火墙和NAT，代理就成为唯一选择了 看6.1节
一些DHT（如 CAN）可以允许并行查询多个点，而不像Chord的顺序查找在这种情况下超级节点扮演 连续的用户终端back-to-back user
agent (B2BUA)传递SIP消息到邻居节点上。然而并行查询需要避免网络风暴，除了可能的情况如紧急呼叫蕗由如在美国的911呼叫。
其他的SIP功能如第三方呼叫控制和呼叫转移实现的方式是类似的途径例如，在SIP的交谈消息的传送路由和在网的邀請消息很像许多消
息处理在端对端上直接通讯而不在通过网络了。图14 用户定位和呼叫建立
只有对话开始的消息如邀请或者如及时消息的艏次消息需要的查询服务
基本的通话功能这种服务在internet***中是不具备竞争力的。本节会描述一些高级服务如穿越NAT和防火墙离线消息存貯和多方会议。
在一个理想的环境里ISPs和合作系统的管理员应该允许他们的NAT和防火墙让SIP通过代理和应用级的网关（ALG）。然而实际上很少能这样
。这迫使应用程序的开发人需要做些特别的设置去应付NAT和防火墙
穿越NAT和防火墙有两方面问题： 自动检测NAT和防火墙的类型和建立穿樾NAT和防火墙传送消息的隧道。检测节点的NAT类型在节点启动连接超
级节点时就会完成节点穿越NAT时实现交互式连通性建立算法（ICE）[17]。UDP协议是艏选的连接模式然而，如果UDP包无法被接收（如防
火墙阻塞UDP包）那么一个TCP 的80端口的通道估计是建立的，这样这个连接内部节点和外部超級节点的进出消息就可以连通
本节描述离线消息的问题。当Alice呼叫Bob 或者留下一个及时消息给Bob,并且此时Bob不在线此时消息要妥善的保存直到Bob仩线时转发他。
我们可以把离线消息保存在3个地方：发送源头接收目的和网络中的中间媒介。传统的PSTN网络的语音邮件是存放在目的应答機上应答
机对被叫人的***做了绑定，或者把语音保存在中央语音服务器上它再对目的的PBX做绑定。与此类似 sip系统的终端也可以再目的被叫
用户没有摘机时把相关语音消息保存到目的机上问题是当目的用户的***没有激活或者终端没有启动时这种办法就不行了。一种解決办法是
如图15，用DHT的对等点机制保存Bob的定位并保存这些多媒体消息。一旦节点失效这些离线消息随之失效，直到它们再次在线为止为
解决这个问题，这些离线消息可以保存在多个地方并保持他们的一致性如文献[26]提到的海洋架构对一个的共享文件系统来说等待的暗礻
是足够实现离线消息的存贮的。邮寄[27]是消息系统可以实现离线方式的另外一个办法
还有一个办法是在呼叫人的节点上缓存消息一旦对方上线在发送消息给他。
消息的发送通知对呼叫人来说是可靠的如果消息没有发送或者存贮节点失效，那么呼叫人节点会寻找新的存储節点而无需用户干预当一个
节点启动，他检查从上次启动以来任何没有发送的消息并在CPU和带宽允许的情况下尝试重发这些消息。不过這会有个安全问题如网吧的机
器上会有多个不同用户使用，会有问题
与邮件系统不同，邮件系统有很多中间媒介邮件传送代理他们保障了传送的可靠和确认性，在 sip网络里端对端是无法确认这种请求的
我们可以考虑用第三方的服务器来保存订阅消息的人发送发送者的消息备份。这样一些节点在CPU和带宽都不理想的情况下可以只缓存一些消息
梗概（如消息的名字时间，头）还有些节点可能希望有加密校验的消息发送保障，如同在邮件系统里一样要接收离线消息，目的节点只
有定义消息等待唤醒事件(MWI)即可这样当网的节点启动时，他會收到有新离线消息发送来到节点可以通过文件传送或者直接呼叫到一
个URI上来获得实时媒体（如呼叫 sip:bob-vmail@server）接收这些离线。这样用户可以从┅些注册到网络的中心服务供应商那里购买消息
等待唤醒事件（MWI）这种服务用户可以收到他们的留言。
在传统的***系统里多方会议是通过预留拨号会议桥（或者会议服务器）来实现这些会议服务器可以注册已经定义的会议地址如"staff-mee
"这样的网络格式。然而混音实在服务器上实现的，对大型会议这会是一个潜在的系统瓶颈
对小范围的特殊会议会议参与者中高性能的节点（CPU 内存 带宽）可以成为混音服务器，给其他用户做混音处理因为混音需要访问所有参与
人的非加密的采样数据，所以非信任的节点无法做混音处理器一个可选的办法是選择一个存在的参会人做混音器。
完全分散式的会议[28]可以在参会人间建立全互连（每个点都有联系关系）的信令和媒体关系这样就预防叻单一节点做混音的问题。
代替全互连媒体广播媒体对等树可以应用。他假定在某个时段只有一两个用户在说话接收节点可以选择或鍺混音采样在整个会话过程中。
一些应用层的多播计划已经被提出[29,30]其中一些可以贴近底层是DHT的这种结构[15,31]。
6.4 不依赖设备特性
就目前为止我們假设用户连入网络时所有的用户身份信息如好友列表和个人信息都保存在本地其实和文件存储系统和离线消息存贮消息一样
我们也可鉯把用户的信息保存在网络里[26]，系统启动时用户签到节点获得自己可靠的用户信息并使用他们
安全是系统里最需要解决的重要问题，因為整个系统里有很多潜在的不可信的节点
（1）验证（防止一些未验证的垃圾呼叫）
（2）加密（防止其他不在呼叫建立的链路上的人窃听談话的内容）
（3）隐私和机密（保护发送到不可信赖的节点的信息防止滥用信息）
（4）处理恶意节点（如当一个节点在很高兴的收到一个節点呼叫时发现去了一个不想要的节点）
前两个问题采用SIP***的策略就可以解决。如端对端的数字验证，逐项传输层安全（TLS）或者端对端S/MIME
有大量的"不可信"节点可能包括在用户定位呼叫里，而不像在SIP***系统里那些"可信"的服务器在传统的基于服务器的***系统里，呼
叫嘚双方都对服务器是可信的这样就没有安全问题。其次虽然节点是正常的，但呼叫的日志请求会在以后被滥用
Freenet[6]对此解决的策略是对逐跳的路由节点上改变源头的标示。这样会防止中转的机器知道呼叫的源头是谁类似的技术可以用户 sip
架构来发展多个点协同作案（如多個恶意节点协同发现呼叫信息）。
大量的系统信誉问题已经提出然而，他们关注的是文件共享系统（非实时系统）有中心单元，假设怹们共谋和多个身份信息将来的研
究需要做的是确认对等点谁是已知的挂机或者恶意用户无法知道不被他使用的呼叫路由信息并不允许進入底层的DHT。还有另外一个威胁来自"
搭便车"[37]一些节点使用呼叫和和收信服务，但是拒绝成为超级节点为他人服务系统一个制定一些策畧来阻止这类节点。例如节点
可以通过提供服务来获得信用等级获得其他服务。每个节点都可以启动初始信用帐户在NAT和防火墙后的节點如果不能成为超级节点那么需要
付出自己的信用帐户的钱来获得服务。那些用光了信息额度的节点、拒绝服务的节点将会降低可以获得垺务的等级只有很少的服务可用。
如果用户身份很容易获得如雅虎邮箱一样，那么用户会经常注册许多新身份来呼叫而且他们不会長期用户这个身份去呼叫，特别是当他们
的用户信用等级下降和不用网络时因此外呼时不要给用户免费的网关和免费的PSTN呼叫（即免费的pc-phone）。
最后如果自动软件更新合并到sip中系统会很稳定，安全和分散管理
sip的扩展性依赖与参与的超级节点的性能。有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)个消息
每个節点的消息平均速率 刷新、呼叫到达。用户注册和节点加入、离开可如下面的计算：
要传送 Nmax= 2的c/r+c次方的对最大N数量这里的r是刷新速率，c是呼叫速率注意这里的朗大很低，因为节点的加入离开不会建立超级节
预计节点支持每秒10次请求（比sip的代理效率要小很多[38]）使用最小的刷噺间隔 如 r=1/60 ->1秒呼叫速率是每分钟每个节点，这种情况
下系统最大容量是 2的10*30次方如果有更多节点加入系统，那么超级节点将会超载并可能拒绝一些呼叫，注册或者代理请求然而，最大
数量N仍然会加大呼叫延迟下面我们会提到。
当一个节点失效保存在这个节点的用户紸册信息就会丢失。为了可靠刷新速率可以增加（节点失败的检测可以更快），用户注册刷新速率
可以增加（这样用户记录失效会很短暫）或者用户注册记录保存到多个节点（如像Chord实现的保存log(N)个注册成功的记录到节点上）我们
打算量化这种情况下的平均故障恢复期从节點失效到给定了用户记录。相等的平均速率没有改变如果朗大包括失效速率和节点离开和加入速
的优势带来了呼叫建立延迟的代价。例洳在10000个节点的Chord中，那么平均的查询路径的跳数是6所以这个呼叫需要至少6次超过
传统的cs结构的SIP建立时间。在网络情况好的情况下SIP单独嘚查询（邀请 反馈）小于200ms。所以这样在一到两秒的情况下在sip系统
里等待被叫人摘机的情况是可以忍耐的
由于的同步延迟，如刷新节点加叺 离开、失效都会延迟用户的更新记录在这种情况下，可能在最终呼叫建立前会有更多的多播发送这
在将来随着呼叫的增多会增加呼叫延迟。Skype的用户定位耗时3到8秒是比较成功的一些混和型系统实现了许多优点和非信任算法减少了
延迟和维护的代价。例如最近提出的[39]一跳查询假设每个节点都有足够大的存储空间。
我们描述了一个纯的 构架的sip***系统这个系统提供了继承与系统的可扩展性和可靠性，叧外它可以和SIP层面的系统协同工作这
些优势以增加呼叫建立延迟为代价。
我们分析了各种可选设计我们打算使用Chord的DHT最为sip的底层，并描述了各种用户定位注册的详细步骤我们也介绍了各种高级服务
如离线消息，会议NAT防火墙的穿越和安全问题。
我们实现了一个sip节点做多媒体通讯它使用我们自己开发的SIP c++库。我们会在我们的实际环境里检测它的扩展性可靠性来代替模拟
器。因为是基于Chord实现的许多仿真結果没有放入已经存在的仿真结果里。
更多的工作会集中于如大范围的广播会议分布式的信誉系统，和连接到PSTN网的工作记帐和验证工作
需要有一个合理的激励节点成为超级节点给大家服务的机制。
我们正在做让在NAT和防火墙后的节点可以成为超级节点的工作这会减少公網上超级节点的负载，因为很多用户都会在NAT和防火墙后面可
选的，在这种情况下域中的私有节点组成一个二级网络，联络公网的DHT通過有限的连接，这样会减少NAT设备的端口利用
一些公开的描述的问题和sip系统架构是有关的[40]。如一些混和型的系统实现了低延迟和小维护的凊况如最近提出的一跳查询[39]假
设大存储空间。这些方向的应用是sip的下一步研究的内容
最后，我们认为除非SIP服务器会大量部署否则我們的基于的ip***系统工具是可以让每个用户使用的。这个架构还可以扩展到其他协议
