[Home]

Summary:ASTERISK-08296: [patch] extend IAX2 to support OSP protocol
Reporter:Di-Shi Sun (homesick)Labels:
Date Opened:2006-12-06 15:11:40.000-0600Date Closed:2007-07-09 21:20:51
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 2006-12-14_iax_proposal.doc
( 1) iax_osp_60397.patch
Description:4 new IE types (0x34~0x37) are defined to carry Open Settlement Protocol (OSP) tokens. The OSP tokens are used to provide authorization, authentication and account support for IAX2.

Since an OSP token is usually longer than 255 octets, and IAX2 does not currently support having multiple instances of the same IE type in a single frame, four OSPTOKEN IE types are defined.

The patch has been tested in our lab.

A proposal of extending draft-guy-iax-02 is also attached.
1. 6.2.2 section, add OSP Token IE into the NEW message IEs table.
2. 8.6 section, add the OSP Token IE types into Table 31: Information Element Definitions
3. Add 8.6.51 section, describe OSP token IE types.


****** ADDITIONAL INFORMATION ******

Disclaimer signed by TransNexus, Inc. 1/27/05
Comments:By: Di-Shi Sun (homesick) 2006-12-06 15:32:30.000-0600

To try the patch, on the source side dial plan, using set(IAXCHINFO(osptoken)=OSP token string) to set the outbound OSP token, then call the dial function. On the destination side dial plan, using set(OSP token string=${IAXCHANINFO(osptoken)}) to get the inbound OSP token.

You also can enable IAX message debug to validate the OSP token.

Thanks.
By: Russell Bryant (russell) 2006-12-07 05:59:25.000-0600

My personal opinion is that we should allow multiple instances of an information element.  Then, for multiple instances, the interpretation would be specific to the IE type.  In this case, you would combine all of the payloads from the IEs to make the single OSP token.

Since this is a pretty significant protocol level decision, I'll contact Mark and see what he thinks.
By: Russell Bryant (russell) 2006-12-07 15:00:57.000-0600

So, based on the discusson on the Astersk-dev mailing list, as well as my emails to Kevin and Mark directly, it looks like the method we would like to use here is to allow multiple instances of information elements.  That way, you would only need to add a single IE type.
By: Di-Shi Sun (homesick) 2006-12-07 15:40:29.000-0600

OK. We propose the new OSP token IE data structure in the following figure.

                    1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      0x34     |  Data Length  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Block Index  |               |
+-+-+-+-+-+-+-+-+               +
|        OSP Token Block        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The first octet of the data field is the OSP token block index starting from 0.

If there is nobody against this idea, we will change the patch and repost it.


By: Russell Bryant (russell) 2006-12-08 14:46:54.000-0600

Do you really need the block index at all?  I would think that the OSP token should just be reassembled in the order that the IEs are placed in the frame.  There will be no situation where somewhere in the middle, the information elements are re-ordered, so it should be safe without it.
By: Di-Shi Sun (homesick) 2006-12-08 15:37:31.000-0600

In draft-guy-iax-02, it said "A NEW message MUST include the 'version' IE, and it MUST be the first IE; the order of other IEs is unspecified.". We do not think it is necessary to change this rule. So adding an index is reasonable. It also makes things more reliable.
By: Russell Bryant (russell) 2006-12-08 17:37:25.000-0600

Alright, that's fair.  I'm on board with going with this proposed method, then.
By: Markku Korpi (korpim) 2006-12-08 17:38:04.000-0600

Sorry, I did not notice that the discussion of the topic continued on bug tracker, before submitting my proposal on the dev-list.

Can we turn the proposal 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. The information element identifier would have the format 0xFx, where the last 4 bits identify the segment number. This would avoid changing the rules specified in the RFC draft.

Alternatively, we can define only one SEGMENT IE identifier, and could even remove the segment no completely, but then the segments will need to be in sequence. I think, that it would be reasonable to specify that segments need to be in sequence, because segmentation is a new feature of the protocol.

When the SEGMENT IE is used for several long IEs in the same message, the Segmented IE identifies still the segments that belong together, except when the segmented IE itself is repeated. Therefore would need either a segment number or number of segments and can place it either in the lowes bits of the IE identifier or in the second octet of the data.

My proposal is to place the no of segments in the lowest bits of the IE Identifier, and therefore my (modified) segmentation proposal is:
                       1
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |    SEGMENT n  |  Data Length  |  SEGMENT IE identifier (OxFn)
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Segmented IE  |               |  Segmented IE = 0x34 (e.g. OSPTOKEN)
  +-+-+-+-+-+-+-+-+               |
  :      Segmented IE DATA        :
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

where n is the no of segments (instead of the segment sequence number).
By: Di-Shi Sun (homesick) 2006-12-08 19:07:24.000-0600

I had discussed with others. As I know, the idea of using a general purpose IE type or types to carry data is difficult to be accepted. A specific IE type is more acceptable. So we propose an OSPTOKEN IE.
By: Di-Shi Sun (homesick) 2006-12-14 13:25:59.000-0600

Hi All,

We updated the patch and the proposal using one OSPTOKEN IE type. It is for svn trunk 48414.

Would anyone please delete the old patch and proposal?

Thanks.
By: Serge Vecher (serge-v) 2006-12-14 14:42:21.000-0600

I just have a few comments about formatting: tabs, not spaces, should be used for indentation.
By: Di-Shi Sun (homesick) 2006-12-14 15:30:32.000-0600

Sorry for the spaces issue. Copy and paste to vi results. :) Would you please delete the old iax_osp_48414.patch? Thanks.
By: Serge Vecher (serge-v) 2007-02-28 14:21:58.000-0600

homesick, would you please update this patch for the latest trunk?
By: Di-Shi Sun (homesick) 2007-02-28 20:08:47.000-0600

Sure. I get stuck in another project. I will come back to this issue in two weeks.
By: Russell Bryant (russell) 2007-03-27 13:33:52

I'm ready to get this merged, but the patch is a bit more out of date than I can really justify fixing manually.  Most of the pieces of the patch don't apply anymore.  :(

Anyway, whenever you have time to update this, just let us know.
By: Di-Shi Sun (homesick) 2007-03-31 19:28:24

I will work for it ASAP and let you know. Sorry for the delay.
By: Di-Shi Sun (homesick) 2007-04-07 04:16:55

Hi All,

I update the patch to reversion 60397. IAX_IE_OSPTOKEN is changed to 53. 52 has been used for IAX_IE_VARIABLE.

I have not received the updated proposal for IAX_IE_VARIABLE yet. I will update it for IAX_IE_OSPTOKEN later.

Please erase the old patch.

Thanks.
By: Russell Bryant (russell) 2007-04-09 14:46:25

The remote variables patch may actually already do everything that you need.  It will transmit channel variables over IAX2.  If the OSP token is just another variable, then you may not need any extra code at all in chan_iax2.

What do you think?
By: Di-Shi Sun (homesick) 2007-04-11 09:46:45

Hi Russell,

My boss had discussed the remote variables patch with Kevin Flemming at VON. Kevin said the remote variables patch was for ad hoc value defined by user. The OSP token, defined by ETSI, should have its own unique IE type. So the OSP patch is necessary.

Thanks.
By: Russell Bryant (russell) 2007-04-20 16:13:37

This patch has been merged into the trunk in revision 61703.

Note that I made some changes.  The most important one is that instead of adding IAXCHANINFO(), I changed it to use the generic CHANNEL() function to get and set the OSP token.  Please let me know if you have any problem with the things I changed.

Thanks!