8.媒体

SIP信令, 帮我们建立会话, 但我们建立通话的目的是”通话”

要通过采样, 量化, 编码将我们声音的模块量变成数字信号,

以便在数字线路上传输, 我们把这些数字信号成为媒体(Media)

1.媒体与媒体处理

常见媒体有音频, 视频, 图像, 文本等,

1） 音频编码

    从模拟信号变成数字信号的过程成为模数转换(AD)

        经过采样,量化,编码三个过程

        编码:

            按照一定的规则将采样的信号用一组二进制或其他进制的数表示

        经过编码的数据在网络上传输,到达对端后

    通过解码,变成原始信号

        再经过数模转换(DA),转换为人们能感知的信号

    编码, 解码都是成对出现,所以习惯是称为编解码Codec,为了方便,简称编码



    PCM编码

        PCM的两种压缩方式A律和u律,分别为PCMA和PCMU

        经过PCM编码仍然占用比较高的带宽,又出现了一些更高级的压缩算法,目的都是降低带宽,提高传输效率

        CPM采样频率为8000Hz,随着人们对声音质量要求的提高,各种高清(HD)编码纷纷涌现,如G.722等

    打包

        在网络上传输语音,要将编码后的语音数据打包,通常打包时间间隔为20ms,

        如果采样频率是8000Hz,1s传输1000ms/20ms= 50个包,

        每个包携带8000/50=160个采样数据,

        在PCMU和PCMA中一个采样数据占1字节,因此一个20ms的PCM包数据净荷是160字节

    Freeswitch支持的语音编码

        G.711: PCM

        G.722: 高清语音

        G.726

        G.723.1

        G.729: 低带宽8kbit/s

        GSM: 13.3kbit/s

        iLBC: 抗丢包,绝大多数情况下都是最佳选择

        iSAC

        CODEC2: 2550bit/s, 最省带宽

        Speex

        SILK: skype,抗丢包

        CELT: 低延迟高清编码, 48kbit/s,达到CD音质

        OPUS: 综合CELT和SILK之长

    编码格式

        名词@xx@yyi,h代表Hz采样频率;i代表ptime,打包间隔;xx,yy代表实际数值

        如speex@16000h@20i

            16000Hz,20ms的Speex编码

    查看Freeswitch支持的编码类型

        show codec

    音频编码最基本的两个技术参数就是采样频率和打包周期

        采样频率越高,声音越清晰,通常8000Hz就够了

        打包周期越短,延迟越小,传输开销就越大,需要更大带宽,最常见的是20ms

2） 媒体工作机理和相关配置

    工作原理

        以PCM音频数据为例, 打包周期是20ms,音频包得到160字节的数据,

        加上12字节的RTP包头,就成了一个RTP包,RTP包头包含音频编码类型,时间戳等,便于对方解码回放及同步等

        RTP使用与SIP不同的UDP端口传送,在实际传输前需要通过SIP信令与对方协商往哪个端口传送

        A: 你好,我的RTP端口是10000

        B: 收到,我的RTP端口是20000

        A音频打包,通过RTP发送到B20000端口

        B音频打包,通过RTP发送到A10000端口

    相关配置

        SIP Profile支持的媒体列表是在vars.xml配置

            <X-PRE-PROCESS cmd="set" data="global_codec_prefs=G722,PCMU,PCMA,GSM"/>

            <X-PRE-PROCESS cmd="set" data="outbound_codec_prefs=PCMU,PCMA,GSM"/>

        如果学习过程中需要频繁实验,不妨直接修改Profile配置文件

            <param name="inbound-codc-prefs" value="$${global_codec_prefs}"/>

            改为

            <param name="inbound-codc-prefs" value="PCMU,PCMA,G729,iLBC,H264,VP8"/>

            然后在控制台执行命令

                sofia profile internal rescan

2.媒体协商

不同的SIP终端进行通信时需要先与支持的编码进行"协商",以便双方能互相理解,对方发来的数据

1） 协商过程

    SIP客户端呼入时使用iLBC编码,打包周期是60ms,而服务器端提供G722,PCMU等,但都是20ms

    Freeswitch与客户端提供的编码逐一比较,发现没有交集,协商失败,返回488,INCOMPATIBLE_DESTINATION(目的地不兼容)

    Offer/Answer机制

        请求发起方提供自己支持的媒体编码列表,被请求方比较自己支持的媒体列表最终选择一种应答

    Set Codec sofia/internal/1006@192.168.7.6 PCMA/8000 20ms 160 samples 64000

        本次协商成功,把Channel编码设为PCMA编码

2） SDP及其在编码协商中的作用

    SDP(会话描述协议),说明Freeswitch使用PCMA编码,RTP端口号是28512

    协商完毕

        双方都知道对方的IP地址和端口号,就可以互发音频RTP包了

3） 协商时机与策略

    协商时机

        早协商

            当呼叫到达一个SIP Profile时,某端口收到INVITE请求而未到达路由阶段,就先行协商

        晚协商

            等到路由阶段,到达拨号计划时再行协商,默认使用晚协商

        设置为早协商,修改SIP Profile

            <param name="inbound-late-negotiation" value="false"/>

            如果启动inbound-zrtp-passthru,则隐含设置inbound-late-negotiation为true

    协商策略

        generous(普通),默认策略

            客户端提供PCMA,G729,而Freeswitch支持列表优先顺序为G729,PCMU,PCMA

            当Freeswitch收到请求时优先考虑客户端感受,优先使用PCMA

        greedy(贪婪)

            Freeswitch优先考虑自己的编码,选择G729

        scrooge(吝啬)

            除了具有greedy特征外,还强制使用自己的采样率

3.其他媒体相关的问题

1） RTP和RTCP

    在完成SIP及SDP协商后,真正的语音数据在RTP协议中传送,

        即双方在前面的SDP协商中已经获得对方的IP,端口号,以及支持的媒体类型.

    RTP,实时传输协议

        说明了在互联网上传递音频和视频的标准数据包格式,一开始被设计为一个多播协议,后来被用于单播应用

        建立在UDP协议上,常用于流媒体,视频会议和一键通

    RTCP,实时传输控制协议

        RTP使用偶数UDP端口

        RTCP使用下一个相邻的技术端口,RTCP本身不传输数据,但会和RTP协作将多媒体数据打包并发送出去

        RTCP主要功能是为RTP提供的服务的质量提供反馈信息

            收集统计信息,如传输字节数,丢失分组数,单向延迟等

            网络应用利用RTCP统计信息控制传输的品质,当网络阻塞时,限制流量或改用压缩率高的编码

2） 转码

    如果两条腿分别使用不同的编码,则需要经过一个转码过程,分别转成对方需要的编码

    呼叫双方采用同样的编码,但如果有IVR或录音,放音等中间环节时,也需要转码

    Freeswitch默认的配置不支持自动转码

        A呼叫B

        A只有PCMA, B只支持PCMU

        协商失败

        要使协商成功,只需在internal Profile将下面一行注释

            <param name="inbound-zrtp-passthru" value="true"/>

        查看重启前后该配置的区别

            sofia status profile internal

        由于A提供PCMA,Freeswitch向B发送SDP的时候,把PCMA放在最前面,

        B收到INVITE后,它仅支持PCMU,它通过200 告诉Freeswitch

        接通后, A向Freeswitch发送PCMA编码的RTP媒体流,Freeswitch自动转换为PCMU,并发给B



3） 透传, 媒体绕过与媒体代理

    Freeswitch不支持G729, 只要通话双方都支持G729,仍可以建立通话

    第一种方式是透传

        在不经过转码的情况下,将从乙方收到的媒体流原样转给另一方

    媒体绕过

        真正的媒体流使用点到点传输, 不经过Freeswitch

        Freeswitch正常建立通话,RTP通过点对点直接传输

4） Media Bug

    为了解决监听和录音问题,Freeswitch在媒体流路径上放了一个Media Bug

    相当于水管上的三通

        媒体流不仅在A于B交换,还通过三通连接到C

    录音也是通过这种机制实现

        C相当于录音机

5） 视频

    Freeswitch也支持视频呼叫和会议, 所有的视频流都是透传, Freeswitch不支持视频转码

    必须保证两端都使用相同的视频编码才可以互看

6） 排错

    媒体协商问题

        打电话在Log查找与"Audio Codec Compare"相关行

    也可以使用外部的抓包工具(tcpdump或Wireshark)来抓包分析

    Freeswitch也提供了一个实用工具,uuid_debug_media,可以比较方便的查看是否有媒体流的收发

        uuid_debug_media 68c65988-ddfb-11e6-8d22-0fcaa3ca5f35 read on/off

4.小结

音视频编码, SDP及RTP

Freeswitch对媒体处理的方法, 协商机制

使用late-negotiatioin, disable-transcoding尽量避免转码,节省系统资源

设置BypassMedia, 让媒体不经过Freeswitch直接在两个SIP客户间点对点传输

来源张永光的博客