I watched the video and summarized everything you said below in case it’s useful for anyone that comes across this. Thanks for sharing the link really good explanation. But I’m hopelessly attached to FreeSWITCH at the moment I also realize this could be solved with an SBC up front. We also should have all the information we need to try the WAN IP first.
Hence my thought of “hey, maybe it’s possible to pare out the behaviour of sending the a LAN IP completely”, since we know in advance it won’t go anywhere. When I check those traces, FreeSWITCH is busy sending RTP to the LAN IP for some seconds before switching. However, we do get sporadic reports of delays up to many seconds before FreeSWITCH clues in. Reason being, we have many devices that don’t STUN (analog gateways to softphones and some deskphones from troublesome vendors).Įven as-is, they do work most of the time thanks to FreeSWITCH doing its autonat thing where it begins sending media to the WAN IP once it receives RTP. I used a Yealink without STUN as it was on my desk and is illustrative the scenario I’m grappling with. OK, thanks for explaining these settings, it’s more clear now!Īs I said earlier, I realize Yealinks can do NAT traversal better.
0 kommentar(er)
