Maketing - from an idea to first announcement

[This is part of Maketing blog posts series]

Announcing a new open source project is one of the most important steps in its evolution. Whether it is something completely new or an alternative for existing projects, you must be able to communicate properly its target and the benefits.

Talking about software projects, try to do the big announcement when you have something running. People like to feel the products, in software that means they should be able to run something.

Hey, you are at beginning, it may be buggy, incomplete, but there should be something running. It gives the change to engage new people with feedback about issues and desired features.

On the other hand, if you have a cool idea but nothing to present, most of the people will forget about it soon. The first adopters are usually the techies, interested in the same domain and they guide after "show me the code first".

Depending on the market, time to bake a project before announcing it is also very important. With SIP Express Router (SER), baking time was about one year (note: it was actually used in research projects and demos) -- when it was released under GPL, the entire history of development was made public (kept in CVS internally at FhG Fokus Institute and then migrated to berlios.de).

SIP was at its beginning as well, so time was a good friend in this aspect during early 2000. Now it might not be the same. The development done internally during the first year allowed to come to the public with quite rich in features SIP server, the first of its type in open source. In just few months we had a consistent external community involved in the project, as users and developers.

Therefore, here is my list to consider when launching a new project:

• release some source code that is working to some extent from day one
  
• don't bake it too much internally - waiting too long you may miss good chances
  
• create basic documentation - how to build and run the application
• create a web site to present the project - it will help to easily refer to, spread the word and get listed in web search results
  
• underline the target of the project - what it tries to offer and how it differentiate from similar ones
• open communication channels to community - mailing lists, web forums, a.s.o. - keep the archive of discussions public, it will help others learn from old debates
  
• abuse your friends and colleagues for initial feedback and first discussions - there are many watching the archive before joining, a dynamic community attracts new members
• use social networking to rich more audience
• be sure you are available to answer questions quickly in the early stage - spread the knowledge about the application so that community members can answer similar questions later to new members, lifting some load from you

If the launch is carefully prepared, you are half way done to ensure the success of the project. First impression matters!

Maketing - the art of building open source projects

An open source project is more than source code - beyond the application itself it is about proper promoting, interactive community and vision.

No matter how good it is the application, if you are not able to promote it and attract a loyal community, then it is not going to succeed. Without transmitting the vision, defining a clear target and development path, community is not jumping on board.

This year is 10 years of SIP Express Router (aka SER) - the reference implementation of open source SIP server. I was involved at the top management of the project from its early beginning, then developing a different path through the fork Kamailio (former OpenSER) for about 3 years and since 2008 I am again full time in it - right now SER and Kamailio share the same source code, same developers, because of database structure constraints, they are still released as independent applications.

Looking back over the years, I realized that building successful open source project is beyond programming skills. With this post I am opening a series of blog posts to share from my experiences.

The posts will be tagged maketing. It is not a typo, just a hash tag resulted from:

• make - one of the famous tools used in open source to build your application, very common in Unix/Linux world
• marketing - strategies and actions of promoting

Coming in my mind to approach in future posts, not in this order and not limited to:

• from an idea to first announcement
• key aspects of code development - taking care of own code and contributing to parts from other developers
  
• developers' interaction - the project counted over 80 registered developers from more than 10 countries, over 25 still very active, 5 joined in the past half a year
• community - from the group of developers to thousands of users - engaging people beyond programmers
  
• marketing - attending events, organizing events, news and articles
• versioning and release policies - what are the important aspects to take care of
  
• branding - how SER, OpenSER and Kamailio went from day one, an unknown name, to become very popular and recognized brand in the market at their time
• handling forking - good and bad times
• project management - its role, who should do it and how has to be done
• penetrating the money market with open source
  

Expect stories based on my personal experiences, what I considered to be good and bad, how I dealt in special cases, what I think could have been done better. Maybe they will be useful for somebody in the wild to build better open source projects...

Update:

Following posts were released in this series:

• Maketing - from an idea to first announcement
  

Kamailio v3.1.4 Released

Kamailio SIP Server v3.1.4 stable is out – a minor release including fixes in code and documentation since v3.1.3 – configuration file and database compatibility is preserved.

Kamailio (former OpenSER) 3.1.4 is based on the latest version of GIT branch 3.1, therefore those running previous 3.1.x versions are advised to upgrade. There is no change done to configuration file or database structure.

Resources for Kamailio version 3.1.4

Source tarballs are available at:

• http://www.kamailio.org/pub/kamailio/3.1.4/src/

Detailed changelog:

• http://www.kamailio.org/pub/kamailio/3.1.4/ChangeLog

Download via GIT:

# git clone –depth 1 git://git.sip-router.org/sip-router kamailio
# cd kamailio
# git checkout -b 3.1 origin/3.1
# make FLAVOUR=kamailio cfg

