PARLAY/OSA API探析

http://www.chinatelecom.com.cn 2002年12月19日中国电信集团北京研究院技术部冯建强

下一代业务的目标就是把业务应用移到网络运营范围之外，向独立的业务供应商开放市场，同时为语音、多媒体和数据提供基于IP和移动方面的支持。这就需要通信网具有标准的、开放的应用编程接口（API），制定这一标准的原因有以下四个：对于网络运营商来说，随着新的增值业务不断开发，他们可以在保证网络原有的安全和完整性前提下提高网络的利用率，使原有的投资能够发挥出更大的价值；对于业务运营商来说，由于可以在一定程度上访问网络的一些基本业务功能，他们可以在较短的时间内用较少的成本，冒较低的风险开发出各种新的应用业务，从而很快获得较大的收益；对于软件开发商，由于标准的应用编程接口屏蔽了底层异构网络以及复杂的信令交互，因此软件开发商不需要掌握太多的通信背景知识，就可以编写出运行在不同通信网平台上的应用程序；而终端用户则可以享受到更大范围内的，更便捷的通信服务。

一、 Parlay及其体系结构

1998年3月，Parlay工作组由BT、Ulticom、Microsoft、Nortel和Seimens5家公司联合成立，主要研究支持外部应用访问安全网络的内部资源的网络接口规范，以拓宽网络的智能化范围，促使第三方业务供应商或电信运营商基于这一接口平台，采用不同的技术在无线、Internet或公众交换网上开发通信产品、提供通信业务，同时为特定的用户群快速定制个性化业务以作为普遍业务的补充。Parlay工作组的工作重点在于制定API规范，但不包括如何实现API、基于API的应用、底层网络软件、物理构件和物理接口。为此Parlay组织积极鼓励电信和IT业界作为一个整体来参与API 的设计和实现。

Parlay最初的版本于1998年12月出版，其书写格式为UML语言。主要定义了应用程序访问业务的接口，譬如呼叫控制业务、多方呼叫业务、多媒体业务、消息业务、会议业务等基本业务功能，还定义了框架接口包括鉴权、认证、业务查找、事件通知等接口，它们能保证业务接口的开放、安全、灵活和易于管理。同时推出了一个以此规范为基础的“可靠呼叫前转”演示业务，说明了一个企业如何通过使用Parlay API规范提供的核心能力在不需要网络经营者干预的情况下给用户提供业务。Parlay工作组第一阶段的主要工作侧重于固定网络呼叫控制、消息处理和安全管理。

1999年5月，6个成员加入了Parlay工作组，它们是 AT&T、Cegetel、Cicso、Ericsson、IBM和Lucent，此时共有11个成员。Parlay工作组第二个阶段的工作侧重于核心API能力，尤其是针对无线和IP服务领域。2000年1月API 2.0出版，。Parlay API 2.0在1.0的基础上增加了企业对其内部用户使用Parlay业务的管理功能（譬如业务预定）接口，允许第三方提供基本业务功能的接口，并增加了移动业务接口以及用于设定QoS等级的连通性业务接口。仅6个月后，2.1出版，2000年10月和2001年3月，2.1修订版出版，修订版没有主要的改变，实际上主要修改了以前版本的书写错误。Parlay工作组第三阶段的目标包括通用计费、业务和网络管理、移动电子商务和虚拟归属环境（VHE）等。从2000年4月，Parlay工作组鼓励新成员加入，已经有相当的影响。在2001年2月，Parlay工作组成员列表由24个成员和13新加入的成员。此时，版本为3.0。

