rfc2824.txt

RFC文档

由于CPL是一种标准化的语言,因此它可以允许第三方来创建或者定制服务,为了客户端服务.这些脚本既可以在终端用户所属的服务器上执行,也可以在服务提供者上执行.

@管理员的服务定义

服务器的管理员同样可以使用CPL,建立一些简单的服务,或者可以他们所控制的服务器的方针.如果服务器正在执行CPL服务,那么就需要延伸服务构架,使得管理员可以象用户一样创建脚本.

@WEB中间设备

最后,这里为创建服务以及用web界面定制服务,提供几条建议.下列环境中,CPL可以用后--尾(back--end):为了使用者的利益,一个网络应用程序可以自行建立一个CPL脚本,然后电话服务就可以执行服务,而不需要理解其他相关的细节.

5CPL的构造

    CPL脚本的创建其实还有很多方法.就象HTML有很多中构造方法一样,我们可以为一个CPL脚本构想很多中构造方法.

@手动

实在是相当的简单直接,CPL的脚本是可以由有一定知识的用户手动编写的.[5]中所描述的CPL,可以用文本方式以一种并不复杂的方式描述,因此手动编写也是相当方便的.

@自动操作脚本

CPL的控制可以由自动操作的方法来创建,举个例子,就象前面所描述的网络中间件.用一个简单的,以文本方式为语法的,标准的文本处理语言,就可以非常简单的编辑CPL脚本.

@图形用户界面工具

最后,用户可以使用图形用户界面工具来编辑CPL脚本.我们希望,如果CPL变的流行的话,大多数中等水平的用户可以使用这种方法.事实上,CPL很快就会用这个工具来开发,以后,脚本语言强有力的表达能力就会简单用图形方法表现出来.

6网络模型

    呼叫处理语言是要在一个基础上工作的,所谓的基础就是要以一个标准的Internet电话网络模型.尽管多种协议的细节会出现不同,但抽象的说,所有主要的Internet电话网络构架都是十分相似的,它们的主要特点都相差不多.这篇文档主要使用了SIP术语,因为它的经验与协议的都一样.

6.1模型组成

    在呼叫处理语言的网络模型中,Internet电话网络包含两个部分.

6.1.1终端系统

    终端系统是一种设备,它可以产生或者接收信号信息和媒体.它包含简单,复杂的电话设备,PC电话客户端,自动语音系统.CPL抽象理解,不用理会这些设备的细节性能.一个终端系统可以发出一个呼叫,同时也可以接收,续传或者舍弃一个呼叫.过程的细节(响铃,多重接线,等等)对于CPL来说,并不重要.

    出于对CPL的目的性,网关--举例来说,一个设备可以连接IP电话网络和PSTN--同样可以认为是一个终端系统.其他设备,比如混合器,防火墙,并不直接由CPL控制,所以这里暂不讨论.

6.1.2信号服务器

    信号服务器是一种设备,它可以暂缓或者控制信号信息.在SIP中,它们是代理服务器,重寄服务器,或者是注册器;在H.323中,它们就是网关.

    在执行安装信息时,信号服务器有三种事情要做.它们可以:

代理:向前将信息继续传递给其他网络,或者其他终端,或者可以将回复传回.

重寄:将一个回复信息传回给发送请求的那个服务器.

舍弃:通知正在发送的系统,安装请求并没有完成.

    RFC[2543][1]有代理和重寄的详细功能说明.终端系统有时也可以完成其他操作:完全拒绝与可能重寄.

    信号服务器也可以正常的断定用户的位置.不管是用注册方法(SIP注册,或者H.323RAS信息),静态构造,还是动态搜索,信号服务器一定要确定一种方法,通过这种方法,它可以确定用户当前的具体位置,并以次来决定是代理,还是重寄.

6.2成分冲突

    当终端设备处理一个呼叫,呼叫的实施请求可以处理多线称,通过网络的各个组成.开始时,起始的终端设备一定要先决定向那里发送请求.有两种可能性:发起人可能由于某种配置,那么它所有的请求都会发送到一个单一的当地的服务器;或者也有可能改变目的地地址,查找远方的信号服务器或者终端,以便找到向那里发送.

    一旦请求到达信号服务器,服务器就会使用它当地的用户的数据库,它的当地的方针,DNS决议,或者其他方法,来决定向下一个发送服务器或者终端系统.一个请求可能会经过几个信号服务器:从零开始(如果终端系统直接相连的化),按理来说,传递到其他信号服务器.另外,终端系统或者信号服务器(按理来说)都可以接收或者发送请求给其他任何一个.

    例如,第一种情况(图[1]),有两条可供呼叫信息选择的路径,对于第一条路径,呼叫发出者只知道一个用户的地址,因为这个用户正在试图连接,并且它被配置成向外发送信息,通过本地的一个向外发送代理服务器.因此,它会把请求传给当地的服务器,服务器可以通过地址,找到要发往的那个服务器,然后把请求传过去.

    如果是这样,目的地用户组织就可以使用多重配置来寻找用户.社团服务器会识别这个用户是那个部分的,然后把请求发给它所属部分的服务器,而用户就在当地服务器附近.(这与经常配置的电子邮件路由是相似的)对于这个请求的回复会按照原路返回.

    但是,对于第二条路径,呼叫发出者知道它正试图连接的特殊设备的地址,并且它没有设置成使用本地向外发送代理服务器.这种情况时,呼叫发出者就会直接连接目的地,而不通过任何服务器中转.

    那么,我们可以考虑一下,Internet电话信号服务器通常并不了解他们所"控制"的终端设备的状态,因为信号信息可能只是把它当成中转.由于结构学的局限性,造成了一些服务在执行时,会有很多限制.举例来说,网络系统并不可能确实的知道一个终端系统是忙还是闲;呼叫也可能根本不通过网络直接传递.因此,信号信息一定要明白的传递给终端系统来判定它们的忙闲;比如终端系统会恢复一个忙的信号.


      向外发送                              伙伴                区域
        代理                              服务器               服务器
       _______  输出代理连接               _______            _______
       |     |     伙伴服务器              |     |            |     |
       |     | -------------------------> |     | ---------> |     |
       |_____|                            |_____|            |_____|