Binaries and packages will be uploaded at:

• http://www.kamailio.org/pub/kamailio/3.1.4/

Modules’ documentation:

• http://www.kamailio.org/docs/modules/3.1.x/

What is new in 3.1.x release series is summarized in the announcement of v3.1.0:

• http://www.kamailio.org/w/kamailio-openser-v3.1.0-release-notes/

If you want to see what is new in development version (to become the future major release v3.2.0), visit the web page:

• http://sip-router.org/wiki/features/new-in-devel

Energy Efficiency and Performance Testing for Kamailio v3.0

Jan Janak, one of the core developers of SIP Express Router (SER) - (since version 3.0.0, SER and Kamailio (former OpenSER, which started as fork of SER in 2005) are built from the same source code) conducted a very interesting research project regarding energy efficiency of VoIP systems during 2010, a collaboration between iptel.org and Columbia University.

The team used the source code from sip-router.org GIT repository from January 2010, which corresponds to Kamailio (former OpenSER) and SER v3.0. The latest stable series v3.1 shares the same internal architecture with v3.0.

As part of the research work, he could also gather some figures about capacity and performances of v3.0 with a quite complex configuration file (involving authentication and NAT traversal as well).

You can read the paper about energy efficiency at:

• Green VoIP Article
  

The draft notes about capacity and performances of v3.0 are available at:

• Performances and Capacity for v3.0
  

Some interesting results:

• one instance of SIP server with 500 000 online users (mixed users - behind and not NAT routers) - consumed energy 210W
  
• one instance of SIP server with 1 000 000 online users (no NAT involved) - consumed energy 190W
  
• on a 32-bit machine with 4GB of memory and with 2.5GB reserved for SIP server, the server could support 43 000 simultaneous TLS connections - consumed energy 209W
• 80 000 permanent TCP connections, the SIP server could still handle at least 1000 requests per second and a connection arrival rate of 1000 new connections per second, done for 20 000 new connections. CPU load generated by the SIP server was from 6% to 8%.

I added a new section to the draft notes to list the enhancements done for the latest stable release (v3.1.x) that contribute to performance improvements, like asynchronous TLS, fine tuning of memory for TLS connections and raw UDP sockets.

Run your own Skype-like service in less than one hour

In the past few weeks, there were couple of articles showing alternatives for Skype (like this one) - applications or/and services.

Why not running your own Skype-like service? Even better, why not do it using open source and free applications and spend 8.5 billions for something else?

The target is to build your own communication service that offers:

• peer-to-peer and secure communication (encryption of the content sent between users)
• voice calls between two users
• video calls between two users
• group voice calls (audio conferencing)
• screen sharing
• chatting - instant messaging between users
• contacts list and presence status notifications
  

The service is going to use the open standard protocol - SIP (Session Initiation Protocol). Two open source application are playing the major roles in the network:

• Kamailio SIP Server - for user authentication server and 'super-node' functionality of relaying the voice/video packets when necessary
• Jitsi - the client application, a cross platform implementation running on Linux, Mac OS X and Windows

Installation of the SIP server is exemplified on a Debian Squeeze system, but any flavour of Linux can be used.

The step-by-step tutorial is available at:

• http://asipto.com/u/2h

It took me about 15 minutes to get the service up and running following the guidelines presented (being very familiar with the two applications), however it should not take more than 1 hour to get everything in action.

Enjoy! Communicate secure and freely!

Remarks about LinuxTag 2011

This year I attended the last two days of LinuxTag show in Berlin. Kamailio project had a booth at exhibition hall for the four days, but I arrived late for it from the Silicon Valley trip.

However, it was just in time to meet with most of the people that took care of project's booth. In a rare moment, due to spread across the world, there were 5 of the 11 members of Kamailio management team.
From left to right: myself, Elena-Ramona Modroiu (Asipto), Henning Westerholt (1&1), Raphael Coeffic (Tekelec, developer of SEMS project), Andreas Granig (Sipwise) and Carsten Bock (Telefonica/O2).

Henning had a presentation about Linux at 1&1, including remarks about usage of Kamailio. Carsten did the fast track, two slides presentation of Kamailio project.

The number of visitors was balanced during my two days there, Friday and Saturday, with waves of crowds. As usual, many of the well know open source projects were there, such as famous Linux and BSD distributions, CMS projects such as Drupal or Typo3, Mozilla, a.s.o.

Very interesting for us, we learned that the German Federal Office for Information Security (BSI) sponsors an integration project that aims to provide a secure, scalable and easy to use open source PBX platform when they presented the upcoming "Gemeinschaft" PBX version 4 that will use Kamailio and Freeswitch.

Yet another confirmation that secure communications, including SIP over TLS, will have a relevant boost this year in VoIP.

