I am trying to work out why my IP telephony does not work from behind e-smith.
I have tried the H323 masq module, and portforwarding, but it didn't work.
The first step in using Callserve is to log on, this is done over TCP, and then swithches to UDP where it fails. It does not even get to the point where I can enter a number to call. Also I *only* want to do outgoing calls.
Here follows three extracts of the communication as taken from TCPDump.
From them it can be seen that there appears to be no response from Callserve to the first UDP packet in the cases where it does not work, so my computer tries three times and gives up.
As I am not really a linux person I have the following questions:
Why does the port change from UDP:1719 to UDP:61003?
I believe that the reason why it does not work is that the outgoing UDP packet has the myIntIP emebbed in the data. Is there anyway to resolve this?
This worked
23:47:21.527413 myExtIP.1719 > CallServeIP.1719: udp 95
23:47:21.611560 CallServeIP.1719 > myExtIP.1719: udp 47
23:47:21.620140 myExtIP.1719 > CallServeIP.1719: udp 333
23:47:21.667044 CallServeIP.1719 > myExtIP.1719: udp 81
This failed - as seen on eth1 (external IF)
14:22:52.101000 > myExtIP.61003 > CallServeIP.1719: udp 95
14:22:57.109757 > myExtIP.61003 > CallServeIP.1719: udp 95
14:23:02.118540 > myExtIP.61003 > CallServeIP.1719: udp 95
And again - as seen on eth0 (internal IF)
14:19:15.253941 < myIntIP.1719 > CallServeIP.1719: udp 95
14:19:20.297746 < myIntIP.1719 > CallServeIP.1719: udp 95
14:19:25.311675 < myIntIP.1719 > CallServeIP.1719: udp 95
I have a more detailed log of the actual UDP packet contents and there it is clear that there is an embedded local IP address in the case where it fails.
0 Replies
531 Views