P2P-SIP轻松实现多媒体会话

SIP协议凭借其简单、易于扩展、便于实现等诸多优点越来越得到业界的青睐，它正逐步成为NGN（下一代网络）和3G多媒体子系统域中的重要协议，本文针对SIP服务在部署中出现的“单点失效”和“性能瓶颈”等问题给出了详细的解决方案。

针对SIP服务在部署中出现的“单点失效”和“性能瓶颈”问题，提出了基于P2P技术的SIP服务网络的结构。这种结构利用现有SIP设施，只做部分升级就能提供非常优越的性能。文中给出了实现方案并重点分析了P2P-SIP网络处理注册和呼叫的流程。并介绍了P2P技术、Chord协议和互联网工程任务组IETF在P2P-SIP方面的研究进展。

SIP服务现状

SIP （Session Initiation Protocol，会话初始化协议）是在Internet节点间建立多媒体会话的控制信令，由IETF制定。SIP协议简单、可扩展性强，被很多互联网电话业务采用，成为VoIP的两大协议之一。VoIP是下一代互联网（NGN）的重要组成部分，因为可以提供更丰富的业务和更低廉的通话费用，最近几年发展迅猛。据iResearch 整理的资料显示，2004年全球VoIP 服务市场规模已经达到35 亿美元，在未来两年仍将呈现高速增长的趋势，预计2008年市场规模将达到210 亿美元。

在用户高速增长的同时，现有的SIP服务器也普遍反映出一些不足：“单点失效”和“性能瓶颈”问题。SIP按域划分用户（比如ccw.com.cn就是一个域，而就是该域内提供网页浏览的一台www服务器），每个域有一台SIP服务器，用户连上本域的服务器。如果用户所在域的服务器宕机，用户就不能使用SIP服务。这就是所谓的“单点失效”问题。当某个域内的用户数目庞大时，单台服务器就会性能不足。如果使用多台服务器，为维护服务器之间的一致性又会增加配置的复杂性和增大性能损耗，性能提升十分有限。这就是所谓的“性能瓶颈”问题。

Skype使用P2P（Point to Point，点对点）机制解决了这两个问题。Skype网络把节点分为超级和普通两种。超级节点通过P2P机制互联，为普通节点提供注册服务。当超级节点失效时，它所管理的普通节点会注册到其他超级节点上，避免了“单点失效”。当网络处理能力不够时，部分普通节点会转换成超级节点以增大网络容量，打破了“性能瓶颈”。靠这种结构，Skype做到了全球注册用户超过1亿，同时在线人数突破700万。可惜Skype使用私有协议，无法接入市场上大量的VoIP设备。

Skype的成功，使得IETF开始借鉴P2P的机制来提升SIP。威廉玛丽学院的David A. Brayn就提出了扩展SIP的Register请求，将其用做P2P的信令。P2P的优点是没有中心服务器，节点间分担负载。没有中心服务器，就不会“单点失效”；节点间分担负载，增加节点就能迅速增大系统容量。而且在P2P中，增加节点的操作几乎是“零配置”的。

P2P-SIP网络的结构

在IETF的设想中，每个SIP节点同时也是P2P节点。节点间地位平等，没有普通节点和超级节点的差别。这种设计要求现有SIP设备做重大改动，而且无法将SIP服务做商业化运营。而本文的设计充分考虑到SIP服务的商业化和电信级运营，不需要改动现有VoIP终端设备，只对现有SIP服务器的软件做改动，而且改动很小。为区别于传统的SIP服务器，本文把P2P化的SIP服务器叫做P2P-SIP Node，简称PN。具体的网络结构如图1所示。

在P2P-SIP网络中，原来管理一个域的单台服务器变成多台PN，PN之间通过P2P机制互联，彼此分担负载。PN可以承担原来服务中压力最大的部分，比如注册、代理和计费。用户连接到任一PN，都可以有效使用服务。部分PN下线或故障不会影响到P2P-SIP网络的正常运行。要扩大P2P-SIP网络的容量，加入新的PN就可以了。

PN在地理上散布各处，逻辑上根据选用的P2P机制的不同可以是环形的（Chord协议）、矩阵的（CAN协议）、网状的（Pastry协议和Tapestry协议）。基本的PN至少包括注册和代理两种功能。为进行商业运营，可以部署全局认证服务器、全局账务服务器和网管服务器等等，用于管理全部的用户和所有的PN。

