您当前的位置是:  首页 > 资讯 > 文章精选 >
 首页 > 资讯 > 文章精选 >

基于SIP协议的媒体录音规范(SIPREC)完整技术概述-1

2019-09-02 11:06:05   作者:james.zhu    来源:Asterisk开源派   评论:0  点击:


  在当前的语音通信环境中,除了用户非常重视呼叫的用户体验,同时对其他第三方的业务要求也有了新的要求。特别是在某些金融领域,法律咨询领域和人力资源领域,双方电话沟通需要有完整的通话录音,这些录音可能会帮助双方对某些歧义进行进一步的佐证。但是,随着呼叫中心,IPPBX部署方式的技术革命,很多呼叫中心,IPPBX已经实现了云部署的方式,以前传统的录音方式基本上很难满足用户的需求,市场份额也正在萎缩。在当前主流的部署方式中,使用SBC对接其他业务应用是大家正在逐步使用的主要的部署方式。关于SBC的背景介绍,我们在以前的文章中做过非常多的关于SBC以及其功能的介绍,笔者也发表过关于开源OpenSIPS电话录音的分享。
  • 如何通过SBC实现公网注册SIP话机演示,实现联通COP对接通话
  • 图解边界会话控制器(SBC)的20个最常用功能
  • SIP系列讲座-边界会话控制器-SBC全面剖析
  • 基于OpenSIPS实现电话录音解决方案探讨
  为了进一步完善SIP呼叫录音的讨论,今天,笔者在以前的录音分享技术讨论的基础上,进一步讨论一些和SIP电话呼叫中的一些非常细节的说明和其相关的行业规范,通过规范和解决方案的示例讨论,读者获得更多关于SIP呼叫录音的技术策略和部署方式。
  更多技术分享,关注SIP技术学习
  笔者这里主要讨论的内容包括:录音解决方案背景介绍,关于SIPREC的技术细节说明(Session Recording Protocol),相关技术架构讨论,基于SIP的媒体录音场景规范(SIPREC)以及数据规范的讨论,SBC对SIPREC的支持和以及其他问题讨论。
  1、录音解决方案背景介绍
  呼叫中心或IPPBX是帮助企业用户和客户主要沟通的工具。根据一家美国公司对市场的调查中,在最近几年,语音仍然是企业用户和客户互动的首先方式。
  以下部分图片来自于互联网
  在呼叫中心或者语音使用比较高的行业中,服务行业是一个需求非常旺盛的行业,客服中心是非常关键的部门。为了保证其服务和其他业务那个在一种可控的环境下进行,双方的录音是最好的凭证。另外,语音呼叫结合电话录音也是服务行业的一个必然的趋势,以下是美国行业调查数据:
  资料来源:https://www.telemessage.com/voice-call-recording-latest-market-and-compliancetrends-infographic/
  当然,录音也不仅仅局限于客服的一种需求,其他行业也存在巨大的市场。以下示例说明了各种环境下对录音的需求:
  但是,随着呼叫中心或客服中心技术的不断发展,很多呼叫中心和客服中心的技术也发生了巨大的变化,从很早的本地部署方式逐渐升级为基于云的部署方式,客服或坐席人员也出现了分布式的部署方式。因此,随着呼叫中心或客服中心技术和管理方式的变化导致了录音解决方案的变化。我们知道,传统的PSTN的录音或者IP录音是通过高阻三通方式或镜像录音实现呼叫录音,但是,这些部署很难满足对现代云部署技术的支撑,它们也满足不了非常细节的业务功能。因此,传统的录音设备或者本地录音方式面临着很大的挑战。
  随着呼叫中心或客服系统朝云平台的迁移,基于云平台的录音解决方案也逐渐形成了自己的市场。同时,录音解决方案可以非常方便地和人工智能的接口实现无缝对接支持。因此,基于云的呼叫中心配合云录音方案将更加普及。
  在基于云部署的呼叫中心的使用场景中,绝大部分的呼叫中心使用了基于SIP协议的解决方案。目前,基于SIP协议的技术架构中,基于SIP协议对媒体录音的规范是SBC,软交换,媒体服务器部署时需要支持的协议规范(SIPREC)。一些比较主流的SBC厂家,媒体服务器都已经支持了SIPREC-基于SIP的媒体录音协议。这看来也是一个市场发展的必然趋势。为了更快了解这些相关的技术和规范,在本文章中,笔者在接下来的章节中会逐步介绍SIPREC相关的技术规范,它们包括:
  RFC5341-基于SIP的媒体录音使用场景规范:
  Use Cases and Requirements for SIP-Based Media Recording (SIPREC)
  RFC7245-SIP媒体录音技术架构:
  An Architecture for Media Recording Using the Session Initiation Protocol
  RFC 7865-SIP录音时的metadata:
  Session Initiation Protocol (SIP) Recording Metadata
  RFC7866-SIP录音的呼叫流程:
  Session Initiation Protocol (SIP) Recording Call Flows
  因为篇幅的关系,我们不可能在一篇文章中涵盖所有的技术细节,除了简略介绍以上规范以外,笔者还要结合目前主流的SBC应用场景和其他的问题进行多方面的讨论来完善目前关于基于SIP媒体录音解决方案的讨论。
  2、SIPREC背景知识
  根据前面章节的介绍,因为某些商业环境的要求,系统可能需要对呼叫会话进行录音。SIPREC是基于SIP协议对媒体录音的场景规范(RFC6341)。其全名为:
  Use Cases and Requirements for SIP-Based Media Recording (SIPREC)
  在整个SIPREC的规范中,包括了SRC和SRS两个核心部分。它们之间的通信会话包括了录音内容本身和一些相关的metadata,通过录音内容和metadata的关联,系统就可以实现对SIP呼叫的媒体录音的完成流程处理。因为对SIP呼叫的录音,涉及了很多的业务模式和其他相关的技术,因此,其规范也相对比较宽泛,不可能严格限定到非常细节的技术范畴。读者一定要清楚,一些其他业务要求和技术要素不在此官方的说明范围之内。这些要素包括:
  • 关于法律强制录音的规定流程不在此规范讨论范围之内
  • 关于媒体注入,编码转换,安全问题不在本规范讨论范围之内
  • 通过网络镜像方式录音Passive 录音方式不在本规范讨论范围之内
  此规范仅讨论active 录音方式,和如何通过SRC对SRS发送媒体流的处理场景。以下是一个关于SIPREC和SIP呼叫流程的图例说明:
  在以上的图例中,用户端可以是SIP终端, 呼叫中心,或者IPPBX,通过一个B2BUA实现对外网呼叫。这里的SRC是SBC,SRC客户端再发送通信会话包括SIPREC metadata和RTP到第三方的SIPREC服务器端。在呼叫环境中,涉及了各种环境场景和控制流程,具体细节和各种录音场景我们在第四章节中做具体说明。
  3、技术架构讨论-RFC7245
  在上面的章节中,我们介绍了关于SIPREC的一些背景知识和规范的局限性。SIPREC的工作方式是基于SIP媒体会话录音的技术架构来实现的。因此,我们有必要针对媒体录音技术架构进行讨论包括。关于SIP媒体会话录音的技术架构,RFC7245对此有明确的规范说明。在RFC7245中,官方协议中首先定义了多个关键词,然后说明了技术架构中具体的结构,创建录音会话和记录metadata数据。
  在RFC7245中所规定的几个关键词包括:
  1. 支持录音意识用户代理- Recording-aware User Agent (UA):此UA可以意识到其拓展已经关联到了通信会话(CS)。其拓展参数可以通知其UA录音会话已启动或表示其状态,可以启动,暂停和完全停止等消息。
  2. 无录音意识用户代理-Recording-unaware User Agent (UA):此UA意识不到其拓展已经关联到了通信会话(CS)。无录音意识代理将通过其他手段通知其UA录音会话已启动或表示其状态,可以启动,暂停和完全停止等消息。
  3. Recording Metadata:描述SRS服务器端需要的相关录音身份确认数据,包括通信会话和dialog状态信息等。一般情况下,这些metadata会和复制媒体录音一起发送到SRS服务器端。
  4. Replicated Media:由SRC客户端创建的媒体流复制数据流,发送到SRS服务器端。它可能包括语音和视频数据。
  其他几个概念在下面的章节中会加以说明,包括:Session Recording Server,Session Recording Client,Communication Session (CS)和Recording Session (RS)。
  对于介于SRS和SRC之间的录音会话来说,它仍然借助了SIP dialogs和SDP的正常处理流程来进行处理。但是,它又对SIP拓展了其他的头域值(例如,headers,tags等)来满足媒体录音的需求。在此规范中规定,复制的媒体数据需要通过实时方式发送到SRS服务器端,不能使用SRC缓存方式发送。
  从媒体录音的技术架构来说,SRC是一个逻辑构件,它可以介于多个应用部署的环境中。它本身必须是一个B2BUA的结构,这样SRC才能对RTP媒体,对SIP信令进行控制,最重要的是可以对会话进行管理。关于B2BUA的概念,读者可以查阅笔者的历史文档来进一步学习,这里不再做过多解释。另外,特别提醒读者,SIP proxy不能作为SRC来工作,因为proxy不能touch到媒体语音流。这就是为什么opensips如果需要支持SIPREC时,opensips必须加载B2BUA模块,作为一个B2BUA来使用。
  当然,SIP endpoints也可以作为一个SRC,这种情况下,终端会对SRS发送复制的媒体。如果终端需要对SRS服务器端发送录音时,它可以发送一个INVITE请求,创建会话后发送,SRC对SRS发送媒体录音。同样,如果SRS需要启动录音时,它可以对SRC终端发送INVITE会话,然后开始录音。
  录音会话可以由SRS或者SRC创建。SRC创建的录音会话的目的是对SRS发送媒体录音流数据。如果有SRC创建录音会话时,它主要执行以下几个步骤:
  1. SRC查询定位SRS的URL地址,按照解析方式来解析SRS地址。
  2. 发送INVITE请求,创建一个dialog,然后发送到SRS。
  3. 在INVITE请求中包括一个录音指示,表示会话已经创建,希望发送媒体录音。
  4. 如果马上要发送复制媒体时,在SDP中包含一个“a=sendonly”,表示马上发送媒体录音。如果还没有准备好发送媒体的话,包含一个“a=inactive”。
  5. 复制的媒体流被录音然后发送到SRS服务器端。
  同样,SRS也可以对SRC发送请求来启动一个录音会话,它需要执行以下几个流程:
  SRS查询SRC URL地址,通过地址解析后获取SRC地址。
  SRS对SRC发送INVITE请求。
  在SRS发送的INVITE中包括一个媒体录音指示,表示要创建一个录音会话来进行媒体录音。
  确认会话数据内容。在实际环境中,确认消息取决于SRC的策略设置。
  如果马上要发送复制媒体时,在SDP中包含一个“a=sendonly”,表示马上发送媒体录音。如果还没有准备好发送媒体的话,包含一个“a=inactive”。
  如果SRS服务器端不知道哪个媒体会话需要录音的话,SRS服务器端可以执行一个协商机制,它可以先对SRC发送一个无实际意义的INVITE,然后SRC客户端对其发送一个初始的offer。
  在媒体录音进行过程中,SRS或者SRC任意一方可以暂停或者重新启动录音。通过SDP中包含一个inactive来暂停录音,或者通过SDP中包含“recvonly”或“sendonly”重新启动录音。
  通常情况下,在一个简单的会话中,在SRC客户端,RTP媒体流可能包含两个媒体数据流。这些媒体流必须在发送到SRS服务器端之前进行混音。如果没有混音的媒体发送到SRS时,需要同时分开发送两个媒体流的metadata。
  在实际部署环境中,双方媒体可能需要进行媒体转换处理,B2BUA可以执行此功能。如果SRC端不能执行媒体转换处理的话,它需要对SRS发送不同的媒体格式,SRS服务器端需要支持多种媒体格式。
  4、SIPREC使用场景讨论
  • 在SIPREC的规范中,它说明了几个基于SIP的录音使用场景。这些场景都可以支持SIPREC规范RFC6341。在此规范中,一些必要的定义需要再次说明一下:
  • SRS-全称是Session Recording Server,它是一个具体的媒体服务器或媒体采集服务器,是一个用户代理,同时汇总各种媒体流的metadata。SRS典型的部署方式是一个多口可拓展的服务器类型。
  • SRC-全称是Session Recording Client,它是一个SIP用户代理,负责对服务器端发送媒体流数据,它本身是一个逻辑功能单元,可以支持多个物理设备,在实际应用环境中,SRC可以是SIP终端话机,媒体网关或者SBC。SRC同时对SRS服务器发送metadata。
  • Communication Session (CS),通信会话创建于一个SIP或者多个用户代理之间的会话,是一个正在被录音的会话对象。
  • Recording Session (RS):为通信会话(CS)录音目的创建的介于SRS和SRC之间的SIP会话。
  关于SRS,SRC和CS直接的关系,读者可查阅此示例:
  在RFC6341中说明了12个应用场景,每一种场景都包含了具体的描述。
  • 全时录音:对RS对一个CS(参考以下示例),系统对所有呼叫进行录音,典型的应用场景包括呼叫中心,企业客服和金融呼叫流程等。
  • 选择性录音:当CS录音创建后,启动RS录音。如果CS没有启动,系统不会录音。
  • 停止启动录音:当呼叫在CS期间时,可以启动停止RS录音。系统可以通过用户界面按钮或者其他热键启动录音。这里注意,在CS期间,可能会生成一个或者多个RS录音。
  • 持续录音:一个RS可以捕捉一个或多个CS录音。此录音方式通常应用于某些场景中,例如前台总机,转每个特定的分机号码或者呼叫。整个RS需要对多个环节中的终端录音,包括了转接时的静音等。最后,这些录音的metadata可以关联在一起,录音文件可以合并。这里可能涉及了编码协商的流程。
  • 实时录音控制:在RS录音期间,如果有特别业务要求,某些个人隐私或者安全信息不能录音时,实时录音控制方式可以停止对某一段时间内的录音暂停/关闭,需要时重新开启。信用卡信息输入就是一个比较常见的例子,如果用户需要对系统服务人员报信用卡或者其他身份信息时就要暂停录音。
  • IVR入口录音:对系统IVR进行录音,包括其metadata等。
  • 企业移动端录音:系统对企业办公人员进行录音。这些员工可能经常不在办公室环境中上班,他们经常使用移动端和企业呼叫中心或者通信系统进行沟通,这些员工的呼叫需要被录音。比较常见的场景包括销售人员,保险销售等。
  • 分布式录音或集中式录音:一些企业,银行,连锁机构等办公系统的电话呼叫需要通过部署在不同地区或者集中管理的电话系统进行呼叫。系统需要对呼叫进行录音,并且对其每个RS的metadata进行存储。这样方便管理每一个呼叫和其相关人分机。
  • 复杂呼叫流程:复杂呼叫流程是一个比较抽象的说法,没有特别具体的定义,此场景比较灵活,宽泛。简单来说,一个呼叫进入到系统用户,客户电话可能首先被前台人员接听,然后转到具体的坐席人员。如果坐席人员不能回答客户问题的话,坐席人员可能需要再呼叫坐席主管,主管来接听客户的电话。坐席人员在此呼叫流程中需要首先执行呼叫停靠,然后再呼叫他/她的主管,主管接听客户电话以后,坐席挂机。整个流程称之为复杂呼叫流程,所有的呼叫都需要录音,并且SRC需要对SRS发送所有的metadata数据。
  • 高可靠性和持续录音:根据用户的需求,此应用场景需要SRS服务器端一直保持工作状态,失效还原功能。所有创建的呼叫都能录音。此场景要求SRS服务器端必须持续工作,无呼叫录音服务丢失。
  • 对通道和多会话录音:一些应用场景要求媒体录音是一个或者多个文件,可以实现同步存储或者回放等功能。语音识别引擎可以对其明显特定的媒体执行ASR/TTS处理。一些多渠道融合的呼叫中心或者IPPBX环境中可能需要对视频,IM,其他数据文件进行存储。为了节省存储空间,一些应用场景中可能需要仅多某些终端在某个特定时间段进行录音。
  • 实时媒体处理:此场景在当前的呼叫中心或客服系统中实时质检环境中使用比较广泛。SRS服务器端必须有能力支持语音识别引擎工具,这些侦查工具可以对某一段媒体进行ASR和以及相关语义识别,情绪分析等工具处理,如果发现其录音中带有比较敏感的词,或者客服人员态度语气有问题,应用系统的主管人员可以及时处理。通过SIPREC的metadata可以非常方便快捷地查询到客服人员的电话座席。
  当然,实现以上基于SIPREC录音解决方案的话,此规范有31个要求。笔者这里不立场31个具体的要求,读者可以查阅RFC6341。
  另外,除了31个要求以外,此规范讨论了关于录音存储和metadata的安全问题,读者也可以查阅RFC6341来进一步学习。
  户签权认证处理和存储空间回放文件的处理。这些机制都和其他的安全机制是一致的。用户可以查阅其他协议的安全处理机制来执行。
  参考资料:
  https://tools.ietf.org/html/rfc6341
  https://tools.ietf.org/html/rfc7245
  https://www.miarec.com/
  www.freepbx.org.cn
  https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-sip-recording.pdf
  第二部分陆续发布。
   
   
  SIPlab@知识星球学习SIP语音相关技术
  asterisk@知识星球免费获取关于Asterisk的完整知识资料
  关注微信公众号:asterisk-cn,获得有价值的Asterisk行业分享
  Asterisk freepbx,FreeSBC技术文档: www.freepbx.org.cn
  融合通信商业解决方案,协同解决方案首选产品:www.hiastar.com
  Asterisk/FreePBX中国合作伙伴,官方qq技术分享群(3000人):589995817
【免责声明】本文仅代表作者本人观点,与CTI论坛无关。CTI论坛对文中陈述、观点判断保持中立,不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。请读者仅作参考,并请自行承担全部责任。

专题

CTI论坛会员企业