VoIP phone no dial tone OpenVPN

[masser]

Hello.
I have spent many hours trying to figure this one out.

I have configured OpenVPN client on my N66U Asus running latest Merlin Firmware RT-N66U_380.62_1 .

The VoIP phone (192.168.1.199) appears to connect to the remote end VOIP server (192.168.0.4) via the tunnel, as I can make a call, and the caller can hear me. The problem is I cannot hear anything, no dial tone, or the caller.

If I disable or switch the H.323 passthrough (WAN - NAT Passthrough) to enabled or disabled, the phone doesn't establish (LCD screen displays DISCOVERING) . Only when I switch to Enabled + NAT helper, can the phone connect. Modifiying SIP or RTSP settings doesn't appear to so anything.

Please can someone help me figure out why I cannot get a dial tone? I'm pretty sure this is some kind of routing issue / double NAT.

The remote end is not seeing any firewall blocks and we are 100% this issue is not related to the remote end nor the hardware.

Here is an extract from the logs.
Oct 8 16:22:17 openvpn[688]: /usr/sbin/ip route add 192.168.0.0/24 via 172.16.254.5
Oct 8 16:22:17 openvpn[688]: /usr/sbin/ip route add 172.16.254.1/32 via 172.16.254.5
Oct 8 16:22:17 openvpn-routing: Skipping, client 1 not in routing policy mode
Oct 8 16:22:17 openvpn[688]: Initialization Sequence Completed
Oct 8 16:23:03 kernel: nf_ct_h323: incomplete TPKT (fragmented?)

Any ideas

 

[sfx2000]

Keep in mind - SIP for signaling, RTP for data - so if you're not hearing dial tone, ring back, or voice, then check your RTP side..

 

[TOD]

Judging by the last message in router's log, his IP-phone uses H. 323 and not SIP.
H.323 devices use H.225 as signaling protocol, and H.245 as media exchange(voice in current case) protocol. Both of these protocols run on top of TPKT(and over TCP).
I have never worked with H. 323, but he's not better suited for NAT traversal than SIP.
Apparently address translation occurs from network where IP-phone located, then the subscriber in other network receives the RTP(voice) traffic correctly, while RTP traffic in the opposite direction can not overcome NAT(device advertise its local IP-address and port, and passing the NAT RTP traffic gets another address : port. Thus, the second subscriber sends its RTP traffic to the address : port that unavailable from his network).
We don't know how works the algorithm of H.323 Passthrough + NAT Helper, besides, it is possible that devices interact over non-standard ports for H.323(H.225 and H.245 to be exact). In this case, the mentioned algorithm is not able to identify this traffic as a target and handle it as intended.
I think that without collecting and inspection of VoIP traffic, it's impossible to solve this problem.

 

[masser]

Hi,

Here is an extract of the VoIP server, showing the IP phone registering.


Is there a way to redirect all inbound traffic fr0m the VPN (TUN11) to the IP Phone (192.168.1.199), as this would be the only device connected to the Asus router? Surely this would correct the issue?










1936557mS PRN: Recv: RegistrationRequest ac10fe06
1936559mS RasTx: v=Src=192.168.0.4:1719, Dst=172.16.254.6:3000, tos=0 peb=0
RasMessage = registrationConfirm = {
requestSeqNum = 4
protocolIdentifier = 0.0.8.2250.0.2
callSignalAddress = { 1 item(s)
[0] = ipAddress = {
ip =
c0 a8 00 04 ....
port = 1720
}
}
gatekeeperIdentifier =
0055 006e 0073 0077 006f 0072 0074 0068 Unsworth
endpointIdentifier =
0055 006e 0073 0077 006f 0072 0074 0068 Unsworth
005f 0035 0037 0066 0063 0030 0065 0063 _57fc0ec
0036 0035 0032 0061 0066 0034 0031 0037 652af417
0036 6
timeToLive = 60
willRespondToIRR = false
preGrantedARQ = {
makeCall = true
useGKCallSignalAddressToMakeCall = true
answerCall = true
useGKCallSignalAddressToAnswer = true
}
}
1937139mS H245Tx: v=0 peb=250
MultimediaSystemControlMessage = request = roundTripDelayRequest = {
sequenceNumber = 7
}
1937339mS H245Rx: v=0 peb=250
MultimediaSystemControlMessage = response = roundTripDelayResponse = {
sequenceNumber = 7
}




Proto NATed Address Destination Address State
udp 192.168.1.199:3000 192.168.0.4:1719 UNREPLIED

 

[sfx2000]

Judging by the last message in router's log, his IP-phone uses H. 323 and not SIP.
H.323 devices use H.225 as signaling protocol, and H.245 as media exchange(voice in current case) protocol. Both of these protocols run on top of TPKT(and over TCP).
I have never worked with H. 323, but he's not better suited for NAT traversal than SIP.
Apparently address translation occurs from network where IP-phone located, then the subscriber in other network receives the RTP(voice) traffic correctly, while RTP traffic in the opposite direction can not overcome NAT(device advertise its local IP-address and port, and passing the NAT RTP traffic gets another address : port. Thus, the second subscriber sends its RTP traffic to the address : port that unavailable from his network).
We don't know how works the algorithm of H.323 Passthrough + NAT Helper, besides, it is possible that devices interact over non-standard ports for H.323(H.225 and H.245 to be exact). In this case, the mentioned algorithm is not able to identify this traffic as a target and handle it as intended.
I think that without collecting and inspection of VoIP traffic, it's impossible to solve this problem.

I would agree - look at the ports needed - generally there are at least two ports - as I mentioned earlier in this thread - one is for registration/signaling, and the other is for data...

No matter if this is standard SIP (if there is such a thing) or something other - generally signaling needs to be reliable, e.g. TCP driven, and the ringback/dialtone/voice is generally on the Data Plane - which in many cases is UDP...

With SIP - many folks can sort that, but forget about the data plane - the RTP side...

 

[TOD]

masser
As I've said before, I have never worked with H.323, so can't give any expert advice.

Oct 8 16:23:03 kernel: nf_ct_h323: incomplete TPKT (fragmented?)

But perhaps you should pay attention to this point. There may be a problem with the packet transmission, the size of which is greater than the MTU of the VPN tunnel, while processing a fragmented packet is restricted.