<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="Ih2E3d"><br>
</div>Asterisk does not support H.324. An Asterisk with patches and<br>
additions from a third-party source does.<br></blockquote><div>Yeah. now i understand your explanation.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
These patches are not official Asterisk patches. The problem here is<br>
not really technichal, but a matter<br>
of the definition of the product with the name "Asterisk" - which is<br>
defined by Digium ;-)<br>
<br>
What I would like to see moving forward is a proper H.324 integration<br>
in chan_dahdi and libpri instead<br>
of tunneling the raw stuff through the whole PBX to an app that<br>
converts it and sends the streams back.<br>
To me, this kinds of break the Asterisk architecture. It works, but<br>
isn't scalable. Would be better to have<br>
the streams separated correctly before they're sent in to the core pbx.<br>
<br>
There was some development on this going on, but it stopped on the<br>
issue of finding a properly licensed<br>
and working ASN.1 library with support for the encoding used.<br>
<br>
While waiting for that, the work done by fontventa is quite amazing.<br></blockquote><div><br></div><div>Thanks for clearing this up.</div><div>Anyway i am about to play around with these patches a little.</div><div><br>
</div><div>Mac. </div></div>