[HowTo] Debian Squeeze - Asterisk 1.8.7.2 - mISDNv2 - chan_lcr - mISDN user - Allo ISDN BRI

[martin_g]

Hallo zusammen,

Update: Während ich meine letzte Installation mühsam rekonstruiert habe, habe ich die Lösung auf all meine bisherigen mISDN/chan_lcr/Asterisk Probleme gefunden Nachdem ich eh schon fertig war, möge es Anderen als HowTo dienen

ich würde um Unterstützung bei oben genannter Konstellation bitten. Ich werde meine bisherigen Schwierigkeiten mit aufführen, dass Nachfolgende vielleicht auch Hilfe finden. Ich würde diesen Post weiter pflegen, um ein möglichst umfassendes HowTo für mich und andere zu erstellen. Mein aktuelles Problem ist weiter unten zu finden und ich habe es rot markiert, gelöste Probleme sind grün markiert.

Vielen Dank zwischenzeitlich auch an Sparkie, dessen bisherige Hilfe bei anderen Fragenden, mir auch sehr geholfen hat.

Ausgangslage (jeweils aktuelle Version)

- Debian Squeeze 6.0.3 mit Kernel 2.6.32-5
- Allo.com ISDN-BRI card: http://www.allo.com/isdn-bri-card.html (CB400P)
- mISDN v2: http://git.misdn.eu/?p=mISDN.git;a=commit;h=e027ab8e827399a146293c95356fcda6bf432a3a
- mISDN user: http://git.misdn.eu/?p=mISDNuser.git;a=commit;h=2ca3c00f5aa29eaf9fec74727d24cfe63545e6e7
- chan_lcr: http://git.misdn.eu/?p=lcr.git;a=commit;h=77bacac2bd6eaeb33b280458e0839b772f9ad18c
- Asterisk 1.8.7.2: http://downloads.asterisk.org/pub/telephony/asterisk/releases/asterisk-1.8.7.2.tar.gz

Entscheidungen

- gegen Debian Wheezy, weil ich mir nicht sicher bin, ob der Kernel 3.1 gut mit mISDN funktioniert.
- Asterisk selbst kompilieren, weil es in Squeeze nur die Version 1.6 ohne Longtime Support gibt
- mISDN v2 selbst kompilieren, weil unsere Karte nicht vom Kernel Modul in Squeeze unterstützt wird

Vorbereitung

aptitude install linux-headers-2.6.32-5-686 git autoconf libncurses5-dev build-essentials # diese Liste ist nicht vollständig, beinhaltet nur, was mir auf Anhieb eingefallen ist. Kann ich aber gerne erweitern.
mkdir /usr/local/src/AST/; cd /usr/local/src/AST

 

[martin_g]

mISDN v2

git clone git://git.misdn.eu/mISDN.git/ /usr/local/src/AST/mISDN
cd /usr/local/src/AST/mISDN
./configure
cp mISDN.cfg.default standalone/mISDN.cfg
rm /lib/modules/2.6.32-5-686/extra -rf  # Vorsicht, dass hier keine noch benötigten Nicht-ISDN Module liegen
rm /lib/modules/2.6.32-5-686/kernel/drivers/isdn -rf  # -> mISDN Problem 1
make modules  # -> mISDN Problem 2
make modules-install
lsmod | grep -iE '(isdn|hfc)'  # bereits geladene ISDN Module (in umgekehrter Reihenfolge zum laden unten) mit modprobe -r entladen
depmod -a
modprobe mISDN_core
modprobe hfcmulti   # oder hfcpci, ... (eben der richtige Treiber für die Karte, lspci -v kann helfen)
modprobe mISDN_dsp
modprobe mISDN_dsp_oslec
dmesg  # sollte keine Fehlermeldungen enthalten (z.B. Unknown HFC multiport controller) -> mISDN Problem 3

Bisherige Probleme

mISDN Problem 1: "error: implicit declaration of function ‘flush_work_sync’"
mISDN -> make modules ergab diesen Fehler:

/usr/local/src/AST/mISDN/standalone/drivers/isdn/mISDN/hwchannel.c: In function ‘mISDN_freedchannel’:
/usr/local/src/AST/mISDN/standalone/drivers/isdn/mISDN/hwchannel.c:113: error: implicit declaration of function ‘flush_work_sync’
make[6]: *** [/usr/local/src/AST/mISDN/standalone/drivers/isdn/mISDN/hwchannel.o] Fehler 1

