Video sessions in the browser opens up for a lot of new applications. While this has been working with various plugins, new opportunities will open up when it becomes part of your standard web browser. HTML5 introduced native video in the browser. New standardization are looking into peer2peer multimedia sessions in the browser, not just broadcast. This opens up for a large set of applications, from “click2call” without plugins to video chats like in Facebook and Google+. This is exciting. And all the old SIP architects seems to have jumped onto this project, trying to get things right from start in this second generation effort. (more…)

Posted: 11 Aug, 2011 | No Comments
Categories: Asterisk news , IETF standards & drafts , ipv6 , Security , sip , tls , Voice 3.0  By: oej.  Print This Post  

Imagine working at your desk, getting a phone call from your friend Randy. You answer on your IP phone. Being Randy, he suddenly wants to play a new jingle he created while being in the mood the day before. The phone speaker is not a good device for a cool guitar riff – is it? On the same desk you have your PC with a softphone that supports HD voice and really cool loudspeakers. Why not transfer the audio to the PC while still using the phone’s microphone? After that, you want to play a video for Randy. Now you want to add media from your laptop to the call – while the call is still managed by the IP phone.

This is a true multimedia session, that is not that far away. But it’s too complex to manage in the SIP protocol today. I just found out about the SPLICES working group in the IETF that is working on this issue. I also know that the Asterisk development team is working on a new media architecture - something we’ve needed for many years. My presentation about the new media architecture from Astridevcon 3 years ago talks about being able to add streams, have multiple streams of the same kind and remove streams dynamically during a call. SPLICES, when finished, will help us implement it in a really cool way in SIP.

Another mailing list to follow.

Do you know another thing? Randy and I wouldn’t be able to have this call as easily if we did not use SIP over IPv6. Doing a call like the one above over two NATs would be awfully complex…

Posted: 06 May, 2011 | No Comments
Categories: Asterisk news , IETF standards & drafts , sip  By: oej.  Print This Post  

Sollentuna, Geneva and Prague, April 1st, 2011: The IETF and the IPv6 Forum today launched SIP-six, the new version of SIP that cleans up a lot of misunderstandings and greatly simplifies implementations of SIP. 

• ”We realize that 99% of the SIP users use SIP for PSTN phone calls. The original SIP standards was written with other applications in mind, a vision that never came true.” said Bob Plug, area director in the IETF. ”That’s why we sat down and said to our selves that this should be way more simple.”

The SIP-six standard totally removes the dependency of domains and URI syntax. There’s no longer any point in using this, since everyone seems to think that IP addressing is more than enough. The new standard use part of the vast IPv6 address space to incorporate the E.164 phone number as end point addresses. This is the reverse of the reverse phone number usage in the enum standard, which is no longer needed in SIP-six.

By using IPv6 mobile IP, phone users register their phones and get access to their phone number. Users that need security can easily integrate IPsec into their setup. Media and signalling uses the same addressing scheme and is mixed so that both SIP-six, RTP and RTCP only uses one port address – but in this case a single port address with a 32 bit subaddress identifying the media stream. This finally solves a lot of the firewall traversal issues that SIP v2.0 had. With the combination of mobile IP and use of public IP addresses NAT traversal won’t be an issue.

The testbed for SIP-six has been running for a year at six choosen large SIP carriers, with the assistance of Edvina AB in Sweden and ViaGenius in Montreal, Canada. In an International effort, the testbed is today put in production and Roboid phones all over the world is automatically connected to this worldwide network.

• -”We have for a long time pointed out that IPv6 is not only a replacement of IPv4, it’s an enhancement that is the breeding ground for new types of applications.” says Olle E. Johansson, chairman of the SIP-six working group. ”With SIP-six we really use the potential of the IPv6 address space and new technologies, like Mobile IPv6.”

• -”While the SIP v2 protocol was developed with IPv6 in mind, it never really used the potential of the new IP protocol. With SIP-six we finally solve that issue and move SIP to new areas. By simplifying the protocol and removing DNS and URIs from the design, new developers and vendors will embrace SIP and we’ll see new applications in a short while.” says Bob Plug. ”This will be the final death blow to ISDN, since it’s an easy upgrade to add the IPv6 address prefix and continue to use the same addressing.”