新的服务比如语音和视频会议、语音邮箱、PSTN落地（即呼叫座机和手机）、自动和人工语音应答可以部署在PN上，也可以作为单台服务器或服务器网络的形式接入P2P-SIP网络。

P2P-SIP网络的实现

1. PN的结构

PN分为两层。上面是SIP层，处理标准的SIP信令；下面是P2P层，使用特定的机制（本文的设计选用Chord协议）互联各个PN的P2P层并维持它们之间的联系。P2P层提供给SIP层的应用程序编程接口（API）只有函数find_responsible_pn(user)，该函数返回负责管理该user的PN的IP地址和端口。由于P2P-SIP网络是动态的，所以负责管理某个用户的PN在不同时段可能是不同的。

首先讲一讲Chord基础知识，Chord是结构化的overlay。所谓overlay，是指P2P系统在物理连接的基础上构建的逻辑网络。而结构化的overlay，是指在overlay中，特定的资源由特定的节点管理；当查询该资源时，根据某种路由规则，找到管理该资源的特定节点。Chord使用SHA-1哈希算法，哈希值为m个比特。共有2m个可能值分布在圆周上，称做Chord环，如图2所示。

图中N表示节点，N后的数字是该节点的哈希值，一般通过哈希节点的IP地址得到。K表示资源，K后的数字是该资源的哈希值。Chord用在SIP中时，K应该是SIP URI，例如sip:humingchunno1@163.com。在Chord中，每个节点都负责管理一段哈希空间——顺时针方向上之前一个节点到自己的范围，哈希值落在该空间中的资源K的信息由本节点保存。例如节点N32就负责管理资源K24和K30的信息（图2中指向N32的实线箭头所示）。

当某个节点比如N8要询问资源K30的信息时，N8首先要找到负责管理K30的节点N32。最简单的做法是N8询问顺时针方向上自己后面的那个节点，称做N8的successor，即N14。如果N14不负责K30，则N14询问自己的successor，即N21。该操作反复进行，直至找到负责K30的节点N32为止。

这种查询机制只要求节点知道顺时针方向上自己后面那个节点的位置（自己的successor），查询效率低，花费的平均时间是函数O(N/2)的值，N是Chord环的实际节点数。为提高查询效率，Chord中每个节点除了记录successor和predecessor（顺时针方向上自己前面的那个节点)外，还要记录m个其他节点。这m个节点由successor(n+2i-1)确定，其中n是本节点的哈希值，i是1到m间的整数。m个节点的集合就是finger表（图2中给出N8的finger表）。这种方式下查询资源花费的平均时间为O(logN)。

新节点，例如图2中的N26，要加入Chord环时，先询问自己知道的Chord中任一节点，假定为N8。N8通过查询，发现N26的successor是N32，告知N26。N26得知后把successor设为N32，并通告N32自己的存在。N32得知后把predecessor设为N26，并把K24交由N26管理。N26则完成加入。

Chord中每个节点都要周期性地更新自己的successor、predecessor和finger表，以保证快速正确的查询。理论的计算和实际的模拟显示，Chord的容错性很强，当网络中50%的节点故障时，查询失败的机率也只有1.3%。

2. P2P-SIP网络的形成和维护

在PN的配置文件中应该有一个配置项，其值是“IP地址:端口”或“域名：端口”的形式。存在多个值时，之间用空格分开。其值也可以为空，表示本PN是P2P-SIP网络的第一个节点。值格式错误时，忽略该值。

PN启动时，如果发现配置项的值为空，PN的Chord层就新建一个Chord环。如果配置项存在一个或多个值，Chord层就依次向这些值发请求直至收到成功应答。如果最终没有收到成功应答，就提示错误或者新建一个Chord环。PN进入P2P-SIP网络后，即PN的Chord层加入到Chord环中，需要从其successor处拷贝一份用户注册信息。

PN正常退出P2P-SIP网络时，需要将自己管理的用户注册信息发给自己的successor。非正常退出时，P2P-SIP网络会暂时丢失部分用户的注册信息。为保证注册过的用户始终可达，可以让PN周期性地将它管理的用户注册信息通告自己的successor，甚至successor的successor。

P2P-SIP网络的维护是PN的Chord层来做的。每个PN的Chord层都周期性地更新自己的successor、predecessor和finger表，从而及时地了解网络的变化。