Bei der Aufarbeitung der bisherigen Installation konnte ich den Fehler leider nicht mehr reproduzieren, aber behoben habe ich ihn über eine dieser beiden Möglichkeiten:
- aktuelle Sourcen von git://git.misdn.eu/mISDN.git/ - nicht von der alten Adresse git://git.misdn.org/mISDN.git/
- Löschen des /lib/modules/2.6.32-5-686/kernel/drivers/isdn
Es kann auch sein, dass der Fehler erst auftritt, wenn man die Config vor dem kompilieren kopiert hat.

mISDN Problem 2: "error: storage size of ‘vaf’ isn’t known"
mISDN -> make modules ergibt diesen Fehler:

/usr/local/src/AST/mISDN/standalone/drivers/isdn/mISDN/layer2.c: In function ‘l2m_debug’:
/usr/local/src/AST/mISDN/standalone/drivers/isdn/mISDN/layer2.c:102: error: storage size of ‘vaf’ isn’t known
/usr/local/src/AST/mISDN/standalone/drivers/isdn/mISDN/layer2.c:102: warning: unused variable ‘vaf’

Ursache: mISDN ist entgegen der Aussage (kompatibel seit Kernel 2.6.19) nicht kompatibel zu Kernel 2.6.32, weil ein struct verwendet wird, das erst mit Kernel 2.6.36 eingeführt wurde: http://lxr.free-electrons.com/ident?v=2.6.36;i=va_format
Workaround: Struct in /usr/local/src/AST/mISDN/drivers/isdn/mISDN/layer2.c einfügen (irgendwo am Anfang - in aktueller Version z.B. in Zeile 28)

struct va_format {
	const char *fmt;
	va_list *va;

};

Das sollte vielleicht besser in eine Core Bibliothek eingefügt werden, aber dazu verstehe ich zu wenig von C.

mISDN Problem 3: "dmesg > Unknown HFC multiport controller"
In dmesg fand ich diesen Fehler:

[ 4852.068719] mISDN: HFC-multi driver 2.03
[ 4852.068769] Unknown HFC multiport controller (vendor:1397 device:8b4 subvendor:ffffffff subdevice:ffffffff)
[ 4852.068808] Please contact the driver maintainer for support.

bzw. bei einer vorherigen Version diesen Fehler:

[ 4852.068719] mISDN: HFC-multi driver 2.03
[ 4852.068769] Unknown HFC multiport controller (vendor:1397 device:8b4 subvendor:1397 subdevice:b51a)
[ 4852.068808] Please contact the driver maintainer for support.

Der erste Fehler (ffffffff bei subvendor/-device) liegt meines Erachtens an einem Fehler in mISDN, den ich nicht gesucht habe. Die IDs sind korrekt im EEPROM der Karte eingetragen und eine ältere mISDN Version hat diese auch erkannt, andere im Netz haben den ff Fehler auch z.B. bei Junghanns Karten. Mittels lcpci können auch alle Werte ausgelesen werden:

lspci -v
> 02:01.0 ISDN controller: Cologne Chip Designs GmbH ISDN network Controller [HFC-4S] (rev 01)
>         Subsystem: Cologne Chip Designs GmbH Device b51a
>         Flags: medium devsel, IRQ 11
>         I/O ports at c000 [size=8]
>         Memory at e2201000 (32-bit, non-prefetchable) [size=4K]
>         Capabilities: [40] Power Management version 2
lspci -vn
> 02:01.0 0204: 1397:08b4 (rev 01)
>         Subsystem: 1397:b51a
>         Flags: medium devsel, IRQ 11
>         I/O ports at c000 [size=8]
>         Memory at e2201000 (32-bit, non-prefetchable) [size=4K]
>         Capabilities: [40] Power Management version 2

Nachdem meine Karte in mISDN eh nicht vorhanden ist, habe ich in /usr/local/src/AST/mISDN/drivers/isdn/hardware/mISDN/hfcmulti.c gleich beide Fälle behandelt (Treiber Datei hängt von der Karte ab).
Ans Ende von static const struct hm_map hfcm_map[] habe ich die Konfiguration meiner Karte eingetragen (Index evtl. anzupassen, aktuell war die letzte ID 34). Woher man die Parameter seiner Karte erfahren kann, weiß ich nicht. In meinem Fall habe ich aus alten mISDNv1 Treibern vom Hersteller gelesen, dass es sich bei der Basis um eine "HFC-4S Eval (old)" handelt. Also habe ich deren Parameter verwendet:

