RFC2824 呼叫过程语言框架和要求

组织：中国互动出现网 (http://www.china-pub.com/)
  RFC文档中文翻译计划 (http://www.china-pub.com/computers/emook/aboutemook.htm)
  E-mail: ouyang@china-pub.com
译者：robert_7 (robert_7)
译文发布时间：
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须保留本文档的翻译及版权信息。

Network Working Group                                          J. Lennox
Request for Comments: 2824                                H. Schulzrinne
Category: Informational                              Columbia University
                                                                May 2000

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

备忘录概要

    这篇备忘录是为了Internet主要提供信息.它并没有详述某一种Internet的标准.因此,它的适用范围是无限制的.

版权声明

    Copyright (C) The Internet Society (2000).  All Rights Reserved.

概要

    由于Internet电话服务需要信号操作的完美结合,我们希望尽可能提供更多的服务,通常是依靠网络设备来完成.我们希望能用一种简单,并且标准的方法来解决这个问题,建立上述需要的服务,并且最好使它们容易操作和升级.这篇文档描述了关于这种机制的一种建筑学的构架,我们给这个构架命名为呼叫处理语言.同时也介绍了这种语言的一些必要条件.

内容目录

1       介绍               ......................................................2
2       术语               ......................................................3
3       关于服务的一些例子  ......................................................4
4       用法简介           ......................................................6
5       CPL的构造         ......................................................6
6       网络模型           ......................................................7
6.1     模型组成           ......................................................7
6.1.1   终断系统           ......................................................7
6.1.2   信号服务器         ......................................................8
6.2     成分冲突         ......................................................8
7       CPL与网络模型的交互.....................................................10
7.1     脚本的作用         .....................................................10
7.2     哪一个脚本在执行    .....................................................11
7.3     脚本在那里执行     ......................................................12
8       呼叫处理语言脚本的创建和传输..............................................12
9       特征冲突操作      .....................................................13
9.1     特征--特征间冲突  .....................................................13
9.2     脚本--脚本语言冲突.....................................................14
9.3     服务器--服务器之间的冲突...............................................15
9.4     信号模糊            ....................................................15
10      同现有语言的关系    .....................................................15
11      相关工作           .....................................................17
11.1        在服务创建的环境中  .....................................................17
11.2    详解网关接口        .....................................................17
12      必要的语言特征      .....................................................17
12.1    语言特性            ....................................................17
12.2    基础特征--呼叫信号   ....................................................19
12.3    基础特征--无信号     ....................................................21
12.4    语言特征             ...................................................22
12.5    控制                ....................................................23
13      安全策略            ....................................................23
14      感谢                ....................................................23
15      作者地址            ....................................................23
16      参考书目            ....................................................24
17      完全版权声明         ...................................................25

1介绍

    现在,一些协议已经被创建出来,来允许把电话通信转变成IP网络,尤其是SIP[1],和H.323[2].这些现存的标准协议,将电话服务的分配进行了广阔并且成地区集中的分布,以便于使用者可以控制它们.

    许多Internet电话服务可以,或者说应该在它们的终端设备上进行操作.比如说,会议通话,或者占线等待中的忙音,或者集中服务都是完全依靠终端系统的状态,和细节流的具体内容,以及那些只有对终端系统有效的信息.多种多样的服务,但是--有一些服务被用户所在的地区限制,所以在终端系统忙是,就得呼叫分类操作,等等--是不依赖与某个特殊终端设备的,或者需要操作,即使是这个终端设备 并不能够信赖.这些服务还是在网络上才能表现出它们的最佳状态,而不是终端系统.

    传统上说,以网络为基础的服务只能被服务提供者创造出来.创造服务通常是依靠一些私人的,有限制的工具,所以终端用户几乎不能相其中添加什么东西.但是,在Internet环境中,这点就改变了.全球的连通和开放性的协议允许终端用户或者第三方,来设计并操作新的或用户化的服务,并且可以升级并修改这些服务.这期间并不需要一个协议提供者来扮演一个仲裁者的角色,他们可以自行完成.

    大多数Internet应用程序都有这样的用户化的环境--就象环球网的CGI[3],和电子邮件的SIEVE[4],或者PROCMAIL.为了给Internet电话创造一个开放式用户化的开发环境,我们需要一个安全并且标准的方法，以便这些新服务的创造者可以简单的描述网络服务器所希望完成的工作.

    这篇文档描述了一种构架,在这种构架下,网络设备会对呼叫信号事件作出回应,也就是激活用户所创造的程序,当然这些程序都是用上文所述的简单,静态,并且没有歧异的语言写成的,就象[5]中所描述的.大体上说,当这篇文档提到"呼叫处理语言"时,它就意味着这样一种语言,遵循这些规则;"the call processing language"或者"THE CPL"就意味着这样一种专业语言.

2术语

    在这部分,我们会定义一些术语,以便下面使用.

STP[1]  常用术语简介:

invitation:原始请求方.SIP 交换时的请求,是从发起呼叫一端到另一端

redirect server:SIP设备的回应,当有invitation送来,或者以请求方式发送来的地址交换,SIP设备就会                      发送请求的对方以回应.

proxy server:一个SIP设备,当它收到了invitation,或者其他形式的请求,并且将它们继续向前传给其他SIP设备时.它不久就会收到一个对它继续前传的回应,然后把它们发还给发送请求的一方.

user agent:创造并接收请求的SIP设备.同样可以建立一个呼叫,或者可以影响一个呼叫.例如,电话,或者声音邮件系统.

user agent client:发送请求的user agent的端口.

user agent server:回应请求的user agent的端口.

H.323[2]常用术语简介:

terminal:一个可以发送,接收呼叫,以及它们之间媒体的H.323设备.

gatekeeper:网络上的一个H.323终端,它可以提供地址交换,并且同时控制网络的使用权,而控制对象就是H.323终端或者其他终端.它也可以为其他终端提供服务,比如查找网关或是带宽管理.

gateway:可以从H.323网络和其他网络之间传输呼叫的设备,通常是公用带宽的电话网.

RAS:连接在两个H.323之间的注册,认证和状态信息,比如endpoint和gatekeeper之间.

本文中常用术语简介:

user location:通过它,Internet电话设备可以确定使用了特殊地址的用户的位置.

CPL:一种呼叫处理语言,一种简单的语言,用来描述Internet电话是如何处理呼叫请求的.

script:一种CPL的特殊形式,描述服务所需的特殊集合.

end system:一个可以发出信息,或是终结信息的设备.它创造或者接收呼叫媒体(视觉,听觉,以及其他等等).它可能是SIP用户的代理或者是H.323的终端.

signalling server:处理呼叫请求路由的设备.它并不处理或者影响呼叫媒体本身.它可能是SIP 代理服务器,或者间接代理服务器,或者是一个H.323gatekeeper.

3关于服务的一些例子

    为了激发更深的讨论,在文章的这个部分,我们提供了几个特殊的服务的例子,我们希望用户可以自己来创建它们.首先要声明的是,它们中的一些是故意安排的较复杂,并以次来证明决策的逻辑一定要应该合理.

@向前呼叫却得到了忙或者没有回答

当一个新的呼叫传来时,呼叫就会在使用者的电话机响起铃声.如果电话机忙,呼叫就会改变道路,发送到用户的声音邮箱中.如果,不这样,四声响之后,还没有回答,那它也应该转入到声音邮箱中,除非是从管理员那里发出来的,在这种情况下,它就应该代理转到用户的电话,如果他已经注册了的话.

@信息地址

工厂做广告,只是简单的一个"信息"地址,留个那些预期的顾客.当有呼叫传入他的地址,如果它正在工作,呼叫者就会被给予一个想接收那个"信息"的人员的名单.如果它并不在工作时间,呼叫者就会得到一个网页,从中可以得知什么时候可以呼叫.

@智能用户地址

当一个新的呼叫传来时,用户注册的地址名单应该要考虑.然后根据呼叫的类型(业务,私人,等等),呼叫应该以一种已经注册的地区的特定的子集响铃,根据注册的信息.如果用户是从一种状态开始,那么这种起始状态应该被发送会呼叫会所.

@带媒体信息的智能用户地址

当一个新的呼叫传来时,呼叫应该由代理转给用户所注册的那个地址,从那里媒体性能可以在呼叫名单中很好的发挥出来.如果用户在这种状态下响了四声还没接,那么呼叫就会从代理服务转向其他工作站,在那里,他或者她注册过,进而减少匹配的狭窄.

@客户端次序--"律师事务所"

当一个新的呼叫传来时,被呼叫的地址就与相关的客户端连接,并且与客户端名字,地址,和呼叫时间都有关系.如果,相应的客户端没有找到,那么呼叫就会传给律师事务所.

4用法简介

    CPL对于在不同情况下操作控制服务是有一定用处的.

@由end user建立的script

在大多数直接创建CPL服务的方法中,一个end user可以简单的创建一个脚本来描述他们的服务.他或她只是来决定他或者她需要的是什么服务,然后用CPL脚本语言描述它,并把它传给服务器.

@第三方的外部方案

由于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:joe@example.com,不管那个用户现在在那里,或者他或她在使用什么样的设备.设备地址,相比较而言,涉及到一个特殊的物理设备,例如:sip:x26063@phones.example.com.另外,中间(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脚本的构架设计成允许脚本在多重信号服务器上执行,在寻找用户期间,概念上,我们可以把脚本--脚本之间的冲突转变为服务器--服务器之间的冲突,就象下部分中讲的那样,应该尽量减少我们需要面对的冲突种类.

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

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

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

@错误报告

    如果一个未曾预料的错误发生了,脚本就一定要能够向脚本所有者报告错误.这和脚本服务器用来向用户报告错误的机制是相同的.(详情请看12.5)

@对用户本地信息的使用

    代理服务器通常会收集用户本地的信息,通过SIP注册信息,H.323的全部信息,或者其他有些机制(详情请看6.2).CPL是与这个信息相关的,因此呼叫可以向前续传到注册的地址,或者是它的子集.

@数据库访问

    关于CPL控制的信息,被安排在额外的数据库中.例如,更广的地址数据库,或者认可信息,在管理员控制下.语言列出了一些数据库的访问协议(如果SQL,LDAP),或者其他类别.

@其他的信息

    脚本可以访问的其他信息,包括网页,尤其是在SIP信息中被发送回来的;或者一个清洁的接口可以施行函数调用,比如Corba, RMI,或者DCOM,例如可以访问额外的帐单数据库.但是,为了简单,这些接口不一定在原始的版本协议中.

12.4语言特征

    有一些特征,与CPL运行环境的操作一点关系都没有,但对于一些标准服务的执行,却是必要的.(下面的,并不完全):

@模式匹配

     它应该可以为地址和文章的字符串提供特殊处理.这些字符串不只是完整的字符,还有部分匹配的字符.

@地址过滤

    一旦用12.3中提到的方法,得到了一个地址集合,用户就应该从它们之中选择一些出来做为它们的子集.这就要以它们的地址与参数为基础.

@随机选择

    呼叫分类的一些形式是随机的,就象它们结束的地方一样.

@数据/时间信息

    用户可能希望以一些服务为条件(举例来说,呼叫续传,和呼叫分类),比如时间,日期等等.  

12.5控制

    就象第八部分中讨论的,我们必须有一个体制,来发送和接收CPL脚本,以及相关的数据,向或者从一个信号服务器.这个方法一定要能够支持将上载时间的错误报告给用户;当然,我们同样需要一些体制,当脚本执行时把错误报告给用户.鉴定是最重要的,加密术是相当有效的.关于这种体制的详情,可能是(应该就是),呼叫处理语言本身的一个详细说明.

13安全考虑

    关于CPL脚本的安全考虑就象[8]与[12.5]中讨论的那样.关于语言执行的考虑在[12.1]中进行了详细的讨论.

14感谢

    我们很高兴的感谢Tom La Porta和Jonathan Rosenberg对我们的支持,以及对文档的注释.

15作者地址

Jonathan Lennox
   Dept. of Computer Science
   Columbia University
   1214 Amsterdam Avenue, MC 0401
   New York, NY 10027
   USA

   EMail: lennox@cs.columbia.edu

   Henning Schulzrinne
   Dept. of Computer Science
   Columbia University
   1214 Amsterdam Avenue, MC 0401
   New York, NY 10027
   USA

   
   EMail: schulzrinne@cs.columbia.edu

16参考书目


   [1]  Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,
        "SIP: Session Initiation Protocol", RFC 2543, March 1999.

   [2]  International Telecommunication Union, "Packet based multimedia
        communication systems," Recommendation H.323, Telecommunication
        Standardization Sector of ITU, Geneva, Switzerland, Feb. 1998.

   [3]  K. Coar and D. Robinson, "The WWW common gateway interface
        version 1.1", Work in Progress.

   [4]  T. Showalter, "Sieve: A mail filtering language", Work in
        Progress.

   [5]  J. Lennox and H. Schulzrinne, "CPL: a language for user control
        of internet telephony services", Work in Progress.

   [6]  International Telecommunication Union, "General recommendations
        on telephone switching and signaling -- intelligent network:
        Introduction to intelligent network capability set 1,"
        Recommendation Q.1211, Telecommunication Standardization Sector
        of ITU, Geneva, Switzerland, Mar. 1993.

   [7]  Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service
        Location Protocol, Version 2", RFC 2608, June 1999.

   [8]  E. J. Cameron, N. D. Griffeth, Y.-J. Lin, M. E. Nilson, W. K.
        Schure, and H. Velthuijsen, "A feature interaction benchmark for
        IN and beyond," Feature Interactions in Telecommunications
        Systems, IOS Press, pp. 1-23, 1994.

   [9]  J. Lennox, J. Rosenberg, and H. Schulzrinne, "Common gateway
        interface for SIP", Work in Progress.

   [10] J. Rosenberg, J. Lennox, and H. Schulzrinne, "Programming
        internet telephony services," Technical Report CUCS-010-99,
        Columbia University, New York, New York, Mar. 1999.

   [11] H. Schulzrinne and J. Rosenberg, "SIP caller preferences and
        callee capabilities", Work in Progress.

17版权说明

Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

18承认


   Funding for the RFC Editor function is currently provided by the
   Internet Society.