There’s been a lot of talk about the new SIP stack that is being worked on for Asterisk. The SIP stack is tightly connected to the RTP media subsystem and that’s a part of Asterisk I’ve spent a lot of time with lately. Here’s a few items I’ve been working on and hope to get into Asterisk 12:

Pinefool – Packet loss concealment and more

This branch improves audio handling. If configured  it adds packet loss concealment which improves recordings quite a lot
when there’s packet loss in the network. This is a very simple form of packet loss concealment, which I call the “Poor Man’s PLC”. If there is packet loss, Asterisk will just copy the previously received audio frame to conceal it. Asterisk already has a more advanced Packet Loss Concealment function, that’s hard to activate when you just forward packets in the RTP layer without any transcoding.

This patch also fixes some issues with packet reordering and loss. Previously Asterisk was masqing it, so two endpoints talking G.729 couldn’t fix the packet loss in their code. With Pinefool, Asterisk will keep the properties of the inbound stream on the outbound stream. A lost packet in the incoming stream will cause a lost packet in the outbound stream. Packets arriving out of order will still be out of order on the outbound stream, making it possible for the receiving end point, which in most cases has a jitter buffer with packet loss concealment, to sort out the mess and produce high-quality audio. I have to acknowledge a lot of help in brainstorms over a lot of chat sessions from Martin Festr Vit, the developer of VoipMonitor.org.

Benefit: Improved audio in lossy networks, better quality recordings

Pinefrog – Improved RTCP and call quality records (CQR)

The Pinefrog branch adds reporting of RTCP for streams that have it. By saving data about each call leg in database or outputting it on the manager port, a third-party application can monitor the health of SIP trunks and possibly calculate MOS score on calls. With an intelligent application, the data could also be used to disable trunks that doesn’t work as expected or select codecs based on network quality.

The CQR, Call Quality Records, are stored in any database supported by the ARA, Asterisk Realtime Architecture. This code has been in production in a large set of different sites, from carriers to call centers, for many years in the 1.4 branch.

Benefit: Being able to manage QoS and make automatic decisions based on this input in 3rd party apps

Pinequeue – background audio processing for queues

This patch implements a new audio backend for queues. Previously agents had to wait for a prompt to be played
for a caller in the queue before the phone gave a ring. With Pinequeue audio is handled in the background
and we will interrupt any prompts played as soon as an agent answers the call.

Benefit: No agents waiting to answer customers that in fact is waiting for a free agent.

Rana – Adjust the DTMF Duration and keep it under control

Fixes a lot of problems with DTMF passed through Asterisk. The duration wasn’t handled properly, which resulted in large differences between the incoming DTMF tone and the tone sent on the outbound call leg.

Benefit: 200 ms DTMF will not become 500 ms or even worse.

Roibus – Implements support of comfort noise (inbound only)

With this patch, Asterisk will negotiate and support comfort noise support on incoming media. Comfort noise goes hand in hand with silence suppression in a device. If a device recognizes silence, it stops sending audio frames and instead instructs the other end to generate replacement audio called “comfort noise”.

This patch is not yet complete. Asterisk will not send cng on the outbound stream yet. Regardless, the patch is already saving a lot of bandwidth and is a requirement for Microsoft Lync trunks too. Primarily it is a bandwidth saving issue. Previously Asterisk did not support it so for a 64 K codec we always send 64k plus over head. Coming work will add support for silence suppression in Asterisk, so that Asterisk can make a decision on whether to send actual audio or suppress it. This will add overhead in your Asterisk server, as a DSP will have to be applied to the audio stream to listen in for silence. In many cases this is worthwhile, as the bandwidth saving generates so many benefits.

Benefit: Some VoIP bandwidth calculation web sites estimates that full (two-way) silence suppression and CNG saves between 30-40% of the bandwidth for a call.

Current work: Implementing full DNS SRV-based failover and load balancing in Asterisk

Currently I’m working with improving the failover and load balancing when using DNS srv records. RFC 3263 describes how this should work in SIP. The Asterisk SIP stack has limited support – just grabbing the first alternative, not failing over. With the help of a set of dialplan functions, you can organize failover for the first INVITE in a call, but no failover during the call. This will have to be fixed.

