I have been having intermittant 8 - 10 second timeouts on SIP calls, We replaced the original Asterisk system which was version 1.4 with Freepbx version 13. We left all the old IP phones. We have 6 locations connected together over VPNs using IAX. We have had reports of random “no audio” on inter-office calls. So I fired up TCPdump on the system and started looking at the calls. The only think I can see is that the phones are using UDP ports “outside” the RTP ports set in Asterisk SIP settings/Chan-SIP. I have the system set to ports 10000 - 20000. The phones were set to 1000 – 1012. I would see calls using 1004 and 1008. Shouldn’t the phones be using the same UDP ports?
The phones will connect from a port of your/it’s chosing to a same/different port on your asterisk PBX typically in the 10000-20000 range for RTP. You should be using 5060 for sip (UDP or TCP) and 5061 for sip over TLS (TCP) for signalling.
Yeah but what if the phones were programmed to use 1000 thru 1012 for their UDP ports
I don’t think sip phones operate like that in general. They communicate with asterisk on port 5060 and then asterisk tells the phone which RTP port to listen on for incoming audio.
On the phones, you have the option to change the port the phone listens on. Can be fixed or random.
Me too, let me know what you find.
The phones are Escene I forget the models, about 5 years old.
The phones in Global Settings have inputs for SIP port and RTP ports. I tried to upload a screenshot but no luck. The SIP is 5060 UDP and the default RTP ports were set to 1000 - 1012. This is even affecting phone to phone calls and phone to voicemail calls.
Let’s start with concept that no ports below 1024 should ever be used for usermode applications. Ports 1 - 1024 are privileged ports that require superuser privileges on all OSes to be opened. Usermode applications open ephemeral ports (1025 - 65535 (5000 on Windows)).
Regardless, a “connection” (even though UDP is connectionless, it follows the same guidelines) is created between unique sockets on each host. A unique socket is an IP address and Port. It is HIGHLY unusual for applications to use the same port for the client and server, but I have seen several applications use this (naive) approach. The limitation is that you cannot have more than 1 session between two hosts at any given time if you force port symmetry between the hosts. And the application may fail if some other application has already opened that port (really common with low ephemeral port numbers).
The short of this is that your phones appear to be behaving normally, using different ports that than the server.
As for your 8 - 10 second drop outs, this is the type of thing I would expect to see associated with a DNS request timeout. Are your phones using DNS to resolve the IP address of the server or remote end? If so, that is where I would start looking.
MGS
I have reprogrammed the phones to the original ports. All the phones and the system use IP routing and not DNS. All these phones are on the same network as the phone system. I have some captures to go through, although I am not sure I will find anything, sigh
By same network do you mean the same LAN? As in no routers between the phones and the FreePBX? Is everything running off of a single switch? Are you VLANing the network?
Another possibility that I’ve seen cause this kind of issue is IP address conflicts. Are you serving all of your IPs from DHCP? Have you checked to ensure that there are no statically assigned IPs in the DHCP pool?
If you run ‘arp -a’ do you have any IPs listed with multiple MAC addresses?
Where are you capturing? Directly on the FreePBX, or do you have options to sample in other places?
Correct same LAN no Vlans, on the same switch. Not my switch or router tho. All phones and Freepbx on the same network. Capturing on the Freepbx system with TCPDump logging all UDP traffic and traffic on 5060. Arp -a shows the 6 phones and the router. I can’t see the DHCP pool. The thing is, is that this is happening over all 6 locations intermittantly. All pretty much the same setup at each place.
So I may have misread your original post.
It sounds like 2 separate (but possibly related) issues. 1st is the SIP time outs, 2nd is dropped audio.
Are the SIP timeouts occurring during registration, call setup, or during a call? What is SIP Debug telling you about these?
The dropped audio seems more likely a lack of QoS across the VPN (these are all calls between sites, correct). But if the SIP timeouts are happening during the call, that could possibly cause the dropped audio. What are your RTCP statistics saying about call quality?
This is NOT unusual nor naive. It is one of the many ways in which NAT is dealt with. It’s called symmetric RTP. You’ll find rPORT settings in the software of a number of endpoints.
mgs,
Almost ALL calls that last more than 10 seconds will work just fine. It is that first 10 seconds that is the issue. I need to bone up on the SIP debug and RTCP stats.
If you read through RFC 4961 - Symmetric RTP / RTP Control Protocol (RTCP) - IETF Tools it does not suggest nor require that the port on host A be the same as the port on host B, only that whatever port is opened for sending on host A is also used for receiving on host A. Similarly with host B. Requiring that host A & B use the same port number is what is naive. It limits simultaneous connections to a maximum of 1 connection.
Many hosts will send and receive on port 5060 for SIP connections, but neither end REQUIRES that port 5060 be used, and every implementation I’ve seen will allow a second, simultaneous connection between the same pair of hosts on some other port. 5061 is a common second SIP port to choose, but so is 5070.
The rPort setting on endpoints just tells the client (the SIP phone) what port to find the SIP server on. Like assuming that HTTP will be on port 80, most clients assume the SIP port will be on 5060. But there is no requirement on either end for that to be the case.
If your call drops in the first 10 seconds, try to use
keepalive=yes
in your trunk settings.
Thanks I will try that