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


7.3脚本在那里执行
用户可以在任何一个网络服务器上运行脚本,只要他们的呼叫确定请求可以通过,并且可以通过服务器建立互信的关系.举例来说,就象图[1]中描述的那样,起始用户在输出代理上运行一个脚本,目的地用户同时在伙伴服务器和部分服务器运行脚本.这些脚本通常是包含不同函数的,只是连接在它们所运行的服务器;在总服务器上运行的脚本可以用来定制用户希望找到的那部分,这样,不管脚本在哪个部分服务器,都可以使用.一些服务,比如过滤不想接收的呼叫,可以在任何的服务器上运行.详情请看9.3节.
这个模型不只指定了用户所在的网络服务器.大体上说,这可以通过它们所在的当地的Internet电话服务器注册它们自己;当然也可以通过外型指南,或者通过自动处理手段,就象本地服务协议[7].有人提议,上述服务器的自动处理手段应该包含一个区域,来判定是否答应用户升级他们的CPL.
8呼叫处理语言脚本的创建和传输
用户创建呼叫语言处理脚本,通常是在终端设备上,然后通过网络传输给信号服务器.脚本将坚持服务于信号服务器,知道被改变或者删除,除非它被赋予一个有效时限;支持CPL脚本的网络系统需要非常稳定的存储.
终端设备,用户以它为基础创建脚本,不需要承担任何到其他终端的连接,在那里呼叫被处理.例如,CPL脚本可能在PC上创建,但是,呼叫可能只设定为在电话上接收.事实上,以它为基础创建脚本的设备并不一定是终端设备.详情请看6.1.1;例如,用户可以在一个独立的终端上创建和升级一个CPL脚本.
CPL同样不需要在网上的终端设备和信号服务器四周的设备才能创建.例如,用户可以继续向前传递他或她的呼叫,传个更远的地方.
具体的方法,通过它可以传递脚本去服务器,还需要确定;还有好多方法需要进一步解决.建议的方法,包括网络文件升级,SIP注册信息的有效载荷,遥远方法的调用,SNMP,ACAP,LDAP,以及遥远文件系统,比如NFS.
用户可以得到当前脚本,不管是从网络,还是终端设备,从而进行编辑.信号服务器可以报告错误,并且与用户,脚本相连.静态错误可能在升级时被检测出来,运行的错误也可能发生.
用户可以相信与多重信号服务器之间的友好关系(详情请看7.3).用户可以选择升级任何一个服务器的脚本.这些脚本可能是完全独立的.
9特征冲突(interactions)操作
特征冲突是一个术语,通常是在电话系统中使用的,尤其是当两个或更多的请求特征发生冲突或是不明确时[8].特征冲突的重点:就是它在和呼叫处理脚本语言一起执行时,大致分成三类:同一个服务器上的特征--特征,同一个服务器上的脚本--脚本,服务器--服务器.
9.1特征--特征之间的冲突
由于前面几章中讨论的事情条件的清楚本质,特征--特征之间的冲突并不能算是一个问题,在呼叫处理语言环境中.然而,一个传统的电话特征的捐献者(subscriber),可能不会想到要同时预备对"呼叫等待"和"呼叫忙"服务,用户创建的CPL脚本只对一个行为有反应"当线路忙时,呼叫到达".
为了有利于创建而提供一个好的用户界面,或者提供一个CPL服务器可以在升级脚本时检测没有达到目的的代码,反对的条件/动作对是可能被避免的.
9.2脚本--脚本之间的冲突
只有当一个服务器为一个呼叫提供多重脚本时,脚本--脚本之间的冲突才会出现,就象7.2中讲的一样.这可能在下列情况中发生:假如呼叫发出者和目的地在各自不同的服务器上,有不一样的脚本;
当一个脚本向前传递一个请求时,那个地址有也有一个脚本;或者一个治理员级的脚本被认为是一个用户的脚本.
对这种冲突的解决方法,就是要在正在执行的脚本中决定一个顺序.在这个顺序中,"第一个"脚本最先执行;假如脚本答应呼叫代理,脚本传递到的另一方地址,同样会被执行.当"第一个"脚本向前传递请求时,这些在"第二个"脚本抵达的行为就会被认为是新的请求.当第二个脚本发送回复时,回复就会以相同的方式抵达第一脚本,就象呼叫抵达在网络之外.注重:在一些情况中,向前传递可能会是递归的,CPL脚本一定要对向前(foreWord)的循环非凡小心.

推荐阅读