.NET
Velocity
Velocity is written by .NET developers for .NET developers, so we understand exactly how you want to write your application, and because it’s written in .NET, you are free to choose any .NET language to develop with it e.g. VB.NET, C#, C++.NET, Delphi. It also means all of your favourite debugging and documentation tools are available to you, and you can write your application in an environment that you are familiar with e.g. Microsoft Visual Studio. When you go to deploy it, there’s no proprietary framework to install. Your application is an actual .NET EXE, not a script to be interpreted by a proprietary interpreter.
Additionally, because Velocity is written directly in .NET, it is very close to the telephony drivers and this gives obvious performance benefits, requiring less CPU, memory etc.
Because you’re writing your application in a .NET language, all of the features of .NET are available to you. You’re not relying on Velocity to provide functions such as FTP, Email etc. These (and basically anything you can think of) can all be done in .NET. The potential is unlimited.
Other Toolkits
Some other toolkits have proprietary IDE’s and languages which you must learn. This means extra time learning the language and the development environment. It also means new features are slow to develop as the vendor is not only trying to write a telephony framework but is also trying to write an IDE and a language. Glorsoft is not in the business of writing IDEs /compilers / interpreters, and does not pretend to be. We write telephony software only and we leave the IDE and language development to Microsoft. Some toolkits use a “walled garden” approach. This means they provide a GUI which allows you to drag and drop controls on screen to do what you need. The main problem with this approach is that if what you want to do does not have a block / cell / control in the development environment, it may prove difficult or even impossible to do what you need to do.
Some other toolkits which have been around for a long time were written long before .NET was even thought of. The problem with this is they were not designed with .NET in mind. Many of them were written using some form of COM, which is now an old technology. Microsoft has provided a way for these legacy applications to work in .NET, but really it’s putting a shiny new .NET wrapper around old legacy code which relies on COM. It does this by automatically generating and adding an extra layer between .NET and the COM object called the Runtime Callable Wrapper. This means that between your code and the Dialogic API you have two extra layers – the RCW and COM. It’s easy to know if a library is a native .NET library or a legacy COM library. When you add a reference to your project, do you need to select the COM tab to see the library, or can you select your library directly from the .NET tab? If you need to select it from the COM tab, it is legacy software and can only be used in .NET through the Runtime Callable Wrapper. This adds extra overhead and either requires a more powerful machine or means that you can process less calls per server. It also means there are more things that can go wrong. Since very early versions of .NET (~10 years ago) Microsoft have recommended that developers do not use the Runtime Callable Wrapper to use old COM code in the long term. They recommend redeveloping your code to work natively in .NET. However many other toolkit providers have ignored this advice and continue to sell legacy code, with unsuspecting developers developing their new applications on old technology.
Flexibility
Velocity
Velocity is flexible. It is a DLL which is linked into your code and because of this you can use it anywhere – in a form, in a console application, in a service. It doesn’t rely on a Windows form events queue.
Other Toolkits
Some other toolkits deliver their functionality through ActiveX controls, which are designed to be run on a form. You CAN get them to run in other areas where they were not designed to run e.g. as a service , but it’s not recommended due to problems with some ActiveX controls relying on the Windows event queue etc.
Even if you do run them in a form, there is an extra overhead when using them in .NET. Because they weren’t designed with .NET in mind, they won’t work natively in .NET. But they can work under certain circumstances because Microsoft have provided an interface to support this legacy code. If you read the “.NET” section at the beginning of this article it explains the difference between .NET libraries and legacy COM code used through the extra layer called the Runtime Callable Wrapper. ActiveX controls are COM controls, so you already have to use the extra Runtime Callable Wrapper layer and the COM layer. But it gets even more complicated. Using an ActiveX control means you need to use yet another layer called the ActiveX Hosting Layer. This layer fools the ActiveX control into thinking it’s being hosted in an ActiveX control host. Using this extra layer (on top of the already Extra RCW and COM layers) allows a .NET application to use legacy ActiveX controls, but it really is a case of trying to fit a round peg into a square hole.
It’s easy to see if a library is an ActiveX control. In your project, in Solution Explorer, expand the References section. Right-click on the reference you have added (you’ll already know it is a legacy COM library because you had to select the COM tab when you added it as a reference). In the properties of the reference, if the value in the FileType field is ActiveX, then you are using a legacy COM ActiveX control and all of the above problems apply.
Microsoft do not recommend using COM as a long term strategy and instead recommend that applications are migrated to be native .NET applications.
Ease of Use And Deployment
Velocity
The library interface to you is entirely synchronous, so it abstracts away all of the difficult asynchronous programming. Additionally, the multithreading is taken care of so you don’t need to spend time on threads, semaphores, queues etc. We’ve done all of that for you. And finally, when you go to deploy it, there’s no proprietary framework to install (other than the Microsoft .NET framework which will most likely be on the server anyway), and at startup Velocity will automatically detect what boards are in the system and use them.
Other Toolkits
Some other toolkits make use of only asynchronous function calls and events. This can make programming them very difficult as the developer needs to keep track of states etc and complexity increases exponentially as the number of states increases. You can use states in velocity if you wish, but there is no requirement.
With some other toolkits, you need to design and implement the multithreading architecture before you even code a single line of telephony code. Velocity does this for you.
With some other toolkits you need to maintain a separate profile to keep track of what boards are in the system. If you add/remove/replace a board you need to remember to rebuild this profile so the toolkit knows about the new configuration. If a user forgets to do this, the toolkit will not know what boards are available and may fail to run properly, or at all.
Telephony Devices Support
Velocity
Velocity supports 2 ranges of telephony devices. They are both made by Dialogic. One range is the Dialogic “Classic” devices (e.g. boards: D/4PCI, D/120JCTLS, D300JCT, DMV1200BTEP etc and software: Host Media Processing 3.0). The other range is the Dialogic Diva range (formerly Eicon). These devices include boards: Diva Analog, Diva BRI, Diva PRI and software: Soft IP. They are all made with the great quality of Dialogic but depending on your exact requirements a board from one range might be more suitable / cost effective than the corresponding board from the other range. When you compile your application developed with the Velocity toolkit, it is not compiled for any particular type of boards. So in your lab you can have a D/4PCI for development, but when you deploy to the customer site you can run the EXE, unchanged, on a Diva2PRI (2 x ISDN E1 ports = 60 calls). The toolkit automatically detects and initializes available boards. It is possible to mix both Dialogic “Classic” boards and Dialogic Diva boards in the same system. In fact, the same EXE can use any combination of boards at the same time.
Other Toolkits
Some other toolkits support only a single range of boards. This limits choice and may mean for example that your application cannot be used on a particular site because there is no board available in that range to interface to the customer’s telephone system.
In toolkits that do support more than one range of boards, it is usually the case that an application is compiled to target a specific board range. If you need to target another range of boards, you need to recompile. This means maintaining multiple projects, each targeting a different range of boards.
Some toolkits that do allow you to use more than one range of boards are interpreted scripts, and before the application starts it can be configured to look for a certain range of boards. But generally only one range of boards can be used at a time.
System Status
Velocity
Velocity allows you to piggyback on the system logs i.e. you can write your own log entries to the system logs so everything is contained in one log file.
Velocity has two built in loggers - a console logger (mainly for use during development) and a text file logger (mainly for use during runtime).
You can also write your own logger class (by subclassing a built in logger base class). This class will receive logging information from the system and you can do anything you want with the log entry (e.g. write it to an encrypted file, write it to a database etc). You can register multiple custom loggers per application.
The Velocity SDK includes a sample Device Monitor which can be used to monitor the status of each and every phone call in realtime. This Device Monitor is password protected and can be run from anywhere over a network and can use SSL certificates to ensure a secure connection.
The sample Device Monitor is written using the Velocity Device Monitor API, which is included in the Velocity toolkit. You can use this Device Monitor to write your own Device Monitor, which could obviously include help menus, customer logos etc. All of the networking code is already done for you.
In the Velocity toolkit, you have the ability, by simply setting a property of a channel, to propogate a human readable status of a channel (e.g. “Customer is entering the PIN”) to all connected device monitors. All connected device monitors will receive this Display Status. Additionally, you can send a custom object (ANY object) to all connected device monitors by simply calling one method inside a channel. This will be delivered to all connected Device Monitors immediately.
Other Toolkits
Some other toolkits have no logging at all. It is up to the developer to write his own logging methods, which is not as simple as it sounds because there could be multiple threads writing to the same file.
Of those toolkits which do have logging, often the developer cannot piggyback on their logging and must still write his own logging mechanism.
Some toolkits don’t have any graphical representation of what is happening on each channel. And of those who do, quite often this can only be run on the server, not remotely.
Of the toolkits which can provide a graphical representation remotely, often this means exposing the entire administrative side of the application server to the customer, which is not ideal in many circumstances.
Development / Testing
Velocity
With Velocity, you can actually develop / test your code on real boards. Therefore you can know that when you deploy your application to a customer site, your application will run exactly as it did in your development environment.
Other Toolkits
Some other toolkits do not allow you to develop / test on real boards without a runtime licence. Some toolkits only allow the developer to use a simple simulator phone during development / testing. But obviously this is not ideal, as in the real world a board and phone line will be used. It doesn’t make sense not to develop and test your application in a real world environment.
