The very first SIP-compatible software I installed myself was SER, Sip Express Router, from iptel.org, a spinoff from the Fokus research institute in Berlin. During the years I have worked with SER and OpenSER/Kamailio, I’ve become friends with many of the developers and have contributed with documentation and training. The team gathers world leading SIP experts and developers, so it’s a joy to meet them and brainstorm and share experiences. In almost all my installations and platforms, a SIP proxy is at the core of the real time multimedia platform. My choice has always been SER/OpenSER/Kamailio.

Starting as a SIP proxy, moving on as an extensible SIP server

Sip Express Router started as an Open Source SIP Proxy. Today we see Kamailio, based on the common sip-router.org core, as an extensible SIP server. With an embedded presence server, http support and interfaces to python and lua for scripting, it’s a platform that can handle many different roles in a large-scale SIP architecture. IPv4 and IPv6 support from the beginning, security integrated and a very active development team. Everything you need to build a standard-compliant cool network for your organization’s real-time communication. 10 years of success.

Jubilee September 2nd, 2011 where it all started

The 3rd of September marks 10 years since the start. Reason to celebrate, don’t you think?

We will celebrate on Friday, September 2nd and into the night. FhG Fokus Research Institute hosts a one-day conference session with all the core people. If you have any interest in SIP and these platforms, make sure you will be there.

The event is organized with sponsorships from FhG Fokus Institute, Asipto, Amooma and TeamForrest. At the same time local events will be organized in Barcelona, Spain and Vienna, Austria.  Read the agenda and register today!

Posted: 09 Aug, 2011 | No Comments
Categories: Open Source , OpenSER/Kamailio , Product news  By: oej.  Print This Post  

A friend of mine, Jacob Schlyter, has not only been busy working on DNSsec around the globe. He has also been co-writing a new draft in the IETF DANE working group. He blogs on kirei.se:

The working group’s first draft describes how to use DNSSEC to associate certificates with domain names For TLS. In this context, a certificate association is a secure binding between a DNS name, TLS/DTLS transport protocol (i.e., TCP, UDP or SCTP) and port number, to an end entity’s certificate or to a certification authority’s certificate.

This proposal builds a distributed PKI based on DNS.  If you want to call me in the voip-forum.com domain, you will be able to get my certificate chain from DNS and set up a secure and trusted session. The current PKI model used in the web delivers encryption – but few bothers with checking identity of the other end, check if the certificate chain is trusted or even if a certificate is revoked.

In SIP, we can do better and really kick off DANE. I will work on this and write more as I make progress in trying to understand the details.

For many years I have believed that DNSsec is a platform that will change the trust model on the net. Now, the light is on the ICANN, IANA and the TLD registries. Will they earn our trust?  Will they be better than the current set of web CAs that someone else approved for all of us? If not, we will have to start building a distributed trustworthy root soon. The technology is getting there, so the focus needs to move to the people and organizations that will be the new platform. These are interesting times. Let’s start discussing SIPdane and get a few implementations running soon!

Posted: 28 Mar, 2011 | No Comments
Categories: dns , dnssec , IETF standards & drafts , Open Source , sip , tls  By: oej.  Print This Post  

FOSS Stockholm is a group of Open Source developers, users, advocates and fans that meet and talk about various Open Source related issues. Today we had a lot of good talks on Open Source in development countries and it’s affect on democracy, about Open Source project management and other interesting topics. I had a quick overview of realtime communication security in order to stimulate a discussion. The slides are now published on Slideshare.

Realtime communication security – SIP, XMPP and others

View more presentations from Olle E Johansson.

Posted: 24 Feb, 2011 | No Comments
Categories: Open Source , Security , sip , XMPP/Jabber  By: oej.  Print This Post  

You are drafted for my IPv6 SIP task force! Here’s our action points:

• Review IETF documents on SIP IPv6  migration. Are all depending on all devices having dual stack? If so, does it really work?
• Test IPv6-only solutions. Do they work? Is it possible to use Asterisk or Kamailio for reaching IPv4 SIP devices?
• Test DNS SRV records. Are they usable to indicate your preference for IPv6 or IPv4 calls to your domain? Will devices support it?
• Check SIP service providers – do they support IPv6 today?
• Check Open Source solutions – is the IPv6 support complete? Does it work both in dual stack and single IPv6 stack mode?
• Check phone manufacturers – does their products support IPv6?

Are there other questions to sort out? Is so, let me know. And let’s make 2011 the year when the SIP world embraced IPv6!

Posted: 01 Jan, 2011 | No Comments
Categories: ipv6 , Open Source , sipit , VoIP Service Providers  By: oej.  Print This Post  

Jon Postel captured an approach to make the Internet a more robust place for applications to live in – and added it to RFC793 (the definition of TCP at the time) :

“TCP implementations will follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others.”.

Robert Sparks has written an article on the SIP Sessions blog about the importance of this for SIP implementations. And he should know. Robert has been managing 25 interoperability sessions with SIP developers. Endless patience with developers that claim that their interpretation of the RFC is correct and that the other side is damn wrong and that’s exactly the reason why their implementation fails the call, the registration or the chat session. I’ve heard Robert saying to me and others many, many times something like: “Yes, there is an issue here, but your app should be more generous and try to handle the situation.” Robert summarizes his thoughts this way:

