rfc2824.txt

RFC文档

    更为复杂的情况是要确定管理员级的脚本.许多管理员级的脚本,比如,某些限制资源和目的地地址的管理员级脚本,需要在起始者之后执行,在目的地之前执行.这主要是为了防止用户脚本越过管理员级脚本;但是,另外的情况中,比如全球的地址转移功能,就需要或早或晚的执行.允许服务器级脚本运行的服务器就得要管理员来配置,尤其是当脚本执行过程中,特殊的管理员级脚本可能会失败.

9.3服务器--服务器之间的冲突

    第三种情况的特征交互性,服务器--服务器之间的冲突,是三种之间最复杂的.这种冲突中,规则的例子如下,就是起始呼叫和继传的冲突:用户(或者是管理员)可能不想让呼叫传到某个特殊的地址,但是当地的脚本可能并没有这项功能,它并不知道呼叫将传往何处,合法的地址将被代理传输给较远的服务器,同样可以传输到一个被禁止的地址.这种类型的问题,即使在管理员级的网络中也不能够解决,就算是较低级别的网络,就象现存的电话网中也不能够解决.CPL还没有声明对它的解决方法,当然这个问题也并非只对CPL脚本产生效应,它对所有研发服务都有害.

    服务器--服务器之间的冲突的另外一个类型,被下面的信号协议很好的解决了.因为它们可以升级,不管这个信号服务器是不是被呼叫处理语言或者其他方式控制.举一个例子,就是向前的循环,假设某个地方,用户X想把呼叫继续向前传给用户Y,而Y又会把它传回给X.SIP有一个机制,可以检测这种续传循环.因此,呼叫处理语言服务器根本不需要定义特殊的机制来防止这种情况的发生;但是,还是会引发不同形式的呼叫处理行为,在那里循环被发现,然后就发回一个错误信息给脚本的所有者,通过一些标准的错误回报机制.

9.4信号模糊

    补充说明,[8]讨论得出了电话网络中的第四类型的特征冲突,信号模糊.这通常会发生在这样一种时候,当若干个特征过载一个相同操作,在一个从终端出发的有限信号路径,在一个网络中:快速转变(switch--hook)同时意味着两样东西.一个是"增加一个第三方",另外一个是"转向呼叫等待".由于Internet电话协议的信号的外在特性,就象上面讨论的那样,这种情况应该不会发生.

10同现有语言的关系

    这篇文档将CPL描述成语言,并不是有意要暗示,一门新的语言就必须要用工具操作.服务器可以操作所有上述功能,就象是现存语言的图书馆或者是扩展;java以及其他各种脚本语言(TCL,PERL,PYTHON,GUILE).都是明显的可能.

    但是,创建一种新语言有很多动机.所有现存语言都是一样的,自然的,完整的;但是有两个天然的缺点.第一个缺点,任何功能的执行,都要花很长的一段时间,使用相当大的记忆库,并且从不能间断.对于呼叫处理,这种资源使用方法是不必要的,就象12.1的描述的那样,实际上是不可信的.相关的模型,电子邮件过滤语言服务[4],有意与图灵机区别.

    相似的安全与保护级别(尽管不是自动的,也不能分析),同样可以完成,但是要通过一个"沙盒子"(sandbox),就象java中的Java applets.在那里,对一切的要求都很严格,比如存储容量,中央处理器的周期,堆栈空间,等等,只要程序用的到的,都做了规定.这个方法的难点就在于,它从根本上的不透明和不够方便:除非这些级别都严格按照标准,现在有个并不好的消息,就是程序占用的空间成摩尔数量级的增长,因此,用户永远都不能确定到底哪个程序可以在指定的服务器上执行,而不耗光系统资源,并且一个在某台服务器上可以执行的程序,可能到了另一台就不会象想象中的那么好用.不能完整表示的语言,换句话说,就是允许脚本作者与服务器之间有协定:在脚本符合语言规范的同时,服务器一定要保证能够运行脚本.

    第二个缺点,对于能完整表示的语言来说,它们能让脚本自动,分析,但却相当的麻烦.正如每一个分析工具都有自己的翻译语言.因此,可以从文档编写世界里得到一个规律:如果文档的组成语言象HTML或者XML一样,并且可以被熟练的人员轻松编写,强有力的文档编程语言,象LaTeX或者 Postscript通常是用不到的.当然,现在有字处理系统可以以LaTeX格式保存文档, 但决不能接受任意写入的LaTeX文档,不管原文档的格式,构架.相比较而言,任何一个HTML编辑者都可以通过网络来编写HTML文档,其中高质量的一些还可以在编辑其他文档的同时保留它们的格式.

11相关工作

11.1在服务创建环境中

    国际电信联盟,对服务创建环境[8]作了抽象的描述.所描述的服务都是在传统的交换电话网络中进行的,就象一个非循环图中的能够涉及到的行为和决定.许多网络服务的主顾,使用更改过的或是升级过的版本,为了它们所有者的服务创建环境.

11.2SIP CGI(详解网关接口)

       网关借口[9]是SIP服务器操作服务的接口.跟CPL不同,它是一个非常低级的接口.因此对于那些并不可信的用户所写的服务并不能合适的运行.

    第十页上讲的"网络电话服务编程"(Programming Internet Telephony Services)详细的讨论了SIP CGI 与CPL 的相似与不同之处.

12必要的语言特征

    这部分列举了呼叫处理语言的几种工具,我们相信它们对于执行命令是必要的.并且与所描述的构架相符. 

12.1语言特征

    这里列举了一些抽象的特性,是所有被提议的呼叫处理语言都应该具有的.

