VoIP语音处理在发送和吸收方向上的软件框图如下图1和2：
图1：发送方向处理流程框图
图2：吸收方向处理流程框图
在发送方向，从codec芯片采集到语音PCM数据后如有须要首先做重采样（SRC），然后做前处理（反应肃清/AEC，噪声抑制/ANS，增益掌握/AGC，俗称3A算法）。后面便是做静音检测（VAD），如是语音就编码（ENC），得到码流并通过RTP/UDP发送给对方。如是静音，就天生静音包(SID) 也通过RTP/UDP发送给对方。在弱网情形下为了提高语音质量，就须要前向纠错（FEC）、重传等手段把相应的包发给对方。一些场景下须要把tone音（比如 DTMF tone）发送给对方，先要做tone音检测（tone detection），然后按照SIP协议协商好的办法把tone音发送给对方。在发送RTP包的同时，也须要发送RTCP包来监控RTP包的收发情形等。
在吸收方向，先收到对方发来的RTP/RTCP包。对付RTP包，如是正常包或者重传包，直接放进jitter buffer(后面简称JB)，这些包有可能被JB收下，也有可能被JB丢弃（比如包来的太迟或者重复包等）。如是FEC包，先做FEC解码，再把解码后的RTP包放进JB。同样也有可能被JB收下或者丢弃。从JB里取出的如是语音包，就须要做解码（DEC），根据网络状况还可能要做丢包补偿（PLC）、加速、减速、领悟等处理。如取出的是静音包（SID），则须要产生舒适噪声（CNG）。如取出的是RFC2833包，就要产生相应的tone音（tone generation）。处理好后还要经由噪声抑制（ANS）/增益掌握（AGC）等处理，有可能的话还须要做重采样（SRC）。末了把PCM数据送给codec芯片播放出去。
下面看详细的知识点：
1，语音的采集和播放：紧张是从codec芯片采集到语音得到PCM数据和把PCM数据发送给codec芯片播放出来，不同的OS下有不同的方法。曾经写过干系的文章，详细见《音频的采集和播放》。
2，重采样（SRC）：便是把PCM的采样率从一种变成另一种。在音频处理中常常碰着采样率不一样的情形，须要做重采样。曾经写过怎么对开源的重采样算法做评估，从而觉定用哪个，详细见《音频开源代码中重采样算法的评估与选择》。也写过基于sinc方法的重采样的事理和实现，详细见《基于sinc的音频重采样（一）：事理》和《基于sinc的音频重采样（二）：实现》。
3，前后处理的3A算法：包括AEC/ANS/AGC等，他们是担保音质的关键成分之一。AEC是反应肃清，曾写过AEC的基本事理和调试履历（算下来我前前后后共四次调试过AEC），详细见《音频处理之反应肃清及调试履历》。ANS是噪声抑制，2021年我花了不少韶光在ANS上，从学习事理到看懂代码以及自己写算法代码。也写了三个算法的系列，分别是webRTC里的ANS和基于MCRA-OMLSA的ANS以及基于稠浊模型的ANS，详细见《webRTC中语音降噪模块ANS细节详解(一)》、《 webRTC中语音降噪模块ANS细节详解(二)》 、《webRTC中语音降噪模块ANS细节详解(三)》、《 webRTC中语音降噪模块ANS细节详解(四) 和 《基于MCRA-OMLSA的语音降噪(一)：事理 》 、《基于MCRA-OMLSA的语音降噪(二)：实现》、《基于MCRA-OMLSA的语音降噪(三)：实现(续)》 以及《语音降噪论文“A Hybrid Approach for Speech Enhancement Using MoG Model and Neural Network Phoneme Classifier”的研读 》、《基于稠浊模型的语音降噪实践 》、《基于稠浊模型的语音降噪效果提升 》。AGC是自动增益掌握，是掌握语音旗子暗记的增益在预设的合理区间之内，避免忽大忽小。目前这一块还没有干系的文章。
4，静音检测（VAD）和舒适噪声天生（CNG）：VAD会根据预先设定的threshold判断是语音还是静音。如果是语音就要去做编码，如果是静音则不须要编码，仅仅是周期性的（比如200毫秒）发送一个带能量大小的SID包给对方，对方收到这个包后去做CNG产生舒适噪声，让通话者觉得更舒畅些。用VAD/CNG紧张有两个好处：一是节省了带宽，常日语音通话中一方只占50%旁边的讲话韶光，别的韶光处于静音状态。在静音时发送SID包，SID包比正常语音包小不少，发的频率也低好多，这样就节省了带宽。二是降功耗，在静音期间不须要编解码了，常日编解码的运算load比VAD/CNG高，这样就降落了功耗。目前还没有这方面的文章。
5，编解码（ENC/DEC）：常用的codec有ITU-T的G系列（g.711/g.722/g.726/g.729等）、3GPP的AMR-WB/AMR-NB/EVS以及互联网厂商提出的iLBC/OPUS等。曾在文章《音频的编解码及其优化方法和履历 》中写过基于reference code去优化CPU load。
6，前向纠错（FEC）和重传：在弱网情形下须要担保音质，就得有一些补救方法，FEC和重传便是个中两种。FEC是在发送端编码天生冗余包，在吸收端解码从而天生那些丧失落的包。重传是把对方须要的包发给对方。曾在文章《语音通信中提高音质的方法 》讲过这两种方法，当然也讲了其他的提高音质的方法。
7，RTP/RTCP/UDP：这三个都是网络协议，RTP是网络传输协议，RTCP是网络传输掌握协议，UDP是数据报协议。在文章《语音传输之RTP/RTCP/UDP及软件实现关键点》里讲了它们的软件实现关键点。
8，tone音：一些场景下会用到tone音，比如DTMF tone，包括tone音检测（tone detection）和tone音天生（tone generation）。文章《谈谈语音通信中的各种tone 》详细的讲了tone音以及发送给对方的三种办法。
9，jitter buffer（JB）：把从网络收到的RTP包放进JB里缓一下，同时把乱序的包排好序等，有利于播放的流畅。文章《音频传输之Jitter Buffer设计与实现 》写了我曾经设计过的一个JB。
10，netEQ：是webRTC里提出的观点，把JB、解码和解码后的PCM处理（加减速播放、丢包补偿（PLC）等）放在一起形成一个模块。也便是吸收方框图中画虚线的部分。我曾经写过一个系列详细先容了netEQ，大家对这个系列的评价还是不错的，详细见《webRTC中音频干系的netEQ（一）：概述 》 《webRTC中音频干系的netEQ（二）：数据构造 》 《webRTC中音频干系的netEQ（三）：存取包和延时打算 》《 webRTC中音频干系的netEQ（四）：掌握命令决策 》和 《webRTC中音频干系的netEQ（五）：DSP处理 》。
以上便是VoIP语音处理中的紧张知识点。须要解释的是一个VoIP语音处理办理方案中以上模块并不全是必须的，而是根据需求选用的。当然有些是必须的，比如编解码。上面的框图只是把涉及到的知识点列出来，框图画的可能不是十分的准确。有些模块（比如提高音质的一些方法）我没用过，就没画出来。写这篇文章的目的只有一个，便是让大家知道VoIP语音处理的流程和个中有哪些知识点。