/*35*/  {VENDOR_CCD, "HFC-4S (allonet CB400P)", 4, 4, 0, 0, 0, 0, 0, 0},

Dann muss man in static struct pci_device_id hfmultipci_ids[] __devinitdata noch die Erkennungsparameter einfügen ((sub)vendor-/device IDs aus dmesg):

        /* PCI_VENDOR_ID_CCD(0x1397), PCI_DEVICE_ID_CCD_HFC4S(0x08B4), */
        /* regular IDs for this card */
        { PCI_VENDOR_ID_CCD, PCI_DEVICE_ID_CCD_HFC4S, PCI_VENDOR_ID_CCD,
                0xb51a, 0, 0, H(35)}, /* HFC-4S (allonet CB400P) - copy from Old Eval */
        /* wrong IDs by the current mISDN version */
        { PCI_VENDOR_ID_CCD, PCI_DEVICE_ID_CCD_HFC4S, 0xffffffff,
                0xffffffff, 0, 0, H(35)}, /* HFC-4S (allonet CB400P) - copy from Old Eval */

H(35) stellt die Referenz auf die oben eingetragenen Parameter. Wenn dort nicht 35 verwendet wurde, dann ist die Zahl entsprechend anzupassen.
Zu beachten ist natürlich, dass die Stellen in anderen Treibern anders heißen können (werden). Bei Unklarheit vielleicht mal in die hfcmulti.c schauen und dann das Pendant im anderen Treiber suchen.
Das Ergebnis von demsg sollte dann etwa so aussehen:

[ 7599.699795] mISDN: HFC-multi driver 2.03
[ 7599.699848] HFC-multi: card manufacturer: 'Cologne Chip AG' card name: 'HFC-4S (allonet CB400P)' clock: normal
[ 7599.699882] hfc_multi 0000:02:01.0: PCI INT A -> Link[LNKB] -> GSI 9 (level, low) -> IRQ 9
[ 7599.699930] card 0: defined at MEMBASE 0xf8380000 (0xe2201000) IRQ 9 HZ 250 leds-type 0
[ 7599.702050] HFC_multi: detected HFC with chip ID=0xc0 revision=1
[ 7599.716034] controller is PCM bus MASTER (auto detected)
[ 7599.716039] controller has PCM BUS ID 100 (auto selected)
[ 7599.816035] 1 devices registered
[ 7599.825938] DSP modul 2.0
[ 7599.825946] mISDN_dsp: DSP clocks every 64 samples. This equals 2 jiffies.

 

[martin_g]

mISDN user

git clone git://git.misdn.eu/mISDNuser.git/ /usr/local/src/AST/mISDNuser
cd /usr/local/src/AST/mISDNuser
dmesg | grep family # höchstes registriertes Protokoll verwenden, hier 34
### [    5.413249] NET: Registered protocol family 34
./configure --with-AF_ISDN=34
make
make install
misdn _info

Der Output von misdn_info könnte etwa so aussehen:

Found 4 ports
  Port  0 'hfc-4s.1-1':      TE/NT-mode BRI S/T (for phone lines & phones)
                              2 B-channels: 1-2
                                B-protocols: RAW HDLC X75slp L2:DSP L2:DSPHDLC
  --------
  Port  1 'hfc-4s.1-2':      TE/NT-mode BRI S/T (for phone lines & phones)
                              2 B-channels: 1-2
                                B-protocols: RAW HDLC X75slp L2:DSP L2:DSPHDLC
  --------
  Port  2 'hfc-4s.1-3':      TE/NT-mode BRI S/T (for phone lines & phones)
                              2 B-channels: 1-2
                                B-protocols: RAW HDLC X75slp L2:DSP L2:DSPHDLC
  --------
  Port  3 'hfc-4s.1-4':      TE/NT-mode BRI S/T (for phone lines & phones)
                              2 B-channels: 1-2
                                B-protocols: RAW HDLC X75slp L2:DSP L2:DSPHDLC

Bisherige Probleme
- keine -

 

[martin_g]

Asterisk

cd /usr/local/src/AST
wget http://downloads.asterisk.org/pub/telephony/asterisk/releases/asterisk-1.8.7.2.tar.gz
tar -xvzf asterisk-1.8.7.2.tar.gz
cd /usr/local/src/AST/asterisk-1.8.7.2
./configure
# ./contrib/scripts/get_mp3_source.sh  # optional für MP3 Support (vermutlich lizenzrechtliche Gründe)
make menuselect	# -> Asterisk Problem 1
make
make install

