A task on my mind right now start is to start making sense of GlobalCall (GC), and seeing how this complements our Diva Server API (DS). Certainly, I don’t have all the answers today, but I can see some patterns emerging. First off, GC has a different philosophy to DS. It abstracts less and exposes nearly every part of the functionality of the adapter below, where DS tends to hide details in the adapter configuration and concentrate on the abstract mechanics of call control. There are benefits to each approach: GC offers maximum flexibility and control to the software developer, where DS can make the code portable across platforms and yet simple at the same time. GC treats call control and media (voice) operations as very separate streams, where DS tends to gloss over the differences and automatically associates a voice stream with every network connection, resulting in simpler code but less flexibility. In many cases this functionality is enough, but I know from past experience that developers from a GC background can be puzzled by the lack of explicit voice resource control, and the lack of a CT-bus to connect audio flows together.

But moving away from C and C++, there is quite a difference between GC and DS. In the DS world, we have got used to increasing demand for support for COM/.NET from C# and VB.NET developers. Today, there is a visible bias on our Developer Resource Centre towards .NET questions. In the GC world, the policy towards .NET has been to promote third party developer solutions, for example Pronexus. Again, there are advantages to each approach: as new functionality comes along, for example richer multimedia support, our APIs will support this functionality first, but over the long term, third parties tend to develop a broader range of library services for the developer, where we tend to focus on the area of our expertise, which is of course the media processing, switching and signalling.