Transcript

Kevin Fleming: OK, good morning everyone. For those of you who don’t know who I am, I’m Kevin Fleming of Digium. I have this fancy title that means that I get to manage all software development operations at Digium, which actually involves both open source and commercial software development. But today, we’re just pretty much going to talk about Asterisk, which is of course open source, and the reason we’re at this conference of open source telephony software. When I sent in the abstract for the presentation today on Stefan’s website, I used one that I’d used before. Actually, I think I used one that I used for the Asterisk talk last year, which said something about what’s new in Asterisk 1.4 and 1.6. Of course, there’s really nothing new in Asterisk 1.4, so we’re actually going to ignore that and just move directly on into 1.6 land. What’s that?

Audience Member: And beyond.

Kevin: And beyond, that’s right. Well, we don’t know what’s beyond 1.6 yet. I’m sure something will come at some point. So, first of all, how many of you have actually even tried Asterisk 1.6? A reasonable number. That’s good. It’s better than it was six months ago. We’ve been fairly busy this past year, year and a half, since we started really heavily working on Asterisk 1.6. One of the big changes that’s caused a lot of discussion in the community and everyone in the development meetings we’ve had is how we’ve changed the release process. For those of you who aren’t familiar with it, I’ll give you a very quick rundown of what’s changed.

Pre-Asterisk 1.6 timeframe, every major release had a large number of new features in it and then it never got any new features for the lifetime. For example, Asterisk 1.0, 1.2, and 1.4 don’t have new features added to them, except in very rare cases where we need to fix a security problem or something like that. So that’s good from a stability point of view.

You can go from Asterisk 1.4.10 and 1.4.24 and while there may be differences, and there are differences in those cases, there’s not a whole list of new features that you need to go try out, see how they work, and all that kind of stuff.

The downside to that is, especially the development that comes from our community, it takes a very long time to get out into users’ hands. It takes a year or 18 months from the time someone gives us something to add to Asterisk before it actually ends up in a release.

So, last year, after a lot of discussion amongst the community and internally about whether we’d be willing to support this or not, we changed this, so that every point release of Asterisk 1.6 has some amount of new features in it. It’s by no means the amount of difference you had going from 1.0 to 1.2 or 1.2 to 1.4. Those were just massive, massive changes.

We’re trying to keep it down to a few, maybe no more than two or three major new features in a point release and then some minor stuff, so that you can move from one to the next without it being such a huge burden like it was going from 1.4 to 1.6. What that means is, right now, we have four Asterisk 1.6 branches that are in some state of release.

Asterisk 1.6.0 is completely released, 1.6.1 is still a release candidate that is very, very close to being released, 1.6.2 is in beta, and 1.6.3 is what we’re working on to become the next release. We’re currently maintaining all of those. We have no plans to stop maintaining any of them at the moment. When we get to doing Asterisk 1.6.4, then we’ll have to figure out how many of these we’re going to continue to maintain. By maintaining, I mean bug fixes go into all of those.

So, if someone goes and downloads the 1.6.2 beta and finds a problem, and we determine that that bug… actually, even if we determine that that bug existed in Asterisk 1.4, it gets fixed in all of those branches and gets into the next releases of all of them.

From that respect, you can, for example, move to Asterisk 1.6.1 and stay with that through 1.6.1.25 or however far we go with that branch, and you won’t have to worry about new functionality coming along, just bug fixes and things you’re already using. So, that’s a significant change. Functionally, it means you get access to new features more quickly, which is what most people want.

If you’re building systems for customers, though it also means that you have to decide how often you want to qualify one of these new releases to put into your system and then how you want to make those new features available. So there’re two sides to that situation there.

But, so far, we’ve got pretty good response to this. So, I’m going to talk now about what are the highlights of each of these release that have been made so far for those of you who haven’t seen what’s been released that’s new over 1.4 and in each of these releases.

So, in Asterisk 1.6.0, obviously that was a major release so they had a large list of changes. Although 1.4, and I certainly do not have all of them here, we would have to take all day to go through them if I did. So, I’ve chosen some highlights here. One area that changed a lot is our TDM support. For a number of reasons, non technological reasons, Zaptel got renamed for trademark issues. So, a lot of work was done just to make sure everything got renamed and were using new names for everything.

