There is a lot to ICE that is beyond the scope of this document. For in-depth detail, see the links to the relevant RFCs below. While the RFCs contain a lot of information, it is mostly oriented at implementation of the ICE protocol and is not necessary for using Asterisk's ICE support. At a user level ICE uses SDP offer/answer, so the general concepts are fairly easy to follow for those familiar with SIP. Also, the details of visually interpreting candidate lists are fairly straightforward and are as easily digestible as media format SDP after a small amount of practice.
Asterisk ICE support is enabled globally by default throughout Asterisk, but is disabled by default for chan_sip specifically, and can be enabled inside chan_sip both globally or on a SIP peer basis in
However, as ICE needs a STUN and/or TURN server to gather usable candidates, these do need to be configured to get things working. Since ICE is an RTP level feature, the configuration can be found in the
rtp.conf file. The configuration applies to all RTP based communications so the options are set in the
general section. To configure a STUN server add a
stunaddr option with the hostname of the STUN server. For example,
turnport option can also be used if the TURN server is running on a non-standard port. If omitted, Asterisk uses the standard port number 3478.
Since ICE is enabled by default, configuration of the STUN server and optionally, the TURN server, is all that is required to get things running.
Successful configuration can be visually verified by turning SIP debugging on (
sip set debug on) in an Asterisk console and looking at INVITE messages as they go past. The body of a typical message would look something like this:
Generation of SDP for ICE candidate lists can be disabled by adding
to the general section in
sip.conf or on a peer-by-peer basis. Since ICE operates on RTP, ICE details are configured in the
rtp.conf file. To disable ICE support in RTP, add
icesupport = no the same line to the general section in