[OpenSIPS-Users] First release of SylkServer application server

[Stefan Sayer]

o Adrian Georgescu on 01/28/2011 10:50 PM:
> Think about what happens under load when you must act at every 5 or 10ms intervals for each single stream. A virtual environment will lose its real-time properties under load. You can send emails and serve web pages without noticeable impact but real time media like audio and video does not tolerate same conditions without losing quality.
> 
> It does not work properly for any software Asterisk or not, is a wrong question to ask in the first place. There is a reason Asterisk needs accurate timing, what you do with your virtual box you take things to the opposite extreme and provide the most inaccurate timing and wonder what is wrong with Asterisk. Nothing is wrong, you are using it wrongly and complain for the wrong reasons.
honestly I don't understand what everyone has with this 'i need an 
accurate timing source'. if you are not interfacing to TDM directly 
this is totally bogus and not required. packet based voip is elastic 
within limits, and those limits are usually much less stringent, 
compared to accuracy of usleep(3) virtualized or not, and the added 
jitter due to scheduling on the VM host. e.g., if you use 20ms packet 
length, those limits are never less than 10ms, and a timing source 
more accurate than that is not needed. usually, due to jitter buffers' 
minimal size, you don't even need 10ms accuracy.

regarding clock skew - which may or may not be worse in VM environment 
- both your media server/conference bridge and your UA should have 
some adaptive jitter buffer which alleviates that anyway, either in a 
clever way (e.g. time stretching) or in some not so clever way.

of course you will run into problems if you overload your physical 
machine, or if your VM scheduler starves your guest of CPU for more 
than, say, two times a packet length. but both usually ocures more 
frequently in relation to disk IO, network or hardware issues, and its 
the same whether virtualized or not.

Stefan