I’m running into a bit of an issue with one of our end users and I was hoping someone might have a suggestion or work around. I am using FreePBX 2.11.0.38 with Asterisk 11.10.2 and we connect all of our end users to it either via Trunk (PBXes) or Extensions (Direct Lines). The FreePBX is on a public IP and not behind a NAT.
I have an end user who is connected to the FreePBX via a Trunk and they are having some odd issues. First, all inbound calls are working without issue. They can be completed, no audio issues in either direction and stay up without any problems until properly disconnected. The issue we are seeing is with outbound calls and it’s a bit weird to me.
When an outbound call is made the call stays up for about 120 seconds and then is dropped by the FreePBX. However, if they make the same call again within 30-60 seconds of the drop the call stays up without issue for as long as needed. If they wait anywhere from 5 to 10 minutes later to make the call or try to make another call at that time, the same issue happens.
Now I can see why it is happening. The PBX connecting to the FreePBX system is on a 1-to-1 NAT (Public to Private) and around 90 seconds into the call I can see the FreePBX sending a new INVITE to the PBX except it’s trying to hit a different port and the PBX never responds causing the FreePBX system to drop the call due to timeout. What is confusing me is the fact the call can be re-established with an immediate call back and everything is fine. FreePBX talks to the PBX always on the proper ports, so yeah I’m a bit at a stump. Here’s an snippet from a call that fails:
xx.xxx.100.249 - FreePBX
xxx.xx.84.104 - End User PBX Public IP
xx.x.7.104 - End User PBX Private IP
--- Snip showing the FreePBX telling the PBX the call is connected ---
U 2014/07/26 22:02:44.053247 xx.xxx.100.249:5082 -> xxx.xx.84.104:35060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP xx.x.7.104:35060;branch=z9hG4bK000030ca;received=xxx.xx.84.104;rport=35060.
From: "Line" <sip:[email protected]>;tag=21835.
To: sip:[email protected];tag=as05df082d.
Call-ID: [email protected].
CSeq: 1 INVITE.
Server: FPBX-2.11.0(11.10.2).
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE.
Supported: replaces, timer.
Session-Expires: 180;refresher=uas.
Contact: <sip:[email protected]:5060>.
Content-Type: application/sdp.
Require: timer.
Content-Length: 238.
.
v=0.
o=root 674198973 674198973 IN IP4 xx.xxx.100.249.
s=Asterisk PBX 11.10.2.
c=IN IP4 xx.xxx.100.249.
t=0 0.
m=audio 12064 RTP/AVP 0 101.
a=rtpmap:0 PCMU/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:20.
a=sendrecv.
--- Snip showing the PBX telling the FreePBX ACK to the 200 OK ---
U 2014/07/26 22:02:44.331426 xxx.xx.84.104:35060 -> xx.xxx.100.249:5060
ACK sip:[email protected]:5060 SIP/2.0.
Via: SIP/2.0/UDP xx.x.7.104:35060;branch=z9hG4bK0000259f;rport.
Max-Forwards: 70.
To: sip:[email protected];tag=as05df082d.
From: "Line" <sip:[email protected]>;tag=21835.
Call-ID: [email protected].
CSeq: 1 ACK.
Content-Length: 0.
.
--- Snip showing about 90 seconds later the FreePBX trying to send an INVITE to the PBX but now using a different port ---
U 2014/07/26 22:04:07.388011 xx.xxx.100.249:5060 -> xxx.xx.84.104:1041
INVITE sip:[email protected]:35060 SIP/2.0.
Via: SIP/2.0/UDP xx.xxx.100.249:5060;branch=z9hG4bK74f08508;rport.
Max-Forwards: 70.
From: sip:[email protected];tag=as05df082d.
To: "Line" <sip:[email protected]>;tag=21835.
Contact: <sip:[email protected]:5060>.
Call-ID: [email protected].
CSeq: 102 INVITE.
User-Agent: FPBX-2.11.0(11.10.2).
Session-Expires: 180;refresher=uac.
Min-SE: 90.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE.
Supported: replaces, timer.
Content-Type: application/sdp.
Content-Length: 238.
.
v=0.
o=root 674198973 674198973 IN IP4 xx.xxx.100.249.
s=Asterisk PBX 11.10.2.
c=IN IP4 xx.xxx.100.249.
t=0 0.
m=audio 12064 RTP/AVP 0 101.
a=rtpmap:0 PCMU/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:20.
a=sendrecv.
There are at least four attempts from the FreePBX to send the INVITE before issuing the timeout.
What I’m looking for is any suggestions or ideas on how I might be able to fix this from the FreePBX side or at the server level of the FreePBX. Because while I am seeing the port on the end user’s public IP change, the private is still holding the proper port. And why does an immediate re-call stay up without these issues?! Any help or suggestions would be appreciated.