<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 50</TITLE>
</HEAD>
<BODY>
<DIV id=idOWAReplyText29351 dir=ltr>
<DIV dir=ltr><FONT size=2><FONT face=Arial></FONT>Roy -</FONT></DIV><FONT
size=2>
<DIV dir=ltr><BR>> once again, I'm trying to find a good way to speed up RTP
bridging. <BR>> in real-world environments where more than 50% of the
clients are <BR>> behind NAT, one cannot just use reinvites because of
NAT problems, <BR>> audio disappears etc. so, since NAT implies the need
for bridging RTP <BR>> somehow. The current implementation with the
good-old recvfrom/sendto <BR>> is inefficient. the use of these calls
makes a overwhelming overhead <BR>> in kernel-space due to
context-switching between user and kernel. I'm <BR>> just thinking using
sendfile or something like it would be useful, <BR>> since there's
hardly anything like a mmap for udp.</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>I do not know what sendfile can do, but just keep me in the loop on
your</DIV>
<DIV dir=ltr>effort as I am also looking into optimizting RTP performance
in asterisk.</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>I've got some code that shaves off a few CPU cycles in RTP bridging
in user <BR>space but you are right - the breakthrough in RTP brigding should in
done on <BR>the kernel. Please don't hesitate to contact me if you need someone
who can <BR>code and test a few things.</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>Thanks</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>-c<BR></DIV></FONT></DIV>
</BODY>
</HTML>