（通信与信息系统专业论文）h323网守呼叫转移功能的实现及研究.pdf

摘要 g n u 异k 是h 3 2 3 网守的一个c + + 实现，提供t h 3 2 3 所规定的大部分网守功能，并根 据g 声l 于溆其源代码 本论文分析了g n u g k 的源代码的设计思路、总体结构和与呼叫相关的细节，通过亭苎竺 改源a 码在该实现韵玉出之上为网守增加三种呼叫转移功能：无条件转移、遇忙转移和无应 答转移 对已经投入使用的系统而言，升级后的设备应该和已有的设备尽可能兼容，并且功自! 墅 级的带来修改应该尽可能的少，这样不仅能够保护用户的投资，还可以显著缩短升级和系统 测试的周期，降低由于升级引起故障的可能性 本文在设计呼叫转移方案时，完全遵循了h 3 2 3 建议规定的各种通信方式和信皇粤粤， 对g n u g k 和其它h 3 2 3 端点的兼容性没有影响同时，在实现呼叫转移时只涉及对网守的修 麦：) 一置修改完成，现有的h 3 2 3 终端均能够立即无需修改地使用三种呼叫转移8 1 竺乎了銎 有h 3 2 3 系统功能的平滑升级同时为系统管理员提供接口，允许对呼叫转移的使用加以控 制 关键词：h 3 2 3 ，网守，g n u g k , 无条件转移，遇忙转移，无应答转移 a b s t r a c t g n u g ki sac + + i m p l e m e n t i o no fh 3 2 3g a t e k e e p e r , w h i c hp r o v i d e sa l m o s ta l lg a t e k e e p e rf u n c t i o n sd e f i n e db yh 3 2 3 ，a n di t ss o u r c ec o d ei so p e nu n d e rt h et e r m so fg p l t h ed e s i g n ，o v e r a hs t r u c t u r ea n dc a l l i n gr e l a t e dd e t a i l so fg n u g ka r ec o v e r e dw i t h i n t h i sp a p e r 3k i n d so fc a l lf o r w a r d i n go p e r a t i o n s ，i e c f u ，c f ba n dc f n r , a r ea d d e dt o g n u g kb yi m p o s i n gd i r e c tm o d i f i c a t i o n st ot h es o u r c ec o d e w i t h r e s p e c tt od e v i c e sa l r e a d yd e p l o y e d ，t h eu p g r a d e do n e ss h o u l db ea sc o m p a t i b l e a sw e l la n dt h em o d i f i c a t i o n si n v o k e db yt h eu p g r a d es h o u l d b ea ss m a l la sw e l l i fs o ，n o t o n l yt h ep r e v i o u si n v e s t m e n ti sp r o t e c t e d ，b u ta l s ot h ed u r a t i o nt ou p g r a d ea n dt e s t i n ga r e s h o r t e n e da n dt h e p o s s i b i l i t yf o rb u g st oc o m ew i t ht h eu p g r a d ei sl o w e r e d w h i l et h ec a l lf o r w a r d i n gf u n c t i o ni sd e i n gd e s i g n e d ，t h ec o m m u n i c a t i o nm e t h o d s a n ds i g n a l l i n gp r o c e s s e sd e f i n e di nh 3 2 3a r ef u l l yr e s p e c t e d ，s ot h e r ei sn oi m p a c tt ot h e c o m p a t i b i l i t yo fg n u g kw i t ho t h e rh 3 2 3e n d p o i n t s f u r t h e r m o r e ，j u s tt h eg a t e k e e p e ri t s e l f i si n v o k e di nt h ei m p r o v m e n t ，s oo n c ec o m p l e t e d ，e x i s t i n gh 3 2 3t e r m i n a l sa r ea b l et o m a k eu s eo ft h i sf u n c t i o n a l i t ya to n c ea n dt h e r ei sn on e e df o rt h e mt ob em o d i f i e da n dt h e f u n c t i o n a l i t yo ft h ew h o l es y s t e mi su p g r a d e ds m o o t h l y ai n t e r f a c ei sa l s op r o v i d e df o r t h ea d m i n i s t r a t o rt oc o n t r o lt h ec a l lf o r w a r d i n g k e y w o r d s ：h 3 2 3 ，g a t e k e e p e r , g n u g k , c f u , c f b ，c f n r l u 独创性声明 本人声明所呈交的学位论文是本人在导师指导下进行的研究工作及取得的 研究成果。据我所知，除了文中特别加以标注和致谢的地方外，论文中不包含 其他人已经发表或撰写过的研究成果，也不包含为获得电子科技大学或其它教 育机构的学位或证书而使用过的材料。与我一同工作的同志对本研究所做的任 何贡献均已在论文中作了明确的说明并表示谢意。 签名：鳌坌! 至 日期：z 0 。牛年2 月万日 关于论文使用授权的说明 本学位论文作者完全了解电子科技大学有关保留、使用学位论文的规定， 有权保留并向国家有关部门或机构送交论文的复印件和磁盘，允许论文被查阅 和借阅。本人授权电子科技大学可以将学位论文的全部或部分内容编入有关数 据库进行检索，可以采用影印、缩印或扫描等复制手段保存、汇编学位论文。 ( 保密的学位论文在解密后应遵守此规定) 签名： 塾坌盗 导师签名： 日期：2 d 。呼年 1 1 概述 第1 章引言 随着i n t e r n e t 的飞速发展，人们对基于口的通信业务的期望也越来越高不仅仅是更加 快速的数据传输速率，还有日益丰富的服务种类而基于i p 的电话服务是近年来流行的一 种i p 业务，i p 电话代表着未来语音通信的发展趋势 和固定电话采用的线路交换方式相比，i n t e r n e t 的分组交换不仅可以更加高效地利用传 输线路资源，而且对潜在的新业务的支持能力也胜出一筹口电话还可以和个人计算机以及 各种消费类电子产品紧密结合，共同构成未来社会所推崇的“无处不在的计算“ 公用电话交换网支持多种补充业务，其中呼叫转移是一种常见而且使用广泛的业务如 果人们采用i p 电话作为替代方案，在享受i p 电话固有的各种优点时，一定也希望能够用种 已经习以为常的方式进行操作从尊重用户习惯的角度考虑，i p 电话也应该支持呼叫转移 当谈到通信时，一个无法回避的话题就是协议目前实现i p 电话的主要协议有n u t 的h 3 2 3 【1 】系列建议和i e t f 的s i p 协议二者中，h 3 2 3 比较成熟而且已经有实际应用 h 3 2 3 的补充业务在h 4 5 0 x 【4 ，5 】中规定按照i t u t 建议h 4 5 0 3 的定义，呼叫转移可以 分为4 类，如下： 无条件转移，即c a l lf o r w a r d i n gu n c o n d i t i o n a l ( c f u ) 通过设置这种呼叫转移，用户可 以把所有呼入电话都无条件地转移到别的用户去，而用户发出呼叫的能力不受影响 遇忙转移，即c a l lf o r w a r d i n gb u s y ( c f b ) 通过设置这种呼叫转移，当用户正在”忙”时， 呼入的全部或者部分电话被转移到别的用户去，用户发出呼叫的能力不受影响 无应答转移，目n c a l lf o r w a r d i n gn o r e p l y ( c d n r ) 这种呼叫转移允许当用户在一定时 间内对呼入电话没有应答时，按照该用户事先的设定，把呼叫转移到另外的用户去，不 影响用户发出呼叫的能力 指示转移，a f 】c a l ld e f l e c t i o n ( c d ) 用户在电话振铃后，可以用特定的按键主动地把呼叫 转向别的用户，不影响用户发出呼叫的能力 1 h 3 2 3 网守呼叫转移功能的实现及研究 在h 4 5 0 x 建议中，r r u t 详细定义了实现以上呼叫转移功能的过程和相应的分组格式 按照该系列建议实现的呼叫转移功能有最好的互操作能力但是这些建议本身非常详尽，需 要网守和端点的相互配合，在编程实现时工作量比较大 如果不采用h 4 5 0 x 建议也能够实现呼叫转移，有基于端点和基于网守两种方式 许多端点在其实现中提供了呼叫转移功能这是基于端点的呼叫转移，即由端点自行判 断是否进行转移和转移的目的端点，然后向网守发送q 9 3 2 建议定义的f a c i l i t y 消息，网守只 需按照h 3 2 3 建议规定的标准方式进行操作即可两个比较流行的v o i p 终端o p e n p h o n e 和o h p h o n e 都用这种方式实现了c f u 、c f b 和c f n r 而本文将尝试以基于网守的方式实现呼叫转移功能和基于端点的呼叫转移相反，在这 种实现方式中，网守负责进行全部的判断和转移工作，端点只要按照h 3 2 3 建议规定的标准方 式进行操作即可，甚至不需要知道是否进行了呼叫转移在这种情况下，h 3 2 3 网守扮演的角 色类似于一台软件交换机j 而且对端点的要求最低，只要能够拨号，就可以使用呼叫转移 网守的定义、功能和选项都在h 3 2 3 建议中有明确的规定但h 3 2 3 是庞大而详尽的国际 建议，按照其规定从头编写网守需要相当长的时间，我们不打算这样做，而是在一个现有网守 的源代码的基础上添加代码来实现相应的功能这样可以显著减少工作量 我们修改的网守, 是g n u g k ，一个跨平台的h 3 2 3 网守实现其实现语言是c + + ，底层采 用o p e n h 3 2 3 和p w l i b 作为支撑库g n u g k 和这两个库的作者使用的发布许可证允许任何人修 改、重新发布甚至出售其源代码1 这些开放的源代码是我们工作的基础 具体的编程环境为：x 8 6 兼容处理器、l i n u xm a n d r a k e9 0 、g c c - 3 2 3 、g n u g k - 2 0 6 、 o p e n h 3 2 3 1 1 2 2 、p w h b 一1 5 2 以及采用t c p 口协议的以太网测试时使用o h p h o n e 一1 4 1 作 为终端 1 2 目标 本文所有分析及论述所要达到的目标是 分析g n u g k 的源代码，研究h 3 2 3 的协议过程，得到在单台网守上实现3 种呼叫转移， 即c f u 、c f b 、c f n r 的算法、策略和h 3 2 3 实体之间的交互方式 在g n u 北的基础上编写代码，实现呼叫转移功能和端点用户之问的交互方式在p c 上进 行模拟测试 分析在多台网守的情况下，呼叫转移功能的实现方式 2 1 当然这样做需要遵守一定的条款，请参考f 蚂分忻眨改。弓 第1 章引言 以上内容在正文部分阐述，而一些相关的背景材料请参考附录包括h 3 2 3 系列建议的体 系结构、抽象语法标记( a s n 1 ) 以及p w l i b 的配置文件接口 3 第2 章相关h 3 2 3 过程分析 本章不是对h 3 2 3 系列建议的详尽阐述，而是着重分析和实现呼叫转移功能相关的内容， 即网守在h 3 2 3 系统中的作用和端点之间建立呼叫的过程要实现一个网络电话系统，还需要 许多协议和h 3 2 3 配合工作，h 3 2 3 和这些配套协议的整体结构以及各个协议的层次和角色请 参考h 0 2 3 系列建议最完整翔实的资料当然是i i u - t 建议本身：【1 ，2 ，3 】 2 1 h 3 2 3 实体 按照 l 3 2 3 的定义，一个h 3 2 3 系统的所有部件( c o m p o n e n t ) ，都是h 3 2 3 实体( e n t i t y ) 这 些实体可以分为以下几种逻辑类型： 终端( t e r m i n a l ) ：在h 3 2 3 系统工作的网络上和其它终端，网关以及多点控制器进行实时 双向通信的实体终端必须提供控制、指示、音频通信，还可能提供彩色视频和或数 据通信o h p h o n e 、o p e n p h o n e 以及n e t m e e t i n g 都是软件实现的终端 网关( g a t e w a y ) ：为分愀( p a c k e tb a s e dn e t w o r k , p b n ) d 2 的h 3 2 3 终端提供与交换 电路匿j ( s w i t c hc i r c u i tn e t w o r k ，s c n ) t 的其它r r u - t 终端，或者与另一个网关的实时 双向通信的端点其它i t u t 终端是指遵守h 3 1 0 、h 3 2 0 、h 3 2 1 、h 3 2 2 、h 3 2 4 、 h 3 2 4 m 和v 7 0 这些r r u _ t 建议的终端 网, 守( g a t e k e e p e r ) ：是为p b n 上的h 3 2 3 终端、网关和多点控制器提供地址翻译和网络 访问控制的h 3 2 3 实体网守还可以提供诸如带宽管理和网关定位等其它功能我们将 要为g n u g k 这个网守实现添加呼叫转移功能 多点控制器( m u l t i p o i n tc o n t r o e r ，m c ) ：让3 个或以上的终端和网关能够参加同一个多 点会议的h 3 2 3 实体m c 也可以让只有2 个终端参加的点对点会议扩展成为多点会议 在m c 的协调下，参加会议的各个终端可以互相协商，从而确定参加会议所需的音频视 频数据的处理能力 5 h 3 2 3 网守呼叫转移功能的实现及研究 多点处理器( m u l t i p o i n tp r o c e s s o r , m p ) ：在多点会议中对音频，视频和或数据信号进 行集中处理的h 3 2 3 实体m p 在m c 的控制下工作，可以对信号进行混合、切换等操作 输入信号可以是单路的，也可以是多路的，e h m p 支持的会议类型而定 m p 年n m c - - 般集成到一个叫做多点控制单元( m u l f i p o i n tc o n t r o l lu n i t , m c u ) 的单一 部件中对m c u 而言，m c 是必备部件，m p 则是可选的 终端，网关和m c u 这些实体产生或者终止信号流，因此又统称为端点( e n d p o i n t ) 在配备有网守的v o i p 网络中，网守和所有注册到它的端点组成一个域( z o n e ) h 3 2 3 建议是独立于具体的底层网络的，但是要求网络有传输层或者类似的概念根 据h 2 2 5 0 建议，t c p i p i s p x i p x 都可以作为h 3 2 3 建议的底层协议本文完全是探讨 在网络上的网守功能，因此所谓传输层就是指t c p i p 协议中的t c p u d p 层，而不再加 以区分 网守在h 3 2 3 建议中不是一种必备设施事实上，由于小型网络通常采用i p 地址固定分配 的方式，因此各个端点可以直接和被叫方的传输层地址通信，此时的呼叫完全无需网守的参 与但是如果网络的规模比较大，又采用某种动态的口地址分配方案( 如d h c p ) ，以上方式在 应用上就会受到很大限制，因为端点很难准确地获得被叫方的网络地址在这种情况下，网守 就变得很有用了使用网守后，终端不再呼叫对方的网络地址，而是呼叫其符号化别名，而由 网守进行别名到网络地址的翻译网守的功能不仅限于进行简单的翻译，h 3 2 3 建议实际上是 把网守作为v o i p 网络的管理中心在网守上实现呼叫转移可以强化网守的管理功能 图2 1 表达了h 3 2 3 的系统结构，更多关于h 3 2 3 及相关建议的描述请参考h 3 2 3 系歹4 建议 6 第2 章相关h 3 2 3 过程分析 图2 1 ：h 3 2 3 系统结构 在以下的讨论中，我们总是假设处于一个配备了网守的v o i p 系统中 2 2 网守的r a s 信令功能 按照h 3 2 3 建议的定义，所谓r a s 是指注册，许可和状, 态, ( r e g i s t r a t i o n ，a d m i s s i o na n d s t a t u s ) h 2 2 5 0 建议定义了r a s 用到的消息格式，1 这些消息在端点和网守之间传递，执行注 册、呼叫许可、带宽请求、状态查询以及注销等过程r a s 信令的传输信道是不可靠的， 在i p 网络中，就是一条u d p 信道r a s 信道是最先建立的h 3 2 3 信道 1 描述消息格式时采用了抽象语义标记( a b s c r a c t s y n t a x n o t a t i o n ，a s n ) ，请参考拙象疆义标i l i 7 h 3 2 3 网守呼叫转移功能的实现及研究 r a s 消息封装在u d p 分组中进行传送，这些u d p 分组可以发送到网守的单播或者组播地 址其中组播地址是2 2 4 0 1 4 1 ：1 7 1 8 ，单播地址则是网守口地址：1 7 1 9 各种r a s 信令功能包括： 8 网守发现( g a t e k 8 叩e rd i s c o v e r y ) ：端点发送g r q ( g a t e k e e p e r r e q u e s t ) 消息，网守则应 答g c f ( g a t e k e e p e r c o n 触m ) 或者g r i ( g a t e k e e p e r r e j e c t ) 从而接受或者拒绝端点的注 册端点可以根据设置，选择向多播地址发送或者向某些特定的单播地址发送g r q 如 果多个网守都发h b g c f , 则由端点自行决定选择和哪个网守进行以后的操作 端点注册( e n d p o i n tr e g i s t r a t i o n ) ：注册时，端点发, m , r r q ( r e g i s t r a t i o nr e q u e s t ) 消息， 网守用r c f ( r e g i s t r a t i o n c o n f i r m ) 或者r 埘( r e g i s t r a t i o n r e j e c t ) 回应端点发送r r q 的 地址正是在网守发现过程中得到的网守r a s 地址，在注册过程中，如果网守拒绝端点 的注册，端点应该重新进行网守发现的过程端点注册的过程就是网守建立端点别 名与其呼叫信令地址的对应关系的过程，因此网守应该按照某种策略来应对别名和 呼叫信令地址不一致的情况，而端点也只允许同时向一台网守注册当端点不再需 要网守提供的服务时，发u r q ( u n r e g i s t r a t i o n r e q u e s t ) ，网守则发, m , u c f ( u n r e g i s t r a t i o n c o n f i r m ) 或者u r j ( u n r e g i s t r a t i o n r e j e c t ) ；网守也可以主动向端点发出u r q ，端点 收到这条消息后，只能回应u c f _ 呼叫许可( c a na d m i s s i o n ) ：当端点需要发起或者应答呼叫时，首先向网守发出a r q ( a d m i s s i o n r e q u e s t ) ，网守则回应a c f ( a d m i s s i o n c o n f i r m ) 或者a 埘( a d m i s s i o n r q e c t ) 来 允许或者拒绝呼叫的进行网守通过a c f 告诉端点被叫方的呼叫信令地址值得注意的 是，网守不一定在a c f 6 f l 包含对应a r q 中别名的呼叫信令地址，可以是另外的地址 呼叫结束( c a l ld i s e n g a g e m e n t ) ：端点在结束呼叫之前发出d i t q ( d i s e n g a g e r e q u e s t ) 给 网守，网守根据d r q 来释放在端点进行呼叫时可能分配的一些资源网守可以回应d c f ( d i s e n g a g e c o n f i r m ) 或者d 耐( d i s e n g a g e r e j e c t ) 造成网守回应d r j 的情况可能是因为 端点并没有在网守注册过 带宽请求( b a n d w i d t hc h a n g e ) ：在端点发出a r q 时，消息中包含了端点希望在呼叫进行 过程中得到的带宽，而网守则把实际分配的带宽在a c f 6 f l 确认呼叫进行过程中当端 点或者网守认为应该改变当前占用的带宽时，用b r q ( b a n d w i d t h r e q u e s t ) b c f ( b a n d w i d m c o n f i r m ) b r j ( b a n d w i d t h r e j e c t ) 进行协商如果网守用b r q 要求端点减少带宽 占用时，端点必须服从 端点定位( e n d p o i n tl o c a t i o n ) ：这是由端点的别名得到其对应的呼叫信令地址的一般机 制，端点或者网守都可以发起消息y 自l r q ( l o c a t i o n r e q u e s t ) l c f ( l o c a t i o n c o n f i r m ) l r j ( l o c a t i o n r e j e c t ) 和网守发现过程中用到的消息一样，端点定位消息可以发送到组 第2 章相关h 3 2 3 过程分析 播或者单播地址如果网守不知道组播：l r q 中请求的别名的呼叫信令地址，可以直接忽 略l r q ，反之则用l r j 回应由于h 3 2 3 建议没有规定多台网守之间的通信方式，因此一 些网守的实现就用端点定位消息来通信 状态查询( s t a t u sr e q u e s t ) ：为了了解端点的状况，网守可以发出i r q ( h f o r e q u e s t ) 消息， 端点则用i r r ( i n f o r 8 q u e s t r e s p o n s e ) 回应在要求严格的网络环境中，端点可以在i r r 消息中要求网守收到i r r 后进行回复，于是网守应该随后发出i a c k ( h f o r e q u e s t a c k ) 或 者i n a k ( l n f o r e q u e s t n a k ) 2 3 呼叫信令过程 当端点决定发起呼叫时，就涉及到呼叫信令过程呼叫信令过程是h 3 2 3 端点之间用呼叫 信令消息建立呼叫、进行通信、拆除呼叫的过程呼叫信令消息应该在可靠的通信信道上传 递，对i p 网络而言，这就是t c p 连接 呼叫信令消息的格式也在h 2 2 5 0 建议中定义但和r a s 消息不同，这些消息不是重新设 计，而是来自q , 9 3 1 和1 q 9 3 2 建议，h 2 2 5 0 对其进行了修改以适应h 3 2 3 通信的需要 每条q 9 3 1 q 9 3 2 消息包含若干信息元( i n f o r m a t i o ne l e m e n t ，) ，不同的消息就是信 息元的不同组合在不同的消息中，某些信息元必须出现( 必备) 而另外的可以不出现( 可选) h 2 2 5 0 呼叫信令消息沿用了这种结构，但有所取舍一些消息和信息元被采纳了，一些经过了 修改，其余的则被禁止在h 3 2 3 通信过程中出现这样，重要的信息元包括协议标识( p m t o c d d i s c r i m i n a t o r ) 、呼叫引用【( c a l lr e f e r e n c e ) 、消息类型( m e s s a g et y p e ) 等 列h 2 2 5 0 呼叫信令消息而言，这些信息元中最重要是用户一用户( u s e r - , u s e r ) 信息元( u u i e ) 在q 9 3 1 和q 9 3 2 h h ，u u i e 是可选的，目的就是传递一些用户自定义的信息h 2 2 5 o 充分利用 这一点，不仅把u u i e 习 为必备信息元，还定义了u u i e 的格式这样，h 3 2 3 实体之间就可以 互相传递呼叫信令消息来表达h 3 2 3 规定的各种通信语义了u c i e 中包含着呼叫信令消息的 大部分信息，因此当谈到这些消息时，更多的是指其u u i e 中携带的信息，而不是q 系列建议本 身规定的那些基本信息 h 2 2 5 o 信令消息包括： l e t u p ，一个h t 3 2 3 实体告诉被叫希望建立呼叫信令信道在s e t u p - u u i e 中，主叫方发送 呼叫类型、主叫的呼叫信令地址等，还可以包含主叫当前的通信能力 c a l lp r o c e e d i n g ，这条消息由被叫端点发出，表示请求的呼叫正在被处理，并且不能接受 新的呼叫c a l l p r o c e e d i n g - u u i e 最重要信息是h 2 4 5 地止，供呼叫双方建立h 2 4 5 信令信道在h 3 2 3 中，h 2 4 5 信令用来控制具体的话音、视频、数据信道的建立、使用 和拆除实现基于网守的呼叫转移不涉及h 2 4 5 唐道，因此本文只是简单提及 9 h 3 2 3 网守呼叫转移功能的实现及研究 1 0 a l e r t i n g ，被叫端点告诉主叫端点已经把呼入电话通知了被叫方的用户，也就是说被叫 正在振铃 c o n n e c t , 当被呼叫的用户拿起听筒后，被叫端点发出此消息告诉对方，呼叫已经建立完 毕至此，呼叫信令消息的功能已经基本完成，应该由h 2 4 5 消息进行下一步的控制 r e l e a s ec o m p l e t e ，呼叫双方都可以发出这条消息来表示拆除呼叫信令连接不过拆 除呼叫信令信道并不表示结束呼叫，因为呼叫双方进行实际通信的信道是h 2 4 5 控制 信道建立的，只要这些信道还存在，呼叫就可以继续当然，如果呼叫信令信道和各 个h 2 4 5 信道都关闭了，那么通信也就结束了h 3 2 3 允许呼叫双方提前关闭呼叫信令信 道 f a c i l i t y , 当主叫收到此消息时，意味着被叫不愿意接受该呼叫，而是让主叫去呼叫别的 端点主叫则只能用r e l e a s ec o m p l e t e 消息拆除呼叫信令连接，然后根据f a d l i 哆消息的 内容向别的端点发出新的呼叫当实现基于网守的呼叫转移时，会用到此消息 当网守用a c f 允许端点发出呼叫时，端点就在呼叫信令信道上发送呼叫信令消息 h 3 2 3 规定了几种呼叫模式，每种过程都对应着不同的呼叫信令过程： 第2 章相关h 3 2 3 过程分析 直接p 乎l l t t 模式，这是最简单的情况，如图22 这个 过程适用于端点对端点的直接呼叫而无需网守 的参与，当然也就无法使用网守提供的服务，而 且呼叫发起方必须在呼叫进行前就知道被叫方 的i p 地址如前面描述的，这种模式只适用于小型 的，i p 地址静态分配的网络 有1 台网守参与的直接呼叫模式，呼叫涉及的端点 都注册到同一台网守上，如图2 3 2 与直接呼叫相 比，这种模式下端点在呼叫前需要取得网守的许 可，呼叫结束后通知网守释放与该呼叫相关的资 源端点发起呼叫时，可以使用被叫在网守注册的 别名，而不必再使用被叫的i p 地址不过，此时网 守参与呼叫的程度有限，不能在呼叫过程中进行 进一步的干预，因此基于网守的呼叫转移功能很 难按照这种模式实现 有1 台网守参与的路由呼叫模式在这种模式下， 主叫端点的呼叫信令消息不再直接发给被叫端 点，而是发给网守，网守再假设自己是主叫端，向主叫端点 被叫端点 真正的被叫发出新的呼叫信令消息，如图2 4 这 图2 2 ：基本呼叫模式 就是所谓的“网守路由呼叫信令”要做到这一点， 网守向主叫端点发出a c f 消息中包含的应该是网 守自己的呼叫信令地址，同时在消息中注明采用路由信令方式建立呼叫网守不仅可 以路由呼叫信令，也可以路由h 2 4 5 控制信令，甚至其它所有的逻辑信道，即扮演一台软 件交换机的角色在这种情况下，呼叫双方可能完全不知道彼此真正的i p 地址，可以更 好地维护网络安全；同时，网守完全参与了呼叫的全部过程，可以对呼叫实施各种干预 g n u g k 把路由全部信令和实际通信的网守称为“h 3 2 3 代理”而本文要实现的基于网守 的呼叫转移功能，需要且仅需要网守路由呼叫信令 有2 台网守参与的路由呼叫模式这是比较复杂的呼叫模式，但有利于多台网守的协同 工作从图2 5 中看到，参与呼叫的端点各自向不同的网守注册当主叫发起呼叫时，其 所属的网守不知道被叫的呼叫信令地址，于是需要向别的网守询问，一般而言这个过程 用r a s 消窟, l r q l c f l r j 完成应答的网守返回的是自己的呼叫信令地址，因此主叫 所属网守就和被叫所属网守建立了呼叫信令信道，再由被叫所属网守与真正的被叫建 立最后一段呼叫信令信道在配置了大量端点的网络环境中，单台网守的处理能力和存 2 图中的r a s 消息前标有4 ，用来和呼叫信令消息相区别，下同 1 1 h 3 2 3 网守呼叫转移功能的实现及研究 1 2 储容量有限，因此需要使用多台网守h 3 2 3 规定的这种呼叫模式为这些网守协同工作 打下了基础，本文将要讨论的基于多台网守的呼叫转移就建立在该呼叫模式之上 第2 章相关h 3 2 3 过程分析 图2 3 ：有1 台网守参与的直接呼叫模式 图2 4 ：有1 台网守参与的路由呼叫模式 1 3 h 3 2 3 网守呼叫转移功能的实现及研究 1 4 图2 5 ：有2 台网守参与的路由呼叫模式 第3 章设计思路 本章分析实现基于网守的呼叫转移功能后网守具有的特性；以及如何利用前章的各 种 l 3 2 3 过程来实现这些特性 3 1 用户接口 由于呼叫转移功能是基于网守的，不要求端点具有任何h 3 2 3 的补充业务功能，因此必须 让最简单的端点也可以设置、使用和取消这项功能而终端最基本的功能就是拨号 设置呼叫转移的操作方式参考了普通电话即根据电话连接的交换机的设定，拨打特殊 的号码，交换机把该号码解释成用户在设置或取消呼叫转移网守在p b n 中扮演着和交换机 在s c n 中类似的角色由之前对r a s 功能的描述可知，端点发出呼叫之前，用a r q 征求网守 的同意a r q 包含着丰富的信息，其中一个域叫做d e s f i n a t i o n i n f o ，是主叫希望呼叫的被叫别 名( 相当于普通电话的被叫号码) ，在正常的处理过程中由网守翻译成呼叫信令地址在a c f 中 返回由于a r q 消息总要经过网守处理，网守当然也可以对某些特殊的被叫别名进行特别的 解释 用户拨打4 + 2 1 + x x x x x x x x 时，a r q 的d e s t i n a t i o n i n f o 域的内容即是“2 1 + x x ) ( x x ) ( ) ( x 网守会 收至i i f l a r q ，在判断出被叫别名以* 2 1 * 打头之后，立即进入呼叫转移的设置流程：去掉“2 1 + ， 把后面的x x x x x x x x 作为用户希望进行c f u 的目的端点别名，保存在发出a r q 的端点的相应 位置，即完成了c f u 的设置；如果去掉w 2 1 + 之后，得到长度为0 的符号串，则解释成用户在取 消c f u 设置，此时网守负责清除之前可能保存的c f u 目的端点的别名当然，如果用户反复设 置c f u ，则只有最后的设置生效如果被叫别名不是以”2 1 * 打头，则解释成用户在进行正常的 呼叫，按h 3 2 3 建议规定继续即可 在进行设置时，网守只是简单的进行记录或者清除，不作各种有效性检验包括转移目的 别名是否存在以及转移是否存在环路这样做的主要原因是在网络环境中，端点随时可以向 网守注册或者注销，如果设置转移时就检查目的端点的存在性，会由于目的端点暂时没有注 册而造成不能设置其为转移目标，使用上不方便j 同理，检查转移是否存在环路在转移经过的 所有端点都注册之前是无法进行的这些检测放在执行呼叫转移时才进行，后面会讲到 1 5 h 3 2 3 网守呼叫转移功能的实现及研究 以上只是交互过程的第一步，因为按照建议，网守应该用a c f a r j 回应a r q 因此网守 在记录用户设置的转移目标后必须按照建议合法地结束这次交互过程 表面上看，用户拨打这个特殊号码并不是真的在进行呼叫，只是进行设置，而网守也一定 找不到和a r q 中被叫别名对应的呼叫信令地址，似乎应该用a r j 拒绝此呼叫但是a r i 消息包 含了用户呼叫被拒绝的理由，端点接收到之后会给用户相应的提示( 例如在屏幕上显示一些文 字信息) 从h 2 2 5 0 规定的取值来看，没有一个理由适用于设置呼叫转移这种情形因此如果 简单地发出a r j ，会造成用户的困惑，不知道为什么被拒绝了( 虽然被拒绝的是呼叫，不是呼叫 转移设置) 然而这个呼叫又确实无法进行，如果不用a r i ) 巨绝呼叫，就应当用r e l e a s e c o m p l e t e q 巨绝 比较而言，后者更恰当一些 如果网守发出a c e 那么按照建议，接下来用户会试 图和a c f 中的呼叫信令地址进行连接此时网守工作在 路由信令的呼叫模式下，因此a c f 中返回的是网守呼叫 信令地址，于是主叫端点发出的s e t u p 实际上会到达网守 在s e t u p u u i e 中，仍然包含了被叫的别名，所以网守还 是可以识别出这些特殊的被叫别名，此时可以用r e l e a s e c o m p l e t e 消息立即结束这个呼叫 这种方式是我们需要的，因为r e l e a s e c o m p l e t e 也包 含用于说明呼叫结束理由的信息元( c a u s e i e ) ，其中一 个取值是n o r m a l c a l l c l e a r i n g ，表示呼叫正常结束，当 端点显示给用户这条理由时，用户比较容易接受，因为 呼q “正常”地结束了实际上q 9 3 1 还规定了一个信息 元d i s p l a y i e ，专门用于让接收的终端在输出设备上显示， 如果能在其中写入更明确的提示信息，可以让用户觉得 更加友好然而h 2 2 5 0 虽然沿用了这个信息元，却并不是 必备信息元，最终是否被显示由终端决定，从测试结果来 看，o h p h o n e 不, n 示r e l e a s e c o m p l e t e e f t 的d i s p l a y i e 普通固定电话是用特殊频率的声音信号提示用户设 置成功，因m e 最理想的办法是网守和用户建立一条临时的 话音通信信道，由网守向用户传送一段事先录制的音频告 诉用户设置成功后再自动结束呼叫，这段音频可以模仿普 通电话的提示音，也可以是人声从h 3 2 3 建议来看，实现 这一点是可行的，但是本文采用的是保存用户设置的转移 主叫端点网守 图3 1 ：设置呼叫转移的信令交互 过程 目标后用n o r m a l c a l l c l e a r i n g 作为理由发出r d e a s e c o m p l e t e 结束呼叫，r e l e a s e c o m p l e t e n 息不包含d i s p l a y i e 1 6 第3 章设计思路 综上所述，用户设置或者取消呼叫转移时的过程可以用图3 1 表示 c f b 和c f n r 的设置方式与c f u 类似，只是具体号码使用有所区别c f b 用* * 6 7 * x x x x x x x x ， c f n r 用+ 6 1 + x x x x x x x x 5 3 2 涉及一台网守的呼叫转移 当呼叫双方及呼叫转移路径经过的所有端点都只向同一台网守注册时，呼叫转移的处理 方式最简单，下面分别讨论 3 2 1c f u c f u 即无条件呼叫转移，所有针对进行了该设置的终端的呼叫都被转移到其设置的终端 可以在r a s 信令阶段实现这种转移 当用户发出正常的呼叫( 即不是拨打1 1 - 1 户接厂i 中规定的特殊被叫) 时，网守会按照h 3 2 3 建 议的流程进行处理，要实现c f u , 只需在进入这个流程之前对被叫别名进行替换，最后的结果 是网守在主叫和替换后的被叫之间建立呼叫，也就实现了c f u 由于任意端点都可以把任意字符串设置为自己的c f u 目标，所以在转移过程中必须进行 有效性检验，包括用户设置的转移目标是否存在以及连续c f u 是否形成了转移环路 本文讨论的呼叫转移采取“尽力转移”的策略，即按照用户的设置进行连续转移，最终呼 叫的端点是转移路径的终点( 即该端点没有设置c f u ) ，或者是最后一个合法的转移目标( 即该 目标在网守已经注册而且与转移路径在之前经过的任何一个端点都不相同) 如图3 2 1 7 h 3 2 3 网守呼叫转移功能的实现及研究 为了实现这样的策略， 每当转移要经过一个新的 别名前，首先网守的注册端 点列表中搜索对应此别名 的端点，没有找到说明期望 的转移目标没有在当前网 守注册，转移不再进行而 是到一个用于保存转移之 前经过的所有合法端点的 链表中搜索，找到相同的端 点就表明出现了环路，同样 不再继续转移下去如此反 复直到满足前面提出的转 移结束条件，把最后得到的 端点作为被叫继续呼叫 这个过程中要注意的 是检查转移环路时比较的 是指向端点的指针，而不是 端点的别名因为按照建 议每个端点可以拥有多 个别名，因此如果只是比 较别名的重复的话，可能 导致错误的判断例如端 点a 、b 、c ，a 1 1 乎i n b 的别名1 ， b 转向c ，c 再转向b 的别名2 ， 从别名来看没有重复，但事 实上已经形成了环路此 图3 2 ：c f u 流程图 外，在进行c f u 时得到的转移路径链表不能丢弃，因为在以后可能进行c f b 和c f n r 时，同样 需要判断转移是否形成了环路h 3 2 3 建议允许网守为呼叫设定时间上限，因此g n u g k 设置了 活动呼叫列表跟踪所有正在进行的呼叫，表中的每一项在对应呼叫的进行期间都会存在，因 此可以把这时得到的转移路径保存在对应的呼叫表项中供整个呼叫过程使用 从以上分析还可以看出，当被叫本身就没有注册时，网守发出a 耐拒绝呼叫，这是h 3 2 3 规 定的标准方式；但是只要被叫已经注册，那么不论c f u 如何设置，也不论其它端点的注册情况 如何，呼叫总是可以进行下去 1 8 第3 章设计思路 最后，本节讨论的是在一台网守上实现c f u ，所以当某个转移目标没有注册时，只是简单 地向已有的转移路径上的最后一个端点发出呼叫，而没有考虑向其它网守发出l 1 0 q 在讨论 涉及多台网守的呼叫转移时，会考虑改进这一点 3 2 2c f b c f b 是遇忙呼叫转移，即当被叫忙无法接听来话时，网守把呼叫转移到被叫预先设置的端 点去 实现c f b 最首要的问题是如何判断端点在“e ”前面讲到，h 3 2 3 建议允许为呼叫设定 时间上限，当呼叫持续时间到达此上限后就切断呼叫，从而释放网络资源供其它端点使用 g n u g k 支持这个特性，在实现时则用专门的数据结构存放当前活动的呼叫因此一个比较简 单的思路是网守和被叫建立呼叫信令信道之前，在这个呼叫列表中根据被叫查找，看是否有 呼叫已经涉及到此被叫如果找到，则被叫忙，执行c f b ；反之则正常呼叫 然而h 3 2 3 同时