Bisherige Probleme

Asterisk Problem 1: "compile-time options"
asterisk -rx 'module show like lcr' zeigt an, dass lcr nicht geladen ist bzw. zeigt es eben gar nicht an. asterisk -rx 'modules load chan_lcr' ergibt folgenden Fehler:

Module 'chan_lcr.so' was not compiled with the same compile-time options as this version of Asterisk.
Module 'chan_lcr.so' will not be initialized as it may cause instability.
Module 'chan_lcr.so' could not be loaded.

Problemlösung: Bei make menuselect muss "Module Embedding -> CHANNELS" ausgewählt werden.

 

[martin_g]

chan_lcr

git clone git://git.misdn.eu/lcr.git/ /usr/local/src/AST/lcr
cd /usr/local/src/AST/lcr
./autogen.sh	# Output differiert; Solange nicht explizit "error" da steht, ist alles gut
./configure --with-asterisk
#CPPFLAGS=-I/usr/local/src/AST/asterisk-1.8.7.2/include ./configure --with-asterisk   # -> chan_lcr Problem 1
make
make install
lcr fork
lcradmin state
lcr query

lcradmin state sollte eine GUI anzeigen und lcr query eine Ausgabe basierend auf misdn_info:

** LCR  Version 1.11

-> Using 'misdn_info'

Found 4 ports
  Port  0 'hfc-4s.1-1':      TE/NT-mode BRI S/T (for phone lines & phones)
                              2 B-channels: 1-2
                                B-protocols: RAW HDLC X75slp L2:DSP L2:DSPHDLC
  --------
  Port  1 'hfc-4s.1-2':      TE/NT-mode BRI S/T (for phone lines & phones)
                              2 B-channels: 1-2
                                B-protocols: RAW HDLC X75slp L2:DSP L2:DSPHDLC
  --------
  Port  2 'hfc-4s.1-3':      TE/NT-mode BRI S/T (for phone lines & phones)
                              2 B-channels: 1-2
                                B-protocols: RAW HDLC X75slp L2:DSP L2:DSPHDLC
  --------
  Port  3 'hfc-4s.1-4':      TE/NT-mode BRI S/T (for phone lines & phones)
                              2 B-channels: 1-2
                                B-protocols: RAW HDLC X75slp L2:DSP L2:DSPHDLC

Bisherige Probleme

chan_lcr Problem 1: "test for header-file asterisk/compiler.h failed"
./configure --with-asterisk ergab bei mir immer diesen Fehler:

checking asterisk/compiler.h usability... no
checking asterisk/compiler.h presence... no
checking for asterisk/compiler.h... no
configure: error: in `/usr/local/src/AST/lcr':
configure: error: --with-asterisk was given, but test for header-file asterisk/compiler.h failed

Ursache: die Asterisk Sourcen werden nicht gefunden.
Lösung: Die Sourcen als zusätzlichen Include Path mit angeben (CPPFLAGS=-I/usr/local/src/AST/asterisk-1.8.7.2/include ./configure --with-asterisk)

chan_lcr Problem 2: "error: No ast_tone_zone_sound, confused..."
Nach Problem 1 tritt dieser Fehler auf:

checking for struct tone_zone_sound in asterisk/indications.h... no
checking for struct ast_tone_zone_sound in asterisk/indications.h... no
configure: error: in `/usr/local/src/AST/lcr':
configure: error: No ast_tone_zone_sound, confused...

Workaround: Asterisk einmal kompilieren (bis einschlißlich make; make install ist nicht erforderlich), die Einstellungen sind dabei relativ egal, weil er später sowieso nochmal kompiliert werden muss. Wie man das richtig lösen kann, weiß ich leider nicht. Vorschläge?
Man findet im Netz zwar einen Patch, der sich mit diesem tone_zone Problem beschäftigt, aber der ist von einem Mitautor von chan_lcr und wieso der dann scheinbar nicht in die aktuelle Source eingeplfegt ist, verstehe ich nicht. http://git.misdn.org/?p=lcr.git;a=commitdiff_plain;h=13f107bc240d351b1eb1915eff140efe1b4a95bb
tone_zone_sound wurde scheinbar bei einer alten Asterisk Version verwendet und die Abfrage ist aus Kompatibilitätsgründen drin.
Hier gibt es noch die Erklärung, dass #ifdef verwendet wird, um zu entscheiden, welche tone_zone verwendet werden soll. Und dass das vom Präprozessor nicht verstanden wird: http://comments.gmane.org/gmane.linux.isdn.i4l.user/5085
Dann verstehe ich allerdings nicht, wieso er bei beiden Alternative 'no' sagt. Mit dem Workaround sieht es dann so aus:

