<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><BR><DIV><DIV>On Aug 13, 2005, at 1:45 PM, John Todd wrote:</DIV><BR class="Apple-interchange-newline"><BLOCKQUOTE type="cite"><P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">I hereby kill this thread and take it to the -users list.</FONT></P> </BLOCKQUOTE></DIV><BR><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Actually this should be on -dev because IAX2 does have scalability issues.  It will not and CAN NOT scale to large scales.  This is due to the single thread that handles all traffic in and out of the single UDP port.  As you start to load the box with calls the call quality starts to degrade and the delay shoots thru the roof.  You have one queue for receive and one for transmit that is serviced by the same thread.  Now if you pile on 30 calls with say a 300ms of latency it starts to sound like crap while running sip in the same situation sounds perfect.  IAX2 has its place but not in a large scale deployment at this time unless we can solve the issue with the bottle neck in the tx/rx queues.  I think we have talked about splitting the tx and rx queues into two threads that only gains a little bit of speed.  The next step would be to move this operation into the kernel since it does this and does it well already.  Then again on the other hand if you had an option to use a dedicated udp port per call that would also cause the issue to go away.  We could add something to punch thru nat and cause it to work just like it does now without much if any thought on the users side.  </DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>/b</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV> </DIV></BODY></HTML>