TURN candidates not present in SIP headers when using ICE on Asterisk 13

Asterisk Asterisk Support
1

I am using an Asterisk 13.13.1 server behind a NAT firewall with FreePBX 13.0.190.17 and I have two chan_sip extensions.
And these extensions are also registered from behind NAT of different networks. I was able to register my extensions in Asterisk.
In order to successful voice communication over RTP, I noticed that it is essential to configure ICE for achieving my needs.
And I did the following steps
I have enabled ICE support for both extensions with FreePBX GUI, then configured STUN and TURN on SIP Settings.
And when I testing the stun status with asterisk CLI (using command: stun show status) , I got the following

Hostname                  Port  Period  Retries  Status  ExternAddr       ExternPort
global.stun.twilio.com    3478  30      3        OK      123.123.123.123    37254

When I tested by making phone calls between the extensions I got the sip INVITE packets with STUN candidates as given below

Content-Length: 527
v=0
o=root 788094571 788094571 IN IP4 123.123.123.123
s=Asterisk PBX 13.13.1
c=IN IP4 123.123.123.123
t=0 0
m=audio 16136 RTP/AVP 0 8 3 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=ice-ufrag:54bf4e3c1e1db66768c03bb8427c02d1
a=ice-pwd:7ecf92c504f005395e9b50e20376e701
a=candidate:Hac1e002e 1 UDP 2130706431 10.10.10.10 16136 typ host
a=candidate:S22c66e1f 1 UDP 1694498815 123.123.123.123 16136 typ srflx raddr 10.10.10.10 rport 16136
a=candidate:Hac1e002e 2 UDP 2130706430 10.10.10.10 16137 typ host
a=candidate:S22c66e1f 2 UDP 1694498814 123.123.123.123 16137 typ srflx raddr 10.10.10.10 rport 16137
a=sendrecv

But the problem is that I don’t getting any candidates related with TURN. What would be the reason for this?
Do i need to setup any additional configurations?

2

I can’t speak for the FreePBX GUI but TURN is configured in the rtp.conf file. Disregarding that - is the endpoint you are using capable of ICE? If not then even with the candidates it won’t use ICE.

3

I am using Zoiper as the softphone. Is it able to handle ICE? What else can I do to make sure about this?

4

I have also tried with MicroSIP, there is an option to enable ICE on MicroSIP. Then also I got the same ICE candidates as I posted above.

5

I don’t know if Zoiper has support for ICE. As well like I said I don’t know how FreePBX configures things, if you provide rtp.conf then it can be seen if TURN is properly configured. Additionally most people don’t need/use ICE for NAT traversal, Asterisk can be configured to support the scenario without it for all endpoints. This is done by configuring Asterisk to know its public IP address and what the local network range is (if it is behind NAT) and also by configuring NAT support itself on the endpoint.

6

This is the content of rtp.conf file

[general]
rtpstart=10000
rtpend=20000
rtpchecksums=yes
strictrtp=yes
stunaddr=global.stun.twilio.com
turnaddr=global.turn.twilio.com
turnusername=<turnusername-here>
turnpassword=<turnpassword-here>
7

That should be enough to do, so I don’t know why there wouldn’t be TURN candidates - unless it failed to authorize and thus didn’t allocate.

8

Can I specify transport type like this- global.turn.twilio.com:3478?transport=udp ?

9

I don’t think pjnath, the library used for it, supports that. We give it the above information and it does everything.

10

When I use the ICE enabled endpoint extensions, I could see that RTP packets have something related to ICE. But TURN candidates are not present in packet headers.

Sent RTP packet to      123.123.123.123:50821 (via ICE) (type 00, seq 018938, ts 033760, len 000160)
Got  RTP packet from    123.123.123.123:50821 (type 00, seq 023113, ts 036000, len 000160)
Sent RTP packet to      123.123.123.123:50821 (via ICE) (type 00, seq 018939, ts 033920, len 000160)
Got  RTP packet from    123.123.123.123:50821 (type 00, seq 023114, ts 036160, len 000160)
11

That means ICE negotiation successfully occurred and media is flowing over it. TURN isn’t absolutely required in order for ICE to work.

12

Do I require to use chan_pjsip instead of chan_sip?

13

No, they are both equivalent in that. I don’t know why TURN candidates would not be present and am not set up to quickly test and narrow it down, it would take some time. If you feel it’s a bug you can file an issue[1] but I don’t have a time frame on when it would get looked into. TURN isn’t something many people use in Asterisk.

[1] https://issues.asterisk.org/jira

14

@Arunbalan
I also have this problem.

It is actually the same thing.
ICE is not working with Asterisk 13.13.1

How did you get one reflexive candidates?