checking for struct tone_zone_sound in asterisk/indications.h... no
checking for struct ast_tone_zone_sound in asterisk/indications.h... yes
checking for struct ast_party_caller in asterisk/channel.h... yes

Und configure läuft durch.

 

[martin_g]

Run-Skripte

Run Skripte für mISDN Treiber laden, sowie für lcr werden über das mitgelieferte genrc erstellt und mittels Debians rcconf beim Systemstart geladen (aptitude install rcconf)

 

[martin_g]

Konfiguration und Tests

asterisk -r
module load chan_lcr

 

[sparkie]

Nachdem ich eh schon fertig war, möge es Anderen als HowTo dienen

WOW! Klasse, sowas hat hier schon lange gefehlt, man merkt es wird doch bald Weihnachten

ich würde um Unterstützung bei oben genannter Konstellation bitten.

klar gerne. Ich habe inzwischen ebenfalls auf eine 4-Port ISDN (HFC-4S) hochgeruestet. Leider bin ich softwaretechnisch mittlerweile etwas hintendran, da alles ja problemlos laeuft. Aber wie heisst es so schoen: Ein Rechner der stabil laeuft ist veraltet

Mein aktuelles Problem ist weiter unten zu finden und ich habe es rot markiert, gelöste Probleme sind grün markiert.

ich finde aber gar keine roten Markierungen ohne beschriebene Loesung mehr - heisst dass du alles bereits gefixt hast?

- sparkie

UPDATE:
ich sehe gerade, das 'ast_tone_zone_sound' Problem hast du wohl noch nicht gefixt Ich hatte in meiner alten Version auch mal ein Problem damit. Ich bin es einfach so

--- chan_lcr.c  2010-05-31 18:27:26.000000000 +0200
+++ /root/chan_lcr.c    2010-06-13 13:46:13.000000000 +0200
@@ -2247,7 +2247,7 @@
        union parameter newparam;
         int res = 0;
         struct chan_call *call;
-       const struct tone_zone_sound *ts = NULL;
+       const struct ast_tone_zone_sound *ts = NULL;
 
        ast_mutex_lock(&chan_lock);
         call = ast->tech_pvt;

umgangen. Ob das hier auch was nuetzt kann ich leider nicht sagen.

 

[martin_g]

Hi,

Keine Probleme mehr. Wieso ich überhaupt um Hilfe ersucht hatte, war der Fehler mit den Compile Time Options. Dem war ich bei unserem letzten Versuch nur durch generelles Abschalten der Prüfung in der loader.c von Asterisk Herr geworden. Und das sollte ja keine Dauerlösung sein.
Die Lösung (erst Asterisk, dann lcr kompilieren) hatte ich aber bei der Aufarbeitung gefunden. Die orangen Dinge sind Workarounds, die sich aber dadurch erübrigt haben (siehe Zitatkommentar).

Wir hatten zwischendrin zwar immer wieder mal abwechselnd kompiliert, aber entweder waren irgendwo noch Reste oder wir hatten es schon in funktionstüchtigem Zustand und haben es nicht bemerkt.

Die Quintessenz ist also, dass es hauptsächlich auf die Reihenfolge oben ankommt. Meine Fehler hatte ich aufgeführt, weil ich die öfters gefunden habe, aber kaum Lösungsansätze.

Viele Grüße
Martin

 

[sparkie]

wir hatten es schon in funktionstüchtigem Zustand und haben es nicht bemerkt.

stimmt. Am laengsten suche ich immer nach den Fehlern, die gar nicht (mehr) vorhanden sind

Die Quintessenz ist also, dass es hauptsächlich auf die Reihenfolge oben ankommt.

zum Vergleich habe ich mein eigenes build script mal in den Anhang kopiert. Vielleicht laesst sich das eine oder andere daraus noch recyclen. Mich hat es immer genervt, dass sich der asterisk quer ueber's System installiert. Darum installiere ich zuerst immer in ein blindes directory, um die Filenamen fuer den echten install daraus abzuleiten. Bei Bedarf kann ich dann mit einem einzigen 'rm' den ganzen Kram wieder entfernen.

vielleicht kann's wer gebrauchen.

- sparkie

Anhang anzeigen build_ast.txt

 

[sparkie]

