Hi all.
I’m running Freepbx 14.0.16.4 on Raspberry PI 3b+
Asterisk version is 13.29.2
I use an OVH SIP account on port 5060.
Locally I use an AASTRA 57i device.
Sporadically, on incoming calls, I got an issue where I can hear the caller, but the caller can’t hear me.
When this occur, the caller calls again and it works.
Any idea ?
Regards,
Laurent.
Try disabling SIP ALG in your router settings.
Also check that your router/firewall is set to forward the RTP port range (default is UDP 10000-20000) to the PBX.
If you still have trouble, capture traffic with tcpdump to see whether RTP is going out to the correct IP address and port.
My routeur is
Front : french box named “Freebox” with all necessary ports forwarded
Then a pfsense
Don’t have SIP ALG setting… What does it means ?.
Assuming that you don’t have the sipproxd package in pfsense (you shouldn’t), then there is no SIP ALG, so you are good there.
Please confirm that UDP ports 10000-20000 (or whatever you have the RTP port range set to) are forwarded in the Freebox to pfSense and are forwarded in pfSense to the PBX.
Approximately what percentage of inbound calls fail? If it’s reasonably high, you could turn on sip debug, call in from your mobile a few times until a failure, paste the Asterisk log for the bad call at pastebin.freepbx.org and post the link here.
If it’s infrequent, about how often do you receive a problematic call?
RTP settings in PABX are 30000 - 40000
I have double-checked that UDP ports are all correctly forwarded (see below)
It is difficult to give a percentage… Sometimes got it twice for the same caller, and sometimes no issue for the 10 next incoming calls.
It appears that you have a complex setup, a queue (1160) pointing to a ring group (600) with 6 extensions (4 SIP, 1 forwarded to a mobile, 1 IAX). Is that correct?
This results in a log more than 1000 lines. If we can’t find the trouble easily, can you temporarily route a DID directly to an extension, to see whether the problem is related to the trunk or to the complex call flow?
A few questions, based on a brief look at the log:
It appears that the queue is playing ‘aslog’ music, but the ring group is playing ‘ring’, which may override that. Which does a caller normally hear, while waiting for an agent to answer? On a failed call (where he didn’t hear the agent), did he still hear the music or ringing? If so, that would indicate that the trouble is related to the call flow (or possibly the extension), rather than a trunking or networking problem.
The username 0033429XXXXXX looks like a phone number. Is it a number on your system? The number called 0473XXXXXX is different; do you have multiple DIDs? If so, do you have a spare one that could be used for testing?
It appears that ext. 1010 is forwarded to a mobile 0603XXXXXX, but that call failed because no Outbound Route was matched. I’m guessing that the route with that match pattern has something in the CallerID field, which didn’t match the ‘anonymous’ incoming caller ID. Possibly, this interfered with extension 1009.
The INVITE to extension 1009 had to be sent 3 times before it got a reply. Is there something unusual in the network path that may have caused this (VPN, weak Wi-Fi, etc.)? Otherwise, this may indicate a problem with the Aastra or its configuration – do you have the trouble when answering from other devices?
A usual way to troubleshoot this sort of problem is to run tcpdump continuously (into a ring buffer of capture files). When the trouble occurs, you can look at the RTP to the trunk to see whether it contains voice and was sent to the proper IP address and port. However, I hesitate to do this on a Pi, for fear of wearing out the SD card. Does your Pi have other accessible storage (SSD, hard drive, network share)?
Well.
Quite complicated.
In a first time, because I saw that all numbers were visible by everyone, I decided to replace all numbers by a slightly modified number, it is why you have strange DID.
Then, on this case, I’m also facing another trouble with my SPA3102 that disconnect randomly just after dialing output number, so it is why the “BYE” signal is sent and the line is hung up.
In fact, my settings are…
If I predial “0”, I can dialout via OVH SIP trunk
If I predial “3”, I can dialout via SPA3102/Freebox
If I predial “2”, I can dialout via USB dongle
Concerning phone devices…
Concerning incoming calls…
Each incoming numbers are enabled/disabled via global calendar, so when out of working hours/days, caller can ear a message that all services are closed.
Each incoming numbers are again enabled/disabled via specific calendar, so when out of working hours specifically for the service the incoming call is accepted or a dedicated message is played.
When an incoming call is accepted, each input number gives a dedicated music on hold, and using ring group “600” makes all the devices ringing.
If the ringing time is too long, I have a SVI on some lines where the caller can ear the working hours, and with a SVI it can repeat the message. After a while the call is terminated.
The first device that pick the call can speak with the caller, and all other devices stop ringing.
On the extensions, a CID prefixe is added so I know where from the incoming call is coming from.
So I have 2 issues :
One concern my SPA3102, but this is not the purpose of this topic (except is you can help me)
Second is that sometimes the caller can’t ear me, but I can ear him.
(I was not able to reproduce the issue during my last 40 incoming tests calls).
I can see with Google that this could comes from a RingAll ring group…
Im really not sure how port forwarding the RTP ports is a factor here. The OP can hear the caller so clearly the incoming RTP is being routed the correct way. This is the outbound audio not being heard. That means the PBX is sending the packets. So what is stopping the outbound?
Inbound and outbound RTP are not symmetrical. Just because you change the local definition of the RTP ports at the host end doesn’t mean your provider is going to do the same. It’s possible that the traffic is getting sent by you to a port at your provider that doesn’t accept RTP traffic. Of course, there are all of the rest of the “standard suspects” including firewalls, NAT rules, and just misconfigurations of the outbound call channel.
OK, so if you want to troubleshoot this we need to rig some kind of continuous capture that we can look at after a failure. What SD card do you have in your Pi? Does it have access to other storage (USB, network)? Can you capture the traffic on a PC or server (via a switch with port monitoring / mirroring)? Or perhaps on pfSense; I know almost nothing about it but it likely has a way to send captured packets to a PC or server that could record them. However, if you know that on the failed calls, the caller heard the music but it went silent when you answered, this is most likely not a network issue and we can look elsewhere.
I’m curious why you changed the RTP ports from 10000-20000 to 30000-40000. If this was to get around a similar problem, perhaps it didn’t fix it completely.
I don’t believe that is the case here, because the INVITE was sent 3 times and there was only 1 response. Although the ring group can cause delays, I wouldn’t expect the replies from the phone to be completely lost.
The SPA3102 can be configured to disconnect on a drop in loop current, detecting the disconnect tone pattern, or long silence. The syslog feature should allow you to see the cause, and it may be possible to adjust the settings to make it less aggressive about hanging up. It is a shame that Free no longer permits connection by SIP.
Maybe I saw it in a forum a long time ago… If you google RTP port range, there are so many ranges !
I do not understand why it needs 3 INVITE…
I just tested to change codecs in the AASTRA, and found that G722 can operate…
Logs are now
Capabilities: us - (alaw|g729|gsm|g726|g722), peer - audio=(g722)/video=(nothing)/text=(nothing), combined - (g722)
Non-codec capabilities (dtmf): us - 0x0 (nothing), peer - 0x0 (nothing), combined - 0x0 (nothing)
I will check if it do the same with a SIP account on my computer using Zoiper for Windows
SPA3102 is so boring to do the settings.
It takes to me so long time to make it working (so many hours spent to adjust the settings and try to understand the role of each of them).
i have a syslog where full logs are stored for the SPA3102, but I still do not understand why it drops sometimes the outbound call.
I will investigate on this side…
I have a little 8 Gb SD card, large enought for the purpose… It is backuped to a remotely FTP server each day and each week
I did the test with Zoiper from my computer.
Only one SIP invite is needed… seem that it is the AASTRA that has something wrong.
Firmware is the last one I can get despite i have googled everywhere.
Hi !
Got a SIP log file of the issue…
https://pastebin.freepbx.org/view/b7060020
Note that
1009 : is the AASTRA extension where from I get the call when I’m at office.
1021 : is a Zoiper account on my computer, for testing only.
1027 : is a Zoiper account on my phone device, to pick-up calls when I’m out-of-office.
91.131.129.x : is the public IP of OVH (SIP account), where the call comes from.
0033428297892 : is the SIP account line number
0891890196 : is the number dialed by the caller (number associated to the OVH SIP account)
0153819322 : caller number
In the case of this log, I was trying to answer the call from 1009.
Hope you can help.
Hi !
I found why I changed the RTP ports range…
According to OVH, it must be 30000-40000
https://community.ovh.com/t/voip-telephones-derriere-nat-fortigate/16347/2
Just to clear up something here. OVH has nothing to do with YOUR RTP ports. They can’t tell you what RTP ports to use on your side. That’s not how it works. They are telling you that their RTP ports are from 30000-40000.
