Asterisk Integration with Altigen

Integration of Asterisk system with Altigen

Equipment:

  • Legacy Altigen system in a 3 chassis design, supporting over 340 extensions
    • Installed are TritonAL12EXT-3 cards for connection of up to 12 analog phones each. These boards are for homing extensions.
    • Installed are TritonVoIP30PT-2 that handle the interconnecting of extensions between the chassis via IP. The version of the Altigen software we are running doesn’t have SIP support. These servers have their own proprietary IP communications via the ports on these boards, and then the servers are configured with a two digit access code which references them by IP Address (e.g. – Server 01, 02, 03). The configuration of extensions is synchronized between all servers and in order to access an extension homed on a different server, an access code (in our case 8) is dialed to access intra-server extensions, the server ID number of the home server for the extension dialed and then the extension is dialed, all in the background without user intervention.
    • Installed are TritonT1/PRI cards that were originally configured for “Mobile Extension” access. These are only installed in the first chassis and were connected together via a crossover cable but apparently weren’t doing anything. Although some mobile extensions were configured, this particular feature was not being utilized. It was with these two cards that lay the key to integrating Asterisk.
    • Installed are TritonPRI cards for connection to the PSTN
  • Asterisk box
    • Running Slackware
    • Running Asterisk version 1.4.19.1
    • Installed is a Digium Wildcard DGM-TE205P dual T1 card

Challenge:

Integrate these two systems via the T1 cards in a PRI configuration in order to do seamless 4 digit dialing between the systems. Add SIP support to the Altigen systems for further integration with SIP aware phone systems

Process:

  • Wiring – I created two T1 crossover cables with the following pinouts:

1 – 4
2 – 5
4 – 1
5 – 2

All other wires in the cable are extraneous and can be cut out.
Connected each port of the Digium card to a TritonT1/PRI card in the first Altigen chassis.
(You won’t see a green light until the driver is loaded in Asterisk)


  • Asterisk Configuration:

    • Downloaded, compiled and installed libpri version 1.4.6 for adding PRI configuration support to Asterisk
    • Recompiled Zaptel version 1.4.10.1 with support for wct4xxp – driver for the DGM-TE205P and removed the ztdummy driver
    • I rebuilt and reinstalled Asterisk after this, but I don’t believe that step is necessary
    • Ensured that the wct4xxp driver was loaded “modprobe wct4xxp
    • The following is the configuration of my /etc/zaptel.conf file, generated automatically by genzaptelconf:

  1. Span 1: TE2/0/1 “T2XXP (PCI) Card 0 Span 1” (MASTER) B8ZS/ESF Clocksource
span=1,1,0,esf,b8zs
bchan=1-23
dchan=24

  1. Span 2: TE2/0/2 “T2XXP (PCI) Card 0 Span 2” B8ZS/ESF
span=2,2,0,esf,b8zs
bchan=25-47
dchan=48

loadzone = us
defaultzone = us

    • Next is the configuration of zapata.conf, which asterisk loads with the chan_zap.so driver in order to enable and communicate on all configured channels of the PRI connection. In this file, I set the switchtype to the default, national setting, nsf to none and signaling to pri_net as Asterisk provides the clocking on the PRI line. I put all channels on both ports in one group. Be sure to specify the context in which you want these channels to be available. The relaxdtmf option was needed since it wasn’t passing the extension as specified in the ${EXTEN} variable from Asterisk. It would connect to the Altigen IVR and then the user would have to enter the extension again. The facilityenable works around an issue of the name not being passed for caller ID over a PRI connection. The following is the configuration of my /etc/asterisk/zapata.conf file:

[trunkgroups]

[channels]
language=en
context=context where your extensions will reside
pridialplan=national
prilocaldialplan=national
;pritimer = t200,2000
;pritimer = t203,10500
resetinterval=never
relaxdtmf=yes
facilityenable=yes
usecallerid=yes
hidecallerid=no
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
rxgain=0.0
txgain=0.0
group=1
callgroup=1
pickupgroup=1

immediate=no

