I come to you once more, oh gurus of FreePBX. I’ve got a local server running FreePBX 16.0.40.4 behind a NAT. Ports 5060 and 10,000-20,000 are forwarded to the server. About a mile away I have a remote extension (PJSIP) at a home office. After multiple issues, I finally got it to work correctly, and then the homeowner called the ISP and had them upgrade their router a couple days ago. The remote extension was working for a bit yesterday, and today I have no audio on the remote extension. The phone rings, I can dial out, but no audio either in or out. Internal extension works fine.
There is no SIP ALG option on the remote router. I forwarded RTP ports 10,000-20,000 to the phone, it still did not work. How do I pull the proper logs to diagnose this? The new router is a Technicolor CGM4981.
The CGM4981 has two analog phone ports, almost certainly SIP over UDP on port 5060. Of course, they are using a private address and in theory shouldn’t conflict, but IMO this problem is likely.
Two approaches:
Try something likely to avoid the problem. Possibilities include connecting via VPN (if supported by the phone), doing SIP over TCP or TLS, or using a port other than 5060. For a quick test of the latter, set up the phone as a chan_sip extension, using port 5160 (or whatever you have chan_sip Bind Port set to). In your firewall, forward UDP port 5160 (or the actual Bind Port value) to the PBX.
Find out what is actually going wrong and try to design a fix accordingly. At the Asterisk command prompt, type pjsip set logger on
and look at the Asterisk log for proper IP addresses and port numbers in the SIP and SDP. If you have trouble interpreting the log, paste the log for a failing call at pastebin.com and post the link here. Depending on what you see, you may need to capture traffic and look at the RTP.
That may or may not have done anything. If it could be useful, you would need to forward the RTP range used by the phone (not 10000-20000, which is the RTP range used at the Asterisk end).
Something that is unlikely to help but easy to try is to change the phone’s local SIP port to 5060, if currently different, or to something else, if currently 5060.
On that phone, there is a spot to configure which RTP ports the phone uses. What should I put in there? I will try the other things you suggested and reply later today.
Last night I tried RTP debugging. There was an IP address 207.223.67.137 coming up (Peerless Networks) that I didn’t recognize. (My SIP provider is Flowroute.) I just don’t understand all these networking processes like RTP yet and I really want to.
Flowroute doesn’t proxy the media, so it goes directly to/from their upstream carrier’s media server. This can vary by destination, and in some cases can vary to the same destination (failover, load balancing, etc.) On incoming calls, the RTP should always come from the CLEC’s media server.
Edit: was looking at this log. Interesting that the packets are being sent to the internal IP address of the remote extension. 192.168.0.3 Is that supposed to happen?
Its interesting how there are packets both to and from the internal IP address 192.168.0.13, (which is the phone). Contrast that with the broken phone, there are no packets from the phone ip address.
On line 377 of the pjsip logger paste, Asterisk correctly asked for media to be sent to its public IP address. However, no RTP ever arrived, so it didn’t know where to send RTP back, and continued to send to the private IP address of the remote.
It would be useful to capture traffic at the remote end to see if the Technicolor butchered the SIP so the Yealink is sending to the wrong address or port, or if the Technicolor is simply nor forwarding the traffic correctly. If you don’t have an easy way of doing that, try setting up a softphone there instead. If it fails in the same way, capturing traffic is trivial. If it doesn’t fail, we can try to configure the Yealink to match the softphone SIP settings as closely as possible. In the meantime, the user can use the softphone to make and receive calls.
I made some progress. First I created a a SIP Chan extension, listening on port 5160. I then configured the yealink phone to that SIP extension. It did ring, but no audio either way. I then did what you said and installed Zoiper on a laptop at the same house as the remote ext. It works! I did notice they are using a STUN server. How do I translate their configuration to the Yealink phone so it will work? Also how do I get logging info off of the zoiper app?
I got the data from sngrep. It was a successful call through the softphone. I don’t know what I’m looking for.
I also don’t know the best way to export it. I copied pasted into pastebin. I also have screenshots. Here it is:
I was looking at an unsuccessful audio call through sngrep. The hard phone rang, but there was no audio. sngrep showed a 401 unauthorized. What does this mean? What is causing this?
It’s not an error; only a request for authentication. On line 4, ext. 514 sent an INVITE to the PBX, calling 516. Line 6, PBX sent a 401. Line 10, ext. 514 resent the INVITE, this time with an Authorization header. Line 12, PBX accepted the auth and proceded with the call.
However, this whole sequence is the conversation beween ext. 514 (a local extension) and the PBX. There is no evidence that anything is wrong here. The interesting sequence would be the conversation between the PBX and ext. 516 (presumably the remote extension you are trying to troubleshoot). But even that wouldn’t tell us much, unless we could compare it with the traffic at the remote end. After all, we strongly suspect that the new router/firewall there is interfering with the traffic.
Based on what you found so far, I’d try to make the Yealink appear like the softphone by changing its local SIP port to a random value (like Zoiper uses), and/or setting up NAT traversal, e.g. with STUN, to emulate being on a public IP.
If those measures are unsuccessful, capture traffic at the Yealink to see what is going wrong.
In fact I don’t see any need to open or forward any port on the home-working-place side.
The phone should be setup with the IP or URL of the company-PBX. The company-PBX needs to let the phone in (where 5060 UDP or 5061 is not the best port thinkable), and let the media flow (10000-10100 with 50 simulaneous calls).
Second solution: Let the router at home and the company router connect via VPN. In this case you don’t need to open or forward any ports nowhere.
To be pedantic , 10000-10100 is actually 50 and one half legs so the chances of a call leg starting on 10100 so not completely working is quite high, most calls have at least two legs.
It probably needs stressing that that is legs, not calls. If both legs are external, one call uses two of those legs. The half leg is referring to having enough room for RTP, but not for RTCP.