So, that’s a change that people have to deal with going from 1.4 to 1.6. Functionally, it’s the same. File names for configuration are different, but the contents of them are identical to what they were before. So, it’s not too terrible a change. But, on the Asterisk side of the world, we had some major new pieces of functionality added in 1.6.0. The first being, of course, SS7 support. We’re using an SS7 stack that was written by one of our developers, it was actually written in his spare time while going to college and working in Digium. He found spare time to write an SS7 stack, so that’s a pretty cool thing.

That is actually in production use both on ANSI SS7 links in North America and ETSI link in the rest of the world. So we’re pretty happy about that. It is, at this moment just ISI, just trumping. It doesn’t do applications, there’s no database lookups, or any of those sorts of things available yet. But, it is actually being used in Telco links to the PSTN; and we also have a number of people using it to be direct SS7 connectivity to mobile operator networks, providing feature services off the pool networks and things like that. So, that’s a pretty nice thing to have.

The second feature there isn’t going to matter as much to this crowd because you don’t have analogue lines that you’re laundering for message waiting, so we’re not going to worry too much about that.

But, of course, the third one is big. So, we have a large project that we’ve been involved in, actually here in Germany, I don’t know how public it is. I guess Dufont can tell me about that.

Audience Member: Is it public?

Audience Member: [inaudible 06:52]

Kevin: Yeah. So there’s a large insurance agency here in Germany that’s rolling out Asterisk installations at 2600 locations. We’ve been very heavily involved in that along with Dufont’s company and some other companies here in Germany. So we’ve had a laundry list of things to go either improvement or implement. To do that. One of these things is we want to start having data to be our ICE port without having to use EuroISDN or one of the other ISDN stacks that are out there. All right, existing ISDN stacks, since it supports EuroISDN BRI was very, very close to BRI. There were not a lot of changes required. So, those changes got made and now we have native BRI support except for NT point to multi point load. That’s still being worked on. So, that means that that works, or any BRI cards that are supported through Dottie, which at the beginning when we released this was just Digium card, but that’s rapidly becoming any HSC compatible card, any HSC based card. Then we’ll move on from there, as well.

So, that provides a number of benefits, and one of those benefits is improved, believe it or not, improved faxing. Even though we all are technology people here, and we all think fax is dead, it’s unfortunately far from dead. So, we’ve had a lot of people had used systems where they’ve used an analog card with Dottie, or some Zaptel, or some other card will talk through that. A BRI card with MISDN and doing fax back and forth between us is very… I won’t say very unreliable, but it’s not the most reliable thing in the world. So this was another reason why we went down this road. So, you’ll see towards the end here, we’re actually continuing to do more work in that area as well.

In the SIP channel driver – again 1.6.0 – there were some massive changes that were made there. One was that we began to supporting SIP over TCP and over TLS for encrypted connections.

In 1.6.0, and all of the current releases, that’s marked as experimental for a couple of reasons, primarily because it was not something that got a lot of testing before 1.6.0 was released. And also because, at least based on the specifications, there is a large list of things we haven’t implemented yet. However, in spite of all of that, it really works pretty well. People are using it with SIP/TLS enabled phones. We’ve had customers who have done inter-operability testing with TLS enabled existing communications platforms like Microsoft OCS, Cisco Call Manager, via – whatever via calls that thing.

And so, that’s actually worked out pretty well and we now have a developer at Digium who’s working on fleshing out the documentation for that, teaching insurance people how to install certificates and how to deal with all of the certificate mess that you have to handle when you’re doing TLS.

So, fairly soon that’s probably going to become a not experimental feature, but it’s still not full TLS support. Of course, as you guys are probably all well aware, Asterisk doesn’t have full SIP support anyway. I’m not sure that there is any platform in the world that has full SIP support. What our goal is right now is to make sure that it works with the end points that you want it to work with and we’ll continue going on from there.

