[Tomer Saar is our Product Manager responsible for the BEEHD for Desktop. He wanted to take my readers for a cooking tour, and I kindly obliged.]

The world is divided to two kinds of people: those who like to cook and those who don’t.

Now, let’s say you are hungry and want to have a 3 course meal. If you’re the first kind, you would decide what you want to make, go to the grocery store, buy the ingredients (they needs to be fresh), pour them into the bowl in the right order, under the right temperature, add spices in the right amount (need to iterate that process by adding and tasting), let it boil, let it soak, let it cool. Sounds long? Well, now you have the first course. Do that again for the main course and for the desert.

I don’t know about you, but I’m not hungry anymore…

Of course, there is another option: take a ready-made soup and add hot water. Enjoy your first course. Then, take 2 frozen hambrugers from freezer and throw them in the oven, then you pull out your readymade rice, add boiling water and wait 5 minutes. Enjoy your main course. Your favorite chocolate bar, Mars/Twix/whatever, will be the desert.

What’s V²oIP Got To Do With It?

Developing a V²oIP client is the same as cooking.

If you like cooking, you will need the following ingredients:

1. A signaling stack such as open-source SIP stacks or your own developed signaling protocol that took you years to develop, and now you must use it because the investment was already made and needs to be justified.
2. Learn all about video processing and network transport (optimized for low latency).
3. Find a decent media framework for both audio and video, and try not to overshoot the $200K that it may cost (or an open source with the consequences such as support, contribution to community and maintenance).
4. Wrap everything together and make the appropriate links and interfaces between the signaling and media side.
5. Think about adding a second signaling protocol and drop the idea because it’s too complicated.
6. Add management components to be able to control the clients from a centralized location, for enterprise deployments.
7. Struggle to understand why the video quality is so bad when you’re connecting from home to the office. It worked so nicely in the lab.
8. Run rigorous tests until it works properly.
9. Try to make it work with an existing endpoint just to realize that you need to replace 20% of your code to make it work, and iterate that process several times for other endpoints.

Ok, now you have a V²oIP client for your first platform and operating system. Want about another OS? Start all of the above again.

If you’re the non-cooking type

In case you don’t like to cook, and you’re developing a V²oIP client, you would probably want to use a package that my friends at RADVISION created. It’s called BEEHD and it’s available for multiple platforms such as PCs, mobile devices, tablets and embedded devices.

You can easily download the trial application and test it, and then you can start developing your application on a ready-to-use V²oIP client with a really easy API set.

You would receive excellent and speedy support from a world-wide support team, enjoy a reference sample application in source code and interoperability with dozens of endpoints, servers and MCUs.

Video quality wouldn’t be compromised when working from remote locations due to sophisticated algorithms. Multiple signaling protocols will ensure that you can connect to almost any other existing endpoint capable of SIP or H.323 and of course enjoy RADVISION capability of delivering a full solution including endpoints, infrastructure and MCUs.

Oh yes, and when you’re ready to develop a V²oIP client on another platform, the APIs would be the same.

So do you like to cook or not?

P.S. (1)

I know you have something to say about the quality and the taste of my readymade meal. That part isn’t the same as building a V²oIP client. Please don’t ruin my analogy

P.S. (2)

By now you should have guessed if I like to cook or not.