[Asterisk-doc] docs/volume-one vm1chp2-systemprep.xml, 1.7,
1.8 vm1chp3-compiling.xml, 1.11, 1.12
jimvanm
cvs at sohoskyway.net
Fri Oct 8 01:37:31 CDT 2004
Comments:
Update of /cvsroot/asterisk/docs/volume-one
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv10908/volume-one
Modified Files:
vm1chp2-systemprep.xml vm1chp3-compiling.xml
Log Message:
More editing.
Index: vm1chp2-systemprep.xml
===================================================================
RCS file: /cvsroot/asterisk/docs/volume-one/vm1chp2-systemprep.xml,v
retrieving revision 1.7
retrieving revision 1.8
diff -C2 -d -r1.7 -r1.8
*** vm1chp2-systemprep.xml 26 Sep 2004 05:54:46 -0000 1.7
--- vm1chp2-systemprep.xml 8 Oct 2004 06:37:25 -0000 1.8
***************
*** 4,8 ****
>Preparing Your System for Asterisk</title
><para
! >This chapter will help you to prepare you system for the installation of Asterisk. While Asterisk will work on many platforms and operating systems, we have chosen to keep things as simple as possible and stick to a single platform and Linux distribution. These instructions may work for you on a different Linux distro, but they have not been tested.</para
><sect1
><title
--- 4,8 ----
>Preparing Your System for Asterisk</title
><para
! >This chapter will help you to prepare you system for the installation of Asterisk. Asterisk will work on many platforms and operating systems, but we have chosen to keep things as simple as possible for you and stick to a single platform and Linux distribution. These instructions may work for you on a different Linux distro, but they have not been tested.</para
><sect1
><title
***************
*** 12,20 ****
>Platform and Digium Hardware</title
><para
! >While Asterisk does run on other platforms other than x86, it is not as heavily developed and tested. The x86 platform is the ideal for use in testing and production environments.</para
! ><para
! >There are two main types of USB controller chips used on motherboards. These include UHCI and OHCI type chips. The ztdummy driver uses the USB controller as a timing source for the applications which require timing, such as the MeetMe conferencing application. For the ztdummy to work, you will require the UHCI type USB controller. OHCI type chips will also work, but they require the zaprtc module which is outside the scope of this document.</para
! ><para
! >The ztdummy module is largely considered a hack and is not appropriate for production systems. Any of the Digium cards when loaded in a system are used as the preferred source for timing.</para
></sect2
><sect2
--- 12,16 ----
>Platform and Digium Hardware</title
><para
! >While Asterisk has been successfully compiled and run on platforms other than x86, it is currently only supported on that platform. To put it simply, the ideal system for a devlopment, hobby or educational system is any PC that you can install Linux on. For more intensive and demanding environments, the selection of a platform requires a thorough understanding of system architecture, load balancing, and such. That discussion is beyond the scope of this document.</para
></sect2
><sect2
***************
*** 22,30 ****
>Hardware Minimums</title
><para
! >Asterisk can be very processor-intensive, due to its use of the CPU to perform Digital Signal Prosessing. If you are building a complex, high usage system, this is extremely important to understand. However, for the purposes of building your first Asterisk PBX, you can safely use any Intel-compatible PC (x86) that's better than, say, a 300MHz Pentium with 256 megs of RAM. Essentially, if you can install and run Fedora Core 1 on it, it should be suitable for your first Asterisk install (the authors have run Asterisk on systems ranging from 700MHz Celerons to Athlon XP 2000s).</para
><para
! >Asterisk doesn't require very much space (approximately 100MB compiled) but sourcecode, voicemail, custom prompts, all require storage. You should be able to build a development system with approximately 4 GB of hard drive space.</para
><para
! >If you are building a VoIP-only system, no extra hardware is required to compile and use Asterisk. Your extensions can be VoIP using freely available softphones (such as [what do we recommend?] ). Lines can be provided through a VoIP carrier such as FWD. A VoIP-only system will allow you to evaluate Asterisk without any cost other than the computer system. However, in order to fully explore the power of Asterisk you will find yourself wanting to install some of Digium's hardware. We recommend that you consider obtaining a development kit from Digium.</para
></sect2
><sect2
--- 18,32 ----
>Hardware Minimums</title
><para
! >Asterisk can be very processor-intensive, due to its use of the CPU to perform Digital Signal Prosessing (DSP). If you are building a complex, high-usage system, this is extremely important to understand. However, for the purposes of building your first Asterisk PBX, you can safely use any Intel-compatible PC (x86) that's better than, say, a 300MHz Pentium with 256 megs of RAM. Essentially, if you can install and run Fedora Core 1 on it, it should be suitable for your first Asterisk install (the authors have run Asterisk on systems ranging from 700MHz Celerons to Athlon XP 2000s).</para
><para
! >Asterisk doesn't require very much space (approximately 100MB compiled) but sourcecode, voicemail, custom prompts, all require storage. You should be able to easily build a development system with approximately 4 GB of hard drive space.</para
><para
! >If you are building a VoIP-only system, no extra hardware is required to compile and use Asterisk. Your extensions can be VoIP using freely available softphones such as the Xten X-Lite SIP phone. Lines can be provided through a VoIP carrier such as FWD. A VoIP-only system will allow you to evaluate Asterisk without any cost other than the computer system. However, in order to fully explore the power of Asterisk you will find yourself wanting to install some of Digium's hardware. We recommend that you consider obtaining a PCI development kit from Digium.<note
! ><para
! >Many people running VoIP-only Asterisk systems require a clocking source to provide timing. The Digium cards have this capability built-in, so if you have one of those cards you've got the required clock. For systems without a clocking source, there's ztdummy. The ztdummy driver uses the USB controller as a timing source for the applications which require timing, such as the MeetMe conferencing application. There are two main types of USB controller chips used on motherboards. These include UHCI and OHCI type chips. For the ztdummy to work, you will require the UHCI-type USB controller. OHCI-type chips will also work, but they require the zaprtc module. The entire ztdummy module falls outside the scope of this document, but we wanted to mention it because the lack of a timing source may affect a VoIP-only system.</para
! ><para
! >The ztdummy module is generally considered a hack and is not really intended for production systems. Any of the Digium cards are the preferred source for timing.</para
! ></note
! ></para
></sect2
><sect2
***************
*** 41,45 ****
>IRQ Sharing Issues</title
><para
! >Many telephony cards such as the X100P can generate a large amount of interrupts; servicing them takes time. Drivers may not be able to do it on-time if another device is processing the same shared IRQ and the IRQ line cannot receive another one. It does tend to work better on SMP (APIC) systems. On single chip systems you can get interrupt misses and misaligned clocking. Any of Digium's cards or other telephony cards can be subject to this problem. Because the precise delivery of IRQs is very much necessary in telephony, one should not share IRQs with anything. This is not to say you will necessarily have IRQ sharing conflicts, but it is something to be aware of.</para
><para
>If you are dedicating the computer to Asterisk, free up as many IRQs as possible by disabling USB, serial and parallel port support in the BIOS. Essentially you want to free as many IRQs as possible. You will <emphasis
--- 43,47 ----
>IRQ Sharing Issues</title
><para
! >Many telephony cards such as the X100P can generate a large amount of interrupts; servicing them takes time. Drivers may not be able to do it on-time if another device is processing the same shared IRQ and the IRQ line cannot receive another one. It tends to work better on SMP (APIC) systems. On single chip systems you can get interrupt misses and misaligned clocking. Any of Digium's cards or other telephony cards can be subject to this problem. Because the precise delivery of IRQs is very much necessary in telephony, one should not share IRQs with anything. This is not to say you will necessarily have IRQ sharing conflicts, but it is something to be aware of.</para
><para
>If you are dedicating the computer to Asterisk, free up as many IRQs as possible by disabling USB, serial and parallel port support in the BIOS. Essentially you want to free as many IRQs as possible. You will <emphasis
***************
*** 152,160 ****
>Production/Clean vs. Experimental/Hobby System</title
><para
! >If an Asterisk system is being deployed in a production environment, careful consideration needs to be paid to the design of the system. Not only should the Asterisk server be optimized to ensure the telephony functions receive the highest priority, but in many cases the Asterisk system should not be running any other processes. If database or web server functionality is desired, careful thought should be given towards deploying those services on a secondary, supporting server, as opposed to on the same platform as Asterisk</para
><para
! >Having said that, the performance possible with modern PCs is such that you can run five (or slightly more) telephones on a hobby system with no problems, even if a full install of your favorite Linux distribution was selected.</para
><para
! >The bottom line is that Asterisk can be installed quite easily on a Linux system that has all the bells and whistles, but if you wanted to build a 30 or more station PBX, you would want to trim the operating system down to the bare essentials.</para
></sect3
><sect3
--- 154,162 ----
>Production/Clean vs. Experimental/Hobby System</title
><para
! >If an Asterisk system is being deployed in a production environment, careful consideration needs to be paid to the design of the system. Not only should the Asterisk server be optimized to ensure the telephony functions receive the highest priority, but in most cases the Asterisk system should not be running any other processes. If database or web server functionality is desired, careful thought should be given towards deploying those services on a secondary, supporting server, as opposed to on the same platform as Asterisk</para
><para
! >Having said that, the performance possible with modern PCs is such that you can run five (or likely more) telephones on a hobby system with no problems, even if a full install of your favorite Linux distribution was selected.</para
><para
! >The bottom line is that Asterisk can be installed quite easily on a Linux system that has all the bells and whistles, but if you wanted to build a 30 or more station PBX, you'd better the operating system down nothing other than what Asterisk requires.</para
></sect3
><sect3
***************
*** 170,174 ****
><listitem
><para
! >Asterisk (the PBSX)</para
></listitem
><listitem
--- 172,176 ----
><listitem
><para
! >Asterisk (the PBX)</para
></listitem
><listitem
***************
*** 186,190 ****
>Asterisk is a very performance-sensitive application. What this means is that you must carefully consider the system resources used by any other applications you are running. The most significant and unnecessary application in this regard would be the X Windowing system, popularly represented in Linux by the Gnome and KDE desktops. Not only is this not required, but it is arguably the worst thing you can run on your Linux system if you want to run Asterisk as well. Remember that Asterisk is a server application, so a desktop is not required.</para
><para
! >You can successfully run and install Asterisk alongside X, but please be aware that it is not a good idea from a performance standpoint, and you should never put a system so configured into a production environment.</para
></sect3
><sect3
--- 188,192 ----
>Asterisk is a very performance-sensitive application. What this means is that you must carefully consider the system resources used by any other applications you are running. The most significant and unnecessary application in this regard would be the X Windowing system, popularly represented in Linux by the Gnome and KDE desktops. Not only is this not required, but it is arguably the worst thing you can run on your Linux system if you want to run Asterisk as well. Remember that Asterisk is a server application, so a desktop is not required.</para
><para
! >You can successfully run and install Asterisk alongside X, but please be aware that it is not a good idea from a performance standpoint, and you should never put a system so configured into a production environment. If you want to properly learn Asterisk, you'd do well to leave X out of the equation.</para
></sect3
><sect3
***************
*** 209,213 ****
>Insert your first Fedora Core 1 disk and boot off of it. Once you see the splash screen, type <command
>linux text</command
! > to boot into the non-graphical installation. You will then be asked to test the media before installing. Feel free to test the media at this point in order to possibly save some installation problems. If you are relatively confident your media is fine, skip this step.</para
><para
>Fedora will then probe for your hardware. After this completes you will be shown the Fedora Core welcome screen. Press <emphasis
--- 211,215 ----
>Insert your first Fedora Core 1 disk and boot off of it. Once you see the splash screen, type <command
>linux text</command
! > to boot into the non-graphical installation. You will then be asked to test the media before installing. Feel free to test the media at this point in order to possibly save some installation problems. </para
><para
>Fedora will then probe for your hardware. After this completes you will be shown the Fedora Core welcome screen. Press <emphasis
***************
*** 271,275 ****
>If you would like a password on your boot loader insert it now or select <emphasis
>OK</emphasis
! > to continue. The next screen shows the boot label and the device it will boot off of. The defaults should be fine - select <emphasis
>OK</emphasis
> to continue to the next screen where you will be asked where you want the boot loader installed to. For most installations you will want the default of <emphasis
--- 273,281 ----
>If you would like a password on your boot loader insert it now or select <emphasis
>OK</emphasis
! > to continue. <note
! ><para
! >You would normally not want a boot loader password on a production system, as you would effectively prevent the system from recovering from a reboot without human intervention. On a lab system, a boot loader might be an effective way to prevent people from messing with your new toy.</para
! ></note
! >The next screen shows the boot label and the device it will boot off of. The defaults should be fine - select <emphasis
>OK</emphasis
> to continue to the next screen where you will be asked where you want the boot loader installed to. For most installations you will want the default of <emphasis
***************
*** 335,339 ****
></note
><para
! >While selecting other packages may not necessarily give you problems compiling or running Asterisk, we are sticking to our minimalistic approach by only selecting the packages we require to obtain, compile, install and configure Asterisk. The above 3 packages will allow us to accomplish this goal. Select <emphasis
>OK</emphasis
> to continue.</para
--- 341,345 ----
></note
><para
! >While selecting other packages may not necessarily give you problems compiling or running Asterisk, we are sticking to our minimalistic approach by only selecting the packages we require to obtain, compile, install and configure Asterisk. The above three packages will allow us to accomplish this goal. Select <emphasis
>OK</emphasis
> to continue.</para
Index: vm1chp3-compiling.xml
===================================================================
RCS file: /cvsroot/asterisk/docs/volume-one/vm1chp3-compiling.xml,v
retrieving revision 1.11
retrieving revision 1.12
diff -C2 -d -r1.11 -r1.12
*** vm1chp3-compiling.xml 7 Oct 2004 14:24:49 -0000 1.11
--- vm1chp3-compiling.xml 8 Oct 2004 06:37:25 -0000 1.12
***************
*** 1,293 ****
<?xml version="1.0" encoding="UTF-8"?>
! <chapter>
! <title>Compiling Asterisk</title>
!
! <sect1>
! <title>Getting Asterisk from CVS</title>
!
! <sect2>
! <title>What is CVS?</title>
!
[...1049 lines suppressed...]
! ></example
! ><para
! >With this minimal configuration set, we should be able to start Asterisk successfully. We can do this with the following command.</para
! ><example
! ><title
! >Starting Asterisk</title
! ><programlisting
! >
/usr/sbin/asterisk -cvvv
! </programlisting
! ></example
! ><para
! >Asterisk will start now and you should see a <command
! >CLI*></command
! > prompt. You will notice several errors as Asterisk starts saying it is unable to find various file names. These files are currently outside the scope of this document and will be discussed in future volumes. At this point Asterisk is not fully functional, but we do know that it will start successfully. All that remains is the configuration of the system.</para
! ></sect2
! ></sect1
! ></chapter
! >
\ No newline at end of file
More information about the Asterisk-Doc
mailing list