STUN/ICE not working

I am running Certified Asterisk 13 with chan_sip (pjsip is no option for me at the moment as I am required to use Asterisk 13). I am trying to use STUN or ICE, but it does not work. Reference for the STUN/ICE configuration is the asterisk wiki.
My configuration for STUN:
icesupport = yes


res_stun_monitor.conf is also set up, the module is loaded

In wireshark I can see STUN packets being sent to and answered by the STUN server.

When enabling STUN debug, I see
STUN Packet, msg Binding Response (0101), length: 68
Found STUN Attribute Mapped Address (0001), length 8
Ignoring STUN attribute Mapped Address (0001), length 8
Found STUN Attribute Source Address (0004), length 8
Ignoring STUN attribute Source Address (0004), length 8
Found STUN Attribute Changed Address (0005), length 8
Ignoring STUN attribute Changed Address (0005), length 8
Found STUN Attribute Non-RFC3489 Attribute (8020), length 8
Ignoring STUN attribute Non-RFC3489 Attribute (8020), length 8
Found STUN Attribute Non-RFC3489 Attribute (8022), length 16
Ignoring STUN attribute Non-RFC3489 Attribute (8022), length 16
Dunno what to do with STUN message 0101 (Binding Response)

However, “stun show status” gives a correct external IP, so STUN seems to work nevertheless.

Hostname                  Port  Period  Retries  Status  ExternAddr       ExternPort          3478  30      3        OK      <correct external IP>    58499

Now, I would expect the SDP then to contain the external address instead of the private IP my asterisk instance has (being behind a NAT). But there is always the private IP address, never the public IP. Also, the IP in the SIP header only contains the private IP address. The external IP address is never used in any SIP message.

My questions regarding this:

  1. Should not STUN/ICE make asterisk replace the private address with the public address
    (a) in the SIP header
    (b) in the SDP header?
  2. The Asterisk Wiki suggests that there should be lines for ice in the SDP. But there are none according to the output I get from sip debug in the asterisk log.
  3. Main question is: Is there something I am doing wrong? What are my options for further debugging or fixing this?


The STUN functionality does not alter the SDP or SIP headers like that. You still have to configure them in sip.conf.

If I recall ICE support may have to be enabled at the user/peer level, if you aren’t doing so. The other side also has to support ICE.

You could run the client of the stund package and check whether there are any anomalies.

Sine you are mentioning the private IPs, the first question would be about your nat related settings (nat, externip/externhost, localnet, …).

Why dont you use the options Asterisk offers when dealing with NAT

I made a list of them here (some of then are configured global other on peer section

Thanks for all the responses.

@ambiorixg12 and EkFudrek I know about these settings and they work as expected. However, I am dealing with a situation where the public IP address changes on a daily basis. This is why I need STUN in the first place.

@jcolp From your answer, I am not sure what to expect from Asterisks STUN feature. You said that with STUN enabled no IPs are replaced, but why then have STUN support in the first place if it has no effect?
I assume switching to pjsip will not change anything wrt this, will it?
I will try to enable ICE on a per user level, maybe this makes a difference. Thanks for the suggestion.

It serves two purposes:

  1. It’s used by the res_stun_monitor module to monitor the external IP address so things inside can be triggered (such as re-registering an outbound registration so they get the new IP address).

  2. It’s used by the ICE support to determine the external IP address to place into ICE candidates.

While it could be used as you originally wanted, that is not functionality anyone has written and built in.

use the externhost = hostname[:port]" is similar to “externaddr” except
; that the hostname is looked up every “externrefresh” seconds
; (default 10s).

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.