Recently had some disk issues so I had to set up a “new” PBX. This weekend I was able to transfer and park normally, but I came in today to find that neither function works at all! The caller (outside) is dropped, but the line does not hang up on our side. I cannot even transfer internal calls!
The basics:
FreePBX 2.9.0.10
Asterisk 1.8
CentOS 6.2 (32 bit)
Aastra XML 2.3.1 1-beta2
Using Aastra 6757i with latest firmware.
Errors from the CLI:
WARNING[2020]: chan_sip.c:Redacted handle_response_invite: Re-invite to non-existing call leg on other UA. SIP dialog ‘Redacted’. Giving up.
I also found this in my sip_notify.conf:
; Aastra check-sync
[aastra-check-cfg]
Event=>check-sync
Content-Length=>0
; Aastra XML event
[aastra-xml]
Event=>aastra-xml
Content-Length=>0
Shouldn’t that be somewhere else as of 1.8? I get the same error whether xfering or parking. This is a complete disaster. Any help would be greatly appreciated.
You didn’t mention how you installed this system (if from a distro which one?)
Looks to me as if you have a networking issue.
Need more details.
Did you try and restore and older version to a newer one?
Apologies. Everything was done from RPMs on a clean 6.2 install. So no silly upgrading as it was all done from scratch. I did not restore any settings from a backup either.
We have not done any real testing on CentOS 6.2
I am really not sure what you have going on. Probably something simple but I would have to ask you 100 questions to get close to drilling in.
I think the problem is sip nat settings and reinvite behavior.
If you are in a huge hurry and need professional help click on the support tab above.
So upon looking more closely at my network settings I was able to find an issue in FreePBX’s SIP settings panel. For some reason (likely user error) it was set to dynamic DHCP. After entering the correct Static pubic address and local broadcast network info my Xfer feature is up and running again. Still no dice with the Parking Lot, but I’m going to take this one step at a time. I’ll run some more tests and post some additional CLI data. Looking like re-invite behavior is the culprit at this point, as NAT should be irrelevant behind the firewall.
1 - I mentioned it was a NAT issue in my first post
2 - You’re welcome