Have a strange situation where a call comes in and is answered no problem. Call is then Blind Transferred to parking lot 70 (default) and the call appears to be successfully parked, the caller can hear on hold music etc. and the BLF shows a call parked. The new recipient then dials 71 to pick up the call and it appears to be bridged in the CDR reports but neither side can hear audio then the call ends. We are on version 13.0.120.
Have pulled the logs but I cant determine what may be causing the drops.
Have you tried uninstalling and reinstalling the module? Not much more than a guess - but a 500 error would suggest some corruption somewhere. You could search the parking code for anything that triggers a 500 error.
IIRC there’s a timeout setting on parked calls - maybe check that?
Thanks for the feedback! I will take a further look and try uninstall and reinstall. The timeout is 180 seconds and the calls are dropping within 2 minutes. But i will up the time to make sure.
@cynjut After going back and forth with the provider again it appears that this is the same issue as we had with them before, their core is sending UPDATE messages which our end is not recognizing and their end is dropping the call. How can we reoslve this on our end? I have found several posts regarding it and it appears that UPDATE is not currently implemented in FreePBX but the provider is insisting that Asterisk can handle it. Can we turn it on? How do i get around this??? My client is ready to throw the box out the window…
@bksales I havent set that yet but I am curious how it would work… The error is coming from the provider end when their core tries to send an UPDATE message during the call. Our end wont accept it so it breaks down the call, the RTP stream is still going until the hang up message. Would this just force the RTP to stay open until the call terminates?
i am certainly no expert here, but i think what happens when you park a call the connection between your pbx and the carrier behaves differently than when a conversation is in progress which triggers their end to try to figure out whether the connection is still active. we used to run into this issue with some of the accounting firms we support - they would call the IRS and have to sit on hold for a very long time to speak to an agent. the recommendation to us at the time was to use the rtpkeepalive. we were using chansip trunks at the time. and it did seem to fix the problem.
@bksales I will definately give it a try, anything at this point to fix this! I am on the Asterisk forum as well to see if there is any more info on which versions of Asterisk are supporting UPDATE. Thanks for the suggestion. I will see how it goes.
I found this article on voip-info saying that canreinvite=update would use UPDATE instead of re-invite. it also says that it should now be called directmedia=____ instead…
We implemented the directmedia=update line but nothing changed, we are still getting dropped calls. How can i find out for certain if Asterisk and/or FreePBX can implement the use of UPDATE messages? I am happy to pay for support but no one is giving me a for certain answer about whether this is possible or not.
i just tested our system - set the parking time out 180 called, parked a call, let it sit on park for 2 min 30 and then dialed 71 to pick it up and it worked. so here is another thought. is your pbx behind an external firewall? or is it directly connected to the internet? if it is behind a firewall/router, take a look at the udp session timers in the router. without rtp traffic the router may be closing your udp session (and this is where the rtpkeepalive does help). if you are connected to the public internet, you might want to set up an account with a different itsp and do some testing. i think you are wasting your time on the UPDATE stuff.
@bksales the PBX is not behind a firewall, the Provider (our ISP) has a direct link modem in the office that does not provide internet access but rather a direct connection to their service. I wouldnt be fixating on the UPDATE method but this is what the provider is insisting is the issue. They have adamantly stated that Asterisk is capable of accepting UPDATE even though i have conversed with folks on the Asterisk forum and have googled until I’m blue in the face i cannot find anything stating that UPDATE is fully support. The provider has Asterisk 1.4 on their IOT list (version 1.4) from back in 2012 so that is why we went with FreePBX, which says to me that they should have identified this issue when they were testing. I cannot see why V11 would have regressed any functionality. I understand that some aspects of UPDATE are support with outgoing messages to phones and some IAX functionality but not incoming. Sorry for the rant but the provider isnt allowing my client out of their SIP service contract so i am stuck trying to figure out a work around.
@bksales thanks for the suggestion, there is already a Cisco 880 from the ISP in place as an SBC. They did some long testing today, they put in a header manipulation rule to eliminate the Update message but the results were the same so they did a media capture of a call. What they are hearing is the call being parked, hold music playing, they hear the beep of the reconnect but then it goes silent. Apparently the termination is happening when one end hangs up the phone. What I cannot figure out for the life of me is why when I test it with another SIP trunk it all works correctly. We can call, park, pick up etc, no problem. When I use this main trunk I can’t get it to work. The only other variable is that the calls that are being dropped are originating from another subscriber to the same ISP. If it’s outside their network then there is not problem. I can call from my cell and park and pick up, no problem. It all points to the provider but they are insisting it’s on our end. I don’t what else to try to demonstrate the issue.