3. 请求处理过程

按照RFC3261的规定，SIP服务器（主要指代理服务器）处理请求时与请求的方法无关。我们将SIP服务器改造成PN时增加的步骤也应该是与方法无关的。下面我们通过详细描述用户的注册和呼叫，来展示P2P-SIP网络中PN处理请求的过程，并表明增加的步骤与方法无关。

用户注册过程

对用户而言，注册到P2P-SIP网络的过程和注册到SIP网络的过程是相同的。只是在P2P-SIP网络中，PN收到注册请求时，并不立即记录该条注册信息，而是先调用函数find_responsible_pn(user)。如果返回的地址是PN自己，这才记录下用户注册信息；如果返回的地址是其他PN，则PN会把注册请求转发给相应的PN。最终，注册请求会被转发到负责处理它的PN处，处理后产生的应答按原路返回。

考虑到减轻PN转发请求和记录事务状态的负担，PN收到不该自己负责的注册请求时，可以返回301 Moved Permanently应答。而把调用find_responsible_pn(user)得到的地址放在应答的Contact头域中,具体的注册过程如图3所示。

第1步：终端发注册请求

IP地址为192.168.13.63的SIP终端准备好REGISTER请求，发给P2P-SIP网络中任一PN（比如Key为69的PN。在P2P-SIP中，Key值是通过哈希节点的IP地址和端口得到的）。如图3中M1所示。

SIP终端可以通过多种方式获得PN的IP地址和端口。比如用户手动指定，或者使用终端默认的PN，或者使用终端上次进入P2P-SIP网络时更新的PN列表。

第2步：PN转发请求

Key值为69的PN收到REGISTER请求后，取得请求中To头域里的SIP URI——表示注册的信息属于哪个用户，调用find_responsible_pn(user)。返回值应该是“IP地址∶端口”字符串的形式。将返回值同本机“IP地址∶端口”作比较，如果相同，说明本机负责处理该请求，之后的处理流程遵循SIP标准；如果不同，就转发REGISTER请求到该“IP地址∶端口”。

在本例中，SIP URI是，假定其哈希值是17，PN的Chord层会查找到负责处理该请求的PN Key值是32，find_responsible_pn(user)返回该PN的“IP地址∶端口”——192.168.13.110:5060。PN的SIP层比较该值发现不是自己，就将注册请求转发到该“IP地址∶端口”，如图3中M2所示。

第3步：PN接受注册，返回应答

Key值为32的PN收到REGISTER请求后，取得请求中To头域里的SIP URI，调用find_responsible_pn(user)。返回值是192.168.13.110:5060，比较后发现是自己，说明自己负责管理该用户，负责处理该用户的注册请求。之后的处理流程遵循SIP标准。假定注册成功，PN返回200 OK应答。如图3中M3所示。应答的返回遵循SIP标准，根据Via头域按原路返回，不需要查找路径，不会使用Chord层的操作。

第4步：SIP终端收到应答，完成注册

Key值为69的PN收到来自192.168.13.110的应答，按照SIP标准处理，把应答发给192.168.13.63:5060。如图3中M4所示。SIP终端收到200 OK应答，完成注册。
用户呼叫过程

对用户而言，在P2P-SIP网络中发起呼叫与在SIP网络中发起呼叫相比没什么不同。构造标准的INVITE请求，发给自己连接的PN（SIP服务器），然后等待应答。

在P2P-SIP网络中，PN收到INVITE请求，进行必要处理后，取出请求中To头域里的SIP URI（表示呼叫哪个用户），调用find_responsible_pn(user)。如果返回值是PN自己，说明PN负责管理To头域所标识的用户，PN具有该用户的注册信息，之后的处理按SIP标准流程; 如果不是，则PN将INVITE请求转发给find_responsible_pn(user)返回的“IP地址：端口”，具体的呼叫过程如图4所示。

第1步：主叫发起呼叫
IP地址为192.168.13.26的用户要呼叫用户。alice可以把请求发给P2P-SIP网络中任一PN。考虑到要在P2P-SIP网络上提供增值业务（比如计费），alice把INVITE请求发给管理它的PN更合适一点，在本例中是IP为192.168.13.203，Key值为0的PN。如图4中M1所示。

