[asterisk-dev] Call numbers in IAX2 media frames

[Tim Panton]

On 28 Nov 2006, at 18:22, Russell Bryant wrote:

> Greetings,
>
> I have been working on an IAX2 implementation recently on my own  
> time, and I have come across something interesting regarding call  
> numbers in IAX2 media frames.
>
> In my own IAX2 stack, I implemented mini frames and meta frames to  
> carry the destination call number.  Now, I see that the RFC draft  
> and the Asterisk implementation are not that way.  Asterisk sends  
> the *source* call number on a mini frame or meta frame.
>
> Since these frames are the ones that carry media, they have to be  
> processed very rapidly.  To put this into context of the Asterisk  
> IAX2 implementation, if these frames had the destination call  
> number, you would immediately be able to access the correct  
> iax2_pvt struct.  Instead, we have to do a very expensive lookup on  
> every single incoming media frame.  We start at call number 1, and  
> iterate through every possible call number, matching on the source  
> call number, IP address, and port.  This requires a mutex lock and  
> unlock on every possible call number until we find it, as well.   
> Note that the call number is 15 bits long, so there are 2^15  
> (32768) possible call numbers.  That means, if the call number for  
> an IAX2 call is 25000, Asterisk would currently do 25000 mutex lock  
> and unlock operations for every single media frame!!!
>
> Of course, there are ways that we could really optimize this lookup  
> process. However, I'm trying to figure out if it really has to be  
> done at all, because getting rid of it all together would be the  
> best optimization.  As it stands, you would still have to do some  
> sort of lookup process on all active calls to find which one the  
> frame belongs to.
>
> I have already contacted Mark about this, and he has not been able  
> to think of a reason that it is the way it is.
>
> Aside from the obvious issue of completely breaking compatibility  
> with every IAX2 implementation there is, including previous  
> Asterisk versions, can anyone think of a reason that media frames  
> should carry the source call number as opposed to the destination  
> call number?

I'd look _very_ carefully at the way that transfer works, since in  
the current model the mini-frame packets
get to keep their numbers but if it were the other way around you'd  
have to change them in
mid flow.

It also allows you to use the same matching code on mini-frames and  
fullframes since
both contain the same data in the first 2 bytes (apart from the top  
bit).
Actually we don't do this - Java doesn't lend it self that that sort  
of brutality :-)


In our implementation we have a two level optimization, first we use  
the source IP address
to select the peer we expect to talk to. We then hash into a table of  
active calls (local to the peer)
which are indexed on the call number.

Tim Panton

www.mexuar.net
www.westhawk.co.uk/