Parlay 1.2和Parlay 2.1最具有代表性。这两个版本在呼叫控制功能上具有较大的区别。Parlay 1.2只定义了一个呼叫控制管理服务接口，管理所有类型的呼叫；另外针对INAP协议专门定义了一个扩展接口，以适应智能网的需要；在Parlay 2.1中呼叫控制接口做了较大改动；由一个统一的呼叫控制模型扩展为针对不同类型业务的多个呼叫控制模型，包括基本呼叫控制，多方呼叫控制，多媒体呼叫控制和会议呼叫控制，这些呼叫模型之间具有继承的关系，后一种模型都是在前一种模型的基础之上的扩展，提供更深层次的控制功能。Parlay 3.0规范了接口表示，在版本2的基础上又增加了终端能力（获得用户所用终端的位置及属性等参数）、数据会话（IP网络上的数据交互业务）、基于内容的计费，策略管理Policy Management：允许在策略域里进行独立于网络结构和传输、应用协议的管理；Parlay还和PAM论坛组织合作于2002年第一季度公布"在席和可用性"接口（Present & Available）。PAM是一种新的服务，可以提供关于用户的出席情况信息和管理。而Parlay API3.1修正3.0中的错误和遗漏，除了原来的UML到IDL的映射外，又将3.0版本从UML语言映射到XML语言，以方便业务供应商在互联网上开发通信业务。

鉴于PaylayAPI的广泛应用和它在业界的重大影响，许多著名的标准化组织和业界组织相继宣布在自己制定的标准或规范中已经采用了或者即将采用Parlay API规范。这些组织主要包括ITU-T、ETSI、IEEE、IETF、3GPP、OMG、TINA-C、Softswitch论坛、JAIN等。目前，Parlay工作组、ETSI和3GPP已经联合起来，共同发展Parlay协议。下图为3个标准组织发布的Parlay版本的对应关系。

Parlay API的版本中比较具有影响力的版本是2.1和3.0，Parlay标准化组织以后的版本只对版本3.0具有向后兼容性而对2.1版本没有后相兼容性。

Parlay组织在2002年第二季度推出Parlay4.0，把Parlay规范和目前的底层通信网协议互相映射，也就是开始着手定义资源接口，譬如和SIP相融合。另外，Parlay规范还将映射到WSDL（网络业务描述语言），建立Parlay的Web服务器。与此同时，Parlay组织还意识到由于Parlay规范的庞大和复杂，比较难以掌握，目前80%的Parlay业务只用到了20%的Parlay API，所以它开始着手定义Parlay X，Parlay X通过把原来的Parlay API进行组合和封装，在Parlay API层之上建立了各具特色的Parlay业务组件模板，譬如用于PC桌面的Parlay X、公司服务器的Parlay X、用于PDA的Parlay X等，每种Parlay X组件只用到了较少的APIs，以适应不同的业务需要，使第三方开发业务更加方便。

Parlay所构想的应用体系结构如下：

其中Parlay客户端就是应用服务器，由第三方业务供应商或网络运营商提供，用以开发各种业务提供给终端用户使用。Parlay服务器又称Parlay Gateway，它为Parlay客户端提供各种基本业务能力的支持，使Parlay客户端的业务能够有控制的、安全的进入到各通信网内。目前Parlay服务器由各个网络运营商提供，只是因为Parlay还没有规定与各底层网络的资源接口，所以Parlay服务器和各通信网之间暂时只能由网络运营商自己设定内部的通信协议，如采用JAIN、INAP、SIP将API映射到低层网络。Parlay客户端是通过调用Parlay APIs访问Parlay服务器，它们之间一般采用CORBA等分布对象技术进行通信。

二、Parlay APIs主要由两部分组成：

1、业务接口（Server Interface）：这类应用编程接口可以访问Parlay服务器所提供的一系列基本业务功能，譬如建立或释放路由、与用户交互、发送用户消息、设定QoS级别等。业务供应商可以按照不同的业务逻辑对它们进行调用以实现不同的业务。

目前Parlay API已有的业务接口包括：

· Call Control：定义了从建立基本呼叫、多方呼叫到建立多媒体会议的能力；

· User Interaction：能够获取终端用户的信息、播放通知、与用户进行交互；具有一般用户交互接口和呼叫用户交互接口

·Terminal Capability：获得用户终端的位置及属性参数；

·User Location/status：获得用户的网络表示、位置及状态等；具有用户位置接口、用户位置CAMEL接口、用户位置紧急接口和用户状态接口。

·Data Session：控制数据交互；

