[asterisk-dev] extend IAX2 IE proposal

[Mihai Balea]

On Dec 11, 2006, at 10:28 PM, Russell Bryant wrote:


>
> If you read Markku's latest proposal, it was changed such that it  
> would support up to 255 segments of 253 bytes each, except for the  
> first segment, which would have 252 bytes.  That is the one I was  
> responding to.
>
> 252 + 254 * 253 = 64514 bytes
>
> It certainly goes large enough, given that the maximum segmented IE  
> length approaches the maximum size of a single UDP packet.
That is the theoretical maximum UDP packet size.  As I mentioned in  
one of my previous emails, Mac OSX limits UDP packets to approx. 9K.   
I'm sure there are other systems out there that would enforce similar  
limits (I am thinking embedded systems).


>
>> The proposal above is, in my view flawed - it does not go large  
>> enough.
>
> See above.

Even if ~ 64K would be achievable, what if I need to transmit 65K?  
The solution does not scale well and limits like this can be easily  
exceeded in today's applications.

>
> You are correct that if an IAX2 Full frame gets lost, it will have  
> to be retransmitted, and the destination will not be able to  
> process any further Full frames until it has been successfully  
> received.  However, that's exactly how it is supposed to work.   
> And, on a lossy link, you can expect some sort of performance hit.   
> It is also worth noting that Asterisk's IAX2 implementation uses a  
> "sliding window" for the transmission and receiving of Full  
> frames.  That means that just because the lost frame has not been  
> acknowledged, this does not mean that further Full frames can not  
> be transmitted.  The receiving side should just save them, and not  
> process them until the next expected frame has been received.  Once  
> received, it will send an ACK which acknowledges all frames  
> received up to the next expected sequence number.
>
> On the topic of holding up the link while transmitting a large  
> packet, this isn't something that would be newly introduced into  
> IAX2.  In fact, it is normal to have extremely large IAX2 trunk  
> frames which get transmitted a lot more often than any signaling  
> frames.

Trunk frames do not require retransmission.

If we're extending the protocol, I would be in favor of defining a  
new type of large frame plus a packetization mechanism that would be  
able to transfer an unlimited amount of data.  We could have a  
separate mechanism of retransmission if needed, as long as we do not  
impact the existing control and media frames.

Mihai