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” 

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.

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/

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!

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!