Thoughts on the current state of ASN.1 and XML technologies.

Viewing Huawei IMS CDR’s in ASN1VE (Updated)

This is an update to the original blog post on this topic done on June 28, 2011 at http://www.obj-sys.com/blog/?p=355. At the time, we did not have support in ASN1VE to process 3GPP TS 32.297 CDR headers, which is what the Huawei IMS CDR’s mentioned in the post contained. Although it is still possible to skip these headers, this is not reliable as the headers may be variable length. The updated procedure to view these CDR files with a newer version of ASN1VE is as follows:

  1. Open the CDR file. The “Assign All Items Wizard” popup window will appear:

    wizard1

    Select the “cdr” option (not “ber”) and click Next.

  2. The second wizard popup will appear:

    wizard1

    On this popup, check the “3GPP TS 32.297 Headers” radio button and click Next.

The normal procedure for assigning an ASN.1 schema file can then be followed from that point forward. The result will be the display of the CDR file with the headers fully decoded.

An example of this can be found in the sample/ts32297 directory within an ASN1VE installation.

No Comments

New XBinder Release

We are pleased to announce the release of XBinder 2.6.1. XBinder is an XML schema code generation tool (also commonly known as an XML data-binding application) that generates C/C++, Java, and C# code to encode/decode schema instances in XML or JSON.

This is primarily a maintenance release providing bug fixes and improvements accumulated over the past year. One significant new feature that was added was support for Visual Studio 2019. For further details on fixes, please refer to the change log at https://www.obj-sys.com/support/change-log-xbinder-2.6.php.

A free 30-day trial may be downloaded from the following URL:

https://www.obj-sys.com/products/xbinder/download.php

No Comments

ASN1C kits available for older Linux 64-bit systems using older glibc and ld libraries

A new ASN1C Linux 64-bit evaluation kit is now available for ASN1C version 7.3.3 to address problems reported by users with the current package. One problem reported was when executing the ASN1C binary, an error similar to this may be displayed: “version ‘GLIBC_2.12’ not found”. A second problem was in linking with libraries in the package in which an error to the effect of “unrecognized relocation” or “bad value” would be reported. This is because our binaries are now built with a newer version of glibc and ld (such as, currently, glibc 2.23 and ld/binutils 2.26). Older systems that have glibc versions such as 2.12 will fail to build with these libraries.

This new package contains executable files and libraries built with an older version of glibc.

The description of the existing package on our download page has been changed to:

  • Linux Ubuntu 16.04 (x64) 64-bit, glibc 2.23

The new package is

  • Linux Centos 6.5 (x64) 64-bit, glibc 2.12, no GUI

Note that in both of these cases, even though we have listed the specific Linux distribution used, the packages should work on any reasonably up-to-date Linux distributions such as SUSE, Fedora, Debian, etc. The only factor in determining which one to use would be the version of glibc.

Also note that the package that uses the older glibc does not contain the ASN1C GUI as it required the newer glibc version be available.

To check which version of glibc your system is currently using, enter the command “ldd –version”. This will print the version of ldd and glibc, with output similar to the following:

  • ldd (GNU libc) 2.12

No Comments

V2X API Library Update

With the recent release of ASN1C 7.3.3, we’ve also updated our V2X API library.  We’ve added support for ETSI TS 103 301 SPATEM, MAPEM, IVIM, SREM, and SSEM messages.

Our V2X API library provides support for encoding V2X (Vehicle-to-everything) messages.  The library is available for C++ (as a shared library) Java (JAR), and C# (DLL).   A simple Python wrapper for the C++ shared library is also provided.

Users of previous versions of the Java or C# library should be aware that a slight change was made: classes in the v2x package/namespace have been split into one of two sub-package/namespaces: v2x.j2735 or v2x.etsi.

Users of previous versions of the C++ or Python library should be aware that the shared library has been split into two files (*_j2735 and *_etsi).  Python users must have both libraries present as the Python wrapper library requires both of them.  C++ users can use whichever one is appropriate.

No Comments

Extending JSON Encoding Rules (JER)

ITU-T standardized the JSON encoding of ASN.1 data in X.697 (JER), but we believe customers want to support use cases the standard doesn’t address.  This post briefly describes two extensions to JER that we’re planning to implement in our ASN.1 compiler, ASN1C.  We plan to implement the first extension (for contents constraints) as an undocumented feature in a 7.3.x patch release in the September-October time frame.

Extension for Contents Constraints

The first extension relates to encoding of BIT STRING or OCTET STRING with a contents constraint.  For example:

OCTET STRING (CONTAINING SomeType)

In short, the purpose of this first extension is to allow the contained type to be encoded in JSON just as it would be encoded if it weren’t a contained type, instead of encoding it as a string of hexadecimal characters.  This extension is all about making the JSON more human-readable.  Here’s an example:

Say your ASN.1 has something like this:

   my-bit-string BIT STRING ( CONTAINING TwoStrings )
…

TwoStrings ::= SEQUENCE {
   one UTF8String,
   two UTF8String
}

The standard JER encoding would look something like:

"my-bit-string" : { "value" : "7B20226F6E6522203A20226D6F6E6579222C202274776F22203A202273686F7722207D", "length" : 280 }

Our extension would instead produce something like:

"my-bit-string" : { "value+" : { "one" : "money", "two" : "show" } }

Extension for Values of Unknown Types

The second extension relates to encoding values of unknown types, which may appear as SEQUENCE/SET/CHOICE extension elements or in open types.  It isn’t possible to convert values of unknown types from BER or PER to standard JER.  Since its type isn’t known, the value is stuck in BER or PER, so to speak.  So, in short, the purpose of our second extension is to enable converting the rest of your data to JSON while preserving what can’t be properly converted (in case you need it) and making a round trip back to the original encoding possible.  This is done by embedding the original encoding in the JSON in hexadecimal form, along with some supplemental information where necessary.

Below are some examples of the JSON that would be produced using our extension.

Handling an unknown open type value:

"some-open-type-element" : { 
   "encoding-rules+" : "BER",
   "encoded-data+" : "03020101"
}

Handling unknown SEQUENCE or SET extension elements:

"extensions+" : {
   "encoding-rules+" : "BER",
   "encoded-data+": [ "hex for extension X", "hex for extension Y" ]
}

Handling an unknown CHOICE extension element:

some-choice-field : {
   "extension+" : {
      "encoding-rules+" : "PER",
      "encoded-data+" : "04020301",
      "encoded-per-index+" : 5
   }
}

No Comments