SIP/RTP如何确定两个端点在同一LAN上？
我只是在尝试我的电话系统，我想知道两个端点如何知道它们在同一局域网上，我两个端点都在使用两个单独的公共IP地址爆发到云电话系统，我将它们从每个端口分段。另一个带有防火墙，所以他们看不到彼此RTP通信和通话没有音频。
我只是想知道两个端点如何意识到它们在同一防火墙/路由器后面，因为它们都从不同的公共IP地址向云系统注册，我希望呼叫在云中桥接而不是穿越本地LAN，而是以某种方式穿越本地LAN这两个终点都只会每次尝试通过LAN上的呼叫，也不知道他们是如何意识到自己在同一LAN上的。
其他人以前遇到过吗？
I am just experimenting with my phone system and I'm wondering how both endpoints know they are on the same LAN, I have both endpoints breaking out to the cloud phone system with two separate public IP addresses, I've segmented them off from each other with a firewall so they can't see each other however every time I attempt a call between the two end points the call is setup as a peer to peer call and attempts to traverse the local LAN via RTP through the firewall, the firewall blocks the RTP communication and the call has no audio.
I am just wondering how both endpoints are realizing they are behind the same firewall/router since they are both registering with the cloud system from different public IP addresses, I wanted the call to be bridged in the cloud and not traverse the local LAN but somehow both endpoints only attempt the call over the LAN every single time and no idea how they're realising they're on the same LAN.
Anyone else encountered this before?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
SIP端点不必知道它们在同一LAN上。他们只是充分利用您提供的IP地址。
您的邀请请求将提供更多的见解，但是根据您的猜测，您的猜测是您在SDP报价中使用Contact/request URI和本地IP地址的公共IP地址。本地IP地址可能可以通过防火墙路线。
SIP endpoints don't have to know they are on the same LAN. They just make best use of the IP addresses you provide.
Your INVITE request will provide more insight, but from what you write my guess is that you use public IP addresses for your contact/request URI and local IP addresses in your SDP offer. The local IP addresses are probably routable through the firewall.
有了ICE和Stun端点，可以选择用于媒体流量的最佳IP-但为此，RTP/Stun数据包应该能够穿越LAN中的防火墙。
尝试直接沟通的尝试可能意味着LAN使用来自公共范围或终点的IPS sip代理不够聪明，无法在LAN前检测NAT。
With ICE and STUN endpoints may select the best IPs for media traffic - but for that to work the RTP/STUN packets should be able to traverse the firewall in your LAN.
Attempts to communicate directly may mean that LAN uses IPs from public ranges or endpoints a SIP proxy were not smart enough to detect NAT in front of your LAN.