·Generic Message：访问信箱；具有邮箱接口、文件夹接口和消息接口。

·Connectivity Management：提供QoS保证；

·Content based Charge：根据用户的数据流量或应用计费；

·Presence and Availability Management：在席和可用性管理。

2、框架接口（Framework Interface）：它们对业务接口提供必需的安全、管理支持。主要有如下接口：

·信任和安全管理

-初始

-认证

· 业务接入

· 业务发现

· 业务注册

· 事件通知

· 完整性管理

-负载管理

-故障管理

-心跳管理

-OAM管理

框架接口可分为应用服务器与框架之间的接口、网络业务能力服务器与框架之间的接口、企业经营者与框架之间的接口。

I、应用与框架之间的接口的基本机制为：

· 鉴权：在被允许使用任何OSA接口前，应用必须通过鉴权。

· 授权：鉴权后，应用被授权接入确定的业务。

· 框架和网络业务能力特征的查找：鉴权成功后，应用可以获得可用的框架接口并使用开放接口获得被授权的网络业务能力特征的信息。鉴权成功后，可以在任何时候使用查找接口。

· 业务协议的建立：任何应用与网络业务能力特征交互之前，必须建立业务协议。业务协议包含离线部分和在线部分。应用在使用任何网络业务能力特征前，需要签订在线部分的业务协议。

· 接入网络业务能力特征：框架通过特定的安全级、上下文、域等提供控制应用的API方法接入业务能力特征或业务数据的能力。

II、框架与业务能力服务器之间的基本机制为：

· 网络业务能力特征的注册：由业务能力服务器提供的SCFs可以在框架上注册。

III、框架与企业经营者之间接口的基本机制为：

· 业务订购功能：此功能代表企业经营者和框架之间的合同。在订购商业模型之中，企业经营者代表业务的订购者，客户应用代表业务使用者，框架代表业务的销售者。

三、Parlay可以提供的第三方业务主要分为以下几类：

· 通信类业务：如点击拨号、VOIP、点击传真、可视电话、会议电话等，以及与位置相关的紧急呼叫业务、路边助手业务等。

· 消息类业务：如统一消息、短消息、语音信箱、E_Mail、多媒体消息、聊天等。

· 信息类服务：如新闻、体育、旅游、金融、天气、黄页、票务等各种信息的查询、订制、通知等，以及基于未知的人员跟踪、找朋友等。

· 支付类业务：如电子商务、移动银行、网上支付、即时售订票、收费浏览等。

· 娱乐类业务：如游戏、博彩、谜语、教育、广告等。各类业务可以相对独立，也可以有机结合，例如可以在查询信息时根据相应的信息进行支付类业务，再如各种娱乐可以通过不同的消息方式来表现（短消息、Email），将娱乐与消息业务相结合。

四、呼叫控制API

呼叫控制接口分为一般呼叫控制、多方呼叫控制、多媒体呼叫控制和会议呼叫控制接口。

1、一般呼叫控制服务是整个呼叫模型的子集。呼叫局限于两方且不可控制呼叫Leg。由于一般呼叫控制服务不能处理多媒体连接，所以不可能控制媒体信道。

一般呼叫控制由网络侧的两个接口，即IpCallControlManager和IpCall，和对应企业侧的两个接口，即IpAppCallControlManager和IpAppCall构成。

IpCallControlManager提供管理呼叫的方法。该接口的CreateCall()方法可建立新的呼叫对象（即实现IpCall接口的对象）。它也提供请求向客户应用通知呼叫事件的方法。例如，客户应用能够调用IpCallControlManager接口请求将到指定电话号码或一定范围电话号码的呼叫事件通知给客户应用，如果由于某种错误呼叫通知不可进行，则不允许客户应用请求呼叫通知。

一旦调用了呼叫通知请求，可以通过接口更改或删除。接口也提供在一系列呼叫上实施的负载控制方法和取消先前设置的负载限制的方法。

