呼叫处理语言的构架与必要条件( 四 )


那么,我们可以考虑一下,Internet电话信号服务器通常并不了解他们所"控制"的终端设备的状态,因为信号信息可能只是把它当成中转.由于结构学的局限性,造成了一些服务在执行时,会有很多限制.举例来说,网络系统并不可能确实的知道一个终端系统是忙还是闲;呼叫也可能根本不通过网络直接传递.因此,信号信息一定要明白的传递给终端系统来判定它们的忙闲;比如终端系统会恢复一个忙的信号.
向外发送伙伴区域
代理服务器服务器
_______输出代理连接______________
伙伴服务器
------------------------->--------->
_______________
Route1^寻找用户
/
发送给代/
理服务器/_
______________
Route2
--------------------------------------------------->
_____起始者直接连接目的地_____
起始端目的地
图[1]:呼叫传递的可能路径
7CPL与网络模型的交互
7.1脚本的作用
CPL脚本是在信号服务器上运行的,控制方面:比如代理,重寄以及遗弃都是为了非凡的呼叫.它并不试图改变或调整多重信号服务器的行为,或者象"GLOBALFUNCTIONALPLANE"只能网络构架[6]中描述的那样.
更多细节,脚本信号服务器的用户坐标功能.就象6.1.2中描述的那样,信号服务器通常可以确定用户通常使用的本地的数据库.CPL脚本取代了这种基本数据库查找功能;它能够提供注册信息,呼叫请求的细节,以及它想查找的额外信息,并且还可以选择那些信号动作来执行.
理论上,脚本可以看做是条件/动作对的列表;假如注册,请求,额外信息的一些特征,与已知的条件相符,然后相应的动作(或者其他合适的动作集合)就会被执行.在这些环境中,以第一个动作和其他辅助动作为结果的附加动作会被执行.假如没有条件符合请求,信号服务器的标准动作--当地的数据库查找,举例--会被执行.
7.2哪一个脚本在执行
CPL脚本通常是与非凡的Internet电话地址相连的.当一个呼叫确立的请求到达了CPL服务器时,那么那个服务器相连的资源,与目的地的地址,就是CPL脚本的数据库请求中列出的;假如一个匹配,相应的脚本就会被执行.
一旦脚本被执行,假如它已经选择要执行一个代理动作,一个新的Internet电话地址就会作为代理的目的地.一旦事情发生,那么服务器就会重新检查脚本的数据库,看看是否还有其他相关的地址;假如有,那么脚本就会被执行(声明脚本不会尝试去代理发送给一个服务器已经连接过的地址).假如想深入了解这个过程的细节,以及一个服务器运行脚本时到底做了些什么,也就是脚本起始地址与目的地地址的关系,请看9.2.
大体上说,在Internet电话网络中,一个地址就意味着两件事:用户或者设备.用户的地址涉及到非凡的个体;例如sip:joe@example.com,不管那个用户现在在那里,或者他或她在使用什么样的设备.设备地址,相比较而言,涉及到一个非凡的物理设备,例如:sip:x26063@phones.example.com.另外,中间(intermediate)的地址类型同样是可行的,并且有一定的用途(比如一个地址"我的电话,不管它在那里,它已经注册了.").但我们不希望它们频繁使用.CPL脚本对于当前所连接的地址类型是不知道的;让脚本与用户地址相连是大多数服务器的工作,所以没有理由让脚本与其他形式的地址相连.递归的作用过程答应一个脚本与几个用户地址相连;因此,一个脚本可以执行一个动作"试着在我的电话上执行.",而一个设备脚本则可以说"假如我不在家,就不接听电话."
对于一个CPL脚本而言,也可以不只与一个非凡的Internet电话地址相连,而是与整个信号服务器所有的地址相连,或者与更大的集合相连.例如,治理员可以配置一个防止呼叫的系统,或者列出一个禁止呼叫的地址清单;这就会对所有人都适用,但同时,用户还是拥有他自己的常用脚本.准确的说,当这种脚本要在递归过程中执行时,它就要准确的按照治理员的脚本执行.9.2节有具体论述.

推荐阅读