unfortunatelly I have a random one way audio issue I can’t solve on my own. Our agents informed me that there are sometimes callers which are not able to hear them. When the agent calls the caller back it seems to work very well.
Setup:
Cisco Router (with firewall) and Cisco Switch
FreePBX Distro 13.0.163 / Asterisk 13.7.1 (within a VLAN)
Snom DECT-IP Base station and phones
At beginning of setting up the PBX I already had a ony way audio issue. I solved this by forwarding the port 5060 to the pbx and set the firewall up to open ports based on session. After this I haven’t recognized any one way audio issues with my test equipment.
In FreePBX I’ve added the static external IP address, two LANs (VLAN of PBX and VLAN of the router) and RTP Port 10001-20000 in Settings > Asterisk SIP settings. Trunks and extensions are PJSIP.
I’ve tried to follow this troubleshoot to solve the new issue: Resolving Audio Problems
Since I already done the first steps my assumption was it is a codec issue. Therefor I’ve removed all codes from Asterisk SIP settings, Trunk settings and DECT-IP base staation settings except for alaw and ulaw. This hasn’t fixed it.
Yesterday I’ve logged the PBX the hole day using this manual Collecting Debug Information and and made a tcpdump of udp traffic for some hours.
Unfortunatelly I’m not sure how to find the important informations within the million lines of log.
But I’ve used Wireshark to filter the tcpdump for traffic where packets gone to the PBX and none gone back and got three hits.
Could anyone help, how to go on from this point to determine the reason for this issue?
The settings for SIP and the settings for PJ-SIP are spread out over three tabs. Make sure that you’ve set up all of the PJ-SIP options correctly as well as the Chan-SIP settings.
Since you are only allowing 10000-20000 for extablished calls, incoming calls are going to be a problem (they aren’t established since there was no outgoing SYN packet). From the gateway router, forward UDP ports 10000-20000 to your PBX. This will allow the connections of externally established sessions through to contact the PBX. Even though you’ve configured Asterisk to use 10001-20000, opening the entire range (10000-20000) and forwarding them to Asterisk should help.
It would be nice to see the results of just those three connections.
Normally, you can safely choose one or the other if you want to further limit your choices. If you are running a local call center, for example, you should use A-Law if you are outside the United States, and U-Law if in. If you receive many calls from both, then using both is fine.
@bksales The router is a Cisco 886VA. (IOS 15.4(3)M5)
@cynjut Unfortunatelly I’ve no access to the maschine now, I’ll post the three connections tomorrow.
I’ve double checked the settings several times but I’ll repeat this tomorrow, too. Sorry for didn’t mentioning this in my initial post I already tried to forward the ports 10000-20000 to the PBX as well as 5070,5080,30000-31000,40000-41000 which are recommended by our provider. Furthermore I’ve disabled SIP ALG at the router.
Since we got calls around the world I would like to keep alaw and ulaw but for some testing purpose I can reduce the codecs to alaw.
Seems that I found the source of the issue. Today I’ve disabled the firewall including all ACL and since then the issue haven’t occured. Due to security reasons it is not a choice to leave the firewall disabled.
Maybe someone who is knowledged with Cisco routers can point to the fault since I haven’t found it till now. Please find a part of the router config below. ip inspect WAAS flush-timeout 10 ip inspect name FW sip ip inspect name FW rtsp ip inspect name FW tcp ip inspect name FW udp ip inspect name FW dns ! interface Vlan3 description voip ip address 192.168.3.1 255.255.255.0 ip nat inside ip virtual-reassembly in ip tcp adjust-mss 1452 ! interface Dialer1 ip access-group 111 in ip inspect FW out ip nat outside ! no ip nat service sip udp port 5060 ip nat pool PORTFWD 192.168.3.254 192.168.3.254 netmask 255.255.255.0 type rotary ip nat inside source route-map NAT_MAP interface Dialer1 overload ip nat inside source static udp 192.168.3.254 5060 ***static-public-IP-address*** 5060 extendable ip nat inside destination list 133 pool PORTFWD ! access-list 111 permit udp any eq domain any access-list 111 permit tcp any eq domain any access-list 111 permit udp any eq 5060 any access-list 111 permit udp any eq 5070 any access-list 111 permit udp any eq 5080 any access-list 111 permit udp any any range 10000 20000 access-list 111 permit udp any any range 30000 31000 access-list 111 permit udp any any range 40000 41000 access-list 111 deny ip any any access-list 133 permit udp any any eq 5070 access-list 133 permit udp any any eq 5080 access-list 133 permit udp any any range 10000 20000 access-list 133 permit udp any any range 30000 31000 access-list 133 permit udp any any range 40000 41000
it has been a while since i worked on the cisco ios but the basic config you posted looks correct. if you have support on your router, you might want to open a ticket with cisco to get some help. i am also sure that there are plenty of old cisco jocks out there that will help for a few dollars.
i am doing this on memory, but i think i remember some issues around using inspect sip but don’t remember exactly what they were.
Sorry I’ve cheered too soon. Seems that the firewall isn’t the source of the issue. Some agents told me now that they had the one way audio isssue even during the test where the firewall was disabled.
Also the three matches in the tcpdump tourned to be false positives. I’ve done a quick search in menu Statistics -> Conversations, for ‘Packets A->B’ and ‘Packets A<-B’ and looking for connections where no return flow occured. Thats why I thought I had three matches. After doing a RTP analysis of the suspicious connections I’ve recognized that they are not one way audio.
So now I’m as wise as befor and don’t know how to go on.
I’ve removed the ip access-group 111 in ip inspect FW out
from interface dialer 1 with the ‘no xyz’ command.
So the port forwarding (ACL133) was still in use but the ACL111 and the Inspect commands not.
I think I got it.
It looks like a misconfigured DECT-IP base station caused the issue.
Yesterday I’ve double check the configurations of all systems (Server,base station, telephones, network devices) and recognized a base station where only ulaw was activated. After activating alaw as well the issue wasn’t reported till now. So the misconfigured base station was the source and the issue is fixed.