IpCall接口提供将呼叫路由到目的方或监视呼叫状态的方法。例如，客户应用能调用接口的方法，请求当呼叫结束时，设置与呼叫相关的信息（例如计费）。使用IpCall接口，客户应用也能请求监视呼叫，即经过指定时长后，将呼叫的状态报告送到客户应用且将呼叫的控制交给应用。这在预付费应用中很有用，以防止当预付费账户为零时，呼叫仍然继续。

IpCall接口也提供设置呼叫计费的操作，lpCall提供的另两个接口是请求用户提供更多的DTMF输入和计费建议操作，它通知用户有关呼叫计费的信息（即消息被发送到它的终端，如果终端有能力显示这一信息）。

IpAppCallControlManager是IpCallControlManager企业侧的对应接口。这个接口提供当呼叫事件（通过IpCallControlManager接口请求）到达时被调用的方法。也提供用以接受底层网络呼叫通知状态（能或不能）信息和当网络遇到呼叫过载时Parlay网关发送的通知信息的方法。接口也提供指示网络中呼叫终止的方法，当网络检测到呼叫（应用感兴趣的）终止后，由Parlay网关调用。

IpAppCall是IpCall接口企业侧对应的接口。该接口提供用以处理呼叫请求的响应和状态报告的方法。例如，IpAppCall接口被通知有关路由请求的状态：路由成功和被叫应答，或被叫忙等。IpAppCall接口接受所有的通过IpCall设置的请求的状态报告。

2、多方呼叫控制

在多方呼叫控制服务中，有六个重要的接口：IpMultiPartyCallControlManager、IpAppMultiPartyCallCaontrolMAnager、IpMultiPartyCall、lpAppMultiPartyCall、IpCallLeg、lpAppCallLeg。

接口IpMultiPartyCallControlManager，lpAppMultiPartyCallControlManager和IpAppMultiPartyCall从一般呼叫控制继承了所有方法且没有引入新的方法，IpMultiPartyCall接口是IpCall的扩展。它包含显式接入呼叫Leg的操作。注意在多方呼叫中，一个呼叫能包含两个以上个呼叫Leg。接口也提供一个建立实现IpCallLeg接口对象的方法。

IpCallLeg接口提供将呼叫Leg路由到指定目的方和合并或分离与入/去呼叫相联系的媒体的方法。也提供当呼叫Leg终止时将Leg指定的请求信息发送到应用的方法。虽然能请求详细的Leg事件报告，但不提供连续监视Leg的方法。将来，通过IpCallLeg接口提供几个接入功能。例如找回呼叫Leg所属的ID。注意一个呼叫能有多个Leg，但一个Leg同时仅能是一个呼叫的部分。

IpAppCallLeg接口是IpCallLeg接口企业侧的对应接口。它接受通过IpCallLeg接口设置的请求的响应。

接口lpMultiPartyCall，继承自lpCall，新增方法有：

· GetCallLeg()，此方法请求与呼叫对象相关的呼叫Leg对象的标识。

· CreateCallLeg()，此方法请求创建新的呼叫Leg对象。

· CreateAndRouteCallLegReq()，此异步操作请求创建并对新创建的呼叫Leg选路。

接口lpAppMultiPartyCall，继承自lpAppCall，新增方法有：

· CreateAndRouteCallLegErr()，此异步方法指示呼叫路由至目的地的请求不成功。

接口lpCallLeg，继承自lpService，呼叫Leg接口用地址代表与呼叫相关的逻辑呼叫Leg。

· RouteReq()，此异步方法请求呼叫Leg路由至目的地址指示的一方。

· EventReportReq()，此异步方法设置、清除或改变Leg对象监视的事件标准。

· Release()，此方法请求释放呼叫Leg。如果成功，呼叫Leg被删除。

· GetInfoReq()，此异步方法请求在适当的时候提供与呼叫Leg相关的信息。

· GetCall()，此方法请求与呼叫Leg相关的呼叫。

· AttachMedia()，此方法请求呼叫Leg与它的呼叫对象相连。

· DetachMedia()，此方法使呼叫Leg与它的呼叫相分离。

· GetLastRedirectedAddress()，此方法用来查询要转向的最后地址。