The pinefrog, darjeeling, pinequeue, rana and roibus branches are in production in at least two large carriers and in some of our call centers. Pinefool is pretty new, we’re testing it in a few sites now. They are written for Asterisk 1.4 or Asterisk 1.8 with ports to many versions. Together with the Digium development team, I am working to make this code part of Asterisk 12.

The combination of pinefool, pinefrog, roibus and rana will improve your media handling vastly.

Check your bug tracker and sales records to see if you haven’t got requests for these kind of
features! If you have then download the branches from my subversion tree and try them out! 

/O

PS. Every branch has a README file for the branch in the main directory. Don’t forget to read it. Thanks!

Last weekend I attended a session about Homer Sipcapture at Fosdem in Brussels. Homer is a software that is built in to Kamailio. In Kamailio has there are two modules that is specially adopted for use with this 3rd party Open Source software – Homer SIPcapture.  Homer was awarded a Kamailio Award last year for it’s unique innovation. With Kamailio and Homer, you can capture SIP messages from a running Kamailio production server or from a mirrored port in a switch in your network. What do you get? A searchable database of your SIP traffic and easy to understand visual diagrams of individual SIP sessions. All in a web interface powered by a database of your traffic. I installed it and after a few hours it was a critical tool in my network, helping me to solve problems.

Two components – sender and receiver

Homer has two major components. The packet sender captures traffic and forwards to a receiver. You can use Kamailio in both places, but you can also enable a sender within FreeSwitch as well as use the Homer capture sender that reads off a network interface and sends to the receiver. To use the Homer software with Kamailio, you need a database server (with capacity to handle your traffic) and a web server with PHP support. (more…)

I’ve been working with SIP for over 10 years, and the starting point was the SIP Express Router by IPtel.org. That server has evolved, the project has both forked and merged back and is now named Kamailio. It’s the SIP server I use for enhanced security, for load balancing, for scalability, for all kinds of fixes of broken SIP implementations and much more. This is also the focus of my SIP training classes.

kamailio-4-0Major Kamailio upgrade

Kamailio is soon about to release a major new release, with over 15 new modules, with extended support of IMS, with web sockets and much more. This is the first release where I have contributed actual code. Previously, I’ve focused on making sure that the documentation is covering everything, is readable and correct. For version 4.0, I have done the same, touched almost all module documentation files.

Lear more about Kamailio in a short presentation!

Here’s a quick introduction to Kamailio – the Open Source SIP server – and how it compares to an IP Pbx like Asterisk or FreeSwitch.

A new Asterisk is being worked on. I look forward to it!

A new Asterisk is being worked on. I look forward to it!

I must say that I’m impressed with the new project leader for Asterisk, Matt Jordan. There are big changes happening under his leadership and I don’t think everyone has understood the huge tasks he’s taken on with his team. I’m not sure I’ve understood all of it either.