Again, in SIP land, actually one of the guys who works for Digium now, but he didn’t at the time, hired a developer in the community to add SIP session timer support. So now, if you have network connectivity problems, or end points that crash or otherwise become unavailable, Asterisk can now tell and make sure that calls are torn down properly. And many other performance and networking related improvements there.

I’m not sure. I assume Stefan is planning on these presentations being on the website somewhere. Is that correct?

Audience Member: Sorry, I didn’t hear you.

Kevin: Are you planning on these presentations being on the website?

Audience Member: Yes please, just send me the PDF afterwards.

Kevin: OK, so we’ll get it there somehow because you’ll want that. Same sort of work was done in the STU channel driver. Primarily performance improvements and a couple of other less commonly used things, there, but still very interesting for people that use these two heavily.

An area that affects people building systems around Asterisk, especially applications that were on the top of Asterisk quite heavily, is – a lot of work was done, actually by a gentleman who just came in and sat under the lights so I can barely see him.

A lot of work was done on the Asterisk manager interface to make things more consistent; there was a lot of inconsistency throughout the manager interface. Certain actions – two actions that reported the same sort of information would describe it differently; there were different header names or it was formatted differently. So, that made building applications not as easy as it could be.

So, a lot of work was done to rectify that situation, and we now have an inversion of the manager interface in Asterisk 1.6. Unfortunately, that means that your 1.4 based applications need some work to work against 1.6, but they should be much easier to maintain going on from there.

And on the application developer side, we also had people request support for Asterisk built-in speech recognition via AGI application. So, we did some work to add that too – that was not a huge job…

Audience Member: Kevin, Kevin.

Kevin: Yes sir?

Audience Member: One important feature we changed is that you can now actually over the manager interface [phone rings] not only see the version that the manager is talking to [inaudible 12:08] Asterisk is going to do.

Kevin: Correct. Yes.

Audience Member: So you can make applications that are aware of, I’m running with 1.4. I’m running with 1.6.0, 1.6.1, 1.6.2…

Kevin: Right.

Audience Member: … blah, blah, blah much, much more easily. I’ve seen the logic in FreePBX, who try to find out this…

Kevin: Yes, Correct.

Audience Member: … and it’s awful.

Kevin: Yes. And our Asterisk GUI now uses that as well; so that you can tell which version your Asterisk is connected to. And since we now have this model of adding new features that means that your external application can learn what features are available, like query in new version of Asterisk that it’s talking to, so… There was a tremendous amount of work done in the database connectivity area of Asterisk as well for 1.6.0 and some of that was continued on in 1.6.1. One of those now, is posting CDRs to databases became much easier to configure. It requires much less configuration than it did before because Asterisk can now determine the tin structure of the tables you are posting CDRs to and map columns automatically between what Asterisk calls them and what your database calls them with a simple configuration file changed.

It also means that you can post additional entries, additional columns of data in the database by just creating in the database and setting them at matching name variable in your dial and it just automatically goes, you don’t have to do any configuration or those kinds of things.

For people who use Asterisk real time with the ability to pull configuration from some other data source, there were three new data sources added. The top two being some of the most obscure things that people are starting to do, really interesting stuff with being able to pull Asterisk configuration from web surfaces or from something like Microsoft Active Directory or an open [inaudible 13:45] directory; so there’s some interesting things there. That’s in the eyes of it’s not going to be too relevant to this crowd because you don’t have analogs left to deal with.

And then we’ve also had a number of dialplan functions for… well, the first three are for basically discovering information about the Asterisk environment itself. So, you can find out what host name your running on, what version of Asterisk it is, and all kinds of other interesting things. It’s a simple function and you can directly query the states of devices and extensions from within the dialplan in addition to being able to use hints.

But, the really cool thing about it is the device state function is a let you create your own custom device state. So, you can now create a whole class of whatever you want to call it; you can store states for users, or states for external objects, or states for parking lots, or whatever you want to store in there. And then use Asterisk’s existing hint extension system to be able to map that state onto a button on a phone or to a button in a flashlight wired panel or something else that monitors extension states.

