After each SIPit, Robert J Sparks writes a summary that includes the results of a survey done during SIPit and reports from the multiparty tests. These are all very interesting and show where the SIP developers are in relationship to the IETF work.


The SIPit26 summary shows  an uptake in SIP implementations that support TLS. It also reveals that we’re going to make the automated self-tests that has been created during SIPit available on line. We’ve created self-tests for TLS, Early media and IPv6. Hopefully there will be more tests added to this suite. Thanks to Nils Ohlmeier and Daniel Constatin Mierla for helping me with these!

The next SIPit is not determined yet - SIP forum is still looking for a host, primarily in Australia or New Zeeland. If you want  to know more about what it means to be a host, please don’t hesitate to contact me. SIPit test events are important for the whole business. Read the report and you’ll understand why.

At SIPit26 we began setting up a series of automated self-tests for IPv6, like we’ve done previously with SIP/TLS. We also integrated IPv6 in as many multiparty tests as possible, to see how IPv4 and IPv6 lived together.Some notes and experiences:

• IPv4-only applications will receive IPv6 in messaging. Even if an application DO NOT support IPv6-native connections, the application will surely get IPv6 addresses in various places in the message. In SIP, a call may traverse an IPv6 proxy before reaching your IPv4 proxy or phone. Via headers will have IPv6 and maybe a record-route header too. All user agents needs to support this. We had at least one crash in a proxy that failed to parse an IPv6 address.
• Placing an IPv4 call to a proxy that forwards the message to an IPv6 phone without handling RTP traversal leads to issues as well. The phone gets an IPv6 address in the Contact: header and failes to send the ACK properly. This happened with Asterisk. Because of parsing failure, the parser gave up and sent ACKs and BYEs to the wrong address.
• We did successfully set up calls between IPv6 user agents using IPv6 proxys. The failures happened in the mixed scenarious.
• When placing a call to a domain that was configured with both A and AAAA records for the SRV records, but only one of them responding, we noticed long timeouts before failover, if that even happened. Many discussions about this followed, which lead to the conclusion that this was a poorly configured domain. Some implementations have hard-coded a preference for IPv4 since IPv6 is mostly used over tunnels and add latency today. This should be user-configurable. An owner of a domain can use SRV record weights to indicate a preference to one or the other protocols, which is a better solution. If you use IPv6 over tunnels, make sure that you separate host records for A and AAAA and have a preference towards the A record hosts in your SRV records.

We do need to continue testing all kinds of migration scenarious to  be able to come up with a best current practise document. SIPit26 gave us many good experiences to build from. I hope that testing continues at SIPit27 with the new SIPit IPv6-o-matic(R)(C)(TM) and the prompts from Allison Smith!

SIPit 26 is over and everything was packed together quickly, thanks to help from sponsors and participants. It did surprise me a lot how quickly we could pack all the phones, cables, tables and equipment together. Three days to set everything up, three hours to take it down.

I think it’s been a great SIPit. Unfortunately, I did not have time to test much myself, but I will take the oppurtunity to test at the next SIPit. On the other hand, we’ve run many successful multiparty tests. Successful tests doesn’t mean that everything works as expected. It’s a good thing to locate new bugs in implementations, to find issues with the standard specifications.  That’s exactly why we run the SIPit interoperability tests.

SIPit26 added a lot of focus on IPv6. We integrated IPv6 in standard tests, we added IPv6 self-tests and we run IPv6 multiparty tests. I’ll write more about the results and experiences learned later.

A big thank you to:

• The SIP Forum and Robert Sparks for organizing SIPits
• My co-host, TANDBERG.
• The sponsors: .se, Ingate, Intertex
• Our partner, the IPv6 Forum
• SNOM Technologies that provided all the phones
• My family that helped me set things up. Lisa printed badges and welcome packs, Erik that helped me building the network
• Lasse Andersson at Whizom who helped me all week, including setting up everything
• Electrum Conference in Kista, that took care of us in a good way and handled everything very professionally.
• All the SIPit partipant companies and attendees. Together we make the SIP world better, promoting interoperability between vendors and products.

Being a SIPit host is an experience I would happily repeat. Join the club and offer to host a coming SIPit. Next up is Asia, possibly Australia. After that it’s back to the USA again. Now, it’s time for me to get back to a normal life and get out in my garden.

With SIPit greetings from a sunny Sollentuna!
/Olle

In a joint press release, the SIP Forum and the IPv6 Forum launches a cooperation in order to raise the pressure on the members and the market to move forward with IPv6 and realtime SIP communication.

