[asterisk-dev] libpri

[Timo Teräs]

Matthew Fredrickson wrote:
> Kevin P. Fleming wrote:
>> Timo Teräs wrote:
>>> Would you prefer that it was done using some ASN.1 compiler + library?
>>> (which one to choose from the many? is the extra bloat and  dependency to
>>> external asn1 library acceptable?). Alternative is to replace the macroes
>>> with something usable.
>> Certainly that seems like a worthwhile path, but any compiler/library
>> that is chosen will need to be under a reasonable open source license.
>> We've already had one situation (chan_ooh323) where the ASN.1 compiler
>> used to generate the GPL-licensed C code was not itself open source,
>> which makes the C source code not very manageable for users who want to
>> modify it.
> 
> Thanks for the response on this issue Kevin.  Timo, I think in order to 
> make supplementary services easier to implement, it would help very much 
> to have an asn1 compiler.  When I looked a few years ago (when I started 
> writing SS code), there wasn't really any good options.  I think now 
> though, there's a tool called asn1c and it appears to be license 
> compatible (BSD), so that might be one option for doing supplementary 
> services in the future.

I checked out asn1c and it does look relatively good: it seems to support
having the generated struct in stack (ie. not dynamically allocating it),
thought it might dynamically allocate space for struct members at decode
time. I just tend to avoid dynamic allocations if possible.

It doesn't really affact the code amount in libpri though: we still need to
convert the asn1c generated structures to libpri internals. It'll make you
not need to know how BER/DER works, which might or might not be good thing.
I guess it's more on the good side.

I didn't look how well it would works with:
- supporting both local operation code or OID based operation code
- if we have ASN.1 encoded PDUs inside other ASN.1 PDU the library might
require to allocate the inner PDU twice

Cheers,
  Timo