einen Vorschlag fuer moegliche Hardware gibt's hier:
Hardwarevorschlag 4-port ISDN/SIP Gateway

 

[martin_g]

Ah okay, Du installierst Asterisk also ganz am Anfang. Okay, wenn ich das gewusst hätte, hätten wir uns bissl Ärger gespart Wir hatten bisher noch kein chan_lcr verwendet und dachten eigentlich, dass Teile davon in den Asterisk mit hinein kompiliert werden müssen. Vielleicht mache ich nochmal eine Kurzvariante der Installation ohne die Fehlerbehandlung. Übersichtlichlich ist das so nicht

 

[martin_g]

habe ja alles soweit am laufen

nur lcr startet nicht nach reboot

und in lcr und asterisk

die routing .conf

interface .conf und

etensions.conf in asterisk
keine ahnung

hast du da mal einen rastschlag

Bitte hier behandeln, dann haben andere auch was davon.

>> lcr startet nicht nach reboot
1. Funktioniert LCR denn überhaupt?
=> lcr fork und lcr query sollte eine Info von mISDN ausgeben.
2. Hast Du schon ein Run Skript erstellt?
=> genrc
3. Funktioniert das Runskript?
=> Erstmal den vorher gestarteten lcr Prozess killen (killall lcr), dann starten /etc/init.d/lcr start und testen: lcr query
4. Das Runskript liegt da ja quasi nur - wenn Du es bei Systemstart ausführen willst, dann muss es auch so verlinkt werden. Entweder mit ln -s nach /etc/rc2.d oder einfacher mit rcconf (aptitude install rcconf). Ob ein Link besteht kannst auch nachschauen (ls -l /etc/rc2.d | grep lcr)
5. Nach dem Reboot sollte lcr da sein
=> lcr query

>> interface .conf und
Das einfachste ist erstmal zu testen, ob Anrufe von draußen überhaupt bei LCR und Asterisk ankommen. Dazu nur diese Sektion in die interface.conf eintragen und das NTBA an den ersten Port der Karte anschließen
[Ext1]
portnum 0
ptp
nodtmf


>> die routing .conf
Die passende Testconfig (erstmal alles an Asterisk weitergeben) sieht so aus:
[main]
default : remote application=asterisk

Danach lcr neu starten, um die Konfig zu aktualisieren /etc/init.d/lcr restart

Dann mal auf einer ISDN Nummer anrufen. Es sollte was zu sehen sein unter lcradmin state. Wenn es dort passt, im Asterisk weiter schauen: asterisk -r > core set verbose. Es sollte jetzt auch der Incomig Call zu sehen sein.

Wenn das nicht funktioniert, dann bitte genauere Infos (läuft das lcr Modul? asterisk -r > module show like lcr).

Die extension.conf ist erstmal zweitrangig. Wichtig ist, dass der Call überhaupt reinkommt. Was danach ist, eigentlich Standard Asterisk Konfiguration (bis auf so Sachen wie Wählregeln, aber wie gesagt, das ist erst der nächste Step).

 

[sparkie]

vielleicht sollte man hier noch die Einbindung von asterisk/lcr in die debian squeeze Basis genauer beschreiben. Nachfolgend ein paar Konfigurationsbeispiele, so wie ich sie am Laufen habe:

Kannst du sowas mal posten

/usr/local/lcr/routing.conf

[main]
                : remote application=asterisk

/usr/local/lcr/interface.conf

[s0-external1]
portname hfc-4s.1-1

screen-in national % 0%
screen-in international % 00%

[s0-external2]
portname hfc-4s.1-2

[s0-external3]
portname hfc-4s.1-3

screen-in national % 0%
screen-in international % 00%

[s0-internal1]
portname hfc-4s.1-4
nt

/etc/asterisk/sip.conf

[general]
context=sip-in 
bindport=5060
bindaddr=0.0.0.0
qualify=no
disallow=all
allow=alaw
allow=ulaw
allow=g729
allow=gsm
allow=slinear
srvlookup=yes
;directmedia=yes

register => xxxxxxxxx:[email protected]/xxxxxxxxx
register => yyyyyyyyyyyy:[email protected]/yyyyyyyyyyyy
register => zzzzzzzzzzzz:[email protected]/zzzzzzzzzzzz

[sipgate-ddd0] ; for calling only
type=friend             
insecure=invite
nat=yes
defaultuser=xxxxxxxxx
fromuser=xxxxxxxxx
fromdomain=sipgate.de   
secret=aaaaaa 
host=sipgate.de         
qualify=yes
;canreinvite=no
dtmfmode=rfc2833

