<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>

<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7650.28">
<TITLE>asterisk-dev Digest, Vol 24, Issue 23</TITLE>
</HEAD>
<BODY>
<DIV id=idOWAReplyText99801 dir=ltr>
<DIV dir=ltr><FONT size=2>Kevin -</FONT></DIV>
<DIV dir=ltr><FONT size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr><FONT size=2>&gt; ----- Constantine Filin 
&lt;cfilin@intermedia.net&gt; wrote:<BR>&gt; &gt; 1) Right now RTP bridging 
happens in channel.c in function<BR>&gt; &gt; "ast_generic_bridge". This 
function<BR>&gt; This is only true if the call requires monitoring for 
DTMF-controlled <BR>&gt; features. If it does not, the bridging happens in rtp.c 
itself, without <BR>&gt; packing the data into/out of ast_frame 
objects.</FONT></DIV><FONT size=2></FONT></DIV>
<DIV dir=ltr><FONT size=2><BR>
<DIV dir=ltr>Please correct me if I am wrong. I think that ast_generic_bridge is 
much<BR>more common than you are describing. For example 
"ast_generic_bridge"<BR>is used when channels of different technilogy are 
bridged or when the<BR>native bridge through rtp.c is not possible (for example 
because of a NATed<BR>SIP telephone), or when there is transcoding 
involved.<BR><BR>&gt; &gt; of winners, then this can<BR>&gt; &gt; shave off 
quite a bit of CPU cycles and increase the performance. Of<BR>&gt; &gt; course 
the rest of&nbsp;"ast_generic_bridge" has to be modified to work <BR>&gt; 
&gt;with several winners.<BR>&gt; Do you really think calling ast_waitfor_n a 
second time is going to make <BR>&gt; much of a difference?<BR><BR>I have a 
problem at hand and I am willing to try&nbsp;all possible&nbsp;ways to fix 
it.<BR><BR>Constantine Filin</DIV>
<DIV dir=ltr>CTO </DIV>
<DIV dir=ltr>Intermedia.NET</DIV>
<DIV dir=ltr>&nbsp;</DIV></FONT></DIV>

</BODY>
</HTML>