[FreePBX 17 / Asterisk 20] — Call drops after 10 seconds (ACK / RTP issue) — Keyyo SIP trunk behind Freebox (France)

Hello everyone :slightly_smiling_face:

I’m facing a persistent issue with FreePBX 17 (Asterisk 20.6.0) running on Debian 12 (fresh install using the official sng_freepbx_debian_install script).

Everything works fine — registration is OK, audio is OK, inbound and outbound calls both work — except that every call gets disconnected exactly after 10 seconds.

🧠 Environment details:

FreePBX 17 (Asterisk 20.6.0)

Debian 12 VM under Unraid

Router: Freebox (France) — SIP ALG disabled

Operator: Keyyo (keyyo.net) SIP trunk

NAT: enabled

Public IP is correctly set in FreePBX SIP settings

RTP ports 10000–10100 forwarded to the PBX VM

PJSIP only (chan_sip disabled)

RTP Keepalive: 20

Outbound Proxy: sip:keyyo.net:5060;lr

Registration OK (Registered (server 'sip:keyyo.net:5060'))

:puzzle_piece: Problem description:

  • I can call out from my SIP phone to a mobile (06)

  • Audio works both ways for ~10 seconds

  • Then the mobile side hangs up automatically, while the SIP phone still stays “in call” for a few seconds before dropping

  • If I call the SIP line from the mobile, the same happens in reverse (call drops at 10s)

Log snippet (pjsip set logger on):

<— Received SIP request (BYE) from ‘sip:keyyo.net:5060’ —>
BYE sip:[email protected]:5060 SIP/2.0
Reason: SIP;cause=200;text=“Call completed elsewhere”

Asterisk seems to receive a BYE from Keyyo after 10s, possibly due to a missing or misrouted ACK.

I have also noticed in the logs that the ACK or RTP path may not always follow the same route as the INVITE.

:gear: Tried so far:

:white_check_mark: Disabled SIP ALG on my Freebox
:white_check_mark: Set NAT external address (public IP) and local networks
:white_check_mark: Forwarded UDP 5060 and 10000–10100
:white_check_mark: Added outbound proxy sip:keyyo.net:5060;lr
:white_check_mark: Tried “Direct Media = No”
:white_check_mark: Restarted Asterisk multiple times
:white_check_mark: Recreated the trunk from scratch

🧩 PJSIP trunk configuration summary:

Username: id_sip
SIP Server: keyyo.net
From User: id_sip
From Domain: keyyo.net
Outbound Proxy: sip:keyyo.net:5060;lr
Context: from-trunk
Qualify Frequency: 60
Support Path: Yes
RTP Keepalive: 20
Direct Media: No

I don’t understand what could be causing this kind of problem because I tested version 15 of FreePBX and I didn’t have this issue. :face_with_diagonal_mouth:

Why do you have an outbound proxy configured? (I don’t think this is your problem, though.)

Has this been garbled by the forum. If you need a proxy, you will need a backslash before the “;”, in the actual .conf file, although it might not be included in console output.

This doesn’t make sense. I think it is reporting normal clearing, with an inappropriate human readable message. 200 is successful answer.

Also the timeout for a missing ACK is 32 seconds, not 10 seconds.

SIP is designed to be able to cut out the middle man. If there are no Record Route headers on the 200 OK, the ACK should be sent to the Contact address from the Record Route. Media should be sent to the address in the c= line in the SDP.

The initial address for the INVITE may be a load balancer, but once the call is accepted that can drop out. As well as the effect of load balancing, they may have a separate machine that only handles media, or may route media directly to their upstream provider.

It looks to me as though you are behind NAT, but your configuration is missing the External Address and Local Networks needed to handle that cleanly.

This is a setting on the router, not FreePBX, so you can’t have literally done this. Failure to disable SIP ALG may explain the 192.168…. address in the request URI on the BYE.

I recreated the trunk and left it at the default settings; I just entered my credentials, and everything is working now.

ChatGPT helped me with a good portion of it, but it created problems where none existed. It just goes to show how stupid AI can still be. :joy:

Did ChatGPT suggest that? It doesn’t cause major problems, but slightly impairs security and makes it more likely that the RTP port chosen will conflict with that used by a previous call that did not get torn down correctly.

Also, if you didn’t change RTP Port Ranges in Asterisk SIP Settings to match, it will cause most trunk-to-trunk calls (e.g., Misc Destination) to fail.

Yes, it was ChatGPT who told me that, but I understand better now, thank you very much.

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