SIP呼叫SDP中关于音频优先级选择的问题

      今天在使用自己SIP硬终端对接某运营商的云平台时，遇到一个比较奇葩的问题，我们SIP终端的音频格式只勾选了G711a，主动呼叫平台的服务号入会时，终端只能听到他们平台刚开始的部分声音，用wireshark分析抓包，发现平台过来g711a的RTP数据，seq突然从某一个值跳变到一个差值比较大的值，两包之家差了大概5000包，这可能是后面再也听不到语音的原因；但是使用一个友商的SIP硬终端呼入时，可以完整听到平台过来的所有声音，通过wireshark分析抓包，发现SIP终端在会成功入会前，平台发送的音频格式为g711u，当会议号和会议密码输入成功后，真正入会后，平台发送给终端的音频格式为g711a；通过自己终端和友商终端抓包的对比，初步怀疑，平台IVR播放提示音的原始音频格式为g711u，我们自己终端SDP报文中只声明了g711a，猜测可能是平台在将g711u转码为g711a后处理上有什么问题，导致部分音频数据丢掉了，没有发给我们，导致我们终端听不到后续的提示音。

       按照上面的推断，在我们自家SIP终端上同时勾选了g711a和g711u后，我们终端再次呼叫平台，分析抓包发现现象还是一样(平台发送过来的音频数据还是g711a，还是只能听到他们平台刚开始的部分声音)，通过和友商厂家SIP报文对比，发现友商SDP中m=audio 4230 RTP/AVP 118 115 114 9 102 113 101 103 0 8 15 18 119声明不同音频格式时，g711u在前面，g711a在后面，而我们终端的音频声明顺序是g711a在前面，g711u在后面，推测可能跟这个声明顺序有关，通过查阅相关RFC文档，发现如果想让对方优先发送那种音频或者视频，需要将该音频或视频能力写在前面。

       修改我们自己SDP中音频优先级，将g711u写在前面，将g711a写在后面，即m=audio 1000 RTP/AVP 0 8，终端再次入会后，能听到平台终端发送过来的所有声音，并且成功入会，INVITE SDP部分报文如下：