 two up here. But while we're trying to sort that out, I can introduce you to Mark Spencer, the creator of Asterisk and owner of Digzium. I think I've heard of Digzium. My name is Ulle Johansson and I'm one of the developers in Asterisk, specializing in SID, but also one of those that get a living out of training people in Asterisk. And I have five days of slides on my laptop and we only have one hour. So I'm going to raise the board rate quite a lot here and work fast. But Mark and I are going to do this together. We haven't got a plan, so we jump in the middle of a presentation and we'll take a bit of that and then see where it takes us listening to your questions, either answering verbatim or finding another set of slides and go from there. So it's going to be very, very interactive. We're going to have two-way communication at least, if not to say a conference breach in the room. How many here listened to that last presentation by Mark about Asterisk? Okay, so I can safely assume that you know Asterisk. How many here knows a program in Linux called Make? Great. So you all heard how wonderful Asterisk is, what you can do with it. You can get your Linux PC to talk, answer your phone calls, do exciting things, great scripts that integrate with SNMP or your MySQL database, check whether or not your kid is home by using Bluetooth presence like Mark does, monitoring your girl's calls. I'm soon about to start doing that. My daughter is 12 and people are starting to call her all the time, so I really need Asterisk. You need Asterisk, so let's check what you need to consider before installation, before you hit Make. When you size your actual server, there's a number of functions you have to consider. You can run Asterisk on extremely small systems. I have a slide somewhere else on this laptop, the smallest one I've seen. It's a Gamstix computer, smaller than a Red Bull can. Not powered by the Red Bull though, even though the programmer was, but it actually hosted Asterisk being able to take multiple calls. You can install Asterisk on Linux's routers, wireless routers, the ones that run Linux, and be able to handle a few calls on that machine. If you're setting up a service provider, you need to have bigger machines, and what you need to think about is, I would say the primary factor is the number of simultaneous calls you want your Asterisk server to make to process. You can easily install Asterisk for home use on a Pentium 500 MHz. You can handle the amount of calls you can handle in a normal family, unless you have 20 kids or more. But the number of simultaneous calls is really important. Remember now that Asterisk is a PBX. We can handle strange PSDN calls coming in, at the same time 3-to-3 VoIP calls, and SIC calls, and X calls. Each one having different properties in regards of codec and bandwidth used in poor quality. In order to take in a call with one set of coding standards for audio, and shift audio out with another set of codec, we have to do something called transcoding. If you're setting up Asterisk to do that in a larger scenario, your CPU will be really hot. Transcoding, in addition to the number of simultaneous calls, eats your CPU. If you have a highly compressed G7 codec call or speech coming in, and you want to send out a plain PSDN call or an ISTN card, your PC will have to transcode the audio. The third factor you have to consider is whether or not you want to run conference bridges. We have an excellent little application called MeetMe. We can take simultaneous, a high number of calls, connect them together so they can speak. You can set up sessions with one teacher that speaks to the students, but doesn't have to listen to all the crappy comments and questions. So we can have one-way conferences, we can have two-way conferences, we can have wait-for-leader and many other things. But mixing all those audio channels also takes a lot of processing power and we need to consider that. Some things you don't want to do on your PBX. This is really important because running audio is really real time. If you publish video screens on your server or web pages, that's not really real time. We can send it with best effort, but if we suddenly start dropping packets in a telephone call, we're actually storing it for a while. We're going to store this audio packet coming in here for a while and then ship it out later. People won't like it. So after it really needs control over your CPU, especially if you use hardware interfaces to connect your PSDN, then it becomes very, very critical that we have the interrupts we need. So on your PBX, do not install X-Windows. Especially if you're using KDE Ignome, which has a lot of processes, it's a lot of power, that will affect the quality of the call. You can do this. I'm running Asterisk on my laptop over here and I have one simultaneous call. You know, I'm a male. I can't do multiplexing and other things at the same time. So one simultaneous call is enough for me. But if you're setting up a production server, don't use X-Windows. If you see a happy penguin or chameleon or any other animal when you fire up your Linux, then your Linux is installed with something called frame buffers. It will also affect calls because it needs interrupts and other things. Also, for a lot of reasons, check your BIOS and your Linux installation, your Linux kernel if you're setting up a real production server. Disable everything you do not use. If there's no use of a USB, disable it. Zero ports, print reports, remove it. Everything that can cause interrupts. Both for removing interrupts but also for security reasons. Asterisk relies on a lot of different libraries in order to compile. Some of them are required. Some of them will add features to your Asterisk installation. Bison used to be required but it's not in the latest release. So this slide needs to be updated. We now have pre-processed all the parser files for you. So it's ready for compilation. We do need open SSL in the current release for each encryption and some other features. Termcap, anchorsestable, and setlib is also... Sorry? Yeah, I said in the release version. In the trying, we'll have a lot of new exciting features for you coming up in the development version of Asterisk where we remove some of these bindings. But that's future stuff. Optional modules. Asterisk will recognize whether or not you have these installed at compilation time. We're not supporting today out of configuration with configuration like many other software do but we do recognize and check for certain installations in the make file. mpeg123 is something we can optionally use for music on hold. We have many other ways of running music on hold today. Libnude is required for some third party applications, mainly if you buy Digium hardware and want to test connectivity and see accuracy and other things. Voice mail by email seems to be a very sexy feature. When I install Asterisk in a new customer site and I enable Voice Mail and they get all your files in the email, it's like, wow! I've got to show the box. Oh, the manager. My wife. Someone. It's really cool. And in order to send mail, we need something that sends mail. Send mail or postfix or any mailer of your preference. If you have Libco installed, we will add additional applications for you. And there's a number of other third party applications that we recognize. Some databases will add database supports to Asterisk, like MySQL. And there are other things as well. There are many different kinds of linuxes out there. Some distributions call themselves enterprise or professional or carrier and some are more personal. One big difference in regards to Asterisk is the number of file descriptors we have available for Asterisk. You have to remember that a file descriptor is used for socket communication as well. It's not only for reading files in your hard disk drive. And for instance, if you're happy enough, go to sleep, to your sick, the wonderful protocol, we're going to have five ports open per call. So we need five file descriptors per call. And if you have 100 calls, you need 500 file descriptors. And for that, Asterisk uses internally file descriptors for logging, reading stuff, doing stuff during the call. So you need to change the number of available file descriptors. We used to have Asterisk previously in CVS. For the latest version, version 1.2, we moved to subversion as our primary tool for maintaining source code for developers. In the subversion repository, we have something that is really working tools. If you download from subversion, there's no guarantee that you will get any audio or video through your Linux system. There's no guarantee of anything else and will fill your hard disk with a lot of code and sound files and other crazy stuff that may or may not compile or do something fun for you. But we have a release version. This version is available from RSVP servers. It's in a tarball. You download the tarball, unpack it, and compile it as normal. If you want to label the bleeding edge, we do invite you to download from subversion. You'll find instructions on Asterisk.org. We have a lot of new pieces going on for the next release, version 1.4. And we do want people to test it. This is our release structure, really. I've made the old slide now because we have released 1.2. In the old days, more than a year ago, one and a half year ago, we only had one branch of CVS. And when people asked what version can I install on my production server, he would get the answers like, you know, February 22 was a good version, but there were a couple cool features added in March 5. But they were broken in March 10. So probably March 6 and March 7 could be a good choice. Well, you couldn't live like that. So, Mallacare released at their first Asterisk conference, Asterikon, Asterisk 1.0. And that was subsequently passed. So we've got 1.0.1.1.0.2.1.0.3. Last year, in November, we released Asterisk 1.2. And we're now up to version 1.2.4 for Asterisk, release version, which is the version we recommend you use for production. The release cycle today is a bit more, I would say, well planned. And hopefully we'll be able to succeed with that. You have to remember that we just learned how to maintain two versions of the source code. So we successfully have policies and procedures in place to maintain a release version where we're not adding features. And we have a hero that maintains the release version called Russell Bryant, a student that really, really takes care of this. Imagine other programmers play around, create sexy tools, become heroes, do cool stuff. And he's sitting there saying, nope, nope, nope. Oh yes, that's a bug fix. I'll implement that. Nope, nope, nope. And he loves it. That's a hero to me. And we tried to release him for that after 1.2 saying, OK, you've done this now. Please. But he wanted to stay. So we need all kinds of people in an open source project. Maintainers of stable releases, testers and developers, they all need to work together. But what we're doing now is actually implementing a release cycle where we say that we will release a new release version every six months. And in the plan, we have a set date for major architecture changes, set date for code freeze and beta testing, release candidate testing. So hopefully, you'll see Asterisk 1.4 during the summer sometime. But you never know, it's the first time. So, tonight, you go home and you realize that, well, it's only sports and boring stuff on TV. Fire up your Linux system, make sure it connects to the internet, download Asterisk, untar the tar file and you know this. Run make, make install. Next step is make samples, and we will remind you of that. Make samples will install a sample configuration. It's not a simple configuration. There's a lot of options in those files. But it's a reference installation where you can connect your phone and place a few calls. You'll actually be surprised because when you call extension Sousa, without Sousa when you connect your phone, you'll get a menu. You'll get Allison talking to you. And one of the options is placing a test call to Digium offices in Hansel, Alabama. And it's quite funny listening to people who call in there and say, hey, someone is speaking and like, hello, hello, hey, hear me? Oh, it's a true person. Hello. And it keeps happening because after installation, they just work and they connect over internet and place a real phone call to USA. Let's ask it. So, let's go into a bit more details. Directories. The main configuration file of Asterisk is called asterisk.com. It's by default on Linux installed in et cetera Asterisk. And this is read at boot time for Asterisk to find out where we have all the optional files to need. Where do we have separate modules to load? Where do we have the collection of sound files that is attached to the distribution? All those cool Allison prompts in American English. And yes, there are distributions of other languages out there. I read the other day in the mailing list that someone made French files now as well. Some of them are professionally recorded files like Allison files. Some of them is the wife with a bad microphone in the kitchen with the kids in the background. And you don't want to use those in a professional environment. But there are still some files, some from the various languages. And of course, you're here at false stamp, so you're Linux professionals. You know what a background demon is. Asterisk executes as a demon. Some people are very surprised by that because they enter Asterisk in the command line and nothing happens to get a new problem played. Boop, what happened? Hello, where did Asterisk go? But that's perfectly all right. We execute in the background. To connect to your background demon, you run asterisk dash R, or actually R asterisk if you want to do it another way. If you do that, it'll be exciting times for you. It'll be really, really cool times because you'll see our professional graphical user interface, the command line. No point in click here. Traditional, true, spirit, command line. Enter takes enter. Command completion, history, everything you need. Really cool. In the command line interface, you can get looking on what happens when people place calls. You can show what's going on in your Asterisk, what calls you have, various configuration options, change some internal settings. However, when Asterisk starts in the background, things may happen that prevents Asterisk from starting. So you start the Asterisk, you get the limits prompt back. You start your phone and the phone says, no server. Hello, what do you want me to do? It's bad. And you don't know what happened. You need to force Asterisk to stay in the foreground and tell you what's going on. And you do that by starting with Asterisk dash C. If you add a couple of Ds for verbosity and a couple of Ds for debug, you'll get a lot of information that will make you happy because you're the exact hackers. You'll get debug messages saying you crazy stuff like, that hurt it or things like that. But you will actually be able to find out what module that didn't load and probably why it didn't load on your machine. And try to fix that and start again. So we have in the true Linux, I would say, religion, many different options. Where load case and uppercase is a difference. We actually have a man page now where you can read about all the various kinds of options. If you want to run Asterisk in a sandbox with different username and group, you can do that. A very important option is dash X. If you run Asterisk dash or X and then a C like man, Asterisk will execute that C like man in a console and then exit. So if you want to create a web interface that updates the list of zip phones that are attached or shows the channels or you want to do something else from a web script on your web server, you can do that. But Asterisk dash dash or X is a very handy way of connecting from other applications to Asterisk and checking what's going on and changing some properties. Like MySQL, we have a script in the distribution called Save Asterisk. They have saved MySQL. The Asterisk sets some options and checks the running daemon. If something happens, the script may optionally mail you a saying, you may restart it, but it will restart after if something happens. If you run in the development version, you can be assured that something will happen and it will make you happy to help us debugging the error and finding and fixing the bug. So Save Asterisk is a good script to use on a production server. We also do our best to support that this manufacturer is by adding a lot of logging. We can log to syslog, but we can also log to ordinary text files on your hard disk drive to do everything we can to fill it. You can log various kinds of messages and as we develop Asterisk, we actually, for each message we print, we sort it up in a category so you can choose what you want to see and where you want to have logging. If you want logging to go to the console or these kinds of messages to go to syslog. In a production server, in a Linux Unix installation, you might want the errors to go to syslog because that's how you handle errors in all your Linux Unix systems, but warnings, notices, debug messages, you might take a file. If the server is up and running and it works fine, you might want to remove the debug messages. We also added DKMF logging. If you're creating ID or scripts and you want to shake your customers and maybe save logs of what they enter, you can do that now easily. So you have Asterisk running on your server and you change the configuration files. In some cases, you can simply tell Asterisk to reload. That means re-read all configuration files. They'll happily ever after, but stay alive. However, for some of the configurations, we can't let you do that because if we have active objects like SIP phones that are active with us, we won't reconfigure them on the fly. And some hardware interfaces doesn't really let us do that on the fly. Re-configure the hardware bindings. So you need to restart. I wouldn't say well documented, but we're trying to document this in each configuration file and try to help you in order to decide whether or not you want to reload or restart. You have to remember that the restart actually drops all active calls. You can't tell Asterisk to wait until we have no calls or actually stop accepting new calls but wait until the current calls hang up then restart in order not to affect the calls. But if you're playing a dangerous game, you can force Asterisk to restart now and then after you just drop all the calls, restart and make you happy but your users will be... Well, thanks God for GSM. They're probably used to calls being dropped and things happening. I don't know if they will react. Depends on the module, really. We have so many different modules, but for instance in SID, if a peer is ranged with us, we will not reconfigure the peer. No, not of the peer. Not of the peer. Users will reconfigure, but not active peers. We might change that. For some of the modules, we have special reload commands. Let's say you've reconfigured parts of the SID channel but you don't really want to change the rest or affect those modules. Then you can reload the SID modules. If you change the dial plan, you can run an extensions reload which is a very clever command because a dial plan can be very huge and big and require a lot of parsing. And you don't want that parsing to affect your current function of the PBX to actually do all the parsing without changing the run of PBX. And when we're done and we have a complete in-memory dial plan, we quickly shift them in memory and release old one without affecting the calls. The extensions reload is a good command to remember. And as Mark said earlier on, we actually, in our beautiful, wonderful Linux Hacker-adapted graphical user interface, we have a lot of documentation. We have show applications and show application application. We have show function now in one, two. We have a new construct called functions that help you build a dial plan. Of course, we have help but we also have documentation for all the AGI commands and all the manager commands. Any questions on that part? This was running in a high-board way. Show function, function name will show you a bit more but there's no document. We have a lot of information made by the community on the VoIP for Vicky. There's also an O'Reilly book with the name Afteris the Future Telephony. But the beautiful part with that is that it's written by members of the communities. Over there, raise it. It's published online under the Creative Commons license. You can download it all as PDF from afterisdocs.org. Okay, let's move on to some of the core parts and take a brief look at Afteris configuration. Is that okay with you? It seems like I successfully killed them with PowerPoints. I had no questions. Please, you can question at any time, no problem. Afteris, like Mark said, is very much like that patch show telephony. We have many, many different modules and there are many, many ways to use apples. In carrier environments for telcos, we use Afteris one way. In the home for monitoring your kids, we use Afteris one way. In PBX environments, in enterprise environments where they order to have a PBX and we add Afteris to add functionality. We might want SIP, we might want voicemail, meet me, we use Afteris one way. So we have many, many modules, channels, functions that you want to configure. But don't be afraid because when you start using Afteris, you won't have to touch all those files. They're just there to scare you. So let's look at configuration files and try to divide them into several groups. As Mark said earlier, the PBX core is the module that really runs Afteris. It has all data plan execution, very sensitive threading and processing of audio and all that. Here we have of course the main configuration file, Afteris Conf but another important file if you want to install Afteris can gum sticks or very, very tiny servers because in this part of the industry, it's really, really sexy to run a small system. You hear grown man looking at something or thing. Look, he's smaller than mine. That's weird. Modules.conf is where you tell Afteris what to load and not to load. If you're for some really, really peculiar, strange reasons not want to run SIP, you can tell Afteris to don't bother with loading channels SIP. I won't talk to you forever more, but you can do that. But there are modules you might want to skip. If you don't want conferencing, unload a module if you have memory constraints or security constraints. The modules that handle this boost up an incoming call or an outcome call is called a channel. For each technology we implement in Afteris we create a new channel driver. So we have SIP, we have SAP for all the PSDN technology, MGCP, X2, 323 and soon Jingle. Those are channels. And for each protocol we have new signaling, we have new ways of defining the devices, the lines, the channels, the endpoints, whatever they call them. For each channel driver we need a configuration file. And those configure the basic stuff if it's a void protocol, IP address, port number, some default settings, and then the various channels or devices we connect to the channel. We have applications and functions. Some of them are embedded in other ports, other modules, but a lot of them are actually their own modules that you load or unload as you wish. Smaller ones have no configuration, but the conference bridge, voicemail especially, and a few other ones have their own configuration files. For voicemail you set up the language you want to use, the email template you want to use, time zones for various accounts, and then the voicemail boxes. So that's an important configuration file if you want after it's your own voicemail. Codex. I'm very lucky that Jean-Marc is in another session here because I frequently say that codex is kind of standardized in a way so you don't need to configure it, and they're very strange modules. Marc is half asleep so he won't object here. But the speech protocol is the only one that is so complicated so we need a configuration file. And I'll discuss that with the speech guide later on. But we have a configuration file, and I asked him yesterday to help me understand that file so I can teach people about it because I don't understand it right now. Codex. Okay, let's see. I have a slide or whatever. If you wait, Marc remembers everything. I need slide words. If you have the speech library installed, we will handle those passed through, but we can't really handle them internally now. Without the slide, I didn't find it. Bad access tips. Okay. Codex are used in the voice channel to handle real-time conversion of an analog audio sound to sound digital media stream. But format drivers are modules that actually take incoming multimedia and save it to file on your audio drive in order to help that industry because some of the files can be pretty large if you monitor calls, for instance, especially if you monitor the calls of teenage daughters that will fill your audio drive. This is also used to read prompts like all the other some prompts that we include and play them out. What you want to do is have the files in a format that is very close to the codec used. Otherwise, asterisks needs to translate all those files as we play them. And you can say the same problem in multiple formats if you run multiple codecs in your asterisks. But there's no configuration file. We have two sets of modules that are called PBX or resource modules that implement a lot of the core features in asterisks and extend asterisks in various ways that are not really channel related or dial plan related, but extend channels, PBX core, or dial plan applications. AGI, of course, is one of those and core parking, core transfer and the whole configuration engine are all implemented as resource modules. And some of these have their own configuration files. Information wants to be free, Mark said, but there are people who believe that information wants to be billed. There are people who have a telecom history where they want to charge for usage instead of availability. And, luckily enough, we have to support that, but you also might want to log each call for traceability in order to see what happens in your PBX. Run statistics, for instance, with the web interface created by Reske here. He made an open source interface to the CDR records. We have various modules to satisfy these crazy people. We can, of course, by defaulting all the call data records as CSV comma separated text files, which should be the worldwide standard. It's easy to handle with standardized and every unit's application can handle it. However, people want to store it in crazy databases, so we support a wide range of databases as well as ODBC. So there are many different drivers to store information about each call as it either fails or is hung up. And each of those have their own configuration file, and we also have a generic configuration file for the CDR subsystem now in order to set some generic information like time zone data and other things. These configuration files mainly handle settings for logging into various database systems, porting out database and table names and such. All configuration files are usually installed in setter afterings. If you're lucky enough to run free BSD, we will now install them from version one to four, the next version, in user local, etc. They should be. There's an additional open source project started by Mark and Jim Dixon called SAPTEL, which is a separate project. So if you install SAPTEL drivers, which are the drivers for hardware interfaces sold by Digium, you need to check also the et cetera SAPTEL com configuration file. Remember that this is a separate open source project, so the configuration file is not within the afterings directory. It's in the et cetera. Well, I have to warn you that this is an open source project. Anything can happen. We're getting better and better in handling things common way. We're implementing now parsers for handling application calls, trying to go for the same syntax in various parts of afterings. But for configuration files, they actually have two different kinds of syntaxes. I don't know how many of you have been around since Windows 3.11. Some of you. Remember the wonderful times of Win I9 and System I9. Those files look very much like Aster's configuration file. You have a section named square brackets. You have label equals value, label equals value. Fine. Simple. You can handle that. But in two of the configuration files, we actually have a sexy object-oriented style with inheritance. I think we can do a lot of marketing bullshit around that. Where you actually set a few properties, then declare an object. Continue. But the next object you declare will inherit properties from the first one. So you need to make sure when you read these files that you read them from top then down to the bottom in order to see how you complete your things. Or you have to repeat all the configuration settings for each object. We can include configuration files from other files into one. So you can separate a big dial plan and take out the incoming lines or the outline lines and separate files and have Asteris merged them for you. In one, two, we can also handle templates. So you can repeat information. If you have a number of grantee phones and a number of sister phones, you can have the settings for grantee phones and sister phones in a template and then you have to apply the template to each phone in your computer. And I won't talk about billing. That's boring. We have a few minutes for questions. 42 is a good number. I will request it. The question was is there a limit of number of SIP users that can register with Asteris? Well, yes and well no. It depends on the system. On the gamma states, yes there is. I don't know that we have any coding limit. The limits we have in Asteris would be the number of messages you have in a mailbox and some other things. However, depending on your system there might be a limit. There are people who use databases to store all the various phones to have and they have like 10,000 accounts and ask phones to register to read from the database, to process the registration, save it in the database and by doing that we can actually handle quite a large number of phones and the limiting factor would be the number of simultaneous calls not really registration unless you have a real poor database because that will affect us. Yes, can I understand the question you are talking about LDAP? The question was can we store in LDAP? Yes, soon. We have an internal architecture called the Asteris real-time architecture because in Asteris 1.0 in the SIP channel we have support from MySQL for storing objects. In voicemail we have Postgres and we have various kind of patches everywhere flying around. Looking at that and all those patches for MySQL, DiorSQL, PostSQL, PreSQL I looked into the source code and said I will never be able to maintain the SIP channel because I don't want to learn all these interfaces. And the other program said the same so we created an internal architecture where we have storage drivers we are not calling them database drivers, they are storage drivers and in the bug tracker there is a patch for a real-time LDAP driver that will make it possible for you to store all objects voicemail accounts, call queue accounts, SIP accounts everything in LDAP Please test that, I need your input I really need it Yes Please check that and see if it works together with CERV, LDAP It's highly configurable but I haven't been able to test it but the whole idea with real-time was not to be a database abstraction layer but a storage abstraction layer so we could support LDAP and other things Stealing ideas is a good thing Ok, more questions Are there any plans to support encrypted connections? Well, as Mark said our roadmap really depends on developers and users that pay developers to do things We have encryption in the X2 protocol and don't quote me for saying this because I'm the SIP programmer here In the X2 protocol we have RSA authentication a very very strong authentication method used between after service for setting up tracks and this is a very important feature From version 1 to after we also have encryption for X protocol The SIP protocol however in order to have encryption needs TLS set up and we haven't got TCP or a UDP only In order to get TCP working we really need to rewrite some of the basic socket abstractions and some of the signaling because a lot of things doesn't apply on a TCP transmission layer so hopefully we can have that by the end of the year There is a strange patch in the bug tracker for encrypted audio SRTP however the key change is made in the full open in the SIP protocol and it works with SNOME phones and some other phones It's a good start We have a patch with TCP support in the bug tracker It's a lot of stuff in the bug tracker however that patch really doesn't scale and do everything right so it's very very very basic Yes we can open a TCP socket and listen to incoming connections There's a lot of things we do wrong Basic rating to face card support I would have to start answering that because he's an American For Euro, yes You can buy extremely cheap HFC based cards I bought them for Kronos which translates to something like 35 euros Yeah okay So there she for one line There's also manufacturers that have four line cards Bearnet and Jumhansnet You just got the Bearnet one for testing I haven't tested those and there are octo cards for BRI We have a new channel in Asterisk called CHAN MISDN I would say successor to ISM for Linux MISDN and a lot of cards support MISDN today We also have a patch which is not included in Asterisk distribution but made by Kauke to Jumhans called BRI stuff that adds to the SAP channel support for HFC based cards and I've been using these in production in many places I actually have one PC with four cards running It requires special motherboard in order to handle all those interrupts but it's been up and running for a year without the problem Who are MISDN which is included in Asterisk today In Europe I'm living in Stockholm, Sweden so I'm in Europe I hope Even though we haven't got the euros A cool feature with those drivers is that we support Asterisk as well So if you have an ISM PBX or an ISM phone you can connect it to Asterisk as a phone and you can connect to Asterisk as a PC That's what I do at Asterisk and I take in 8 phone numbers 8 MSNs on one single VR app It's cool There's an old channel called CHAN copy as well if you want to run copy The cool thing with that I think Fridts of M cards are drives for that is that on the same server I'm taking faxes on some MSN and Asterisk taking the rest I don't know if it's maintained anymore It is Okay, cool The things of the patience you have for compilation One of that my fellow Asterisk programmers installed one of my patches for testing on a pencil 133 I said, oh I'm downloading now and after a while I said okay did it work Okay, I'm still compiling and you compile for an hour or two but you can dial from the command line and place calls over the sound card You had a question? You configure after it and if they're on the same bus to the MT you configure after it to only answer some MSNs and this will go with the rest of the calls So that's how I did it with Hilafax and other things and I still have the MTBX numbers I know that that worked with Cenk copy I believe it works with clear eyes I wouldn't be surprised if it didn't work I've come to hear you on OpenBSD That's a good question I haven't run on OpenBSD but on FreeBSD I've actually, most of my apps are developed on FreeBSD The only thing that doesn't work is the subtle drivers because they're kernel level drivers However, there is a project that created subtle drivers for FreeBSD so we can get the time we need for some applications but I run production service on FreeBSD with VoIP only and it works brilliant In the source code we actually support NetBSD, FreeBSD, OpenBSD and OS 10 Let's discuss that offline or report bugs within bug tracker 729 for FreeBSD I believe it's available We have 729 for FreeBSD OS 10 and Linux I think they're $10 a channel or, yeah and that's a license fee to the patent over digium.com have a mail order shop for you We have a cool interface called after-it's manager interface There's AMI already today which is a TCP IP interface and then there's also SNMP in the bug tracker and then after-it's the current plan is actually to use something we call the manager proxy The manager proxy will be able to implement all of those features XML, parsing and other things because currently we have chosen not to implement XML within the core PBX because XML parsing can be tedious and it can be a reason to download another service attack but the manager proxy will try to implement various kinds of CTI interfaces that exist in the industry as well as being the layer you use for SOAP and so on There are Java interfaces, SOAP interfaces a lot of different interfaces There are many, many projects surrounding our main core project If you go to the VoIP info wiki and search for them you might find something but currently we have a kind of raw and unstructured manager interface and we'll probably keep working on the raw and unstructured interface and structure it a bit more so you can easily use the manager proxy to translate that into various XML calls and support SOAP XML RPC or whatever flavor you want Sorry? There's not official support built in for a speechwreck engine yet but we're working on doing it You can use festival already and there is res-captural and it's going to be available soon It's sort of unofficially available right now but you'll officially be able to get it but res-captural is obviously based on the text-to-speech which is a proprietary package so your options are barely limited in the pure open-source sense just because there's not a lot of really good text-to-speech festivals about as good as it gets and it's very super-intensive and not especially scalable as it seems to on the speechwreck side that's but we haven't seen real official integration with it Don't know, that question has been raised but there's also voice XML which might be a more logical route to go initially but it's also to be side-stalled What we have in Astro is one, two Bad sound, we need to speak to that is an interface called external IVR which can be used to connect to your application over a unit's pipe and your application will control the whole IVR prompts and everything so you can produce prompts in real-time store it available for Astro and tell Astro to play it that's been used to create kind of live options on the phone where you can't really script it because you don't know what's happening and when so you need to control it from an external application so that's a very good use interface to create your own integration to various kind of engines, voice XML and other things, I've seen people use that for voice XML and we have a few patches that we included in the SIP channel in order to send the URLs you need for that kind of stuff Astro is already the killer yes, okay how do we keep track of the use of location what's that, features okay, if you want call forwarding or follow me there's all stuff you create yourself in the dial plan or from the phone but it's so different in various parts of the world on how you want to do it in various companies but because the dial plan is highly scriptable you create do not disturb follow me call forwarding functions on some phones, voice phones especially SIP phones, the phone wants to be king often there for call forwarding and enable that in the phone by doing that Astro is to place the call first to the phone and get a forwarding instruction from the phone and follow that to the next point SIP can be done in many ways sorry can you activate the call forwarding from the phone yes, that's one of the labs we have in Astro is training classes I'm holding but it's normally done if you want to do it in one protocol Astro is where you do it in the dial plan by adding an extension since we then I would add star 21, star phone number hash and take that as a call forwarding instruction but in other parts of the world you might have other vertical service code for implementing that but it all depends on the phone and how you want to do it in your environment again, the redundancy aspect yes, if you want redundancy you want Astro is to be in control in a way so you can reach it from many different servers instead of doing it on the phone ok, we have to close it up we'll be around for questions on the floor here thank you very much