Inbound calls dropped at 30 seconds PBX requesting "BYE"

Good morning all! I have a PBX that has been running flawlessly for over a month. Last Thursday, I received notice that suddenly, incoming calls are getting dropped after ~30 seconds. I have looked and looked for a solution over the last week and still cant find a resolution. Many of the posts offer great suggestions, however, none seem to get my system back up and working.

Current PBX Version: 14.0.11
Current System Version: 12.7.6-1904-1.sng7 (up to date)
Phones: Sangoma S705’s and S500’s

Nothing on my network has changed, no hardware changes, or software updates.
I have a packet capture that I have analyzed and it looks like the PBX is sending out a REQUEST: ACK sip:[email protected]:port to the extension, but i never see a response come back to the PBX from the extension. I don’t know if this is normal behavior but found it interesting.
Were not experiencing any latency or jitter, sound quality is great, outbound and internal calls work great, just calls coming in are having the issue.

I have the pcap file but 'm not sure how to upload it other than changing the extension from .pcap to .tzg or some approved extension.
I’m hoping that someone a little more experienced with FreePBX and Wireshark could look it over and offer a magical fix!

This is a NAT issue. When the PBX is sending the 200 OK to tell the provider the call was answered it expects a ACK from the provider. If it doesn’t get that then it doesn’t start to flow media back out to the provider because it doesn’t thing the call is completed. It will re-transmit the 200 OK wanting a reply for it. If Asterisk finds that a channel isn’t flowing RTP after 30 seconds it will drop the call.

Outbound calls work fine because outbound traffic establishes the connection and the NAT/firewall let the traffic flow fine.

If you’re on a dynamic IP, check that your public IP address matches what you see in Asterisk SIP Settings -> External Address. If you change it, restart (not just reload) Asterisk.

Otherwise, rename your .pcap to .tgz and upload it.

It is a static IP from our ISP. The setup is eth0 is our internal network where the phones reside and provide them access to the PBX. Our external route to the SIP trunk provider is through eth1, and is only allowed to connect to the specific gateway address from the provider. It still wouldn’t let me upload it so I’ll share it through a Google Drive link.

Thanks for all the help, this PBX is our production system at our school and the principal, faculty and staff really want it working again soon! :wink:

Looking at this, it is exactly what I said in my initial reply to you. This is a NAT issue.

It’s doing exactly what I described. It’s re-transmitting the 200 OK because it’s not getting the ACK reply back and then sending the BYE because it never starts the RTP flow on the channel.

You’ll also notice that the BYE gets the proper 200 OK reply immediately. That is due to the BYE being its own request. It’s not part of the original INVITE dialog which means the PBX is generating it and sending it out (just like how your outbound calls work).

Awesome! I’ve forwarded that information to our provider. Quick question, If I’m understanding correctly, you say that the PBX drops the call because there isn’t an active audio stream but we do have good two-way audio during those few seconds after the call is answered. With that in mind, is there any other things that I should look into while I wait on the provider to reply? I’m completely stumped, like I said, nothing has changed on my side so I’m not sure where else to look.

Again, thank you very much for the assistance! You are a life saver and I appreciate it VERY much! They might even let me come back to work next week! haha…

If there is audio then the BYE is due to the re-transmission timeout/limit being hit.

I don’t suppose there is a way to disable that time out temporarily is there?

I suspect that this is the same problem as
Migrating sip to pjsip trunk problem, incoming call drops after 32 seconds
Dreaded "incoming calls drop after 30 seconds"
where a quirk in pjsip interacts badly with some SIP proxies.

The incoming INVITE from NTS (packet 3240) gets a 200 OK response (packet 3419), which looks perfectly ok from an RFC point of view. However, the lack of a user part in the Contact header causes some proxies to parse it incorrectly, so that the ACK is not sent or is sent to an incorrect address.

If you can try a chan_sip trunk, it may be a quick fix. If you are already using chan_sip, please post trunk settings (mask usernames, passwords, etc.)