switchtype = national
nsf = none
signalling = pri_net
group = 1
channel => 1-23
channel => 25-47

    • With Asterisk running, when loading the chan_zap.so driver, this will turn the lines up and be ready for the connection on the Altigen side of things.

  • Altigen configuration:

    • We are running AltiContact Manager 5.0A with Update 4
    • First, I had to undo the configuration of the TritonT1/PRI cards. The trunks on one of the cards were configured as Mobile Extensions and then tied to the other TritonT1/PRI card. I removed this configuration and also changed the Span type of the cards to Regular ISDN PRI from T1 CAS.
      • In the Boards pane, double-click on the Mobile Extensions pseudo board that appears and in the lower half of that screen you will see the board that has it’s ports configured as such. Highlight one and remove the check to configure it as a Mobile Extension, click on the Apply To button and choose all of the ports of that board and click Ok.
      • This required a restart of the Altigen Switching Service COM Server (AltiServ.exe as it appears in the Task Manager). When this service is stopped, it will stop a plethora of other services related to it. This service is very temperamental and never completes stopping so I had to kill the process in the Task Manager, after which I could start it again without any incident. After starting this service again, it will automatically start other necessary services, so this is the only one you need to worry about.
      • In the Boards pane, double-click on the TritonT1/PRI card then double-click on the span name in the right half of that box. At the next screen, ensure that the Frame Type is set to ESF and the Line Code is set to B8ZS. Ours already were, so there was no need to change these options. Ensure that the System Clock Master is NOT checked, as Asterisk will be providing the clocking on the line. Click on the Protocol button. At the next screen, ensure that the Span type selection is set to Regular ISDN PRI, the switch mode is NI-2 PRI (this is the National switch type), B Channel Maintenance Message is set to Restart and Service and NSF is set to None. Changing these parameters should require a restart of the service once again, so follow the above procedure. When everything comes back up, all the channels on the cards should show green and you should see confirmation on Asterisk that the D Channel is now up and running.
    • I next changed the access code to get to these trunks and set all of the channels on the trunks to Tie Trunks.
      • Double-click on any one of the channels of the TritonT1/PRI card. Choose an access number that isn’t already in use (in our case it is 5) from the Access Code drop down box. This needs to be configured beforehand in the Number Plan of the System Configuration as a Trunk Access. Place a check in the Enable Tie Trunk box, click on the Apply To button and highlight all of the ports of both cards and choose Ok.
    • Next, I created a virtual extension on the first server that contains the TritonT1/PRI cards, since it is the gateway to and from the Asterisk server. Supposedly there is an unlimited number of virtual extensions that can be created, so make sure you have them setup either on Asterisk or another system you will be bridging with Asterisk and create away. In order to “port” extensions over so that they live on Asterisk, you will need to delete them from the Altigen system first, then recreate them as virtual extensions like the following procedure:
      • From the Restriction tab of the newly created virtual extension, make sure the following are checked and enabled:
        • Allow Calls to be Transferred or Conferenced to an Outside Number
        • Allow Extension User to Configure Forwarding, Notification and Reminder Call to an Outside Number
      • From the Answering tab of the newly created virtual extension, Enable Forward to Outside Number, choose the access code you had set on the trunk (in our case it is 5) and then type in the extension number in the box provided.
      • Synchronize the systems via the DINA Manager utility and make sure that you choose the server that contains the trunk ports to Asterisk as the home server for that virtual extension. If you perform a test call from Altigen to one of those extension, it should pick up a trunk line, connect to Asterisk and ring the extension.


Phone System Integration.jpg


Integration of Asterisk system with Altigen

Equipment:

  • Legacy Altigen system in a 3 chassis design, supporting over 340 extensions
    • Installed are TritonAL12EXT-3 cards for connection of up to 12 analog phones each. These boards are for homing extensions.
    • Installed are TritonVoIP30PT-2 that handle the interconnecting of extensions between the chassis via IP. The version of the Altigen software we are running doesn’t have SIP support. These servers have their own proprietary IP communications via the ports on these boards, and then the servers are configured with a two digit access code which references them by IP Address (e.g. – Server 01, 02, 03). The configuration of extensions is synchronized between all servers and in order to access an extension homed on a different server, an access code (in our case 8) is dialed to access intra-server extensions, the server ID number of the home server for the extension dialed and then the extension is dialed, all in the background without user intervention.
    • Installed are TritonT1/PRI cards that were originally configured for “Mobile Extension” access. These are only installed in the first chassis and were connected together via a crossover cable but apparently weren’t doing anything. Although some mobile extensions were configured, this particular feature was not being utilized. It was with these two cards that lay the key to integrating Asterisk.
    • Installed are TritonPRI cards for connection to the PSTN
  • Asterisk box
    • Running Slackware
    • Running Asterisk version 1.4.19.1
    • Installed is a Digium Wildcard DGM-TE205P dual T1 card

Challenge:

Integrate these two systems via the T1 cards in a PRI configuration in order to do seamless 4 digit dialing between the systems. Add SIP support to the Altigen systems for further integration with SIP aware phone systems

Process:

  • Wiring – I created two T1 crossover cables with the following pinouts:

1 – 4
2 – 5
4 – 1
5 – 2

All other wires in the cable are extraneous and can be cut out.
Connected each port of the Digium card to a TritonT1/PRI card in the first Altigen chassis.
(You won’t see a green light until the driver is loaded in Asterisk)


  • Asterisk Configuration:

    • Downloaded, compiled and installed libpri version 1.4.6 for adding PRI configuration support to Asterisk
    • Recompiled Zaptel version 1.4.10.1 with support for wct4xxp – driver for the DGM-TE205P and removed the ztdummy driver
    • I rebuilt and reinstalled Asterisk after this, but I don’t believe that step is necessary
    • Ensured that the wct4xxp driver was loaded “modprobe wct4xxp
    • The following is the configuration of my /etc/zaptel.conf file, generated automatically by genzaptelconf:

  1. Span 1: TE2/0/1 “T2XXP (PCI) Card 0 Span 1” (MASTER) B8ZS/ESF Clocksource
