[asterisk-dev] extend IAX2 IE proposal

[Markku Korpi]

Russell Bryant wrote:
> Mihai Balea wrote:
>> 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).
> 
> Ah.  Well, for this reason, as well as concerns of having to retransmit 
> an extremely large Full frames, I would say that the text in the RFC 
> describing this new segmented information element method should only be 
> used in situations where the payload is "slightly" larger than 255 
> bytes, such as the case with the OSP token information, which will take 
> 4 segments.  However, the text should strongly discourage use of this 
> method for extremely large amounts of data.
> 
>> 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.
> 
> If we come to a point where we would like to implement the ability to do 
> transfers of this size, then we will have to handle it with a separate 
> method.
> 
>>> 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.
> 
> True.  I was just trying to address the concern about blocking the link 
> while the single large packet is transmitted.
> 
>> 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.
> 
> I agree with you if we decide to implement a method for doing something 
> like peer-to-peer file transfers over IAX2.  However, I still think this 
> generic IE segmentation method is perfect for OSP tokens, and perhaps 
> other applications in the future which would only take a few segments.
> 

There are actually two independent tasks that we need to solve, when we 
carry large amounts of information in IAX2 _signalling_ messages:

Task A: Breaking the IE into segments that can be included in an IAX2 
signaling message in a backward compatible manner..

Task B: If an IAX2 signaling message becomes larger than what can be 
transported over the network, i.e. bigger than max UDP packet (~1500 
bytes), the IAX2 message needs to be broken into pieces, i.e. need to be 
segmented.

The purpose of the current IE segmentation proposal is to cover the task 
  A (only), and it already covers the OP's OSPTOKEN application in a 
future proof manner.

However, if we do not create additionally an IAX2 message segmentation 
method, there is no way to transport transport, for example, an IAX2 NEW 
message that contains a bit more supplementary service information in 
addition to the OSPTOKEN. In other words, the IAX2 signalling message 
size limit can be hit fairly easily with single IEs and a couple of 
segmented IEs.

I am not taking a position, whether a particular application needs to be 
implemented using IAX2 signaling transport, but just saying that there 
are signaling applications requiring IAX2 message segmentation. If this 
requirement is agreed I can make a proposal for message segmentation.

Markku