Inside our booth, we offered demos and presentation of various Kamailio use cases:

• the telephony system implemented at 1&1
• demo of SIP:Provider CE - full featured IP telephony platform
  
• presentation of IMS extensions
• how to use SIP Express Media Server (SEMS) for SIP signaling back-to-back user agent with Kamailio or as stand alone performant SIP media application server for features such as IVR, transcoding or prepaid engine
  

Is this the end of SIP over UDP?

The recent move in market with the acquisition of Skype is going to impact many things on the VoIP space, in many cases in a positive way.

Most of the SIP traffic these days is over UDP - unreliable and unencrypted protocol - everything is sent in clear text over the internet: who you are calling to, content of the text messages, your presence states.

Skype made a reputation for itself as offering very secure communication. Microsoft is a marketing devil, no secret, any bit they can exploit will become a sales weapon. Secure communication is one of what they've just got.

To be able to fight in the SMB/enterprise market, the Unified Communication (UC)/VoIP solutions providers will have to deliver from now on secure communication systems. SIP has all the meanings of ensuring secure communication, but it was not deployed much in that way. The companies were focused to check the bullets in the list of the 500 old PBX features.

It was a clear increase in the demand for secure SIP communication platforms lately, but the Skype take over by Microsoft will accelerate it a lot. Otherwise it will be extremely hard to compete against the new Microsoft UC solutions.

Fortunately, the open source SIP-based UC applications are ready. On the server side, being a lot deployed in insecure environments (e.g., well known Internet), we directed a lot of efforts at SER/Kamailio open source SIP server project to ensure the security of unified communication sessions - signaling for voice, video or desktop sharing, instant messaging and presence.

Starting with v3.0.0, there is a brand new architecture for TLS communication, designed for scalability (e.g., up to 80 000 active TLS connections on an average server hardware). In v3.1.0 that work was completed with asynchronous processing of TLS connections, increasing substantially the capacity to handle such secure connections.

On the client side, open source softphone applications such as Jitsi can connect to the server through TLS and send the media stream via SRTP (secure RTP) or ZRTP, thus the entire communication is secure.

For client side, there are also many choices of SIP hard phones with TLS and SRTP support, such as Snom or Cisco. Therefore doing secure communication with SIP is possible, very easy. The time to promote and deploy it massively has arrived.

UDP for SIP may stay for some time in many SIP-based UC systems, but this moment can mark the start of its end.

SIP for Skype

Let's put it straight. Skype was the simplest telephony service ever. Period. And that's perfectly ok.

Frankly, building a Skype-like service is damn easy. Hopefully, now since it is gone and not anymore a potential easy-to-buy target, it will wake up some people in decision positions from the major telephony operators.

It's just lately Skype added video group chat, but what was the rest?

• audio conversations directly between two people
• instant messaging between two people
  
• audio group chat (audio conferencing)
• multi-user chant (group chat)
• desktop sharing
  
• contacts list (buddy list) with presence states (offline, online with sub-statuses like away, do not disturb, a.s.o.)
• secure communication - encryption for all cases above
  
• interconnect to other networks (PSTN and SIP)

In the core network were just the group of authentication servers with the storage for accounts data (user profiles) and the gateways to break out to PSTN and SIP. There was nothing else done in the Skype core network, everything was done in the client side, offering peer to peer communication model. To localize and make possible to have the conversation with the called person, some instances of the client applications were acting as supernodes, guiding the signaling and media streams.


That's all folks!

Now, let's look at the SIP side. It was designed to be able to establish peer to peer real time communication (RTC) sessions over IP networks. Here is the classic SIP trapezoid:



The difference to Skype implementation is in essence that the core network servers do location services along with authentication and storing the user profiles. But the rest is practically identical as concept. Simple and straight.

What it takes to build a service such as Skype with SIP?

Here is the same bullet list saying if it is possible and how, exemplifying with open source applications (therefore very cost effective to design the service and deploy the components):

• audio conversations directly between two people - yes, the very basic concept in SIP. Client applications, lot of them, e.g.,: Jitsi, Ekiga, Linphone, ... Server applications: Kamailio, Asterisk, FreeSwitch, SEMS
  
• instant messaging between two people - yes, the end to end model using SIP MESSAGE request, widely supported. Client applications: Jitsi, Ekiga, Linphone. Server applications: Kamailio, Asterisk, FreeSwitch
• audio group chat (audio conferencing) - yes, most client applications can do 3-way conferencing (small conference of 3 people), then Jitsi can do multi-user conferencing. In addition, instances of applications such as Asterisk, SEMS or FreeSwitch can be used as dedicated conference bridges, where anyone with a SIP capable phone can dial in and join group conversations.
  
