精华内容
下载资源
问答
  • 2020-06-03 12:02:57

    前面介绍了呼叫系统的行业应用和关键技术等,都只是些呼叫系统的基本知识,还不能完全地揭示一个呼叫系统的实际面貌。那么呼叫系统究竟是如何构成及运转的呢?本节将具体研究这一问题。

    1.呼叫系统的逻辑架构

    呼叫系统包括多个组成部分,不同部分的功能、作用也不同。最简单的划分可以分为平台和业务两部分。平台主要进行话务处理,具有通用性,不同的呼叫系统可能使用相似的平台。业务处理则相对具有专业性,不同行业、不同银行或券商的业务都会有所不同,很难有统一的内容。

    平台的通用性和业务的专业性,是呼叫系统的一个基本特点,也是众多开发与集成厂商关注的问题。下面以一个基本的呼叫系统产品为例,介绍呼叫系统的逻辑架构,看看它是如何把平台和业务结合起来的。

    通常的呼叫系统解决方案都采用了业务与交换分离的设计思想,如图9.5所示。

    整个呼叫系统分为三个逻辑层次(平台):通信平台、业务平台和数据信息平台。这基本是按照呼叫系统各个部分的功能类型以及它们在一个交易进行的标准流程中所处的顺序来划分的。

    (1)通信平台

    通信平台是应用的用户接口部分,它担负着客户与系统间的对话功能。它用于检査用户输入的数据,显示应用输出的数据。

    通信平台根据功能划分为通信接入层和媒体服务层两个层次。

    ①通信接入层。通信接入层负责用户的接入,包括电话呼叫系统、WAP、短消息.Internet等各种渠道的接入,从另一个角度来说,通信接入层可以称为系统和客户的接口,包括客户的呼入以及主动的呼出两个部分。

    通信接入层具体负责与电信PSTN的接口、话务的分配和排队功能,具有ACD的能力,提供各种路由排队策略。

    ②媒体服务层。媒体服务层提供包括IVR、人工坐席服务、Fax、E-mail、Web等灵活的服务方式,完成客户与系统间的对话和交互功能。

    (2)业务平台

    业务处理平台实现系统提供的各种具体应用,处理具体的业务处理逻辑,可以看作是实现一系列功能服务簇。在智能电销系统业务功能设计中采用RTU(RightstoUse)用户使用权限的方式。在系统中通过RTU管理方式控制具体业务的开通和关闭,在工程实施中只需根据具体的业务需求开通相应的业务功能的RTU即可,因此在项目实施中十分方便。

    (3)数据信息平台

    数据信息平台是与各业务系统的接口,可能的组成部分包括交易系统、调度系统、MIS系统等。

    2.呼叫系统的接入平台

    接入平台是通信平台的一部分,也是呼叫系统分类的一个常见依据。不同的接入平台适用的情况不同,建设成本不同,实现功能的质量也不同。根据接入设备的不同,平台主要分板卡、PBX和IPCC三种类型。

    (1)板卡平台方案

    图9.6是板卡平台的呼叫系统构成示意图。系统由工控机(插有语音处理卡、座席卡和传真卡等)、人工座席、IVR、数据库、业务处理系统等构成。基于计算机语音板卡的方式的基本思想是,在微机平台上集成各种专用的计算机语音板卡(如呼叫处理卡、语音资源卡、服务坐席卡),完成通信接口、语音处理、传真处理、座席转接等功能,再结合外部的计算机网络来实现应用系统的需求。板卡平台方案的自动呼叫分配功能由软件ACD实现。这种呼叫处理系统本身就是一个计算机网络,所以很容易将其接入数据库系统,用户可以很方便地同时得到电话呼叫系统和计算机数据两种资源。微机方案的实施带有明显的软件研发特点,灵活性较强,但由于复杂的电话呼叫系统交换是在微机平台上由呼叫处理卡完成的,所以系统呼叫处理能力相对较弱。板卡平台方案的发展是由板卡生产厂商(如Dialog?ic,NMS)和应用软件开发商共同推动的。

    以板卡平台为基础的呼叫处理系统的主要技术组成如下:

    ①Client/Server结构的微机网络技术。在这种系统中,呼叫处理和语音处理的功能集中在语音工作站中,系统的资源控制、数据库系统在服务器中实现,业务生成、改动则由专门的应用处理工作站完成。整个系统是一个Client/Server结构的微机网络。

    ②语音板卡技术。语音板卡的种类包括通信线路接口卡(数字中继卡、模拟线接口卡等)、信令处理卡(如七号信令卡)、语音资源卡、传真资源卡、座席卡以及通用语音处理平台。

    ③语音总线技术。语音总线使各种功能专一的语音板卡连接

    成一个功能复杂的系统,同时也是微机语音平台实现交换的基础。

    ④机间扩展总线技术。限于微机的处理能力,一个语音工作站只能处理一部分呼叫或实现某一项功能。要将独立的语音工作站互联成一个大系统,就需要机间总线技术。这种系统的硬件系统在板卡级集成,由于是总线结构,硬件系统的可靠性指标由系统中的最差部件决定。由于系统的所有功能都是由软件编程实现的,因而系统整体可靠性的瓶颈在于软件开发商的经验和软件的质量。板卡方案的实施带有明显的软件研发特点,工程进度的控制较难,基本上决定于开发商的研发能力。

    板卡方案适宜建设规模相对较小、业务灵活的呼叫系统。

    板卡方案的优点如下:

    ①对于规模不大的系统,在系统建设初期投资较小。但是,如果系统规模大到一定程度,由于微机平台和软件开发的特点,系统的造价将大大增加。

    ②在系统功能较为单一、软件开发商富有经验的条件下,系统建设周期可能较短。

    ③由于系统的大部分功能是由软件控制实现的,系统开发新功能较为容易。

    但是呼叫系统需要对大量呼叫进行复杂的处理,而这种处理量对于单一呼叫处理并不是线性叠加的关系,因此不能靠简单的多机处理解决存在的问题。

    从技术上分析,板卡方案的缺点也很多:

    ①硬件指标低。硬件系统的可靠性指标与通信系统的要求相差甚远。

    ②没有适于呼叫处理的操作系统。呼叫处理是实时性要求很高的操作,要求有高性能实时操作系统。微机平台的操作系统,如OS/2?WindowsNT,Windows95?Windows98,SCOUNIX等,都是分时系统而非实时系统,难以保证呼叫处理的稳定性和安全性,更不用说在呼叫处理的基础上完成智能路由。

    ③对于软件开发的要求太高。

    ④呼叫系统的高效率来源于呼叫与数据距离最近的概念,而微机方案仅能实现呼叫与自动语音距离最近,这对于声读服务或简单的座席服务是适宜的,但对于复杂的呼叫系统应用,微机方案的最终性能与PBX方案相比是有较大的差距。

    (2)PBX平台方案

    如图9.7所示是PBX平台.呼叫系统的构成示意图。系统由交换机、ACD、IVR、人工座席、数据库、业务处理系统等组成。基于交换机方案的核心思想是,在专用交换机集成ACD的基础上扩展路由功能,开放CTI-Link接口,用CTI技术实现通信和计算机的功能结合,再配以必要的语音和数据库系统,从而以强大的通信和计算机功能满足呼叫系统的要求。呼叫处理由交换机完成,客户的自动语音服务由自动语音应答系统完成。CTI服务器作为系统核心部件,通过交换机CTI-Link获取交换机的状态并实现与交换机的通信。PBX方案可以在结构上清晰地区分开计算机系统和通信系统,CTI服务器是协调控制两者的连接设备:保证座席和自动语音应答系统可以充分利用数据资源和呼叫处理资源。PBX方案发展是基于CTI-Link标准、通信厂家和计算机厂家利用各自优势,分工合作的结果。

    由于PBX方案处理能力较大,性能稳定,因此国际上大型呼叫系统一般采用PBX方案实现。

    PBX方案的优点:

    ①既保留了通信系统和计算机系统的独立性,又综合了两者的功能。

    ②各子系统的功能明确,有成熟的国际标准,如CSTA179及CSTA180标准。

    ③由于有明确的技术分工,有利于各子系统的生产厂商形成规模产业,从而降低系统的综合成本。

    ④对于各子系统,生产厂商一般都有较长的技术积累期,因而具有可靠性较高的技术指标。

    PBX方案的缺点:

    ①系统牵扯的厂家有可能较多,接口多而复杂,这对集成商的经验和组织协调能力是一个考验。

    ②由于有众多著名厂商参与,提供的方案和产品的功能都很强,同时造价也较贵。如果不能加以妥善选取,系统的总造价将较贵。

    (3)IPCC平台方案

    图9.8为IPCC构成图。系统主要由语音网关(通常由路由器加相关模块构成)、CallManager.IPIVR、IP座席、ICM控制软件、PG网关、AW工作站、数据库、业务处理系统等构成。IPCC是在IP语音技术(VoIP)的基础上发展起来的,它是IP电话呼叫系统技术与呼叫系统的结合,并被认为是呼叫系统发展的方向。它的实现思想是把语音转换为IP包,与数据一起在计算机网络上传递,在一定程度上实现了三网合一,完全使用计算机网络构建呼叫系统。该呼叫系统具有地域分散性、可移动性的特点。

    IPCC与传统呼叫系统相比,增加了一个CallManager服务器,专门用于实现IP电话呼叫系统功能,座席的电话呼叫系统机不再与交换机或语音板卡相连,而是直接连入IP网络,把实际呼叫系统的范围扩大到整个IP网络。IPCC的核心是ICM软件,它由ICM(IntelligentCallManager)%PG(PeripheicGateway)外围网关、AW管理工作站组成,具有强大的控制管理功能,能够在全网范围内实现语音和数据的可靠传递。话务的ACD、话务的转接以及相关数据的传递都由ICM负责,它是从网络到桌面的功能强劲的CTI软件。

    组建IPCC,在很大程度上利用了企业原有的网络资源,而且灵活性很高,扩展十分方便,不太受地域限制。只要网络能够到达,座席人员甚至可以在家中工作,客户从因特网以及其他多媒体方式接入得到服务也很方便。IPCC在理论上具有了提供3A(Any?time,Anywhere,Anyhow)服务的能力。

    IPCC方案的优点:

    ①基于IPCC方案的最大的好处就在于它简化了呼叫系统的底层架构。因此,此方案的建设成本是最少的。

    ②由于底层架构的简化,使IPCC方案易于实施和管理。

    ③由于IPCC的应用主要以软件形式实现,因此有利于功能的维护和扩展。

    ④IPCC方案提供了对多种媒体的支持和管理,从而可以提高客户服务的质量。

    3.呼叫系统的业务处理

    如美国学者PaulGreenberg所介绍①,呼叫系统的典型处理流程如下:

    (1)呼叫进入中心交换局(CenterOffice),

    (2)PBX应答呼叫,捕获自动号码证实(ANI)或被叫号码证实(DNIS)信息。

    (3)PBX寻找空闲的VRU路由,并把该呼叫转至该线路。

    (4)PBX通过RS232串行口发送初始呼叫信息给自动语音应答VRU,包括呼叫转至的端口号及ANI和DNIS信息。

    (5)VRU播放提示菜单信息给呼叫者,以确定哪类接线员受理比较合适。

    (6)VRU检査接线员队列,若无空闲接线员,则播放消息给呼叫者,告诉其在等待队列中的位置,询问是否愿意等待等。

    (7)接线员空闲时,VRU通过拍叉簧把呼叫转至该接线员,等待PBX发来的拨号音,拨新的分机号。接线员拿起电话呼叫系统后,VRU自动挂机,处理另一个呼叫。

    ①[美]PaulGreenberg.实时的客户关系骨理.机械工业出版社,2002

    (8)利用数据库的共享或局域网通信工程,VRU向接线员的PC发送ANI信息,呼叫到达时,客户信息会自动显示出来。

    (9)呼叫用户或接线员一方挂机时,PBX检测到断线信号,通过RS232串行口发送呼叫记录信息给VkU。此时VRU根据此信息确定刚处理完呼叫的接线员已恢复空闲,可进行下一次呼叫处理。

    更多相关内容
  • 容联CC(呼叫中心)系统介绍

    千次阅读 2018-05-17 11:52:32
    1.概述 呼叫中心系统是利用通讯及计算机技术结合而成,如IVR(交互式语音400呼叫中心流程应答系统)、ACD(自动呼叫分配系统)等,呼叫中心系统可以灵活的处理大量不同的电话呼入和呼出业务。主要应用于营销、服务等...

    1.概述

    呼叫中心系统是利用通讯及计算机技术结合而成,如IVR(交互式语音400呼叫中心流程应答系统)、ACD(自动呼叫分配系统)等,呼叫中心系统可以灵活的处理大量不同的电话呼入和呼出业务。主要应用于营销、服务等多项工作中。呼叫中心系统具备同时处理大量来电、主叫号码显示、记录存储来电信息等功能(说明:大家日常使用的10086就是典型的呼叫中心系统)。

    目前我们公司所开发的呼叫中心系统主要用于外呼场景,典型的用户有马上消费和美利金融,现在以马上消费的预测试外呼系统做为基线版本进行衍生。以下内容主要以马上消费的预测试外呼系统进行简单说明。

    2.系统组成

    2.1系统拓扑图


    2.2预测式外呼流程说明

    以下内容主要针对2.1拓扑图描述整个外呼过程中,各模块的交互及作用,拓扑图中红色虚线表示媒体流,蓝色实现表示控制流,单项箭头表示单项消息,双向箭头表示双向消息(即模块间消息交互)。

    1.数据源:包括两种方式上传到DB中:一是由系统管理员通过CC产品管理模块(admin模块),以文件形式导入到DB中;二是由系统管理员使用自己的客户系统调用接口方式自定义文件导入到DB中。以上两种方式最终都需要以外呼任务的形式在CC产品预测试外呼系统中体现。

    2.外呼任务获取:外呼任务创建成功后,PDS模块每隔15秒查询一次数据库来获取外呼任务信息。

    3.是否发起呼叫:PDS获取到任务信息后,判断任务技能组中是否存在空闲座席,如果没有空闲座席则不会呼叫客户,如果存在空闲座席,会通过算法呼叫一定数量的客户。技能组中的座席信息是通过CCS模块获取得到。

    4.外呼客户:PDS获取到外呼任务后,技能组中的座席登录且空闲,此时PDS将呼叫客户的信息传输给sia模块,sia模块再将呼叫信息传输给ccmanager,ccmanager将呼叫信息传输给clpms,最终由clpms模块发起呼叫。当客户应答后,由CCS将该客户转接给技能组中的空闲座席,最终实现座席与客户通话。

    5.流程中其他模块作用:OAM主要用于PDS和CCS模块间消息转发,SBC主要用于外呼透传号码转换。

    2.3模块结构

    预测试外呼系统主要包括aaa、admin、ccc、cccservice、ccmanager、pds、clpms、dbaservice、ccs、oam、sia和fileserver等12个模块。

    l ccs:全称call center service,即呼叫中心服务端,主要用于控制座席状态变化、队列排队机制及电话分配。

    l aaa:全称athentication(认证)、authorization(授权)、accounting(计费),即鉴权服务器,主要用于呼叫中心系统的认证、授权及计费。

    l dba:数据库管理模块,主要用于部分模块与数据库的交互操作,例如一些模块的脚本语句无法直接操作数据库,需要通过该模块进行操作。

    l oam:全称Operation(操作)、Administration(管理)、Maintenance(维护),主要用于监控各模块运行是否正常及部分模块间的消息交互及转发。

    l pds:全称Plant Design System,即智能计算服务,通过相关参数计算出合理的外呼数量,可以有效的提高工作效率。

    l sia:也称IVR(Interactive Voice Response),即互动式语音应答服务,主要用于人机交互,通过语音方式引导用户进行相关操作。

    l ccc:全称call center client,即呼叫中心客户端,主要用于座席人员操作,座席人员通过该模块可以进行接听来电、外呼、客户信息录入等。

    l cccservice:客户端服务器,用于支撑客户端的操作及客户端与其他模块间的交互。

    l admin:呼叫中心管理系统,用于整个呼叫中心系统的管理及配置操作,包括路由配置、创建企业、座席管理、通话记录管理、计费管理和报表管理等。

    l ccmanager:呼叫控制服务器,主要用于字冠分析,路由管理服务器,接收应用层命令,控制媒体服务器的中间模块。

    l clpms:媒体服务器,主要处理信令交互,媒体交互的软件,支持SIP、H.323信令。媒体支持SILK,OPUS,G729,G711等语音编解码,VP8,H264等视频编解码。能处理语音,视频点对点通话,会议等模式。

    l fileserver:文件服务器,主要用于IVR语音及通话录音文件的管理。

    2.4面向用户系统

    面向用户界面系统包括ccc和admin,以下主要介绍ccc和admin的一些基本功能项。

    2.4.1 ccc座席端系统

    主要包括座席信息管理、话单管理、客户资料管理、工单管理、知识库和监控。

    l 角色:分为班长席和普通座席

    l 座席信息管理:主要用于座席人员个人信息的管理,通过编辑可以修改个人信息

    l 话单管理:记录系统全部的来电和去电通话记录

    l 客户资料管理:记录系统所有的客户资料信息

    l 工单管理:记录系统全部的工单信息

    l 知识库:记录座席人员日常的一些操作及技能文档,并可以共享给所有座席人员参考

    l 监控:班长席可以通过监控功能来控制普通座席的一些操作

    2.4.2 admin呼叫中心管理系统

    主要包括系统首页、外呼、总机、报表、监控、录音、配置和账户。

    l 系统首页:包括首页、管理和审核

    l 外呼:包括联系人管理、策略设置、任务模板和任务列表

    l 总机:流程配置、总机配置和挂机短信,总机配置包括特服号、日志管理、sip号码、分机管理和总机管理

    l 报表:包括呼叫日志、呼叫话单、短信详单、通话报表、任务汇总统计、座席数据统计、通话详单数据、呼叫结果汇总统计、通话按键、座席签入签出、座席工作情况日志、座席工作量时报、座席小结统计、小结详情、客户呼叫统计、公有云呼叫话单和IVR按键统计

    l 监控:包括模块监控、线路监控和告警监控

    l 录音:包括手动外呼录音、预测外呼录音、质检结果查询、座席质检查询、服务质量分析和质检设置

    l 配置:包括通话设置、客户配置、微信配置流程配置、短信配置、功能费配置、多渠道配置、高级配置、系统配置、黑名单审核和公告管理。通话配置包括特服号管理、日志管理


    展开全文
  • 呼叫中心的解决方案

    千次阅读 2012-05-05 10:11:49
    呼叫中心的解决方案 曾锃 田忠和 摘 要 呼叫中心技术是一门新兴的多学科交叉的技术,于90年代迅速崛起并在国外得到了广泛地应用。对呼叫中心的开发作了一般性探讨,并着重介绍了呼叫中心同外围设备(包括...

    呼叫中心接入的解决方案

    曾锃 田忠和

    摘  要  呼叫中心技术是一门新兴的多学科交叉的技术,于90年代迅速崛起并在国外得到了广泛地应用。对呼叫中心的开发作了一般性探讨,并着重介绍了呼叫中心同外围设备(包括电话、传真、人工座席和Web服务器)的接入。
    关键词  呼叫中心  座席代表  Web  进程

    1  呼叫中心业务的扩展

      呼叫中心(Call Center)传统上是指若干个人工座席代表,集中处理打入或打出电话的系统。近年来,随着通信和计算机技术的发展和融合,特别是Internet的应用,呼叫中心被赋予了新的内容。呼叫中心不但能处理电话,还有自动语音、传真、电子函件、Web访问,甚至是基于Internet的电话和视频会议等。出现了将通信服务,语音和传真服务,Web服务,Email服务,数据库服务等集于一身的综合性(All-in-one)呼叫中心服务。
      呼叫中心的客户设备有两大类:电话(包括电话,传真机)和计算机。它们以同一个电话号码,按不同的方式连通呼叫中心,请求三种服务:电话-自动语音应答服务;电话-人工座席服务;计算机-Web服务。
      用户的呼叫,都由CTI(Computer Telephone Integrate)接入。前两种方式是由CTI接入后直接进行调度和服务。对计算机的服务请求,因为是通过Modem拨号接入的,因此CTI辨识后将电话通路转接到服务端的Modem池,通过远程服务器连接到呼叫中心的Web服务器。呼叫中心的功能延伸后增加了接入的复杂性。本文将对语音、座席、Web服务的接入方案和处理方法进行阐述。

    2  呼叫中心系统解决方案

    2.1  方案的构成
      
    呼叫中心一般分为三个主要部分:第一是客户接入设备;第二是CTI设备;第三是企业内部的Intranet系统。Intranet包括远程服务器、防火墙、路由器、Web服务器、后台数据库服务器等。图1显示了以功能卡为主的呼叫中心解决方案。

    t48-1.gif (6452 bytes)
    图1以功能卡为主的呼叫中心示意图

    2.2  CTI模型
      CTI是呼叫中心的核心设备。它负责呼叫接入、调度控制、信息通信和自动操作等任务。它由工控机、语音卡和座席卡以及应用软件等构成。
      开发模型在CTI应用结构和整个开发过程中,通常涉及到三个方面:最终用户、应用系统开发商、硬件厂商(如图2示)。

    t48-2.gif (2529 bytes)
    图2CTI系统模型

      最终用户所用的应用系统一般由系统最终用户、应用系统开发商、硬件厂商、语音处理/电话网络接口、操作系统及驱动程序、开发平台组成。而应用系统开发商必须在硬件厂商提供的软硬件开发平台下,结合具体操作系统提供的编程环境,给最终用户开发应用系统。硬件厂商则必须开发稳定、可靠的硬件产品以及丰富、方便的开发接口(如硬件驱动程序)。

    3  呼叫中心的接入方式

      在CTI行业中,有许多制造商,如DIALOGIC,MNS等公司。本文将用DIALOGIC公司的系列产品,VFX/40 ESC语音卡,处理电话的提起和挂断,检测电话的双音频信号,发送语音和传真。MSI/80 SC座席卡,此卡兼用两种连接:一部分卡的呼出口连接座席电话,建立座席通道;另一部分呼出口连接Modem池,通过远程服务接至Web服务器,实现Intranet的应用。操作系统采用SCO-UNIX。
      客户通过一个电话号码拨入呼叫中心,根据不同功能有三种接入方式:
      (1)自动语音接入:客户拨通电话, VFX语音卡检测到呼叫信号即自动用语音应答,客户根据语音提示,用电话按键操作,CTI从后台数据库获取数据,以语音或传真方式提供所需信息。
      (2)请求座席接入:开始和自动语音接入一样,当根据提示按下接转人工座席的特定电话键后,CTI软件通过MSI系列座席卡接通空闲座席代表的电话,进行客户和座席业务代表的会话。
      (3)Web浏览接入:客户计算机由“拨号网络”拨通电话,客户计算机在“拨号网络”设置时要做特殊设定,设定拨入号码后加“b”。当计算机拨通电话后,CTI 的VFX语音卡辨识出有双音频信号“b”,就立即通过SC总线连通MSI系列座席卡的专用呼出口,此呼出口连接在Modem池上,由此建立客户计算机和Web服务器之间的连接。

    4  呼叫中心接入的软件设计

      接入处理包括对客户呼叫的响应和挂断。整个过程可分为五个部分:(1)呼叫的接入;(2)座席的接入;(3)Web连接;(4)座席和Web服务的断开;(5)语音卡和座席卡的桥接和断开。下面分别加以说明。
    4.1  呼叫的接入
      呼叫接入是呼叫中心的核心技术之一。有适用于PSTN或ISDN的接入设备,可自动检测和接收电话通信所需的各种信号、信令,完成信令和协议之间的转换和控制。VFX/40 ESC用于PSTN。
    4.1.1  主要处理模式
      在DIALOGIC开发软件包中的许多函数都有同步(Synchronious)和异步(Asychronious)两种模式。同步模式是一种线性方式,各种过程在软件的控制下顺序执行,例如:在接入电话后播放欢迎致辞。在播放的过程中,不执行其它操作。异步模式是事件触发方式,例如:电话接通(off_hook),挂断(on_hook),语音播放(dx_play)等都是作为一个事件来处理。CTI产生各种突发事件,驱使执行相应的应用函数,实现相应的功能。例如:语音开始播放是一个事件,软件将根据需要,控制语音卡播放不同的语音。语音开始播放后返回,等待下一个事件的发生。
      由此,应用程序也可采用同步和异步两种方法。同步处理将每一路电话接通到挂断的全过程作为一个进程来处理,过程清晰,编程方便,程序流程能够预测和控制。其缺点是灵活性差,如果系统需要修改或扩展时,程序修改的量相当可观,并且所占用的系统资源大。异步处理适应灵活多变,修改和扩展方便,占用系统小。但系统编程复杂,对各种事件的相应处理和出现时间必须精确地掌握。
    4.1.2  处理模式的扩展
      针对同步和异步的不同特点,我们采用异步守候,同步运行的模式,见图3。

    t49-1.gif (3542 bytes)
    图3呼叫接入过程

      异步守候进程等待呼叫事件,在第一次振铃之后,检测是否有特殊双音频信号‘b’,如果检测到,则置Web服务标志位‘m’;同时唤醒同步运行进程;将语音通道号和Web服务标志位作为参数传至同步运行进程。如果没有检测到,则唤醒同步运行进程后,将语音通道号和语音服务标志‘t’传至该同步运行的服务进程。例如:一个同步运行的服务进程p4,它的第一个参数是电话和Modem的区别标志,‘m’:Modem,‘t’:Telephone;第二个参数是通道名称;第三个参数是通道号。利用system命令调用p4。
    4.1.3  实现语句
    if(digbuf[chfd].dg_value[0]=='b'){  /* 判断缓冲区内容是否为b */
      sprintf(dispbuf,"p4 %c %s %d &",'m',chptr->devname,
      chptr-.chno);
      system(dispbuf);   /* system调用为Web服务的p4,
            后面加&为后台运行 */
      }
    else{
      sprintf(dispbuf,"d4 %c %s %d &",'t',chptr->devname,
      chptr->chno);
      system(dispbuf);   /* system调用为电话语音服务的p4 */
    }
      同步运行服务进程发现Web服务标志置位,就转向网络服务,否则将相应的语音通道打开,获得语音句柄(handle),提供传统的语音或传真服务。
      这种混合方式,能及时捕捉呼叫信号,按任务分别执行。其优点是系统资源占用相对较少,编程清晰、处理方便。例如:如果完全采用同步模式,每一个语音通道将有一个进程守候,即使没有呼入,语音通道进程依然存在。而采用混合方式,只在出现呼叫时才产生一个相应的同步进行服务进程,无疑大大提高了系统资源的利用。
    4.2  座席的接入
      座席接入的任务是由语音服务转为呼叫座席,实现人与人的对话,并且将客户的帐号、口令等信息传给座席计算机。
      需要人工座席服务时,语音服务进程执行call_lady函数,将客户信息传递给座席进程,座席进程接收消息后按一定算法(如均衡呼叫算法)连通空闲的座席电话。UNIX进程间的通信一般有消息队列,共享内存和管道三种方式。接入时我们采用消息队列,消息队列是内存的一部分,任何进程都可以定义消息队列,并在队列中写入或取出消息内容。我们规定了进程通信协议。以下是语音接入处理进程发向座席接入进程的消息队列结构:
    struct  MSGFORM{
      char  MsgID;    /*消息队列唯一的标识号*/
      char  msgtext[30];    /*消息体*/
    } ;
      消息体内的信息结构:
    struct  MSGTEXTSTRU{
      char  voxchannel[8];  /*语音通道的唯一标志*/
      char msgtype;  /*服务类型:T-座席服务,P-Web服务*/
      char  usercounte[10];    /*客户帐号*/
      char  userpasswd[6];  /*口令*/
    };
      消息体的内容包括语音通道的标识,类型标志,帐号和密码。构成一个定长的字符串。语音通道的标识是DIALOGIC系列所规定的通道唯一标志。类型标志可自定义。
      座席接入后返回消息队列给语音处理进程,表示接入是否成功。这一次消息交互是以MsgID消息队列标识号握手的。
    4.3  Web的接入
      Web接入和座席接入使用同一块座席卡的不同呼出口,进程间的交互过程使用与座席同一个消息队列,只是服务类型为P,连通空闲的Modem口,实现呼叫转移。从而登录远程服务器,由远程服务器提供Web的网络服务。
    4.4  座席和Web服务的断开
      接入也包括断开操作。断开有两种情况:一种是工作结束客户主动挂机断开连接,或者座席、Web服务繁忙不能连接而正常断开;另一种是座席故障无响应或客户长期占用Web服务,超时而引起的非正常断开。例如,客户浏览Web后不再操作。我们采用三种非正常断开方案:一是浏览器TCP/IP自动超时断开拨号网络;二是Web应用程序对于超时不操作的用户断开其连接;三是规定每一笔浏览业务连接的最长时限。在一定的时间之内,客户必须完成业务操作,否则时间一到,呼叫中心程序断开连接。
    4.5  语音卡和座席卡的桥接和断开
    4.5.1  原理说明
      语音卡和座席卡之间通过SC总线进行信息交换。SC总线的信息传输是数字信号,采用分时方式,每一个时间片段称为时间槽(time-slot)。卡的通道在SC总线上的表示即为时间槽,在软件中通道通过开发包中的函数获得特定的时间槽,此时间槽在整个系统中是唯一的。SC总线的桥接就是通过通道句柄对其它通道的时间槽进行监听(listen)实现的。桥接过程如下:
      ①语音通道获得一个时间槽(time-slot)。
      ②座席通道获得一个时间槽(time-slot)。
      ③语音通道的句柄监听(listen)座席通道的时间槽。
      ④座席通道的句柄监听(listen)语音通道的时间槽。
    4.5.2  实现语句
    voxdevhd=dx_open(voxchannel,0)
    /*以同步方式打开语音通道,获得语音通道句柄voxdevhd */
    statdevhd=ms_open(statchannel,0)
     /*以同步方式打开座席通道,获得座席通道句柄statdevhd */
    dx_getxmitslot(voxdevhd,& voxtsinfo)
         /*语音通道获得时间槽voxtsinfo*/
    ms_getxmitslot(statdevhd,& stattsinfo)    
         /*座席通道获得时间槽stattsinfo*/
    ms_listen(statdevhd,& voxtsinfo) /*语音通道监听座席通道*/
    ag_listen(voxdevhd,& stattsinfo) /*座席通道监听语音通道*/
    通道断开,只需通道句柄取消监听(Unlisten)时间槽就可以了。语句为:
    ms_unlisten(statdevhd)    /*座席通道断开监听*/
    ag_unlisten(voxdevhd)    /*语音通道断开监听*/
    4.6  方案小结
      此方案优点是通过座席卡转接Modem,完成远程服务器的登录,因此可以把它当成座席的一个部分。只需加入人工座席和Modem的区别标志位,就可以很快地完成编程的工作,而源程序的变动不大。同时可以根据负载的情况,灵活地调节人工座席和Modem的个数,以满足实际的需要。此方案电气性能好,软件容易实现。但其缺点是占用了宝贵的座席资源,以MSI座席卡为例,每块卡8个端口(Port)。如果Modem占了4口,人工座席最多只有4个,对于座席数量多或Web接入多的系统,要用较多的座席卡,以增加呼出端口数量。

    5  总结及展望

      本文讨论了呼叫中心的系统解决方案及接入的软件设计方案。随着Internet和其它传播媒介的发展,呼叫中心的接入方式必然不断地丰富和扩展。在电子商务及许多公众服务行业中将发挥出越来越大的作用。

    曾锃(华中理工大学自动控制科学工程系  武汉 430074)
    田忠和(华中理工大学自动控制科学工程系  武汉 430074)

    参考文献

    1,曲晋云. 呼叫中心及相关技术. 电信快报, 1999年第1期
    2,Herman D'hooge. 通信PC机. 电信交换, 1997年第1期
    3,Dialogic Cooperation, Voice Software Reference for Unix

    展开全文
  • 14、Call Management (Outgoing Call Screening) 15、Call Park 16、Call Pickup 17、Automatic Redial 18、Click to Dial 在《最常用的18个SIP呼叫业务流程详解(1~5)》中介绍了三种保持(Hold)和两种转接...

    目录

    6、Transfer - Instant Messaging

    7、Call Forwarding Unconditional

    8、Call Forwarding - Busy

    9、Call Forwarding - No Answer

    10、3-Way Conference - Third Party Is Added

    11、3-Way Conference - Third Party Joins

    12、Find-Me

    13、Call Management (Incoming Call Screening)

    14、Call Management (Outgoing Call Screening)

    15、Call Park

    16、Call Pickup

    17、Automatic Redial

    18、Click to Dial


     

    在《最常用的18个SIP呼叫业务流程详解(1~5)》中介绍了三种保持(Hold)和两种转接(Transfer)的详细流程,本节继续介绍剩余的流程。

     

    6、Transfer - Instant Messaging

      Transfer - Instant Messaging,我们称之为即时消息转发。其主要的工作方式是,首先用户Alice和Bob创建了一个会话,然后Bob呼叫Carol,Bob发送即时消息给Carol,即时消息中包含一个Alice的URL和一个嵌入的Replace头。如果Carol点击这个URL链接,Carol的SIP终端会对Alice发送一个INVITE请求,并且替换了会话中的Bob。在这个示例中,其URL传递是使用的SIP MESSAGE method来实现(参考RFC3428),也可以使用其他IM即时协议来完成Bob和Carol之间的URL传递工作。具体的处理流程经过11个步骤:

      现在,我们配合SIP消息来进一步说明如何实现即时消息转发方式。

      首先,Alice对Bob发送INVITE消息(F1):

      Bob回复180(F2) :

      紧接着Bob对Alice发送 200 OK(F3):

      Alice对Bob发送Ack确认,开始RTP流(F4):

      然后Bob对Carol发送一个message call(F5),在这个即时消息中携带了Alice的URL和Replaces头。

      Carol看到以后,发送一个200 OK给Bob:

      接下来,Carol点击URL,控制这个呼叫,对Alice发送一个INVITE请求,并且替换了Bob(F7)。

      Alice对比dialog中消息和Replaces的头消息,确认以后,接受Carol的请求。Alice对Carol回复一个200 OK(F8):

      Carol对Alice回复了ACK消息(F9),并且开始RTP流。

      Alice和Carol开始通话以后,并且因为已经替换了Replaces头,所以Alice对Bob挂机处理,Alice对Bob发送BYE消息(F10):

      Bob对Alice发送200 OK(F11),到此为止,即时消息转接的流程完成。

    7、Call Forwarding Unconditional

      Call Forwarding Unconditional,我们称之为无条件呼叫前转。从字面意思,读者也可以看明白,被呼叫方会把呼叫进行无条件转移。与之对应的是忙状态呼叫前转和无应答呼叫前转。这些业务都涉及到了运营商接入业务(PSTN或者IMS),不是专门针对内网IPPBX用户之间的电话转接功能。我们会在后续的章节中分别介绍这两种呼叫的流程。这里,我们仅对无条件前转进行分析。

      这里,我们假设Alice呼叫Bob(这里没有标识Bob的流程)。Bob会把呼叫无条件前转到PSTN网络。如果实现此场景,呼叫必须经过Proxy和Gateway来实现处理。Gateway看作为另外一个Proxy的URL地址,同时支持了PSTN的接口。在以下的场景中,Alice对Bob进行呼叫,这个INVITE消息会经过Proxy,Proxy则会重写请求的URL地址,然后前转这个INVITE到Gateway地址。以上两步是前转最重要的部分,所以,我们仅针对这个部分进行深入分析,对网关侧和Bob的响应不做分析。

      这里,读者需要注意,在以上示例中的F3中,Proxy是通过返回Alice 一个181 响应消息来实现的呼叫前转处理。严格地说,在这个使用场景中,Proxy仅扮演着用户代理的角色,它不能生成non-100的临时响应回复消息。另外需要说明的是,呼叫前转的处理也可以通过redirect的方式来实现,就是通常所说302 Moved Temporarily response。以下图例是一个完整的无条件呼叫前转流程和具体的SIP消息操作。

      接下来,我们针对无条件呼叫前转的具体细节,结合请求响应消息进行分析介绍。首先,Alice对Bob发送INVITE请求,通过Proxy执行呼叫(F1):

      然后,Proxy回复Alice 一个100 trying(F2),表示正在处理这个请求,忽略了流程图。接下来,Proxy会对Alice发送一个181响应消息(181 Call is Being forwarded),执行F3流程;同时Proxy对Gateway发出一个INVITE请求(F4)。这里,Proxy对Gateway发送到INVITE请求中已经重写了请求URL地址。

      读者可以看到,Proxy和Gateway都没有做任何其他的条件判断,直接转发到下一个目的地地址。在F5中,Gateway直接对Proxy回复一个180 Ringing,然后在F6中,Proxy回复Alice一个180 Ringing。

      Gateway对Proxy发送180 Ringing以后,紧接着,Gateway对Proxy发送200 OK(F7),然后Proxy对Alice发送200 OK(F8)。

      Alice收到200 OK以后,接下来,Alice对这个INVITE请求进行确认,发送ACK消息(F9)。Proxy收到ACK消息以后,直接对Gateway发送ACK确认信息(F10)。双方RTP语音流正式创建。

      通话完成后,Alice挂机,对Proxy发送BYE消息(F11),然后Proxy对Gateway发送BYE消息(F12)。

     

      最后,Gateway对Proxy发送200 OK(F13),Proxy再对Alice发送200 OK(F14),到这里,双方的无条件呼叫前转正式结束。

    8、Call Forwarding - Busy

      Call Forwarding - Busy,我们称之为遇忙呼叫前转。简单来说,就是呼叫方通过Proxy呼叫被呼叫方时,被呼叫方此时处于忙状态,然后Proxy把呼叫再次转发到第三方用户。例如,Alice通过Proxy呼叫用户1,此时,如果用户1处于忙状态,Proxy收到用户1的回复信息,Proxy会把此呼叫通过一个INVITE再次转发到用户2终端。遇忙呼叫前转到流程图如下:

      下面,我们配合具体的SIP消息示例来进一步说明整个遇忙呼叫前转的处理过程。

      首先,Alice对Proxy发送一个INVITE请求,需要呼叫用户1(F1),Proxy

      接下来对用户1发送一个INVITE请求,通知用户1,Alice要呼叫对方。

      在处理以上流程的同时,Proxy会对Alice发送一个100 Trying(F3),Proxy告诉Alice正在处理此呼叫,忽略了100 Trying图例。经过一定时间后,用户1此时此刻正在处于电话的忙状态,不能接听此呼叫。然后用户1对Proxy发送了一个486 Buy响应消息(F4)。

      Proxy获悉用户1是处于忙状态后,对用户1发送一个ACK确认信息,表示收到了用户1的状态响应(F5)。

      为了处理用户1处于忙状态不能接听电话的问题,Proxy首先通知Alice,proxy需要进行电话前转。所以,Proxy需要对Alice发送一个180 call is Being Forwarded的消息,通知Alice,你的呼叫正在被前转。同时,Proxy再次发起一个INVITE请求,这次,对用户2发出INVITE请求进行呼叫前转。

      接下来,用户2对Proxy发送180 Ringing响应消息(F8),Proxy然后对Alice发送180 Ringing响应消息(F9),表示前转接受。

     

      发送180 Ringing以后,紧接着,用户2对Proxy发送200 OK(F10),然后Proxy对Alice发送200 OK(F11)。

      Alice收到Proxy发送的200 OK以后,发送确认消息ACK(F12)。然后Proxy对用户2发送确认消息ACK(F13)。接下来,Alice和用户2创建媒体流,双方开始正常通话。

      通话结束后,Alice对Proxy发送BYE消息(挂机,F14),然后Proxy对用户2发送BYE消息(F15)。

      最后,双方进行挂机的最终确认,首先由用户2发送200 OK到Proxy(F16),然后Proxy对Alice发送200 OK(F17)。

     

      到此为止,遇忙呼叫前转的处理流程正式结束。

    9、Call Forwarding - No Answer

      Call Forwarding-NO Answer, 我们称之为无应答前转。具体的实现过程和前面谈论忙呼叫前转的处理方式基本一致,唯一不同是,用户1是无应答,然后Proxy通过定时器检测超时,进行对第三方用户2前转处理。其余的处理流程基本和遇忙前转的处理流程一致。简单来说,Alice通过Proxy呼叫用户1,用户1在一定时间内没有应答此呼叫,然后Proxy把这个呼叫转接到用户2,对用户2进行呼叫处理。在请求超时后(F6),Proxy对用户1发送取消请求,然后通知Alice,同时对用户2再次进行INVITE请求处理,进行呼叫请求。具体的呼叫流程如下:

      接下来,笔者配合具体的SIP消息来进一步说明无应答呼叫前转的处理方式。

      首先,Alice通过Proxy对用户1发出INVITE请求,对用户1进行呼叫(F1),然后Proxy对用户1发送INVITE请求,对用户2进行呼叫请求处理。

      接下来,Proxy马上对Alice发送一个100 Trying(F3忽略),表示正在对用户1进行呼叫,通知Alice等待。用户1对Proxy发送180 Ringing(F4),Proxy也对Alice发送180 Ringing(F5)。

      这时,用户1处于振铃状态,在Proxy设定的定时器超时设置范围内,用户1终端无人接听此呼叫。因此,Proxy对用户1发送Cancel消息,通知用户1停止振铃。

      然后,用户1对Proxy发送200 OK(F7):

      接下来,用户1马上对Proxy发送一个487 响应消息,表示定时器超时,在一定振铃时间内无人应答此呼叫。

      Proxy收到超时消息以后,对用户1发送ACK确认消息,确认超时事件(F9):

      这时,Proxy需要做两件事。Proxy知道用户1是因为振铃超时,无人应答这个呼叫。接下来,Proxy重新调整呼叫流程,再次进行呼叫转接到处理。首先,Proxy先对Alice发送一个电话转接到响应消息(181 电话前转),通知Alice,你的呼叫正在被前转到其他用户终端(F10)。紧接着Proxy对用户2发送一个INVITE请求,对其进行呼叫(F11):

      然后,用户2对Proxy发送180 Ringing(F12),Proxy又对Alice发送180 Ringing(F13):

      振铃发送以后,用户2继续对Proxy发送200 OK(F14),Proxy又对Alice发送200 OK(F15):

      Alice收到200 OK以后,继续对此流程进行进一步的处理,以便开始双方的通话或RTP流。Alice马上回复Proxy ACK确认消息(F16),Proxy也马上对用户2回复ACK确认消息(F17):

     

      经过一定时间段通话以后,Alice首先挂机,对Proxy发送BYE消息(F18),Proxy再对用户2发送BYE消息(F19),通知用户2挂机:

      最后,用户2对Proxy发送最后200 OK消息(F20),然后Proxy对Alice发送最后的200 OK(F21)。到此为止,无应答呼叫前转的呼叫流程正式完成。

      这里读者一定要注意,我们讨论的呼叫前转方式方式可以通过IPPBX或者软交换的配置来实现,proxy或者媒体服务器的设置会影响振铃的时长设置,这样可能导致电话振铃问题,被呼叫方如果接听不及时的话,可能产生无应答呼叫。

      所以,在部署前转时一定要配合IPPBX或者其他的软交换来解决。另外,结合一些其他的应用需求,还有一些IPPBX可以设置为无应答或者分机随行的方式,如果终端无应答,可以转接到用户手机或者其他的终端,或者留言等方式。这些需要用户支持其他的接入方式来实现。

    10、3-Way Conference - Third Party Is Added

      3-Way Conference - Third Party Is Added,我们称之为三方会议邀请。简单来说,此呼叫业务就是一个简单的三方电话会议。通常来说,如果是两方通话,我们称之为正常呼叫业务。如果介入了第三方或者更多人的话,我们称之为三方会议或者多方会议。

      一般的三方会议至少需要一个混音处理单元。在以下的部署场景中,Alice呼叫Bob,然后双方进行通话。这时,Bob想把第三方Carol也邀请到电话会议中来一起讨论问题。当然,Bob自己本身必须具备处理第三方媒体混音的功能。然后,Bob首先对Alice发送一个re-INVITE,在INVITE中,修改了多个Contact URLs为一个URL,这个URL表示Bob的混音单元。然后,Bob对Carol发送一个INVITE请求,邀请Carol参加会议,并且使用同样的Contact URL。

      这里,读者要注意,Bob邀请的处理方式可能有所不同。Bob可以先等Carol应答以后,再对Alice发送re-INVITE。Bob也可以呼叫Carol之前,先把Alice设置为等待状态。另外,Bob邀请会议时,Bob包含了一个功能标签tag-“isfocus”,表示Bob是一个会议处理中心。"isfocus"是在规范rfc3840中定义:

      Summary of the media feature indicated by this tag: This feature tag

      indicates that the UA is a conference server, also known as a

      focus, and will mix together the media for all calls to the same

      URI [13].

      关于会议中focus的定义和规范,读者可以参考rfc4579的第三章节。以下是一个完整的会议第三方邀请处理流程。

      下面,我们通过SIP消息结合具体的流程来说明第三方会议邀请是如何进行的。

      首先,Alice对Bob发送INVITE请求,对其进行呼叫(F1):

      Bob对Alice回复180 Ringing(F2):

    11、3-Way Conference - Third Party Joins

      3-Way Conference - Third Party Joins,我们称之为三方会议加入。和上面的三方会议邀请不同的是,这里的第三方是自己主动希望加入到电话会议中,而不是由其他人邀请加入。因此,在处理三方会议时,其处理流程和前面的被邀请的方式完全不同。

      通过以上的处理流程我们来详细解释会议加入的方式是如何处理的。这里,我们假设Alice和Bob两个人正在进行双方的语音通话。Carol通过其他学习方式或者对Bob的订阅消息,例如Bob发送的其他非SIP消息或者Bob对Carol发送到NoTIFY消息,其消息中含有dialog事件包。关于dialog的事件订阅的处理,读者可以参考RFC4579中的第5.8章节和RFC4235的规范。

      这时,Carol希望加入到Alice和Bob之间的电话呼叫中。这时,Carol会对Bob发送一个INVITE请求(F5),这个请求中包含一个Join头,在这个头中,包含Alice和Bob两者之间的dialog,以此来保证Carol加入到是正确的dialog,而不是其他的会议呼叫。Bob然后对Alice发送一个re-INVITE修改了通话模式(F7),从双方谈话变成一个“isfocus”模式(rfc3840),开始支持三方会议的模式。然后,Bob才接受来自于Carol的INVITE请求,最后开始三方通话或者电话会议模式,此时,三方会议加入的处理流程彻底完成。现在,我们通过完整的SIP消息配合具体的处理流程来进一步对电话加入的方式做出详细介绍。

      首先,Alice对Bob发送INVITE请求,进行电话呼叫(F1):

      然后,Bob对Alice发送180 Ringing(F2),紧接着,Bob对Alice发送200 OK(F3):



      然后,Alice对200 OK回复ACK确认信息(F4),双方开始RTP流传输:

      这时,Carol通过Bob发送到其他的非SIP消息或者NOTIFY事件了解了Alice和Bob之间正在进行电话呼叫,Carol想加入到这个电话呼叫中。因此,Carol对Bob发送一个INVITE请求,在这个INVITE请求中(F5),包含有Join的头,这个头中含有加入他们之间还有的dialog消息内容(Join中忽略了具体的内容):

      Bob先对Carol发送一个180 Ringing(F6):

      然后,Bob再对Alice发送一个re-INVITE请求,Bob通知Alice,因为Carol要加入电话会议中,我现在需要修改通话模式,修改为“isfocus”模式来支持电话会议,需要进行媒体混音处理。

      Alice收到Bob的INVITE请求后,对其请求表示同意,然后对Bob发送200 OK(F8):

      Bob对Alice 的200 OK发送响应消息,获悉Alice同意修改为会议模式(F9):

      现在,Bob完成了和Alice的协商,获悉Alice已经准备好进行电话会议。接下来,Bob才对Carol发送200 OK,接受了其要求加入电话会议的INVITE请求,这里包括了新的Contact的会议地址。

      接下来,Carol知道Bob已经允许自己可以加入到会议中,对Bob发送最后ACK确认消息,表示正式加入会议中。此时,Carol加入到了会议室,三方会议正式开启(F11),RTP流开始工作。这里的Bob构成了一个媒体混音单元,也可能是一个会议媒体服务器功能,进行三方混音。

      这里,笔者再进一步介绍一下会议的标签isfocus tag。会议模式中的isfocus参数可以支持多种使用方式,通过SIP,它可以支持以下几种方式:

    • 创建会议
    • 加入会议
    • 邀请用户加入会议
    • 踢出会议用户
    • 支持对会议URL判断,可以检查到是否是会议URL
    • 删除会议

      会议创建的方式Ad-Hoc方式临时自组的方式来创建一个会议,也可以通过REFER方式来创建一个会议室。会议邀请的方式可以通过INVITE请求,用户可以主动呼入或者用户被呼方式来进入到会议室,也可以通过REFER的方式邀请用户进入到会议室。关于会议的管理和使用部署,RFC4579中有着非常详细的说明,同时此规范也介绍了其他的协商流程。读者可以阅读此规范进一步了解多方会议的处理流程。

      在开源媒体服务器中,Asterisk/FreePBX/FreeSWITCH也支持了强大的会议功能。用户可以创建会议室,系统通过自动拨号的形式邀请会议用户来加入到会议中,用户也可以通过语音IVR的形式进入到会议室中。会议主席也可以对会议人员实现静音或者踢出等功能。如果使用Asterisk的界面管理系统FreePBX,用户也可以通过界面来创建会议室,支持多种会议的管理功能,例如会议密码设置,最大会议用户人数设置,进入会议室播放提示,音乐等待等功能。

    12、Find-Me

      Find-Me, 我们称之为有效用户查询呼叫。简单来说,Alice通过Proxy呼叫Bob,Bob可能有几个Contact地址。Proxy会根据不同的Contact列表来逐一查询这些地址的状态,如果有可接通的地址,则对其进行呼叫;如果没有,Proxy会继续查询其他的地址,直到找到可接听呼叫的地址。一旦找到可接听通话的地址,则不再继续查询其他的地址。

      这里笔者提醒读者,在对用户状态的查询中,系统也可以使用并列查询的方式。我们刚才使用的是按序查询的方式,系统也可以使用并列查询的方式。并列查询状态下,Proxy会同时对所有Contact 列表中的地址发送查询可接听的地址,然后创建RTP语音流。以下图例中说明了两种重新的处理不同。并列查询的处理方式:

      按序查询的处理方式:

      在本章节的有效用户查询呼叫中,我们使用的方式是按序查询的方式。Proxy会通过Bob的Contact列表逐一查询地址状态,如果有效,则创建呼叫。

      下面,我们结合SIP消息和具体的流程进行分析。

      首先,Alice通过Proxy对Bob进行呼叫,发送INVITE请求给Proxy(F1),Proxy对Bob发送INVITE请求(F2):

      接下来,Proxy马上回Alice 一个100 Trying(这里忽略,F3),表示呼叫正在处理中。用户1对Proxy回一个180 Ringing(F4)。紧接着,Proxy对Alice回复一个180 Ringing,表示用户1已经振铃(F5)。

     

      但是,在一定的振铃时间内,用户1没有人接听电话呼叫,Proxy的定时器出现超时。然后,Proxy对用户1发送Cancel消息(F6)。

      用户1对Proxy回复一个200 OK(F7):

      然后,用户1对Proxy发送一个487 超时消息(F8):

      Proxy对487 回复一个ACK确认消息(F9):

      在获悉用户1呼叫超时以后,Proxy继续对Contact 列表中的用户2地址发送INVITE请求(F10):

      但是,用户2根本没有登录注册,所以,用户2回复480 消息(F11)

      Proxy对用户2回复ACK确认(F12):

      然后,Proxy继续对Bob的Contact 列表中的用户3地址发送INVITE请求消息(F13):

      但对用户3发送INVITE请求后,发现用户3处于忙状态,不能接听这个呼叫。用户3回复486 Busy Here(F14):

      紧接着,Proxy对用户3回复ACK确认消息(F15):

      接下来,Proxy继续对Bob的Contact列表中的用户4地址发送INVITE请求(F16):

      然后,用户4回复Proxy 180 Ringing(F17),Proxy再回复Alice一个180 Ringing(F18):

      紧接着,用户4对Proxy发送一个200 OK(F19),然后,Proxy又对Alice发送一个200 OK(F20):

      然后,Alice对Proxy发送一个ACK确认消息(F21),Proxy对用户4发送一个ACK确认消息(F22)。到此为止,整个有效用户查询呼叫的流程完成,双方开始语音流的互通。

      结合以上多种用户终端出现的情况,Proxy经过了Bob的4个Contact列表地址查询,第一个呼叫超时,第二个地址没有登录,第三个用户忙,到最后一个用户地址,才真正和Alice创建了RTP语音流的传输。在每一个异常状态下,终端都返回相应的响应消息,然后Proxy会对每一个响应发送ACK,然后再进行下一个有效用户的地址查询。

      通话一段时间后,用户4对Alice挂机,对Proxy首先发送BYE消息(F23), Proxy对Alice进行挂机处理,对其发送BYE消息(F24):

      然后,Alice对Proxy发送200 OK(F25),Proxy再对用户4发送200 OK(F26):

      Alice和用户4的通话正式结束。

    13、Call Management (Incoming Call Screening)

      Call Management (Incoming Call Screening),我们这里称之为呼叫筛选或呼叫过滤。在企业通信环境中,为了节省员工的时间,提高工作效率,用户可以设置一个电话筛选机制来保证不被一些不相关的电话骚扰。简单来说,如果有外部呼叫呼入到IPPBX的终端时,终端可以显示呼叫方号码,或者名称,或者通过第三方媒体发送到语音提示。此时,终端用户可以根据终端所设置的号码地址薄选择继续接听电话,拒绝,转语音邮箱,或者对呼叫方播放一个自定义的语音媒体。以上这些功能都可以通过Proxy加媒体播放服务器来实现,或者使用企业IPPBX本身的配置功能来实现。为了更加专业地表达此功能名称,我们称之为呼叫筛选或呼叫过滤,黑白名单过滤比较通俗易懂。其实,呼叫筛选和黑白名单过滤的功能要求基本类似,从功能设置的角度来说它们的功能基本相同。

      在日常生活中,我们简单称之为黑白名单过滤。因为大量的骚扰电话的问题,我们现在已经对呼叫筛选不陌生了。我们手机app所设置的骚扰电话设置或者黑名单过滤等都可以视为呼叫筛选的功能。但是,这些基于个人终端的业务支持,不是我们这里讨论的内容。

      呼叫筛选的具体流程经过了几个步骤。假设,Alice呼叫用户Bob,Bob的终端联系方式中可能已经对Alice设置为拒绝接听的地址,因此Bob拒绝接听此呼叫。拒绝接听后,Bob对Alice返回了一个消息,通知你呼叫必须通过Proxy的安全认证机制,Bob仅接受经过Proxy确认的呼叫。因此,Alice再次对Proxy发送请求,但是因为安全设置的问题,Alice没有通过Proxy的安全认证,Proxy在错误消息返回时插入了一个新的Error-info的URL地址,Alice播放这个来自于媒体服务器或者第三方声明提示等服务器的语音提示。

      这里注意,安全认证不能使用From 头来判断,必须通过Proxy的安全机制来处理。以下是一个呼叫筛选的流程图,在图例中,一般企业用户使用IPPBX本身自带的媒体播放功能对Alice实现媒体语音提示。
      接下来,我们根据SIP消息细节结合每一个处理流程来进一步说明呼叫筛选的处理过程。

      首先,Bob看到来自于Alice的呼叫,表示Alice需要和Bob通话(F1)。

      Bob拒绝了Alice的呼叫请求,要求必须通过Proxy认证才能通话。Bob对Alice发送305消息(F2):

      Alice获悉这个错误以后,对Bob发送ACK确认消息(F3):

      然后,Alice对Proxy发送INVITE请求(F4):

      然后,Proxy对Alice发送认证响应消息407(F5):

      Alice对Proxy返回确认ACK消息(F6):

      然后,Alice对Proxy发送安全认证消息(F7),携带自己的认证信息:

      Proxy经过安全认证检查以后,发现Alice没有权限直接呼叫Bob,呼叫筛选不能通过,因此对Alice返回一个失败消息(F8),并且插入了一个Error-info,带了一个URL地址。这个地址播放语音提示。

      Alice收到403 响应错误消息以后,对Proxy发送一个ACK确认消息(F9):

      为了知道Proxy对Alice发送的是什么提示,Alice会继续对这个Error-info的地址进行访问,发送一个INVITE请求(F10)这时一个媒体播放的服务器地址,其服务器会对Alice播放刚才呼叫失败的提示音:

      然后,媒体播放服务器对Alice发送200 OK消息(F11),表示可以对Alice播放语音提示。

      另外,在F11的200 OK中,媒体播放服务器对Alice增加了一个渲染功能标签,表示此服务器仅能支持自动媒体功能automaton和rendering:

      F11 200 OK Announcement Server -> Alice

      SIP/2.0 200 OK

      Via: SIP/2.0/TLS client.atlanta.example.com:5061

      ;branch=z9hG4bK74bfj

      ;received=192.0.2.103

      From: Alice ;tag=1234567

      To: Bob ;tag=234934

      Call-ID: 12345600@atlanta.example.com

      CSeq: 4 INVITE

      Contact:

      ;automaton;+sip.rendering="no"

      Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY

      Content-Type: application/sdp

      Content-Length: …

      v=0

      o=annc 2890844543 2890844543 IN IP4 announce.biloxi.example.com

      s=

      c=IN IP4 announce.biloxi.example.com

      t=0 0

      m=audio 49174 RTP/AVP 0

      a=rtpmap:0 PCMU/8000

      注意,在RFC5359规范的2.13章节中,F11的处理流程可能存在表述错误。读者需要根据实际的场景来做出正确的判断。按照流程图的示意,F11应该是从媒体服务器到Alice的返回消息:

      但是,按照正常的处理规范来说,应该是媒体服务器对Alice的返回消息(200 OK)。另外一个矛盾的地方是,在具体的流程中(F11),规范又描述为媒体到Proxy 1的处理流程:

      以上讨论是笔者仅根据官方规范做的疑点做出的自己的判断,读者可以通过其他渠道和规范发布者确认最终结果。

      现在我们回到合理的处理流程中。接下来,Alice收到200 OK以后,对媒体服务器发送ACK确认消息,然后媒体播放服务器对Alice播放语音提示(F12):

      语音提示播放完成以后,媒体服务器对Alice发送BYE消息,表示媒体播放结束,断开连接(F13)。

      最后,Alice收到了媒体播放器发送到最后提示,表示断开连接,Alice发送确认消息(F14):

    14、Call Management (Outgoing Call Screening)

      Call Management (Outgoing Call Screening),我们称之为呼出呼叫筛选。此呼叫业务和上面的呼入呼叫筛选基本类似,但是处理流程更加简单。简单举例,呼叫方Alice通过Proxy呼叫Bob,但是Bob在Alice的呼叫筛选名单中,Proxy对Alice要求安全认证的验证,Alice对Proxy发送安全认证的消息,但是因为Bob在Alice的Call Screening的筛选名单中,不能对Bob进行呼叫,因此,最后,Proxy对返回403 呼叫筛选失败,最后挂机。

      现在,我们结合具体的SIP消息,配合每个呼叫流程做进一步的细节介绍。

      首先,Alice对Proxy发送INVITE请求,要求对Bob进行呼叫(F1):

      Proxy要求Alice发送安全认证消息进行验证(F2),返回407响应消息:

      Alice获悉以后,继续对Proxy发送ACK确认消息(F3):

      然后再次对Proxy发送INVITE消息,包含了安全认证的信息(F4):

      Proxy经过检查,Alice没有权限呼叫Bob,因此对Alice返回403 Screening Failure (Originating)的消息,表示不能对Bob进行呼叫(F5)。另外,在返回的消息中插入了一个Error-info 头,包含了一个媒体播放的链接,用户可以听到失败提示音。

      Alice收到403以后,获悉自己不能呼叫Bob,发送ACK给Proxy。此时,外呼筛选流程结束(F6)。

      关于呼叫筛选的功能,很多IPPBX支持了多种配置方式和功能。比较常见的处理方式包括:不在呼叫权限组,呼叫前缀不对,用户不接受其他部门呼叫,一定时间内不接受其他无关联用户呼叫,或者其他IP地址的呼叫,出差期间不接受呼叫等筛选方式。

      这里比较关键的是筛选失败以后的处理,如何对呼叫失败方进行一个比较友好的处理方式,比如,对呼叫失败方播放语音提示,转到语音留言,抓到其他的IVR流程,或者进行后期回呼处理。在Asterisk或者FreeSWITCH平台中,这些处理策略都可以通过IPPBX的拨号规则加一定的脚本来实现筛选的路由控制。具体的实现方式用户参考网上的学习资料。

    15、Call Park

      Call Park,我们称之为呼叫驻留/停靠。简单来说,呼叫驻留就是呼叫方呼叫被呼叫方时,电话被驻留在驻留服务器(一般是媒体服务器或者IPPBX)。经过一段时间后,呼叫方电话被其他第三方用户再次接听。具体的实现过程是这样的,假设Alice呼叫Bob,Bob和Alice开始通话,通话后,可能Alice想转接第三方或者Bob可能有其他事情,暂时不能继续和Alice通话,Bob通过终端按键对其通话进行电话驻留的设置。

      所以,Alice的电话被驻留在驻留服务器或者IPPBX/媒体服务器。Alice电话被驻留以后,媒体服务器会对Bob发送订阅消息,说明电话驻留状态。然后,媒体服务器对Alice发送一个INVITE请求,通知Alice,媒体服务器现在替换了Bob来对其会话进行管理。Alice获悉驻留状态后,接受此处理流程,然后,媒体服务器或者IPPBX对其播放音乐媒体提示音。接下来,Alice对Bob发送BYE消息,媒体服务器对Bob发送Bob消息,表示现在媒体服务器已经驻留了Alice的通话,Bob脱离和Alice之间的关系。第三方Carol想接听这个被驻留在媒体服务器的呼叫,因此,首先需要对媒体服务器发送订阅消息,媒体服务器接受订阅以后,获悉Carol想接听这个被驻留的呼叫,接下来Carol对Alice发送INVITE请求,并且要求替换会话中的媒体服务器。Alice收到此请求后,同意和Carol进行通话,发送协商成功的响应消息,然后双方正式开始通话,驻留处理流程完成。

      在电话驻留的流程中,几个问题需要读者注意。首先,这里的电话驻留被重新接听的是第三方的用户,当然,接听用户也可能是发起驻留电话自己本身。但是,这样的驻留方式也不符合大部分场景中的电话使用习惯。因为,大部分已经开始的通话,或者进行电话转接,或者一定时间后双方挂机,或者挂机后,双方稍晚时间后重新呼叫对方。因此,电话驻留其实也是电话转接的一种特殊方式或特殊使用场景。其次,电话驻留的方式其实也是音乐等待的一种处理方式。只是,在电话驻留服务器或者媒体服务器中,驻留处理可以分割为多个驻留空间或者slot,电话驻留基本的处理流程或原理事实上和语音等待类似。最后,电话驻留服务器开启驻留处理时也对驻留方发送了automaton,,rendering和 byeless tag标签,表示其服务器的支持能力。以下是电话驻留的处理流程:



      现在,我们结合具体的SIP消息和每一个处理的具体细节来一步步介绍整个电话驻留的处理:



      首先,Alice对Bob发送INVITE呼叫请求(F1):

      然后Bob对Alice响应180 Ringing(F2):

      紧接着,Bob对Alice发送200 OK(F3):

      Alice收到200 OK以后,对Bob发送ACK确认消息(F4),双方开始通话。

      通话后获悉,Alice可能需要被驻留,然后第三方Carol来接听。因此,Bob首先需要对Alice通话进行电话驻留处理,把Alice的呼叫停靠在驻留服务器或者媒体服务器上,Bob对服务器发送REFER消息(F5),并且通知媒体服务器在会话中使用Bob替换Alice。这里的Refer-To是Alice,Refer-By是Bob自己。注意,这里不存在Bob和媒体服务器之间的直接的会话。

      驻留服务器收到Bob的REFER以后,对Bob发送一个202 Accepted,表示接受此REFER消息(F6):

      然后,驻留服务器对Bob发送NOTIFY消息,创建一个对事件的订阅,同时提示Bob正在处理电话驻留(F7),100 Trying:

      Bob回复200表示收到订阅事件(F8):

      接下来,驻留媒体服务器对Alice发送INVITE请求,同时替换Bob(F9),增加了渲染功能的标签,表示媒体服务器的处理能力(在Contact中插入了媒体服务器的渲染功能标签:

      Contact:;automaton ;+sip.byeless;+sip.rendering="no"

      注意:以下图例中忽略了渲染功能标签

      Alice接受了媒体服务器的请求,发送200 OK(F10):

      媒体服务器对Alice发送ACK确认消息,开始媒体流处理(这里开始播放语音提示,F11):

      提示音播放开始以后,Alice对Bob发送BYE消息(F12),表示Alice已经和媒体服务器创建了新的会话关系:

      Bob获悉Alice的电话被成功驻留以后,对Alice发送一个最终的200 OK(F13):

      这时,媒体服务器再次对Bob发送NOTIFY消息,并且携带了返回的200 OK消息,表示媒体服务器成功处理了Alice的驻留(F14)。

      Bob对媒体服务器返回200 OK消息,并且确认了dialog的ID(F15),到此为止,Alice已经完全驻留在媒体服务器中。

      接下来,如果Carol想接听这个被驻留在服务器的Alice的电话时,Carol首先需要对媒体服务器发送订阅消息,否则,Carol不知道Alice电话的事件。因此,Carol对服务器发送订阅消息(F16):

      媒体服务器对Carol回复一个200 OK,获悉媒体服务器的支持能力等渲染标签(F17):

      有了新的事件以后,媒体服务器对Carol发送NOTIFY消息,通知Carol的事件具体消息内容(F18):

      Carol获悉被驻留方的地址信息后,对媒体服务器发送200 OK(F19):

      Bob通过媒体服务器发送到NOTIFY已经获得被驻留电话的地址信息,然后,为了接听Alice的驻留电话,Bob对Alice发送INVITE请求,并且要求替换媒体服务器的地址(Replaces,F20)。

      Alice接受了Carol的请求,对Carol返回200 OK(F21):

      然后,Carol对Alice继续发送一个ACK确认消息(F22),创建RTP流,双方开始正式通话,Carol接听被驻留的电话。

      然后,Alice必须对驻留服务器发送最后的通知消息(BYE,F23),表示Alice已经开始和Carol通话,驻留服务器和Alice的驻留关系释放。

      驻留服务器最后对Alice返回200 OK(F24),表示确认驻留关系释放:

      呼叫驻留到这一步,媒体服务器释放了和Alice的驻留关系,Alice通知了Bob,Carol接听了驻留电话。呼叫驻留的流程才真正完成。

      企业IPPBX基本上都支持了呼叫驻留/停靠的业务需求。IPPBX支持了多种驻留热键功能,用户可以通过热键功能来驻留呼叫或者重新被激活驻留的呼叫。在开源平台Asterisk(#72)或者FreeSWITCH(*5900)都有相应的设置,用户可以根据配置文件来实现电话驻留或重接被驻留的呼叫,另外,IPPBX用户也可以对驻留的空间进行管理,根据配置的不同,驻留空间可以支持很多个slot。还有,电话驻留的语音提示音也可以实现自定义功能,这样就可以方便地支持系统用户的操作。最后,电话驻留时长也可以通过配置文件来进行调整。FreePBX支持了电话驻留的界面配置,也支持了多种配置选项,用户可以参考其功能配置:

    16、Call Pickup

      Call Pickup, 我们称之为组内代答或者呼叫代答功能。一般情况下,如果是企业客户用户的话,每个部门的员工都有各自的分机。如果有人呼叫分机1,分机1如果没有应答的话,分机2看到分机1用户分机没有人应答,分机2用户可以通过热键来替正在振铃的分机1代接此呼叫。一般情况下,如果系统用户想替其他分机代接的话,这些分机必须在一个工作组或者根据业务类型分配的部门,同一组内用户可以互相代接其他用户的呼叫。

      组内代接的具体处理流程需要经过大概以上几个步骤。假设,Alice呼叫Bob,Bob没有应答此呼叫。和Bob同组的Bill想为Bob代接此呼叫。为了代接此呼叫,Bill首先需要对Bob发送订阅消息,通过订阅消息获取到Dialog消息内容。然后,根据获取的dialog消息内容,对Alice发送INVITE请求消息,替换Bob。Alice收到INVITE请求以后,然后对Bob分机发送一个CANCEL取消的消息,通知Bob分机停止振铃。这里读者要注意,对于F11和F12相关的顺序和200 OK(F10)它们之间是不确定的。

      在以上图例中的F7流程中,Replaces头中使用了一个新的参数“early-only”,这个参数可以防止接受一个Bob可能已经接受的INVITE请求。如果Bill已经准备从Bob那里代接此呼叫,无论Bill是否应答呼叫,参数“early-only”就将不会出现在F7的流程中。另外,读者需要注意一下Bob和Bill之间的订阅会话创建的时间问题。实际上,这个订阅会话可能已经存在于Alice呼叫Bob之前。这里的图例是为了表达方便,而显示在F3,Alice呼叫之后发生,实际上,Bob和Bill的订阅可能已经发生在Alice呼叫之前。

      另外提醒读者,根据RFC5359的描述,这里可能是拼写错误,把Bill说成了Carol。以上流程图中没有Carol。

      Also note that the subscription between Bob and Carol could have been

      established prior to Alice's call.

      关于"early-only”的规范定义,用户可以参考RFC3891,此规范完整介绍了Replaces和其参数的使用方式,以及如何检查INVITE重用。现在,我们结合具体的SIP消息,配合每一个处理流程来一步步说明组内代接:

      首先,Alice对Bob发送INVITE请求,要求和Bob进行通话(F1):

      接下来,Bob对Alice发送180 Ringing,Bob分机振铃(F2)。

      这时,因为Bob分机振铃,无人接听电话,Bill打算为Bob代接呼叫,Bill对Bob发送订阅消息来获取呼叫的dialog身份确认消息(F3):

      Bob收到Bill订阅消息,然后回复200 OK(F4):

      紧接着,Bob对Bill发送NOTIFY消息,包括了订阅消息的内容和Alice的相关消息信息(F5):

      Bill回复Bob收到了订阅的dialog消息内容(F6),准备对Alice发送INVITE请求。

      Bill对Alice发送INVITE请求,替换Bob,使用了early-only(F7):

      Replaces: 12345600@atlanta.example.com

      ;from-tag=314578;to-tag=1234567;early-only

      Alice收到Bill的INVITE请求,检查匹配Replaces头中的dialog,确认以后,接受了这个来自于Bill的INVITE,然后对Bill发送200 OK(F8):

      Alice接受了Bill的INVITE以后,Alice还要对正在振铃的Bob的分机发送一个CANCEL取消的回复,通知Bob分机停止振铃(F9):

      Bob收到CANCEL以后,停止振铃,然后对Alice回复200 OK(F10):

      然后Bob最后对Alice发送487 响应消息,表示对Bob的请求正式结束(F11):

      Alice对Bob发送最后确认消息ACK(F12),他们两个人之间的会话关系正式结束。

      Bill回复Alice发送的200 OK(F8)的ACK确认消息(F13),双方开始RTP语音流的传输,组内代接成功。

      经过一段时间通话后,Alice先挂机,对Bill发送BYE消息(F14):

      然后,Bill对Alice发送最后的200 OK(F15),双方通话结束。

      大部分的企业IPPBX都支持了组内代接功能。顾名思义,如果需要实现组内代接功能的话,用户首先需要创建一个呼叫组,组内成员则可以通过IPPBX的系统热键来代接电话。在asterisk或FreePBX平台上,用户可以按热键*8来实现代接功能。当然,其他平台也可以通过热键设置来接听代接电话。另外,用户可以通过比较灵活和人性化的设计可以支持代接成功或者失败的的语音提示,这样可以让用户获得更好的用户体验。

    17、Automatic Redial

      Automatic Redial,我们称之为自动呼叫重拨功能。简单来说,如果呼叫方呼叫被呼叫方时,对端如果处于忙状态或者其他状态,在一定时间后,呼叫方再次呼叫被呼叫方。具体的实现过程相对比较简单(查看以下图例)。

      假设,Alice呼叫Bob,这时Bob处于忙状态可能正在接听其他电话呼叫,Bob正在通话中。Alice呼叫后,对Bob发送一个订阅消息,对Bob分机状态进行订阅。当Bob处于空闲状态后,Bob对Alice发送一个提醒消息,通知Alice现在Bob分机处于空闲状态,可以对Bob分机进行呼叫。Alice收到这个提醒消息以后,结束对Bob的状态订阅,然后,Alice对Bob发送一个INVITE请求,对Bob进行呼叫,双方互相通话。

      下面,我们根据SIP消息内容,结合每一个具体的处理流程来进一步分析如何实现呼叫重拨功能。

      首先,Alice呼叫Bob,对Bob发送INVITE请求(F1):

      因为Bob此时正处于忙状态,所以,Bob回复Alice 一个486 响应消息(F2):

      Alice回复一个ACK确认消息(F3):

      为了获悉Bob分机的状态,Alice对Bob发送了一个订阅(F4),获取dialog消息内容:

      Bob回复Alice的订阅,回复200 OK(F5):

      Bob对Alice发送NOTIFY消息(F6):

      Alice回复200 OK(F7):

      Bob分机处于空闲状态,再次对Alice发送NOTIFY消息,提醒Alice现在Bob是处于空闲状态(F8)。

      Bob收到来自于Alice的提醒消息,Bob现在处于空闲状态,回复200 OK(F9):

      然后,Alice马上对Bob发送INVITE消息,进行呼叫请求(F10):

      因为Bob已经是空闲状态,所以接听了来自Alice的呼叫。对Alice返回180 振铃消息(F11):

      Alice然后返回200 OK(F12):

      紧接着,Alice对Bob发送一个ACK确认消息(F13),重拨呼叫接通。双方开始语音流传输(F13)。

      Bob再次对Alice发送NOTIFY消息(F14):

      Alice返回200 OK(F15):

      经过以上互相发送NOTIFY和确认消息,Alice已获悉对方状态,不再对Bob进行状态订阅,结束订阅,所以Alice对Bob再次发送订阅通知,结束对Bob的订阅(F16),重置Expire:0。

      Bob回复Alice 200 OK(F17):

      Bob对Alice发送NOTIFY消息(F18),订阅结束。

      最后,Alice对Bob返回200 OK响应消息(F19),订阅结束确认。

      在以上的订阅消息结束处理中,根据RFC6665的规范(4.1.2.3),取消订阅可以通过重设Expire头,设置expire:0 来通知取消订阅。根据规范的说明,成功取消订阅会再次触发一个最终NOTIFY消息(F18)。因此,读者不用对此产生误解。另外,我们这里没有涉及更多订阅的定时器刷新等问题,更多关于订阅的处理,读者可以查阅rfc6665来做进一步的学习。

      关于订阅功能使用方面,笔者建议读者在部署IPPBX和使用SIP终端时要慎用此功能。因为,一旦开启了订阅信息,IPPBX分机之间的订阅消息会生成大量的无效的数据,这样可能影响IPPBX本身的性能和企业内网的网络的稳定性,还有用户消息传送的时延,这样可能导致其他处理流程的错误。比如,如果Bob的终端对Alice发送了NOTIFY消息,通知Alice现在Bob处于空闲状态,Alice可以对其进行呼叫,但是,可能当前的Alice也正在处于其他的状态,可能没有可能再次及时对Bob发起呼叫,因此这个流程就会出现其他的问题。

      一些技术论文对消息导致的系统性能问题和网络优化做了讨论。Ahmadreza Montazerolghaem发表的论文关于重传机制优化的论文可能对读者有所帮助,大家可以参考这个方法来进一步优化自己的网络环境。

      The Overload Reduction in SIP Servers through Exact Regulation of the Retransmission Timer of the Invite Message

      Finnian McKeon 发表的论文中对SIP即时消息互发对网络影响数据流量的影响可以给我们提供一些参考建议,用户可以查阅研究。

      另外,Maria Isabel Pous在论文-SIP-based Applications in UMTS: A Performance Analysis也对SIP消息产生的影响做了深入的分析,读者可以查阅其论文作为参考资料。

    18、Click to Dial

      Click to Dial,我们称之为点击呼叫或页面点击呼叫。浏览器用户以插件的形式或者页面的形式通过浏览器访问点击界面。用户通过点击页面的一个SIP URL链接,页面点击呼叫消息传递给电脑SIP终端,终端配置了呼叫方的SIP URL地址,通过REFER发送SIP终端,然后SIP终端和被呼叫方创建一个会话连接,实现双方呼叫。

      这里的呼叫场景适合于简单的点对点的SIP呼叫场景。如果用户通过媒体服务器实现呼叫的话,处理流程和我们现在讨论的有所不同。具体的呼叫流程如下:

      现在,我们配合具体的SIP消息内容和每一个流程来简单说明点击呼叫的处理过程。

      首先,Bob的PC端SIP对BobSIP电话发送REFER消息(F1),这里的头域中设置了Refer-Sub:false,这表示PC端要求不生成REFER的dialog,仅支持2XX响应消息。关于Refer-Sub的使用方法和参数设置,读者可以查阅RFC4488。

      然后,BobSIP电话终端回复202 接受(F2):

      接下来,Bob对Carol发送INVITE请求消息,表示需要对Carol进行呼叫(F3):

      接下来,Carol对Bob SIP 电话回复180 振铃(F4):

      然后,Alice对Bob SIP电话回复200 OK(F5):

      接下来,Bob的SIP 电话回复ACK确认消息(F6),然后实现双方语音流传输。

      到此为止,整个点击呼叫的流程结束,双方开始电话互通。

      事实上,现在点击呼叫业务功能可以通过很多种方式实现,可以通过浏览器插件的形式实现,也可以通过HTML加脚本语言的形式实现,WebRTC或者邮件终端插件工具来实现。

      特别是基于开源软交换的平台,例如Asterisk/FreePBX或者FreeSWITCH都可以通过接口语言来开发更加灵活的点击呼叫功能。例如,通过脚本语言加Asterisk AMI接口实现的页面点击呼叫功能。用户可以下载以下代码来实现点击呼叫功能。以下是一个PHP的页面点击呼叫实例地址,读者可以参考:

      https://github.com/spbx/Simple-Click2Call-for-Asterisk-PBX/blob/master/click2dial.php

      基于Asterisk的点击呼叫的插件,用户可以参考TBDialOut来实现,开源项目地址:

      http://www.oak-wood.co.uk/tbdialout/

      19、总结讨论

      笔者根据RFC5359,结合一些具体的图例非常系统地讨论了最常用的18个SIP呼叫流程的具体细节。在每一个细节中,笔者增加了一些相关的讨论,帮助读者能够更加全面地了解部署使用时的问题和风险。笔者再次强调,这18个SIP呼叫业务是一个规范流程,不一定是强制执行的标准,特别是涉及到Proxy的内容,读者一定要注意。不同的Proxy或者媒体服务器可能对流程的处理有所不同,读者需要根据自己的部署平台来对照检查。整体而言,通过这18个完整的SIP呼叫业务细节讨论,笔者为提供SIP呼叫业务的技术人员提供了相对比较完整的学习资料和比较权威的参考,希望对大家有所帮助。

      另外,因为笔者水平和资源有限,肯定有很多错误之处,敬请谅解。

      参考资料:

      https://tools.ietf.org/html/rfc4579

      https://www.rfc-editor.org/rfc/rfc5359.txt

      https://tools.ietf.org/html/rfc7088

      https://www.rfc-editor.org/rfc/rfc3515.txt

      https://tools.ietf.org/html/rfc3840

      https://tools.ietf.org/html/rfc3891

      https://www.rfc-editor.org/rfc/rfc6665.txt

      http://file.scirp.org/Html/1-1730003_32286.htm

      https://arrow.dit.ie/cgi/viewcontent.cgi?

      referer=https://www.google.com/&httpsredir=1&article=1005&context=ittscicon

      http://www.cs.columbia.edu/~nahum/papers/sip-multicore-journal.pdf

      https://support.sonus.net/display/SBXDOC51/GRUU+Support

      https://www.tech-invite.com/fo-sip/tinv-fo-sip-service-99.html

      www.freepbx.org.cn

      https://svn.resiprocate.org/viewsvn/resiprocate/main/resip/recon/MOHParkServer/doc/MOHParkServer_User_Documentation.pdf?revision=8937&view=co

      http://ijsetr.com/uploads/463152IJSETR13872-273.pdf

      https://tools.ietf.org/html/rfc3665

      https://tools.ietf.org/html/rfc3265

      https://tools.ietf.org/html/rfc3515

      https://tools.ietf.org/html/rfc4317

    展开全文
  • 上一篇我们介绍了客服IM,这种主要是以文字为载体,实际在在线客服之前,企业客服主要是以电话为主的,也就是呼叫中心呼叫中心通过电话的方式接待客户,处理客户的诉求,与客户的交互方式除了语音交流外,还可以...
  • sip协议呼叫流程详解

    2017-09-06 18:05:00
    1、SIP业务基本知识 1.1 业务介绍会话初始协议(Session Initiation Protocol)是一种信令协议,用于初始、管理和终止网络中...用户代理是呼叫的终端系统元素,而SIP服务器是处理与多个呼叫相关联信令的网络设备。...
  • 上篇记录了呼叫中心框架选型,本文记录外端中继对接鼎信网关的配置以及通过中继->语音网关 一,鼎信MTG1000B媒体网关对接数字中继 一般厂商都会给你佩带转换盒,运营商的中继接口是那种圆口,网关E1是网口,...
  • 如果我们拨打阿里云95187热线服务,拨通之后就可以通过按键进入不同的服务内容,以更好地解决遇到的各种问题——这正是呼叫中心帮助客户为他们的用户所提供的热线呼入呼出功能,云呼叫中心则是呼叫中心的云化版本。...
  • GSCC呼叫中心系统

    千次阅读 2014-06-18 17:28:58
    金鳞通讯呼叫中心系统功能 一、IVR语音导航  1、自由定制、无限级别的欢迎词,可根据业务需要随时更改  2、上/下班、工作日/节假日设置不同IVR语音菜单   3、针对来电号码,制定特殊IVR流程   二、...
  • 呼叫中心的一些知识

    2010-10-10 10:49:32
    呼叫中心的一些概念不太清楚,什么IVR,中继线,坐席,400词语一大堆,听PM讲了一些,还提到有一个公式的,遂在网上查了下。发现这个行业还是有很多东西的,发展的也比较成熟了。概念一大堆,提供该服务的公司也很...
  • 呼叫中心CTI系统

    2020-01-06 15:05:40
    1.什么是CTI? CTI技术是指计算机和通信技术的集成技术,它传统的定义是“计算机电话集成” (Computer Telephony Integration...最初的CTI技术,只是自动地对电话中的信令信息进行识别处理,并通过建立有关的话路连...
  • 其中,955XX号码规划用于服务型企事业单位的客服电话,不需要申请呼叫中心业务经营许可证。950/951/952XX规划用于开展经营性呼叫中心业务。如果申请企业不需要开展经营性呼叫中心业务,建议企业使用400号、800号或...
  • 该CTI呼叫中心平台,包含CTI数据库、业务数据库,CTI数据库的输出端和业务数据库的输出端均与CTI中间件模块的输入端、企业应用模块的输入端相连,CTI中间件模块的输入端、企业应用模块输入端还与OCX控件模块的输出端...
  • 外呼

    2021-08-05 06:47:03
    外呼是现代客户服务中心系统出服务主动发起对客户的呼叫。中文名外呼外文名Outbound出类型预览型、预约型和预测型两种方式ⅣR流程主动出外呼简介编辑语音外呼(Outbound)是指:电话通过电脑自动往外拨打用户...
  •  大概就在10年的时候,三大运营商也都在做视频呼叫中心的业务评估,不过基本属于规范制定中,其中中联通走的比较快,而且他们的视频呼叫中心最终也上线了(但业务一直起不来),也有一些传统的语音呼叫中心厂家在...
  • 第二课 SS7信令系统网络简介

    千次阅读 2013-05-16 10:22:15
    第二课 SS7信令系统网络简介 课程目的: 描述SS7信令网络的基本元素: 信令点(SSP,SCP,STP) 链路和链路集 路由和路由集 计算一条信令链路的信息传输容量 论述SS7信令拓普结构的可靠性 认识ANSI和...
  • 一、GSM信令流程 GSM 系统使用类似OSI协议模型的简化协议,包括物理层(L1)、数据链路层(L2)和应用层(L3)。L1是协议模型最底层,提供物理媒介传输比特流所需的 全部功能。L2保证正确传递消息及识别单个呼叫。...
  • 呼叫中心介绍

    2009-07-22 10:54:00
    一、 什么是呼叫中心 呼叫中心(Call Center,又称客户服务中心)起源于发达国家对服务质量的需求,其主旨是通过电话、传真等形式为客户提供迅速、准确的咨询信息以及业务受理和投诉等服务,通过程控交换机的智能...
  • 转: GSM信令流程

    千次阅读 2011-03-28 15:25:00
    一、GSM信令流程 GSM 系统使用类似OSI协议模型的简化协议,包括物理层(L1)、数据链路层(L2)和应用层(L3)。L1是协议模型最底层,提供物理媒介传输比特流所需的全部功能。L2保证正确传递消息及识别单个呼叫。在...
  • 呼叫中心

    千次阅读 2007-10-29 22:48:00
    360度看呼叫中心 {转} 目前,呼叫中心在我国已有了较大的发展,截止到2000年底,我国总共拥有呼叫中心座席数量近8万,市场总规模达到83.59亿元,而且据国内权威专家预测,此后呼叫中心将以每年30%的速度高速增长,...
  • FreeSwitch笔记

    2022-05-18 14:01:04
    1,信令 用户设备(如话机)与端局交换机之间,以及交换机与交换机之间需要进行通信。这些通信所包含的信息有(但不限于)用户,中继状态,主叫号码,被叫号码,中继路由的选项等。 1.1,信令分类 按功能分类: ...
  • 一、 研究导读 随着近两年IP融合通信、视频通信、统一通信、云计算等...由于传统的呼叫中心语音处理能力受限于硬件板卡,存在依赖硬件、成本高、维护困难、可扩展性不强等特点,特别是对于移动媒体的支持能力也十分...
  • 360度看呼叫中心

    千次阅读 2007-08-11 17:46:00
    目前,呼叫中心在我国已有了较大的发展,截止到2000年底,我国总共拥有呼叫中心座席数量近8万,市场总规模达到83.59亿元,而且据国内权威专家预测,此后呼叫中心将以每年30%的速度高速增长,可谓是形势一片大好。...
  • 设备之间采用集中控制和IP网络组网的方式,利用ISDN PRI信令中继接公网。对在任何地市所需要的任何数量座席,均可提供可靠的数字式或模拟座席或IP座席(本次项目暂时不涉及远端坐席)。 利用AVAYA S8730通信...
  • 摘要 本文对当前3G反向链路呼叫及通话过程中的安全问题做了分析,并分别从MS和BS相互之间的AKA、信令完整性保护和数据保密、入侵检测等进行了讨论。另外,在讨论中适当地将安全与移动性管理相结合,并根据实际应用中...
  • 服务鉴权流程

    2021-01-12 23:13:35
    鉴权流程的目的是由 HSS 向 MME 提供 EPS 鉴权向量(RAND, AU...WCDMA移动核心交换网鉴权流程_信息与通信_工程科技_专业资料。主要讲解目前最...6.1 常规身份验证过程 身份验证就是辨别用户身份...
  •  呼叫中心或者说CTI技术一直以来就是群雄并起、没有标准的领域。在选择呼叫中心时没有技术指标参考,如何比较不同系统间的优劣? 从系统功能上讲, 系统提供商之间的差别不大,如何比较性能上的差别?在使用...

空空如也

空空如也

1 2 3 4 5 ... 15
收藏数 292
精华内容 116
关键字:

呼叫中心 呼入信令流程