The current one cannot be resolved. This issue was introduced
in the version9 to version12 upgrade in git revision
b61d0bc663.
Signed-off-by: Holger Hans Peter Freyther <zecke@selfish.org>
So what the Erlang asn1ct does is: Decode the incoming EXTERNAL type,
convert it to the 1994 format and hand it to the user program.
The encoder is opposite: Take what the user supplies (in our case 1994)
and then transform it to 1990 before handing it to the actual encoder function.
The only problem is: The 1994 format does only support OCTET STRING as actual
embedded data type, whereas the 1990 format can also indicate
'singla-asn1-type', i.e. a constructed type.
So since that information is already lost before we ever get the record from
the Erlang asn1 decoder, it will be re-encoded as OCTET STRING :(
Until this is fixed in the asn1ct/asn1rt code, we have to use this workaround...
This is a non-standard MAP package creating ROSE CONTRACT information object
class instances which will later be used by TCAP APPLICATION-CONTEXT
information object classes that in turn will formally associate the
OPERATION-PACKAGES with the application context names.
You need to provide your own ./priv/map.pcap file to run the test.
Results from a real SIGTRAN link:
test/map_codec_tests.erl:49: PCAP: 191.795 s
test/map_codec_tests.erl:50: Parsed 807605 PCAP packets
When trying to asn1rt:encode() the DialoguePortion in ber_bin mode,
we get something like
2> asn1rt:encode('MAP', 'MapSpecificPDUs', {'begin', Msg}).
{error,{asn1,{function_clause,[{asn1rt_check,transform_to_EXTERNAL1990,
[[<<96,15,128,2,7,128,161,9,6,7,4,0,0,1,0,5,3>>],
[asn1_NOVALUE,asn1_NOVALUE,{0,0,17,773,1,1,1},'EXTERNAL']]},
{'MAP',enc_EXTERNAL,2},
{'MAP',enc_MapSpecificPDUs_begin,2},
{'MAP',enc_MapSpecificPDUs,2},
{'MAP',encode,2},
{asn1rt,encode,3},
{erl_eval,do_apply,5},
{shell,exprs,7}]}}}
Harald Welte
Norbert Hartl