• multi-user chat (group chat) - yes, server side with Kamailio in a not standardized way, just reusing the SIP MESSAGE to carry the chat content and imc module to control the members of the chat room. Client applications can be also the host of multi-chat room.
  
• desktop sharing - yes, use Jitsi as client and Kamailio as server
• contacts list (buddy list) with presence states (offline, online with sub-statuses like away, do not disturb, a.s.o.) - yes, client application: Jitsi. Skype model is SIP end-to-end presence model which is very simple from server side application point of view. The SIP end-to-end presence is implemented in many other SIP client applications. Server side: Kamailio. Contact list can be managed locally or via XCAP. Jitsi is a very good client application for both. When XCAP is used, in server side you can use Kamailio with embedded XCAP server.
  
• secure communication - encryption for all cases above - yes, via TLS for SIP and SRTP for media stream. Using Jitsi and Kamailio can be an example of doing such communication. Servers can run on different ports that will help going through firewalls and the TLS will ensure nobody can detect it is SIP.
  
• interconnect to other networks (PSTN and SIP) - yes, numerous SIP-to-PSTN gateways or termination providers
  

Actually, looking at the points above, SIP as it was at its early stage of specifications (call setup, instant messaging and presence) is far more closer to Skype communication model than the latest IETF/ITU published specs in regard to SIP.

Where is the problem in IP telephony? Why no big telecom which had the infrastructure and the financial resources could do any revolutionary step in IP networks? Because they don't think simple and don't look at what is important for the most of the users nowadays. All that matters so far for operators (based on my 10 years in the area) are the roaming/inter-connect fees and the set of 500 old PBX features, which are not used more than 2 percent anyhow in a daily basis, and 95% were never used probably.

The change for a proper evolution would be very simple technically, practically is the hardest: because that's about the change of mentality and concepts.

First, stop pushing new SIP specifications with very complex architecture! They don't help neither implementers nor operators. Roll back to the basics of the SIP, it is really a good protocol for RTC. Forget about compressing signaling, bandwidth issues, gran'ma love to 10 digits dialpad, battery life, a.s.o., they are the false problems for you right now (btw, gran'ma loves to see gran'kids on the screen). Get out simple to use services, bring on board new customers with that. Start listening to young and enthusiastic minds, they know what they like to make their life easier, they have the future ahead. Just as that: build the services for your kids.

If you keep talking only with the classic telephony vendors, then the chances to evolve and develop new ways of communication through your companies are close to zero. It could be the Skype protocol "the one" for the future of telephony, it could be XMPP, or SIP can stay in for that, but that is the least relevant aspect.

The winner will be the proper model, not the technology behind it. Definitely the classic telephony is not that!

Evolution - face it!

SIP/IP vs PSTN/H323 as concepts in the arena, again. It was flying on twitter a new SIP vs H323 head to head comparison (I assume it is new, there is no publishing date on the page, but they claim it is at least actual).

Just reading the start of the comparison, I had big doubts. They claim that people who did such comparisons in the past were unknowledgeable, students or similar, misleading with their articles. But in this case there isn't even an author (nor list of authors), so we know that those doing it now are proper specialists. For me is more that clear that they have no understanding of SIP and its intended role for real time communications (RTC) over IP networks.

I guess they are telecom people, based on their way of thinking and the reasons they wrote in the article, no matter it is venders or operators. So, first guys, sleep well, SIP is not a replacement protocol to upgrade PSTN network. H323 could have been designed for that, definitely not SIP.

Personally I will refrain from doing technical comments on H323. Simply I don't care about, it is not for the new wave of communication demands. Instead I will punctually tell how wrong the concepts about SIP are in this article. If I was one of the authors, first I would remove the paragraphs from the start of the article, it has ridiculous content: "this is, frankly, the best comparison of H.323 and SIP available anywhere", "comparing apples to apples", ...?!?! Or at least add the authors name so the others can check them and be sure they have right expertise with SIP.

Rarely I could see so much misunderstanding of SIP while claiming to know it. Now, point by point comments about the sections in the comparison article (note: you have to read the article with SIP vs H323 comparison more or less in parallel with the next comments for proper understanding):

Philosophy

First, yes, SIP is for establishing real time communication sessions, an audio call being just a possibility. And that's how it should be. Remember, SIP is not to upgrade PSTN protocol. It is for being able to cope with new communication demands.

Here is your biggest failure guys. SIP has very less to do with the session content. That is advertised in SDP (Session Description Protocol). So, being it audio, video or 3D holograms sessions, SIP does not need to be changed at all.

