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


12.2基本特征--呼叫信号
为了使自己有效利用,呼叫处理语言一定要能够对呼叫信号事件产生反应,并且能够创造信号事件.
@当呼叫到来时,可以操作动作
详情请看[7],非凡是[7.1]
@应该能够依照事情的特点做决定
呼叫事件的许多特点都与脚本决定进程有关.下面的这些,只是为了强调它的重要性:
-目的地地址
我们希望能够以目的地为基础来安排路由.声明:在SIP标准中,我们希望能够过滤每一个地址,非凡是在所需的URL中.
-起始地址
相似的,我们希望能够以起始端为基础安排路由.
-呼叫者的参数选择
在SIP标准中,呼叫者可以表示关于将要抵达设备类型的参数选择--详情请看[11].脚本应该可以按照相关的信息做决定.
-关于呼叫者或呼叫的信息
SIP拥有原文区域,就象主题,团体,和优先级等等,以及一个可以确定地址的名字;用户同样可以添加一些不标准的标题.H.323有一个单独的播放区域.脚本应该可以以参数为基础做决定.
-多媒体描述
呼叫邀请可以具体列出将要流动的媒体类型,它们带宽的用法,它们的网络目的地的地址,等等.脚本同样可以以媒体特征为基础做决定.
-证实/密码术状态
呼叫邀请应该是可以鉴别的.证实的许多道具都是相互关联的:证实/密码术的方法,执行证实的人,加密的非凡区域,等等.脚本会通过这些安全参数做决定.
@以呼叫邀请为基础,采取行动
为了回复引入的呼叫建立请求,我们可以采取很多响应的办法.我们可以:
-舍弃
我们要指出那个呼叫是不被答应的,或者是不能完成的.我们还可以发出更多的具体的舍弃代码,(包括,关于SIP,相关原文的字符串,警告代码,以及信息的有效载荷).
-重寄
我们可以告诉呼叫创始人,试试另一条路.
-代理
我们可以把呼叫邀请发送给另一个坐标,或者其他一些地方("分叉"的请求),等候回答.当然,也可以具体列出一个时间值,在那个值之后,我们将放弃接收回复信息.
@以回复代理或者分叉邀请为基础,而做动作
一旦我们代理了一个邀请,我们就要按照我们接收到的请求做决定.我们应该这样做:
-考虑信息区域
我们应该考虑相同的回复区域,就象我们考虑原始请求一样.
-延迟呼叫起始者
假如回答是令人满足的,它就应该发送回给发送者.
-对于一个叉路,选择一个延迟回复的
假如我们将请求分叉,我们就是想得到几个回复.这有几点要注重:从中选择回复,假如我们只接收到一个回复,但却不是所有的,那就要等,但要注重要等多久.
-起始其它行为
假如我们接收不到回复,或者我们喜欢,我们就应该试试其它的.(例如,在忙是向前续传)
12.3基本特征--无信号
呼叫处理语言有很多其他的特征,跟呼叫信号本质上是没有关系的;但是,它们也是极其想要执行更多的有效的特征.
提供这些特征的服务器可能是在其他Internet设备中,或者就在服务器里(或者还有其他可能性).这些语言独立与它们所在的服务器,起码是在更高的级别上.
@搬运
作为CPL服务器自然移动事件的补充,用户也就会希望可以移动其他物件.为移动信息所建的存储库可以在本地机,也可以在更远的机器上.
@错误报告
假如一个未曾预料的错误发生了,脚本就一定要能够向脚本所有者报告错误.这和脚本服务器用来向用户报告错误的机制是相同的.(详情请看12.5)
@对用户本地信息的使用
代理服务器通常会收集用户本地的信息,通过SIP注册信息,H.323的全部信息,或者其他有些机制(详情请看6.2).CPL是与这个信息相关的,因此呼叫可以向前续传到注册的地址,或者是它的子集.

推荐阅读