“Real systems will have imperfections. Systems that use the robustness principle make it less likely that those imperfections will result in failure. Introducing elements that don’t follow the principle negates that robustness, and in real systems,  will cause those systems to fail.”

Read this article named “The Robustness Principle Has Two Parts” 

Posted: 27 Feb, 2010 | No Comments
Categories: IETF standards & drafts , Open Source  By: oej.  Print This Post  

I am working with two very different implementation projects this winter. One is about using Asterisk in large call center environments. Another has a goal of building a SIP network for 15.000 phones in a university.

Asterisk for large call centers – full control

The call center platform is focused on a lot of PBX functionality. Every agent stays connected to a conference session, where customers are connected and disconnected, recording is enabled and disabled, dtmf is used to control various services and both AGI and AMI (the manager interface) are both being used heavily to integrate with a controlling application. Asterisk is in full control of each and every call, all the time, but the application controls the flow of the calls. The dialplan is very small for a large-scale Asterisk installation.

Large scale SIP networks – Asterisk on the edge, providing services

For the university, scaling is important. It’s a plain SIP network, with two computer centers in different buildings. All accounts are managed by LDAP, there’s no account defined locally in the VoIP platform. SIP proxys (Kamailio) rule this network and DNS is used for failover. Many services like call transfer, three-party conference calls and call forwarding will be handled by the phones. Asterisk serves as gateways to the old world, Nortel systems, and feature servers for IVR, voicemail and switchboard. No single server is in control of any call.

The power of open standards and open source

Two completely different designs, both made possible by Open Source and Open Standards. Both of them needs to scale. Both of them needs failover, redundancy and stability. And in both cases, we’re replacing expensive legacy telecom equipment with new platforms that will cost less to operate, that has a higher degree of interoperability and much more functionality than the previous solutions. Open telephony wins.

Posted: 21 Feb, 2010 | No Comments
Categories: Asterisk news , Edvina news , Open Source , OpenSER/Kamailio  By: oej.  Print This Post  

I’ve created a test branch for patches hidden in several Asterisk development branches – all based on Asterisk 1.4

• RTCP improvements from pinefrog-1.4
• “Sip show chanstats” cli command
• The branch pinequality-* giving you the manager “sipchannel” event to check QoS

This branch is now open for testing and I need feedback. Among the improvements you’ll find:

• Manager QoS events during a call and after a call
• Improved RTCP – it now works for p2p bridge in RTP, which means that we will get RTCP stats for many, many more sip calls
• RTCP over NAT improvements – if Asterisk is behind NAT, we will now kick-start RTCP from the remote end by sending a first “emtpy” RTCP packet to open a NAT port.
• QoS reports to realtime storage after each call – one report per call leg (The amount of data and the names will change)

The reason that I store  QoS data in realtime, is that the CDR is usually gone or frozen at the time that we freeze the RTP channels and get the last QoS data. The QoS reports can’t thus be included in CDR, you have to merge it in automatically later in your database.There’s still a lot to do, but please test it so I get some sort of feedback.For testing, don’t forget to run the “rtcp debug” cli command so you can see what’sgoing on in the RTCP channel.

FAQ

• Yes, this work will be ported to trunk and hopefully merged soon.
• No, we don’t support RTCP XR or MOS in this work
• No, I have no reason or funding to adapt it to 1.6.x at this point.
• No, the RTPAUDIOQOS channel variable is not changed. You will get more data than before – for many more calls.

This work is funded to 20% by companies in the community. If you want to cover the80% that’s still not funded, please contact me by e-mail: oej@edvina.net.
URL:  http://svn.asterisk.org/svn/asterisk/team/oej/pinefrog-deluxe-rtcp-test/

Posted: 21 Jan, 2010 | [2] Comments
Categories: Asterisk news , Open Source  By: oej.  Print This Post  

Kamailio - the successor to OpenSER – has been released in a new version, 3.0. This version is based on the merge between SER, SIP Express Router, and OpenSER code bases and developer teams. It’s a SIP server that you can run as a SIP proxy, a session border controller, a SIP load balancer or SIP application server. In version 3.0 you have the power of all the modules and applications in OpenSER and the raw strength of the SER core in one product. Go check it out today!

Posted: 21 Jan, 2010 | No Comments
Categories: Open Source , OpenSER/Kamailio  By: oej.  Print This Post  

During 2008, I worked with my Portuguese business partner Wavecom to build a large installation of Asterisk and OpenSER in Portugal. The network is now running 300 servers, 250 of them running Asterisk, FreePBX and OpenSER. It’s handling 200 connections to legacy PBXs of all kinds and over 10.000 phone numbers. During 2009 we’ve developed a failover solution, to make sure that every FreePBX server always stays up, regardless of the state of the hardware.

We’ve migrated 34 Universities to use Open Realtime Communication with Open Source. They are now migrating their user base from old PBX phones to modern VoIP phones.

Want to learn more?
Come to Amoocom in Germany, May 4-5, 2009 and listen to my talk!   And if you need help with similar large-size projects, contact me on info@edvina.net!

Posted: 31 Mar, 2009 | No Comments
Categories: Edvina news , Open Source , OpenSER/Kamailio  By: oej.  Print This Post