And for people who use number look up systems, like DUNDI and Ena, now that we have dial click functions available we’ve made the ability to use those much, much easier than they used to be. It used to be that if you went off and did a new number query and it returned back 10 results, you could only get the 1st one. And if you did another query you might get a different one back because it might sort differently when they come back or you might get the same one. Now it’s possible with both of those, do a query, get 10 results, look at each one in turn and decide which one you want to use or do a fail over, then the first one or the second one, whatever you want to do there.

So now you move on to Asterisk 1.6.1 – again, bunch of interesting things. The first groups there are starting down the road of being able to easily cluster Asterisk servers and share information amongst them. So, the first one is distributed message wave indication, which sound like a really cool feature and for some people it is very nice. In the past with Asterisk, if you had a cluster of Asterisk servers, let’s say sitting behind this proxy load balancer and it had phones that just register to the cluster, randomly register to a server, whichever one the load balancer shows.

If their mailbox was not hosted on that server ,then they wouldn’t get message waiting indication because that server didn’t know about the status of their mailbox. Now, it’s possible to have one or more Asterisk servers in the cluster provide all the mailboxes for the whole cluster and it doesn’t matter where the phone register is, they’ll be able to see the mailbox state from anywhere.

And then that is again being extended, or has been extended to work for device states as well. So, it’s now possible for a phone to subscribe to the status of an extension that either lives on another server or consists of multiple devices, some of which are on other servers. And have that little blinking light on the phone represent that all those devices across multiple servers.

We expect more work to come there in that area being able to natively cluster Asterisk facilities across main servers so you don’t have to do it yourself with external logic outside of Asterisk.

Some other things that have been added, again more on the analog lines side of the world; we have automatic name control [inaudible 17:11] functions available in dialplan. You can actually apply those to a channel and add thresholds you can set and do interesting things with those.

The Chance by Application got updated quiet a bit. It’s now basically fully functional for barging in on calls, whispering on calls and doing all kinds of things. Switching between loads while you’re on calls, which is especially nice for call centers. We have agency providers who were listening in on calls and occasionally want to talk to the agent or just barging in on the call completely and talk to both parties on the call.

One of our other application development interfaces, which is called ExternalIVR, got some significant improvements as well for your TCP connection stub servers – all kinds of other useful things now.

Continuing down the 1.6.11 road. Some of the work that was done in 1.6.0 to improve the performance of chan-iax2 was then also done for chan-SIP in 1.6.1. So, now it’s possible to mange much larger lists of peers with reloads not making all of chan-SIPs stop while the reload occurs like it’s used to. Which means that incoming look-ups, when invites come in are much faster than they use to be. There have been a lot of good things there.

In addition, although I’ve somehow managed to miss it here, chan-SIP has seen the beginnings of a configuration model change, where now internally inside chan-SIP, there’s no such thing as users and peers anymore. There’re just peers now. They have different attributes of whether they can call in or whether they can call out and register all those things they had before.

Again, that adaptive database work extended on 1.6.1 to now is also true for the real time directors so it’s possible to add columns to the database tables live and have Asterisk automatically use them without having to do reloads, or anything else, which is really nice.

For people who are running Asterisk in virtualized environments or actually not on Linux where you don’t have Dottie readily available. One of the problems you had in the past was that there are some portions of Asterisk that need timing sources to do music on hold playback, file playback and also other things.

That was always dependent upon having Dottie. That is no longer the case. There are now multiple timing source modules available. In Asterisk 1.6.1, there where only two – one uses Dottie and one uses a very poor old Unix layer timing method. In 1.6.2, there’s been another one added.

The useful thing there is, we can now easily add modules for timing sources available on other platforms. If someone writes one for BSD specific things on Mac OS X or OpenBSD, VirtualBox or whatever, they are very very easy to add to the system now.

It doesn’t provide conferencing. If you want to run MeetMe, you still need to have Dottie do that. For all the other things, that just requires timing that’s now available and can be done many different platform ways.

Let me move on to Asterisk 1.6.2; again, another batch of new features. One of the things actually I think Phillip asked about in our developers meeting this weekend, because he didn’t know what’s available for people who use [inaudible 20:27] are the ones who use this although there are other phones that support it as well.

