Unified Communications
Seems to be a theme with Linkus Audio issues. Linkus App registers (8111 = check) call attempts (6023 >5060) Check. No Audio and eventually requests time out. PCAP shows 401 unauthorized at the start. For the likes of me, I can't see why.
Date
Votes
5 comments
-
Larry Neblett The 401 is not the issue, When the device tries to register, the server will challenge (401) the device in an effort to get the device to respond back with its credentials. If the device responds with the proper credentials, it will be allowed to proceed with the query (register, Invite, etc.).
What you describe is typically a NAT issue. The 32 seconds is a tell. When the call is initially connected and a 200OK is sent, there is an expectation that the 200OK will be ack'ed in 32 seconds and if not the call will end.
Look at the contact and connection headers in the Invite and the 200OK. If they show your private IP, ther's the issue.
-
Devin Bickel Thanks for responding Larry, both reflected the public IP.
Out of frustration I changed the nat settings on the PBX to use 6023 and that seemed to resolve it.
so this does have me a bit confused, a great amount of documentation shows the when you use 6023 and map to that to 5060, the pbx should be set at 5060.
What and why is the point of mapping 6023 to 5060 if the system is only listening to 6023?
Greatly appreciated!
-
Larry Neblett In your initial post the transport seems to be UDP. It is unclear as to why a port remap is needed unless it is Yeastar's way of trying to avoid the typical hacker using 5060. However, this does pose a potential problem in that the source port is different from the seen port. The UAS would typically look at the contact and connection headers and follow the source ports in that messaging once the 200OK is seen and I suspect that perhaps this is what was happening.
I have Linkus running locally and am using 5080 as I have other PBX systems already occupying 5060, 5070 and others. I am not port remapping as 5080 <--->5080 without issue. You did not mention if local or cloud.
-
Devin Bickel To follow up with this, we are using the local Linkus application.
The end of the day our firewall utilizes SIP Algorithm in two ways. Disabling SIP ALG is not enough as the sip nat policy is still applied to the SIP Policy by default, even though its disabled. I needed to delete the default SIP Policy (uses the 5060 rule which we changed to 6023 and port mapped to 5060) and reboot firewall in order to clear SIP ALG. **it's always the firewall**
Packet capture showed the above which was the palm in face moment.
As for port mapping, using 6023 outside but mapped to 5060 inside has reduced SIP Hacks to zero. The Yeastar documentation is a mixture of accuracy. I am going to play with some of this as I do like not seeing weekly hits of hackers trying to get in.
Thank you Larry
-
Larry Neblett I strongly advise against port re-mapping. The issue is that the source port and messaging port will not be the same and SIP likes 1:1 NAT.
If need be, then change the SIP port to be 6023.
The issue is that the PBX will still be using the contact IP and port of 5060. You are relying on the router to send out port 6023 and hope that the other end will respond to 6023 and ignore the contact header where 5060 is listed by the PBX.
Your provider may ignore the contact header and respond to the seen, but perhaps not all other devices will. All I can say is glad it is working, and good luck going forward.
Please sign in to leave a comment.