I'm looking for a VoIP library adhering to the following criterias:

  • written in .NET or at least with .NET interface
  • a clear ("clean code" like) interface would be a big advantage
  • must support Direct IP Call
  • must support G711 (PCMA) aLaw 8kHz mono
  • must support recording concurrently to actual talking
  • I must be able to subscribe to SIP INFO message and send SIP INFO messages with custom payload
  • should support SRTP or encryption of all transport by TLS
  • license:
    • must not require us to open source our software
    • must cost less than 30,000 $
    • should not incur costs for each device sold (we only require one line/port, but will sell several devices)

I would be especially glad to receive first-hand accounts of level of support (how fast are they reacting, how helpful is the answer …) and how nice the interface is. The technical details I can and will have to verify on my own anyway.

Since I've already done some digging myself this is the list of libraries I'm currently looking into, grouped into how well they fit our needs (on a preliminary analysis):


Not so promising:

Not at all:


5 Answers 5


My project, Managed Media Aggregation, does everything you need with rtp and rtsp, it includes a client and server which are both efficient and standards compliant.

The server supports over 1000 clients without any issue and memory usage is rarely above 150 mb even with those clients consuming media.

The solution also has some codec implementations but only really Jpeg is completely supported at this time although there are useful tools for just about every documented codec and container format including h264 and mpeg.

Playing and decoding as well as encoding will be supported soon.

You can get the sip stuff from sipsorcery.codeplex.com

If you need the codecs now then:

Audio Transcoding can be achieved either using naudio or bass.

Video is going be your problem domain but I'm not sure if that is an aspect to your project.

Net cost here is only your time or what you donate.

MMA uses the Apache License 2.0.

  • Thank you for your great post and your information on VoIP Libraries and the Ozeki library in particular. I was always wondering how media-handling written in .net can be stutter-free even under heavy load (especially when the GC is running - which interferes with the processing of other threads). I would really appreciate it if you could elaborate on the subject. Maybe you've already written a blog post? Maybe it's "simple" because everything is already handled by existing unmanaged-code? ... Commented Jan 5, 2015 at 6:07
  • I'm especially wondering about that because Ozeki claimed it to be not an issue. I specifically asked them how they ensure that the GC is not introducing stutter. They said they had done "optimizations" to prevent that. Unfortunately they never got more specific about the technical details and i remain a bit sceptical... Commented Jan 5, 2015 at 7:07
  • Unfortunately Ozeki is not doing managed decoding they are using ffmpeg, research cscodec. Its possible the gc won't introduce studder if you don't have enough memory pressure in the first place to cause it. I don't have a blog yet but I answer questions on the project page which does have a thread where h264 decoding is discussed.
    – Jay
    Commented Jan 5, 2015 at 18:47

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 long bufferPointer. With the kinds of libraries it is also quite common that there are properties like int IsLoopbackInterfaceEnabled where you need to convert from int to bool yourself.

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 int
    • typos
    • basically no object oriented abstraction - everything is done using the CAbtoPhoneClass
    • 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)
  • PCBest
    • 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 .PhoneLineRecording[2] and .PhoneLineState[2]. 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 ints
    • 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.
  • They use open source software and sell you it. You could fix or report the bugs yourself and pay nothing.
    – Jay
    Commented Jan 3, 2015 at 18:32
  • @Jay: I know that this is the case for things as FluorineFX and others. But what about the whole SIP, RTP and SRTP handling? What libraries are they using for this? The problem is that it requires a lot of know-how to put those things together so that they work reliably. I have to admit however, that lately i have been rather disappointed by the quality of the Ozeki SDK. Commented Jan 4, 2015 at 9:57
  • Sipsorcery for sip and srtp. My library for the rest. See my answer. In the end that company isn't doing anything but supporting open source software for a charge.
    – Jay
    Commented Jan 4, 2015 at 20:03
  • 1
    @Jay: have you ever considered doing that - supporting open source software for a charge? Because it would be much easier to "sell" this to my boss instead of donations... ;-) Commented Jan 5, 2015 at 6:35
  • My library has free support, if he makes money off the project a donation should be just as good as buying something and usable as a tax deduction also.
    – Jay
    Commented Jan 5, 2015 at 18:49

I also evaluate Ozaki for some weeks. It seems very promising, but as a new comer, I find that is not well documented (at least for me that I am not experienced in VoIP domain, I wish more verbosity, for example in what concern errors), somehow inconsistent between consecutive releases, and their site seems to me very cluttered with much information, but not well organized. Also I find that is tremendous expensive.

  • have you also looked into other libraries? I and presumably others would probably be very interested in a comparison - even a subjective and incomplete one. If i compare it with other libraries i actually think Ozeki is not expensive at all - it depends on how many channels/concurrent connection you need. If you need a lot of them, then yes, it is expensive. Commented Dec 9, 2014 at 12:00
  • First of all, I am very newcomer to this. So am I am not very familiar with prices and other aspects. I just downloaded Conaito, VaxVOIP and Abto VoIP. For example I was tempted by VaxVoip web softphone. But unfortunately I was absolutely unable to simply regsvr32 their DLL on my Win 8.1 x64 notebook, so I was not able to look deeper. So I continue for a while with Ozaki. What it frustrating me about Ozaki is that I started between two releases, with the last one, their examples ceased to work well, and they don't seem to me very cooperative with providing some clues.
    – net4u
    Commented Dec 9, 2014 at 15:16
  • And I really can't think to buy an expensive SDK if at least their basic examples I can't manage to make working.
    – net4u
    Commented Dec 9, 2014 at 15:17
  • 2
    I wouldn't pay anything for ozeki, the software is boxed up free software which has been obfuscated.
    – Jay
    Commented Jan 3, 2015 at 18:26
  • what free software? anyway it seems terrific expensive for me, but otherwise it looks promising. also, I don't like their support. Is not very friendly.
    – net4u
    Commented Jan 6, 2015 at 14:51

I am using Ozeki SDK, According my experience the latest versions(1.3.7 and 1.3.8) is not working as expected in some cases.

Also almost there is no support at all.

I am testing https://sites.google.com/site/sipekvoip/ rigth now, It is promising.


Try PortSIP VoIP SDK ( https://www.portsip.com/portsip-voip-sdk/).

This is the easy to use and powerful SDK, support multiple platforms; the free sample project can be download to test.

And here's the most important thing: The PortSIP VoIP SDK is not derived from any other open source project. As far as I know, a lot of SDK's just simply modified from an open source project such as linphone then sell it as commercial.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.