Cavalera Claudio Luigi wrote:
-----Original Message-----
Yes there is something here http://tinyurl.com/2houc2 and here http://www.vmware.com/pdf/vmware_timekeeping.pdf
I'll try to solve this :-)
[snip]
Actually, I have been wanting to figure this out for some time now. You can use clock=pit to keep the timer stable in a VM. However, the problem still exists.
Hello John, I'm not sure I've understood you. Could you please explain a little better? :-) I've followed instructions in the link I've posted and clock skews seems to have gone away (at least in freeswitch debug log). But I admit that date is not as accurate as I would like (2 minutes in advance at the moment). Have you got some command or procedure to debug this? I mean how can I be sure that I solved this once and for all?
The problem is that in bridged network mode RTP packets from my sip phone (on the host system) were seen twice by the guest (same sequence number, same packet really). MikeJ pointed this out so I switched to NAT mode, which fixed it for me. To keep your clock in sync just boot with 'clock=pit' and run ntpd.
MikeJ helped to figured out that the culprit is actually the vmware bridge. Change the network type to NAT and it will "just work". Mike says that if the soft phone was not on the same box as the host system that it would work a little better. I will test with a native linux bridge and xen in a few days. =]
-John
But if I changed network type to NAT how can I reach the freeswitch server inside vmware? Isn't that the same as reaching a private host behind a home nat dsl router?
Best regards, Claudio
[snip] Sorry, but I can't be much of a help here. I believe there is a file /etc/vmware/vmnet8 or so that allows you to configure port forwarding inside the VM. I agree dealing with nat even once (let alone twice) is a big fat PITA. Perhaps you can figure out how to run VMware in "routed" mode. I would prefer this as I could then run NAT on the host system doing 1:1 NAT or on the router itself. Also, and anthm can explain better but if you add something like: <action application="set" data="timer_name=soft" /> to extension 9999 for example (before the playback). The choppyness will disappear. From what I understood freeswitch gets its timing information from the client and if the client is sending every packet twice it confuses freeswitch. Actually another solution/work-around (without modifying the rtp code) would be to run ebtables on your linux box and filter the erronous packet, on my system it comes from some cisco mac address. HTH, John