图1与DHT中超级结点相连的普通结点
图2 P2P-SIP结点中的块算法 图2给出了P2P-SIP结点中不同部件的算法。结点启动和用户用标识符登记时,发现模块被激活用于初始化网络地址翻译和防火墙探测[8],点发现和SIP注册。组播SIP注册、上一引导周期存储的端地址和预配置的自举地址被用来初始化结点集。用户界面模块记录用户的“朋友列表”并调用用户定位 模块定位这些朋友。用户定位模块使用SIP模块,或者,如果这个结点加入了DHT就使用DHT模块。DHT模块维护端信息(例如,Chord指针表)并执行像发现、加入和离开的一些DHT操作。 SIP被用作是定位其他用户或结点、加入DHT、注册用户、呼叫建立和即时消息的基础协议。一旦用户被定位,呼叫建立或即时消息就可以直接经由SIP模块发送到用户的电话。SIP REGISTER更新和OPTIONS消息用于探测结点失败。当一个超级结点关闭或者失败,注册被发送到DHT中的其他适当的超级结点。其他的SIP功能例如第三方呼叫控制和呼叫传输可以用相同的方法实现。媒介路径(音频设备,编解码器和传输)独立于P2P-SIP操作。 一些分布式哈希表允许对多端点并行搜索,不像Chord中的顺序搜索。在这种情况下超级结点可以担当背靠背用户代理并向邻居端点传播SIP消息。然而,除非是像美国的911这种紧急呼叫路由的情况,应该避免并行搜索以免网络中发生泛洪。 在实际的实施中允许多种P2P-SIP网络(分布式哈希表)相互连接是非常有用的。我们的混合结构允许P2P-SIP网络群和基于服务器的SIP结构共存。有两种方法:将一个网络中所有的用户与所有其他网络交互注册或者在呼叫建立的过程中在其余的网络中定位用户。前一种方法工作在少量的已知的P2P-SIP网络。后一种方法可以使用一个像DNS这样的全局命名服务器或层次化的P2P-SIP网络实现。第一种情况,每一个P2P-SIP网络用一个域名表示。这与基于服务器的SIP网络是没有区别的,域名在那个网络中解析一个或多个自举结点[4]。第二种情况,用P2P-SIP代替DNS来解析域名。例如,单独的大的组织可以有本地P2P-SIP网络与全局(公共)P2P-SIP网络连接,如图3所示。本地特定域的DHT有典型的服务结点,这些结点在全局DHT中也是可达的。例如, private.com在全局DHT中映射到结点A和C。特定域DHT中的任何结点可以到达全局DHT,全局DHT中的任何结点可以经由域中的典型服务结点到达特定域DHT。 图3 混合系统举例 混合结构允许用户在她的提供者可用的情况下用她的提供者注册,也可以用P2P-SIP网络。呼叫建立在可以用DNS解析时被发送到SIP目的地,同样也可以用P2P-SIP网络。3 设计和实现3.1命名 结点和用户标识符是用SIP通用资源标志符(URI)表示的。例如,如果一个结点在传输地址192.1.2.3:8054上监听SIP消息并且Chord的哈希函数给出的键值是17,结点的URI就是sip:17@192.1.2.3:8054。域example.com中的一个不知道传输地址的结点标识符或键值(例如10)表示为sip:10@example.com。每一个局部的P2P-SIP网络用一个DNS域名表示,example.invalid用于没有域的键,例如全局DHT中的键。这样的结点标识符对于DHT的维护是有用的,例如,查询另外一个结点的传输地址来成为这个结点的指针表的入口。 用户标识符可以由系统随机分配,或由用户选择一个鉴定名(如,alice172@sippeer.net)或者用户选择她的有效email地址(如alice@example.com)。前两种方法允许用户选择密码,但是不清楚P2P结点怎样从用户那里得到密码。我们使用最后一种方法,因为它允许系统产生一个随机密码并email给用户用作验证。前两种方法,如果密码由系统随机产生并且SIP REGISTER请求消息的连接头里有email地址,密码可以发给用户。3.2认证 当一个用户第一次登陆P2P-SIP网络时,我们需要验证用户的标识符是有效的并且确实属于该用户。没有公共密钥结构(PKI),系统可以产生一个新的密码并用email发送给用户。这个密码在后来的拨入当中用于注册验证。可以使用一个可用的生存时间,比如一个月。当用户随后再登陆时这些信息被刷新。3.3 SIP消息 SIP REGISTER消息被结点既用于用户注册也用于DHT的维护。用户注册消息类似于基于服务器的注册,To头表示用户标识符,Contact头表示用户的联系位置。结点将SIP REGISTER消息用于两种情况:查询和更新。如果消息中有Contact头,则是更新请求表示发送者想更新To头中用户标识符的绑定;否则就是一个查询请求,发送者请求获得To头中用户标识符的Contact信息;在一个P2P-SIP结点的Chord网络中结点的Contact信息包括它自己的传输地址,后继结点地址和前导结点地址。3.4 DHT发现和加入 结点发送SIP REGISTER消息使用sip:224.0.1.75(SIP REGISTER组播IPv4地址)作为请求URI ,To头作为本地结点标识符来发现本地网络中的其他P2P-SIP端点。也可以使用像服务定位协议(SLP)和预配置的自举结点地址这样的额外机制。结点存储发现的端点地址列表用于以后的重新启动。 一旦结点发现一个端点,它通过发送一个以To头作为此结点标识符的SIP REGISTER查询给那个端点加入DHT。成功的应答包括现存的DHT中的此结点的后继和前导,结点可以用来更新它的Chord数据结构。 结点一旦知道它在Chord环里的邻居,就向它们(后继和前导)发送SIP REGISTER更新,这样就可以更新它们的数据结构。 Chord的稳定性是通过周期性的发送SIP REGISTER消息更新后继和前导的数据结构以及查询指针表入口以校验本地数据结构来实现的。3.5 SIP消息路由 Chord里的每个结点对基于它在Chord环里的位置的键空间的一个子集负责。当结点收到一个SIP请求,它提取出目标键作为REGISTER请求的To头URI和其他任何请求的请求URI。对REGISTER请求,如果目的键值属于这个结点的键空间,则这个结点应该是目的键的登记者。如果这个键的用户记录存在,则发送一个成功的应答,否则就发送一个失败的应答。成功的应答包含用户的连接位置或结点联系(本地传输地址,后继和前导地址)分别用于用户或结点注册。如果结点收到一个非REGISTER请求,它为目标用户提供代理或将请求重定向到可用的用户连接位置。如果目标键值不属于这个结点的键空间,则请求被代理到基于Chord算法和数据结构的下一跳结点。3.6可靠性 Chord通过存储㏒(N)个后继地址以及在K(常量)个成功的后继结点中复制键来提供结点失败时的可靠性。在P2P-SIP中,结点更新应答包含所有㏒(N)后继地址,并且用户注册信息被复制到K个后继结点中。 当一个结点有序地离开网络时,它会注销它的后继和前导以便他们可以更新Chord数据结构。并把所有的注册转移到它的后继。当一个结点异常地失败时,它的后继和前导发现这个失败并且更新他们的数据结构。算法的稳定性保证了信息能够在一段时间内传播到Chord中的其他相应的结点。注册信息由结点A传到结点B,如果结点B信任结点A就可以鉴定结点A,否则结点B重新生成一个密码并发送给用户的email地址。一旦我们拥有一个P2P名誉系统,DHT中将只存在可信任的结点。如果注册结点是恶意的则问题仍然存在,而且可能造成拒绝服务攻击(DoS)。存储用户注册信息的P2P-SIP结点也代理到那个用户的呼叫请求。一旦呼叫建立完成,呼叫路径中就不再需要P2P-SIP结点。3.7现存SIP电话的适配器 一个SIP用户代理商可以将P2P-SIP结点当作是输出代理参与P2P-SIP网络。用各种各样的SIP用户代理商,例如哥伦比亚大学的sipc、思科IP phone 7960、Pingtel IP phone、Xten Network的X-Lite client v2.0和Microsoft Windows Messenger,测试了P2P-SIP适配器SIPPEER。 一些电话不像SIP规范[1]中说的输出代理应该被当作预装载的路由集那样执行输出代理。实际上,如果输出代理不记录路由最初的INVITE请求,则后来的对话中的请求(例BYE)不应该发送给代理。假定sipc用户alice@example.com 使用P2P-SIP邀请思科phone用户bob@example.com。呼叫后,bob挂断。思科phone发送BYE请求给输出代理(P2P-SIP结点)但是请求URI包含alice@pc2.examole:5060。因为这个URI可能没有在P2P-SIP网络中注册,P2P-SIP结点可能不能代理请求,这将引起DHT查找失败。在SIPPEER中通过在这种情况下代理请求到请求URI代替DHT查找来解决这个问题。4 结束语 我们提出了纯P2P结构的SIP电话。除了与现存的SIP结构的互操作性,这个结构还提供了可靠性和P2P系统固有的扩展性。今后还需要在像使用P2P的大规模应用层组播会议这样的高级服务方面以及像认证和计费之类的与PSTN协同工作的相关因素方面做更多的研究。参考文献:[1] J. Rosenberg, H. 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.[2] www.hpl.hp.com/techreports/2002/HPL-2002-57.html.[3] I. Stoica, R. Morris, D. Karger, F. Kaashoek, and H. Balakrishnan. Chord: A scalable peer-to-peer lookup service for internet applications. In SIGCOMM, San Diego,CA, USA, Aug 2001.[4] J. Rosenberg and H. Schulzrinne. Session initiation protocol(SIP): locating SIP servers. RFC 3263, Internet Engineering Task Force, June 2002.[5] www.cs.columbia.edu/ ˜kns10/publication/sip-p2pdesign.pdf.[6] www.ietf.org/html.charters/zeroconf-charter.html.[7] www.skype.com.[8] J. 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.[9] K. Singh and H. Schulzrinne. Peer-to-peer Internet telephony using SIP. Technical Report CUCS-044-04, Department of Computer Science, Columbia University, New York, NY,Oct. 2004.[10] www.research.earthlink.net/p2p/.[11] www.ctiforum.com/technology/Voip/2005/06/voip0644.htm