SIP-six is implemented as a channel driver in Asterisk 2.0, as a replacement for SIP2.0 in Kamailio 4.0 and a channel module in FreeSwitch – all releases to be released later today. Softphones for testing will shortly be available from Blink and Zoiper.

Posted: 01 Apr, 2011 | 1 Comment
Categories: Asterisk news  By: oej.  Print This Post  

The Session Initiation Protocol was developed in the 21st century. RFC 3261 is dated June 2002. In this time, network and Internet security was nothing new. Still, this is the year 2011 and most phones and servers still lack important security features. It’s not a lack of security technology and solution proposals that is the problem. It’s a lack of requirements from the market. And two paradigms that yet again meet – the netheads and the bellheads. In this article, I will try to give you an overview of the issues at hand without going to far into all the technichal details. (more…)

Posted: 06 Feb, 2011 | No Comments
Categories: Asterisk news , IETF standards & drafts , Security , sip  By: oej.  Print This Post  

Building services in Asterisk is about combining a lot of small services into larger building blocks. The Asterisk platform provides you with a large set of functions, like calling out, answering, recording, playing prompts and listening for DTMF. In combination with simple logic control statements – much like any other programming language, you can use these to build complex services. Asterisk very much follow the design principles behind the UNIX operating system – small building blocks combined with a script language may build very complex larger services.

The dial plan language gets more powerful for every release

During the years, the possibilities in the dialplan have been expanded. The language have gotten a lot of new constructs and both functions and applications.  I can admit that the language is not the best of languages, but it performs the job. Compared with Asterisk 1.0 the need for using an external language in AGI is much lower with Asterisk 1.8. Thew is one big roadblock that breaks the design – voicemail.

Asterisk Voicemail is a large monolithic roadblock

The Asterisk voicemail application does not follow this design. It has built-in menus you can not change. It has built-in assumptions on how you want to handle your voicemail that you can not change. It has built-in accounts that is not very adaptable or easy to fit in with your LDAP architecture.Many people have private versions of voicemail – either hardcoded changes to the app_voicemail.c source code or something they wrote in the dial plan. A few years ago I started my own voicemail system for a customer who just needed a small voicemail-to-email solution – mini voicemail. It was a bad name, it should have been named voicemailblocks.

VM-blocks – the tools you need to build voicemail solutions

The idea was to build a series of voicemail building blocks that anyone could use to build larger customized voicemail solutions. I still think it is a good idea. After I developed the original code, channel data stores was added to Asterisk, which should make it much more easy to build the rest of these blocks. A vm-block channel data store can keep all the data about a voicemail account in memory that can be shared by the different dial plan applications.I hope that someone in the Asterisk community agrees with these ideas and continue coding on this. The first blocks are part of Asterisk 1.8. Let’s hope we get a more complete system for 1.10. If you are interested, I am open for discussion so we can agree on the blocks we need.

Posted: 15 Jan, 2011 | No Comments
Categories: Asterisk 1.8 LTS , Asterisk news  By: oej.  Print This Post  

Asterisk was originally built as a stand-alone system, a single central point for all telephony communication. In short, a PBX. Nowadays, the Asterisk Open Source telephony server, is used in many ways – many of them not really being PBXs. All kinds of applications are being powered by Asterisk.While building applications with Asterisk, you soon realize that you’re limited to that single server. It’s hard to scale and one limiting factor is that the call state is being held in one server. Many services depend on call states – if an agent in a call center is busy, you need to find an available agent. If a trunk to the PSTN is in use, you might want to find another way out. Call states are important.Of course, the Asterisk project is now working on the long term solution, the Asterisk SCF and the applications that will be built using this framework. But that will take some time. Meanwhile, the Asterisk PBX team has been working on a few ways to distribute the call states between a group of servers. This article will describe a few of the different architectures being worked on. (more…)

Posted: 08 Jan, 2011 | No Comments
Categories: Asterisk news , OpenSER/Kamailio , sip  By: oej.  Print This Post  

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!

Posted: 24 May, 2010 | No Comments
Categories: Asterisk news , Edvina news , ipv6 , sipit  By: oej.  Print This Post  

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

Posted: 07 Mar, 2010 | No Comments
Categories: Asterisk news , Edvina news  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  

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

Posted: 13 Feb, 2010 | [3] Comments
Categories: Asterisk 1.8 LTS , Asterisk news , Security  By: oej.  Print This Post