[ziilit-ddd0] ; for calling only
type=friend             
insecure=invite
nat=yes
defaultuser=zzzzzzzzzzzz
fromuser=zzzzzzzzzzzz
fromdomain=sip.ziil-it.de
secret=cccccccccccc 
host=sip.ziil-it.de
qualify=yes
;canreinvite=no
dtmfmode=rfc2833

[dusnet-ddd0] ; for calling only
type=friend
insecure=invite
nat=yes
defaultuser=yyyyyyyyyyyy
fromuser=yyyyyyyyyyyy
fromdomain=dus.net
secret=bbbbbbbb 
host=proxy.dus.net
qualify=yes
;canreinvite=no
dtmfmode=rfc2833

extensions.conf macht keinen Sinn hier zu posten, da ich mir ueber AGI ein Interface zu AWK gebaut habe. Meine Dialplaene bestehen praktisch zu 95% nur aus awk scripten, weil ich die Originalsprache der extensions.conf nicht leiden kann. Weil:

Das wofuer ich im AWK 1 Zeile benoetige, erfordert in der original extensions.conf ungefaehr 10 Zeilen

/etc/rc2.d/S19lcr - /etc/init.d/lcr

#! /bin/sh

### BEGIN INIT INFO
# Provides:          lcr
# Required-Start:    $syslog $remote_fs
# Required-Stop:     $syslog $remote_fs
# Default-Start:     2
# Default-Stop:      0 1 3 4 5 6
# Description:       linux call router launch
### END INIT INFO

. /lib/lsb/init-functions

[ -f /etc/default/rcS ] && . /etc/default/rcS
PATH=/bin:/usr/bin:/sbin:/usr/sbin
DAEMON=/usr/local/sbin/lcr
DESC="linux call router daemon"
NAME="lcr"
PIDFILE=/var/run/lcr.pid

test -x $DAEMON || exit 0

case "$1" in
  start)
        log_daemon_msg "Starting $DESC" "$NAME"

        # see genrc for std opts [ /usr/local/lcr/mISDN ]
        modprobe mISDN_core debug=0x1
        modprobe mISDN_dsp debug=0x1 options=0x0
        modprobe mISDN_dsp_oslec
#       modprobe hfcpci debug=0x1
#       modprobe hfcsusb debug=0x1
        modprobe hfcmulti debug=0x1

        sleep 1
        start-stop-daemon --start --background --pidfile $PIDFILE --make-pidfile --startas $DAEMON -- start

        log_end_msg $?
        ;;
  stop)
        log_daemon_msg "Stopping $DESC" "$NAME"

        start-stop-daemon --stop --pidfile $PIDFILE 
        rm -f $PIDFILE

        # NOT NOW
#       rmmod hfcsusb
#       rmmod hfcpci
#       rmmod mISDN_dsp_oslec
#       rmmod mISDN_dsp
#       rmmod mISDN_core

        log_end_msg $?
        ;;
  restart)
        log_daemon_msg "Restarting $DESC" "$NAME"
        log_end_msg $?
        $0 stop
        sleep 1
        $0 start
        ;;
  *)
        log_success_msg "Usage: $0 {start|stop|restart}"
        exit 1
        ;;
esac

exit 0

/etc/rc2.d/S20asterisk - /etc/init.d/asterisk

#!/bin/sh

### BEGIN INIT INFO
# Provides:        asterisk
# Required-Start:  $syslog $remote_fs lcr
# Required-Stop:   $syslog $remote_fs
# Default-Start:   2 
# Default-Stop:    0 1 3 4 5 6
# Description:     asterisk PBX launch
### END INIT INFO

. /lib/lsb/init-functions

[ -f /etc/default/rcS ] && . /etc/default/rcS
PATH=/bin:/usr/bin:/sbin:/usr/sbin
DAEMON=/usr/sbin/asterisk
DESC="PBX daemon"
NAME="asterisk"
PIDFILE=/var/run/asterisk/asterisk.pid

test -x $DAEMON || exit 0

case "$1" in
    start)
        log_daemon_msg "Starting $DESC" "$NAME"

        start-stop-daemon --start --pidfile $PIDFILE --exec $DAEMON 

        log_end_msg $?
        ;;
    stop)
        log_daemon_msg "Stopping $DESC" "$NAME"

        start-stop-daemon --stop --pidfile $PIDFILE 
