灌音php技巧_SIP呼叫录音流程示例说明RFC8068呼叫转接呼叫重启若何录音

呼叫录音的主要性是不言而喻的，在未涌现语音呼叫和语音识别技能结合的场景之前，语音录音的运用仅仅限于人工监听或者人工质检，标准化程度比较低，针对海量数据的处理能力也极其有限。
由于语音识别技能和大数据的赋能，对语音数据的深加工也是用户的一定哀求，通过语音识别引擎和大数据云打算的支持，可以进一步提高海量数据的处理效率，增加用户体验实时性。
但是，一样平常企业办公通信或者在呼叫中央场景中，呼叫流程存在多种交互办法，呼叫流程变革很大，有时一个呼叫会话可能涉及到不同接听工具。

如果在未理解呼叫流程的条件下，大略剖析一个语音文件很难全面反响实际接听业务完全流程，终极可能导致数据剖析结果和业务的脱节问题，形成了各种信息孤岛，造成了资源摧残浪费蹂躏和决策失落控。
因此，读者如果要节制管理全体呼叫中央业务录音场景，须要全面理解呼叫录音或者会话录音的呼叫流程。

在针对基于SIP协议会话录音的呼叫流程技能细节方面，RFC8068供应了一个相比拟较全面的详讲授明，读者可以根据此规范来进一步理解SIP呼叫录音的流程。
在以下的针对RFC8068的详解中，我们将针对RFC8068结合SIP呼叫录音规范SIPREC进行解释和谈论。
以下谈论内容中包括关于SIPREC规范，以及基于SIPREC规范支持的几种会话录音流程场景解释。

SIPREC录音做事器-宇高

1-关于RFC8068规范和SIPREC规范背景解释

关于RFC8068的根本来自于SIP呼叫录音规范-SIPREC，关于SIPREC协议规范的谈论涉及了SIPREC客户端（SRC）和做事器端（SRS）。
笔者已经对此规范做了完全的谈论，并且对其它呼叫录音办法存在的问题做了谈论，用户可以先理解关于SRC和SRS流程进一步得到基本的关于SIPREC知识。
一些重点行业用户和比较大型的SBC（比如奥科SBC，Ribbon的SBC都支持了SIPREC，宇高的SIPREC）运用处景中，SIPREC是一个必要支持功能。
因此，我们须要对这些干系技能协议做全面理解。

基于SIP协议的媒体录音规范（SIPREC）完全技能概述

关于SIP语音网络中呼叫录音的三种录音办法的支配谈论，SIPREC是呼叫录音核心规范

2-关于RFC8068

本协议紧张罗列从SRC和SRS的会话流程以及双方提取的metadata数据。
通过metadata才能真正绑定会话关系。
在本文档中，笔者会利用很多简称格式来表达特定的观点，这些都是metadata的描述。
关于metadata的详细属性，我们这里不会做详细解释，用户可以参考RFC7856规范进行理解，在RFC7856中对每个metadata属性有非常明确的描述。
首先我们先容呼叫流程和metadata收发的流程。

在以上呼叫流程中，流程忽略了SIP信令的细节（例如ACK，re-INVITE或BYEs），我们这里仅理解从F1到Fn-1的flow，紧张解释metadata的概要数据收发，包括以下四个紧张呼叫大类是否混音的解释。

3-呼叫录音中SRC未混音发送流程

在未混音发送流程中，包括了四种呼叫示例（在以下的示例中，由于流程中的xml交互数据太多，因此呼叫流程交互数据忽略。
），这四种示例包括：

3.1-基本呼叫流程未混音。
呼叫方和被呼叫方各自发送自己的语音和视频，都基于同样的通信会话（Communication Session（RFC7865））。
在此示例中，SRC是一个基于呼叫方和被呼叫方之间的B2BUA实体，SRC没有对媒体流进行混音，直接发送到了SRS做事器端。

3.2-呼叫保持和重启。
一个在Alice和Bob创建的呼叫，创建了RS进行录音。
Bob将Alice的呼叫置于呼叫保持状态，然后重新启动呼叫，这个流程是刚才利用的同一RS的一个部分。
读者这里要把稳，recv和send来指示呼叫参与者是否连续进行媒体流交互。
这个xml数据包括了hold数据和resume的数据。

