📄 rfc2824.txt
字号:
组织:中国互动出现网 (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脚本语言描述它,并把它传给服务器.
@第三方的外部方案
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -