FreeSwitch 编码协商

https://freeswitch.org/confluence/display/FREESWITCH/Codec+Negotiation

 

摘要

        编码协商可能是一个令人困惑的主题。如果您不熟悉SDP(会话描述协议),那么这就增加了一层额外的神秘。如果你对这个话题感到陌生(或者只是对你所读过的和经历的东西感到困惑),那么希望通过这个简短的介绍,事情会变得更清楚一些。

        首先,我们所说的“编解码协商”是什么意思?我们正在讨论是:每条腿将选择什么编码(codec)的处理过程。FreeSWITCH支持许多种编码。大部分的SIP终端也支持多种编码。而每条腿只能使用一种编码,因此,编码协商过程就是筛选过滤并确定最终选用编码的过程。这种“筛选过程”会引起混淆。这个过程是如何工作的?又如何修改它?本文将帮你回答这些问题。

FreeSWITCH的编码协商

        FreeSWITCH支持两种基本的编解码协商模式:早期协商和晚期协商。早期协商意味着在FreeSWITCH和终端之间尽快协商编码,甚至在FreeSWITCH需要发送媒体(如铃声)或响应呼叫之前。这个过程甚至在来电到触发拨号计划之前就发生了。晚期协商意味着延迟编解码的选择处理,直到呼叫触发拨号计划之后,(能够)收集到更多的信息时才协商编码。这些附加信息可用于影响协商过程。我们接下来说明早期协商和晚期协商之间的区别。

 

考虑一下这个场景:

  • Alice有一台支持G722PCMU的电话
  • Bob有一台支持PCMUPCMA的电话
  • FreeSWITCH针对外呼的编码偏好列表是:G722,G722.1,PCMU,PCMA,G729
    FS的这个编码表将提供给所有的外呼通话)

观察以下两个呼叫流程,看你能否发现A腿编码协商处理的差异:

  • 早期协商

Alice (A)拨打Bob (B)的号码

A呼叫FS并提供两种编码:G722和PCMU

FS检查A的编码表,并立即为A腿选择了G722编码

FS呼叫B并提供编码表:G722,G722.1,PCMU,PCMA,G729

B检视编码表,并选择PCMU

FS将A和B桥接在一起

FS执行G722和PCMU的编码转换

 

  • 携带“继承编码”集的晚期协商

Alice (A)拨打Bob (B)的号码

A呼叫FS并提供两种编码:G722和PCMU

FS检视这两种编码,但没有马上选择其中的一种

FS呼叫B并提供可选编码G722和PCMU

B检视编码集并选择PCMU

此时FS为A腿选择PCMU编码

FS将A和B桥接到一块

A与B通过PCMU通信(不需要额外的编码转换)

        注意A腿编码协商在时间上的差异。早期协商模式下,FreeSWITCH立刻选择一种编码(G722)。它并不等待和关心外呼(B腿)过程发生了什么,因此A腿直接选择722编码。在A腿决定编码后,FreeSWITCH通过拨号计划传递这个呼叫,最终通过一个bridge app呼叫Bob的电话。为了初始化bridge,FreeSWITCH呼叫了B腿,并提供了一个相当大的编码表,这个表来源于FreeSWITCH的外呼编码偏好配置(这个表是可自定义的,详情后叙)。Bob的电话看到这个编码表,并从中选择第一个匹配的编码,在本例中就是PCMU。这时,双边的编码协商结束。

  • A 腿使用 G722
  • B 腿使用 PCMU

        Bob的电话一回振铃信号,两条腿就被桥接在一起。FreeSWITCH必须将Alice的编解码器(G 722)转换为Bob的编解码器(PCMU),因为协商的结果是两种不同的编码。通常情况下,这是没问题的,但假设两部话机支持的编码集有交集,那你可能希望最终协商出相同的编码以减少CPU的消耗。这就是晚期协商起作用的地方。

        如您所见,当FreeSWITCH为A腿选择一种编码而不知道B腿上设置了什么编码时,就很容易出现“编码失配”。编码“不匹配”并不总是坏事,但很多时候,让两条腿共享相同的编码是件好事。使用晚期协商和一种名为“继承编码”的技术,我们可以强制A腿使用B腿上协商的编码。(这个过程稍后会详细描述,目前我们只考虑基本概念。)

        在我们的第二个例子中,基本的呼叫流是FreeSWITCH创建A腿,但不是立即协商编解码。相反,FreeSWITCH在执行拨号计划之后才开始协商A腿的编码。在这种情况下,拨号计划执行结果是桥接Bob的电话。在桥接过程中,FreeSWITCH与Bob的电话协商了一种编码器即PCMU。一旦在B腿上选择了编码,FreeSWITCH就回到Alice的话机上,告诉它我们将在A腿上使用PCMU。现在呼叫的两条腿就使用相同的编码,这正是我们想要的。

        这就是早期协商和晚期协商的区别所在。请记住:简单地启用晚期协商并不会自动强制A腿继承B腿的编码。它只是允许“继承编码”作为协商编码的一种方式。晚期协商允许使用其他编码协商技巧。更多详情,请继续阅读。

早期协商

        这是缺省的行为模式。

一般原则

 

  • A腿呼叫FreeSWITCH时,它所提供的编码表将与相关SIP配置文件中的inbound-codec-prefs内容进行比较。一旦A提供的某个编码与FS允许的编码匹配,就会选择它为A腿的编码。如果A提供的编码中没有一个与允许的编码相匹配,则呼叫失败。

注:由于算法的原因,入局SDP中的编码顺序相对于inbound-codec-prefs配置的编码顺序具体优先权。

  • 当FS呼叫B腿时,SIP配置项outbound-codec-prefs中的编码表被重新组织,方法是将上面A腿协商的编码推到表的顶部。显然,如果B不能接受编码表,结果就是呼叫失败。

例如:

A -------- GSM/PCMA/G729 --------> FS (allowing G729/PCMA/PCMU) -------- PCMA/G729/PCMU --------> B

发生了什么?

  • AFS建议编码表GSM/PCMA/G729
  • FS根据其允许的编码表(inbound-codec-prefs中配置)按优先次序(SDP中的先后顺序)检查建议的编码表,并选择PCMA作为第一个授权编码,因此编解码表调整为:PCMA/G 729/PCMU
  • FS将调整后的编码表提交给B

早期协商参数

  • disable-transcoding

这是一个可以在出局SIP配置文件中设置的参数。
它将强制B腿(出局)使用A腿(入局)协商结果相同的编码。

若要设置此参数,请将以下行添加到所需的SIP配置文件中

注意:通常误解的是,这个参数禁用FS中的编码转换能力。这是错误的。

这个参数只是更改出局编码以匹配入局端上的协商结果,从而达到不需转码的目的。

通过设置absolute_codec_string变量值为入局编码,也能达到相同的目的。

这个参数(仅在关闭晚期协商时适用)将从A腿获取协商后的编码,并将其作为在B腿的唯一选项(忽略任何其他编码设置),如果B腿不能使用相同的编码,则呼叫失败。(笔者实测,实际上在晚期协商模式下也是生效的)

  • absolute_codec_string

这是一个通道变量,可以在拨号计划中设置,通常是在桥接前设置。
这个变量将强制B腿使用变量值指定的编码列表,而不用考虑其它任何因素。

例如:


或者

在后一种表达式中,请在编码表加上一对单引号,以保护参数解析的完整性,以逗号( ',' )为编码分割符,比如{var1=val1,var2=val2,absolute_codec_string='GSM,PCMU'}

注意:这个通道变量适用于disable-transcoding变量。换句话说,如果在出局SIP配置文件设置了disable-transcoding变量,并且在拨号计划中设置absolute_codec_string

为有别于入局编码的值,那么依然会产生转码开销。

  • codec_string

这是一个通道变量,可以在拨号计划中设置,通常是在桥接前设置。
The defined codec list will override the one set in the outbound-codec-prefs parameter of the outbound profile.
这个变量定义的编码列表将覆盖出局配置文件的 outbound-codec-prefs参数中设置的值。
以下是一个例子:


或者:

早期协商+禁用转码:

        如果sofia配置文件中设置了这个参数,那么所有呼出到B腿的信令中,将只携带A腿协商结果(只带一种编码,优先级最高的那个)

在任何一种情况下,A腿上的变量“codec_string”控制提供给B腿的编码集。
变量“
absolute_codec_string”类似,但它暗示了隐式的编码列表,并将禁用一种默认行为--将A腿编码添加到列表中。

晚期协商(需要的参数)

  • inbound-late-negotiation
  • 呼叫将直接执行拨号计划而不需要先查看编码。
  • 协商将在A腿被应答后进行。
  • 允许你将呼叫路由到一个脚本,检查SDP,并通过"codec_string"通道变量重写可接受的编码表。
  • inherit_codec

inherit_codec=true (仅在启用晚期协商时才适用)将在B腿应答后触发编码协商,界时B腿的协商结果将会传递给A腿,以便两边使用相同的编码(如果A腿支持它);否则,它将从自己的列表中使用它所能使用的一切

  • ep_codec_string

只有在配置文件上启用晚期协商时,此变量才可用。它是一个可读字符串,包含主叫终端提取的所有编码。这可以很容易地从拨号计划中解析出来。

代理媒体

        如果启用代理媒体并且没有执行过answer app那么将无法进行编码协商。

不相容宿端

        如下所示,在需要混频/双腿编码不同、特别是激活media_mix_inbound_outbound_codecs变量的场景,媒体代理都不适用。

混频/双腿编码不同(需要转码)

        如果您希望FreeSWITCH能够将两条腿与不同的编码匹配(在其中进行编码转换),那么需要设置几个变量才能使其成为可能。首先,您必须设置media_mix_inbound_outbound_codecs=true,既可以全局设置(通过ie vars.xml),也可以通过bridge变量单独设置(例如: )。

        这个变量在V1.6及更高版本中是必须的,这是由于WebRTC支持,以及UDP承载SIP时SDP体量不断增长的原因。由于SDP的剪切尺寸,使得从WebRTC到SIP转换成原始SDP变得越来越困难。基于UDP承载SIP时,一旦出现分包,就会破坏SIP数据包,因为UDP不会进行自动分包重组。当SIP包大于MTU值时,就会产生分包,唯一的解决方案就是减小包的大小。这意味着压缩报头、消除额外的报头、或者删减不需要的编码描述以裁减SDP包体大小。

        这意味着紧凑的头,消除额外的头,或只是不使用这么大的SDP消除编解码你不需要。对FS的影响是:如果没有将media_mix_inbound_outbound_codecs设置为true,则只有A腿提供给FS的编码会被传递给B腿,这会减小SDP的体量,并大大减小了转码所带来的副作用。

        其次,你可能希望关闭inbound-late-negotiationinbound-zrtp-passthru (第二个强制第一个为true),或者希望在桥接之前预先应答A腿的呼叫。

        最后,您应该确保这些变量,disable-transcoding,inherit_codec,bypass_mediaproxy_media,统统设置为false (因为这些都与我们想要实现的目标无关)。

警告

        如果您的sdp包含具有不同ptime首选项的编码,并且ptimesdp中指定,那么sofia将不会发送ptime属性

 2010-10-18 11:47:52.234322 [WARNING] sofia_glue.c:213 Codec G723 payload 4 added to sdp wanting ptime 30 but it's already 20 (G729:18:20), disabling ptime.

说明实例

使用代理媒体模式时修改编码

         下面是一个dialplan示例,它允许您更改编码首选顺序,同时仍然享受proxy_media模式的低cpu使用率。它类似于openser/opensips/kamailio textops模块中的subst()


  
    
    
      
    

    
    
      
      
    

    
    
      
    

    
    
      
    

    
      
    
  

重写SDP

switch_r_sdp:


出局禁用G.729b


  
     
  

启用代理媒体时的编码协商

  • 正确方式

  
    
    
  
  • 错误方式

  
    
  

 

你可能感兴趣的:(FreeSWITCH)