· ContinueProcessing()，此操作继续呼叫Leg的处理。应用在呼叫Leg处理由于应用预约的事件通知被检出而中断后调用此操作。

· SetChargePlan()，设定操作员定义呼叫的计费策略。计费策略必须在呼叫Leg路由至目的地前设定。此方法也可以用来改变目前呼叫的计费策略。

· SetAdviceOfCharge()，此方法允许AOC信息发送到可以接收该信息的终端。

· SuperviseReq()，应用调用此方法监视呼叫Leg。

· Deassign()，此方法请求重新指定应用和呼叫Leg以及相关对象的关系。

接口lpAppCallLeg，继承自lpInterface，应用呼叫Leg接口用来处理与呼叫Leg请求相关的响应和错误。

· EventReportRes()，此异步方法报告所要请求报告的事件。

· EventReportErr()，此异步方法指示处理呼叫Leg事件报告的请求未成功以及原因。

· GetInfoRes()，此异步方法报告应用所请求的所有必要信息。

· GetInfoErr()，此异步方法报告源端请求错误。

· RouteErr()，此方法报告路由错误。

· SuperviseRes()，此异步方法报告呼叫Leg监视事件给应用。

· SuperviseErr()，此异步方法报告呼叫Leg监视错误。

· CallLegEnded()，此方法指示应用网络中Leg已结束。

3、在多媒体呼叫中，涉及以下七个接口：IpMultiMediaCallControlManager、IpAppMultiMediaCallControlManager、IpMultiMediaCall、IpAppMultiMediaCall、IpMultiMediaCallLeg、IpAppMultiMediaCallLeg、IpMultiMediaChannel。

接口IpMultiMediaCallControlManager继承了IpMultiPartyCallControlManager提供的所有方法而且通过提供两个新的方法扩展了它的能力。通过这些方法可以激活或去激活媒体信道通知能力。当激活媒体信道通知能力时，包含两个标准集。两个标准集必须在信道报告给客户应用前全部实现。首先，多媒体呼叫必须与呼叫标准匹配（即目的呼叫码必须在一定范围内）而且媒体信道指示必须匹配。

企业侧的对应接口IpAppMultiMediaCallControlManager继承了IpAppMultiPartyCallControlMAnager接口的所有方法，引入了一个新方法，即媒体信道事件通知方法。

为代表网络侧的多媒体呼叫，使用一个实现IpMultiMediaCall接口的对象。接口继承了IpMultiPartyCall接口的操作，引入一个新方法去设定一个呼叫认可的数据流量（以微秒测算）。当给定的数据量过期后，企业侧称为IpAppMultiMediaCall的对应接口收到事件的通知。

接口IpMultiMediaCallLeg继承了IpCallLeg的所有操作，客户应用通过调用这个接口的方法能够监控和影响媒体信道。提供了三个新的操作。一是能够监控打开和关闭媒体信道，有两种监控类型：一般监控（满足任何媒体类型）或指定监控（仅当使用指定媒体类型的信道才发送通知）。如果监控设置为中断模式，为打开这种媒体信道，应用必须显式地允许接入。IpMultiMediaCallLeg接口提供相应的方法。IpMultiMediaCallLeg引入的最新方法使得可以接入所有与这个呼叫Leg相关的已打开的媒体信道列表的方法。（注意一个呼叫Leg可与几个媒体信道相联系）。

在企业侧必须实现IpAppMultiMediaCallLeg接口，它继承了父类IpAppCallLeg的方法。引入一个新的操作，即媒体信道通知，当打开或关闭满足请求的检测标准时，由Parlay网关调用。

在多媒体呼叫控制中包含的最后一个接口是IpMultiMediaChannel接口，这个接口表现为与呼叫Leg联系的单向数据流。只有一个方法可用，即关闭信道。

4、会议呼叫控制是Parlay API定义的最高级的呼叫控制形式。会议呼叫控制服务用会议和子会议的概念提升了多媒体呼叫控制服务。会议与多媒体、多方呼叫的不同点是会议资源可提前保留。子会议是会议中全部Legs的子集，只有在同一子会议中的Legs才能相互通信（即只有在同一子会议的Legs间才有媒体通路）。

