VoIP Community of Thailand - เว็บบอร์ด VoIP Issabel, Elastix Asterisk FreePBX IPPhone VoIP Gateway Call Center IPPBX ของไทย โดยคนไทย เพื่อคนไทย

DAHDI ย่อมาจาก Digium Asterisk Hardware Device Interface เป็นเหมือนกับไดร์เวอร์ที่ทำให้ Asterisk รู้จักและทำงานร่วมกับการ์ดอินเตอร์เฟสต่างๆได้ เช่น การ์ด FXS, FXO โดยที่ Asterisk จะมองการ์ดเหล่านี้ (ผ่านทาง DAHDI) ว่าเป็น Channel

เดิมทีใช้ชื่อว่า "ZapTel" แต่บังเอิญชื่อนี้ไปตรงกับชื่อบริษัท "ZapTel" ซึ่งทำธุรกิจทางด้านให้บริการบัตรโทรศัพท์ บริษัทนี้โวยวายมาที่บริษัท Digium ว่าเวลาค้นหาคำว่า "Zaptel cards" ในอินเตอร์เน็ตเจอแต่ ZapTel ที่เกี่ยวข้องกับ Asterisk ทั้งนั้น ไม่เจอสินค้าของบริษัทเลย ทาง Digium ก็เลยเปลี่ยนชื่อ Zaptel ไปเป็น DAHDI เมื่อวันที่ 18 พฤษภาคม 2550 DAHDI เวอร์ชั่นแรกคือ 2.0.0

ตั้งแต่ Asterisk 1.6.0 ขึ้นไปรองรับเฉพาะ DAHDI เท่านั้นนะครับ มันไม่รองรับ Zaptel ถ้าเดิมเราใช้ Asterisk 1.4 + Zaptel แล้วอัพเกรดเป็น Asterisk 1.6 + DAHDI ก็ยังคงใช้ Dial Plan เดิมได้นะครับ แต่ก็อาจจะมีปัญหาเล็กน้อยซึ่งทาง Digium ก็สามารถแก้ปัญหาไปได้ระดับหนึ่งแล้ว ผมเชื่อว่าถ้า Dial Plan ไม่ซับซ้อนมากก็ไม่ต้องกังวลอะไร

การเปลี่ยนชื่อจาก Zaptel เป็น DAHDI ส่งผลให้ชื่อไฟล์ต่างๆที่เกี่ยวข้องกับ Zaptel ก็เปลี่ยนไปด้วย ดังนี้ครับ

/etc/zaptel.conf --> /etc/dahdi/system.conf
/etc/asterisk/zapata.conf --> /etc/asterisk/chan_dahdi.conf

ไฟล์คอนฟิกของ DAHDI
/etc/dahdi/system.conf
/etc/asterisk/chan_dahdi.conf

/etc/dahdi/init.conf (ใช้แทนไฟล์ /etc/sysconfig/zaptel) เป็นไฟล์คอนฟิก (ที่อยู่ในรูปแบบของ shell script) ของ dahdi init.d script ค่าที่อยู่ไฟล์นี้ใช้จะถูกใช้แทนค่าดีฟอลท์ที่เซ็ตจาก init.d script ทุกค่าเป็นออปชั่น (ไม่จำเป็นต้องคอนฟิกบอก TELEPHONY=no) แต่อย่างไรก็ตาม Asterisk จะไม่ได้อ่านตัวแปร MODULES จากไฟล์นี้แล้ว เพราะมันไปอ่านจากไฟล์ /etc/dahdi/modules แทน

ไฟล์ /etc/sysconfig/zaptel ถูกแยกเป็น 2 ไฟล์ คือ /etc/dahdi/modules ซึ่งจะบอก DAHDI ว่าให้โหลดโมดูลอะไรบ้าง และ /etc/modprobe.d/dahdi จะบอกว่าโหลดโมดูลด้วยออปชั่นอะไรบ้าง

DAHDI แบ่งออกเป็น 2 ส่วนคือ DAHDI-Linux และ DAHDI-Tools ดังนี้

1 DAHDI-LINUX