#       rm -f $PIDFILE
#       $DAEMON -rx 'stop now'

        log_end_msg $?
        ;;
  restart)
        log_daemon_msg "Restarting $DESC" "$NAME"
        log_end_msg $?
        $0 stop
        sleep 1
        $0 start
        ;;
  *)
        log_success_msg "Usage: /etc/init.d/asterisk {start|stop|restart}"
        exit 1
        ;;
esac         

exit 0

diese Beispiele geben nur wieder wie ich es auf meinem System erfolgreich konfiguriert habe. Es ist gut moeglich dass ich hier und dort gegen irgendwelche 'policies' aka 'Regeln des guten Geschmacks' verstosse

- sparkie

 

[ichego1]

Habe dazu noch eine Frage ?
SIP-LCR-Asterisk Asterisk-Lcr-Sip
Klappt bei euch die DTMF Übertragung vom Asterisk und zum Asterisk ohne Probleme ?

 

[martin_g]

Ich habe es noch nicht getestet, glaube aber nicht, dass es Schwierigkeiten macht. In meinem Beispiel mußt Du in der interface.conf natürlich das 'nodtmf' weglassen.

 

[sparkie]

Klappt bei euch die DTMF Übertragung vom Asterisk und zum Asterisk ohne Probleme ?

habe gerade zufaellig was gefunden. Vielleicht ist das der Fix:

Fix: Asterisk DTMF detection works now

[Git] LCR - Linux Call Router branch

ich komme in naechster Zeit leider nicht dazu es auszuprobieren...

 

[Mona]

Erstmal vielen Dank an alle für die tolle Arbeit und die vielen Hilfestellungen.

Ich will mich ja auch gar nicht (mehr) darüber aufregen, warum man aus einem stabilen, schnellen und einfachen Szenario (asterisk+mISDN1) ein vergleichsweise schlecht dokumentiertes, kompliziertes und aufwendiges (asterisk+lcr+mISDNv2) gemacht hat. Es ist eben, wie es ist....

Nach Tagen des kompilierens, lesens, vergleichens, neu installierens, noch mal probierens bin ich soweit gekommen, dass alles anscheinend fehlerfrei installiert ist.

Mit der neusten git-Version von lcr lief das configure nicht durch, aber durch das Auskommentieren der beiden Zeilen

#PKG_CHECK_MODULES(OPENCORE_AMRNB, opencore-amrnb >= 0.1.0, , found_opencore_amrnb=no)
#PKG_CHECK_MODULES(SOFIA, sofia-sip-ua >= 1.12)

lief "./configure" durch. Ich habe keine Ahnung, was die beiden Zeilen machen, hoffe der Fehler liegt nicht daran.

Asterisk (1.8.20.1) läuft: Connected to Asterisk 1.8.20.1 currently running on io (pid = 1781)
lcr läuft: lcr PBX is running: 2212

mISDN läuft:

lsmod | grep -iE '(isdn|hfc)'
hfcmulti               54902  10
mISDN_dsp             190877  0
mISDN_core             69403  19 hfcmulti,mISDN_dsp

module chan_lcr ist geladen:

*CLI> module show like chan_lcr.so
Module                         Description                              Use Count
chan_lcr.so                    Channel driver for Linux-Call-Router Sup 0
1 modules loaded

Wenn ich aber nun, wie es in allen Anleitungen steht, bei /etc/lcr/routing.conf eintrage

[main]
                : remote application=asterisk

und lcr anschließend neu starte, bricht lcr mit einer Fehlermeldung ab:

Restarting lcr PBX: lcrLCR: Signal received: 15
LCR terminated

** LCR  Version 1.14

While parsing /etc/lcr/routing.conf, an error occurred in line 2:
->                 : remote application=asterisk
                           ^
Unknown action name 'remote'.
 failed!

Hat sich da die Syntax mal wieder geändert? Ich kann zu der Fehlermeldung leider keinerlei Hinweise finden....

 

[martin_g]

Probier es erstmal so:

>> die routing .conf
Die passende Testconfig (erstmal alles an Asterisk weitergeben) sieht so aus:
[main]
default : remote application=asterisk

 

[Mona]

Hat leider nichts gebracht, gleiche Fehlermeldung:

/etc/init.d/lcr start

** LCR  Version 1.14

While parsing /etc/lcr/routing.conf, an error occurred in line 2:
-> default : remote application=asterisk
                   ^
Unknown action name 'remote'.

Wenn ich die Fehlermeldung richtig interpretiere, kann er mit "remote" nichts anfangen