During the installation before compiling asterisk (this can be done after dadhi and libpri) download the souce of speex from http://speex.org/downloads/ into /usr/src/
The installation is quite simple:
tar -xzvf speex-1.2rc1.tar.gz
cd speex-1.2rc1
./configure --prefix=/usr
make
make install
ldconfig
cd ..
Sunday, December 28, 2008
Friday, December 26, 2008
Dadhi installation
New asterisk install, this time zaptel is replaced by dahdi. The installation is quite simple just download the files from asterisk.org on /usr/src, untar files and run the following:
cd /usr/src/dahdi-linux-2.1.0.3#
make clean
make
make install
cd /usr/src/dahdi-tools-2.1.0.2#
./configure
make
make install
make config
Two files to check /etc/dahdi/system.conf and /etc/dahdi/init.conf. On the fist one change zone to UK.
After this as I am not running any voice hardware you can run:
modprobe dadhi
modprobe dadhi-dummy
And a lsmod | more will show the following output:
Module Size Used by
dahdi_dummy 5224 0
dahdi 186280 1 dahdi_dummy
Dadhi README notes available at:
http://svn.digium.com/view/dahdi/tools/tags/2.0.0-rc2/UPGRADE.txt?view=co
cd /usr/src/dahdi-linux-2.1.0.3#
make clean
make
make install
cd /usr/src/dahdi-tools-2.1.0.2#
./configure
make
make install
make config
Two files to check /etc/dahdi/system.conf and /etc/dahdi/init.conf. On the fist one change zone to UK.
After this as I am not running any voice hardware you can run:
modprobe dadhi
modprobe dadhi-dummy
And a lsmod | more will show the following output:
Module Size Used by
dahdi_dummy 5224 0
dahdi 186280 1 dahdi_dummy
Dadhi README notes available at:
http://svn.digium.com/view/dahdi/tools/tags/2.0.0-rc2/UPGRADE.txt?view=co
Thursday, December 25, 2008
Error on Cisco 805 boot (boot#..)
I use a small Cisco 805 as dhcp server in my house. After a power failure the system started with the following prompt:
user@user-desktop:~$ minicom
Welcome to minicom 2.3-rc1
OPTIONS: I18n
Compiled on Dec 10 2007, 10:36:19.
Port /dev/ttyS0
Press CTRL-A Z for help on special keys
TinyROM version 1.4(1)
19:37 11/07/00
Copyright (c) 1998-2000 by cisco Systems, Inc.
All rights reserved.
POST .............. OK. 16MB DRAM, 12MB Flash.
boot#
boot#
Honestly don't know what this is and the commands available were:
boot# help
boot Execute image or CLI command script.
delete Deletes file-name from flash (8th delete is permanent).
disable Disable privileged commands.
echo Display arguments (to test CLI behavior).
enable Enable privileged or debug commands.
erase Erase deleted and invalid files from flash.
help Display help for command (* for all).
list List files currently in ram and saved in flash.
load Load saved boot environment from flash.
passwd Set or change the ROM password.
reset Reset console port to current parameters.
set Set boot environment values.
save Save boot environment or loaded file to flash.
show Show current or saved boot environment.
upload Load image or configuration data into RAM.
undelete Undelete file-name (maximum of 8 deletes & undeletes).
boot#
Luckily googling around I found this page from cisco: http://www.cisco.com/en/US/ts/fn/200/fn27475.html that shows what to do to recover the system.
The command "set" will show the device config and which file it will be use to boot. The output of the set command show that I didn't have any boot image.
boot# set
set baud =9600
set data-bits =8
set parity =none
set stop-bits =1
set console-flags =0
set mac-address =000B.BE48.D887
set unit-ip =0.0.0.0
set serv-ip =0.0.0.0
set netmask =0.0.0.0
set gate-ip =0.0.0.0
set pkt-timeout =4
set tftp-timeout =16
set boot-action =none
set file-name =""
set watchdog =off
set prompt ="boot"
set ios-conf =0xA0
boot#
The second command to use is "list" that shows what you have saved on the ROM. I could find the ios image preset to boot from. Using the "set" command you configure the router to boot using the cisco image like follows:
boot# list
Status Size Dev Name
------ 48K flash TinyROM-1.4(1)
---r-- 911 flash full-config
---r-x 7529K flash c805-xxxx-5.bin
4480K free 12288K total
boot#
The list showed the c805-xxxx.bin being present, using set I change the boot-action and file-name settings:
boot# set boot-action=flash
boot# set file-name="c805-xxxx-5.bin"
Once done just use the "save" command to (guess...) save the configuration and finally "boot" to load the ios into memory.
boot# save
save: succeeded (0 seconds).
boot# boot
Accessing flash:c805-xxxx-5.bin
Booting "c805-xxxx-5.bin" ...,
After the "Booting c805......" message the system starts as normal.
user@user-desktop:~$ minicom
Welcome to minicom 2.3-rc1
OPTIONS: I18n
Compiled on Dec 10 2007, 10:36:19.
Port /dev/ttyS0
Press CTRL-A Z for help on special keys
TinyROM version 1.4(1)
19:37 11/07/00
Copyright (c) 1998-2000 by cisco Systems, Inc.
All rights reserved.
POST .............. OK. 16MB DRAM, 12MB Flash.
boot#
boot#
Honestly don't know what this is and the commands available were:
boot# help
boot Execute image or CLI command script.
delete Deletes file-name from flash (8th delete is permanent).
disable Disable privileged commands.
echo Display arguments (to test CLI behavior).
enable Enable privileged or debug commands.
erase Erase deleted and invalid files from flash.
help Display help for command (* for all).
list List files currently in ram and saved in flash.
load Load saved boot environment from flash.
passwd Set or change the ROM password.
reset Reset console port to current parameters.
set Set boot environment values.
save Save boot environment or loaded file to flash.
show Show current or saved boot environment.
upload Load image or configuration data into RAM.
undelete Undelete file-name (maximum of 8 deletes & undeletes).
boot#
Luckily googling around I found this page from cisco: http://www.cisco.com/en/US/ts/fn/200/fn27475.html that shows what to do to recover the system.
The command "set" will show the device config and which file it will be use to boot. The output of the set command show that I didn't have any boot image.
boot# set
set baud =9600
set data-bits =8
set parity =none
set stop-bits =1
set console-flags =0
set mac-address =000B.BE48.D887
set unit-ip =0.0.0.0
set serv-ip =0.0.0.0
set netmask =0.0.0.0
set gate-ip =0.0.0.0
set pkt-timeout =4
set tftp-timeout =16
set boot-action =none
set file-name =""
set watchdog =off
set prompt ="boot"
set ios-conf =0xA0
boot#
The second command to use is "list" that shows what you have saved on the ROM. I could find the ios image preset to boot from. Using the "set" command you configure the router to boot using the cisco image like follows:
boot# list
Status Size Dev Name
------ 48K flash TinyROM-1.4(1)
---r-- 911 flash full-config
---r-x 7529K flash c805-xxxx-5.bin
4480K free 12288K total
boot#
The list showed the c805-xxxx.bin being present, using set I change the boot-action and file-name settings:
boot# set boot-action=flash
boot# set file-name="c805-xxxx-5.bin"
Once done just use the "save" command to (guess...) save the configuration and finally "boot" to load the ios into memory.
boot# save
save: succeeded (0 seconds).
boot# boot
Accessing flash:c805-xxxx-5.bin
Booting "c805-xxxx-5.bin" ...,
After the "Booting c805......" message the system starts as normal.
Monday, December 01, 2008
H.323 delay in outbound dialling
Last week users reported a long delay when dialling out from their SIP extensions. My setup is quite simple.
Avaya PBX connected to the outside world - H323 Trunk to Asterisk - Asterisk connected to SIP users using softphones from their macs/linux laptops (all this because Avaya don't have a decent softphone for macs/linux yet).
The logs for a few test calls showed a 60+ seconds delay from the time the call was dialled to the time the call was placed over the H323 ip trunk between Avaya and Asterisk.
After checking that it was not a sip problem, dialling problem, h323 trunk problem by checking logs, tcpdump, avaya trunk side, etc. I concluded the problem was on the h323 setup on Asterisk.
Googling around I found only 1 case of a user asking on the asterisk user list about a similar problem and that he fixed the problem by "disable h323 srv lookups".
I honestly didn't have about srv-enum-etc but helped me find out the problem. My DNS was not resolving any request because it was down. It didn't matter that on /etc/resolve.conf I had 4 dns entries, the first one was down and it was enough to stop this.
It seems h323 does a srv lookup for enum information before dialing out and possible it can be disabled. I couldn't find how unfortunately so to fix this I had to point the box to another dns server on my network. Once this was done all starting working again.
Just in case I am copying some logs of what I was seeing when the problem was present.
[Nov 28 15:34:09] VERBOSE[10584] logger.c: -- Executing [myavayaextension@default:1] Dial("SIP/myasteriskextension-081b5bc8", "H323/myavayaextension@Avaya") in new stack
[Nov 28 15:34:09] VERBOSE[10584] logger.c: -- Requested transfer capability: 0x00 - SPEECH
------------------- 64 seconds delay -----------------
[Nov 28 15:35:13] VERBOSE[10584] logger.c: -- Called myavayaextension@Avaya
[Nov 28 15:35:13] VERBOSE[10584] logger.c: -- H323/Avaya-31 is making progress passing it to SIP/myasteriskextension-081b5bc8
[Nov 28 15:35:13] VERBOSE[10584] logger.c: -- H323/Avaya-31 is ringing
[Nov 28 15:35:17] VERBOSE[10584] logger.c: -- H323/Avaya-31 answered SIP/myasteriskextension-081b5bc8
[Nov 28 15:35:18] VERBOSE[10584] logger.c: == Spawn extension (default, myavayaextension, 1) exited non-zero on 'SIP/myasteriskextension-081b5bc8'
[Nov 28 15:19:52] VERBOSE[10551] logger.c: -- Executing [myavayaextension@default:1] Dial("SIP/myasteriskextension-081b5bc8", "H323/myavayaextension@Avaya") in new stack
[Nov 28 15:19:52] DEBUG[10551] chan_h323.c: type=H323, format=8, data=myavayaextension@Avaya.
[Nov 28 15:19:52] DEBUG[10551] chan_h323.c: Extension: myavayaextensionHost: Avaya
[Nov 28 15:19:52] DEBUG[10551] chan_h323.c: Calling to myavayaextension@Avaya on H323/Avaya-30
[Nov 28 15:19:52] VERBOSE[10551] logger.c: -- Requested transfer capability: 0x00 - SPEECH
[Nov 28 15:19:52] DEBUG[10551] chan_h323.c: Placing outgoing call to myavayaextension@192.168.58.216:1720, 101
[Nov 28 15:19:52] VERBOSE[10551] logger.c: -- Making call to myavayaextension@192.168.58.216:1720 without gatekeeper.
[Nov 28 15:19:52] VERBOSE[10551] logger.c: Using 192.168.58.227 for outbound call
------------------- 64 seconds delay -----------------
[Nov 28 15:20:56] VERBOSE[10551] logger.c: == New H.323 Connection created.
[Nov 28 15:20:56] VERBOSE[10551] logger.c: -- root is calling host myavayaextension@192.168.58.216:1720
[Nov 28 15:20:56] VERBOSE[10551] logger.c: -- Call token is ip$localhost/9446
[Nov 28 15:20:56] VERBOSE[10551] logger.c: -- Call reference is 9446
[Nov 28 15:20:56] VERBOSE[10551] logger.c: -- DTMF Payload is [pt=101]
[Nov 28 15:20:56] VERBOSE[10551] logger.c: -- Called myavayaextension@Avaya
Notes:
myasteriskextension
myavayaextension = my 5 digit extension on the avaya pbx.
Avaya PBX connected to the outside world - H323 Trunk to Asterisk - Asterisk connected to SIP users using softphones from their macs/linux laptops (all this because Avaya don't have a decent softphone for macs/linux yet).
The logs for a few test calls showed a 60+ seconds delay from the time the call was dialled to the time the call was placed over the H323 ip trunk between Avaya and Asterisk.
After checking that it was not a sip problem, dialling problem, h323 trunk problem by checking logs, tcpdump, avaya trunk side, etc. I concluded the problem was on the h323 setup on Asterisk.
Googling around I found only 1 case of a user asking on the asterisk user list about a similar problem and that he fixed the problem by "disable h323 srv lookups".
I honestly didn't have about srv-enum-etc but helped me find out the problem. My DNS was not resolving any request because it was down. It didn't matter that on /etc/resolve.conf I had 4 dns entries, the first one was down and it was enough to stop this.
It seems h323 does a srv lookup for enum information before dialing out and possible it can be disabled. I couldn't find how unfortunately so to fix this I had to point the box to another dns server on my network. Once this was done all starting working again.
Just in case I am copying some logs of what I was seeing when the problem was present.
[Nov 28 15:34:09] VERBOSE[10584] logger.c: -- Executing [myavayaextension@default:1] Dial("SIP/myasteriskextension-081b5bc8", "H323/myavayaextension@Avaya") in new stack
[Nov 28 15:34:09] VERBOSE[10584] logger.c: -- Requested transfer capability: 0x00 - SPEECH
------------------- 64 seconds delay -----------------
[Nov 28 15:35:13] VERBOSE[10584] logger.c: -- Called myavayaextension@Avaya
[Nov 28 15:35:13] VERBOSE[10584] logger.c: -- H323/Avaya-31 is making progress passing it to SIP/myasteriskextension-081b5bc8
[Nov 28 15:35:13] VERBOSE[10584] logger.c: -- H323/Avaya-31 is ringing
[Nov 28 15:35:17] VERBOSE[10584] logger.c: -- H323/Avaya-31 answered SIP/myasteriskextension-081b5bc8
[Nov 28 15:35:18] VERBOSE[10584] logger.c: == Spawn extension (default, myavayaextension, 1) exited non-zero on 'SIP/myasteriskextension-081b5bc8'
[Nov 28 15:19:52] VERBOSE[10551] logger.c: -- Executing [myavayaextension@default:1] Dial("SIP/myasteriskextension-081b5bc8", "H323/myavayaextension@Avaya") in new stack
[Nov 28 15:19:52] DEBUG[10551] chan_h323.c: type=H323, format=8, data=myavayaextension@Avaya.
[Nov 28 15:19:52] DEBUG[10551] chan_h323.c: Extension: myavayaextensionHost: Avaya
[Nov 28 15:19:52] DEBUG[10551] chan_h323.c: Calling to myavayaextension@Avaya on H323/Avaya-30
[Nov 28 15:19:52] VERBOSE[10551] logger.c: -- Requested transfer capability: 0x00 - SPEECH
[Nov 28 15:19:52] DEBUG[10551] chan_h323.c: Placing outgoing call to myavayaextension@192.168.58.216:1720, 101
[Nov 28 15:19:52] VERBOSE[10551] logger.c: -- Making call to myavayaextension@192.168.58.216:1720 without gatekeeper.
[Nov 28 15:19:52] VERBOSE[10551] logger.c: Using 192.168.58.227 for outbound call
------------------- 64 seconds delay -----------------
[Nov 28 15:20:56] VERBOSE[10551] logger.c: == New H.323 Connection created.
[Nov 28 15:20:56] VERBOSE[10551] logger.c: -- root is calling host myavayaextension@192.168.58.216:1720
[Nov 28 15:20:56] VERBOSE[10551] logger.c: -- Call token is ip$localhost/9446
[Nov 28 15:20:56] VERBOSE[10551] logger.c: -- Call reference is 9446
[Nov 28 15:20:56] VERBOSE[10551] logger.c: -- DTMF Payload is [pt=101]
[Nov 28 15:20:56] VERBOSE[10551] logger.c: -- Called myavayaextension@Avaya
Notes:
myasteriskextension
myavayaextension = my 5 digit extension on the avaya pbx.
Subscribe to:
Posts (Atom)