1.1 โมดูลทั่วไป
ตอนที่เราคอมไพล์ dahdi-linux นะครับ จะมีไฟล์ .ko ติดตั้งอยู่ในไดเร็คตอรี่ของ Linux Kernel โมดูลเหล่านี้ได้แก่
zaptel.ko --> dahdi.ko
ztd-eth.ko --> dahdi_dynamic_eth.ko
ztd-loc.ko --> dahdi_dynamic_loc.ko
ztdummy.ko --> dahdi_dummy.ko
ztdynamic.ko --> dahdi_dynamic.ko
zttranscode.ko --> dahdi_transcode.ko

รายชื่อโมดูลที่จะถูกโหลดจะอยู่ในไฟล์ /etc/dahdi/modules

1.2 โมดูล Software Echo Canceller
Echo Canceller คือส่วนที่จะทำหน้าที่กำจัดเสียงสะท้อนกลับเวลาคุยโทรศัพท์ ถ้าในระหว่างที่เราคุยโทรศัพท์เราได้ยินเสียงของเราเองย้อนกลับเข้ามานั่นแสดงว่าเกิดเสียงสะท้อนนะครับ Asterisk รองรับ Echo Canceller อยู่ 2 ประเภทครับ คือแบบ Software (ใช้โปรแกรมหรือโค๊ดโปรแกรมช่วย) และแบบ Hardware (มีอยู่บนการ์ดอินเตอร์เฟสเลย) โดยที่ Asterisk มีแบบ Software Echo Canceller มาให้ในตัวแล้วนะครับ รอให้เราเปิดให้งานเท่านั้น

Software และ Hardware Echo Canceller ต่างกันตรงที่แบบ Software ใช้ CPU ของเครื่องคอมพิวเตอร์เป็นตัวประมวลผล ซึ่งว่ากันว่าจะทำให้ CPU โหลดพอสมควร ยิ่งมีคอลมากก็ยิ่งโหลดมากขึ้น ส่วนแบบ Hardware นั้นนะครับทางผู้ผลิตการ์ดอินเตอร์เฟสได้ใส่ Echo Canceller ไว้บนตัวการ์ดเลย ทำให้ Asterisk ไม่ต้องรับภาระตรงนี้ ดังนั้นถ้าเราใช้การ์ดที่มี Echo Canceller ในตัวก็ให้ปิด Echo Canceller บน Asterisk ด้วยนะครับ อย่าลืมหล่ะ

ตอนที่ติดตั้ง dahdi-linux เราไม่ต้องระบุว่าจะใช้ Software Echo Canceller แบบใด ซึ่งมีทั้งหมด 4 แบบคือ MG2, KB1, SEC และ SEC2 ทั้ง 4 แบบจะถูกคอมไพล์สร้างเป็นโมดูลที่สามารถโหลดได้

