[Asterisk-Dev] Henning G. Schulzrinne quote on IAX2 from von magazine

[Steve Underwood]

Brian West wrote:

>
> On Aug 13, 2005, at 1:45 PM, John Todd wrote:
>
>> I hereby kill this thread and take it to the -users list.
>>
> 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.  

These problems are with implementation rather than the protocol. Using a 
single port does have certain effects, but these should not be negative. 
They should actually be rather positive. Much of the inefficiency of 
most current RTP implementations comes from handling so many ports. Of 
course, the inefficiency on the wire comes from handling so little in 
each stream.

Trying to merge and split multiple streams in the kernel would be a bad 
idea. If you want greater efficiency you should reduce the number of 
operations between the kernel and userland. Trunking/untrunking in 
userland does that. There is nothing to stop people trunking with RTP. 
People have been doing it since the early days of RTP, and I believe 
there is a spec for this in preparaion. With trunking RTP becomes a lot 
like the media part of IAX (i.e ignoring the signaling side).

It seems to me the problems with the current implementation are just 
that. Implementation details which should be solvable. I can't see a 
structural reason why things should not work well. Have you monitored 
the bad sounding systems in any detailed way? Are packets lost, or just 
delayed?

Regards,
Steve