Inbound call from SIP drops as soon as the destination extension answers

I have a SIP connection from VoipVoip that has a regular phone number assigned to it. If I place an outbound call via that line, it routes just fine (I created a temporary outbound route to test) and stays connected until one end purposely hangs up.

I have an inbound route configured to go directly to a specific extension that automatically answers the call coming into it (it is an analog device on an ATA). I can call this extension internally without issue. If the call comes in from the VoipVoip SIP trunk, however, as soon as it is answered it disconnects.

I pulled call information from the ‘full’ log (following instructions at, and have it here:

Some things I noticed from the log file:

At one section, I see a number of error lines:

ERROR[6592][C-00000069] res_pjsip_header_funcs.c: This function requires a PJSIP channel.

Right before it disconnects, I see this:

[2021-10-06 19:16:58] VERBOSE[6592][C-00000069] app_dial.c: Called SIP/7010
[2021-10-06 19:16:58] VERBOSE[6592][C-00000069] app_dial.c: Connected line update to SIP/VoipVoip-00000112 prevented.
[2021-10-06 19:16:58] VERBOSE[6592][C-00000069] app_dial.c: SIP/7010-00000113 is ringing
[2021-10-06 19:16:59] VERBOSE[6592][C-00000069] app_dial.c: Connected line update to SIP/VoipVoip-00000112 prevented.
[2021-10-06 19:16:59] VERBOSE[6592][C-00000069] app_dial.c: SIP/7010-00000113 answered SIP/VoipVoip-00000112
[2021-10-06 19:16:59] VERBOSE[6592][C-00000069] bridge_channel.c: Channel SIP/VoipVoip-00000112 joined ‘simple_bridge’ basic-bridge <9f979517-37ea-453c-bc24-7309e5da4d78>
[2021-10-06 19:17:05] VERBOSE[6592][C-00000069] bridge_channel.c: Channel SIP/VoipVoip-00000112 left ‘simple_bridge’ basic-bridge <9f979517-37ea-453c-bc24-7309e5da4d78>
[2021-10-06 19:17:05] VERBOSE[6592][C-00000069] app_macro.c: Spawn extension (macro-dial-one, s, 55) exited non-zero on ‘SIP/VoipVoip-00000112’ in macro ‘dial-one’
[2021-10-06 19:17:05] VERBOSE[6592][C-00000069] app_macro.c: Spawn extension (macro-exten-vm, s, 30) exited non-zero on ‘SIP/VoipVoip-00000112’ in macro ‘exten-vm’
[2021-10-06 19:17:05] VERBOSE[6592][C-00000069] pbx.c: Spawn extension (ext-local, 7010, 3) exited non-zero on ‘SIP/VoipVoip-00000112’

The ‘Connected line update…’ message caught my eye, and I did a Google search on that. Several of the references indicated that it was unrelated to the disconnect issue (I found nothing else useful in that thread, and it was rather old anyway).

This is a fairly new install of FreePBX 15, using the installer from

Other connectivity seems to be working ok, this is one that is causing me headaches now. Any help would be greatly appreciated.

It doesn’t drop immediately. There doesn’t seem to be a standard default timeout at 6 seconds, but you might find that the phone or the service is timing out at that point. It might be a lack of RTP.

You need to get the protocol logs and see which leg is sending the BYE, and whether the BYE contains additional information.

Note that chan_sip is, effectively unsupported. It gets no support from Sangoma, and the open source community is no longer actively involved.

Thanks. I will look for the logs.

The reason I say ‘drops immediately’, is that when I call from my mobile as soon as I see the line picked up by the end analog device (a telephone hybrid - this is a radio station), the call immediately disconnects - my mobile disconnects and a second or so later the hybrid disconnects. That is close enough to immediate for me :slight_smile:

Getting some slightly different results now, not sure why.

Now the call establishes, the hybrid answers, but I have no audio and the call drops in ~30 seconds or so.

I modified my firewall rules to log all traffic passing through the rules I have set up for SIP. I see the connection coming in to port UDP/5060 from the provider. I also see the stream connection coming in from source port UDP/63036 to destination port UDP/17390. These connections are all passing.

What I am finding interesting is that the UDP/5060 packet comes in to the VIP interface of the firewall cluster, but the UDP/17390 packet targets the active firewall interface itself, instead of the VIP. Is it possible that the different destination IP addresses are the problem? The traffic still transits the firewall and is permitted to the PBX with no issue.

To illustrate, in case that is not clear (addressing is not real):

I have two firewalls that are in an active/standby state.

The firewall virtual address (which is held by whatever firewall is active) is
Firewall 1 has an address on it’s physical interface of
Firewall 2 has an address on it’s physical interface of

Firewall 1 is standby
Firewall 2 is active

The UDP/5060 packet is addressed to and passes through just fine.
The UDP/17390 packet is addressed to and passes through just fine.

Sorry if that was already clear, I am a network guy by trade and sometimes tend to get in ‘the zone’ and assume everyone understands firewalls and networks and such :slight_smile:

So you have NAT and port forwarding? How is Asterisk configured to find its public address? Are you doing a pure port forward, or is the firewall manipulating the SIP or SDP?

Is the call now being terminated by Asterisk, and if so is there a message about a critical packet?

You need to use rtp set debug on to see if Asterisk is getting the RTP, and sngrep (shell commend) to see if the RTP is reaching the Asterisk machine.

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