Here’s a list of things I’ve seen on the mailing lists:

  • Dialog with the community is much improved. Brainstorms happen in the open and things are developed in the open. This is a big change. I just hope I had more time to engage, but that’s my problem. The community seems a bit surprised too. I expected much more participation. We need to relearn how to contribute and discuss, now that we’re allowed to do that again.
    Digium had to re-learn how to interact with the community – but that goes two ways. The community needs to stand up to the challenge. Get involved.
  • Old issues that we wanted to forget are attacked and fixed. Like Masquerade and bridging – it’s all about to change. When I worked with Terry Wilson on the SIP transfer code in 1.2 we learned to hate Masquerade. That’s years ago and the masquerade is still around, annoying all Asterisk developers. It’s a complex operation that, well, causes a lot of issues. Time to get rid of it and get a modern multichannel bridge active in every call.
  • Manager is being changed dramatically.  Manager is getting an overhaul into something more logical for the current design of Asterisk and languages and methods used to build AMI applications. Yes, this will affect everyone’s 3rd party applications. Applications needs to move on, sometimes we just can’t be backwards compatible. Most applications doesn’t support punch cards and output exceed 80 characters per line quite often… Asterisk is ten years old and it’s time for some new designs. Asterisk 11 is a LTS that will live for a long time, giving developers time to adopt to the new Asterisk.
  • The SIP Channel is rewritten. This is a gigantic project and has been needed for almost ten years. I never thought we could get funding for a complete rewrite, so I opted for remaking the current code in my old Codename Pineapple project that never got fully funded at the time. I have tons of opinions about a new SIP channel, but have no resources to really participate, just add a comment here and there like a grumpy old grandpa…
    I wish the developers follow my SIP2012 efforts (soon to be renamed SIP2014) and learn modern SIP and have the new SIP functions as part of the design. I do hope that they DO NOT base it on the current SIP channel that lacks transaction support, has poor ideas on SIP branching and forking and… You know. The new SIP implementation is required to work in larger SIP networks with proxies, unlike the old SIP channel. We need domain support, we need SIP URI support, we need security that works. That means that the developers need a better understanding of SIP than has been the tradition in the Asterisk development team. They’re always free to contact me with questions, which would be a positive change too.
  • New APIs are developed. Manager and AGI and ExternIVR are things that have happened and evolved but was never part of a consolidated effort to create a good unified API to Asterisk. We’ve discussed this at many Astridevcons under different names – PineMango was one of them. For Asterisk to survive, we need a modern API.
  • Realtime is changing. Josh Colp is working on a new object handling system, again something discussed many times that finally happens. We do need a replacement of the poor realtime architecture that has been extended beyond control. We need to be able to use an API to manage in-memory objects in real time. It seems to me that this is exactly what File is working on.

Doing all of this at the same time sounds to me like someone wanting to make a stand. If all of these project will be completed we will have a brand new Asterisk coming out. Kevin changed almost all the internals for the better . Matt and his team will change a lot on this list (and propably much more), things that change the functionality for the better, not just improve stability. Both are needed, but from a marketing standpoint all these changes are big things that can make a real splash at product release.
In the future I hope we can have time to spend on innovation, new things that will amaze all of us, that fits into this new Asterisk. Not just rewrites and stabilization.

The Matt Jordan challenge – what’s the community response?

Inspiration for this new stuff needs to come from the community. We expect too much work being done by Digium – even though they keep showing us that they still invest heavily in Asterisk, even in bad times. Can the community step up and assist in the redesign of our good old Asterisk? There are so many companies out there getting their living out of Asterisk. Fund a developer, contribute with resources, test, participate. The Matt Jordan challenge is on!

Thank you Digium

A big thank you to Digium and Matt and your team for all this work. It sounds like you are having fun. We did need more fun in Asterisk. We did need more open communication with the community, improved interaction – and I’m very happy to see the changes happen. The next step is a vision for Asterisk – that’ll be the OEJ challenge. Where is Asterisk going?

 

SIPitSIPit is one part of the SIP development. IETF develops new proposed standards and additions to existing standards – but they need to be tested for interoperability. Just writing documents is not enough. We need code and we need agreements that the standards actually work and deliver interoperability to the users. One implementation following the standards should be able to interoperate fully with another implementation of the same standards. If not, we have a huge problem.

The SIP Interoperability Testbed

SIPit is organized by the SIP forum and lead by Robert Sparks, one of the engineers in the IETF. Robert has organized 29 SIPit events around the world and the next one, SIPit 30, will be hosted by Cisco Systems in Raleigh-Durham, North Carolina, USA. At SIPit we test both the base SIP standard, as documented in RFC 3261, and the new additions, like SIP Outbound, SIP identity, GRUU and ICE. We have phones, proxys, conference bridges, session border controllers and all kinds of devices as well as SIP stacks under development. We have a gentleman’s agreement not to reveal anything else than generic test results. I can’t use Facebook and say “ha ha, Saul’s new SIP server sucks!“. This leads to a very open and helpful environment. We teach each other, wants everyone to succeed and learn a lot in the process.

Here’s a presentation with a few bullet points to explain to you and your employer why you need to register now! The company will earn on it, get a better product. You will learn more. See you at SIPit!

 

