1. 这个问题很大可能和和SDP没有正确修改有关。需要排查SIP信令的sdp地址是否正确。
  2. 防火墙策略问题：有的网络允许udp出去，但是不允许udp进来。需要设置防火墙策略。
  3. udp端口范围太小。一般一个通话需要占用4个udp端口。如果开放的udp端口太少，在通话达到一定数量后，就会出现一部分呼叫没有可用端口。
  4. 用户设备的问题。例如用户的电脑声卡或者扬声器出现问题。
  5. 由于网络的复杂性，还有很多可能

一般遇到这个问题，可以按照如下的思路排查：

  1. 服务端有录音功能的，可以先在服务端听录音，看看服务端录音里是否正常。一般来说有四种情况。
    1. 两方的录音都没有
    2. 主叫方有，被叫方没有
    3. 被叫方有，主叫方没有
    4. 主被叫都有。但是就是一方听不到另一方。

通过排查服务端的录音，就可以大致知道到底是AB两个leg, 每个leg上的语音流收发的情况。

  1. 从信令的的sdp中分析，这个需要一定的SIP协议的分析能力。有些时候，sdp里面的媒体地址不正确，也会导致媒体流无法正常首发。
  2. NAT策略。NAT一般有四种，用的比较多的是端口限制型。这种NAT要求外网流量在进入NAT内部时，必需先有内部的流量出去。当内部流量出去之后，这个NAT洞才会出现，外部的流量才能从这个洞进入。如果NAT内部设备一直不发送rtp包，那么外部的流量即使进来，也会被防火墙拦截掉。
  3. 无论是运维人员还是开发人员，在遇到媒体流问题时，一定要先搞清楚整个软交换的网络拓扑架构。否则只能南辕北辙。
  4. sngrep -cr, 加上r这个参数，可以实时观察媒体流的流动情况。是个非常好的功能。但是对于那种加密的媒体流，sngrep是抓不到的，这点要注意。常见的WebRTC的媒体流就是加密的。
  5. 最终如果还是解决不了，那么只能祭出最后的杀器：tcpdump + wireshark。服务端抓包的话，虽然sngrep可以抓包，但是比较浪费内存还可能会出现丢包。最好用tcpdump抓包成文件，然后在wireshark上分析。