[asterisk-dev] Call numbers in IAX2 media frames

[Tim Panton]

On 28 Nov 2006, at 20:36, Russell Bryant wrote:

> Tim Panton wrote:
>> 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.
>
> Ah, interesting point.  However, I still don't see this as a  
> problem.  There is a call number information element that is sent  
> with a TXREQ message that contains the destination call number on  
> the peer that the media would then be sent to.
>
>> 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 :-)
>
> Right, but splitting that up is not any kind of measurable  
> performance hit. Also, it's only helpful for the code that gets the  
> source IP address out of the frame.  There is a lot more work to do  
> after that in which they differ.
>
> Like I said before, there are definitely compatibility issues in  
> regards to this proposed change.  I'm trying to figure out if it  
> could still work.  :)
>
>> 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.
>
> I assume you meant source IP address and port number.  But,  
> wouldn't it be nice to just immediately have the local call number  
> to identify the call?  That way, you would completely eliminate the  
> step in that process of matching the peer.

Well, yes and no. For security reasons you still need to verify the  
rest of the results, but the computational
load could be way smaller.

I don't see anything that couldn't be fixed by tweaking other bits of  
the protocol.

I'm just wondering if it is necessary to change the protocol to get  
same efficiency. Looking at our
stuff, I can't say that swapping them would make much of a difference  
to the performance.

I'm sure that you could get close in asterisk by using a simple map  
of source->dest call nos per peer.
Ok, that's 64k per active peer, but it would be be _quick_ and no  
locks needed until you have your channel
and want to manipulate it. That's an extreme solution, but not absurd.

I've just spent a week fighting to get Mark's last IAX improvement  
working/tested in our stack, so
I'm a bit sensitive ;-)


Tim Panton

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