Megaco v2 compilation, files to update by hand?

[Hakan Mattsson]

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> 
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
    megaco/src/engine/megaco_message_internal.hrl
    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
    to megaco/src/binary/megaco_ber_encoder_v2.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 
    megaco_ber_encoder_v2.
    
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?

/Håkan