第2步：PN转发请求到PN
Key值为0的PN收到INVITE请求后，取得请求中To头域里的SIP URI，调用find_responsible_pn(user)。返回值是192.168.13.110:5060。比较后发现不是自己，将请求转发给192.168.13.110:5060。如图4中M2所示。

第3步：PN转发请求到被叫
IP地址为192.168.13.110的PN收到该请求，进行相同的处理。发现返回值是自己，说明PN管理该用户，拥有该用户的注册请求。之后的处理流程遵循SIP标准，即在本地取得用户michael的当前地址，然后转发请求到该地址。如图4中M3所示。

第4步：被叫接受呼叫，返回应答
用户michael所在的SIP终端收到该请求，按照SIP标准进行处理。假定michael接受呼叫请求，则返回200 OK应答。如图4中M4所示。

第5步：应答沿原路返回
应答的返回遵循SIP标准，根据Via头域按原路返回，不需要查找路径，不会使用Chord层的操作。如图4中M5、M6所示。

第6步：主叫收到应答，发出确认，建立呼叫

用户alice所在的SIP终端收到200 OK应答，用ACK请求进行确认。ACK请求不经过P2P-SIP网络，直接发给用户michael所在的SIP终端。如图4中M7所示。用户michael所在的SIP终端收到ACK确认请求，呼叫建立。结束通话时，michael和alice直接交换SIP信令，不经过P2P-SIP网络。
按照本文所述的设计和实现方案，对原有的SIP软交换平台进行改造，在PN上实现了注册、呼叫和计费功能。原来的语音邮箱和自动应答功能作为单台媒体服务器接入P2P-SIP网络，在P2P-SIP网络内提供全局的用户认证、拨号策略、账务系统和网管服务。

基本的测试显示，5台处理能力为72万次/小时BHCA（中文叫忙时试呼次数，是电信领域用来衡量服务器处理能力的重要指标，注册用户数在电信领域指的就是座机的数目）的普通PC机组成P2P-SIP网络后其BHCA可以达到288万次/小时，支持的注册用户数达48万。

链接：SIP协议介绍

会话发起协议SIP(Session Initiation Protocol)是IETF制定的多媒体通信系统框架协议之一，它是一个基于文本的应用层控制协议，独立于底层协议，用于建立、修改和终止IP网上的双方或多方多媒体会话。SIP协议借鉴了HTTP、SMTP等协议，支持代理、重定向、登记定位用户等功能。支持用户移动，与RTP/RTCP、SDP、 RTSP、DNS等协议配合。支持Voice、Video、Data、Email、Presence、IM、Chat、Game等。

正如其名字所隐含的，SIP用于发起会话，它能控制多个参与者参加的多媒体会话的建立和终结，并能动态调整和修改会话属性，如会话带宽要求、传输的媒体类型（语音、视频和数据等）、媒体的编解码格式、对组播和单播的支持等。

SIP协议凭借其简单、易于扩展、便于实现等诸多优点越来越得到业界的青睐，它正逐步成为NGN（下一代网络）和3G多媒体子系统域中的重要协议，并且市场上出现越来越多的支持SIP的客户端软件和智能多媒体终端，以及用SIP协议实现的服务器和软交换设备。　

首先讲一讲Chord基础知识，Chord是结构化的overlay。所谓overlay，是指P2P系统在物理连接的基础上构建的逻辑网络。而结构化的overlay，是指在overlay中，特定的资源由特定的节点管理；当查询该资源时，根据某种路由规则，找到管理该资源的特定节点。Chord使用SHA-1哈希算法，哈希值为m个比特。共有2m个可能值分布在圆周上，称做Chord环，如图2所示。

图中N表示节点，N后的数字是该节点的哈希值，一般通过哈希节点的IP地址得到。K表示资源，K后的数字是该资源的哈希值。Chord用在SIP中时，K应该是SIP URI，例如sip:humingchunno1@163.com。在Chord中，每个节点都负责管理一段哈希空间——顺时针方向上之前一个节点到自己的范围，哈希值落在该空间中的资源K的信息由本节点保存。例如节点N32就负责管理资源K24和K30的信息（图2中指向N32的实线箭头所示）。

当某个节点比如N8要询问资源K30的信息时，N8首先要找到负责管理K30的节点N32。最简单的做法是N8询问顺时针方向上自己后面的那个节点，称做N8的successor，即N14。如果N14不负责K30，则N14询问自己的successor，即N21。该操作反复进行，直至找到负责K30的节点N32为止。