有两种会议开始方式：没有会议资源的优先保留和有会议资源的优先保留的开始方式。

在会议呼叫控制服务中，六个接口最重要，这些接口简要描述如下：

IpConfCallControlManager是必须用以生成会议和资源管理的接口。它继承了父类接口lpMultiMediaCallControlManager，但也增加了重要的新成员。该接口提供建立新会议，检测会议是否有足够的资源可用，为会议预留资源和释放分配的资源的方法。

当建立一个新的会议时，应用必须指明要用的子会议数目。它至少为1，会议参加者数目和预期的会议时长也在建立会议的请求时提供，网络随后尽力在指定的时间分配必要的资源。如果资源可用，会议开始。当会议时长超出了资源预留的时间，资源不再保证，但会议可以继续。注意如果需要资源满足另外的请求，会议能被网络结束或拒绝。

IpConfCallControlManager接口也提供检测在给定的预计时间是否有足够的资源可用的方法。当调用此方法，必须输入指定的开始和结束日期以及时间（代表搜索间隔），和可选的期望参加者数目和会议周期。搜索算法返回实际可利用的资源，会议时长和开始时间。注意此方法仍然没有保留资源。

为了保留资源，IpConfCallControlManager接口提供了另一个方法。作为此方法的参数，必须制定开始的日期和时间，参加者数目和会议预期时长。以及会议指定的策略，内容，是否允许会议建立以后允许实体的加入。

IpConfCallControlManager接口提供的最后一个方法专为释放先前保留的资源。本方法有效地取消了资源预留。

IpAppConfCallControlManager提供了当会议因先前的预约由网络建立时，Parlay网关调用的方法。它继承了IpAppMultiMediaCallManager接口，除了以上描述的方法外，没有引入新的方法。

IpConfCall接口继承了IpMultiMediaCall接口，用以管理子会议，但也可向不需要知道有多个子会议的应用隐藏子会议。除了继承的方法外，该接口提供了请求会议中所有子会议列表的新方法，去建立新子会议和请求监控事件。

IpAppConfCall是相对于IpConfCall接口的企业侧接口。IpAppConfCall接口接收通过IpConfCall接口调用的请求的响应。它继承了父接口IpAppMultiMediaCall的方法，且提供了两个新方法。

首先，通过IpAppConfCall接口，提供当到达一个新的实体（和呼叫Leg）时的通知方法。例如可以用于计划会议（会议资源已经预留），这里使用资源预留期间提供的地址参加者可以拨进会议（如果会议策略允许拨入）。

第二个新的操作是通知应用实体的离去，当实体离开会议和监控实体提前申请离开，应由Parlay网关调用。

IpSubConfCall提供管理子会议的操作。子会议又称为一个会议中所有Legs的子集。所以仅在同一子会议的Legs才能相互通信。它继承了IpMultiMediaCall，并提供几个新的方法。

该接口提供的一个方法是分拆子会议。这种情况下，子会议中一些Legs移往新建的子会议。

相反的操作，也提供了合并子会议，在这种情况下，该子会议中的所有Legs移往一已经存在的子会议，且释放空子会议。该接口也提供了将呼叫Leg移往另一子会议的方法。

通过IpSubConfCall接口，可以改变的多媒体（子）会议策略。

IpAppSubConfCall接口允许通知应用关于子会议的事件。它继承了IpAppMultiMediaCall接口，并引入了两个新的操作。都是用来调用去通知应用网络所作的请求。一个方法用于提供主席请求，另一个是坐席请求。

在当前通信网由传统的向下一代网络演进的背景下，IP、移动和固定/智能网不断融合，数据称为业务新的增长点。ITU－T已经成立了一个工作组（SG11）对开放业务访问（OSA）进行研究，其中Parlay APIs是一个重要的参考，由此可见Parlay API作为开放的业务应用编程接口很有可能成为下一代网络的一个标准，对其进行研究对于下一代网络的研究和新业务的开发部署具有重要的意义。