3.3-呼叫转接示例（基于re-INVITE或者Refer转接办法）。
Alice和Bob创建呼叫，然后通过SRC作为一个B2BUA发送xml数据。
然后Alice发起一个呼叫转接，转接完成后，SRC对SRS发送一个呼叫参与者修正的xml数据。
在这个示例中，Alice退出转接，终极Bob和Carol创建了通话，SRC开始对Bob和Carol进行录音。
这里有两种转接处理办法，一种是在同样的会话中进行转接，利用re-INVITE进行转接处理。
在这种转接中，Alice退出会话，同时Carol加入到会话中。

<?xml version="1.0" encoding="UTF-8"?> <recording xmlns='urn:ietf:params:xml:ns:recording:1'> <datamode>partial</datamode> <session session_id="hVpd7YQgRW2nD22h7q60JQ=="> <sipSessionID>3363127f0d084c10876dddd4f8e5eeb9 ;remote=2272bb7e70fe41dba0025ae9a26d54cf</sipSessionID> </session> <participant participant_id="Atnm1ZRnOC6Pm5MApkrDzQ=="> <nameID aor="sip:carol@example.com"> <name xml:lang="it">Carol</name> </nameID> </participant> <participantsessionassoc participant_id="Atnm1ZRnOC6Pm5MApkrDzQ==" session_id="hVpd7YQgRW2nD22h7q60JQ=="> // Carol加入这个会话 <associate-time>2013-12-16T23:41:07Z</associate-time> </participantsessionassoc> <participantsessionassoc participant_id="srfBElmCRp2QB23b7Mpk0w==" session_id="hVpd7YQgRW2nD22h7q60JQ=="> // Alice指示退出会话 <disassociate-time>2013-12-16T23:41:07Z</disassociate-time> </participantsessionassoc> <participantstreamassoc participant_id="zSfPoSvdSDCmU3A3TRDxAw=="> // Bob <send>8zc6e0lYTlWIINA6GR+3ag==</send> <send>EiXGlc+4TruqqoDaNE76ag==</send> <recv>60JAJm9UTvik0Ltlih/Gzw==</recv> <recv>AcR5FUd3Edi8cACQJy/3JQ==</recv> </participantstreamassoc> <participantstreamassoc participant_id="Atnm1ZRnOC6Pm5MApkrDzQ=="> // Carol <send>60JAJm9UTvik0Ltlih/Gzw==</send> <send>AcR5FUd3Edi8cACQJy/3JQ==</send> <recv>8zc6e0lYTlWIINA6GR+3ag==</recv> <recv>EiXGlc+4TruqqoDaNE76ag==</recv> <associate-time>2013-12-16T23:42:07Z</associate-time> </participantstreamassoc> </recording>

其余一种是利用一个新的会话进行转接处理，利用Refer转接办法进行处理。
在SRC创建的同一组CS中，利用一个新的会话来处理呼叫转接。
在这种处理办法中，SRC首先发一个option数据，关照Alice退出就的CS会话。
然后，SRC可以通过INVITE携带一个新的session，表示不再利用旧的会话。

<?xml version="1.0" encoding="UTF-8"?> <recording xmlns='urn:ietf:params:xml:ns:recording:1'> <datamode>partial</datamode> <session session_id="hVpd7YQgRW2nD22h7q60JQ=="> // 指示和这个会话干系的都将关闭停滞。
停滞韶光如下 <stop-time>2010-12-16T23:41:07Z</stop-time> </session> <participantsessionassoc participant_id="srfBElmCRp2QB23b7Mpk0w==" session_id="hVpd7YQgRW2nD22h7q60JQ=="> <disassociate-time>2010-12-16T23:41:07Z</disassociate-time> </participantsessionassoc> <participantsessionassoc participant_id="zSfPoSvdSDCmU3A3TRDxAw==" session_id="hVpd7YQgRW2nD22h7q60JQ=="> <disassociate-time>2010-12-16T23:41:07Z</disassociate-time> </participantsessionassoc> </recording>

然后由于通过Refer办法处理的转接，以是SRC在转接后发送一个指示修正的xml数据。
在这个示例中，我们假设SRC利用了同样的CS连续进行通话流程。
xml中的sipSessionID节点数据表示Bob和Carol在UUID的配对中。