这种查询机制只要求节点知道顺时针方向上自己后面那个节点的位置（自己的successor），查询效率低，花费的平均时间是函数O(N/2)的值，N是Chord环的实际节点数。为提高查询效率，Chord中每个节点除了记录successor和predecessor（顺时针方向上自己前面的那个节点)外，还要记录m个其他节点。这m个节点由successor(n+2i-1)确定，其中n是本节点的哈希值，i是1到m间的整数。m个节点的集合就是finger表（图2中给出N8的finger表）。这种方式下查询资源花费的平均时间为O(logN)。

新节点，例如图2中的N26，要加入Chord环时，先询问自己知道的Chord中任一节点，假定为N8。N8通过查询，发现N26的successor是N32，告知N26。N26得知后把successor设为N32，并通告N32自己的存在。N32得知后把predecessor设为N26，并把K24交由N26管理。N26则完成加入。

Chord中每个节点都要周期性地更新自己的successor、predecessor和finger表，以保证快速正确的查询。理论的计算和实际的模拟显示，Chord的容错性很强，当网络中50%的节点故障时，查询失败的机率也只有1.3%。

2. P2P-SIP网络的形成和维护

在PN的配置文件中应该有一个配置项，其值是“IP地址:端口”或“域名：端口”的形式。存在多个值时，之间用空格分开。其值也可以为空，表示本PN是P2P-SIP网络的第一个节点。值格式错误时，忽略该值。

PN启动时，如果发现配置项的值为空，PN的Chord层就新建一个Chord环。如果配置项存在一个或多个值，Chord层就依次向这些值发请求直至收到成功应答。如果最终没有收到成功应答，就提示错误或者新建一个Chord环。PN进入P2P-SIP网络后，即PN的Chord层加入到Chord环中，需要从其successor处拷贝一份用户注册信息。

PN正常退出P2P-SIP网络时，需要将自己管理的用户注册信息发给自己的successor。非正常退出时，P2P-SIP网络会暂时丢失部分用户的注册信息。为保证注册过的用户始终可达，可以让PN周期性地将它管理的用户注册信息通告自己的successor，甚至successor的successor。

P2P-SIP网络的维护是PN的Chord层来做的。每个PN的Chord层都周期性地更新自己的successor、predecessor和finger表，从而及时地了解网络的变化。

3. 请求处理过程

按照RFC3261的规定，SIP服务器（主要指代理服务器）处理请求时与请求的方法无关。我们将SIP服务器改造成PN时增加的步骤也应该是与方法无关的。下面我们通过详细描述用户的注册和呼叫，来展示P2P-SIP网络中PN处理请求的过程，并表明增加的步骤与方法无关。

用户注册过程

对用户而言，注册到P2P-SIP网络的过程和注册到SIP网络的过程是相同的。只是在P2P-SIP网络中，PN收到注册请求时，并不立即记录该条注册信息，而是先调用函数find_responsible_pn(user)。如果返回的地址是PN自己，这才记录下用户注册信息；如果返回的地址是其他PN，则PN会把注册请求转发给相应的PN。最终，注册请求会被转发到负责处理它的PN处，处理后产生的应答按原路返回。

考虑到减轻PN转发请求和记录事务状态的负担，PN收到不该自己负责的注册请求时，可以返回301 Moved Permanently应答。而把调用find_responsible_pn(user)得到的地址放在应答的Contact头域中,具体的注册过程如图3所示。

第1步：终端发注册请求

IP地址为192.168.13.63的SIP终端准备好REGISTER请求，发给P2P-SIP网络中任一PN（比如Key为69的PN。在P2P-SIP中，Key值是通过哈希节点的IP地址和端口得到的）。如图3中M1所示。

SIP终端可以通过多种方式获得PN的IP地址和端口。比如用户手动指定，或者使用终端默认的PN，或者使用终端上次进入P2P-SIP网络时更新的PN列表。

第2步：PN转发请求

Key值为69的PN收到REGISTER请求后，取得请求中To头域里的SIP URI——表示注册的信息属于哪个用户，调用find_responsible_pn(user)。返回值应该是“IP地址∶端口”字符串的形式。将返回值同本机“IP地址∶端口”作比较，如果相同，说明本机负责处理该请求，之后的处理流程遵循SIP标准；如果不同，就转发REGISTER请求到该“IP地址∶端口”。