IPv6friday.org :: Learn more about IPv6 every FridayI’ve started a separate blog to inspire people to learn more about IPv6 and start their own labs. It’s called IPv6friday.org and publishes a short article about IPv6 every Friday. I don’t know how the idea got started – I think it was just this Tweet that got a lot of responses.

IPv6 Friday beings

The main problem with IPv6: Knowledge and experience

The main problem with IPv6 today is the lack of knowledge and experience among all the network engineers and system developers out there. In Sweden, we have been running a few very open meetings about IPv6 to discuss and map what to do. Almost all discussions ends up with the question: How can we get companies to invest in IPv6 training on all levels? How do we get the technical people to start playing with IPv6? I don’t have the answer, but for myself, I’ve learned a lot by publishing these articles. Learning new stuff is always fun. As a parallel project, I’m moving a lot of my own servers and services to dual stack (or in some cases, single stack IPv6) servers. It takes time, I make mistakes and I discover a lot of issues in various pieces of software.

Follow me and spend 30 minutes on IPv6 every Friday!

Spend 30 minutes with IPv6 every Friday!Please join the ride, follow the flow and spend at least 30 minutes on IPv6 every Friday. Learn more, lab and join the discussion. In addition to the blog, there’s a Twitter account, Facebook page and a Google plus page. If you have ideas or want to contribute, just contact me.

IPv6 is the future of the Internet. It’s required for the Internet to grow. It’s required for the Internet to be for everyone on the planet. It’s needed for true peer-to-peer applications. We do need it to stop spending time on NAT traversal in SIP and focus on more important issues – like how SIP can become competitive to Skype and FaceTime and the architecture and requirements for a global open Internet-based federation for realtime communication. 30 minutes a week isn’t too much of your valuable time. It’s an investment for the future that will help both yourself in your personal career and the organization your work for. See you next Friday!

 

RFC 3261, The Session Initiation Protocol, was published in 2002, six years after the initial work on SIP. Wikipedia writes

“SIP was originally designed by Henning Schulzrinne and Mark Handley in 1996. In November 2000, SIP was accepted as a 3GPP signaling protocol and permanent element of the IP Multimedia Subsystem (IMS) architecture for IP-based streaming multimedia services in cellular systems. The latest version of the specification is RFC 3261 from the IETF Network Working Group published in June 2002.

The SIP 2012 Realtime Communication Framework - a specification that we need!The problem here is that SIP 2.0 has changed a lot. It’s been formally updated by  a number of RFCs: 3265, 3853, 4320, 4916, 5393, 56215626, 5630, 5922, 5954, 6026, 6141 (according to tools.ietf.org). And that’s the updates that changes the core protocol. In addition, there is a lot of extensions and additions to what now could be called The SIP 2012 Realtime Communication Framework. The core protocol is now just one piece of the puzzle.

Customers need to change requirements

I’ve seen too many public tenders and requirements that refer to “SIP according to RFC 3261″. This is like buying a PC referring to Windows 95 as the base requirement for compatibility. So what should be referred to? Here’s the core of the problem. There’s no simple document or reference profile to refer to. And there is a huge gap between the IETF and the current implementations, something that we see every year at SIPit events. Only customer requirements can push vendors to move forward.

An example: The SipConnect specification from the SIP forum

The SIP Forum SIP Connect 1,1 specification is a good example of a reference profile that customers can use. It focuses on the SIP trunk – the connection between a PSTN gateway provider (ITSP) and an enterprise PBX. SIP connect makes it possible for customers not to refer to RFC 3261, but a more complete specification that builds a framework on top of the specifications. During the work with SIP connect, it was revealed that many PBXs used SIP in a way that was actually not supported by the current set of RFCs. The SIP forum took this issue back to the IETF and the result is GIN – a way to register for many E.164 phone numbers (RFC 6140). Building a reference framework with customer focus actually added to the standard framework, based on the use in the current implementations.

There are more frameworks built on SIP – IP Multimedia System (IMS) from 3gPP is another example, but not for business users or vendors selling SIP solutions to consumers. The 3gpp is active in the IETF, trying to make sure that changes and additions are documented in RFCs and made compatible with the rest of the SIP framework.