We can now actually do SIP call’s Dialog state, but busy LAN feels the way it’s not much preferred to that. When the phone is told there is a call ringing on another extension, you can actually push that button and it knows how to grab that call from the other extension. That is now possible with Asterisk 1.6.2.

We started adding support for some more wideband codecs. These are two that are beginning to become popular at end-points. G722.1 has lower network bandwidth requirements than G722 and G722.1C is both lower network bandwidth requirements and higher audio end than either of those.

So, we’re starting to see the applications for even higher audio quality there. I don’t know that R2 is used in Europe at all, but we have had support for MFC/R2 part call, which is used very heavily in Central and South America and parts of Asia and a lot of Africa. Another signaling protocol that is used over E1 links, which has being missing from Masters Squared for a very long time.

And then another big chunk of work, which relates to that virtualization and other things that I was talking about before is there is now a new internal method inside Asterisk for bringing calls together and conferencing calls, conferencing channels together. It hasn’t been applied to all of Asterisk that does those things. Right now, there is one application that uses it. It’s called ConfBridge, it’s similar to MeetMe. It doesn’t have quite all the functionality of MeetMe yet. But it’s a method for testing this to see if it’s going to work well and figuring out what we need to learn.

But, the plan is for that to actually make its way throughout the rest of Asterisk. And it will have some very significant improvements in the areas of, for example, not requiring that anymore in conferencing, which will be a big thing for people who are doing virtual servers and stuff like that. But, it also means for application developers things like adding channels, moving an existing call and adding a third party to it will become trivial. It doesn’t require pulling the calls out of where they are now and sending them into a MeetMe conference and then adding a third one to it.

Any call can become a conference and then switch back to a regular call and lots of others things. So, we expect a lot of stability improvements there, especially in applications that do channel redirection and all that kind of thing.

Another thing that was added… many of these by the way, I haven’t gone through the whole list, but many of the things here were actually written by community contributors, which is still a good thing to see. We have a lot of major new pieces of functionality being contributed by community developers. And this is one of them.

It’s now possible to provide Asterisk a file that defines a list of aliases for the command line commands, which can be used for a number of different things. It can be used to localize them if you want to change them into a language other than English you can do that. If you want to just have abbreviations for things that you use all the time, that’s also possible. And also since the command line interface structure changed between 1.2 and 1.4 and 1.6, it’s now possible to make Asterisk 1.6 support all the same command lines as 1.2 did by just dropping in the appropriate file there that provides aliases for all of the them.

Again, along that same line, working towards being able to internationalize things better, all the internal documentation for dialplan applications and functions has been moved from a non-parsable, very hard to maintain just blob of text format into XML. It’s still inside the source code so Asterisk developers can still maintain it the same way. But, when Asterisk gets built, it’s all extracted out into an XML file and that’s what Asterisk uses at run time to display documentation.

Which means that it is now possible from the command line to change the language that you would like to see the application documentation presented in and have another version of that same file with the same documentation in it, but in a different language. And we’re going to continue to move in that direction so that all the internal documentation in Asterisk can be localized and you can provide your own version, a French version, whatever you want to provide there.

And then like I said on the timing source line we added another timing source there, although that one is very limit specific.

So, now we get on to now working on Asterisk 1.6.3, which has not made its way into any sort of release yet. It’s still just our development trunk, but we’re getting closer to having completed many of the things we planned on doing for that release.

One of the big things there that came from one of the commercial development projects we have done recently is that the RTP stack in Asterisk use to be imbedded inside the main Asterisks binary and there was no logical [inaudible 25:30] there. It is now moved to the AOL module for most people that will have no effect immediately, but it means that in the future if you have external media gateways or even TDM cards in your machine that can do RTP handling themselves, it will be possible for Asterisk to knock to any [inaudible 25:52] that uses RTP to have RTP directly go directly to those media gateways or directly to those cards and not to have to close your Asterisks if you don’t want it to. It can then move media back to Asterisks if that is necessary.

So, we are hoping that it is something that is going to continue down the road of being able to scale Asterisks to larger installations where you don’t have to all media going through that Asterisks server just because it is [inaudible 26:13].

