2010 February

February 2010

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.

Hans Petter Selasky alerted the Asterisk developer community about a potential harmful pattern in Asterisk dialplans on February 9th.  His example is as follows:

exten => _X.,1,Dial(SIP/${EXTEN}@testsip)

He writes: “And if ${EXTEN} = “000@testsip&SIP/333” what turns out to happen then is similar to SQL injection 🙁 “He is exactly right. Many VoIP protocols, including IAX2 and SIP, have a very large allowed character set in the dialed extension, a character set that allows characters that are used as separators to the dial() and the queue() applications, as well as within the dialstring that these applications send to the channel drivers in Asterisk. A user can change the dial options and dial something we should not be able to dial in your system. This article describes the issue in more detail and gives you some help on how to avoid this causing trouble in your Asterisk server. (more…)

On my wishlist for 1.8 long-term-support release the #1 item is a new media negotiation framework for Asterisk.

The history – something to learn from

If we had integrated John Martin’s videocaps in time for release of 1.4 we now would have enjoyed four releases of an Asterisk with much better video support, instead of the broken support we have today. Integration of that code was denied because of plans of something greater and bigger, which we have discussed for years at many Astridevcons. Because of us denying this and other code,  outside-of-tree code has been around that fixes a lot of issues and the original Asterisk still lacks proper video support.There’s also a few codec negotation patches that has been around and maintained for years, one of the major ones being Maxim Sobolev’s patch.

What are the issues we need to solve?

There are a few main issues here:

  • Codecs: Codecs should not be handled as a bit, being turned on and off. Both audio and video codecs have attributes that we need to take care of properly
  • Call setup: When answering, the properties of the answer needs to be relayed to the calling channel, not just a control frame that says “somebody answered”.
  • Media streams: We should be prepared for multiple media streams, including multiple media streams of the same format

The new solution should be extensible, it should be easy to add both new codecs and properties.The solution has to be configurable. The way you want Asterisk to set up a bridge between two channels varies much. Some people prefer Asterisk doing transcoding some people want Asterisk to stay out of as much trouble as possible and just set up whatever is most simple. Other users just want to standardize all call legs to one type of phone, but have a different policy for other connections. There’s no one-solution-fits-all.

Asterisk needs a new media negotiation framework for continued success

We did write up a few documents on this a year ago at Astridevcon in Phoenix. I would really like to see some work on this. My personal feeling is that this is very important for the continued success of Asterisk in the marketplace. The amount of long-lived patches in this area that has been maintained for years shows that we have to do something (and that we sadly have ignored customer demand). The arrival of new codecs and new solutions, like video conferences with multiple audio and video channels, with text channels and possibly other types of channels (lika a binary channel for MSRP and digital ISDN) – all this tells us that we have to get there. (more…)