เราสามารถคอนฟิกเลือก Echo Canceller ได้โดยใช้ยูติลิตี้ "dahdi_cfg" เราควรใช้ Echo Canceller เสมอนะครับ เว้นแต่ว่าใช้การ์ดอินเตอร์เฟสที่มี Echo Canceller อยู่ในตัวแล้ว และดีฟอลท์ในไฟล์ system.conf ไม่ได้อินาเบิล Echo Canceller ไว้นะครับ (เพราะมี # อยู่หน้าบรรทัด) เราต้องอินาเบิลขึ้นมาใช้งานเอง

/etc/dahdi/genconf_parameters (แทนไฟล์ zapconf และ genzaptelconf) เป็นไฟล์คอนฟิกเพื่อปรับแต่งพารามิเตอร์แบบละเอียดสำหรับยูติลิตี้ dahdi_genconf

2 DAHDI Tools

เป็นคำสั่งหรือยูติลิตี้ที่เกี่ยวข้องกับ DAHDI มีดังต่อไปนี้ครับ

ztcfg --> dahdi_cfg
เป็น DAHDI Configurator โดยอาศัยข้อมูลในไฟล์ /etc/dahdi/system.com

zapconf --> dahdi_genconf
สร้างไฟล์ /etc/dahdi/system.conf ดังนั้นมันจะเป็นการดีที่เราจะไม่ไปแก้ไขไฟล์ /etc/dahdi/system.conf ใช้ /etc/dahdi/genconf_parameters เพื่อกำหนดแอ๊คชั่น

dahdi_hardware
แสดงรายชื่อของการ์ด DAHDI ที่ดีเทคได้ในเครื่อง

ztmonitor --> dahdi_monitor
มอนิเตอร์ระดับสัญญาณบน Analog channel ยอมให้เราบันทึกเสียงได้ คำสั่งคือ
dahdi_monitor <channel num> [-vv] -m -o -p -l limit -s FILE -S FILE
เช่น dahdi_monitor 1 -vv
ไฟล์เสียงที่อัดได้มีฟอร์แม๊ตแบ 8 KHz, 16 Bit signed ใช้โปรแกรม sox แปลงให้เป็นไฟล์ .wav ใช้คำสั่ง sox -r 8000 -s -w file.raw file.wav

ztscan --> dahdi_scan
สร้างรายชื่อทั้งหมดของ DAHDI channels พร้อมแสดงรายละเอียดสั้นๆ

zttest --> dahdi_test
วัดความแม่นยำในการทำงานของภาค Digital Signal Processing ของการ์ด FXS/FXO

zttool --> dahdi_tool
เช็คว่าขณะนี้การ์ดอินเตอร์เฟสกำลังทำอะไรอยู่

ztspeed --> dahdi_speed

การ์ดอินเตอร์เฟสหรือฮาร์ดแวร์ของ DAHDI
ปัจจุบันมีผู้ผลิตการ์ดอินเตอร์เฟสหลายบริษัท ซึ่งเข้ากันได้กับ DAHDI โดยไม่ต้องลงไดร์เวอร์แต่อย่างใด ตัวอย่างผู้ผลิตการ์ดเหล่านี้ได้แก่
Digium
Sangoma
Xorcom Asteribank
Rhino
OpenVox

นอกจาก Asterisk ที่รองรับการ์ดอินเตอร์เฟสเหล่านี้แล้ว ยังมีโปรแกรมอื่นที่รองรับการ์ดด้วยนะครับ ซึ่งเป็นโปรเจ็คเกี่ยวกับ VoIP เช่นเดียวกัน ได้แก่ CallWeaver และ YATE

ไฟล์ /etc/dahdi/system.conf
มาดูรายละเอียดของไฟล์ /etc/dahdi/system.conf กันครับ เว็บไซต์ http://docs.tzafrir.org.il/dahdi-tools/ ... ystem_conf
วิธีการสำคัญในการคอนฟิกอุปกรณ์ DAHDI คือใช้ยูติลิตี้ที่มีชื่อว่า "dahdi_cfg" ซึ่งเมื่อสั่งให้ทำงาน dahdi_cfg จะอ่านข้อมูลจากไฟล์ /etc/dahdi/system.conf เพื่อหาว่ามีคอนฟิกไหนบ้างที่จะส่งไปยัง Channels เมื่อเจอแล้วก็จะส่งไปยัง Kernel
ตัวอย่างคอนฟิกใน system.conf มีอยู่ในไดเร็คตอรี่ /etc/dahdi แล้ว แก้ไขให้ตรงกับความต้องการ แต่เราก็สามารถใช้ยูติลิตี้ "dahdi_genconf" สร้างขึ้นมาก็ได้ ซึ่งควรจะทำงานได้

1 Span Configuration

span=<span num>,<timing source>,<line build out (LBO)>, <framing>,<coding>[,yellow]

All T1/E1/BRI spans generate a clock signal on their transmit side. The <timing source> parameter determines whether the clock signal from the far end of the T1/E1/BRI is used as the master source of clock timing. If it is, our own clock will synchronise to it. T1/E1/BRI connected directly or indirectly to a PSTN provider (telco) should generally be the first choice to sync to. The PSTN will never be a slave to you. You must be a slave to it.

Choose 1 to make the equipment at the far end of the E1/T1/BRI link the preferred source of the master clock. Choose 2 to make it the second choice for the master clock, if the first choice port fails (the far end dies, a cable breaks, or whatever). Choose 3 to make a port the third choice, and so on. If you have, say, 2 ports connected to the PSTN, mark those as 1 and 2. The number used for each port should be different.

If you choose 0, the port will never be used as a source of timing. This is appropriate when you know the far end should always be a slave to you. If the port is connected to a channel bank, for example, you should always be its master. Likewise, BRI TE ports should always be configured as a slave. Any number of ports can be marked as 0.

Incorrect timing sync may cause clicks/noise in the audio, poor quality or failed faxes, unreliable modem operation, and is a general all round bad thing.

The line build-out (or LBO) is an integer, from the following table:

0: 0 db (CSU) / 0-133 feet (DSX-1)
1: 133-266 feet (DSX-1)
2: 266-399 feet (DSX-1)
3: 399-533 feet (DSX-1)
4: 533-655 feet (DSX-1)
5: -7.5db (CSU)
6: -15db (CSU)
7: -22.5db (CSU)
If the span is a BRI port the line build-out is not used and should be set to 0.

framing
one of d4 or esf for T1 or cas or ccs for E1. Use ccs for BRI. d4 could be referred to as sf or superframe

coding
one of ami or b8zs for T1 or ami or hdb3 for E1. Use ami for BRI.

For E1 there is the optional keyword crc4 to enable CRC4 checking.

If the keyword yellow follows, yellow alarm is transmitted when no channels are open.

#span=1,0,0,esf,b8zs
#span=2,1,0,esf,b8zs
#span=3,0,0,ccs,hdb3,crc4

2 Dynamic Spans
Next come the dynamic span definitions, in the form:

dynamic=<driver>,<address>,<numchans>,<timing>
Where <driver> is the name of the driver (e.g. eth), <address> is the driver specific address (like a MAC for eth), <numchans> is the number of channels, and <timing> is a timing priority, like for a normal span. use "0" to not use this as a timing source, or prioritize them as primary, secondard, etc. Note that you MUST have a REAL DAHDI device if you are not using external timing.

dynamic=eth,eth0/00:02:b3:35:43:9c,24,0
If a non-zero timing value is used, as above, only the last span should have the non-zero value.

3 Channel Configuration
Next come the definitions for using the channels. The format is: <device>=<channel list>

Valid devices are:

e&m
Channel(s) are signalled using E&M signalling (specific implementation, such as Immediate, Wink, or Feature Group D are handled by the userspace library).

fxsls
Channel(s) are signalled using FXS Loopstart protocol.

fxsgs
Channel(s) are signalled using FXS Groundstart protocol.

fxsks
Channel(s) are signalled using FXS Koolstart protocol.

fxols
Channel(s) are signalled using FXO Loopstart protocol.

fxogs
Channel(s) are signalled using FXO Groundstart protocol.

fxoks
Channel(s) are signalled using FXO Koolstart protocol.

sf
Channel(s) are signalled using in-band single freq tone. Syntax as follows:

channel# => sf:<rxfreq>,<rxbw>,<rxflag>,<txfreq>,<txlevel>,<txflag>
rxfreq is rx tone freq in Hz, rxbw is rx notch (and decode)
bandwith in hz (typically 10.0), rxflag is either 'normal' or
'inverted', txfreq is tx tone freq in hz, txlevel is tx tone
level in dbm, txflag is either 'normal' or 'inverted'. Set
rxfreq or txfreq to 0.0 if that tone is not desired.

unused
No signalling is performed, each channel in the list remains idle

clear
Channel(s) are bundled into a single span. No conversion or signalling is performed, and raw data is available on the master.

bchan
Like clear except all channels are treated individually and are not bundled. inclear is an alias for this.

rawhdlc
The DAHDI driver performs HDLC encoding and decoding on the bundle, and the resulting data is communicated via the master device.

dchan
The DAHDI driver performs HDLC encoding and decoding on the bundle and also performs incoming and outgoing FCS insertion and verification. fcshdlc is an alias for this.

hardhdlc
The hardware driver performs HDLC encoding and decoding on the bundle and also performs incoming and outgoing FCS insertion and verification. Is subject to limitations and support of underlying hardware. BRI spans serviced by the wcb4xxp driver must use hardhdlc channels for the signalling channels.

nethdlc
The DAHDI driver bundles the channels together into an hdlc network device, which in turn can be configured with sethdlc (available separately). In 2.6.x kernels you can also optionally pass the name for the network interface after the channel list. Syntax:

nethdlc=<channel list>[:interface name]
Use original names, don't use the names which have been already registered in system e.g eth.

dacs
The DAHDI driver cross connects the channels starting at the channel number listed at the end, after a colon

dacsrbs
The DAHDI driver cross connects the channels starting at the channel number listed at the end, after a colon and also performs the DACSing of RBS bits

The channel list is a comma-separated list of channels or ranges, for example:

1,3,5 (channels one, three, and five)
16-23, 29 (channels 16 through 23, as well as channel 29)
So, some complete examples are:

e&m=1-12
nethdlc=13-24
fxsls=25,26,27,28
fxols=29-32
An example of BRI port:

span=1,1,0,ccs,ami
bchan=1,2
hardhdlc=3
Note When using BRI channels in asterisk, use the bri_cpe, bri_net, or bri_cpe_ptmp (for point to multipoint mode). libpri does not currently support point to multipoint when in NT mode. Otherwise, the bearer channel are configured identically to other DAHDI channels.

#fxoks=1-24
#bchan=25-47
#dchan=48
#fxols=1-12
#fxols=13-24
#e&m=25-29
#nethdlc=30-33
#clear=44
#clear=45
#clear=46
#clear=47
#fcshdlc=48
#dacs=1-24:48
#dacsrbs=1-24:48

4 Tone Zone Data
Finally, you can preload some tone zones, to prevent them from getting overwritten by other users (if you allow non-root users to open /dev/dahdi/* interfaces anyway. Also this means they won't have to be loaded at runtime. The format is "loadzone=<zone>" where the zone is a two letter country code.

You may also specify a default zone with "defaultzone=<zone>" where zone is a two letter country code.

An up-to-date list of the zones can be found in the file zonedata.c

loadzone = us
#loadzone = us-old
#loadzone=gr
#loadzone=it
#loadzone=fr
#loadzone=de
#loadzone=uk
#loadzone=fi
#loadzone=jp
#loadzone=sp
#loadzone=no
#loadzone=hu
#loadzone=lt
#loadzone=pl
defaultzone=us

5 PCI Radio Interface
(see http://www.zapatatelephony.org/app_rpt.html)

The PCI Radio Interface card interfaces up to 4 two-way radios (either a base/mobile radio or repeater system) to DAHDI channels. The driver may work either independent of an application, or with it, through the driver;s ioctl() interface. This file gives you access to specify load-time parameters for Radio channels, so that the driver may run by itself, and just act like a generic DAHDI radio interface.

Unlike the rest of this file, you specify a block of parameters, and then the channel(s) to which they apply. CTCSS is specified as a frequency in tenths of hertz, for example 131.8 HZ is specified as 1318. DCS for receive is specified as the code directly, for example 223. DCS for transmit is specified as D and then the code, for example D223.

The hardware supports a "community" CTCSS decoder system that has arbitrary transmit CTCSS or DCS codes associated with them, unlike traditional "community" systems that encode the same tone they decode.

this example is a single tone DCS transmit and receive

specify the transmit tone (in DCS mode this stays constant):

#tx=D371
specify the receive DCS code:

#dcsrx=223
this example is a "community" CTCSS (if you only want a single tone, then only specify 1 in the ctcss list)

specify the default transmit tone (when not receiving):

#tx=1000
Specify the receive freq, the tag (use 0 if none), and the transmit code. The tag may be used by applications to determine classification of tones. The tones are to be specified in order of presedence, most important first. Currently, 15 tones may be specified..

#ctcss=1318,1,1318
#ctcss=1862,1,1862
The following parameters may be omitted if their default value is acceptible

Set the receive debounce time in milliseconds:

#debouncetime=123
set the transmit quiet dropoff burst time in milliseconds:

#bursttime=234
set the COR level threshold (specified in tenths of millivolts) valid values are {3125,6250,9375,12500,15625,18750,21875,25000}

#corthresh=12500
Invert COR signal {y,n}

#invertcor=y
Set the external tone mode; yes, no, internal {y,n,i}

#exttone=y
Now apply the configuration to the specified channels:

We are all done with our channel parameters, so now we specify what channels they apply to

#channels=1-4

6 Overiding PCM encoding
Usually the channel driver sets the encoding of the PCM for the channel (mulaw / alaw. That is: g711u or g711a). However there are some cases where you would like to override that. mulaw and alaw set different such encoding. Use them for channels you have already defined with e.g. bchan or fxoks.

#mulaw=1-4
#alaw=1-4
deflaw is similar, but resets the encoding to the channel driver's default. It must be useful for something, I guess.

#mulaw=1-10
#deflaw=5

7 Echo Cancellers
DAHDI uses modular echo cancellers that are configured per channel. The echo cancellers are compiled and installed as part of the dahdi-linux package. You can specify in this file the echo canceller to be used for each channel. The default behavior is for there to be NO echo canceller on any channel, so it is very important that you specify one here if you do not have hardware echo cancellers and need echo cancellation.

Valid echo cancellers are: mg2, kb1, sec2, and sec. If compiled, hpec is also a valid echo canceller.

To configure the default echo cancellers, use the format: echocanceller=<echocanceller name>,<channel(s)>

Example: Configure channels 1 through 8 to use the mg2 echo canceller

#echocanceller=mg2,1-8
And change channel 2 to use the kb1 echo canceller.

#echocanceller=kb1,2

2.5. Sample init.confShell settings for Dahdi initialization scripts. This replaces the old/per-platform files (/etc/sysconfig/zaptel, /etc/defaults/zaptel)

The maximal timeout (seconds) to wait for udevd to finish generating device nodes after the modules have loaded and before running dahdi_cfg.

#DAHDI_DEV_TIMEOUT=40
Override settings for xpp_fxloader

#XPP_FIRMWARE_DIR=/usr/share/dahdi
#XPP_HOTPLUG_DISABLED=yes
#XPP_HOTPLUG_DAHDI=yes

2.6. Sample genconf_parameters

FIXME: still not properly formatted.




/etc/dahdi/genconf_parameters
ไฟล์นี้มีพารามิเตอร์ที่จะมีผลต่อยูติลิตี้ที่ใช้สร้างไฟล์คอนฟิก ซึ่งมีชื่อว่า "dahdi_genconf"

รูปแบบ: A comment from # to end of line Blank lines ignored Whitespace at end of line trimmed Single valued items: key <whitespace…> value * List valued items: key <whitespace…>value1 <whitespace…>value2 …

#base_exten 4000
เมื่อสร้าง Extensions สำหรับการ์ด DAHDI ไว้ในไฟล์ chan_dahdi.conf หรือ users.conf เบอร์ Extension จะมีรูปแบบเป็น chan_number+base_exten ซึ่งค่าดีฟอลท์คือ

#fxs_immediate yes
ทำให้เบอร์ Extension ที่เป็น FXS (พอร์ตที่ต่อกับเครื่องโทรศัพท์ธรรมดาหรือแฟ็กซ์) ตอบรับอัตโนมัติ (ในไฟล์ chan_dahdi.conf เซ็ตค่า immediate = yes ด้วยนะครับ) ห้ามเซ็ตออปชั่นนี้เป็น Yes นะครับจนกว่าจะได้อ่านเอกสารเกี่ยวกับออปชั่นนี้จนเข้าใจเสียก่อน

#fxs_default_start ls
สำหรับเบอร์ Extension ที่เป็น FXS จะใช้ KS หรือว่า LS ดีหล่ะ ? ซึ่งแบบ KS เป็นวิธีการเดียวเท่านั้นที่ Asterisk ใช้เพื่อทำ Disconnect Supervision และดังนั้นจึงเป็นค่าที่ควรใช้และเซ็ตให้เป็นดีฟอลท์ ถ้ามีปัญหาเรื่องการวางสาย (เราวางสายแล้วแต่ Asterisk ไม่ดีเท็ค) ก็เช็คว่าเป็น KS หรือเปล่า

#fxo_default_start ls
สำหรับพอร์ต FXO (ต่อกับเบอร์โทรศัพท์ หรือเบอร์ภายในของตู้สาขาโทรศัพท์) ใช้ KS หรือ LS ดีหล่ะ ? ดีฟอลท์เป็น KS และควรจะเลือก KS เพราะสามารถดีเท็คการวางสายโทรศัพท์ได้ดีกว่า เพราะถ้าเราวางสายแล้วแต่ Asterisk ยังไม่ดีเท็คว่าเราวางสาย สายก็จะค้าง ทำให้โทรเข้า โทรออกไม่ได้นะครับ

#lc_country il
เซ็ตค่า Tone Zone ซึ่ง Asterisk จะใช้ค่า Tone Zone นี้มากำหนดว่าจะสร้างสัญญาณ Busy, Dial Tone และอื่นๆ ด้วยความถี่เป็นเท่าไหร่ ติดดับเป็นระยะเวลาเท่าไหร่ ค่าดีฟอลท์คือ us (ประเทศสหรัฐอเมริกา) ออปชั่นนี้จะควบคุมทั้งค่า loadzone และ defaultzone ในไฟล์ system.conf

#context_lines from-pstn
เป็น context ใน dialplan (ไฟล์ extensions.conf) ซึ่ง Asterisk จะส่งจาก trunk ในไฟล์ chan_dahdi.conf หรือ users.conf ไปให้ อย่าลืมว่าในไฟล์ extensions.conf จะต้องมี context ชื่อนี้อยู่ด้วยนะครับ ดีฟอลท์คือ from-pstn

#context_phones from-internal
The dialplan context into which to send extensions in chan_dahdi.conf or users.conf. The default value is:
เป็น context ใน dialplan (ไฟล์ extensions.conf) ที่จะส่งจากเบอร์ Extension ในไฟล์ chan_dahdi.conf หรือ users.conf ไป ในไฟล์ extensions.conf ต้องมี context ชื่อนี้อยู่ด้วยนะครับ ดีฟอลท์คือ from-internal

#context_input astbank-input
#context_output astbank-output
Two extra contexts for the input ports and output ports of an Astribank. Default values are:

#group_phones 5
A group to put all analog phones in. By default 0, so you can dial to the first phone available using Dahdi/g5 .

#group_lines 0
A group in which to put all the channels belonging to some trunk. Thus you can dial through "some trunk" using Dahdi/G0/NUMBER

Channels of digital trunk of span N are also added to group 10+N (that is: 14 for channels of span 4).

#bri_sig_style bri
Do we want to use PtP (bri) or PtMP (bri_ptmp) for BRI? PtMP allows connecting several CPE devices on the same network device (several BRI phones on the same line, kind of like several analog phones on the same analog line). However it is generally brings unnecessary complexity for a pbx-pbx connection. It is still the default as this is normally what you get for a BRI PSTN connection.

#brint_overlap
If this option is set (that is: not remmed-out), BRI NT ports will also be set as overlap. This is useful if you want to connect ISDN phones.


The echo canceler to use. If you have a hardware echo canceler, just leave it be, as this one won't be used anyway.

#echo_can hpec
#echo_can oslec
#echo_can none # to avoid echo canceler altogether
The default is mg2, but it may change in the future. E.g: a packager that bundles a better echo canceler may set it as the default, or dahdi_genconf will scan for the "best" echo canceler.


bri_hardhdlc: yes - forces BRI cards to use hardhdlc signalling. no - forces BRI cards to use dchan (an alias for fcshdlc). It is usefull only for dahdi with the bristuff patch.

If it is left out or set to auto: Information supplied by the driver is used to decide: - Currently implemented for Astribanks. - Taken from /sys/bus/xpds/drivers/bri/dchan_hardhdlc. Without this info, falls back to hardhdlc.

#bri_hardhdlc auto
For MFC/R2 Support: R2 will make E1 spans CAS and with the r2_idle_bits bit in system.conf . It will also make dahdi_genconf default to generating the channels of this card in unicall.conf rather than in chan_dahdi.conf . The meaning of this may be extended somehow to support R2 through openr2/chan_dahdi later on.

#pri_connection_type R2
#pri_connection_type CAS
Explicitly set the idle bits for E1 CAS (Sample value is the default):

#r2_idle_bits 1101
Set T1 framing type to d4 instead of esf:

#tdm_framing d4
Use E&M on CAS (default is FXS/FXO). If set, E1 spans will be used as E&M-E1 and T1 will use the requested type:

#em_signalling em
#em_signalling em_w
#em_signalling featd
#em_signalling featdtmf
#em_signalling featdtmf_ta
#em_signalling featb
#em_signalling fgccama
#em_signalling fgccamamf
pri_termtype contains a list of settings: Currently the only setting is for TE or NT (the default is TE). This sets two different but normally related configuration items:

A TE span will have *_cpe signalling in Asterisk and will also get timing from the remote party.

A NT span will have *_new signalling in Asterisk and will provide timing to the remote party.

pri_termtype is a list if span specs and configuration (TE/NT) for them. The first spec that matches is used. The matching is of perl regular expressions, but with * and ? have their meaning from basic regular expressions.

#pri_termtype
SPAN/2 NT SPAN/4 NT

#pri_termtype
SPAN/* NT

7 TonezonesThe file zonedata.c contains the information about the tone zones used in libtonezone (and hence also in ztcfg). Here is a list of those zones:
us United States / North America
au Australia
fr France
nl Netherlands
uk United Kingdom
fi Finland
es Spain
jp Japan
no Norway
at Austria
nz New Zealand
it Italy
us-old United States Circa 1950 / North America
gr Greece
tw Taiwan
cl Chile
se Sweden
be Belgium
sg Singapore
il Israel
br Brazil
hu Hungary
lt Lithuania
pl Poland
za South Africa
pt Portugal
ee Estonia
mx Mexico
in India
de Germany
ch Switzerland
dk Denmark
cz Czech Republic
cn China
ar Argentina
my Malaysia
th Thailand
bg Bulgaria
ve Venezuela
ph Philippines
ru Russian Federation
tr Turkey
pa Panama

8 DAHDI PERL modules
The directory xpp has, in addition to helper utilities for the Xorcom Astribank, a collection of perl modules to provide information related to DAHDI. The perl modules themselves are under xpp/perl_modules/ . In xpp/ there are several utilities that use those modules: - xpp-specific: dahdi_registration, xpp_sync, xpp_blink . - General: lsdahdi, dahdi_genconf, dahdi_hardware, dahdi_drivers

The DAHDI perl modules will currently only be automatically installed if you happen to install the xpp directory. Those utilities require the perl modules to be installed, however they will also look for them in the directory perl_modules, and thus can be run directly from the DAHDI source tree. For example:

./xpp/dahdi_hardware -v
ดูออปชั่นในการเรียกใช้งานคำสั่ง เรายังสามารถใช้ perldoc ยกตัวอย่างเช่น

perldoc ./xpp/lsdahdi
Some of them are specific for the Xorcom Astribank and described in its docuemntation. the others are:

lsdahdi
A somewhat glorified cat /proc/dahdi/*.

dahdi_genconf
ผลิตคอนฟิกไฟล์โดยอาศัย DAHDI channels ที่มีอยู่แล้ว และใช้พารามิเตอร์ในไฟล์ /etc/dahdi/genconf_parameters

dahdi_drivers
เป็นสคิปต์ที่มีแค่ 2 บรรทัด (ไม่ได้ถูกติดตั้งโดยดีฟอลท์) ซึ่งจะบอกว่าโมดูลไหนที่ควรจะถูก modprobe ในเครื่องนี้

dahdi_hardware
คำสั่งนี้ใช้ข้อมูลจาก sysfs และความสามารถของคำสั่งเอง เพื่อแสดงว่า PCI/USB DAHDI hardware ถูกเชื่อมต่ออยู่และขณะนี้ถูกใช้งานอยู่หรือไม่ นอกจากนั้นก็ยังแสดงข้อมูลสำหรับ Astribanks จาก /proc/xpp ด้วย

9 PPP Support
DAHDI digital cards can provide data channels through ppp as point-to-point connections. This requires a plugin to the ppp daemon that is included in the ppp/ subdirectory. To install it:

Make sure you have the PPP source / headers installed. On Debian:

apt-get install ppp-dev
Run make on the ppp subdirectory:

make -C ppp
make -C ppp install
Make sure your kernel has support for both PPP (which is common is distribution kernels and for HDLC (much less common) - CONFIG_PPP and CONFIG_HDLC .

ไดเร็คตอรี่ /etc/dahdi

ไดเร็คตอรี่ /etc/dahdi นี้จะเก็บคอนฟิกและค่าพารามิเตอร์ตั้งต้นของการ์ด DAHDI เมื่อติดตั้ง DAHDI ครั้งแรกจะมีไฟล์ 4 ไฟล์คือ
genconf_parameters
init.conf
modules
system.conf

คำสั่งที่เกี่ยวข้องกับ DAHDI ใน Asterisk Console

ใน Asterisk Console มีคำสั่งเกี่ยวกับ DAHDI อยู่หลายคำสั่งนะครับ ได้แก่

dahdi destroy channel -> Destroy a channel
dahdi restart -> Fully restart DAHDI channels
dahdi set dnd -> Sets/resets DND (Do Not Disturb) mode on a channel
dahdi set hwgain -> Set hardware gain on a channel
dahdi set swgain -> Set software gain on a channel
dahdi show cadenses -> List cadenses
dahdi show channels [trunkgroup -> Show active DAHDI channels
dahdi show channels -> Show information on a channel
dahdi show status -> Show all DAHDI cards status
dahdi show version -> Show the DAHDI version in use