@体积小,效率高,易执行

    为什么这点是必须的呢?作为对这个问题答案的补充,网络服务器应该能够处理体积巨大的呼叫,但我们不希望CPL的执行成为一个大瓶颈.达到这个目的的有效方法之一,就是在执行之前先编译它.

@容易实现

    对于一个在服务器上运行的脚本,不合理的构造就会导致用户不能到达,或者使运行时期的错误显示变的困难(尽管双信道的机制可以缓解这个问题,就象电子邮件一样).因此,它应该是易于检验的,当脚本连接到服务器,那么它在语句上至少是合法的,并且没有明显的循环和错误模式,同时也不会占用太多的系统资源.

@在安全模式下执行

    CPL脚本所做的任何行为,都不会使服务器产生混淆,对于那个服务器来说,用户是不可以访问的,或者没经过允许就影响其他用户的状态.作为补充说明,因为CPL脚本通常是在服务器上运行的,而用户是不可以在那上面运行普通代码的,因此,每一种语言以及它的运行环境都要经过精心设计,这样脚本才不会占用太多的网络资源,服务器的中央处理器的周期,存储系统和记忆体.

@机器和人都可以轻松的编写和分析

    为了有最大的适应性,我们希望可以允许用户自行编写他们自己的脚本,或者通过定制来修改别人的脚本,使之成为自己的.但是,大多数用户对于同一样功能的函数都希望设立了相同的接口,然后有一个相关的程序可以专门为它创建脚本.这两种建议都会很好的实现它:特殊情况中,对于脚本编辑器来说,分析人编写的代码和机器自动生成的代码都很容易.

@扩展

    想要给一种语言添加些特性并不难,但要保证一件事,那就是现存的脚本可以继续工作,现存的服务器可以很容易的识别出那些他们不了解的特征,并且把事情通知给用户.

@相互独立的信号细节

    只要脚本相同,就应该一样可以使用,不管是按照什么协议指定的:SIP也好,H.323也好,普通的电话网络,或者是其他一些建立呼叫的方法.脚本它同时也应该不清楚地址的格式.(在需要进行语言描述时,我们采用SIP的术语,但对于其他系统,它也一样可以很简单的,容易的使用.)对于把语言扩展成为其他形式的交流也一样很有用,就象电子邮件和传真.

12.2基本特征--呼叫信号

    为了使自己有效利用,呼叫处理语言一定要能够对呼叫信号事件产生反应,并且能够创造信号事件.

@当呼叫到来时,可以操作动作

    详情请看[7],特别是[7.1]

@应该能够依照事情的特点做决定

    呼叫事件的许多特点都与脚本决定进程有关.下面的这些，只是为了强调它的重要性:

-   目的地地址
    
    我们希望能够以目的地为基础来安排路由.声明:在SIP标准中,我们希望能够过滤每一个地址,特别是在所需的URL中.

-   起始地址

    相似的,我们希望能够以起始端为基础安排路由.

-   呼叫者的参数选择

    在SIP标准中,呼叫者可以表示关于将要抵达设备类型的参数选择--详情请看[11].脚本应该可以按照相关的信息做决定.

-   关于呼叫者或呼叫的信息

    SIP拥有原文区域,就象主题,团体,和优先级等等,以及一个可以确定地址的名字;用户同样可以添加一些不标准的标题.H.323有一个单独的播放区域.脚本应该可以以参数为基础做决定.

-   多媒体描述

    呼叫邀请可以详细列出将要流动的媒体类型,它们带宽的用法,它们的网络目的地的地址,等等.脚本同样可以以媒体特征为基础做决定.

-   证明/密码术状态

    呼叫邀请应该是可以鉴别的.证明的许多道具都是相互关联的:证明/密码术的方法,执行证明的人,加密的特殊区域,等等.脚本会通过这些安全参数做决定.

@以呼叫邀请为基础,采取行动

    为了回复引入的呼叫建立请求,我们可以采取很多响应的办法.我们可以:

-   舍弃
  
    我们要指出那个呼叫是不被允许的,或者是不能完成的.我们还可以发出更多的详细的舍弃代码,(包括,关于SIP,相关原文的字符串,警告代码,以及信息的有效载荷).

-   重寄
    
    我们可以告诉呼叫创始人,试试另一条路.

-   代理

    我们可以把呼叫邀请发送给另一个坐标,或者其他一些地方("分叉"的请求),等候回答.当然,也可以详细列出一个时间值,在那个值之后,我们将放弃接收回复信息.

@以回复代理或者分叉邀请为基础,而做动作

    一旦我们代理了一个邀请,我们就要按照我们接收到的请求做决定.我们应该这样做:

-   考虑信息区域

    我们应该考虑相同的回复区域,就象我们考虑原始请求一样.

-   延迟呼叫起始者

    如果回答是令人满意的,它就应该发送回给发送者.

-   对于一个叉路,选择一个延迟回复的

    如果我们将请求分叉,我们就是想得到几个回复.这有几点要注意:从中选择回复,如果我们只接收到一个回复,但却不是所有的,那就要等,但要注意要等多久.

-   起始其它行为

    如果我们接收不到回复,或者我们喜欢,我们就应该试试其它的.(例如,在忙是向前续传)

12.3基本特征--无信号

    呼叫处理语言有很多其他的特征,跟呼叫信号本质上是没有关系的;但是,它们也是极其想要执行更多的有效的特征.

    提供这些特征的服务器可能是在其他Internet设备中,或者就在服务器里(或者还有其他可能性).这些语言独立与它们所在的服务器,起码是在更高的级别上.

@搬运

    作为CPL服务器自然移动事件的补充,用户也就会希望可以移动其他物件.为移动信息所建的存储库可以在本地机,也可以在更远的机器上.