To rephrase, SIP is to establish the communication session, not to understand the content of the session. That's PSTN where the operator wanted to control the content and have the intelligence on the network, so all pieces around had to understand everything. Lately, we, the end consumers, don't like anymore dummy endpoints, but smartphones. And if these phones are able of transmitting something completely new, then I don't like after spending lot of $$$ on my device to have the operator limiting me. SIP is for that. Operator can charge on minutes, bandwidth, but not on content type -- that's my business. Do you like to be charged differently for a flight because you ate caviar than someone else that ate hot dog? Do you want to be forced to tell to the flight operator what you have eaten?

Now I hope the philosophy is clear: we talk about the "free as in speech" to do with what I own.

Complexity

Can you point the document (RFC) where SIP was extended for video or application sharing? How did you come up with these? Guys, google first...

SIP is really a simple protocol. Even the initial model for instant messaging and presence is very simple and works perfectly with all implementations (it is the end-to-end model, architecture used pretty much the same in Skype or XMPP/Gtalk). Then we got the mobile/telecom operators pushing for so called SIMPLE extensions which is indeed complex. That it is not SIP core, but newer extensions.

Reliability

I haven't understood a term from what it is claimed the H323 does there. But SIP has lot of mechanisms to deal with failure routing, from using DSN SRV (yes, cool down, this is fine, we are over IP networks here, where DNS is the heart) to doing serial forking. Ultimately, if it is the case, the user agent had to do any re-INVITE, perfectly ok because it is the one that knows about the content of the session.

Message Definition

Having university studies in both compilers and network communications, I can put just a smiley here: :-). Really guys, it is where you could get with it? I can start an endless debate here.

Message Encoding

Folks, take a deep breath and give me a break with bandwidth consumption by SIP signaling. The SIP compression concept you pointed were the most useless ever I met, however, pushed by vendors hoping to sell new boxes for few more millions of bucks to their money-milking operators.

Have you computed what is the percentage of the SIP packets in a 5 minutes call with GSM, G729 or G711 audio codecs? How much one could gain compressing less than 10KB? If you search through all SIP related RFCs you can get wrong and complex specifications, does not mean they have to be implemented or they will be ever. First, RFC stands for Request For Comments. People with ideas can write new specs, others can review and approve to become a RFC number, then it is the period to see if it worth a penny or not.

The large number of RFCs related to SIP gets to the conclusion that the protocol is very flexible, easy to extend and many were able to do that, period.

Just to freak you out, Twitter messages are maximum 140 characters long. What does it take to send a Twitter message? An HTTP request with very big JSON body. A HTTP request has more or less same amount (and structure) of SIP message. Then the body for Twitter is far more bigger than SDP for a SIP audio call initiation. Now, does anyone care about compression of Twitter packets? Does any of the users with smart phones twitting over mobile networks complained about? Guys, look around, we are in 2011.

Extensibility - Vendor Specific

I assume you heard that (the risk you claim for SIP) from the cousin of a friend of your wife/husband's colleague from high school meeting first time after graduation at the 30 years reunion. If not, then some links/examples would be good.

Extensibility - Standard

Evolution has some risks, not everything can be backward compatible. But the next phrase I quote from your article blew my mind:

"In addition, several extensions are "mandatory" in some implementations, which cause interoperability problems."

No more comments here.

Scalability - Load Balancing

SIP does not provide any in-protocol standard load balancing "specifications", it is in essence IP based protocol and there are lot of load balancing meanings here, like DNS based ones. Reporting usage can be done very easy by operators/vendors through replies and custom headers.

I am doing SIP load balancing solutions for so many years, never found anything missing in the protocol in this aspect. Lack of vision to apply a protocol is not a weak of the protocol.

Scalability - Call Signaling

Is this again about bandwidth of signaling packets?!?!? Com'on...

Scalability - Statelessness

I'm core developer for 10 years of a SIP Server and didn't know it has to be stateful for TCP. How is that, can you elaborate? We can do it stateless at SIP Express Router (SER) / Kamailio from the first day of TCP support, it's simply working. You say it is actually wrong? Is there any RFC requiring the server to be stateful? Please give the details.

Scalability - Address Resolution

3 is for sure the number making SIP bad. There are either 3 "full messages" or "as many as 30". Pointless what you mention at this section. How did you measure the "processing requirements"? Can you give the sample H323 and SIP packets used in measurements and how you made them? I would like to run the SIP packets through SER/Kamailio to see if the match the "processing" demands.

Come with numbers guys and proper arguments, otherwise is bullshit bingo article.

Addressing

First, about myself, when I'd see no digit-based numbers/IDs in in SIP, I will keep partying one week long. That means SIP got to the level to be used properly.

The part with "unofficial" convention is the best of the article, really, keep it up folks!

Billing

Wow, can't believe it. They are trusting the end device to report proper billing information. Great folks, why don't you start such a business over Internet? How long will take to update an open source softphone to report the call duration the user wants to? Wake up, Internet is open, it is not PSTN and you cannot control customer's devices anymore.

