Megaco v2 compilation, files to update by hand?
Thu Aug 22 11:39:39 CEST 2002
On Wed, 21 Aug 2002, Peter-Henry Mander wrote:
Pete> I am using the Megaco protocol version 1 to build a Gateway Controller
Pete> and Media Gateway in Erlang. Now I hope to compile the ASN.1 file for
Pete> Megaco v2. The changes between the two version don't affect this
Pete> project too much, it's mainly to prove the point of keeping up to the
Pete> minute on the standard.
Pete> Here's the problem: I have successfully compiled Megaco version 2
Pete> ASN.1 into Erlang using 'erlc'. At this point, it seems there maybe
Pete> other source files in the Megaco project that need updating and kept
Pete> synchronised with the new version of the protocol.
No not really. It is possible to introduce a new encoding or a new version
of an existing encoding without any doing any changes in the Megaco application.
Pete> Which other files in the source directories and include paths need
Pete> updating after compiling the ASN.1 so that my application development
Pete> will support Megaco version 2?
I would do the following:
- Put the new ASN.1 stuff under megaco/src/binary
- Copy the .hrl file that the ASN.1 compiler generated
to megaco/include/megaco_message_v2.hrl and re-apply
the convenient default values found in ...v1.hrl.
- Manually verify that all records defined in
is compatible with the ones in the new ...v2.hrl file.
This is needed in order to ensure that the Megaco
engine is not affected by the new internal form.
- Copy the megaco/src/binary/megaco_ber_encoder.erl
and change the ASN.1 encoding/decoding module
to the newly generated one.
- Replace the ...v1.hrl the include statements in your
application to ...v2.hrl.
- Configure the Megaco application to use the
Now you should be able to use v2 of the Megaco protocol.
If you want to mix v1 and v2 messages it is more complex.
You need to introduce yet another encoder module that
decodes the version part of the message header. This code
can be copied from the decoder that the ASN.1 compiler has
generated. Then you simply switch on the version number in
order to invoke the correct decoder. The corresponding
change is also needed for encode.
As the v1 and v2 internal forms are not fully compatible,
you need to isolate the version dependent parts of your
application and provide both a v1 and v2 implementation
of them. Each one uses its corresponding megaco_message
header file. Even if it is possible to treat the records
as tuples I would avoid. In the megaco user callback
module you can switch on the protocol version to do decide
which application module that should do the work.
What did I forget?
More information about the erlang-questions