DIDWW calls issue call close after 30s with NAT FreePBX

FreePBX Providers
,
1

Hi I have an issue with our DIDWW pjsip trunks.

When I select Local address our real network address outbound work fine but Inbound calls are closing with BYE after 30 seconds.

If I select 0.0.0.0/1 as local network address the call for Oubound will fail after 25s but Inbound will work fine.

DIDWW support say that issue come from the fact that our PBX present in O and C the local ip instead of public ip

CSeq: 10 INVITE

Server: FPBX-17.0.19.28(22.5.0)

Allow: OPTIONS, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INFO, REFER, MESSAGE

Contact: sip:172.23.3.105:5060

Supported: 100rel, timer, replaces, norefersub

Content-Type: application/sdp

Content-Length: 300

v=0

o=- 311510 791167 IN IP4 172.23.3.105

s=Asterisk

c=IN IP4 172.23.3.105

t=0 0

m=audio 11082 RTP/AVP 0 8 18 101

a=rtpmap:0 PCMU/8000

a=rtpmap:8 PCMA/8000

a=rtpmap:18 G729/8000

a=fmtp:18 annexb=no

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-16

a=ptime:20

a=maxptime:140

a=sendrecv

Did someone else figure out how to fix this?

2

You need to correctly configure your external address and local networks.

(This document has not been updated for a long time, but should still cover the general location of the settings.)

3

Hi David

Thanks for your response. Unfortunately with this auto discovery setting inbound will be interrupted after 30 seconds.

When I change local address to a wider one like 0.0.0.0/1 Inbound will work but oubound calls will drop after 30 seconds and any calls between PBX extentions also will drop after 30 seconds.

This is quite strange and I can’t figure out why.

4

Setting local networks to a larger range than needed (and noting you are setting it to a range that covers half the possible IPv4 addresses!) is going to cause your original problem, not fix it. With none of the settings, Asterisk assumes that it is safe to use the actual address of the machine. Once you set them, that treatment is extended to anything matching the local networks, but otherwise gets the external address.

Getting the correct settings for local networks is something that should be easy for someone who created the LAN, but is difficult, or impossible, to automate. Getting the external address can be more difficult, but unless it is frequently changing, in which case you need a more suitable ISP, is something you should learn how to do, although, in most cases, it can be done automatically, and I think FreePBX tries to do that.

Unfortunately, you don’t seem to have access to the fallback position, of letting the ITSP discover the address from your outgoing media, either because they don’t have that capability, or because you aren’t actually sending any outbound media.

Note that you often need multiple local networks values, but the person who manages your LAN should know all of these.

(In fact 0.0.0.0/1 fails to cover the one local network we can tell that you have, as 172 is greater than 128, so its first bit is 1, but your pattern only matches cases with the first bit 0.)

5

Hi David

I’m managing the local network and the settings I added where correct 172.23.0.0/22 and that one is also auto completing when pushing Detect Network Settings.

As I indicated with this setting the inbound calls are ended up after 30 seconds. If you want I can add a packet capture of a such a drop call after 30 seconds.

Strange part is that with wider local network inbound will work but outbound will drop after 30 seconds.

Hope I was clear enough with what I had explained.

6

Are you sure that it is 30 seconds. That does sound possible, as it is often used as a timeout for lack of RTP, which is, effectively, what your service provider is saying will be the problem.

Logs are always be useful, but be careful not to over-redact them; we need to understand which addresses are different, whether they are public or private, and what they represent.

You should be checking that the Via and Contact lines, in the outgoing INVITE, contain the public address, and so does the c= line, in the SDP.

7

test.tgz (1.1 KB)

Please see in this capture how the call inbound call was end up if i’m adding a subnet that contain my local net in local networks field in PBX.

I also tried:

  1. Expected configuration 172.23.0.0/22
  2. Recommended in forum 0.0.0.0/1 with this inbound will work but outbound and interior calls will be dropped after 30 seconds
  3. 0.0.0.0/1 and 127.0.0.0/1 that basically will cover the full ipv4 again inbound issue
8

Neither options 2 nor 3 make any sense. Where did you see option 2 recommended?

Line 32 of your log, and subsequent equivalent lines contains the wrong address after received=. That indicates that you have SIP ALG enabled in your router. This should be turned off as it is, in most cases, broken, and should not be necessary with Asterisk, as Asterisk is able to set correct external addresses.

In your log, lines 47, 59, etc. and line 78, etc., contain the wrong address, which comes back to incorrect local networks (if you are using options 3, that would be the cause).

