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

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

2019-09-03 13:58:31   作者: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服务器端。在呼叫环境中,涉及了各种环境场景和控制流程,具体细节和各种录音场景我们在第四章节中做具体说明。
  剧透时间:可能是东半球网关销售量最大的厂家即将震撼发布一系列融合通信产品,完成融合通信产品生态链部局。
  www.dinstar.cn
  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发送请求来启动一个录音会话,它需要执行以下几个流程:
  1. SRS查询SRC URL地址,通过地址解析后获取SRC地址。
  2. SRS对SRC发送INVITE请求。
  3. 在SRS发送的INVITE中包括一个媒体录音指示,表示要创建一个录音会话来进行媒体录音。
  4. 确认会话数据内容。在实际环境中,确认消息取决于SRC的策略设置。
  5. 如果马上要发送复制媒体时,在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个应用场景,每一种场景都包含了具体的描述。
  1. 全时录音:对RS对一个CS(参考以下示例),系统对所有呼叫进行录音,典型的应用场景包括呼叫中心,企业客服和金融呼叫流程等。
  2. 选择性录音:当CS录音创建后,启动RS录音。如果CS没有启动,系统不会录音。
  3. 停止启动录音:当呼叫在CS期间时,可以启动停止RS录音。系统可以通过用户界面按钮或者其他热键启动录音。这里注意,在CS期间,可能会生成一个或者多个RS录音。
  4. 持续录音:一个RS可以捕捉一个或多个CS录音。此录音方式通常应用于某些场景中,例如前台总机,转每个特定的分机号码或者呼叫。整个RS需要对多个环节中的终端录音,包括了转接时的静音等。最后,这些录音的metadata可以关联在一起,录音文件可以合并。这里可能涉及了编码协商的流程。
  
  5.实时录音控制:在RS录音期间,如果有特别业务要求,某些个人隐私或者安全信息不能录音时,实时录音控制方式可以停止对某一段时间内的录音暂停/关闭,需要时重新开启。信用卡信息输入就是一个比较常见的例子,如果用户需要对系统服务人员报信用卡或者其他身份信息时就要暂停录音。
  6.IVR入口录音:对系统IVR进行录音,包括其metadata等。
  7.企业移动端录音:系统对企业办公人员进行录音。这些员工可能经常不在办公室环境中上班,他们经常使用移动端和企业呼叫中心或者通信系统进行沟通,这些员工的呼叫需要被录音。比较常见的场景包括销售人员,保险销售等。
  8.分布式录音或集中式录音:一些企业,银行,连锁机构等办公系统的电话呼叫需要通过部署在不同地区或者集中管理的电话系统进行呼叫。系统需要对呼叫进行录音,并且对其每个RS的metadata进行存储。这样方便管理每一个呼叫和其相关人分机。
  9.复杂呼叫流程:复杂呼叫流程是一个比较抽象的说法,没有特别具体的定义,此场景比较灵活,宽泛。简单来说,一个呼叫进入到系统用户,客户电话可能首先被前台人员接听,然后转到具体的坐席人员。如果坐席人员不能回答客户问题的话,坐席人员可能需要再呼叫坐席主管,主管来接听客户的电话。坐席人员在此呼叫流程中需要首先执行呼叫停靠,然后再呼叫他/她的主管,主管接听客户电话以后,坐席挂机。整个流程称之为复杂呼叫流程,所有的呼叫都需要录音,并且SRC需要对SRS发送所有的metadata数据。
  10.高可靠性和持续录音:根据用户的需求,此应用场景需要SRS服务器端一直保持工作状态,失效还原功能。所有创建的呼叫都能录音。此场景要求SRS服务器端必须持续工作,无呼叫录音服务丢失。
  11.对通道和多会话录音:一些应用场景要求媒体录音是一个或者多个文件,可以实现同步存储或者回放等功能。语音识别引擎可以对其明显特定的媒体执行ASR/TTS处理。一些多渠道融合的呼叫中心或者IPPBX环境中可能需要对视频,IM,其他数据文件进行存储。为了节省存储空间,一些应用场景中可能需要仅多某些终端在某个特定时间段进行录音。
  12.实时媒体处理:此场景在当前的呼叫中心或客服系统中实时质检环境中使用比较广泛。SRS服务器端必须有能力支持语音识别引擎工具,这些侦查工具可以对某一段媒体进行ASR和以及相关语义识别,情绪分析等工具处理,如果发现其录音中带有比较敏感的词,或者客服人员态度语气有问题,应用系统的主管人员可以及时处理。通过SIPREC的metadata可以非常方便快捷地查询到客服人员的电话座席。以下示例是宁卫开发的基于ASR的实时质系统。系统用户可以根据自己的业务需求添加一些敏感词。如果客服人员和客户之间的沟通有危险词汇或者不礼貌用语,系统直接提示其状态(红色标识)。此对话过程可通过短信,邮箱或者其他第三方接口实时推送给坐席主管现在的状态告警。

  当然,实现以上基于SIPREC录音解决方案的话,此规范有31个要求。笔者这里不立场31个具体的要求,读者可以查阅RFC6341。
  另外,除了31个要求以外,此规范讨论了关于录音存储和metadata的安全问题,读者也可以查阅RFC6341来进一步学习。
  5、SIP录音时的metadata
  SIP录音时的metadata涉及到了录音会话的相关参数的绑定。这些数据通过SRC发送到SRS服务器端。RFC7865主要针对通信会话的录音文件进行了规范,其核心包括SRS服务器端的metadata数据模式和数据录音格式规范描述。在RFC7865中涵盖了几个主要的定义,它们分别是:
  • Metedata model:以UML为基础的抽象metadata表达方式
  • Metedada class:模式中的每一块为一个class
  • Attributes:class的属性
  • Linkages:模式中每个class之间的相关性,每个linkage表示class之间的一个逻辑相关性
  以下示例表示了各种class自己的相互关系和其相关性,读者可以查阅RFC7865进一步了解这个数据模式。另外,读者也可以学习UML或者软件工程相关的文章了解UML背景知识。
  在metadata的数据格式方面,涉及了从SRC到SRS的发送格式。通过XML的格式来表示metadata的内容。
  录音文件的metadata有分为不同的class。每个class有着自己不同的属性参数设置和相关性设置。这些class包括:
  1. Recording session:录音会话类别,在XML中使用“recording”,它依赖于SIP和SDP所关联的属性。
  2. Commnucation session group: 关联一组通信会话,例如坐席通过几次电话转接停靠以后的一系列相关呼叫。它在XML中使用“group”表示。
  3. Commnucation session:通信会话表示其通信属性和metadata,其属性包括:session_id,sipSession_ID, group-ref,start-time,stop-time。
  4. CS-RS Association :表示通信会话和录音会话的关联性,属性包括关联时间,断开时间和session_id。
  5. Participant:录音参与者进入到录音会话的双方,包括终端描述,Participant_id等。
  6. Participant-CS Association:参与者和通信会话的关联性绑定关系。关联性描述参与者和通信会话关联时间,session_id,断开时间等属性。
  7. Media Stream:描述SRC发送到SRS服务器端的媒体属性,包括label,stream_id和session_id等属性设置。
  8. Participant-Stream Association:描述参与者和媒体之间的绑定关系和时间段,参与者可能是发送方,接收方或者两者角色都支持。
  9. Syntax of XML Elements for Date and Time:定义XML文件中日期和时间段规范,包括关联时间,断开时间,启动录音时间,停止录音时间等相关的时间规范。此时间标准需要遵从RFC3339的格式规范。时间戳必须使用一个大写的T或者Z。
  10. Format of Unique ID:描述了生成UUID的步骤和解析规范。UUID解析必须遵从RFC4648。
  11. Metadata Version Indicator:version指示帮助SRC和SRS确认使用的XML文件版本是否一致。目前规定的是双方都使用版本1。如果版本不一致的话,可能导致传输失败,目前的规范中没有支持任何的协商机制。
  因为本身metadata的数据结构比较复杂,另外,如果SRS处理大量数据的时候需要消耗很多的计算资源和带宽。因此,SRS可以明确通知SRC发送一个关于录音的metadata的概要或者部分相关内容,而不需要发送一个完整的XML文件。具体的语法格式如下:
  1. SRS internal error
  2.  
  完整的metadata格式包含了大量的XML数据,文件相对比较大,这里不再介绍,读者可以查阅RFC7865-8的完整SIP 录音metadata 示例。
  6、SIP会话录音协议
  前面的讨论中,笔者已经介绍了录音技术架构,使用场景和metadata。在这一章节,我们重点介绍一下会话录音协议-Session Recording Protocol。此协议主要规定了SR之间的实时媒体发送和metadata发生的逻辑流程,包括SIP使用, SDP使用和RTP的处理规范。再次说明,此协议仅支持active 录音模式,不支持passive 录音模式(镜像录音)。在此协议中,主要规范了几个方面的处理流程:
  基本操作流程规定,SIP处理流程定义,SDP处理流程定义。RTP处理流程定义,metadata处理,持续录音处理和安全处理机制处理。
  基本操作流程规定中介绍了关于传输媒体流,传输metadata,接收录音指示和提供录音优先设置。在传输媒体流的模式讨论中,规范了两种传输方式。一种传输方式是SRC以B2BUA的方式传输,一种是以SRC以endpoint的方式来传输。SRC以endpoint的模式传输媒体:
  以下是SRC以B2BUA的模式传输,电话会议就是此工作方式的表现形式。
  除了传输媒体流录音以外,metadata也需要实时随着媒体的发送传输到SRS服务器端。SRC负责传输metadata,SRC也可以通过起始的CS的INVITE请求提供初始媒体流录音的metadata数据消息,后续的metadata可以通过媒体事件的UPDATE(查阅rfc3311)来传递,也可以通过SRC发送到re-INVITE发送。传输metadata通常是逐步递增的,消息内容可能会不断增加,文件也可能非常大。因此,SRC发可以根据自己的策略重新发送metadata。meatadata通过INVITE或者UPDATE的消息体来传输。一些媒体流的属性需要通过RS的SDP传输。在SRC和SRS传输过程中,可能出现其他的故障,丢失了metedata。SRS可以通过一个失败消息对SRC要求重新传输metadata,SRS和SRC可以保持数据的同步。以下是一个通过SIP UPDATE重新传输的流程实例:
  在CS传输过程中,SRC负责对所有的参与者提供录音指示消息内容。一些支持录音状态意识到UA会收到一个SDP带“a=record”消息,表示SRC开始发送录音,同样UA会在SDP中设定一个“a=recordpref”表示录音的优先偏好设置。如果UA暂时因为各种原因不能录音,则可忽略这个优先偏好设置。以下示例介绍了一个UA A作为SRC呼叫 终端B的流程,终端A呼叫并且开始录音,UA B则看到对方录音,UA B回复了一个off状态,不想对呼叫进行录音。最后,UA A重新发送消息,停止呼叫录音。
  录音会话中同样涉及了SIP处理,它是一个SIP 会话的拓展,很多的消息会包含在SRS和SRC中。当SRC或者SRS收到一个SIP会话时,它不是录音会话的话,处理流程完全取决于SRC或者SRS自己。SRC通过SIP INVITE请求对SRS发起一个录音会话,无论是SRS还是SRC都是通过SIP的To或From头来定义。SRC必须在Contact URL的功能标签添加一个“+sip.src”来表示其拓展。在通过路由代理时,呼叫方可以添加一个标签“siprec”表示录音会话需要路由到SRC或者SRS服务器端。SRC收到一个新的INVITE呼叫时,它必须通过INVITE中的两个功能标签才能确认是一个录音会话呼叫,一个是“+sip.srs”和“siprec”。同样的原则,当SRS服务器端收到一个新的INVITE以后,它必须确认是否包含两个标签“+sip.src”和“siprec”才能确认是一个SRC发送到录音请求。有意识录音UA(recording-aware UA)可以通过标签字段的形式支持是否录音,重新启动录音或者暂停录音。一些网关或者终端通过界面来实现对DTMF控制也是一种录音方式。
  除了对会话的控制以外,媒体录音也需要metadata传输等机制,因此需要涉及到SDP的控制处理策略。在SDP处理模式上,SRC/SRS都遵守SDP offer/answer模式,具体规范查阅(RFC3264),笔者也曾经做过介绍,读者可对照学习。在SRC和SRS媒体发送过程中,SRC客户端本身不希望从SRS服务器端收到媒体流数据,它仅是一个发送端,因此对SRC在SDP的设置中a字段设置为“a=sendonly”。SRC对每个发送到SRS服务器端的媒体录音参与者必须都提供一个标识“a=label”,以此来确认每个媒体流的metadata。具体标识的规范读者查阅RFC4574。以下示例是一个标识的示例,包括了具体的内容介绍,这里的 是可选的。
  媒体录音也需要处理,因为各种原因,SRC可能增加或者删除一些录音会话。删除增加会话需要根据RFC3264的规范来处理。RS暂停会话需要在SDP offer中增加一个a字段“a=inactive”。
  在通信会话中,目前的机制对通信会话录音是播放一个语音提示音或者播放一个广播,提醒需要UA需要录音。在SDP中增加了一个“record”属性参数。通过SDP的a字段“a=record”来处理各种环境的变化设置,其具体的语法如下:
  当SRC收到一个录音优先级/偏好时,SRC通过设定a字段的属性来控制是否录音“a=record”,off或者on。
  前面我们讨论的是SRC的SDP控制,在SRS端的处理流程其实也具有相同的处理流程和逻辑,可能有一些正好是一个相反的设置机制。SRS通常情况下只是从SRC端接收RTP流,因此其SDP的a字段设置为“a=recvonly”。示例如下:
  在SRS的SDP处理中,对有录音意识UA,录音指示和优先级/偏好设置和SRC基本类似,读者可参考SRC配置说明,这里不再做过多介绍。
  RTP处理也是录音会话协议中非常重要的一个部分。其规范推荐了RTP/RTCP在SIPREC中的使用机制,保证SRS,SRC和有录音意识终端那个通过这些推荐的处理机制来正常工作。在RTP的处理机制中,推荐了RTCP在SIPREC的两种功能(数据分发反馈处理机制,包括持续的传输层身份确认(SSRC)),RTP属性支持能力,SSRC,CSRC,SDES,Keepalive等机制处理方式。这些处理方式保证了语音传输,加密,稳定性处理,活动侦测,带宽优化,异步传输等处理机制,用户在实际本身时可灵活调整其参数来达到最佳的RTP处理解决方案。
  SRC可以扮演多种角色,它可能是一个UA也可能是一个B2BUA代理。因此,在RTP的处理上就会导致不同的处理方式,也可以灵活运用在不同的录音场景中。SRC可以作为一个RTP流的转移功能模块,实现直接转发RTP,或者可以作为一个RTP媒体的编码转换模块,它可以针对不同的媒体格式进行转码处理。SRC也可以作为一个媒体混音单元,读者可查阅RFC3550对混音单元的规范做进一步学习。
  SRC也可以作为一个RTP的endpoint,这些我们在前面做过介绍,这里不再讨论。
  在录音会话中,metadata属性参数包含在了SDP描述中,其他数据包含在了application/rs-metadata。"recording-session"值包含了SRS需要处理的metadata。在SRC的示例如下:
  SRS发送到UPDATE消息如下:
  在录音会话时,规范做对持续录音的场景做了一些规范推荐。在持续录音时,关于SRC和SRS的处理机制可以按照前面的流程处理。一些特殊情况,可能需要用户针对特殊环境做进一步处理,例如NAT环境中端口活动检测,如果是支持ICE的终端可能可以解决这个问题,如果是不支持ICE的终端,用户需要按照RFC6263来处理SRC和SRS的端口绑定。
  在录音会话环境中,规范推荐了一些相关的安全问题的讨论,比如,SRC/SRS必须都支持加密,必须考虑RTP加密,metadata的安全处理,用户签权认证处理和存储空间回放文件的处理。这些机制都和其他的安全机制是一致的。用户可以查阅其他协议的安全处理机制来执行。
  7、SBC对SIPREC的支持
  在前面的章节中,笔者介绍了SIPREC的使用背景,录音协议,录音流程,技术架构和metadata等比较底层的技术概念。在实际应用场景中,SBC对SIPREC支持是非常典型的应用案例。目前,国外一些主流的SBC厂家产品都已经支持了SIPREC(包括FreeSBC即将发布SIPREC高级功能),这样就为SIP呼叫媒体录音部署提供了可靠的技术环境。SBC支持SIPREC主要的应用场景包括:
  SBC企业本地部署支持SIPREC: 企业IPPBX或者呼叫中心和SBC/SRC连接,SRC通过SIPREC和SRS连接。录音服务器可以通过终端以各种访问形式进行访问,运营商和SBC进行对接,然后呼叫到用户终端。
  多租户企业IPPBX录音解决方案: 托管型的IPPBX或呼叫中心可以通过远端终端呼叫SBC/SRC,然后通过SBC呼叫托管中心的PBX,IPPBX呼叫语音商线路出局。SRC同时对SRS发送RTP媒体流和metadata数据。
  高可靠性SIPREC录音解决方案:SIPREC同样规范了高可靠性的处理方式,SRS必须实现媒体流存储无丢失机制。所以,SRS可以通过主从处理的方式同步媒体流和metadata数据。
  同样,SRS的负载也是非常重要的技术要素。一些SBC做了均衡负载的处理,例如奥科SBC支持了类似的功能:
  以上应用场景是比较典型的部署方式,SIPREC规范相对比较新,厂家仍然需要不断更新支持一些SIPREC规范的高级功能。
  8、其他问题讨论
  前面我们讨论了关于SIPREC录音的官方协议和应用场景。SIPREC相当于镜像录音来说,其部署方式更符合目前SIP大型应用环境,云平台的处理方式。但是,因为SIPREC是基于其他规范基础发展而来的,因此其他规范的使用限制了一些SRC/SRS工作环境。另外,一些终端产品还没有支持SIPREC,只有大部分SBC产品支持了SIPREC,SRS服务器端的功能仍然处于发展阶段,一些商业产品支持了基本的SIPREC功能,一些高级功能仍然受到了限制。大家比较关心的问题包括:
  • SRC客户端发送到metadata文件大小影响传输结果和SRS的负载,SRC可能需要支持更多的传输策略来解决类似的问题。
  • SRC是否支持混音,如果SBC测来处理这些需求的话,会导致SBC负载非常高,直接影响SBC的性能。
  • SRS服务器端的高可靠性设置问题也是需要用户面对的问题。可能一些厂家的SBC很好解决了此问题,但是需要真正实际验证。
  • SRC是否很好支持了metadata的拓展支持决定了和SIP会话处理。如果很好支持很多拓展字段,可能会帮助SRS服务器端更加准确管理metedata和通信会话处理。另外,SIP会话的处理也需要终端和其他设备能够很好配合,保证其具有良好的兼容性,从而保证metadata的准确性。
  •  
  •   
  • 随着融合通信的发展,用户沟通增加了更多媒体支持,包括IM消息,共享文件和视频格式。如何更好处理这些文件和其metadata也是一个非常大的挑战。
  9、总结
  在本文章中,笔者首先介绍了SIPREC的规范和其相关的细节。基于SIP协议的媒体录音应用已经非常广泛,从银行到企业客服,保险业务推广,法律机构和政府要求都需要电话录音。这些录音文件需要和其具体的通信会话相关人员进行正确绑定才能符合真正的客户要求。然后,笔者针对SIPREC和其他相关协议做了完整介绍,例如12个使用场景,录音协议,metadata规范,呼叫流程规范。然后,笔者针对目前SRC使用最广泛的SBC做了介绍,通过SBC的集成,企业客户可以实现SIPREC录音解决方案。最后,笔者讨论了目前使用SIPREC可能面对的挑战和一些相关问题,为读者提供了相对比较完整的专业建议。当然,随着技术的不断发展,SIPREC的功能会更加完善,云平台的使用越来越多,SBC部署的广大,支持的终端也可能越来越多,SIPREC的需求也会逐渐增加。
  以上就是笔者针对基于SIP协议的媒体录音规范和应用方面的概述。这里没有过度讨论各种录音方式的特点。这些讨论通常根据用户的需求来决定,所以笔者认为没有必要做过多讨论。另外,关于SIPREC的场景讨论也可能遗漏了其他方面的要素,望读者谅解。总之,此文章已经基本涵盖了基于SIP协议做媒体录音的大部分内容和规范,也完整叙述了其相关规范所有的技术要点,对于读者快速了解这些技术有着非常大的帮助。
  参考资料:
  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论坛对文中陈述、观点判断保持中立,不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。请读者仅作参考,并请自行承担全部责任。

相关热词搜索: SIP协议 SIPREC

上一篇:小议联络中心的AI发展方向-1

下一篇:最后一页

专题

CTI论坛会员企业