Call Setup

You tried hard guys. You admit H323 may require more elaborate call establishment for complex scenarios, but no example given. You show how is done in a similar case with SIP. Conclusion: it is possible with SIP, not sure it is with H323.

Capability Negotiation

Is it me and potentially my imperfect English, but the H323 side and SIP side have different kind of topic. I see no direct relation between what you say in one side and then compare against in the other.

PSTN Interworking

H323 borrows? I thought H323 is PSTN over IP, sorry if I got it wrong so far. I hope SIP will never become like this, we don't need PSTN over IP and that is the problem now with SIP. Many try to turn it in PSTNoIP protocol. I just pray they will fail.

Services

Yet again a section with random statements. I haven't heard of any new and cool service provider recently via "well suited" H323 protocol. And, fyi, XML, SOAP and CPL are pretty much standards.

Video and Data Conferencing

As mentioned above, you have no clue folks about the purpose of SIP. Does the pilot has any clue of what you ate before boarding the plane? How can he fly the plane then?

Codecs

SIP does not support any codec itself, and never will do. Keep reading the specs guys and understand the purpose of SIP.

Nowadays we call them smartphones those devices that need to create and understand the content of a session that is established via SIP.

Firewall/NAT support

You refer to 5 documents for H323 and 4 for SIP. So we are doing better in SIP then.

Loop Detection

Max-Forward cannot be used at all for loop detection in SIP.

Since H323 can fork, how it will deal with the case in the presentation linked in the SIP side?

If you mean that a gatekeeper is call stateful server, then SIP server can be the same and detect looped calls very easy. If you refer to call stateful H323 server and stateless SIP server, then tell me how is it with H323 stateless server.

Conferencing Entity

What's that in the SIP side: "no, ... conference bridge may provide ... " while in H323 is "yes, a MC is required...". Have you ever heard of SIP audio conferences through SIP with Asterisk, FreeSwitch & co?!?!

Open-source projects

I bet it was hard to choose the one of the SIP open source projects to list, but I am glad you have one for H323. How many H323 open source softphones are out there? What about server applications? Plenty I guess based on your observations here, just stupid Google does not find them.

Conclusions

The biggest fear I have is turning SIP in a protocol to bring PSTN in IP networks. Hopefully it will not happen, although standardization bodies are overwhelmed by guys with old telecom mentality and concepts.

As for the H323 vs SIP article it is written without any understanding of SIP. If the authors want to do a real comparison, bring two guys, one having proper expertise in H323 and the other in SIP, put the problems on the table and let them give the solutions.

The way that article is written shows only frustration and inability to understand and see the demands in the new waves of IP communications, nothing else.

SIP has to be interoperable and integrate easy and seamless with email, web, twitter and what so ever IP based communication service, not with PSTN. It must replace PSTN-type of communications, not just help to upgrade PSTN physical infrastructure.

We need evolution in telecommunications, SIP is the chance for that! But has to be done right. If not, SIP may disappear, however at that time the telco and mobile operators will be already replaced completely in our lives.

Two technologies striking back in VoIP - part II

Do you remember VoIP/Telephony shows back in 2005-2007? It was IMS (Internet Multimedia Subsystem) all over. Then silence.
What killed the trend? Did everyone deploy it and this was it? No, there were many deploying pre-IMS, half-IMS or IMS-ready solutions (most of them being just some re-labeled existing system by the marketing/sales departments of some vendors) for astonishing amount of money, bringing back to them no other benefit that a SIP server with registrar, location and proxy services could deliver.

Many of us, including me, I was reticent about IMS. It was not because things like being a bad idea, but seeing who is behind the movement (read old telco vendors), organizations with few understanding of new communication demands over IP. They couldn't have it pushed beyond voice. Remember, IMS concept promised a framework to offer voice and new real time applications to mobile networks.

But voice was there, it had a dedicated channel (no IP) even in 3G networks. So an IMS with nothing more than voice brought zero add-value to services. There was no real return of investment for most of those deploying x-IMS.

Things are changing, demands for data over mobile networks is increasing, the operators are forced to go to 4G or what so ever will be next. Here we talk about technologies like LTE. With such technologies, there is no longer a dedicated channel for voice. Everything is IP.
Therefore the operators need a system that has to route the voice over LTE. One of the options, the natural one, is IMS.

IMS is a lot about defining standard interfaces, to handle services such as: interconnect, roaming, billing, access policies a.s.o. Not bad at all. Many concepts map directly, entirely or partially, over the standard SIP concepts, e.g., HSS (Home Subscriber Server) and SIP Registrar/Location Server.