Another large chunk of work, which also came from the project that we are doing for the German Insurance company is that we now have full connected party information transferred throughout Asterisk across all the channel drivers that support it. So, that includes things like, if the call is forwarded, the recipient of the call will be told who redirected the call to them via standard messaging to do that. Some SIP phones know how to display those things, for example.

It means that when a call gets connected if you call another party, when the call gets connected and their system sends what would be the equivalent to their caller ID back to you. Your phone display will now show their name and number instead of the number that you dialed. If the call gets transferred when the transfer is complete, your display will actually shown who you are talking to not who you were originally talking to that ended up transferring you – all those things that PBX’s have done for a very long time.

They’re supported over SIP and supported on chan-isdn. Some of it is supported in chan-dahdi and more of that is being sent in more now and get that up to par there. And we have some community developers that are working on supporting it for Cisco ICCB skinny phones and some of the other phones as well. We are hopeful that will end up working its way in… And works across these two as well, so connect these two servers together over these two updates will flow back and forth.

This actually works server to server using the same protocol. So, if you have three extra servers and two phones on the side of them and one phone ends up calling the other phone through all three of those Asterisk servers and it’s all over SIP, and then the recipient at the far end transfers the call to another party off of that server, that connected party update will make its way all the way back through all those servers back to the original phone. So, it’s a pretty cool feature.

Another chunk of work that was done was to improve the way Asterisks channels or managed insides the core of Asterisk itself. The data structure that was used for doing that was shall we say, not terribly efficient, served well for 50 channels or 100 channels, but getting up to 500 or 1000 or whatever it takes, it suffered greatly. That has now, has been significantly improved and that will also mean that there is far fewer cases where Asterisks will have the risk of locking problems and deadlock problems like it has in the past. And again, more performance improvements in these two channel [inaudible 28:36].

So, now we get into the even more fun stuff, which is what we are working on right now. Of course, we have people ask us all the time what’s coming in Asterisks, what’s the roadmap for Asterisk. Well, of course, we don’t know what the community developers are working on, at least not everything they are working on. But, we can certainly talk about the things the Digium developers are working on and are committed to getting done in some period of time very soon.

These are all things that are actively being worked on right now by our developers and will make their way into future Asterisks once its release is possible, 1.6.4 and 5, depending on whenever they complete it. The first one is a little, not as far long as the rest, but many of these again, are being driven by the requirements of our European customers and German Insurance Company and others because we’re trying to make sure that Asterisk can provide the same functionality that the ISDN network and ISDN-based PBXs have always provided.

So, one of those, for example, is call completion services – being able to call someone and find out that they’re busy and let the network tell you when they’re no longer busy and let’s you call them back. It actually calls them back automatically for you.

So, that’s being worked on right now. And again, we plan on supporting that on SIP and ISDN natively, and we will provide a method for using it on channel drivers that don’t have a way to do it. So, for example, for an analog phone, it will be possible for the dial-up planner to initiate this so that you can get a live PR saying, “That person was busy, would you like to be called back when they become available?” And then you push a key and it does the work behind the scenes to call you back when they become available.

Same thing will be true as part of that for what is called call completion on no reply. When you call someone and they don’t actually answer the phone and you want to be notified the next time they use their phone, so that you could call them back.

So, it’s been interesting having discussions about this, getting this implemented and reading specifications. Many people would consider these sorts of things to be massive privacy violations – to know when you’re no longer on your phone or when you just made a call and hung up, you might not want people to know that. But, it’s all configurable, so you can disable and enable it however you like.

So, we are also continuing down the road of better the ISDN support natively in chan-dahdi for a number of reasons. chan-isdn, which is based on MISDN 1.X, I won’t say it’s been abandoned, but the developers that had started working on that have now moved on to other projects. MISDN is now moving to MISDN 2, an entirely different interface. And chan-misdn has a lot of features that chan-dahdi does not. Things for supporting ISDN phones, doing these call completion things and stuff like that.

So, we have a developer right now working on moving all of that – not moving, but replicating all that functionality in chan-dahdi so that it will be possible to provide all the same features there. And then we are going to continue with more ISDN network-specific functionality being added into that area – the next thing is via some charter support. So, that’s going to show up there as well. We know we can support it on ISDN. There has been discussion about supporting it on SIP, although there don’t seem to be very many relevant specifications for doing so. So, when they show up, we’ll figure out how to do that.

