I have a S100 with Yealink 42S handsets
I had a TL R600 in front of it and was having one way audio once in a while at the customer end.
I removed the router as a test and have the Yeastar with the WAM right into it
The problem is still there so I have the S100 with INTERNET right into the WAM and still getting one way audio on some calls at the caller end
Any Idea's on where I would look
Greg
It is almost a certainty that it is a NAT issue.
When an INVITE to start a call is sent, it is sent to the S-PBX by the provider or remote device initiating the call. The S then responds with a 100 Trying followed by a 180 Ringing. There are some variations to this as it depends on the destination and if 183 Session progress is set, but the INVITE is key regardless.
When the INVITE was sent it was sent to the address seen upon the last registration or if peer the AOR (address (IP) of record). However, within the INVITE there is a contact and connect header which tells the S what IP it should use when the session is started to communicate back to the provider. The contact header is the IP to be used for SIP messaging whereas the connect header is the IP to be used for RTP (audio) along with the port.
Conversely, once the call is answered, the S will respond with a 200OK/SDP which tells the provider what IP the S wants the provider to use when communicating going forward. Again it will be comprised of a contact and connect header and these should contain the public IP of where the S PBX resides.
When the 200OK is seen by the provider the session is started and these IPs now come into play and the provider will respond with an ACK. If the NAT is correct then the S will see the ACK and all is well.
If the ACK is not seen within 500ms, then T1 (timer 1) comes into play and the S will resend the 200/OK at 500ms following the sending of the first 200OK. If no ACK again, this will repeat at 1 sec, 2 sec, 4, sec and 8 second and again at the 16 second intervals. 500ms following the 16 second send interval TB (timer B) fires and the S considers the provider to no longer be on-line and able to control the call, it disconnects same. If you add the time up between the re-send intervals and the 500ms wait for a response following the final send at the 16 second mark, the total time before disconnect is ~32 seconds.
The reason for this is to prevent "hung calls". As the PBX may have a limit as to how many calls it can handle, you do not want the call to remain active and thereby eat into the call capacity when the call is not productive and the S can no longer see any responses. Otherwise any call using the provider would remain open and in limbo forever as the S would simply wait for the provider to ultimately come back. The SIP protocol prevents this.
There are some TP-LINK routers that will simply not handle SIP correctly. I have no experience with this model, but in 2014, I thought I had found a practical solution by discovering some of TP-Link's so called business class routers. Unfortunately, after getting a couple of different models in and testing I discovered that they were incapable of doing full cone NAT. I filed a ticket and the issue was escalated and after some back and forth, their engineering group and I went on a three month journey where they provided Beta firmwares for me to test.
Full cone in this context is that when the message is sent from the UCM the UCM may send out port 5060 and then tell the remote site to use 10000 for audio and expects to see the response coming back on same. By the time the router sent it out the WAN to the provider, the ports were altered and using the psuedo port as might be done if forwarding had not been enabled. So, in essence I would send on port 123, the message would be sent to the provider indicating 678 and the provider would respond to 678, but this port was not known and not forwarded so the PBX would never see the message. Further, the pseudo is random for each session.
Following is NAT table:
The first column is the originating IP, the second is the port that the device used to send a packet, the third is the psuedo port that the router has mapped to the sending IP and port, the fourth column (blacked out) is the destination IP, the fifth is the port being sent to at the destination IP and the last column reflects the outbound WAN path.
If you look at the table those IPs ending in 10, 100, 108, 110 and 113 are all different PBX systems. As I cannot port forward 5060 to all 5, I have to set a different local port for 4 of them. If you look at these, you will note that the sending port and the psuedo port are all the same and of course, as I am using common SIP trunk providers and they all want to see port 5060. All the PBXs are sending from their respective local SIP ports to the providers' 5060 port. When the provider responds back to the PBXs they are sending back to the local SIP ports of 5060, 5070, 5080, 5085, etc., as I have programmed each PBX to be on a separate port and have port forwarded each back to the desired PBX. The providers are in fact sending to the pseudo port, but as this is the same as the originating port it is a full cone or 1:1 NAT.
If you look at the other sessions (look to the bottom) you will note that the devices are sending from different ports but the destination IP may or may not be the same, but the port (443) is the same. Routers use the pseudo port as a mapping so that when response come back, the router can determine which device made the request and direct the response back accordingly. To put this into perspective, assume you have 10 PC and all are looking at Yahoo.com at the same time. The router sends all 10 requests to Yahoo, but Yahoo only sees the public IP that sent the requests. It has no idea of the PCs, how many or what their private IP is, so when responding, Yahoo is sending the response back to the public IP, but sending to the psuedo port where upon when seen at the router, the router can direct the response back to the requesting IP for that given response. The pseudo is always unique.
So, in any event, I worked with their engineering group for 4 months and they finally delivered a Beta firmware that worked, but I don't know if they ever put into production. I checked back a couple of times, but did not see any mention and by that time, I had already moved on.
The below is a snippet of one of the email exchanges with TP-Link -
My response is the message following [Lneblett]
And the destination port of the RTP packets from the media server is determined by the massage in the SDP? or it is absolutely static?[Lneblett] It is determined by the SDP message, but must take into account which ports are being forwarded and takes into account other ports that may be in use by other applications.
Thanks!
BTW: The randomized port translation of the TP-LINK SMB router can't be changed, we thought it can hide the real port of the internal host and can handle on different internal host that use same port.[Lneblett] I tend to disagree with this statement. Of course the firmware can be changed to accommodate a one-to-one PAT. It is merely a question of TP-LINK making a decision that doing so meets both its corporate needs as well as that of its customers. The PAT functionality that the router currently employs ignores the fact that certain remote hosts can initiate a request that the local system has no reason to believe that it can’t meet. The local system has no idea of the router’s functionality and therefore has no reason to expect that its packets will be altered.
So, I no longer use their routers nor will I. This is not to say that the current models have the issue, but I spent too much time and effort on the issue and it was apparent to me that their understanding of SIP was lacking. This was over 5 years ago and I have since found other routers that work just fine and I do not deviate from them. I do use some of their other products without issue.
When you changed and exposed the S to the Internet directly, the NAT conditions changed as you are no longer behind a NAPTR router and forwarding is not being accommodated. You further changed from a "switch mode" to a "route mode" and the only thing I can say is that I never, ever expose a PBX directly to the Internet and I suggest you nor anyone else does either.
Sorry for the long response, but I am afraid that you need to do some captures to see what is happening in order to know how to respond which may also involving mirroring the WAN port and capturing on a different PC as you can't capture the WAN traffic on the S.
Larry Thank you what routers are you using now ?
Well, keep in mind that I am not indicating that the router you have will not work. I am only indicating the issue I had some time ago and providing some insight as to what you can look for, why, and how it works,
The one I prefer and have been using since is Draytek. However, I have used MikroTik, SonicWall, Ubiquiti and a number of others, but all the features that I require are there:
1. 1:1 NAT
2. Object oriented firewall that allows me to select the specific IPs I want to allow in while blocking the others
3. Local DNS capability so that I can set a DNS entry so that I can assign a FQDN to an IP that will only be used internally to resolve an address to a local IP.
4. A level of testing/diagnostic tools that allows me to see what is actually happening
5. QoS capability. Draytek has an auto QoS for Voi as well as custom settings to tailor.
6. Some level of bandwidth shaping/reservations
7. VPN capability
8. DMZ
and so on.
Larry is this the one you use
No, they were Edge Routers.
I looked at the specs and they were not very revealing.
Here are links to a Draytek spec sheets:
This is a 2926-
https://www.draytek.com.tw/ftp/Vigor2926/Document/Vigor2926-datasheet-170725.pdf
Here is a 2133 (lower price):
https://www.draytek.com.tw/ftp/Vigor2133/Document/Vigor2133-datasheet-191025.pdf