<?xml version="1.0" encoding="UTF-8"?> <recording xmlns='urn:ietf:params:xml:ns:recording:1'> <datamode>complete</datamode> <session session_id="bfLZ+NTFEeCNxQTuRyQBmw=="> // 本地和远端配对，利用新的会话处理 <sipSessionID>3363127f0d084c10876dddd4f8e5eeb9 ;remote=2272bb7e70fe41dba0025ae9a26d54cf </sipSessionID> <start-time>2010-12-16T23:41:07Z</start-time> </session> <participant participant_id="zSfPoSvdSDCmU3A3TRDxAw=="> <nameID aor="sip:Bob@biloxy.com"/> </participant> <participant participant_id="Atnm1ZRnOC6Pm5MApkrDzQ=="> <nameID aor="sip:carol@example.com"/> </participant> <stream stream_id="60JAJm9UTvik0Ltlih/Gzw==" session_id="bfLZ+NTFEeCNxQTuRyQBmw=="> <label>96</label> </stream>

3.4-呼叫挂机。
当呼叫参与方的任何一方如果挂机的话，SRC会对SRS发送指示数据表示双方挂机。

<?xml version="1.0" encoding="UTF-8"?> <recording xmlns='urn:ietf:params:xml:ns:recording:1'> <datamode>partial</datamode> <session session_id="hVpd7YQgRW2nD22h7q60JQ=="> // 停滞韶光 <stop-time>2010-12-16T23:41:07Z</stop-time> </session> <participantsessionassoc participant_id="srfBElmCRp2QB23b7Mpk0w==" session_id="hVpd7YQgRW2nD22h7q60JQ=="> // 停滞关联 <disassociate-time>2010-12-16T23:41:07Z</disassociate-time> </participantsessionassoc> <participantsessionassoc participant_id="zSfPoSvdSDCmU3A3TRDxAw==" session_id="hVpd7YQgRW2nD22h7q60JQ=="> // 停滞关联 <disassociate-time>2010-12-16T23:41:07Z</disassociate-time> </participantsessionassoc> </recording>

4-呼叫录音中SRC已混音发送流程

在混音模式发送流程中，发出流程中的SRC是会议模式的一个部分，SRC可以是focus或者会议参与方。
这里的SRS做事器端可以是一个SIP用户代理或者MEDIACTRL架构的部分实体组件。
由于挂机信息和前面的未混音处理办法一样，以是这里的所有挂机数据都未列出。

4.1-基本呼叫流程带混音发送场景。
这里的呼叫参与方是Alice和Bob, 他们都是在一个CS中的部分组件实体。
在这种呼叫模式下，每个呼叫参与方会进入到会议模式环境中，也便是常日说的MCU（Multipoint Control Unit (MCU)）中。
在此会议模式中，每个呼叫参与方的媒体流都会被其他呼叫或者会议参与方吸收。
以下是通过SRC发起的INVITE带混音数据，发送到SRS做事器端。
这里要把稳的是，xml中包括了两种Session-IDs. 一种是关联介于Alice和会议Focus之间的SIP会话，其余一种Session-ID是关联介于Bob和会议focus之间的SIP会话。
其余，由于Alice和Bob都是呼入到了会议模式，因此，他们的Session-ID都不相同。