And then a couple of other things. One of which is more for development and the developer side of the world. Chan-dahdi, which is one of the two largest modules in Asterisk – it’s just huge – does many, many different things. We are splitting it up into multiple pieces so that the analog signaling module will be a module, the PRI module will be one, so will SD7, so will R2.

And we’re doing that partly for code maintenance reasons, but partly because that will allow those to be reused. As an example, after this weekend talking with Carson Kale from – I guess he’s not, well, one of the MISDN developers. He wants to start working towards being able to support MISDN two in Asterisk.

MISDN two does not have an ISDN stack in it. It is a set of hardware drivers and some overload things, but it doesn’t have a whole ISDN staff like MISDN one did. So, what this will mean is, we can work on an MISDN two channel record for people who want to use that without having to replicate all of our PRI code. It will be in a module we can use to do things. For us developers, that sounds like a really cool thing. I don’t know if it’s going to affect users very much.

And the last thing is something that’s actually come up over the last, I don’t know, three months or four months. I guess, it’s even true here as well – because Bill was telling us about it. The incidence of attacks on SIM servers on the Internet has just gotten incredible over the last few months. There are very, very easy script kits anyone can just go download and start scanning servers for valid user names and passwords and start attacking sent calls and things like that. So, we’ve had a lot of people asking lately, what can we do to help them to at least become aware of these attacks.

We don’t know that we’re ever going to have Asterisk have a way internally try to stop them, because there’re plenty of tools that live outside Asterisk, which you can use to stop them or at least slow them down. But, you need Asterisk to let them know when something is happening and you might want to pay attention to.

There has been systems built in the past that will scan Asterisk log files, and that is sort of OK, but there are a lot of things that aren’t logged well enough and it’s not very real time. So, one of the things we’ve started working on – in fact we’ve worked on heavily this past weekend here at our developer meeting, and now Russel, Frank, and I have been working on it for the last few days – is building a framework inside Asterisk so that any portion of Asterisk will be able to report events in a very structured parsable way over any communication mechanism you want, manager interface, or XML, or log files, or whatever you feel like, so that you can have immediate notification when things start occurring.

So, for example, if you have SIP registrations failing for the same peer over and over and over again. The SIP channel can actually send you an event every time that happens. Then some external system can see that and say “Hey, this user normally registers once every day, and is fine, and it’s from this IP address.” And suddenly I’ve got 50 failed registrations from a completely different IP address in the last five minutes. That IP address is clearly trying to attack my system. I will go duck tape my firewall or whatever I’m going to do to stop that IP address from coming in.

So that’s our plan for right now is to make sure that all the modules, especially modules that connect to the IP network, and Asterisk can give you as much information as possible, about what’s going on, the events that they’re seeing occurring, so that external systems can react to those.

Now interestingly we have a large Internet Voice over IP service provider in Canada that we met with in Toronto a few weeks ago, that kind of started this ball rolling for us. He wants to start working on building the system that will actually monitor the events, and being able to trigger and do things based on that. So, we’re hoping as soon as we can get the documentation for this finished – and everybody knows what the event will look like. He can go start working on that, and that’s going to be done probably on our Asterisk mailing list. So, any of you who are interested, especially if you’re service provider and have to deal with this kind of stuff…

That will be our public discussion about how do we build those kinds of tools and what they should be able to do, and hopefully they will be built in a way that they won’t be platform specific. So, if you want to manipulate a firewall in Linux versus one FreeBSD, or whatever else that the same systems will be able to do that.

So, those are all things we are planning on being – I guess I could pretty much say this year. They should all be done this year, and all be in releases this year. There will probably be many, many, many more things, but those are the big things that we are working on.

And I think that is my last slide. Which is good because I haven’t eaten the lunch Corey can schedule. So, anybody have any questions they would like me to answer, or not answer, whichever you prefer. Yes sir.

Audience Member: Do want or plan to support overlap dialing in SIP?

Kevin: I believe that’s already supported.

