[asterisk-dev] extend IAX2 IE proposal

Mihai Balea mihai at hates.ms
Sun Dec 10 16:02:23 MST 2006


>
> I am a little concerned about the proposal- it has some aspects  
> that are a
> little concerning.
> Suppose someone uses this mechanism to send a 100 K datablock. I know,
> this does seem a little extreme, but it will happen. Given the  
> range of
> users of iax, and the number of users, it is inevitable.
>
I can easily imagine a scenario where one would send 100K of data.   
One example would be a picture.

> On transmitting the packet, it will be assigned an oseqno.
> The network will, because of mtu requirements, break it up into 70  
> smaller
> packets. - all sent as UDP. On an slightly lossy network, there is a
> chance of one of those packets being dropped. Consequently, the whole
> packet fails in the transmission process.
>
> At this point, the IAX2 retry mechanism will be required to resend the
> packet. During this resend period, all other full frames between  
> the two
> iax entities are delayed. The receiving node of the big packet cannot
> acknowledge subsequent full frames - this will imply it has  
> successfully
> received the 100 k datablock.

Even before you run into IAX2 retransmission issues, you hit the UDP  
maximum size limit.  The UDP header has a 16 bit field for size,  
which allows packets of up to 64K.  Even when your data is less than  
64K, some systems will limit the maximum UDP size to much less than  
that  - for example Mac OSX has a limit of about 9K

Also, as Derek mentioned,  IAX2 retransmission mechanism was not  
designed to deal with this kind of usage.  Although I cannot speak  
for the IAX2 authors, I believe that the system was designed for the  
delivery of control packets and it does a pretty good job at that.   
If you want to send data reliably you will have to either extend the  
protocol in a major way or choose a different mechanism.  Stopgap  
solutions like the original proposal would work, but would be limited  
in scope.

Just my $0.02...

Mihai





More information about the asterisk-dev mailing list