Route 1   ^                                                    \寻找用户
         /                                                      \   
发送给代 /                                                        \ 
理服务器 /                                                         _|
   _______                                                      _______
   |     |   Route 2                                            |     |
   |     | ---------------------------------------------------> |     |
   |_____|      起始者直接连接目的地                             |_____|

  起始端                                                         目的地
图[1]:呼叫传递的可能路径

7CPL与网络模型的交互

7.1脚本的作用

    CPL脚本是在信号服务器上运行的,控制方面:比如代理,重寄以及遗弃都是为了特殊的呼叫.它并不试图改变或调整多重信号服务器的行为,或者象"GLOBAL FUNCTIONAL PLANE"只能网络构架[6]中描述的那样.

    更多细节,脚本信号服务器的用户坐标功能.就象6.1.2中描述的那样,信号服务器通常可以确定用户通常使用的本地的数据库.CPL脚本取代了这种基本数据库查找功能;它能够提供注册信息,呼叫请求的细节,以及它想查找的额外信息,并且还可以选择那些信号动作来执行.

    理论上,脚本可以看做是条件/动作对的列表;如果注册,请求,额外信息的一些特征,与已知的条件相符,然后相应的动作(或者其他合适的动作集合)就会被执行.在这些环境中,以第一个动作和其他辅助动作为结果的附加动作会被执行.如果没有条件符合请求,信号服务器的标准动作--当地的数据库查找,举例--会被执行.

7.2哪一个脚本在执行

    CPL脚本通常是与特殊的Internet电话地址相连的.当一个呼叫确立的请求到达了CPL服务器时,那么那个服务器相连的资源,与目的地的地址,就是CPL脚本的数据库请求中列出的;如果一个匹配,相应的脚本就会被执行.

    一旦脚本被执行,如果它已经选择要执行一个代理动作,一个新的Internet电话地址就会作为代理的目的地.一旦事情发生,那么服务器就会重新检查脚本的数据库,看看是否还有其他相关的地址;如果有,那么脚本就会被执行(声明脚本不会尝试去代理发送给一个服务器已经连接过的地址).如果想深入了解这个过程的细节,以及一个服务器运行脚本时到底做了些什么,也就是脚本起始地址与目的地地址的关系,请看9.2.

    大体上说,在Internet电话网络中,一个地址就意味着两件事:用户或者设备.用户的地址涉及到特殊的个体;例如sip:[e-mail],不管那个用户现在在那里,或者他或她在使用什么样的设备.设备地址,相比较而言,涉及到一个特殊的物理设备,例如:sip:[e-mail].另外,中间(intermediate)的地址类型同样是可行的,并且有一定的用途(比如一个地址"我的电话,不管它在那里,它已经注册了.").但我们不希望它们频繁使用.CPL脚本对于当前所连接的地址类型是不知道的;让脚本与用户地址相连是大多数服务器的工作,所以没有理由让脚本与其他形式的地址相连.递归的作用过程允许一个脚本与几个用户地址相连;因此,一个脚本可以执行一个动作"试着在我的电话上执行.",而一个设备脚本则可以说"如果我不在家,就不接听电话."

    对于一个CPL脚本而言,也可以不只与一个特殊的Internet电话地址相连,而是与整个信号服务器所有的地址相连,或者与更大的集合相连.例如,管理员可以配置一个防止呼叫的系统,或者列出一个禁止呼叫的地址清单;这就会对所有人都适用,但同时,用户还是拥有他自己的常用脚本.准确的说,当这种脚本要在递归过程中执行时,它就要准确的按照管理员的脚本执行.9.2节有详细论述.

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)的循环特别小心.

    理论上,这也可以看成是互不相连的服务器上执行各自的脚本.由于CPL脚本的构架设计成允许脚本在多重信号服务器上执行,在寻找用户期间,概念上,我们可以把脚本--脚本之间的冲突转变为服务器--服务器之间的冲突,就象下部分中讲的那样,应该尽量减少我们需要面对的冲突种类.

    接下来,要解决的问题,就要将脚本正确的进行排序.为了处理这样一种情况,当一个脚本向一个地址传递时,该地址同时有另外一个脚本,顺序是明显的;另外的一些情况就较为敏感了.当起始者和目的地同时有两个脚本,起始者的脚本应该在目的地的脚本执行前执行;这就意味着起始者可以做地址传输,呼叫过滤,等等,在目的地地址和顺序被确定之前.