Audience Member: It’s been supported since 1.0, but since 1.4 this applies with blanking disabled, that’s a new feature that you can disable, not many devices support it, I know grand stream supported it. Basically after it says that you need more digits for a response code.

Kevin: Yeah, you have to build your pattern in your dial frame in a particular way so that it can do that.

Audience Member: It sounds like in 1.6 wasn’t there to extend overlap dial and support in the dialplan. So you can actually dialplan. There is a function I’ll say…

Kevin: That’s correct.

Audience Member: I need more digits.

Kevin: That’s correct.

Audience Member: So it’s even more included.

Kevin: Yep.

Audience Member: So you do support it?

Kevin: Yes, on ISDN and on SIP. Yes sir. Anybody else?

Audience Member: I have a question.

Kevin: Yes.

Audience Member: I have one question where you mentioned that you’re going send the back to caller names on hold.

Kevin: Yes. For the parking party.

Audience Member: Would you add that to pickup? The command.

Kevin: Actually it already works for pickup as well. I didn’t describe that earlier. It works for pick up as well. So they are all part of it. So, if you park a call somewhere… You hear a call come in. It gets parked. Then if you go and pick that up you will actually see the caller ID of the person that got parked, not the parking extension that you dialed on your phone. That actually has been tested on, I think, five or six different brands of SIP phones. When we first started playing around with being able to do this a couple of years ago, there were six specifications for doing it, but almost no phone supported it. Now, it looks like almost all of them do. We have tested on Polycom and Asterisk, on Grandstream and Siemens and… I can’t… At least five or six different kinds, and they all support it. Of course it depends on how extensive the display is, you know.

If you have one of those brand new, open-stage phones with an enormous color screen and you get a call in that has been transferred to you and was originally redirected, you will see all of that on the display as we show each step that happened on the call. If you have got a Grandstream phone with a two-line display, well of course, you are not going to see all of that, but the information is there. So… Any other questions? Yes.

Audience Member: Do you already know which model of the [inaudible 38:57] of the charge at this point?

Kevin: The plan is to support all of them that we can support, which I believe is all three that there are – AFC SD and E. Yeah. That’s the plan. Now, the E part is the one that has been the sticking point all along because there has been confusion as to when it actually arrives in the signaling. If it arrives after the call is torn down or after the call is being torn down. So, that is going to require a little bit of research. That is one of the things that we were talking to Kirsten about this week. He has a lot of experience in that area, so we are hopeful we will be able to get some of that and figure out what is the right way to approach that.

I don’t think it would be wise of us to support a device in charge, but not support all three formats because then it is just partial implementation and that’s not good.

Audience Member: So it will be supported [inaudible 39:53].

Kevin: I suppose it could be. We are not currently doing it there, but it is certainly possible. Is it still [inaudible 40:01] the accept signal?

Audience Member: Yes.

Kevin: So, it is probably the same facility and that’s just formatted the same way then.

Audience Member: Yes.

Kevin: And that shouldn’t be a problem.

Audience Member: Yeah.

Kevin: It is not on our road map right now, but I think once all the message decoding and everything is there, then it should make it relatively easy to do. So… Yeah.

Audience Member: [inaudible 40:23] soft.com and there are different places for providing how much money is left in your accounts [inaudible 40:41] messages in the [inaudible 40:47] received message.

Kevin: Sure.

Audience Member: Is it possible to do some [inaudible 40:53]

Kevin: Well, the device’s charges [inaudible 40:58] slightly different application, but yeah. Absolutely. OK. Any other questions? Yes sir.

Audience Member: [inaudible 41:06] T.38 Relay?

Kevin: T.38 Relay. Good question. There is actually a patch and a bug track right now that three communications developers are working on to add a fax relay between TDM and T.38 using standard SP, which is what the fax modules in Asterisk use. From what I have seen the last time I looked, which was about a week and a half ago, it is progressing pretty well. It seems to be working reasonably well. So, that could very well make its way into 1.6.30. It seems to be getting pretty close to being ready. That basically means we would have all major modes of PDF and T.38 fax support. Anybody else? All right. Thank you very much.

[applause]