I don’t have a plausible explanation why this used to work and now fails, other than a hardware or software change at the provider end.

If chan_sip doesn’t help, post details of your router/firewall setup.

Ok, I have tried a Chan_sip extension that i created the other day and get the same result. I also get the same result if I call in and loop through the IVR by entering invalid responses making it stay in a loop until the 30 seconds disconnects me!

Firewall Info:

Trunk Info:

Thanks again!!

OK, I took a closer look at your original capture.

Packet 7765 shows a chan_sip REGISTER request, which got a successful response in the following packet. The request and response show port 5160 in the Contact headers, as they should.

However, the INVITE for the failed call came in to port 5060 (pjsip), so you either have a still active registration on port 5060 from pjsip, or you configured NTS (on their portal) to send your calls to port 5060. Either way, the call came in to port 5060, was processed by pjsip, NTS didn’t like the Contact header in the 200 so the call failed.

Well if this is set with PJSIP listening on 5060, I’d be more concerned as to why it returned a 100 Trying and a 200 OK back to the provider. Because that means something on PJSIP accepted that call.

If this was going to PJSIP incorrectly and there is no PJSIP endpoint that INVITE should have resulted in an error code reply not a provisional reply.

@tobywimberley You don’t have Allow SIP Guests or Anonymous enabled in the Asterisk SIP settings do you? Because that’s bad.

He does have Guests enabled. In fact, you can see that the INVITE sent in packet 7985 from a hacker in Iceland was processed with the ‘not in service’ message.

Event: Newchannel
Privilege: call,all
Channel: PJSIP/anonymous-00001a40
ChannelState: 4
ChannelStateDesc: Ring
CallerIDNum: 1234#1234
CallerIDName: <unknown>
ConnectedLineNum: <unknown>
ConnectedLineName: <unknown>
Language: en
Context: from-sip-external
Exten: 9011441157940267
Priority: 1
Uniqueid: 1558537975.7784
Linkedid: 1558537975.7784

Yes, unfortunately, if I disable either my calls don’t come through at all. The caller just gets a busy signal. The provider is supposed to be looking into that too. The account shows to be sending in CID but apparently not.

Change you context to from-trunk-pai-rpid or something. I’m on my phone on the train at the moment.

I hope that we don’t have to get the provider involved. Try these steps:

In your chan_sip trunk, PEER Details, use

On the Incoming tab, remove USER Context (leave it blank)

At the end of the Register String, add a / followed by your 10-digit main number, so it looks similar to
8062345678:[email protected]/8062345678
(but with the actual data for your account).

Remove registration on the pjsip trunk (set Registration to None or delete the trunk altogether).

Restart Asterisk, confirm that the chan_sip trunk is registered and try an incoming call. If it fails, report what, if anything, appears in the Asterisk log. If nothing, report whether a packet capture shows the incoming INVITE, what the caller hears and what gets logged at the provider.

Possibly related: at least one extension seems to be using g729. Is that intentional?

I’d like to thank everyone for the superb assistance in finding a solution to this issue. As it turns out, the ISP made some system changes to their side that made their system incompatible with pjsip. After looking at some more trace files, i noticed that the provider was responding to the ACK request but over port 5060 and not 5160. I simply disabled pjsip, reconfigured the endpoints and now everything is flowing as it should be!!!

Now to figure out the allow anon and guest issue!! :wink:

Again, thank you so much for the help!!! People like you all really make life for me so much easier!!!

Toby Wimberley

I just want to clarify this is incorrect. This was probably more an issue with destination ports than an incompatibility with PJSIP.

FreePBX, by default now, binds 5060 to PJSIP and 5160 to Chan_SIP. While your Chan_SIP trunk was registering and telling them you’re at IP:5160 they were most likely ignoring the port and sending calls to IP:5060 which would have caused PJSIP to respond to the INVITEs.

Just understand there is a difference between misconfiguration and incompatibility. This was the former not the latter.

1 Like

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