在本例中，SIP URI是michael@powercn.com，假定其哈希值是17，PN的Chord层会查找到负责处理该请求的PN Key值是32，find_responsible_pn(user)返回该PN的“IP地址∶端口”——192.168.13.110:5060。PN的SIP层比较该值发现不是自己，就将注册请求转发到该“IP地址∶端口”，如图3中M2所示。

第3步：PN接受注册，返回应答

Key值为32的PN收到REGISTER请求后，取得请求中To头域里的SIP URI(michael@powercn.com)，调用find_responsible_pn(user)。返回值是192.168.13.110:5060，比较后发现是自己，说明自己负责管理该用户，负责处理该用户的注册请求。之后的处理流程遵循SIP标准。假定注册成功，PN返回200 OK应答。如图3中M3所示。应答的返回遵循SIP标准，根据Via头域按原路返回，不需要查找路径，不会使用Chord层的操作。

第4步：SIP终端收到应答，完成注册

Key值为69的PN收到来自192.168.13.110的应答，按照SIP标准处理，把应答发给192.168.13.63:5060。如图3中M4所示。SIP终端收到200 OK应答，完成注册。
用户呼叫过程

对用户而言，在P2P-SIP网络中发起呼叫与在SIP网络中发起呼叫相比没什么不同。构造标准的INVITE请求，发给自己连接的PN（SIP服务器），然后等待应答。

在P2P-SIP网络中，PN收到INVITE请求，进行必要处理后，取出请求中To头域里的SIP URI（表示呼叫哪个用户），调用find_responsible_pn(user)。如果返回值是PN自己，说明PN负责管理To头域所标识的用户，PN具有该用户的注册信息，之后的处理按SIP标准流程; 如果不是，则PN将INVITE请求转发给find_responsible_pn(user)返回的“IP地址：端口”，具体的呼叫过程如图4所示。

第1步：主叫发起呼叫
IP地址为192.168.13.26的用户alice@powercn.com要呼叫用户michael@powercn.com。alice可以把请求发给P2P-SIP网络中任一PN。考虑到要在P2P-SIP网络上提供增值业务（比如计费），alice把INVITE请求发给管理它的PN更合适一点，在本例中是IP为192.168.13.203，Key值为0的PN。如图4中M1所示。

第2步：PN转发请求到PN
Key值为0的PN收到INVITE请求后，取得请求中To头域里的SIP URI(michael@powercn.com)，调用find_responsible_pn(user)。返回值是192.168.13.110:5060。比较后发现不是自己，将请求转发给192.168.13.110:5060。如图4中M2所示。

第3步：PN转发请求到被叫
IP地址为192.168.13.110的PN收到该请求，进行相同的处理。发现返回值是自己，说明PN管理该用户，拥有该用户的注册请求。之后的处理流程遵循SIP标准，即在本地取得用户michael的当前地址，然后转发请求到该地址。如图4中M3所示。

第4步：被叫接受呼叫，返回应答
用户michael所在的SIP终端收到该请求，按照SIP标准进行处理。假定michael接受呼叫请求，则返回200 OK应答。如图4中M4所示。

第5步：应答沿原路返回
应答的返回遵循SIP标准，根据Via头域按原路返回，不需要查找路径，不会使用Chord层的操作。如图4中M5、M6所示。

第6步：主叫收到应答，发出确认，建立呼叫

用户alice所在的SIP终端收到200 OK应答，用ACK请求进行确认。ACK请求不经过P2P-SIP网络，直接发给用户michael所在的SIP终端。如图4中M7所示。用户michael所在的SIP终端收到ACK确认请求，呼叫建立。结束通话时，michael和alice直接交换SIP信令，不经过P2P-SIP网络。
按照本文所述的设计和实现方案，对原有的SIP软交换平台进行改造，在PN上实现了注册、呼叫和计费功能。原来的语音邮箱和自动应答功能作为单台媒体服务器接入P2P-SIP网络，在P2P-SIP网络内提供全局的用户认证、拨号策略、账务系统和网管服务。

基本的测试显示，5台处理能力为72万次/小时BHCA（中文叫忙时试呼次数，是电信领域用来衡量服务器处理能力的重要指标，注册用户数在电信领域指的就是座机的数目）的普通PC机组成P2P-SIP网络后其BHCA可以达到288万次/小时，支持的注册用户数达48万。