Asterisk 20.4.0 with STUN/TURN function

Asterisk Asterisk Support
1

Hello. We have two Asterisk servers 20.4.0 and I made a separate TURN/STUN server (Debian 12.5 with Coturn software).

All calls have been working for a couple of years now, but sometimes I see the following error message under the CLI:
ERROR[235487]: pjproject: <?>: icess0x7f043ce6c458 …Error sending STUN request: Network is unreachable
I thought I’d make my own STUN server: Coturn
I made the following settings under Asterisk for the STUN function:

in pjsip_wizard.conf inserted the following:

endpoint/direct_media = no
endpoint/rewrite_contact = yes
endpoint/rtp_symmetric = yes
endpoint/force_rport = yes

in res_stun_monitor.conf.conf inserted the following:

stunaddr = sturn.xxx.yy
stunrefresh = 30

in rtp.conf.conf inserted the following:

stunaddr=sturn.xxx.yy:3478
turnaddr=sturn.xxx.yy:3478
turnusername=user
turnpassword=pass

If I look at it under CLI, the module is loaded and connected to the STUN server:

Module Description Use Count Status Support Level
res_stun_monitor.so STUN Network Monitor 0 Running core

Hostname Port Period Retries Status ExternAddr ExternPort
sturn.xxx.yy 3478 30 3 OK x.y.z.v 51304

When I start a call, I see the following logged:

[2024-06-04 11:55:10] STUN Packet, msg Binding Response (0101), length: 64
[2024-06-04 11:55:10] Found STUN Attribute Mapped Address (0001), length 8
[2024-06-04 11:55:10] Ignoring STUN attribute Mapped Address (0001), length 8
[2024-06-04 11:55:10] Found STUN Attribute Source Address (0004), length 8
[2024-06-04 11:55:10] Ignoring STUN attribute Source Address (0004), length 8
[2024-06-04 11:55:10] Found STUN Attribute Changed Address (0005), length 8
[2024-06-04 11:55:10] Ignoring STUN attribute Changed Address (0005), length 8
[2024-06-04 11:55:10] Found STUN Attribute Non-RFC3489 Attribute (8022), length 24
[2024-06-04 11:55:10] Ignoring STUN attribute Non-RFC3489 Attribute (8022), length 24
[2024-06-04 11:55:10] Dunno what to do with STUN message 0101 (Binding Response)
[2024-06-04 11:55:10]     -- Executing [+xxxxxxxxxxx@from-internal:1] NoOp("PJSIP/502-00000004", "Kimeno mobil hivas: +36203392836") in new stack
[2024-06-04 11:55:10]     -- Executing [+xxxxxxxxxxx@from-internal:2] NoOp("PJSIP/502-00000004", "CallerID: Mekk Elek") in new stack
[2024-06-04 11:55:10]     -- Executing [+xxxxxxxxxxx@from-internal:3] Gosub("PJSIP/502-00000004", "subCallrecording,s,1(+xxxxxxxxxxx)") in new stack
[2024-06-04 11:55:10]     -- Executing [s@subCallrecording:1] Set("PJSIP/502-00000004", "CALLFILENAME=2024-06-04 11-55-10_502_+xxxxxxxxxxx") in new stack
[2024-06-04 11:55:10]     -- Executing [s@subCallrecording:2] MixMonitor("PJSIP/502-00000004", "2024-06-04 11-55-10_502_+xxxxxxxxxxx.wav,b") in new stack
[2024-06-04 11:55:10]     -- Executing [s@subCallrecording:3] Return("PJSIP/502-00000004", "") in new stack
[2024-06-04 11:55:10]   == Begin MixMonitor Recording PJSIP/502-00000004
[2024-06-04 11:55:10]     -- Executing [+xxxxxxxxxxx@from-internal:4] Set("PJSIP/502-00000004", "CALLERID(num)=xxxxxxxx") in new stack
[2024-06-04 11:55:10]     -- Executing [+xxxxxxxxxxx@from-internal:5] Dial("PJSIP/502-00000004", "PJSIP/00xxxxxxxxxxx@invitech1,30") in new stack
[2024-06-04 11:55:10]     -- Called PJSIP/00xxxxxxxxxxx@invitech1
[2024-06-04 11:55:10] STUN Packet, msg Binding Response (0101), length: 64
[2024-06-04 11:55:10] Found STUN Attribute Mapped Address (0001), length 8
[2024-06-04 11:55:10] Ignoring STUN attribute Mapped Address (0001), length 8
[2024-06-04 11:55:10] Found STUN Attribute Source Address (0004), length 8
[2024-06-04 11:55:10] Ignoring STUN attribute Source Address (0004), length 8
[2024-06-04 11:55:10] Found STUN Attribute Changed Address (0005), length 8
[2024-06-04 11:55:10] Ignoring STUN attribute Changed Address (0005), length 8
[2024-06-04 11:55:10] Found STUN Attribute Non-RFC3489 Attribute (8022), length 24
[2024-06-04 11:55:10] Ignoring STUN attribute Non-RFC3489 Attribute (8022), length 24
[2024-06-04 11:55:10] Dunno what to do with STUN message 0101 (Binding Response)
[2024-06-04 11:55:11]        > 0x7f46844afc20 -- Strict RTP learning after remote address set to: 91.83.81.243:18130
[2024-06-04 11:55:11]     -- PJSIP/invitech1-00000005 is making progress passing it to PJSIP/502-00000004
[2024-06-04 11:55:11]        > 0x7f4684068b40 -- Strict RTP learning after remote address set to: 192.168.88.125:8000
[2024-06-04 11:55:12]        > 0x7f4684068b40 -- Strict RTP qualifying stream type: audio
[2024-06-04 11:55:12]        > 0x7f4684068b40 -- Strict RTP switching source address to 213.16.87.54:8000
[2024-06-04 11:55:12]        > 0x7f46844afc20 -- Strict RTP switching to RTP target address 91.83.81.243:18130 as source
[2024-06-04 11:55:12]     -- PJSIP/invitech1-00000005 is making progress passing it to PJSIP/502-00000004
[2024-06-04 11:55:16]        > 0x7f4684068b40 -- Strict RTP learning complete - Locking on source address 213.16.87.54:8000
[2024-06-04 11:55:16]        > 0x7f46844afc20 -- Strict RTP learning complete - Locking on source address 91.83.81.243:18130
[2024-06-04 11:55:18]     -- PJSIP/invitech1-00000005 requested media update control 26, passing it to PJSIP/502-00000004
[2024-06-04 11:55:18]     -- PJSIP/invitech1-00000005 requested media update control 26, passing it to PJSIP/502-00000004
[2024-06-04 11:55:18]     -- PJSIP/invitech1-00000005 requested media update control 26, passing it to PJSIP/502-00000004
[2024-06-04 11:55:18]     -- PJSIP/invitech1-00000005 requested media update control 26, passing it to PJSIP/502-00000004
[2024-06-04 11:55:18]     -- PJSIP/invitech1-00000005 requested media update control 26, passing it to PJSIP/502-00000004
[2024-06-04 11:55:18]     -- PJSIP/invitech1-00000005 requested media update control 26, passing it to PJSIP/502-00000004
[2024-06-04 11:55:18]     -- PJSIP/invitech1-00000005 requested media update control 26, passing it to PJSIP/502-00000004
[2024-06-04 11:55:18]     -- PJSIP/invitech1-00000005 requested media update control 26, passing it to PJSIP/502-00000004
[2024-06-04 11:55:18]     -- PJSIP/invitech1-00000005 answered PJSIP/502-00000004
[2024-06-04 11:55:18]     -- Channel PJSIP/invitech1-00000005 joined 'simple_bridge' basic-bridge <9246bad3-45b8-4b88-839c-1dd2fb11f4b6>
[2024-06-04 11:55:18]     -- Channel PJSIP/502-00000004 joined 'simple_bridge' basic-bridge <9246bad3-45b8-4b88-839c-1dd2fb11f4b6>
[2024-06-04 11:55:19] STUN Packet, msg Binding Response (0101), length: 64
[2024-06-04 11:55:19] Found STUN Attribute Mapped Address (0001), length 8
[2024-06-04 11:55:19] Ignoring STUN attribute Mapped Address (0001), length 8
[2024-06-04 11:55:19] Found STUN Attribute Source Address (0004), length 8
[2024-06-04 11:55:19] Ignoring STUN attribute Source Address (0004), length 8
[2024-06-04 11:55:19] Found STUN Attribute Changed Address (0005), length 8
[2024-06-04 11:55:19] Ignoring STUN attribute Changed Address (0005), length 8
[2024-06-04 11:55:19] Found STUN Attribute Non-RFC3489 Attribute (8022), length 24
[2024-06-04 11:55:19] Ignoring STUN attribute Non-RFC3489 Attribute (8022), length 24
[2024-06-04 11:55:19] Dunno what to do with STUN message 0101 (Binding Response)
[2024-06-04 11:55:23]     -- Channel PJSIP/invitech1-00000005 left 'simple_bridge' basic-bridge <9246bad3-45b8-4b88-839c-1dd2fb11f4b6>
[2024-06-04 11:55:23]     -- Channel PJSIP/502-00000004 left 'simple_bridge' basic-bridge <9246bad3-45b8-4b88-839c-1dd2fb11f4b6>
[2024-06-04 11:55:23]   == Spawn extension (from-internal, +36203392836, 5) exited non-zero on 'PJSIP/502-00000004'
[2024-06-04 11:55:23]   == MixMonitor close filestream (mixed)
[2024-06-04 11:55:23]   == End MixMonitor Recording PJSIP/502-00000004

