[asterisk-dev] extend IAX2 IE proposal

[Markku Korpi]

Tim Panton wrote:
> 
> On 3 Dec 2006, at 21:11, Derek Smithies wrote:
> 
>> Hi, On Sun, 3 Dec 2006, Markku Korpi wrote:
>>> Derek Smithies wrote:
>>>> On Wed, 29 Nov 2006, Kevin P. Fleming wrote:
>>>>> Di-Shi Sun wrote:>
>>> 
>>> The third option could be to add a segmentation procedure in a 
>>> similar way as they are used e.g. in SS7 ISUP and Q.931. In this
>>> case we would need to select a message coding scheme that would
>>> cause an old client/peer to throw away the segment message, but
>>> proceed with the non-segmented content.
>>> 
>> Are you suggesting to segment a large block of data into 250 byte
>> (say) chunks, with each chunk in a separate IE? Place a header byte
>> (or two) as the first element of the data field stating where this
>> chunk is in the large block of data ?

Yes, that would be roughly the segmentation principle, if we allow
segmentation at any octet boundary.

However, it would simplify the call processing, if we would/could split 
messages to segments at their IE boundaries only. This would allow 
reception of IEs contained in the segments in one step without a need to 
store the chunks and reassemble them back to a full message. The 
downside, this simplification would limit the max IE size to one 
segment, which could become a major limitation, probably sooner than 
later...
But perhaps there is a compromise.

> 
> But Kevin's point still applies, IAX doesn't support multiple
> instances of the same IE type in a message. So to implement your
> scheme you need to allocate new IE types called ExtendedMessage0
> through to ExtendedMessage32 (or whatever) - which then obviates the
> the need for the second 'sequence' byte in the data.
> 
> Anyhow, I can't help feeling this is the wrong way to tackle the
> problem (admittedly we have not had the actual problem described,
> just a possible solution).
> 
> Depending on what (exactly) the OP is trying to do, using one of the 
> existing frame types seems like a better plan than using an IE, 
> perhaps a 'pseudo' image or provisioning frame ?
> 

If I interpret the OP correctly, he has faced two different problems 
when trying to implement new services over IAX:
  - Repeating the same information element in an IAX message
  - Sending messages when the IAX message size is exceeded

Segmentation could solve the latter problem in a backward compatible 
manner. The IAX message size limit is reached quite quickly, when we 
start implementing supplementary services over IAX.

Repetition is required, too, and is a very useful feature with 
supplementary services - for example listing of forwarding points in 
case of multiple call forwarding.

Like Russell said in his reply, the IAX protocol itself does not hinder 
repetition - only the current messages do not use it yet.

Markku