[asterisk-dev] [Code Review] Audit and reformat IAX2 definitions to match the IANA-registered values.

Tilghman Lesher tlesher at digium.com
Mon May 24 12:09:34 CDT 2010



> On 2010-05-21 07:40:55, Kevin Fleming wrote:
> > /trunk/channels/iax2.h, lines 181-182
> > <https://reviewboard.asterisk.org/r/672/diff/1/?file=10340#file10340line181>
> >
> >     My recommendation for how to deal with the conflict here is this:
> >     
> >     1) Request two new IE assignments from IANA for OSPTOKEN and VARIABLE.
> >     
> >     2) Modify Asterisk to use the new IE values by default when sending these IEs, and to optionally use the old values when configured to do so (probably on a per-peer basis).
> >     
> >     3) Mark the old values in Asterisk as 'deprecated', but continue to accept them indefinitely.
> >     
> >     4) Request that IANA mark 0x35 for OSPTOKEN as deprecated in favor of the new value allocated in step 1.
> >     
> >     5) Don't ever do this again :-)
> 
> Russell Bryant wrote:
>     Is there any way to get the registry changed to match what we've been using so we don't have to do this mess in Asterisk?  I would put money on betting that Asterisk is the only IAX2 implementation that supports VARIABLE and OSPTOKEN, since they are relatively new and not core protocol functionality.
> 
> Kevin Fleming wrote:
>     I honestly don't know; I'm sure it is possible, but I've not seen any documentation of how to go about it. Presumably it would involve Ed Guy's assent, since he's the 'expert' they have in their records for doing 'expert review' of registry additions. I'll talk to him and see what might be achievable.

We can actually deal with this without a change in standard.  OSP tokens are base-64 encoded and therefore will NEVER contain an '=' character, whereas IAX_IE_VARIABLE will ALWAYS contain an '=' character.

I suggest that we request a new IE for IAX_IE_VARIABLE, then use the above logic to verify whether the OSPTOKEN field contains an actual OSP token or an IAX2 variable and go from there.  This provides for maximum compatibility with only a very slight cost in logic time.  Both of these types are exceptionally rare anyway.


- Tilghman


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/672/#review2054
-----------------------------------------------------------


On 2010-05-21 09:04:28, Kevin Fleming wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/672/
> -----------------------------------------------------------
> 
> (Updated 2010-05-21 09:04:28)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> While preparing to document some new possible IAX2 support, I cross-checked the IAX2 control subclass and information element definitions in iax2.h against the registered values in the IANA registries. This comparison was harder than it needed to be because the values in iax2.h were in decimal and not hexadecimal, so the attached patch changes that.
> 
> However, while doing this comparison, I found a mismatch that we'll need to discuss how to address. We are using 0x34 as IAX_IE_VARIABLE but in the IANA registry this value is for IAX_IE_OSPTOKEN (which we have 0x35 for). Changing this will break backwards compatibility, but as it stands, we are not compatible with the IANA-registered definitions, so something has to change or implementations written to the specifications won't interoperate with Asterisk properly.
> 
> 
> Diffs
> -----
> 
>   /trunk/channels/iax2.h 264951 
> 
> Diff: https://reviewboard.asterisk.org/r/672/diff
> 
> 
> Testing
> -------
> 
> Compile testing; there are no functional changes here yet.
> 
> 
> Thanks,
> 
> Kevin
> 
>




More information about the asterisk-dev mailing list