<div class="gmail_quote">On Wed, Jan 20, 2010 at 5:53 PM, Jeff LaCoursiere <span dir="ltr"><<a href="mailto:jeff@jeff.net">jeff@jeff.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
</div>Pretty crappy analogy. Just because you *can* do something doesn't mean<br>
it is production ready. But then the OP said it wasn't all that<br>
important, so I would say go Xen and tell us how it works out. I think<br>
you will only have trouble with conferencing, and maybe not even then if<br>
the machine is beefy enough and unloaded. Monitoring servers are usually<br>
pretty unloaded.<br clear="all"></blockquote></div><br>I probably should have put all my thoughts on this matter into one email, but that's what I get for reading down the line and replying as I get to things. Sorry for the multiple posts from me on the same topic!<br>
<br>I just wanted to add that in Asterisk 1.6.1 and 1.6.2, new internal timing mechanisms were introduced (res_timing_pthread and res_timing_timerfd) which allow you to get away from using DAHDI as your timing source. DAHDI is still required for the MeetMe conference bridge application however, which is why in Asterisk 1.6.2, the new ConfBridge() application was introduced, which is not supposed to depend on DAHDI. I haven't had a chance to play around with this new application yet, but from all reports, it seems to be working as intended.<br>
<br>-- <br>Thanks,<br>--Warren Selby<br><a href="http://www.selbytech.com">http://www.selbytech.com</a><br>