Closed nickvsnetworking closed 2 years ago
From my recollection, the CDR spec depends on the CAMEL (CAP) and MAP ones, and maybe few others. So, when you upgrade to newer ASN.1 files from the 32.298, you better need to do the same with the files from the CAMEL 29.078 and MAP 29.002 ones ; otherwise, you may have some inconsistencies within some object declarations. I am not sure this will solve your issue, it's just a hint.
And for the extract.py
script (which is really quick'n dirty), some parameters may be hardcoded and requiring to be updated to process new files.
I am currently working on a full ASN.1 3GPP update to Rel.16, but I can already say that this GSNAddress
object issue seems to come from the ASN.1 module provided in the 3GPP document: the object is both imported from GenericChargingDataTypes and defined locally in GPRSChargingDataTypes.
To make it compile smoothly, it is only a matter of commenting or the import or the local definition in the module GPRSChargingDataTypes.
If you git pull
from now, you'll have a working CDR ASN.1 module from the 3GPP Rel.16.
Hi folks,
I'm trying to compile the updated 3GPP TS 32.298 ASN1 definitions (Release 13 specifically).
They already exist in the repo today here, but only for an older release.
So I hopped on the 3GPP website and downloaded them, extracted all the files into a folder and renamed to .asn, then tried to compile, and I'm getting the below:
I've had a look at how it's done in the older version in the repo for some hints as to where I was going wrong:
GSNAddress does get defined in multiple ASN1 definitions by the looks of it, but I assume this can be handled? I tried adding the -
fverifwarn
arg when runningpycrate_asn1compile
but didn't' change the behaviour.Here's the ZIP file of the TS 32.298 ASN1 defs from 3GPP, in the folder I'm trying to compile, any pointers to help this compile so I can update to release 13 would be much appreciated: 32298-d90_ASN1.zip
Thanks,
Nick