It is almost mid of 2011, for few years there was a gap in (public and high) interest regarding IMS. But now is different. Starting with the end of last year, more and more people showed real interest in bringing IMS extensions in Kamailio. They are in the source code repository for some time, still under heavy work, but you can run it -- see the tutorial pointed at this web page.

First the big advantage for companies looking to use it is trying it at very low cost. Although the IMS extensions were available for some long time for free through OpenIMSCore project (which is part of our SIP-Router.org development eco-system), this time there are made available on top of a very stable VoIP/Telephony engine. All the IMS extensions are modules, so the stability of the other extensions and core is not affected at all.

More over, apart of voice, Kamailio (being the core of the IMS solution) offers add-on services such as presence and instant messaging out of the box. Furthermore, existing embedded programming language interfaces to Lua, Perl or Python offer a straightforwards and easy way to implement RTC goodies (e.g., see some slides with a tutorial for sending notifications to Twitter on missed calls).

I summary, with the IMS extensions on top of Kamailio:

• free-as-in-beer system that anyone can try before deciding to pay integrators for professional installation
• rock solid underneath system
• access to other hundreds of RTC extensions
• services beyond voice
• embedded scripting languages
• open source, vendor-unlocked environment, with many companies able to offer professional consultancy services
  

Forced by the need of a new voice system for LTE, backed up by cost effective and reach in extra features solutions like you can get with Kamailio, IMS has a good chance to succeed this time.

First part of writing about technologies striking back in VoIP was about IPv6. Same like there, things seems to get serious now (repeating the disclaimer from first part: the statements are made based on the activity inside our mailing lists, looking back at the discussions about these subjects in the past 10 years).

On our mailing list, Jason Penton (new developer to work on IMS extensions), revealed his company plans to deploy IMS in several countries across Africa (Uganda, Tanzania, Nigeria & DRC -- click to see the message).

The development of the IMS extensions is coordinated by Carsten Bock, long time developer and member of management team of Kamailio.

If you are interested in IMS, Carsten (along with other developers) will be present at Kamailio booth during LinuxTag 2011, in Berlin. We will be glad to talk with you, just drop by. We have several visitor passes that we can give away, write me an email if you are interested. Of course, flyers and giveaways will be on site, more details about developers availability at:

• http://asipto.com/u/21
  

The Others - We 'Switched' the Seats

The other day I saw on the web space the launch of a new mailing list about IPv6 by SIP Forum. SIP Forum seems to be an exclusive club of Telco vendors/equipment manufacturers and operators (annual membership fee $7500). Claiming to some extent they help promoting adoption of SIP, the group is well known, also maybe due to organization of various SIP related events such as SIPit (where I participated several times).

Do they help with SIP adoption? I don't think so. Why?

Just short details about what triggered this post now, but the facts are actual since many years. So I subscribed to the new IPv6 mailing list using my address used everywhere on all the mailing lists I am member of. It is from one of the very popular free emails providers. And I got rejected, with the following reason:

Your request to the IPv6 mailing list
Subscription request  has been rejected by the list moderator.  The moderator gave the following reason for rejecting your request:  "As a SPAM control measure, all SIP Forum WG mailing list subscriptions must be from an address (domain name) that has an obvious association with SIP and IP communications technology.  Please re-subscribe under such an email address, or send email to  describing the organizational affiliation with SIP and your interest in participating in the WG mailing list.  I hope you understand and appreciate our desire to keep spam from the list, and will bear with this inconvenience."  Any questions or comments should be directed to the list administrator at: [email address]  

To clarify, I don't claim my name or address is something well know in the SIP world, that is the most irrelevant aspect in this context. For the record and the reason I'll point out later, in summary: I have 10 years working with SIP and only SIP, spoke every year at least 3-4 times at SIP related events, participated to many SIP Forum events (including SIPit in Stockholm where I helped setting up the IPv6 SIP testbed, providing several Kamailio instances on IPv6 to be used by all the others for various use cases testing). It was not even SIPv2.0 when I started (RFc3261, June 2002), since then managing and developing SIP Express Router (SER) and/or Kamailio (OpenSER) SIP server projects. The IPv6 support is in our project (May 2002) also before SIPv2.0 was out. My interest was not in learning anything, but helping others to figure out the way to SIP IPv6. We did our work back in 2002.

The issue here is something that's being a reality for many year, nobody is speaking about it. SIP has been hijacked from the purpose of innovating the real time communications over IP networks. It is going to be killed if the situation goes on like this.

Back in early 2000, people working with SIP were open minded, the specification written at that time were for IP networks and new services. It was small companies, enthusiasts, academic institutes and open sources projects really pushing SIP ahead. It was cool, it was fun. Just as an example: KPhone, a very early implementation of SIP softphone, it works even now with audio, video and, surprise, PRESENCE, based on initial specifications (end to end presence) -- and see author's picture, Billy Biggs, when he did it in early 2000.