<?xml version="1.0" encoding="UTF-8"?> <recording xmlns='urn:ietf:params:xml:ns:recording:1'> <datamode>complete</datamode> <session session_id="hVpd7YQgRW2nD22h7q60JQ=="> <sipSessionID>fa3b60f27e91441e84c55a9a0095f075 ;remote=a358d2b81a444a8c8fb05950cef331e7</sipSessionID> <sipSessionID>ca718e1430474b5485a53aa5d0bea45e ;remote=68caf509b9284b7ea45f84a049febf0a</sipSessionID> <start-time>2010-12-16T23:41:07Z</start-time> </session> <participant participant_id="srfBElmCRp2QB23b7Mpk0w=="> <nameID aor="sip:alice@atlanta.com"> <name xml:lang="it">Alice</name> </nameID> </participant> <participant participant_id="zSfPoSvdSDCmU3A3TRDxAw=="> <nameID aor="sip:bob@biloxy.com"> <name xml:lang="it">Bob</name> </nameID> </participant> <stream stream_id="i1Pz3to5hGk8fuXl+PbwCw==" session_id="hVpd7YQgRW2nD22h7q60JQ=="> <label>96</label> </stream> // 各自的会议关联session-ID <participantsessionassoc participant_id="srfBElmCRp2QB23b7Mpk0w==" session_id="hVpd7YQgRW2nD22h7q60JQ=="> <associate-time>2010-12-16T23:41:07Z</associate-time> </participantsessionassoc> <participantsessionassoc participant_id="zSfPoSvdSDCmU3A3TRDxAw==" session_id="hVpd7YQgRW2nD22h7q60JQ=="> <associate-time>2010-12-16T23:41:07Z</associate-time> </participantsessionassoc> <participantstreamassoc participant_id="srfBElmCRp2QB23b7Mpk0w=="> <send>i1Pz3to5hGk8fuXl+PbwCw==</send> <recv>i1Pz3to5hGk8fuXl+PbwCw==</recv> </participantstreamassoc> <participantstreamassoc participant_id="zSfPoSvdSDCmU3A3TRDxAw=="> <send>i1Pz3to5hGk8fuXl+PbwCw==</send> <recv>i1Pz3to5hGk8fuXl+PbwCw==</recv> </participantstreamassoc> </recording>

4.2-带SRC混音的呼叫保持和重启流程。
这个示例和前面先容的紧张流程都是相同的。
在呼叫保存中，呼叫启动时，SRC就开始混音，双方的xml数据分别是发送和吸收。
如果双方开启了重新通话后，SRC对SRS发送INVITE更新后，双方的xml数据会更新为都能同时发送和吸收。

//呼叫保持阶段<?xml version="1.0" encoding="UTF-8"?> <recording xmlns='urn:ietf:params:xml:ns:recording:1'> <datamode>partial</datamode> <stream stream_id="i1Pz3to5hGk8fuXl+PbwCw==" session_id="hVpd7YQgRW2nD22h7q60JQ=="> <label>96</label> </stream> <participantstreamassoc participant_id="srfBElmCRp2QB23b7Mpk0w=="> <recv>i1Pz3to5hGk8fuXl+PbwCw==</recv> </participantstreamassoc> <participantstreamassoc participant_id="zSfPoSvdSDCmU3A3TRDxAw=="> <send>i1Pz3to5hGk8fuXl+PbwCw==</send> </participantstreamassoc> </recording> // 呼叫重新启动后 <?xml version="1.0" encoding="UTF-8"?> <recording xmlns='urn:ietf:params:xml:ns:recording:1'> <datamode>partial</datamode> <stream stream_id="i1Pz3to5hGk8fuXl+PbwCw==" session_id="hVpd7YQgRW2nD22h7q60JQ=="> <label>96</label> </stream> // 双方可以同时send和recv <participantstreamassoc participant_id="srfBElmCRp2QB23b7Mpk0w=="> <send>i1Pz3to5hGk8fuXl+PbwCw==</send> <recv>i1Pz3to5hGk8fuXl+PbwCw==</recv> </participantstreamassoc> <participantstreamassoc participant_id="zSfPoSvdSDCmU3A3TRDxAw=="> <send>i1Pz3to5hGk8fuXl+PbwCw==</send> <recv>i1Pz3to5hGk8fuXl+PbwCw==</recv> </participantstreamassoc> </recording>

4.3-在会话中加入或者丢弃一个会议参与方。
读者可能都知道，在一样平常电话的会议模式中，会议期间可能仍旧有新的用户进入，也可能有其他会议参与方退出会议。
这些处理刚才同样也可以运用在会话录音中，无论是新进入者还是退出的用户，都须要记录其会话数据。
这种环境中，SRC可以是会议的focus或者会议参与者。
这里假设，Alice和Bob已经在会议中，第三方Carol加入到会议中，然后SRC对其他人发送xml数据指示有新的会议职员加入。

