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
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
