[asterisk-dev] extend IAX2 IE proposal

[Markku Korpi]

Derek Smithies wrote:
> Hi,
> On Fri, 8 Dec 2006, Markku Korpi wrote:
>> Di-Shi Sun wrote:
>>> We posted the extend IAX2 IE proposal and the patch for IAX channel driver
>>> on bugs.digium.com. Ticket no. 0008531.
> 
>> We should consider carefully, whether this is really the way to go and even
>> bring it into the RFC.
>>
>> This method is basically segmentation of a single IE type only.
>> If we continue adding other long IEs in this manner the IE identifiers get
>> exhausted very quickly. Additionally this method leads to bad protocol
>> architecture.
> 
> Agreed.
>  However, there has been discusssion on this list about alternatives. Some 
> of the alternatives would have broken interoperability with existing iax 
> implementations. 
> 
> Full credit to Di-Shi Sun for putting up a patch to do the required job. 
> 
> Markku, what do you suggest as the correct approach?
> Protocols like SIP and H.323 do provide the required feature - and it is 
> inevitable that features like this are requested again.
> 
> Perhaps, we should provide a new full frame type with a very 
> general type/specification that all can forward etc, but only those 
> clients who need to know can decode it.
> 
> After a year (say) the new full frame type is a mandatory part of an iax 
> implementation. In the mean time, Di-Shi Sun can use his segmented IE 
> type.
> 

A new full frame type would provide cleaner protocol architecture, if we 
could start 'on green meadows'. Due to the fact that it would need to be 
mandatory, it would basically be incompatible with the current IAX2 
protocol.

We could avoid introduction of a new full frame type, if we modify 
Di-Shi Sun's segmented OSPTOKEN proposal slightly and turn it to a 
generic segmentation method. It can then be used with any long IE in any 
message.

We would define a SEGMENT information element, to carry information 
elements that are longer than 255 octets, and therefore do not fit into 
a single information element.  The information element identifier would 
have the format 0xFx, where the last 4 bits identify the segment number. 
Additionally the first octet of the segmented data provides the 
identifier of the information element that is segmented.

If a message contains several long information elements, the 
segmentation can be applied to all of them separately. For the sake of 
implementation simplicity, the segments of an IE should be included in 
sequence in the message.

The format of the SEGMENT information element would be:

                         1
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    SEGMENT    |  Data Length  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Segmented IE  |               |
    +-+-+-+-+-+-+-+-+               |
    |                               |
    :    Segmented IE DATA          :
    |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                         1
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

The Data Legth is the length of data in the SEGMENT IE including the 
Segmented IE octet.

Application of this method to OSPTOKEN patch provided by Di-Shi Sun 
would basically mean addition of one additional octet.

The segmented, full length OSPTOKEN IE can then be carried in NEW 
message in the following segments:

                         1
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      0xF0     | Length = 0xFF |  SEGMENT IE/Segment 0
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      0x34     |               |  Segmented IE = OSPTOKEN
    +-+-+-+-+-+-+-+-+               |
    |                               |
    :    First OSP Token Block      :
    |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      0xF1     | Length = 0xFF |  SEGMENT IE/Segment 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      0x34     |               |  Segmented IE = OSPTOKEN
    +-+-+-+-+-+-+-+-+               |
    |                               |
    :    Second OSP Token Block     :
    |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      0xF2     | Length = 0xFF |  SEGMENT IE/Segment 2
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      0x34     |               |  Segmented IE = OSPTOKEN
    +-+-+-+-+-+-+-+-+               |
    |                               |
    :    Third OSP Token Block      :
    |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      0xF3     | Length = n    |  SEGMENT IE/Segment 3
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      0x34     |               |  Segmented IE = OSPTOKEN
    +-+-+-+-+-+-+-+-+               |
    |                               |
    :    Fourth OSP Token Block     :
    |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This method should provide easier backwards compatibility, because an 
IAX2 entitity that has not implemented the SEGMENT IE would ignore it.

Comments?

Markku