Now, all organizations that eventually coordinate SIP independent activities, mainly including SIP specifications, are controlled by the old Telco vendors/operators and polluted with Telco mentality. If you are not one of us, fuck off. Besides that, basic concepts of real time communication became nightmares in specifications (did I say SIMPLE?), events and conferences have prohibitive fees, and I can continue...

Hey guys, you do have to retire! With this way of thinking you stopped innovation in SIP, you turned SIP in a protocol to put PSTN architecture on IP. It is not going to work, trust me. We do not longer need PSTN-type of communications, we need new ways of communication. You forced many ideas of services that could have been done very easy via SIP to hack-around solutions through web technologies or similar. Just because it was not a "heavy, well know guy in the gang" doing it.

I may be nobody or somebody in the SIP world now (provided the summary above) and can send an email justifying my interest in SIP and IPv6, that I am not a spammer and beg for acceptance. I'll eventually get it. But if I was just an young guy with good ideas with no experience in the field, just knowing what would make my life easier with VoIP? Should I fax photo ID with SSN and last bill to my Telco?

You, Telco guys, are here for ages. What you brought us lately? Nothing. All SIP desk phones, TDM phones and mobile phones (up to very few years ago) have more or less the interface from 1960 - 10 digits dialpad. You always claimed it is what people want. Right now, you, the vendors, don't how how to get out quickly your touchscreen devices (concept which was brought to the market by a non-Telco-related company) or, you, the operators, how to start social interaction services. Cheaper rates and any kind of innovation in telecommunications lately were because of open source, better and feature rich VoIP switches, plus the new alternative communication streams, don't even think to claim any of those.

You are not capable to change the trend of becoming a bunch of wires and antennas. Soon you won't be even useful for that, as major Internet companies are laying down fiber and power up wifi and wimax networks. I travel a lot, I rather pay 5 bucks for 2 hours internet, check the email, do some voip, video and messaging, than paying you 1 dollar roaming fee per minute.

Your end is coming unless you open your minds and let new, young and enthusiast people coming in and you listen to them. They know what they need, they build their future right now.

The other day experience shows you consider everyone else irrelevant, a bad guy or potential enemy. You could have banned me with my first spam message. You could mark on mailing list settings first (or all) post by 'untrusted' members to be moderated. No, my email was not known to moderator, I am high risk spammer for a 2-hours-ago started list. How many were registered? 10, 20? It was only the welcome message in the archive at that time.

I am not going to try joining again, with less relevance for the benefits of that mailing list. But how many brilliant minds were kicked out from Telco environment because the old dinosaurs in the key positions spending investors and share holders money love their commission with expired vendors? You stay on your private yachts now and need just to call secretary to ship cold champagne, thus, by now smaller, bricks with 10 keys dialpad are more than enough, it would have been even better with ONE KEY. But the rest need to properly interact and communicate.

Fortunately there were and still are THE OTHERS, those rejected with stupid reasons that made no point to retry in the same direction. And they succeeded, my SMS is now Twitter, Facebook & co, my voice (and video and presence which are yet years away to your offerings) is now my own SIP server most of the time, for the rest I have cool options such as Rebtel, Truphone, Gtalk or Skype.

I no longer want to be +123456789, I have a name and cool email address everyone important to me knows and it is easy to remember for them. Btw, if Enum would have made it out, being the unique 'contact address' for all communication meanings, were you able to detect faster that my Enum number belongs to a person with real interest in SIP and IPv6? Would you have been capable to do copy of the number and DNS NAPTR lookup faster than a copy of the email address and web search? Pathetic.

Guess what Telco guys, we were the others, those isolated, but now it is your turn to be. And we will make sure that you change for better or vanish!

PS. The guys behind IPv6 mailing list at SIP Forum might be good people, this is not something personal to anyone. The debate here was about the policies of such organizations, about the management thinking: a walled garden environment, always killing evolution, thing which is present in most of telecom related organizations.

SIP:Provider CE v2.2 RC1 is out

SIP:Provider CE, a complete open source VoIP provider servicing platform, released v2.2 rc1. It uses Kamailio v3.1 for core SIP routing, Asterisk for voicemail and SEMS for B2BUA applications. See full release notes at:

• http://www.sipwise.com/news/announcements/spce-v2_2rc1-release/

This version runs two instances of Kamailio, one acting as load balancer and the second for SIP registrar and proxy services.

Among SIP:Provider CE features: user web management interface, administration web interface and monitoring, call forwarding, click to dial, call blocking, speed dial, postpaid billing engine with individual billing profiles, peering, least cost routing, multi-domain, voicemail, IVR and topology hiding. See more details at:

• http://www.sipwise.com/products/spce/features/