span=1,1,0,esf,b8zs
bchan=1-23
dchan=24

  1. Span 2: TE2/0/2 “T2XXP (PCI) Card 0 Span 2” B8ZS/ESF
span=2,2,0,esf,b8zs
bchan=25-47
dchan=48

loadzone = us
defaultzone = us

    • Next is the configuration of zapata.conf, which asterisk loads with the chan_zap.so driver in order to enable and communicate on all configured channels of the PRI connection. In this file, I set the switchtype to the default, national setting, nsf to none and signaling to pri_net as Asterisk provides the clocking on the PRI line. I put all channels on both ports in one group. Be sure to specify the context in which you want these channels to be available. The relaxdtmf option was needed since it wasn’t passing the extension as specified in the ${EXTEN} variable from Asterisk. It would connect to the Altigen IVR and then the user would have to enter the extension again. The facilityenable works around an issue of the name not being passed for caller ID over a PRI connection. The following is the configuration of my /etc/asterisk/zapata.conf file:

[trunkgroups]

[channels]
language=en
context=context where your extensions will reside
pridialplan=national
prilocaldialplan=national
;pritimer = t200,2000
;pritimer = t203,10500
resetinterval=never
relaxdtmf=yes
facilityenable=yes
usecallerid=yes
hidecallerid=no
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
rxgain=0.0
txgain=0.0
group=1
callgroup=1
pickupgroup=1

immediate=no

switchtype = national
nsf = none
signalling = pri_net
group = 1
channel => 1-23
channel => 25-47

    • With Asterisk running, when loading the chan_zap.so driver, this will turn the lines up and be ready for the connection on the Altigen side of things.

  • Altigen configuration:

    • We are running AltiContact Manager 5.0A with Update 4
    • First, I had to undo the configuration of the TritonT1/PRI cards. The trunks on one of the cards were configured as Mobile Extensions and then tied to the other TritonT1/PRI card. I removed this configuration and also changed the Span type of the cards to Regular ISDN PRI from T1 CAS.
      • In the Boards pane, double-click on the Mobile Extensions pseudo board that appears and in the lower half of that screen you will see the board that has it’s ports configured as such. Highlight one and remove the check to configure it as a Mobile Extension, click on the Apply To button and choose all of the ports of that board and click Ok.
      • This required a restart of the Altigen Switching Service COM Server (AltiServ.exe as it appears in the Task Manager). When this service is stopped, it will stop a plethora of other services related to it. This service is very temperamental and never completes stopping so I had to kill the process in the Task Manager, after which I could start it again without any incident. After starting this service again, it will automatically start other necessary services, so this is the only one you need to worry about.
      • In the Boards pane, double-click on the TritonT1/PRI card then double-click on the span name in the right half of that box. At the next screen, ensure that the Frame Type is set to ESF and the Line Code is set to B8ZS. Ours already were, so there was no need to change these options. Ensure that the System Clock Master is NOT checked, as Asterisk will be providing the clocking on the line. Click on the Protocol button. At the next screen, ensure that the Span type selection is set to Regular ISDN PRI, the switch mode is NI-2 PRI (this is the National switch type), B Channel Maintenance Message is set to Restart and Service and NSF is set to None. Changing these parameters should require a restart of the service once again, so follow the above procedure. When everything comes back up, all the channels on the cards should show green and you should see confirmation on Asterisk that the D Channel is now up and running.
    • I next changed the access code to get to these trunks and set all of the channels on the trunks to Tie Trunks.
      • Double-click on any one of the channels of the TritonT1/PRI card. Choose an access number that isn’t already in use (in our case it is 5) from the Access Code drop down box. This needs to be configured beforehand in the Number Plan of the System Configuration as a Trunk Access. Place a check in the Enable Tie Trunk box, click on the Apply To button and highlight all of the ports of both cards and choose Ok.
    • Next, I created a virtual extension on the first server that contains the TritonT1/PRI cards, since it is the gateway to and from the Asterisk server. Supposedly there is an unlimited number of virtual extensions that can be created, so make sure you have them setup either on Asterisk or another system you will be bridging with Asterisk and create away. In order to “port” extensions over so that they live on Asterisk, you will need to delete them from the Altigen system first, then recreate them as virtual extensions like the following procedure:
      • From the Restriction tab of the newly created virtual extension, make sure the following are checked and enabled:
        • Allow Calls to be Transferred or Conferenced to an Outside Number
        • Allow Extension User to Configure Forwarding, Notification and Reminder Call to an Outside Number
      • From the Answering tab of the newly created virtual extension, Enable Forward to Outside Number, choose the access code you had set on the trunk (in our case it is 5) and then type in the extension number in the box provided.
      • Synchronize the systems via the DINA Manager utility and make sure that you choose the server that contains the trunk ports to Asterisk as the home server for that virtual extension. If you perform a test call from Altigen to one of those extension, it should pick up a trunk line, connect to Asterisk and ring the extension.


Phone System Integration.jpg


Created by: machete, Last modification: Mon 22 of Dec, 2008 (15:54 UTC)
Please update this page with new information, just login and click on the "Edit" or "Discussion" tab. Get a free login here: Register Thanks! - Find us on Google+