毕业设计（论文）-基于SIP业务模拟器工具设计和研究.doc

福州大学本科毕业设计（论文） 本科生毕业设计（论文）题 目： sip业务模拟器工具的 设计与研究 姓 名： 学 号： 学 院： 数学与计算机科学学院 专 业： 信息与计算科学 年 级： 2007级 指导教师： （签名）2011 年 06 月16 日 sip业务模拟器工具设计和研究中文摘要本文讨论了关于下一代网络（ngn）的应用开发的问题，它是基于sip业务的开发，sip（会话初始化协议）的开发目的是用来帮助提供跨越因特网的高级电话业务。本文设计了一个sip呼处理的模拟器。开始描述了sip基本术语，所需要的基本原理以及模拟器工具的系统架构，并使用mfc开发出相关的界面。接着对于呼处理的模块设计，其需要两部分完成，一个是sip消息本身的解析模块设计，另一个是sip消息脚本的解析模块设计。对于sip消息本身的解析模块设计，采用了按行的解析算法思想以及c+实现，和按字节的解析算法思想相比，即保证了消息的完整性又具有整体直观性，也提高了程序的运行效率。而sip消息脚本通过xml编写，故是实现xml脚本的解析，此解析算法思想是采用串行解析技术，并通过形成链表和树形结构，完成对关键字的提取。此模拟器工具是在window 使用visual c+ 6.0来实现，在winsock的编程原理基础上，即客户机-服务器的通信模式，采用改进的流套接字编程方法，实现sip基本呼叫建立过程。最后通过对此模拟器工具的进行了性能测试来说明其对验证大量的准正常和异常case的效果。关键字：sip消息、解析算法、呼处理 the development of simulative tool based on sip professional work abstract目 录中文摘要iiabstractiii第1章 绪论11.1 背景知识11.2 sip协议简介11.3 工具开发概要31.4 本文主要研究内容3第2章 系统架构及界面开发42.1 系统架构42.2 主界面及子界面5第3章 sip消息解析模块设计93.1 sip消息引言93.2 sip消息解析策略及初步模型103.3 sip解析模型改进11第4章 xml脚本解析模块设计134.1 解析技术134.2 脚本格式及特点134.3 脚本解析模型及特点17第5章 模拟器测试及结果分析195.1 模拟器呼叫模块及结果195.2 性能测试及结果205.3 结果分析21结论21谢辞22参考文献23iv第1章 绪论1.1 背景知识随着voip（网络电话）的迅猛发展，通讯技术数字化已成为现代通信技术的基本特征和最突出的发展趋势。而网络的下一个发展目标就是ngn，ngn是下一代网络，又称为次世代网络，它使得新一代网络上语音、视频、数据等综合业务成为了可能。而sip协议是ngn中的重要协议，sip称为会话初始化协议，它的开发目的是用来帮助提供跨越因特网的高级电话业务。因特网电话正在向一种正式的商业电话模式演进，sip就是用来确保这种演进实现而需要的ngn序列协议中重要的一员。目前，单一的业务已经无法满足人们的需求了，而转变为一种综合的业务，它融合了文本数据业务、语音数据业务、多媒体视频数据业务。为了建设投资小、效益高、可共享的网络，以电话网为代表的电信网和以因特网为代表的数据网络的互通和融合进程正在快速发展。加上以前被我们视为瓶颈的带宽和服务质量问题已得到解决，大大推动了 ip 技术的发展，带动各种应用向 ip靠拢。sip (session initiation protocol，会话初始协议)是由 ietf ( the internet engi2neering task force，互联网工程任务组) 于1999 年提出的一个基于 ip 网络的一种实时通信应用信令协议1。因为 sip协议具有internet协议简单、灵活、扩展性好等特点，目前已得到越来越广泛的应用。因此，对基于 sip业务的应用软件工具进行相关的开发及测试也就十分重要。1.2 sip协议简介sip（session initiation protocol）会话初始协议是ietf制定的，用于多方多媒体的通信。sip是一个基于文本的应用层控制协议，独立于底层传输协议tcp/udp/sctp，用于建立、修改和终止ip网上的双方或者多方多媒体会话。sip协议借鉴了http、smtp等协议，支持代理、重定向及登记定位用户等功能，支持用户移动。通过与rtp/rtcp、sdp、rtsp等协议及dns配合，sip支持语音、视频、数据、e-mail、状态、im、聊天、游戏等。sip 可以用来对会话进行初始化, 也可以邀请成员加入经其他手段建立或公布的会话。sip 支持建立和终止多媒体通信方面的功能有：l 用户端定位( user locat ion)：对在通信中使用的端系统的位置的确定。l 用户能力( user capabilties)：决定在通信中要使用的媒体和媒体参数。l 用户可行性( user availability )：确定被呼叫方是否愿意加入通信。l 呼叫建立( call setup)：呼叫方和被呼叫方双方建立呼叫参数。l 呼叫处理( call handling)：包括转移和结束呼叫。sip的终端系统称为用户代理（user agent，简称ua），含用户代理客户机uac（user agent client）以及用户代理服务器uas（user agent server）两部分，呼叫过程即是uac和uas通信的过程。一个呼叫建立过程如图1.1。用户代理客户端（uac）用户代理服务器（uas）invite180200ackbye200图1.1 sip业务模拟器基本呼叫建立过程sip协议把一个呼叫分为三个阶段：呼叫建立，呼叫保持，呼叫释放。图1.1所示的是一个呼叫建立的信令过程。首先要建立呼叫信令信道，即一个udp或者tcp连接。则，由服务器的ip地址和端口号建立客户端和服务器端之间的呼叫信令信道。然后，客户端向服务器端发送invite消息，如果服务器端同意建立呼叫，发送180、200消息，其中180状态码表示请求已经收到，正在处理中，200表示请求已经成功。此时，如果客户端突然不想参加此次会话，可以向服务器端发送bye消息，此次呼叫结束；如果客户端仍然想参加此次会话，就向服务器端发送ack消息，确认客户端已经收到了对invite请求的最终响应(200)，经过三次握手机制后，基本呼叫建立完成，进入呼叫保持阶段。当双方通信一段时间后，任何一方可以发送bye消息来结束此次会话的呼叫。1.3 工具开发概要sipserver呼处理相关业务测试过程中需要验证大量的准正常和异常case,这些case在设备正常呼叫过程中很难出现，测试的难度较大。需要一种测试业务模拟工具，它实现了uac（用户代理客户端）功能，能够根据用户配置的脚本，自动生成相应的呼叫流程，发送和接收相应的sip消息，并报告执行结果。1.4 本文主要研究内容很多的sip测试工具器是基于dos命令并在linux下的，本文设计了一个在windows下的sip业务模拟器工具，是一个呼叫处理工具，该工具和dos命令下的界面相比，更简洁直观，优化了命令的传输形式。一开始描述了系统构架并完成相关的界面；其次研究了sip消息解析模块的设计，提出一中按行解析的新思路，而其编码是基于扩展的巴基科范式（abnf）2；而后对脚本解析的设计和实现，在原有的xml解析算法流程进行扩展，以达到满足项目需求；最后通过visual c+6.0 实现模拟器工具以及采用winsock的原理实现基本呼叫的过程。最后一章通过实验数据来表明该模拟器工具的性能。第2章 系统架构及界面开发2.1 系统架构数据对象脚本文件对象类sip消息对象类配置参数对象类统计数据对象类。呼处理控制脚本解析呼处理控制sip消息解析统计数据收集。界面和数据展示消息窗口统计窗口案例展示窗口配置窗口。 图2.1 系统架构图2.2 主界面及子界面 图2.2 主界面图2.2.1 工具栏工具栏上有4个功能按钮，每个按钮需求说明如下：1) start test：启动测试，默认状态：disabled ，只有scenario被选择，状态才转为enabled2) stop test：停止测试，默认状态：disabled，只有start test开始了，状态才转为enabled3) select scenario：选择测试方案，点击后弹出文件选择框，选择 scenario，在scenario window 显示4) option：设置测试选项，点击后弹出测试选项对话框，完成后选项配置要保存到配置文件中。2.2.2 scenario window情景窗口（图2.3）需要实现的内容为：1) 允许编辑，修改2) 提供右键弹出菜单，来保存用户修改3) 脚本的格式参考sipp的脚本格式 图2.3 情景窗口：显示脚本内容2.2.3 message window消息窗口（图2.4）需要实现的内容为：1) 显示当前接收发送的消息2) 提供右键弹出菜单，来保存log功能 图2.4 消息显示窗口2.2.4 statistic window统计窗口(图2.5)显示测试的统计信息：测试方案执行次数，成功次数，失败次数，预期消息，未预期的消息 图2.5 消息统计窗口2.2.5 option window软件的运行参数配置如图2.6：该配置提供本地ip和本地端口以及远程ip和远程端口。 图2.6软件运行参数配置如下内容将自动保存到配置文件中：option.iniproduct_infomulticalls=1rip=rport=5060lip=lport=5060maxcallnum=1000log=1第3章 sip消息解析模块设计3.1 sip消息引言sip采用c/s结果的消息机制，分布式控制。sip消息分为两大类：从客户端到服务器的请求（request）和从服务器到客户端的响应（response）。sip基于http，是一中文本型请求响应吸引：客户端发起请求，服务器端回送响应。一次sip事务处理包括一个客户端的请求、没有多个临时响应，以及一个来自服务器端的最终响应。sip消息 = 开始行消息头crlf消息体开始行 = 请求行/状态行 图3.1 sip消息格式图3.1显示了sip消息格式，它以起始行开始，请求消息中称为请求行，响应消息中称状态行。起始行后面是一些标题区域，包括格式name：value以及一个空行将标题区域和可选信息实体分隔开。消息头由域名和域值并加上中间的”:”组成的，例如：from：。消息体由sdp消息构成，sdp消息是文本信息，采用utf-8编码中的iso10646字符集，但sip消息中不一定都有sdp消息。一个由uac发出的合法sip请求必须包含的最小头字段如下：to，from，cseq，call-id，max-forwards，via所有这些头字段在sip请求中都是强制的。这六个域是构成sip消息的基本块，它们联合提供大多数的消息路由服务，包括消息寻址、响应路由、限制消息传播、消息定制、唯一性鉴定事务。这些头字段还追加了一些强制请求行包括方法、请求地址、sip版本。3.2 sip消息解析策略及初步模型sip消息是采用c+面向对象来实现的，根据c+面向对象的特点，以及sip协议自身的特点，提出了一种按行解析的新思路产生sip协议栈来保存sip消息。 按行解析式是相对于按字节解析的，一个字节、一个字节读取时按照字节解析的；而所谓按行解析，是把sip消息中的每个行当作一个整体来处理，通过逐行解析，来完成整个消息的解析。但是sip消息每一行的格式和类型又是不尽相同，不可能用一个函数解析到底，针对这一点，结合c+语言的继承性和多态性可以完全解决这个问题。继承性使得能够将sip消息看作一个整体来对待，多态性则将其中请求消息与相应消息的不同的细节问题解决得比较完善，通过建立在继承性和多态性的基础上，完成按行解析的过程。解析模块完成两大功能：第一是正向消息解析，完成文本（字符串）到协议规定的消息格式的转换，主要是在接收消息时候调用。第二是逆向消息编码，完成消息到字符串的转换，主要在发送消息时候调用。基于单线程的解析模型算法流程图如图3.1。解析起始行开始收到消息解析头字段解析sip版本号状态码和解释信息解析请求方法请求uri和版本解析消息体sip消息？消息体？ 结束图3.1 sip消息解析流程图有是无否sip消息解析算法描述：当ua接收到一个sip消息后，首先对字符串形式的消息进行整体的判断和分解。当对行结束符以及回车换行的识别，判断消息是否合法。如果合法，再将消息分成三个部分分别进行判断和解析。先是对开始行进行分析判断，判断收到的消息是请求还是响应，而后对其进行解析，同时提取相关信息（sip uri和版本号）；随后对各个头字段进行解析，提取相关信息；当遇到空行（crlf）后，调用对消息体的解析函数；最后完成消息的解析。3.3 sip解析模型改进在实现单线程解析的基础上，采用abnf语法规则2。我们可以设计一个多线程的消息处理模型来提高解析效率，即系统解析sip消息时，可以同时从开始行、头字段、消息体解析。在消息头种类比较多时，可以快速匹配到对应的消息头解析函数。在词法解析算法中3,标准lr算法是可以同时处理多个进程，系统可能会并行地存在几组树结构栈，大大缩减计算量；在解析过程中采用共享子树结构来表现局部分析结果，节省空间开销；通过节点合并，压缩局部歧义。sip消息解析时，解析模块从输入消息的句首顺次“移入”sip消息的开始行、头字段、消息体，并根据语法中的重写规则逐级向上按条件“规约”，直到构造出表示sip消息结构的整个推到树。在移入和归约过程中sip信息以栈的形式存放，栈中存放解析过程的有关“历史”信息，在解析时根据这些历史信息和当前正在处理的符合来决定究竟是移入还是归约3。sip算法解析过程：1) 从输入消息的左端将一个未处理过的终结符移入栈顶，并等待更多的信息到了之后再做决定；2) 根据上下文无关语法的abnf规则，用该规则左边的符合来取代栈顶的与规则右边相匹配的符合；3) 对栈中符合和输入符合串进行处理，输入串处理完成，且栈中只剩下一个符号s，分析成功，然后结束；4) 若栈中并非只有一个符合s或者输入的字符串中的符号没有处理完成，也不能进行任何的规约操作，分析失败结束。sip解析改进算法流程如图4所示5。开 始输入abnf规则输入sip消息i = 1取第i个条件的信息电子词典lr分析表i+按lr分析表处理，如果出现多种操作，启动多线程是否出错？是否接受？是否归约？移 进打印出错信 息打印出错信 息输出分析树结 束合一算法生成子树成功否？是否否否是是否是图3.2 改进sip解析算法流程图第4章 xml脚本解析模块设计4.1 解析技术xml解析技术分为串行解析技术和并行解析技术。其中串行解析技术是指解析xml文档过程中采用单线程方式，即解析相关操作按照顺序执行的解析技术。而本文的xml解析模块的设计采用串行解析技术的原理，在此基础上通过基于预处理技术，可以提高解析性能，同时可以保持应用程序编程接口的兼容性。4.2 脚本格式及特点脚本实际上是一个sipp的xml配置文件，xml脚本不但提供了sip消息本身，而且通过xml元素的属性提供了对这些消息的处理控制信息，这些处理控制信息包括重传时间、是否是必须的消息、及时开始和结束等。目前ph1阶段我们只支持其中一部分功能，可以认为我们的脚本文件是sipp的一个子集。格式：所有的脚本都是以下方式开始以结束。一个客户机（uac）的脚本结构内容是以“send”关键字开始的，在“”和“”之间的内容称为关键字，如下： !cdata invite sip:serviceremote_ip:remote_port sip/2.0 via: sip/2.0/transport local_ip:local_port from: sipp ;tag=call_number to: sut call-id: call_id cseq: 1 invite contact: sip:sipplocal_ip:local_port max-forwards: 70 subject: performance test content-type: application/sdp content-length: len v=0 o=user1 53655765 2353687637 in iplocal_ip_type local_ip s=- t=0 0 c=in ipmedia_ip_type media_ip m=audio media_port rtp/avp 0 a=rtpmap:0 pcmu/8000 一个服务器（uas）的脚本结构内容如下： !cdata sip/2.0 180 ringing last_via: last_from: last_to:;tag=call_number last_call-id: last_cseq: contact: content-length: 0 在“send”命令中，我们把sip的消息封装到“”标签之间。在这两个标签里的内容将会被发送到远程系统。这些关键字是用来说明sipp该做什么事情。关键字列表说明如表1： 表1 sip消息关键字说明关键字默认值说明serviceservice服务字段，通过命令 s service_name传递remote_ip-远程ip地址，通过命令行传递remote_port5060远程ip端口，通过命令行传递。你可以增加一个已经计算过的偏移量remote_port + 3 来赋给这个值。transportudp取决于t 参数的值，将获得值“udp”或者“tcp”local_ipprimary host ip address获得-i参数的值local_ip_type-取决于-i参数地址类型（ipv4或ipv6），local_ip_type 的值若是4则为ipv4，若为6则为ipv6local_portrandom获得-p参数的值，你可以增加一个已经经过计算的偏移量(localport+3)赋给这个值。len-计算sip消息体的长度。用在“content-length”字段中，你可以增加一个已经经过计算的偏移量(len+3) 赋给这个值。call_number-索引。从1开始，每出现一个呼叫增加一。cseq-该值是自动生成的，初始值是1，可以通过使用-base_cseq命令行选择来改变它。call_id-sipp每一个新的呼叫就会产生一个call-id，一个这个值识别一个呼叫。在客户模块中，它通过sipp中的call-id字段值的形成来强制使用。否者，由于成为一个已经存在的呼叫的一部分使得sipp无法识别该应答哪一个消息的发送。注：call-id可以通过三斜杠字符串/来识别。如：call-id：abcdefghij/call_id，则sipp仍然可以识别并当作是同一个呼叫部分。media_ip-取决于-mi参数的值，它是本地ip地址对rtp的回应值。media_ip_type-取决于-mi参数的地址类型（ipv4或ipv6），media_ip_type 的值若是4则为ipv4，若为6则为ipv6media_port-取决于-mp参数的值，它设置了本地rtp回声值。rtp/udp包接收它们的发送者。你可以增加一个已经经过计算的偏移量(media_port +3) 赋给这个值。auto_media_port-仅使用在pcap中。从-mp参数的值开始来设置它的端口，使用含10000组建（为pcap_play限制10000个当前rtp会话）的周期系统来改变每个呼叫。last_*-如果接收的消息是最后一个，则last_*关键字会被自动的加到这个当前消息的特定字段中（除了复传送的消息外）。如果这个头字段不是当前的或者该消息已经被接收，则该关键字被丢弃，且是值到最后一行的所有字节都会被丢弃。若一个消息中出现该头字段多次，所有该情况连续使用last_*关键字来代替。field0-n-从外部csv文件写入该值。$n-用于写入呼叫变量数n值。authentication-用于设置鉴别字段，该字段可以有参数，如下：authentication username=myusernamepassword=mypassword.如果username没有提供，则从-s命令行参数中取得。如果password没有提供，则从-ap命令行参数中取得。pid-提供sipp主线程的进程id号routes-如果“rrs”属性在recv命令中被设置成“true”，则接收消息中的“record-route”头字段被存储并可以使用该关键字进行重呼叫。next_url-如果“rrs”属性在recv命令中被设置成“true”，则该字段含有cantact字段的文本内容（该内容在cantact中使用包含）。branch-提供一个分支值，它在情景中由一串z9hg4bk+呼叫数+消息索引组成。msg_index-为情景提供消息数量cseq-提供最后请求接收的cseq值。这个值可以增大（如：cseq+1，为最后请求的cseq值增一）。在xml脚本中，元素的属性表示对此消息的处理控制的方法。例如：optional属性说明这个消息是否是必需的。xml的cdata部分表示了sip消息的一个框架，可以看到在方括号中的内容代表了一个变量，这些变量由用户配置文件中给出，如remote_ip、local_ip、transport等，或者由模拟器工具自己生成，如call_id、call_number、tag等。通过这种方式，用户可以方便地编写出针对某类系统具有普遍适用性的测试实例。4.3 脚本解析模型及特点4.3.1 串行解析技术 根据对xml实例进行验证的模式，可以将串行解析技术进一步分为独立解析和解析与验证集两种解析模式。独立解析的模式指将解析过程与验证过程彼此独立、验证过程处于解析过程之后的处理模式。文档对象模型dom6是独立解析模式的一种，是w3c推荐的一种独立于语言和平台的标准，并且是一种基于树型的解析技术，其目标是提供一个可以通用于各种程序语言、操作系统和应用程序的编程接口。dom模型在解析xml文档时先将整个xml文档扫描一遍，得到独立的元素、属性和注释等然后以节点树的形式在内存中创建xml文档的表示，是以层次结构组织的节点或信息片段的集合，每个节点代表一个可以与之交互的对象，用户可以通过结点树访问文档内容。 此模型的优点是在内存中保留整个文档的所有信息，用户可以随意访问任意位置的节点信息或是对之进行修改，开发人员可以方便编写程序。4.3.2 解析模型描述在串行技术的基础上，又根据sip脚本的内容特点，对有些特定的字符串进行预处理，预过滤技术根据一定的规则、机制，在解析之前对xml文档进行预处理，将用户真正需要的部分过滤出来然后执行解析，从而降低了解析的工作量，提高了解析的性能。在解析xml文档dom解析技术的基础上，采用c+面向对象的方法实现对xml的解析，其定义了一系列的对象和方法对dom树的节点进行各种随机操作：1) cxmldocument对象：作为树的最高节点，是解析xml文档的入口。2) cxmlattrlist对象和cxmlattrelement对象：这些节点对象都是文档某一部分的映射，节点的定级层次恰好反映了文档的结构。3) cxmlnode对象是节点类，用于保存信息；而cxmlutil对象是内部转换封装类，用于对有用信息转换。以下描述在解析过程中对节点和属性的遍历，先获取脚本的内容：在解析过程中，脚本文件的内容通过节点的遍历会保存到子节点的标签值中，则可以先获得根节点的地址，在找出相应的子节点的地址，最后通过子节点中的gettagvalue()获取脚本的内容。在遍历xml的节点：通过解析，可以生成根节点，而根节点下会有相应的子节点,通过循环会生成子节点链表；故可以通过定义根节点，找到子节点的头节点，再通过链表的遍历，寻找出相应的节点。最后可获取xml的属性值：解析过程中，通过cxmlattrelement类的setattrname()和setattrvalue()来保存相应的属性，若成功，则会通过cxmlattrlist:addattrelement()函数添加到属性链表中，故可以在节点下的属性链表中获取相应元素属性的地址，从而可以获取属性值。 对得到的属性和属性值进行扩展解析，与满足用户的需求，由于sip消息是封包在“”之间，故需要获得相关的值，再进行对其进一步解析，由uac结构中可知我们需要提取的是关键字，因关键字的特殊性，可采用按字节解析的算法对其进行提取。xml解析算法过程如下：1) 输入xml文档内容；2) 进行预处理，取得用户所需要的信息；3) 解析开始部分内容，得到版本号和编码代号，如果失败，则结束，否则进入下一步；4) 进行子内容的解析，通过调用接口函数可获得xml的节点和xml属性值；5) 判断是否有下一个字内容，若有则返回上一步，否则结束。解析模型流程如图4.1：输入脚本内容开始解析版本号和编码成功？解析消息内容子消息？结束有无是否图4.1 xml解析算法流程图预处理第5章 模拟器测试及结果分析5.1 模拟器呼叫模块及结果此模拟器呼叫是单路呼叫，单路呼叫的运行线程模拟一个sip用户代理，单路呼叫模块既可以动态配置成uac，也可以配置成uas，通过sip服务器与其它的sip用户代理进行会话。与真正的用户代理不同，单路呼叫模块只进行会话的信令交换，不进行真实的会话媒体流的交换。单路呼叫模块的结构如图5.1,由呼处理控制和sip消息解编码器两个子模块组成。呼处理控制sip呼叫信息解码编码解编码器图5.1 模拟器呼叫模块moni呼叫处理控制子模块根据单路呼叫模块的运行线程在会话扮演的角色是uas还是uac，通过选择相应的呼叫流程对呼叫进行控制，此模拟器只支持典型流程的呼叫。预期每次呼叫，都会有一定数量的准正常和异常case，其指标由呼叫失败率和忙时最高呼处理能力bhca（busy hour call attempt）值等来说明。通过呼叫测试获得的统计信息如表2所示。序号总呼叫次数成功呼叫次数失败呼叫次数bhca(次/秒)失败率110000800020002736020%27000600010002862014%3500042507502146015%440003600400956010%5.2 性能测试及结果通过sip业务模拟器对sip服务器性能的测试，是模拟通话高峰时的情况，对sip服务器施加话务压力，监测sip服务器此时的性能，而性能指标一般包括呼叫高峰时呼损率和忙时最高呼处理能力bhca（busy hour call attempt）值等。测试的目标是监测sip模拟器工具实现的bhca值，呼叫高峰时呼损率，以及支持并发呼叫的能力。该软交换设备的预期性能是bhca大于140万，呼叫高峰时呼损率小于0.0034%，每秒钟至少能够同时支持200路并发呼叫。首先测试单台pc作为呼叫器实施业务压力的能力，单个呼叫器在30路并发时每小时能够对软交换成功呼叫33万次。在实际的测试环境中利用1台pc作为控制器，10台pc作为呼叫器，这样能够确保测试系统本身能够达到测试必需的性能。在测试中对软交换四次呼叫，每次总呼叫次数为100万，并发路数的依次为100,150,200,250，测试运行结果如表3所示。 表3 sipserver呼处理测试结果序号并发路数 单路呼叫次数时间(s)bhca(次/小时)失败数(呼损率)1100=1010100002442148万43(0.004%)2150=101566672363152万125(0.01%)3200=102050003084117万4285(0.4%)4250=10254000593961 万74356(7.4%)5.3 结果分析从表3 可以看出，在100路到150路并发的情况下，bhca值大于140万和呼损率小于0.0034%，待测系统的性能超过预期要求的性能。但是并发的路数增加达到200 路和250 路时，软交换的性能指标下降，不能达到预期性能，并随着并发路数增加bhca值越低，呼损率越高。对于200路和250路并发呼叫的测试情况，通过察看控制器记录的呼叫失败信息，