As we have looked into the librariers quite extensively I would like to share our findings with you.
Now basically i've come to accept that the Interface Quality of basically all the VoIP libraries is.. well.. bad! At least from a Clean-Code developers view-point.
Exceptions like "License is invalid or expired or any other error occured" are standard.
Some may not ever throw exceptions but rather raise an event in response. The event contains a string which will either be "Initialized" or if not - the error reason.
Mind you, the event is not async, it occurs before the method finishes.
Other have cryptic names (lots of cryptic abbrevations. I don't mean things like DTMF which you can easily google and find out what it means). One library had quite a lot of Typos.
Other libraries again offer Native C++ Imports where you will have to work with
unsafe a lot. Some offer COM or even .net DLL wrappers, but if you want to do more advanced things like buffering you will still need to use pointers / unsafe code. These are not even wrapped to
IntPtr but are
With the kinds of libraries it is also quite common that there are properties like
int IsLoopbackInterfaceEnabled where you need to convert from
Update - Issues with Ozeki
We've made some bad experiences with Ozeki and so i have to withdraw my previous statement. So here's what's gone wrong (apart from several bugs we've detected and had them fix):
First, we detected an audio quality issue. As some custom VoIP-HW and radio-devices were involved (which do influence quality) we've performed a lot of tests. Finally we could pinpoint it to the Ozeki SDK and we've asked Ozeki about it. It was a known issue with the default settings regarding which Windows Audio API (Wasapi or Waveform API) Ozeki SDK employs.
Now this wasn't the end of it. Switching the audio API in the sample application (the one provided by Ozeki) or in a few demo applications we wrote ourselves worked just fine. However, in our real application changing just the one config line results in no audio being output from the speakers, at all.
Again, I've asked Ozeki for help. I thought maybe it's just another known issue. it's not. So after some discussion we agree that they should investigate a fully working repro. So i've sent them one.
Their reply was that the issue was likely related to Speaker instantiation. So they didn't thoroughly investigate the issue but rather are trying to fob me of with some generic answers. Alas, there was some more discussion and their next suggestion was that the initialization should be done at another time (although they meant something different). So i invested some more hours and tried out a lot of combinations, including doing initialization in GUI thread, not doing it in GUI thread etc.etc. It didn't help. Their final response was that it works in their sample application so the issue must be with our application.
This is a really lame excuse if ever I've heard one.
(Also: when changing the configuration to the other API it works "flawlessly" (bad audio quality) - and according to Ozeki changing the API should not have any side-effects).
I've submitted the Repro-Case to Ozeki on December 12th 2014 and the issue has not been resolved up until now (June 8th 2015).
Also there's other issues with the Ozeki SDK which slow down development. For some of those there's workarounds (which are a pain) and for some of those there aren't (which is even more pain).
Finally we've made the decision to ask our C++ development department to write a VoIP Service based on PJSIP for us. According to our developer it's a treat.
here's the original text regarding Ozeki SDK:
Finally we have decided to settle with the Ozeki SDK. We consider their API the best of all examined libraries (still far from perfect, though). Mind you, the exceptions are not very clear (oh, so you are telling me the adress is incorrect, why don't you give me an example of a correct address?) and "state machine" of objects is not very clear (p.Ex. for a
IPhoneCall you can call
.Start() twice. The second time there is no exception, nothing. But it doesn't work, no matter whether you called
.HangUp() before or not. This means you can only use the object once - for one call - which is perfectly fine. It would be better if the method would throw an exception and tell me that i can't use it).
Ozeki Support also seemed to be ok. They feature extensive VoIP documentation on the website and also offer lots of example C# projects.
All-in-all it was the easiest interface to use. And functionality / audio quality is ok, too. Price-wise their ok, too (for our scenario at least).
Here is a short list of notes i took regarding the other SDKs:
- Abto: ActiveX, COM and DLL available.
- need to use
long pointer / unsafe code for quite some methods
- inspecific exception messages
booleans are represented as
- basically no object oriented abstraction - everything is done using the
- there's loads of events. The interface is not clean and easily understandable, you need to read a lot of documentation to know what to do.
- pjsip wrapper
- direct wrapper to c lib (basically a native import)
- Only one where the example C# code comes with up-to-date VS2013 solution
- need to sub-class
GTAPIEnv. How ugly is that?
- Configure settings by methods like
SetInteger(string name, int value). The opposite of a clean interface!
- LanScape VoIP Media Engine
- no object orentied abstraction
- instead one works a lot with arrays. Things like
.PhoneLineState. So 1990!
- Errors are represented as Enums. They are Abbreviated - half way understandable.
- PortSIP VoIP SDK
- direct DLL Import interface
- Conaito SIP Client SDK
- only generic exception like "VOIP SDK Failed". If i remember correctly, you would then have to read a property to get some (a little) more information about the issue. Hello, concurrency? Sure.
- Instantiating the API class requires a reference to a
Windows.Forms.Control. WPF, anyone? No-GUI Service, anyone?
- VaxVoIP SIP Phone SDK
- once more,
bools are represented as
- every method returns an int. C style coding. Always compare return code with 0 to find out whether it worked out. To get more info, you got to read out an
.Error property (thread safety? Goodbye!)
- not very well documented, you've got to look into the examples to find things.
- again, there's lots of events - go read the documentation for hours.
- IntTalk VoIP SDK
- they actually stopped selling the SDK recently. Now they offer to program custom VoIP software for you.