WebRTC (sipML5) answer delayed ~1.5 minutes when Asterisk is behind NAT (Asterisk 18 + PJSIP + WSS)

Asterisk Asterisk WebRTC
1

Hi all,

I’m running Asterisk 18.26.4 with PJSIP and WebRTC (sipML5 in Chrome). Asterisk is deployed behind NAT.

Problem:

Inbound SIP calls from my provider reach Asterisk immediately and are processed normally (Queue(), ringing, etc.). However, when the WebRTC agent clicks “Answer” in the browser, the SIP 200 OK from the browser is delayed by ~1–2 minutes.

After the 200 OK finally arrives, Asterisk immediately sends ACK and the call bridges successfully.

So the delay happens before Asterisk receives the final 200 OK from the WebRTC client.

Environment:

- Asterisk 18.26.4

- Inbound trunk: UDP 5060

- WebRTC transport: WSS 8089

- Asterisk is behind NAT

- WebRTC uses DTLS-SRTP

- Queue() is used for inbound routing

- TURN server is configured (relay candidate visible in SDP)

Observed behavior:

  1. Provider → Asterisk INVITE arrives instantly.

  2. Asterisk sends 100 Trying / 180 Ringing immediately.

  3. Queue() calls WebRTC endpoint.

  4. Asterisk sends INVITE over WSS immediately (confirmed via pjsip logger).

  5. Browser rings immediately.

  6. User clicks “Answer”.

  7. ~1.5 minutes delay.

  8. Browser finally sends SIP/2.0 200 OK with SDP.

  9. Asterisk sends ACK immediately and call connects.

Current transport config:

[transport-udp]

type=transport

protocol=udp

bind=0.0.0.0:5060

local_net=132.X.X.0/16

[transport-wss]

type=transport

protocol=wss

bind=0.0.0.0:8089

cert_file=/etc/asterisk/certs/xxx.pem

priv_key_file=/etc/asterisk/certs/xxx.pem

WebRTC endpoint template:

type=endpoint

webrtc=yes

media_encryption=dtls

dtls_verify=fingerprint

dtls_setup=actpass

use_avpf=yes

force_rport=yes

rewrite_contact=yes

rtp_symmetric=yes

media_use_received_transport=yes

direct_media=no

transport=transport-wss

allow=opus,ulaw

Questions:

  1. If Asterisk is behind NAT, should I explicitly set:

    • external_signaling_address

    • external_media_address

    • proper private local_net ranges

    • ice_support=yes

  2. Could incorrect NAT settings cause WebRTC ICE to stall for a long time before the browser sends 200 OK?

  3. Is a 1–2 minute delay typical when ICE is trying multiple failed candidates before selecting a working relay path?

  4. What is the recommended minimal NAT configuration for Asterisk 18 + PJSIP + WebRTC behind NAT?

I can provide:

- Full pjsip set logger on output

- rtp set debug on

- chrome://webrtc-internals dump

- Full pjsip.conf and rtp.conf

Any guidance on proper NAT + ICE configuration for this scenario would be greatly appreciated.

2

I’m not familiar with the fine details of ICE, but very long delays in call setup are normally the result of unreachable name servers.

3

I’ve had this happen due to ICE Candidate thrashing, basically there were so many ICE candidate pairs it just took a while to get through them all.

It was due to my phone being on a vpn with turn enabled, which, due to the 2 network interfaces it took the DTLS handshake a while to find the best one.

Does your asterisk box have a public IP that allows direct connection?

4

Thanks for the suggestion.

DNS resolution appears to be working correctly in my environment. The domain ivr.X.net resolves to the public IP 192.145.X.X, and I also tested using the direct IP address instead of the domain with the same behavior, so it doesn’t appear to be related to unreachable name servers.

The setup is Asterisk 18 with PJSIP + WebRTC (sipML5) behind a Fortigate firewall. The server has a private IP (132.x.x.x) which is NATed to the public IP 192.145.x.x.

When using PJSIP WebRTC within the local network, there is a noticeable delay when answering the call. However, when the connection is from outside the local network, the call rings but the agent cannot answer it successfully.

Interestingly, chan_sip works both locally and publicly without any delay

5

That sounds very similar to what I am observing.

My Asterisk server does not have a direct public IP. It is behind a Fortigate firewall with the following setup:

Private IP: 132.x.x.x

Public NAT IP: 192.145.x.x

Domain: ivr.x.net → 192.145.x.x → 132.32.x.x

WebRTC clients connect via WSS to Asterisk, and TURN/STUN is configured on the same server.

When using PJSIP WebRTC inside the local network, the call can be answered but there is a noticeable delay before the call connects. When the connection is from outside the local network, the call rings but the agent is unable to answer it.

Interestingly, chan_sip works both locally and publicly without any delay

6

What about reverse lookups (inaddr.arpa)?

It’s probably going to be best to use tcpdump/wireshark, to see where it is stalling.