我只是对 SIP 的工作原理感到困惑，但我的却没有。我制作了一个简单的 android 服务器，它打开一个服务器套接字并监听 3G/4G 网络上的传入连接。然后我创建了一个连接到服务器的客户端，连接被我运营商的防火墙（AT&T）阻止了。
在此之后，我下载了一个基于 SIP 的开源 VOIP 应用程序，并将这 2 部电话注册到 SIP 代理上，让它们互相呼叫，这样就完美了。
我对 SIP 如何在蜂窝网络上工作感到非常困惑，SIP 是一种 p2p 协议，SIP 代理仅用于重定向。这 2 部电话如何在 VOIP 会话中相互连接？为什么此连接没有被运营商阻止？有人可以向我解释吗？先感谢您！
在基本的 SIP 中，端点媒体流量通常以您所说的 P2P 方式在彼此之间直接通信。他们这样做是在 SIP SDP协商中相互提供地址/端口。
在“完美”的网络世界中，这可以正常工作，因为所有端点都可以在彼此之间直接对话。
正如我们所知，情况并非如此。
在大多数情况下，IPv4 世界的主要障碍是 NAT。
人们提出的第一个解决方案是STUN。STUN 将为您提供您在 NAT 后面使用的“公共”IP 地址，SIP 堆栈将在 SIP/SDP 数据包中使用该 IP 地址。只要打孔有效，此方法就有效。
人们提出的下一个解决方案是TURN。TURN 是一个 UDP 代理，允许客户端（例如 SIP 客户端）从公共网络（即互联网）分配和使用专用网络上的 IP 地址/端口。它应该适用于所有情况，但会在 TURN 服务器上增加大量网络开销。它不会像 P2P 连接那样有效。使用 TURN 的好处是不需要双方都支持它才能工作。因此，当您在 Internet 上的软电话与内部网络上的硬件 SIP 设备之间进行通话时，这很好。
人们提出的下一个解决方案是ICE。两个 SIP 端点都需要支持 ICE。它通过扩展 SDP 协议来工作，以允许它在 SDP 协商中添加所有可能的连接（所有本地网络适配器、STUN 提供的公共地址和 TURN 按优先级顺序分配的地址）。然后一侧通过列出的连接并尝试建立连接。这允许两个连接都“尝试”连接 P2P 并在没有其他方法的情况下回退到 TURN 连接。它还应该在任何网络环境中工作到任何网络环境，并在 SIP 端点之间找到最有效的网络路径。ICE 的缺点是两个 SIP 端点都需要支持 ICE 才能工作。（顺便说一句，ICE/TURN/STUN 现在是WEBRTC的一项要求出于同样的原因，Web 浏览器之间相互通信的协议）
其他可能的解决方案是让您在中间有某种“智能” sip 代理，如果另一侧不支持它，它可能会在一侧伪造 ICE。另一个是如果需要转码，则拥有某种媒体网关或 B2BUA，这将与 TURN 存在相同的问题。
如果可能，我建议您使用 STUN、TURN 和 ICE 设置您的 SIP 客户端，这将增加 SIP 呼叫实际工作的可能性。
至于为什么您的案例现在不起作用，它需要网络和/或 SIP 日志来了解确切的障碍是什么。