freeswitch 媒体早期协商模式分析

从 wiki 上，学习到 freeswitch 的媒体协商分为早期协商跟延迟协商，简单的说，就是协商的时间点不同。

早期协商： 是在一个 Inbound call 进来的时候，fs 就对其 SIP 消息中的 SDP 跟 inbound-codec-prefs 参数值进行匹配比较，并确认 lega 的编码方式

延迟协商： 在收到 inbound call 的时候，先不做匹配比较，而是等到 outbound call 有了回复后，183或200OK消息后，再做编码协商确认

在阅读wiki的时候，看到如下描述：

意思就是，通常情况下 FS 会将 lega 匹配到的编码加上 outbound-codec-prefs 参数中指定的编码一起， 构造在 sdp 中，作为 legb 的请求。

并且只有在 early negotiation + disable transcoding 的情况下，才仅仅把协商出来的编码作为 legb 的请求。(我的理解：协商出来的编码是唯一的，匹配的编码可以是多个)

然而，经过 FS 测试发现，只要是 early negotiation 模式， 不管是否设置了 disable transcoding, 发给 legb 的 INVITE 消息中，都只带了一个编码，就是 lega 协商出来的那个！ 这里有些不解，于是跟踪了下源码。流程如下：

在针对 inbound call 调用 switch_core_media_negotiate_sdp的过程中，有如下调用

即 FS 在这里第一步，把匹配到的 codec 做了一个排序， greedy 表示以 fs 提供的编码顺序优先； 第二步就是把排序后的第一个编码赋值给 lega 的当前 payload_map

接下来 FS 就会调用 switch_core_media_set_codec来设置 lega 的 read_codec

当把 lega 的所有媒体处理协商完成，FS 执行 bridge 动作， 会调用 switch_core_session_outgoing_channel函数

在这里，就把 lega 中协商出来的唯一 codec 设置到了 legb 通道的 SWITCH_ORIGINATOR_CODEC_VARIABLE变量上，

那么，接下来，FS 就调用 switch_core_media_prepare_codecsf方法，获取到通道中的 SWITCH_ORIGINATOR_CODEC_VARIABLE 变量值，作为 ocodec 即 outbound codec.

最后， 调用 switch_core_media_gen_local_sdp 方法，构造出 outbound INVITE 消息中的 SDP 信息。

至此， 基本上就是 Freeswtch 在媒体早期协商模式下的基本简单流程，表明了，FS 只会用协商出来的编码（即匹配列表中的第一个）作为 legb INVITE 的编码