Hi Guys,
I’m writing here because I’ve a problem that drive me nuts.
I have two locations A e B with a working VPN connection
A is 192.168.1.0/24
B is 192.168.2.0/24
Traffic flows good between the two networks…
Asterisk is on A net, ip 192.168.1.10
There is no nat involved here, has the traffic is routed
On B i have 4 sip clients
1 Grandstream GXP2010
2 different SoftPhones (3CXPhone and SJPhone)
1 Siemens C610-IP
The first 3 clients work perfectly… with the Siemens I have one way audio (in the direction A->B)
I have same settings on all extensions… I have tried swapping the IP address with a working client…
Codecs are correct…
If I phisically take the siemens and put it on network A it works perfectly…
I have tried with a friend’s other Siemens (C470 IP) and it doesn’t work… same behaviour
Seems to be a strange incompatibility between Siemens Chagall Platform and vpn…
For casting out nines I have tried using a 3CX Server and the issue is the same…
Have you heard something about this problem, or experienced something similar with this or other equipment?
Thank you very much for the help, I don’t know what to think…
I forgot to mention that the server is an AsteriskNow 1.5 distro, running Asterisk 1.4.44 and that I already tried on the extension settings all the combinations for nat and canreinvite.
I have also added both A and B subnet on the localnet setting
Hi David, thank for the help… nat is not involved here…
I’ve deeply tracked down the thing running wireshark on both nets and intercepting the packets.
It seems, for some strange reason, that the remote cisco doesn’t route, or drop, the packets down the ipsec pipe…
because i see both audio flows in/out at the router in B, but on router A we found only the packets in out direction…
The only difference between the siemens and other clients is that the siemens add a ToS header to the rtp packet, while the other clients don’t
I think we need a cisco guru here, because there are no configurations on the router that do such a thing…
or simply a guru…
The problem is solved!
The solution is however a tricky workaround…
Based on the Wireshark dumps, as I wrote in the previous message, I noticed that the only relevant difference was in the DiffServ EF (0xb8) flag in the udp packet header.
On the B side router I have setup a policy to rewrite that header setting it to 0x00 and now I have perfect two way audio…
:mrgreen:
Maybe some ipsec vpn expert can explain the thing… This stuff is too complicated for me…
I think that the packets were not dropped by A or B router, but on some Internet node between them…
or simply is not possible to encapsulate ToS flagged packets over an ipsec tunnel…
difference between the siemens and other clients is that the siemens add a ToS header to the rtp packet, while the other clients don’t
Maybe some ipsec vpn expert can explain the thing… This stuff is too complicated for me… 