<?xml version="1.0" encoding="UTF-8"?> <recording xmlns='urn:ietf:params:xml:ns:recording:1'> <datamode>partial</datamode> <session session_id="hVpd7YQgRW2nD22h7q60JQ=="> <sipSessionID>fa3b60f27e91441e84c55a9a0095f075 ;remote=a358d2b81a444a8c8fb05950cef331e7</sipSessionID> <sipSessionID>ca718e1430474b5485a53aa5d0bea45e ;remote=68caf509b9284b7ea45f84a049febf0a</sipSessionID> <sipSessionID>497c0f13929643b4a16858e2a3885edc ;remote=0e8a82bedda74f57be4a4a4da54167c4</sipSessionID> </session> // carol 加入会议 <participant participant_id="Atnm1ZRnOC6Pm5MApkrDzQ=="> <nameID aor="sip:carol@example.com"> <name xml:lang="it">Carol</name> // 一段韶光后，Alice退出会议 <?xml version="1.0" encoding="UTF-8"?> <recording xmlns='urn:ietf:params:xml:ns:recording:1'> <datamode>partial</datamode> <session session_id="hVpd7YQgRW2nD22h7q60JQ=="> <sipSessionID>ca718e1430474b5485a53aa5d0bea45e ;remote=68caf509b9284b7ea45f84a049febf0a</sipSessionID> <sipSessionID>497c0f13929643b4a16858e2a3885edc ;remote=0e8a82bedda74f57be4a4a4da54167c4</sipSessionID> </session> <participantsessionassoc participant_id="srfBElmCRp2QB23b7Mpk0w==" session_id="hVpd7YQgRW2nD22h7q60JQ=="> // 退出会议 <disassociate-time>2010-12-16T23:41:07Z</disassociate-time> </participantsessionassoc> </recording>

4.4-挂机处理流程。
挂机流程大概和前面的挂机流程类似。
首先关照做事器端停滞会话录音，在xml数据中发送会话停滞录音韶光和挂机韶光。

5-塔式呼叫掌握模式。
分外行业中利用的一种录音模式，一些股票交易所或者拍卖行利用这种录音办法进行录音。
不像现在基于大数据云支配的电话系统的处理办法，在传统的分布式交流机支配场景中，存储空间和系统是非常昂贵的，也不能很灵巧地实现扩展。
因此，为了实现最优的存储设置，推举利用的办法是将来自于不同的呼叫终真个多并发呼叫进行混音。
每个呼叫作为一个CS，将这些呼叫汇聚成一个单个的RS。
这样就可以实现将多个CS汇聚为一个RS，可以从SRC客户端发送到SRS做事器端。

这种录音模式环境中，存在三种录音的可能性：

1）CS1和CS2都利用同样的focus混音，这个被利用的focus是在每个CS中是一个SRC。

2）CS1 SRC是一个focus，其他的会议参与方CS都是会议模式的SRC。
混音依赖于CS1来处理。

3）会议中，CS1和CS2都是SRC。

在RFC8068-3.5章节中，规范作者仅谈论了第一种模式和XML数据，其他可能性未做进一步描述。
由于是一种分外场景，而且无太多细节数据，这里不再谈论。
读者如果有兴趣的话，可以参考RFC8068连续学习。

总结

笔者针对RFC8068规范为读者解读了关于SIP协议会话录音的呼叫呼叫转接，呼叫保持重启等场景如何录音。
这些会话录音包括了未混音和混音状态下的数据收发的处理。
紧张针对会话数据XML数据中的数据变动进行理解读。

在这些交互数据中，会话-ID，参与方数据ID，挂机韶光都有非常丰富的关联性。
和传统录音办法比较，通过这些数据的支持可以更好和SIP信令数据进行深度绑定，终极实现用户数据同步。

但是，在本规范中仅谈论了几种呼叫用例，其实在实际用户场景中，特殊是基于终端-SBC（SRC-SRS）-IPPBX的用户场景中，还有更多呼叫业务须要处理，而且这些业务和IPPBX端绑定比较紧密，终极流程实现仍旧须要大家进一步去优化。

得到关于SIP/IP语音干系技能分享-加入“SIP实验室技能分享群“-QQ号-589995817

参考资料：

www.sip.org.cn

http://www.voicecodes.com/index.php/siprec/

www.dinstar.cn

https://www.rfc-editor.org/rfc/rfc8068.html

https://www.rfc-editor.org/rfc/rfc7245.html

https://www.rfc-editor.org/rfc/rfc7865