The connection is established, there is sound on both sides (although it takes 2 seconds before the sound is heard when connecting), but it appears that Ignoring STUN attribute. Is this problem or is this normal operation?

2

If you don’t need to use STUN/TURN in Asterisk itself, then don’t. Using it adds another layer of dependency and potential failure to things and will introduce latency.

ERROR[235487]: pjproject: <?>: icess0x7f043ce6c458 …Error sending STUN request: Network is unreachable

This message can occur if there are IPv6 ICE candidates with link local addresses.

3

How do I know I don’t need STUN? Because I read that it is necessary in cases where the call would go behind NAT. Our VOIP servers are within the network of an internet service provider. Thus, VOIP has its own internal network and an external IP as well. In this case, it is not needed?

What exactly does that mean? Does anyone who wants to connect to us with a webrtc call only have an IPv6 address?

4

STUN is used to discover the external IP address and port for media. If you are directly on the internet, it’s not needed. If you’ve configured Asterisk to know it is behind NAT and port forwarded, it’s not needed. Within Asterisk it’s for cases where you can’t do any of that, which realistically is rare. It also doesn’t guarantee that media will flow as it is dependent on the behavior of the device providing internet access.

TURN is used for the case where direct connectivity fails, and if that happens with Asterisk it’s probably behind an extremely restrictive NAT.

As for IPv6 address, no. ICE works by giving a list of potential IP addresses+ports where media can go. The process then sends STUN packets to figure out which ones work, ultimately usually finding a path for media to flow. If one of those candidates is an IPv6 link local address then you’ll get the error message. It’s harmless. Some other ICE candidate will most likely succeed and media will flow.

5

And can I this IPv6 link local address be deleted from the list? Or is there no way to do this, so the maximum ice_support can be disabled in rtp.conf? But I think it is not recommended if the basic setting is ice_support=yes

6

If using WebRTC, then ICE is mandatory. There is an ice_deny option[1] which can be used to disallow candidates from being added. I don’t know if anyone has done so for this, I believe people just ignore the error as stuff still works regardless.

[1] asterisk/configs/samples/rtp.conf.sample at master · asterisk/asterisk · GitHub

7

Thx. Maybe can I list what IP’s it currently contains? Or should I simply block the IPv6 addresses of all network cards? Let’s I can disable this locally in Debian in sysctl.conf too…

8

The ICE candidates appear in the SDP in the SIP traffic, you can take a look. It’s up to you what you do with all this information.

9 
[2024-06-04 14:52:17]     -- Called palkonk-live
[2024-06-04 14:52:17]     -- x=0, open writing:  /var/spool/asterisk/recording/live/mvm/accidentInsuranceUpgrade/2024-06-04/1717505537.60913 format: wav, 0x7f0440028830
[2024-06-04 14:52:17]     -- PJSIP/palkonk-live-00008bfb is ringing
[2024-06-04 14:52:17]        > 0x7f027c716430 -- Strict RTP learning after remote address set to: x.y.z.y:18454
[2024-06-04 14:52:17]        > 0x7f027c716430 -- Strict RTP switching to RTP target address x.y.z.y:18454 as source
[2024-06-04 14:52:17]        > 0x7f041c4a2a90 -- Strict RTP learning after remote address set to: 192.168.0.3:59269
[2024-06-04 14:52:17] ERROR[235487]: pjproject: <?>:       icess0x7f041c90d118 ......Error sending STUN request: Network is unreachable
[2024-06-04 14:52:17]     -- PJSIP/palkonk-live-00008bfb answered
[2024-06-04 14:52:17]        > Launching Stasis(dialer-live) on PJSIP/palkonk-live-00008bfb

Then the problem is probably with the range 192.168.0.0/16. Anyway, this is also included in pjsip.conf:

[system-udp]
type = transport
protocol = udp
bind = 0.0.0.0:5060
allow_reload=yes
local_net=192.168.0.0/16
local_net=172.16.1.0/24
10

It is unlikely that is the cause. I’m not sure what exactly you’re expecting at this point from the thread.

11

I thought that because I just checked to see if this ip range is still alive, and it’s not. This domain used to be your local network, but not anymore. I’ll try it in the evening when no one is working on it.
Thank you very much for your help!

12

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