ICE disabled, but "ICE session created" log entries

I have been recently seeing numerous log entries related to ICE that were not there previously, they talk about ICE and STUN sessions, however I do not use either of these. It is filling up my log files and making it difficult to find anything else in the logs.

How do I disable ICE and STUN?

in sip.conf I already have “icesupport = no”

I am running Asterisk 13.3.2. I have the logs output to syslog as fail2Ban looks for them there (If I don’t have fail2ban running then I get subjected to sipvicious attacks which use up my monthly download quota within a few hours).

Thank you.

The log entries are as follows…

Jan 11 20:15:18 ext asterisk: [2019-01-11 20:15:18] #033[1;31mWARNING#033[0m[11311]: #033[1;37mchan_sip.c#033[0m:#033[1;37m3996#033[0m #033[1;37mretrans_pkt#033[0m: Retransmission timeout reached on transmission 1656275085-1171702266-649856119 for seqno 1 (Critical Response) – See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
Jan 11 20:15:18 ext asterisk: Packet timed out after 32000ms with no response
Jan 11 20:15:18 ext asterisk: 20:15:18.263 icess0x7fda1c0 ICE session created, comp_cnt=2, role is Unknown agent
Jan 11 20:15:18 ext asterisk: 20:15:18.264 icess0x7fda1c0 Candidate 0 added: comp_id=1, type=host, foundation=Hc0a88318, addr=192.168.131.24:16410, base=192.168.131.24:16410, prio=0x7effffff (2130706431)
Jan 11 20:15:18 ext asterisk: 20:15:18.264 icess0x7fda1c0 Candidate 1 added: comp_id=1, type=host, foundation=Hc0a88301, addr=192.168.131.1:16410, base=192.168.131.1:16410, prio=0x7effffff (2130706431)
Jan 11 20:15:18 ext asterisk: 20:15:18.264 icess0x7fda1c0 Candidate 2 added: comp_id=1, type=host, foundation=Hc0a80118, addr=192.168.1.24:16410, base=192.168.1.24:16410, prio=0x7effffff (2130706431)
Jan 11 20:15:18 ext asterisk: 20:15:18.264 icess0x7fda1c0 Candidate 3 added: comp_id=1, type=host, foundation=Hc0a80101, addr=192.168.1.1:16410, base=192.168.1.1:16410, prio=0x7effffff (2130706431)
Jan 11 20:15:18 ext asterisk: 20:15:18.264 icess0x7fda1c0 Candidate 4 added: comp_id=1, type=host, foundation=Hc0a88118, addr=192.168.129.24:16410, base=192.168.129.24:16410, prio=0x7effffff (2130706431)
Jan 11 20:15:18 ext asterisk: 20:15:18.264 icess0x7fda1c0 Candidate 5 added: comp_id=1, type=host, foundation=Hc0a88101, addr=192.168.129.1:16410, base=192.168.129.1:16410, prio=0x7effffff (2130706431)
Jan 11 20:15:18 ext asterisk: 20:15:18.264 icess0x7fda1c0 Candidate 6 added: comp_id=1, type=host, foundation=Hc0a88018, addr=192.168.128.24:16410, base=192.168.128.24:16410, prio=0x7effffff (2130706431)
Jan 11 20:15:18 ext asterisk: 20:15:18.264 icess0x7fda1c0 Candidate 7 added: comp_id=1, type=host, foundation=Hc0a88001, addr=192.168.128.1:16410, base=192.168.128.1:16410, prio=0x7effffff (2130706431)
Jan 11 20:15:18 ext asterisk: 20:15:18.264 icess0x7fda1c0 Candidate 8 added: comp_id=1, type=host, foundation=Hc0a88518, addr=192.168.133.24:16410, base=192.168.133.24:16410, prio=0x7effffff (2130706431)
Jan 11 20:15:18 ext asterisk: 20:15:18.264 icess0x7fda1c0 Candidate 9 added: comp_id=1, type=host, foundation=Hc0a88501, addr=192.168.133.1:16410, base=192.168.133.1:16410, prio=0x7effffff (2130706431)
Jan 11 20:15:18 ext asterisk: 20:15:18.264 icess0x7fda1c0 Candidate 10 added: comp_id=1, type=host, foundation=Hc0a80218, addr=192.168.2.24:16410, base=192.168.2.24:16410, prio=0x7effffff (2130706431)
Jan 11 20:15:18 ext asterisk: 20:15:18.264 icess0x7fda1c0 Candidate 11 added: comp_id=1, type=host, foundation=Hc0a80201, addr=192.168.2.1:16410, base=192.168.2.1:16410, prio=0x7effffff (2130706431)
Jan 11 20:15:18 ext asterisk: 20:15:18.264 icess0x7fda1c0 Candidate 12 added: comp_id=1, type=host, foundation=Hc0a88401, addr=192.168.132.1:16410, base=192.168.132.1:16410, prio=0x7effffff (2130706431)
Jan 11 20:15:18 ext asterisk: 20:15:18.264 icess0x7fda1c0 Candidate 13 added: comp_id=1, type=host, foundation=Hc0a8c001, addr=192.168.192.1:16410, base=192.168.192.1:16410, prio=0x7effffff (2130706431)
Jan 11 20:15:18 ext asterisk: 20:15:18.264 icess0x7fda1c0 Candidate 14 added: comp_id=1, type=host, foundation=Hdce96750, addr=:16410, base=:16410, prio=0x7effffff (2130706431)
Jan 11 20:15:18 ext asterisk: 20:15:18.264 icess0x7fda1c0 Destroying ICE session 0x7fda1c00ad98
Jan 11 20:15:18 ext asterisk: 20:15:18.264 stuse0x7fda1c0 STUN session 0x7fda1c00cda8 destroy request, ref_cnt=4
Jan 11 20:15:18 ext asterisk: 20:15:18.264 stuse0x7fda1c0 STUN session 0x7fda1c038898 destroy request, ref_cnt=3
Jan 11 20:15:18 ext asterisk: 20:15:18.264 ice_session.c ICE session 0x7fda1c00ad98 destroyed
Jan 11 20:15:18 ext asterisk: 20:15:18.264 stun_session.c STUN session 0x7fda1c00cda8 destroyed
Jan 11 20:15:18 ext asterisk: 20:15:18.264 stun_session.c STUN session 0x7fda1c038898 destroyed
Jan 11 20:15:18 ext asterisk: #033[1;30m == #033[0mUsing SIP RTP TOS bits 96
Jan 11 20:15:18 ext asterisk: #033[1;30m == #033[0mUsing SIP RTP CoS mark 5
Jan 11 20:15:18 ext asterisk: [2019-01-11 20:15:18] #033[1;33mNOTICE#033[0m[11311][C-00000007]: #033[1;37mchan_sip.c#033[0m:#033[1;37m25621#033[0m #033[1;37mhandle_request_invite#033[0m: Call from ‘’ (195.154.150.115:58463) to extension ‘*30441904911302’ rejected because extension not found in context ‘public’.

That is normal and is due to the way that the RTP interface works. A session may initially allocate with ICE/STUN, but then afterwards disable itself. If you never need to use ICE/STUN/TURN at all you can disable it in rtp.conf and it will not allocate at all.