Well the Asterisk and DAHDI projects are separate (although they do fall under the same maintainer of Digium generally). DAHDI can be installed independently of Asterisk, and vice-versa, but certain features of Asterisk require a timing source. The source can either be res_timing_pthread (awful), res_timing_timerfd (only available in kernels newer than 2.6.23 or something, so not available on CentOS 5.x, and not as robust as DAHDI timing), or res_timing_dahdi, which of course requires that DAHDI be loaded. (Also of note, in newer versions of DAHDI you don't need to load dahdi dummy separately. Just loading DAHDI itself is enough without modules as the dummy timing has been put into the core, so it's not an external module anymore.)
If you don't have DAHDI installed prior to installing Asterisk (or rather, you don't have Asterisk compiled against DAHDI), then the features that require timing either need to use something other than res_timing_dahdi, or they won't be compiled at all. I believe chan_dahdi only compiles if Asterisk is compiled against DAHDI. Leif. On Thu, Mar 8, 2012 at 12:30 PM, Bruce N <[email protected]> wrote: > Much appreciated Lief. This is amazing detailed info. I will have to find > the time to go over this process thoroughly. > > I thought that the RPM install of Asterisk installs and loads DUMMY DAHDI by > default. But I guess, as you say, the install might happen but it doesn't > mean it load and function well?! > > Best, > Bruce > > > > On Fri, Feb 17, 2012 at 1:13 PM, Leif Madsen <[email protected]> wrote: >> >> On Thu, Feb 9, 2012 at 9:57 AM, Bruce N <[email protected]> wrote: >> > I noticed that RPM packages of Asterisk downloaded from Digium >> > repository >> > installs DAHDI on a VPS just fine without the need to tamper the mother >> > node (install DAHDI on mother node first). However, when installing >> > Asterisk from source one has to install DAHDI drivers on the mother node >> > first to make it available to the VPS. That is something I would like to >> > avoid. So, I want to build my own custom Asterisk RPM package but it's >> > the >> > first time for me and need some guidance from those who are familiar >> > with >> > RPM package development. Digium repositories also do not include all >> > Asterisk features and add-ons (e.g. OOH323, etc...) hence I want to >> > build >> > my own. >> >> That's because some modules are build as submodules of the primary >> package. Look on >> http://packages.asterisk.org/centos/5/asterisk-1.8/x86_64/RPMS/ (for >> example) and you'll see the submodules that gives you the other >> modules, such as ooh323 that you mention. >> >> > My first question is if the building process requires me to install >> > Asterisk on a physical server with all features and then build the RPM? >> > If >> > so, how does that package work on different type of hardware? I also >> > don't >> > understand why a compiled version is able to get DAHDI running on a VPS >> > while same is not possible from a source install. >> >> You have to build for the hardware architecture that you're installing >> on. x86_64 can load both i386 and x86_64 build (both in terms of >> installation and of building). A 32-bit OS can only build 32-bit RPMs. >> Sometimes you can crosscompile and build, but if you're using >> something like mock, you do need the appropriate hardware to build on. >> >> I don't understand what you mean by install DAHDI on a VPS in regards >> to "compiled" or "source". An RPM is pre-compiled software, but the >> ability of the system to load or allow the loading of kernel modules >> is not circumvented by building an RPM. >> >> > My second question is if you know of any simple guides that can run me >> > through RPM building process on a RedHat (CentOS specifically) platform. >> > I >> > am hoping this doesn't require me to write a lengthy install script. >> >> The install script is the .spec file, which is provided inside an >> .src.rpm which you can use to build the .src.rpm. Then you use the >> .src.rpm to build the installable .rpm. This is usually done via >> rpmbuild application. If you use mock, which I mentioned earlier, then >> the usage of mock deals with much of the build environment creation >> and the packaging for you. The "old way" is to install all the >> dependencies required to compile Asterisk on the box to "precompile" >> the software for the RPM. With mock the same thing happens, but you >> don't dirty the build environment since it is created each time you >> build the RPM. >> >> It took me about a week to go from not knowing anything about RPMs to >> building the spec files for my environment and using mock to build >> both DAHDI and Asterisk 1.4/1.8 RPMs for all the modules I required >> along with converting all our other spec files to being usable by mock >> to build all our RPMs (about 12 applications in total). >> >> Leif. > > -- Leif Madsen. http://www.leifmadsen.com http://www.oreilly.com/catalog/asterisk --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