The wrong address in 47, 59, etc. means that the provider’s ACK will not know how to reach you, which will cause the call to break at the 32 second (not 30) mark.

Line 371 shows a response to a request, relating to the call, which has never been logged as sent. I don’t understand what went wrong there.

There are no timestamps, an no logging of Asterisk’s actions, so I can’t see exactly when the BYE was sent, or why, but I would expect Asterisk to abort the call at 32 seconds, because the ACK has been sent to an address, on your LAN, is not reachable from the provider.

9

Hi David

For point2 the forum link is DIDWW calls issue call close after 30s with NAT FreePBX (wrong link… looking for proper one)

This capture was made with option 1 enabled.

Unfortunately asterisk full log is over 10Mb and I can’t attach here. If you agree I can add it on a file transfer server and provide you the link

10

Correct link for point 2 PJSIP Inbound calls hangs up exactly after 30 seconds

11

I managed to truncate full log to a size to add

Test call is arround Line 2024705: From: sip:[email protected];tag=22-4AB5A209-69232982000BD119-022F06C0

12

It still doesn’t think that it is calling a public address.

[2025-11-23 14:28:21] VERBOSE[26786] res_pjsip_logger.c: <--- Transmitting SIP request (1270 bytes) to UDP:46.19.210.19:5060 --->
INVITE sip:[email protected]:5060;user=phone SIP/2.0^M
Via: SIP/2.0/UDP 172.23.3.105:5060;rport;branch=z9hG4bKPjba8c8a2d-fd97-49f8-97f4-57b315c99f2b^M

This is also wrong, and as the provider aborts at 32 seconds is probably the cause, atlhough I suspect it is is re-INVITE transaction that hasn’t got through. (I’m not sure how they found the right address to which to send BYE.)

Contact: <sip:[email protected]:5060>^M

This will have caused them problems sending media to you:

c=IN IP4 172.23.3.105^M

Are you, by any chance, using a customised transport, in which case you will have to manually set the external address and local networks, in the custom .conf file.

(Incidentally the first thing I did was to delete all the debug lines, to reduce the noise.)

13

I had only one reference in custom file for transport:

0.0.0.0-udp
symmetric_transport=true

I had removed them, restart asterisk with fwconsole restart but still same issue with proper local network and external_media_address and external_signaling_address in pjsip.transports.conf

Thanks

14

I meant type=transport, which you say you haven’t customised.

I think you need to use the CLI commands to check what local networks setting is actually being used.

15

Hi David

Do you mean this:

pjsip show transport 0.0.0.0-udp

Transport: <TransportId…> <BindAddress…>

Transport: 0.0.0.0-udp udp 3 96 0.0.0.0:5060

ParameterName : ParameterValue

allow_reload : false
allow_wildcard_certs : No
async_operations : 1
bind : 0.0.0.0:5060
ca_list_file :
ca_list_path :
cert_file :
cipher :
cos : 3
domain :
external_media_address : 70.98.240.130
external_signaling_address : 70.98.240.130
external_signaling_port : 5060
local_net : 172.23.0.0/255.255.252.0
method : unspecified
password :
priv_key_file :
protocol : udp
require_client_cert : No
symmetric_transport : true
tos : 96
verify_client : No
verify_server : No
websocket_write_timeout : 100

16

While what @david55 is pointing out is true, you’re still sending them a private IP address in the SDP which is going to cause audio issues, however, that’s the not cause of the issue here.

DIDWW is never ACKing the 200 OK from your system. Now either your 200 OK isn’t making it back to DIDWW or the ACK from DIDWW isn’t making it back to the PBX. I’m going with it is the former since DIDWW is re-transmitting the same INVITE over and over and over again before they give up and send a BYE.

These are two different issues of local IPs being used AND incoming calls not being setup correctly with DIDWW having to re-transmit their INVITE over and over until they give up. Could they be releated? Possible but just fixing the local IP problem might not solve this.

17

Hi @BlazeStudios

By local IP you mean local network? If yes it is setup correctly. But issue still persist for inbound calls.

This issue remain why my PBX send this private ip if it has configuration for external ip address and also External IP Address and External Signaling Port setup. My expectation was to use this for any external destination.

18

He’s also still sending a private address in the Contact header, which is the cause of the issue, as the ACK will be sent to that address. What I don’t quite understand is why the BYE is reaching him, as that should also be sent to the same address. Maybe the provider sends it to both addresses, to cover this sort of problem.

The CLI output looks good, so I don’t understand why it is not using the public address.

19

Have full Asterisk restarts been done? I think some transport changes won’t take on a simple reload.

20

I did restart, also vm reboot