I have a client where we installed the distro of FreePBX in June. A few days ago the client called me and mentioned that for some numbers when he calls them, he hears the ringtone, but when the other party picks up he can’t hear them. This has started about a month ago. Since it is only for a few numbers. I didn’t think anything is wrong with his extension or with the phone system. I called the phone provider and mentioned it and the reply was that it is possible that the audio could be on another channel. asynchron instead of synchron.
Are there any logs I could check in FreePBX for the phone numbers to get an idea what is going on?
Logs for a call where it happens is going to be the first step: /var/log/asterisk/full
After that, you are probably going to need to tell us more about your NAT setup and your router/firewall. How your extensions and trunks are configured are also going to be important clues.
After that, SIP DEBUG is probably going to enter into the picture.
This is a failure of the RTP part of the protocol, so there are only a few places that could be messing you up.
In other words - you haven’t provided nearly enough information for us to start really helping you. Start with the logs and work your way through.
Thanks for your reply. The phone provider can replicate the problem. They tell us the caller phone opens RTP port UPD 16216 invite, but the response comes from RTP UDP 54396. The phone provider still investigate the issue, but says there is a way to enable symetric RTP at the endpoint. Does this make sense?
The phone opens a connection from it to your PBX. The PBX answers that phone and processes the call. If another call needs to be placed (to your provider, for example), the PBX will open the connection to your provider. So, the phone does NOT open an RTP connection to your provider - the PBX does, and it shouldn’t make any difference to your provider that the outbound and inbound ports are different.
The problem you are having is either that your provider isn’t actually a SIP provider, or your NAT configuration is messed up. It sounds like they are expecting you to be connecting a single phone to the connection, which isn’t what you are doing.
You need to tell us how your system is connected to the Internet (NAT or not) and how you have the trunk set up to talk to your provider. If the audio is working to the PBX (a call recording would tell you) but not to the phone (the PBX will be in the middle and all audio will go through the PBX) then your extensions are set up incorrectly. Also, firewall performance, and even manufacturer, are important parts of this.
One-way audio, even in both directions, is almost always a NAT problem, if the one-way audio is both directions.
Now, your problem is also specific to certain numbers. The call path for your system is always from your server to the provider, so there is no direct audio involved. It sounds to me like you’re experiencing someone, somewhere trying to do direct audio to your PBX instead of going through your provider and your end is not set up for it. If you want to allow direct-media to your PBX, you can do this, but withiout logs and SIP DEBUG output, there’s no way of knowing if this is actually the problem you are having.
Unless you start giving us some specifics, I’m afraid there’s little we can do for you. Your only option after that is to buy support from Sangoma and have them troubleshoot it.
Thanks for taking the time to reply. Much appreciated. I have the same understanding that the PBX negotiate the call and not the endpoint… Maybe the phone provider was just testing with a endpoint.
It’s a SIP trunk an yes we use NAT. I can provide you tomorrow more information how the trunk is set up. Our client is telling us about 4 weeks ago the numbers were working fine, the audio. I’m not aware that something with NAT has changed. We are talking about 5 numbers where audio from the other side is not working.
I reviewed the full log files today and I didn’t see helpful information just that the call was established.
Assuming @BlazeStudios is on the right track, you may need to use the SIP DEBUG commands on the server and place a call to the problem destination. The output should tell you how the call’s audio is being routed and give us a sense of where the problem is.
For sure, something changed. While I’m pretty sure it wasn’t here, it could be a setting that was “working but no one knows why” that needs some attention. More likely, someone upstream changed a setting and now you’re stuck with this problem.
Here are some information. I debug the sip call from the extension today. There were made two calls. The first call with no audio and the second call was fine. This is just an excerpt from the log with the RTP port. Is this the relevant part?
First call with no audio
.[1;30m > .[0m0x7f5ec805a200 – Strict RTP learning after remote address set to: 192.168.14.108:3000
.[Kphonesystem*CLI>
.[0K.[1;30m > .[0m0x7f5ed00105b0 – Strict RTP learning after remote address set to: 95.128.80.5:8332
.[Kphonesystem*CLI>
.[0K.[1;30m > .[0m0x7f5ed00105b0 – Strict RTP learning after remote address set to: 95.128.80.5:42886
.[Kphonesystem*CLI>
.[0K.[1;30m > .[0m0x7f5ec805a200 – Strict RTP switching to RTP target address 192.168.14.108:3000 as source
.[Kphonesystem*CLI>
.[0K.[1;30m > .[0m0x7f5ed00105b0 – Strict RTP learning after remote address set to: 0.0.0.0:8332
.[Kphonesystem*CLI>
.[0K.[1;30m > .[0m0x7f5ed00105b0 – Strict RTP learning after remote address set to: 95.128.80.5:42888