This happened Friday after upgrading from version 13 to 14.0.13.28.
PBX will automatically transfer our calls to the answering service at 5 pm.
Now when the calls are transferred there is no audio either direction. The call rings the answering service. They answer but the caller cannot hear them and they cannot hear the caller.
Nothing has changed with our SIP service, router, or phone system otherwise.
Any suggestions would be appreciated,
-Adam
This is a typical symptom of no RTP port forwarding rules at the Router/Firewall.
I don’t mind trying that since I’m at a total loss.
Please keep in mind, I would agree except this only happens when inbound calls are transferred to and external number.
We have no audio issues with normal inbound or outbound calls.
Also, we didn’t have this issue prior to the update.
Hope that helps,
-Adam
This might be a good time to turn on SIP DEBUG and see what the RTP traffic is doing. There are lots of possible culprits on the RTP side of the call. One of the more common is a misconfiguration on the router. I had a similar problem once and it was because the audio was getting sent out through the same trunk that it came in on and the audio was getting lost at my provider. I set up a second trunk (outbound only, to a different provider) to handle this specific case and it helped. While I doubt that this is your problem, it highlights the “5 balls in the air” nature of debugging RTP traffic.
https://wiki.freepbx.org/display/SUP/Providing+Great+Debug is always a great place to start.
This has been resolved.
We used Virtual Extensions with FollowMe to route calls to the answering service.
Changed this to Misc. Destinations and it works.
Funny thing is using Misc. Dest. was our preferred method when we used TrixBox, but for some reason it didn’t work in FreePBX in the prior version and we had to use FollowMe. Now in 14 we have gone back to our preferred method.
I know it doesn’t make sense.
If anyone has another/better way to do the same action I’m open to it. I like learning and finding other ways/better ways to do the same action.
Thanks for the replys,
-Adam
If you’re a faithful follower of the forums, you’d recognize this. We had a flurry of problem reports where one would work, but not the other. I don’t remember that anyone ever got a real handle on what the problem was (or is).
This issue is happening this evening.
It worked during testing earlier today, but now it’s doing the same thing . The call is connected but no audio can be hear by either party.
I thought that perhaps, for some reason, my time conditions were causing it tonight, but setting the Inbound Route straight to the Misc. Destination doesn’t help.
Back to square 1.
Please try this test (and possible workaround):
Create an Announcement, e.g. “Please wait while your call is connected.” and route that to your Misc Destination. Then, route your Time Condition (or the Inbound Route directly) to the Announcement.
If there is a problem with RTP port forwarding, this will cover it up by sending audio to the caller before the outbound leg is connected. If it doesn’t fix the problem, it will provide useful troubleshooting info (does the caller hear the announcement, does the caller hear ringback tone from the answering service).
Read this post and do the originate test. SIP Port Forwarding
If you don’t hear the echo, then revisit your RTP port forwarding rules.
Stewart1,
I’m going to try this and will report back. I’ve got my fingers crossed.
Igaetz,
We’ve had a firewall rule allowing all traffic from the SIP providers SBC.
Stewart1,
In our testing your idea worked.
I took a ringing.wav file and and used 1 ring from it as the announcement. After the announcment plays the call is transferred to the Misc. Destination.
The real test will be at 5 pm when all of our DID’s roll over.
Thanks,
-Adam
So far everything is working.
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.