“SIP and IPv6 are the two fundamental Internet plumbing pieces of the future Internet. This partnership will allow the SIP Forum and the IPv6 Forum to leverage each organization’s powerful worldwide user base to drive the right knowledge and best practices to the Internet community at large,” said Latif Ladid, President of the IPv6 Forum & Emeritus Trustee Internet Society. “This union will smooth the adoption of these two technologies and spur Internet growth and solid sustainability.” 

“The SIP Forum shares a similar mission and vision as the IPv6 Forum for the broad interoperability and adoption of open standards, next generation Internet-based technologies and services,” said Richard Shockey, SIP Forum Chairman of the Board. “By coming together, our two organizations can help move the industry forward and develop the foundation to fuel a new generation of communications innovation.”

I believe this partnership can lead to a lot of progress. Unified Communication ties people together across boundaries. One of these boundaries will be the IPv4 and the IPv6 Internet. The SIP industry has a responsibility to make sure that this transition works seamlessly and that our customers get products and services that will continue to work as the IPv6-only part of the Internet starts growing - and I’m not only talking about laptops with softphones and chat software - SIP is an application that will run on smartphones, TV sets, pads and all kinds of connected things. A Unified Communication network requires IPv6 to be unified.

SIPit is the main interoperability event for all things SIP. It’s organized by the SIP Forum and creates good feedback to the IETF. Asterisk has been participating in SIPit during many years and in many variants  - videocaps, Marc Blanchet’s IPv6 branch and the standard Digium releases. All these tests has lead to a large amount of improvements for Asterisk and have helped us to build a network with other developers in the business, a network which helps when we have bugs that involve interoperability with these devices or servers. SIPit has proven important for the success of Asterisk, and thus it is also important for  everyone in the Asterisk community. 

Now, when we are working on the next  long-term release (1.8) we really need to test again and make sure that we interoperate properly. New stuff, like Terry’s SRTP branch, my RTCP work and the call completion and caller ID update work needs serious testing. We need feedback to be able to fix the issues with the TCP and TLS support. (more…)

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:

[from_sip]

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…)

Let’s change everything - and cause no damage for the end users!

The current version of the Internet is up for a big overhaul. We have to change the whole infrastructure it runs on, the famous IP protocol. A lot of work needs to be done and it affects everyone that works with the infrastructure. The result of all the hard work? Everything will work exactly as before. Nothing gained for the end-user experience. That’s why very few are paying attention to IPv6. It is very hard to convince the persons in charge of IT projects what the benefit is compared with upgrading all PCs to Windows 7 or installing that new spam filter for e-mail.

Internet telephony needs IPv6 peer-to-peer addressing

It is easy to explain the need for a unified address space using telephony as an example. The fact that all companies and homes use a private address space that can’t be reached from the outside doesn’t matter when it comes to the old-fashioned Internet applications. The web browser contacts a server on the Internet. The e-mail client contacts an e-mail server on the Internet. The IM/Presence application contacts a server on the Internet. Nothing needs to reach in. Until you start using peer-2-peer applications. And telephony is a very common p2p application.

• -”You know that you have a broadband router that use one IP address from the Internet, assigned to you by the provider?
• “- “Yes”
• - “Do you also know that the broadband router let’s all your devices on the inside share this address by setting up a private address range that can’t be reached from the outside?”
• - “Yes”
• - “If you add an IP phone on the inside - do you want to be able to receive calls?”
• - “Yes”
• - “How do you think I can call your phone  directly, if we don’t share the address space?”
• - “I don’t know.”

With IPv6, true p2p Internet telephony will become possible. When we get rid of the need for NAT, network address translation, we can finally separate access and policy. With a unified address plan, every device on the net has the possibility of reaching every other device. Policys might prevent access and we implement these in a firewall software in the systems or in dedicated systems.Currently, in order for a phone to work on the inside of a NAT, most implementations connect to a server on the Internet. In order for an incoming call to get through, the phone or the server keeps sending empty messages. As long as these messages are sent - occupying unneeded bandwidth and resources in the network - the NAT believes there’s a communication session going on and let the messages in. The NAT itself has no policy, it just checks if there’s a client-initiated session going on or not. As long as the NAT believes there’s a session, it will forward packets from the outside to the inside device. When you have an incoming call, the server can forward an alert to the phone and the phone will start ringing. The same setup is used if your organization has a PBX system on the inside and use a SIP trunk provider on the Internet.This solution is used by a range of applications and are not unique in any way for IP telephony.  IPv6 will make it easier to enable true Internet telephony and other p2p applications, as long as your firewalls let it happen. (more…)