Wanted: A reference profile for SIP phones and servers

If you look at the original set of SIP RFCs, there was a lack of solutions for NAT handling. In the current SIP framework the IETF have added new standards like ICE/TURN/STUN and SIP outbound. There are also standard frameworks for configuration update notifications, registration management and TLS certificate management – something that most vendors implement in a proprietary way. We see more implementations of these additions at every SIPit test event, but most phones on the market (and most servers) are still not supporting these new standards. We need a reference profile (maybe from the SIP Forum?) that customers can refer to in order to put pressure on vendors to update their implementations.  SIP implementations that is based on more current work will lead to better products, more NAT and IPv6 friendly solutions and improved security. Standardization in configuration and security management will lead to lower costs and less vendor lock-ins.

The question is who starts the work specifying the new reference profile? 

 

Avanzada 7 have published the video from my talk at Voip2Day in Madrid in the beginning of October. Enjoy!

( 28 Oct, 2011) oej.  

In a SIP network, you often have multiple servers communicating with each other. As soon as you add TCP and TLS to the mix, you will want to reuse connections. Why? Setting up A TLS connection involves a lot of messages going back and forth in the process up validating certificates and coming up with keying material for the encrypted session. Now if you have a re-invite that wants to put a call on hold, you don’t want to loose a lot of packet-roundtrip-times while this happens. A better solution is to keep connections open where possible and allow communication both ways.

RFC 3261 states that if you open a connection with a connection-oriented protocol, like TCP or STCP, the connection should stay open to cover the whole transaction. This means that if the other end sends a message in the dialog, a connection needs to be opened in the other direction. This is of course a problem with NAT between a device and a server, something that the SIP Outbound standard handles. Between servers, like B2bua’s and proxys, the problem still exists. This is managed by the Connection Reuse RFC, RFC 5923.

Mutual TLS authentication opens up for two-way communication

RFC 5923 – SIP Connection reuse – explains how this can work. One requirement is that the TLS connection has mutual connection, which means that the server ask the client for a certificate. The client indicates in the request that it is prepared to receive inbound requests, not only the response to the request, on the same connection. When that happens, the server and client sets up a connection table where the content of the certificates are stored – the domains and host names. Now if one of them has a request that is targeted to the same domain and the same IP and port (after DNS SRV lookups), the connection can be reused.

Checking and caching the certificate content

When the connection is initiated, both ends provide TLS certificates that contain one or multiple names or SIP uri’s. This list is cached and associated with the session. Now, if the same server host multiple domains, you can’t use the connection if the domain that is the target of the request doesn’t match the names in the certificate. In that case, you need to open a new connection to the same server.

Use DNS host names instead of IP addresses

On a related topic, notice that the RFC always use host names and not IP addresses in the Via: headers. This is of course a requirement if you want to match certificates. For TLS to work in all directions, host names should be used in Via: and Record-Route/Route headers. With a GRUU, you can also have a domain in the Contact. This also helps IPv4/IPv6 dual stack handling, letting every path select the optimal connection.

Combined with SIP outbound we have open connections all the way

Connection reuse is an important feature for all SIP servers, B2BUAs like Asterisk and SIP servers like Kamailio. Without it TLS will be hard to use and cause delays that will affect the calls. In combination with SIP Outbound, where the UA manages the connections to the first-hop servers, it is a working solution for TLS over NAT as well. Keeping TCP/TLS connections open like this is not new, Jabber/XMPP has done this from start. It’s just new to SIP.

I think SIP Connection Reuse support should be on the list of requirements when you select your next SIP application server for your Open Unifed Communication platform.

A modern SIP invite with SIP identity, outbound, ice and hopefully S/MIME will cause UDP fragmentation. A SIP stack that wants to stay up to date supports TCP. Anyone implementing a SIP network wants to support TCP. When we are there, beyond UDP, we might as well think about using TLS. Is it time to produce a SIP profile for user agents? SIP UA 2011.

( 18 Oct, 2011) oej.  

Next Page »