SARK UCS/MVP Managed PCI Telephony Cards(DAHDI)

SARK UCS/MVP 2.3.1 PCI

SARK UCS/MVP releases prior to 2.1.12 used a simple modprobe/proc detection technique to discover and configure telephony cards . This is OK for analogue cards but is less satisfactory for BRI/PRI and mixed set-ups which are more sensitive to the mix of modules loaded.

Releases designated 2.1.13 and later use a different detection technique which eased integration of new cards, particularly in mixed card and multi-card set-ups.. Cards were detected using their vendor/device/subsystem ID's and checked against database entries for known, supported card types.

With the release/rename of Zaptel as DAHDI, Digium have provided several new tools to aid in card detection. SARK UCS/MVP 2.3.1 integrates these new tools into a new interface which moves the burden of board detection back to Digium.

Board recognition and configuration begins with the PCI cards panel in the server-manager...

The main PCI cards window contains a highlighted table, showing the detected cards, in the example above a TDM4xx and a TE110 are shown, together with 2 sub-windows which show the generated DAHDI .conf files for the system. It is important to note that when this panel is first displayed, the contents of chan_dahdi and system.conf will be as they were before card detection took place. The new contents will not be generated until you issue a commit.

Card Setup - step by step...

1. Press "Initialise" to ready the system to generate its configuration information. N.B. this will destroy any previously generated configs. It will also clear down any pre-2.3 configs which may have already been on your system.
2. Press "ReGen". This will run the Digium routine dahdi_genconf to configure the cards.
3. Make any changes you need to chan_dahdi and system.conf. If you do not know what these files do then it is strongly recommended that you simply leave them to default.
4. Press "Save" or "Commit".
5. The very first time you do this you should at this point reboot your server to make sure that the new kmod loader (dahdi) gets started. You can skip to step 8.
6. In subsequent iterations, when you are ready to bring your configuration on-line; press "STOP" to halt the PBX
7. Press "START" to fetch the PBX back into service with your new configuration.
8. Your new configiration is ready to use.

dahdi_genconf limitations

As sniffer routines go, genconf is none too bright. As a result, you will probably want to change some of the choices it has made (for example, its choice of group numbers) before you issue you your commit. It would seem that the majority of work has gone into the detection and setup of TDM analogue type cards and very little into TE PRI. As a result there are a few shortcomings in the PRI processor logic. As if that wasn't bad enough, genconf generates blank lines into /etc/dahdi/system.conf, which dahdi_cfg won't parse (it throws an error), so you need to remove these before restarting asterisk.

What did the PCI routine do?

Quite a lot actually. It detected your cards and generated the necessary .conf files for Asterisk to recognise them. You can prove this by logging into the Asterisk console and querying the card channels...

As you can see. In our case, our two cards comprise a TE110 (ISDN30) card and a TDM22B (Analogue) card, You will also note that genconf has set the contexts as "from-trunk" and "from-internal", which are the FreePBX inbound and outbound processor contexts. Now, you can ask genconf to use different context names (there is a config file), but it only works for TDM cards (not PRI). So, to avoid conflict, SAIL now has entry points for these context names.

Generated Trunks and Outbound Hunt Groups

In addition to creating the Asterisk entities, the ystem has also created the necessary entries in the SARK/SAIL database foir you to address these ports. First we show the trunklines. Notice that SARK/SAIL has also automatically created a group entry so that you may do outbound call line hunting. Also, note that SARK doesn't bother to generate the 30 PRI channels because they are logical constructs in EuroISDN so there is no point in addressing them.

Generated Extensions

Finally, we show the FXS extension entries which were created.

Creating a Route to handle our DAHDI Trunks

Here we show a new route being created to send calls out over the lines that Sark PCI generated for us.