Using the ASN2XML DLL
The latest release of ASN2XML features a DLL component that users can embed in their application programs. This makes it possible to output translated XML to different output mediums such as a GUI window.
Using the DLL is easy. The Asn2Xml.h header file that is included in the download package contains the Asn2Xml class that defines the program interface. The typical steps are to:
- Set the ASN.1 schema(s) using the addAsn1Schema method.
- Create a file input source using the setFileDataSource method (note: alternate data sources such as memory or socket can be created by creating an input stream object).
- Invoke the toXMLFile method to do the translation to a file. It is possible to create alternate output streams for output to different output mediums.
By default, the encoding rules are set to Basic Encoding Rules (BER) and its derivatives (DER or CER). It is also possible to translate PER-encoded data by using the setEncodingRules method.
That is basically it. A key performance advantage that can be gained is that if a lot of files that adhere to the same schema need to be processed (common in CDR applications), the schema file(s) would only need to be loaded and compiled once and a loop could then be set up to process the data files. If the command-line version of the tool were used, the schema files would need to be compiled for each data file processed.
Sample programs showing how to use the DLL are available in the sample_dll directory in the download package.
ooh323c moves forward
Thanks to recent financial support from companies such as Oxford Consulting Group and 2N Telekomunikace, the Objective Open H.323 stack has seen some considerable improvement in the last few months. The most noteworthy accomplishment was fixing a very elusive and subtle memory bug that could cause a crash after a relatively small number of calls (50 - 100). This followed on the heels of a fix to the Asterisk ooh323c channel driver that allowed Asterisk to work with the latest stable version of ooh323c. Once corrected, load testing of several thousand calls showed great stability. A luxury/performance car manufacturer is now using Asterisk with ooh323c to make car-to-car calls.
So contrary to some reports floating around on the Internet, ooh323c is not dead. We continue to upgrade it and improve stability (although we are not doing any major new development such as adding T.38, or H.450, or video support). The latest release is our most robust and stable yet, it can be downloaded from http://www.obj-sys.com/telephony-objective.shtml.
CSTA .NET API
Objective Systems is pleased to announce that version 1.0.0 of a new software product called CSTADLL is now available.
For some time Objective Systems has offered CSTA API kits that take the form of three separate kits, one for each CSTA phase. These kits contain C++ class definitions created using ASN1C against the ACSE and CSTA ASN.1 specifications for the specific phase, along with C++ samples and an interactive console-mode test client with its C++ source code that allows a user to establish a CSTA session with a PBX device.
The CSTADLL software is different from the C++ CSTA API kits in the following ways:
- The CSTADLL software supports all three CSTA phases in one kit.
- The CSTADLL software is targeted at the Microsoft .NET (2.0 or higher) platform. Developers using CSTADLL can use the classes that it exposes from any .NET language, such as C# or Visual BASIC.
- The CSTADLL software includes some helper classes in addition to the generated classes. These helper classes do things like make some common CSTA operations easier to do and manage a TCP/IP session with a PBX device. A developer using CSTADLL has the choice of using the helper classes, the generated classes, or a mix of both.
- A developer using CSTADLL can specify an asynchronous callback that will be invoked whenever asynchronous messages are received from the PBX device. The most common use of this feature will probably be monitoring operations.
- The CSTADLL software has explicit support for a couple of additional PBX devices, namely the Panasonic KX-TDA and KX-TDE, and the Alcatel OXO.
The CSTADLL version 1.0.0 software kit contains the following items:
- A Microsoft .NET 2.0 DLL that exposes classes generated by ASN1C from the ACSE and CSTA ASN.1 definition files for all three phases as well as a few helper classes as described above.
- An interactive console-mode client program with its C# source code that can be used as an illustration of how some CSTA operations can be carried out using the DLL.
- A simple GUI client program with its Visual BASIC source code that can also be used as an illustration of how some CSTA operations can be carried out using the DLL.
- A few sample programs. Currently only C# samples are provided. As additional releases of CSTADLL are done we hope to add more samples in C# and other .NET languages.
- The ACSE and CSTA ASN.1 specifications for each of the three phases. These are the specifications that were used to generate the classes that are included in the DLL.
- The source code for all of the classes as generated by ASN1C.
- Documentation, both in PDF format and HTML format.
To download a CSTADLL kit for evaluation, visit the CSTADLL Product Page.
iPhone Support in ASN1C
Objective Systems is pleased to announce availability of ASN1C runtime libraries for the iPhone.
Given the ubiquity of ASN.1 applications and the likelihood of more of them being needed on the iPhone, we have begun supporting ASN1C runtime libraries compiled against the iPhone OS. We currently only build our libraries against the version 3.1.3 SDK, but we can build against 2.2.1 as well.
Support for the iPhone brings our phone support full-circle, with libraries compiled against SymbianOS, multiple versions of Windows CE, Android, and Java Micro Edition.
Using ASN1C-generated sources with the iPhone is very straightforward. Typically programs for the iPhone are coded in Objective-C, Apple’s object-oriented answer to the C programming language. Even though ASN1C doesn’t emit Objective-C code, Objective-C is a strict superset of the C language, so any Objective-C compiler will compile C code generated by ASN1C.
Objective-C will also work with regular C++ code as well. There are, however, some caveats to this, as outlined by Apple in their developer guide. The main point of concern is that the object model used in Objective-C is incompatible with the one used in C++; therefore, C++ classes may not inherit from Objective-C classes and vice versa.
Those interested in deploying applications on the iPhone OS are encouraged to examine Apple’s iPhone Application Programming Guide for a full reference on the subject.
Compiling code for the iPhone is surprisingly easy (at least in this developer’s experience), even if you’re not using the XCode IDE. Objective Systems provides a platform.mk file that should contain all the necessary definitions for compiling against the iPhone SDK, provided that it is installed in the default location. A sample compilation will look a bit like this:
/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/gcc [...] -isysroot /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.1.3.sdk -arch armv6 -mthumb [...] writer.c
The relevant observations (obviously some text has been removed for clarity):
gccis invoked from the iPhoneOS platform directory.- The ARM architecture is targeted (
-arch armv6) using the thumb instruction set (-mthumb). - The SDK root is set using the
-isysrootswitch.
That’s really all there is to it. Questions or comments? Email us at support and we’ll be glad to help.
Recent additions to time type encodings in ASN.1 standards
It was with some surprise that I discovered recently that new encodings for ISO 8601 date/time types had been added to the X.691 PER encoding standard. The rumor for many years was that ASN.1 was finished and nothing new was going to be added. It therefore came as a pleasant surprise to see new capabilities introduced.
This particular new capability seems very logical. Date/time types are prime candidates for optimized encoding given the short numeric ranges used for the particular components. The new encodings rarely, if ever, take up more than 32 bits, and they are straight-forward to understand. This adds even more capability and compactness to ASN.1 PER, which IMHO is still the most useful compact standardized binary encoding around. Recent attempts to come up with binary encodings for XML have the feel of trying to fit a square peg into a round hole.
As to our implementation of these new rules, they will be in ASN1C v6.3.1 which will be released in a week or two. Support in the ASN1VE Viewer/Editor will most likely not occur until this summer.
So well done ITU-T! My only request in the future is to please provide some kind of notification system for standards updates so that we are not caught completely off guard.
Hosted Floating License Server
Posted by Yi in Uncategorized on April 19th, 2010
The floating license server Objective Systems currently provided to users is for use within their development environments. A new design will be available soon that would be hosted at our site. In the future, a floating licensing user won’t need to install and maintain a floating license server product at their place. They would be able to connect to Objective Systems for the license.
With the new floating license server, you will be provided with the licensed products - ASN1VE, ASN1C, XBinder etc. - along with a license file (osyslic.txt). After installation of the licensed product is complete, copy the osyslic.txt file into a directory in which the executable file is installed. And you should be able to run the product in licensed mode if there is a concurrent slot available for the product within the server.
If you are a current floating license user, you may have installed the server on your site, and created an osysfloatlic.txt configuration file to use with the floating license client programs (ASN1VE, ASN1C, XBINDER). With the floating license server hosted at Objective Systems, the configuration file osysfloatlic.txt is no longer supported. You should use the osyslic.txt file provided with the licensed products to connect to the license server andrequest for a concurrent slot.
If you choose to use the floating license server hosted at Objective Systems, life is easier for you. You can stop reading here.
We have customers all over the world which may create a performance issue if a customer in, for example, China would like to use this option. One option for a customer to host the server on their site still exists. If you choose to host the floating license server at your site, you will get two kinds license files: osyslic_server.txt and osyslic_client.txt in addition to the licensed products (ASN1VE, ASN1C, XBINDER etc) and the license server kit. The license file (osyslic_server.txt) should be renamed to osyslic.txt and installed in the bin subdirectory in the server installation. The license file (osyslic_client.txt) should be renamed to osyslic.txt and installed in the bin subdirectory in the licensed product.
You may find more information related to the floating license server in the following README files (those files are included in the server kit as well):
README for Windows
README for other platforms
If you host the license server at your site, osysfloatlic.txt file is still supported, although this is not the preferred way for a user to connect to a floating license server. The logic in determining a floating license server to connect to will be as follows:
- Check for the presence of an osysfloatlic.txt file as was done before and, if present, attempt to connect using the information in the file.
- If not present, read the osyslic.txt file and check for floating license information. If present, use this file to connect to the server.
CSTA All-Phase Software
Work is progressing on a CSTA All-Phases software collection for Microsoft platforms. This collection will include a .NET 2.0 DLL, a couple of sample clients (a GUI client and a console-mode client) that can be used for testing, and numerous other samples.
The DLL will include the following things:
- All of the classes generated by ASN1C for the CSTA and ACSE ASN.1 specifications for all three phases.
- Three classes, one for each phase, that will allow you to communicate with any PBX device that uses standard BER communication.
- Three classes, one for each phase, that will allow you to communicate with any PBX device that uses IETF communication (BER with a two-byte length prefix).
- Numerous additional classes for various specific PBX devices that have special communication protocols.
- Helper classes for tasks like managing communication to the PBX and holding CSTA operation codes as constants.
The GUI client will be a simple client that will allow you to enter specific commands and see the results. Asynchronous data, such as monitor packets, will be displayed in a separate box from the one used for synchronous results. The console-mode client will be similar to the current CSTA C++ test client programs; the client will prompt you for the needed input and display results from the operations you choose.
ASN1C 6.3 GUI Improvements
One of our longstanding items for improvement in ASN1C has been the interface used to wrap the command-line tool. In ASN1C 6.3, we made a lot of changes to the GUI, both in the way it is programmed and in the presentation to the user.
Since Qt was released under the LGPL, we have transitioned from our commercial license (3.3) to the open-sourced (4.6). ASN1C 6.3 should showcase somewhat better integration with your chosen operating system in addition to some nicer icons and other features.
We also made some changes to our project format. The new GUI will read old projects, but project files created with the new GUI will be incompatible with the old. This was necessitated by essentially having to recode the GUI hooks from scratch. Reorganizing the interface (see below) required remapping some of the options, and therefore relocating them in the project files. Meta data are now included in the project files, so it will be possible to tell when you load an older project with a newer interface.
On the outside, the interface has been redesigned to use a tabbed approach to options instead of a large number of steps in a Wizard. The old wizard is still there, but options common to all languages have been isolated into one screen, while language-specific options now only occupy one screen of their own:
The net effect is fewer screens to navigate through, better organization, and a better-integrated experience.
In the future, we also plan to convert the documentation for the GUI into a Qt help resource instead of using the old text browser element.
XML Data Binding on Android
We’ve already added support for Java code generation to XBinder. Now, support for Android is coming soon. This will be useful to people in at least two camps:
- XBinder Java users who want to reuse code on Android
- Android application developers who want a data binding solution but find out that Android doesn’t include JAXB
For those who aren’t familiar with Android, it is the open source OS for mobile phones that originated with Google. And, it runs Java code - sort of. It actually has its own VM, called Dalvik, which runs Dalvik Excutable (DEX) code. Android tools convert Java byte code to DEX. So, basically, Java code can run on Android just by using this conversion tool.
The problem, for you and for us, is that Android doesn’t implement the full Java 5 API. Things like JAXB and StAX are missing. Thus, no data binding and no nice “pull parser”, streaming API for XML. Enter XBinder’s Android support.
Our Android support provides the missing pieces. Instead of JAXB, you use XBinder as your data binding solution. Given your XML Schema, XBinder generates classes that model your data, along with methods for encoding/decoding to/from XML. No more writing code to parse your XML (check out our comparison of coding with and without XBinder). Using the StAX API, XBinder does the parsing for you.
Now, if you are paying attention, you’ll notice that I said Android is missing StAX but XBinder uses it. This is one of the more interesting aspects of our Android support. One of those missing pieces that XBinder provides is an implementation of StAX (as complete an implementation as was required by XBinder). Of course, you are free to take your favorite StAX implementation, get it working on Android, and use it with XBinder. However, we think our implementation is special in that 1) it is ready to use and 2) it has a small footprint, thanks to XmlPull.
What is XmlPull? It is another “pull-parser” API very similar to StAX. While Android doesn’t come with StAX, it does come with an implementation of XmlPull. We kept our runtime small by implementing StAX as a thin layer over XmlPull. Thus, the bulk of what is needed is already present on the Android device.
XBinder’s Android support is expected to be available in a few weeks.
Improved Large File Support in ASN1VE
One of the issues we hear about often concerning ASN1VE is problems working with extremely large files. A common use case for ASN1VE is using it with with telecom billing files such as TAP3, NRTRDE, or other CDR formats and these files can get quite large.
The ASN1VE 2.0 release attempts to solve some of these issues. One area of improvement is in not attempting to decode all repeating records within a large repeating construct (for example, the Call Event Details list within a TAP3 file) at once. Decoding several thousand records at once does not make much sense because a user could not view them all anyway. So the new way of doing it is to decode up to some configurable amount (1000 is the default) and end the list with a special “More…” icon. The user can then click this icon to expand the next set, and continue to do this to incrementally decode as many records as desired.
Of course, if the user does have a need to decode large quantities of data at once and get it loaded into the tree view (perhaps to do a search), it is possible to change the “Maximum number of records decoded at one time” configuration parameter. The user will just need to sit and wait patiently in this case and make sure they have lots of memory available in their PC.