Monday, January 23, 2012

Quick Start on Asterisk-GUI (Analog Trunk)

Provisioning an analog trunk on Asterisk GUI 2.0.4 requires bit more work compared to provisioning SIP client (and some manual setting in my case) so I'll cover the settings before moving onto the provisioning steps. 


Some Background
I am using Asterisk version 1.4.26.2 (it is quite old). Just prior to this release, the Zaptel driver has been renamed to DAHDI (See this link for more information). 


Interesting enough, the module is named “chan_dahdi.so” but the “zapata.conf” file (instead of the chan_dahdi.conf file) is read by asterisk:
home-unix6*CLI> module reload chan_dahdi.so
    -- Reloading module 'chan_dahdi.so' (DAHDI Telephony w/PRI)
  == Parsing '/usr/local/etc/asterisk/zapata.conf': Found
P.S. the purpose of zapata.conf is to configure all TDM interface parameters. The configuration was covered in this post.

Check out the change logs [r122314] and confirmed chan_zap.c was indeed removed in one of the earlier releases (1.4.22). 

Some manual settings
1. Asterisk GUI cannot detect analog hardware - I added one line in ztscan.conf (in etc/asterisk directory), restarted the asterisk process and the FXO port can be detected: 

[1]
active=yes
alarms=OK
description=Wildcard TDM400P REV E/F Board 1
name=WCTDM/0
manufacturer=Digium
devicetype=Wildcard TDM400P REV E/F
location=PCI Bus 05 Slot 09
basechan=1
totchans=4
irq=10
port=1,FXO



2. Asterisk GUI provision the analog trunk as Zap channel (in extensions.conf file), but Asterisk doesn’t understand Zap - unless the “dahdichanname” parameter in asterisk.conf is set to "no"

home-unix6# cat asterisk.conf | grep dahdi
dahdichanname = no yes; Channels created by chan_dahdi will be called 'DAHDI', otherwise 'Zap'



3. After Asterisk process restarts, "chan_dahdi.so" module is not loaded. 
At the moment, I have to manually run "module load chan_module.so" in Asterisk console, because adding "load => chan_dahdi.so" in modules.conf does not help... 




Provisioning
1. If the analog port is detected, it will be displayed on the "Configure Hardware" page:


2. On "Trunk" page, select "New Analog Trunk". Tick "Channel" and assign a name to it: 
3. On "Outgoing Calling Rules" page, set "New Calling Rule" and use the trunk previously defined in step two (local-line):

4. On "Dial plans" page, edit the existing dialplan (if none exist, just create a new one). Tick to include the outgoing calling rule previously defined (localline):




5. Apply the changes ("Apply Change" button is on the top right corner of web browser). This requires a system restart but I restarted the Asterisk process. 


6. The analog trunk has been provisioned and can make or receive phone calls. 




Notes:
Remember Some Manual Settings 3. After Asterisk process restarts, "chan_dahdi.so" module is not loaded. So manual loading/ reload is required. 







2 comments:

  1. I remember old days when using zap with Asterisk 1.0 and then 1.2 manually loading modules was a common practice. When any VoIP Service Provider integrating PSTN connectivity, used to do it like this

    modprobe zaptel (loads zaptel driver)
    modprobe wct4xxp (loads 4 port E1 card)
    modprobe wctfxo (loads fxo analog card)
    asterisk -vvvvvvvvvc

    and similarly we have to perform these steps in reverse order to unload everything.

    ReplyDelete
    Replies
    1. Hi Gregor, thank you for your comment and my apologies for this belated reply.

      Hmm, interesting. So it seems there is a manual procedure in place to load the relevant drivers during the PSTN integration process. Which also means this process has yet to be automated by Asterisk 1.2 (in my case v1.4).

      I quickly glanced through the change log of the latest v1.8 but didn't seem to find anything related to the issue discussed. (Perhaps I overlooked some details?) http://downloads.asterisk.org/pub/telephony/asterisk/ChangeLog-1.8-current

      Delete