We have the problem that if the configured TURN-server is blocked (if packets are just dropped by the firewall and the connection is not reset which works fine), this leads to high CPU, an unresponsive Asterisk for about 2 minutes and a very delayed call. However in most of the cases, in our specific scenario (intercom) we could also create a direct call.
Is there a way to prevent this such as a timeout for the request to the turn server or configuring some endpoints to not use it at all?
Since no one answered, I started a search in the source on github to find out more.
I found that the call to the turn is made in res_rtp_asterisk.c, function called ast_rtp_ice_turn_request. I saw, that there is a while waiting for the call to be done and it looks like there is no timeout or so. For stun however, the ast_stun_request in sun.c has STUN_MAX_RETIRES and a fixed timeout of 3000ms. So it looks to me, that there is nothing I can do and if the turn server is down or there is no connection because of no internet or so, my asterisk will just be not working.
Can anyone confirm this or is there maybe a way around it (because im not familiar with the asterisk code-base at all)? In particular, im not completeley sure, how long the line ast_cond_timedwait(&rtp->cond, ao2_object_get_lockaddr(instance), &ts); , which is in the while, blocks and if there is a way to get out of it (in a quick search, I couldnt find, where the status it waits for is set).
If indeed, there is no way around it, what would be the correct procedure to propose this to be resolved?
TURN usage in Asterisk is minimal to non-existent, as a result that code path is seldom touched. There’s probably no way around it. Issues are filed on Github[1], but there is no time frame on when it would get looked at - or even if.
Thanks a lot for the answer. Will create an issue on github then.
Is there an alternative that is more used to get around scenarios, where a relay is needed to allow communication or it just basically never happenes?
I have to say that the reason we need it is also just because although we have a vpn-connection to the asterisk, iphone-clients refuse to route the traffic through the tunnel and we cant get apple to fix it (just a small company, no way we can put any pressure on the giant ).
Most people have RTP ports forwarded to Asterisk, so that there is a clear path to Asterisk, and then have rtp.conf configured to have the external IP address as part of the ICE candidates.
).