Debian und mISDN (gelöst)

[voip-knowledge]

Hallo,
ich bins mal wieder.

Asterisk läuft jetzt ganz gut, jedenfalls nur mit SIP

Was ich möchte:

Eingehende Rufe über ISDN oder SIP
Ausgehende Rufe über ISDN oder SIP

habe eine HFC PCI Karte im Rechner


Was ich bisher gemacht habe:

- Debian 3.1 installiert
- Kernel auf 2.6.x
- Kernel gepached
- alle wichtigen Packete installiert
- Asterisk installiert
- misdn mit Beronet Treibern installiert (habe blöderweise vorher Zaptel installiert, ich hoffe das macht nichts)

Das lief bis auf ein paar Kleinigkeiten ganz gut, die Fehler die während der Installation gemeldet wurden sind behoben. Über SIP kann ich Telefonate in beide Richtungen führen.

Mein Problem:

ISDN funktioniert leider nicht, dazu mal die wichtigsten Dateien:

misdn.conf

[general]
debug=0
method=standard
append_digits2exten=yes
bridging=yes

[default]
context=default
language=en
nationalprefix=0
internationalprefix=00
rxgain=0
txgain=0
dialplan=0

[TEports]
context=outgoing
ports=1
msn=123456

misdn-init

#
# Configuration file for your misdn hardware
#
# Usage: /etc/init.d/misdn-init start|stop|restart|config|scan|help
#

#
# Card Settings
#
# Syntax: card=<number>,<type>[,<option>...]
#
# <number> count your cards beginning with 1
# <type> either 0x1,0x4 or 0x8 for your hfcmulti hardware,
# or the name of your card driver module.
# <option> ulaw - uLaw (instead of aLaw)
# dtmf - enable DTMF detection on all B-channels
# pcm_slave - set PCM bus into slave mode
#
card=1,hfcpci

#
# Port settings
#
# Syntax: <port_type>=<port_number>[,<port_number>...]
#
# <port_type> te_ptp - TE-Mode, PTP
# te_ptmp - TE-Mode, PTMP
# nt_ptp - NT-Mode, PTP
# nt_ptmp - NT-Mode, PTMP
# <port_number> port that should be considered
#
te_ptmp=1

#
# Port Options
#
# Syntax: option=<port_number>,<option>[,<option>...]
#
# <option> master_clock - use master clock for this S/T interface
# (only once per chip, only for HFC 8/4)
# optical - optical (only HFC-E1)
# los - report LOS (only HFC-E1)
# ais - report AIS (only HFC-E1)
# slip - report SLIP (only HFC-E1)
#
#option=1,master_clock
#option=2,ais
#option=3,optical,los,ais,slip

#
# General Options for your hfcmulti hardware
#
# poll=<number>
#
# Only one poll value must be given for all cards.
# Give the number of samples for each fifo process.
# By default 128 is used. Decrease to reduce delay, increase to
# reduce cpu load. If unsure, don't mess with it!!!
# Valid is 32, 64, 128, 256.
#
# pcm=<number>
#
# Give the id of the PCM bus. All PCM busses with the same ID
# are expected to be connected and have equal slots.
# Only one chip of the PCM bus must be master, the others slave.
# -1 means no support of PCM bus.
#
# debug=<number>
#
# Enable debugging (see hfc_multi.h for debug options).
#
poll=64
#pcm=1
debug=0

sip.conf

[general]
context=default
bindport=5060
bindaddr=0.0.0.0
srvlookup=yes

; --------------------------------------------------------------------
;
register => 123456:[email protected]/123456

[123456]
type=peer
username=123456
fromuser=123456
secret=GEHEIM
host=sipgate.de
fromdomain=sipgate.de
insecure=very
canreinvite=no
nat=no
disallow=all
allow=ulaw

[sipgate_de_in]
type=peer
fromdomain=sipgate.de
host=sipgate.de
disallow=all
allow=ulaw
context=ankommend

; --------------------------------------------------------------------
;
; hier kommen die Anmeldekontexte für die SIP Endgeraete 1-2
;

[1]
callerid=Phone 1 <1>
host=dynamic
domain=192.168.0.10
user=1
secret=geheim
type=friend
mailbox=1
nat=no
canreinvite=no

[2]
callerid=Phone 2 <2>
host=dynamic
domain=192.168.2.10
user=2
secret=geheim
type=friend
mailbox=2
nat=no
canreinvite=no

extensions.conf

[general]
static=yes
writeprotect=no

; --------------------------------------------------------------------
; Es hat sich als gute Praxis erwiesen, die Inhalte der Datei
; extensions.conf modular aufzubauen. Diese Praxis wollen
; wir auch hier anwenden
;

[lokal]
; Erreichbarkeit der Nebenstellen 1-2
; untereinander herstellen

exten => _1,1,NoCDR()
exten => _1,n,Dial,SIP/${EXTEN}|55|Ttr

[sipgate_out]
; Diesen Context verwenden wir zum waehlen von abgehenden
; Rufnummern über den Sipgate Account 123456

exten => _0.,1,Dial,SIP/${EXTEN}@123456|45|rt

[outgoing]

exten => _0.,1,Dial(mISDN/1/${EXTEN:1}) ; Für ausgehende Gespräche muß die 0 vorgewählt werden und es wird Port 1 verwendet.


exten => 123456,1,Dial(SIP/1,10,Ttr) ; Eingehende Anrufe auf die MSN 123456 weiterleiten, an den SIP Client mit der Kennung 1
exten => 123456,2,Hangup ; Auflegen, wenn keiner drangeht.

[ankommend]
; alle Anrufe mit einer ID 123456 sollen an das SIP Endgeraet 1
; signalisiert werden

exten => 123456,1,Dial,SIP/1|30|r


; --------------------------------------------------------------------
;
; hier kommt der default-Context, in dem alle Geraete in der
; Grundkonfiguration erstmal laufen.
; Alle Geraete können sich gegenseitig anrufen

[default]
include => lokal
include => sipgate_out
include => outgoing

Im CLI

voip*CLI> misdn show config
Misdn General-Config:
-> VERSION: 0.2.1
-> DEBUG_LEVEL: 0 -> TRACEFILE: not set
-> TRACE_CALLS: false -> TRACE_DIR: /var/log/
-> BRIDGING: yes -> STOP_TONE_AFTER_FIRST_DIGIT: yes
-> APPEND_DIGITS2EXTEN: yes -> L1_INFO_OK: yes
-> CLEAR_L3: no -> DYNAMIC_CRYPT: no
-> CRYPT_PREFIX: not set -> CRYPT_KEYS: not set

[PORT 1]
-> PTP: no -> GROUPNAME: TEports
-> RXGAIN: 0 -> TXGAIN: 0
-> TE_CHOOSE_CHANNEL: no -> CONTEXT: outgoing
-> LANGUAGE: en -> CALLERID:
-> METHOD: standard -> DIALPLAN: 0
-> LOCALDIALPLAN: 0 -> NATIONALPREFIX: 0
-> INTERNATIONALPREFIX: 00 -> PRESENTATION: allowed
-> ALWAYS_IMMEDIATE: no -> IMMEDIATE: no
-> HOLD_ALLOWED: no -> EARLY_BCONNECT: yes
-> USE_CALLINGPRES: yes -> ECHOCANCEL: no
-> ECHOCANCELWHENBRIDGED: no -> ECHOTRAINING: yes
-> CALLINGGROUP: none -> PICKUPGROUP: none
-> MSNs: *

und

voip*CLI> misdn show channels
Chan List: (nil)

Was läuft da falsch?
Ist die Karte richtig installiert?
Muss ich die MSN mit- oder ohne Vorwahl angeben?

Vielen Dank

 

[crich]

Hi,

es macht nichts ob du erst zaptel oder erst mISDN installierst.

Was funktioniert eigentlich nicht mit ISDN ? deine configs sehen soweit OK aus und "misdn show channels" zeigt immer NIL an wenn gerade kein Gespräch läuft => es werden nur aktive calls angezeigt.

"misdn show stacks" zeigt dir ob deine Ports aktiv sind.

PS: der parameter heisst msns nicht msn in der midsn.conf

 

[voip-knowledge]

Hi Christian,

schonmal vielen Dank.

Aslo erstes habe ich jetzt mal aus msn msns gemacht.
Funktioniert leider immer noch nicht. Die MSN muss doch ohne Vorwahl, oder?

wenn ich misdn show stacks eingebe kommt folgendes:

BEGIN STACK_LIST:
* Stack Addr: Port 1 Type TE Prot. PMP L2Link DOWN L1LinkOWN Debug:0

das hört sich doch eigendlich ganz gut an denke ich.

Wenn ich aber jetzt auf mein ISDN Anschluss anrufe kommt nur diese Dame vom Band: "Ihr gewünschter Gesprächspartner ist vorübergehend nicht erreichbar" und so weiter.

Wenn ich raus telefonieren möchte und die 0 vorwähle erscheint folgendes:

Feb 8 12:13:29 WARNING[4976]: chan_sip.c:9532 handle_response_invite: Forbidden - wrong password on authentication for INVITE to '"Phone 1" <sip:[email protected]>;tag=as0dedafd3'
Feb 8 12:13:39 WARNING[5109]: pbx.c:2403 __ast_pbx_run: Timeout, but no rule 't' in context 'default'

Ich will doch über ISDN nicht über SIP?


Ciao

Tobi

 

[crich]

Es sieht so aus als ob dein Kabel nicht korrekt ist .. denn bei show stacks muss zumindest die L1 -> UP sein.

die msn einstellung ist beim rauswählen egal, ich bin aber ziemlich sicher, dass du keine 123456 msn hast, du must hier schon was richtiges eintragen. Im zweifel benutze einfach msns=* ,dann reagiert chan_misdn immer.

Also prüfe bitte deine Verkabelung, der L1 Link muss up sein, sonst wird garnichts funktionieren.

Dein Wählplan enthält 2 mal eine 0-vorwahl extension

 

[voip-knowledge]

Hi,

vielen tausend Dank.

Ich Idiot hab das Kabel falsch angeschlossen. Deshalb gibt es ja das OSI Modell

Eine Frage habe ich aber noch zur Installation:

Muss ich Zaptel und Libri überhaupt installieren, wenn ich mit chan-mISDN arbeite?

Ich hab das noch nicht ganz verstanden.


Vielen Dank nochmal

 

[crich]

nein brauchst du nicht.

 

[ramazz0tti]

moin,

wobei asterisk libpri und zaptel aktuell genug braucht, um erfolgreich zu compiliern, wie ich festgestellt habe.


cu,
*markus*

 

[crich]

hallo ramazotti,

das stimmt nur bedingt. Wenn man eine komplette Neuinstallation auf einer frischen Distribution von Linux macht, dann ist es nicht notwendig zaptel/libpri zu kompilieren.

bei einem Upgrade von einer vorhanden asterisk/zaptel.. installation auf eine neuere macht hingegen schon, denn die neue asterisk erkennt das *ein* zaptel installiert ist und versucht dann chan_zap zu kompilieren, dann wird leider festgestellt, dass zaptel zu alt ist und man solle dieses upgraden....

also prinzipiell nicht notwendig, aber wenn man es sich einmal eingefangen hat, wird mans nicht mehr so schnell los

 

[ramazz0tti]

moin,

hm, aber wenn man die url in http://www.ip-phone-forum.de/showpost.php?p=523091&postcount=4 so anschaut, haengt zaptel doch ziemlich mit misdn zusammen, oder?

btw, um auf die geschichte mit den gebridgten isdn-datenanrufen zurueckzukommen, die problematik besteht wohl bei allen isdn-implementierungen bzw scheitert ganz einfach an der art und weise, wie das durch iax2 geschoben wird (speech mit codec alaw), so das jeder isdn-terminaladapter und wohl auch die isdn-bildtelefone (z.b. t-view 100) die lust verlieren?


cu,
*markus*

 

[crich]

wenn man keine zaptel hardware hat braucht man kein zaptel, das ist ja klar oder?

wenn man allerdings zaptel hardware hat und zwischen dieser und misdn bridging machen will dann braucht man in der tat zaptel.

jedenfalls gibt es zu den datenarufen verschiedene probleme, das hauptproblem ist, das chan_zap und chan_iax2 den datendienst-transport nicht korrekt handhaben, da es hierfür eigentlich auch keinen "richtigen" standardweg gibt.

ich habe aber etwa im kopf wie das ganze etwa funktionieren müsste .. würde aber extrem viel zeit kosten.

 

[ramazz0tti]

moin,

wenn man keine zaptel hardware hat braucht man kein zaptel, das ist ja klar oder?

jo, wahrscheinlich. und manchmal fliesst wasser auch bergab.

ich habe aber etwa im kopf wie das ganze etwa funktionieren müsste .. würde aber extrem viel zeit kosten.

 

[voip-knowledge]

Nachdem mein Asterisk super lief hab ich mir gedacht installier ich ihn nochmals.
Blöderweise schaff ich das aber nicht mehr richtig.

Habe Debian wie folgt installiert:

Kernel 2.6.8
Kernel-Source 2.6.8
Das ganze verlinkt
Asterisk installiert (ohne Probleme)
wenn ich dann die Installation von misdn (beronet) starte kommt folgendes:

cp: reguläre Datei ,,/lib/modules/2.6.8-2-k7/build/include/linux/mISDNif.h" kann nicht angelegt werden: Datei oder Verzeichnis nicht gefunden
make: *** [MISDN_MAKE_MODS] Fehler 1

was ist das denn schon wieder?

Vielen Dank

 

[crich]

du brauchst unter debian noch das header paket, also apt-get install kernel-headers-2.6. ..

aber ich sag dir gleich, dass du mit dem 2.6.8 Kernel nicht das mqueue misdn benutzen kannst, das funzt leider erst ab kernel 2.6.12 so richtig

 

[voip-knowledge]

Ich habe keine Lust mehr ständig neue Kernel unter Debian zu kompilieren
Das ist echt eine nervende Sache.
Kann ich Debian mit dem 2.6.8 Kernel installieren und dann einfach nen Kernel-Source 2.6.15 nehmen, ist das möglich? Wäre ja sehr viel bequemer.

Weil diese Sache mit dem kompletten neu kompilieren nimmt viel Zeit und Nerven in Anspruch.

Vielen Dank für deine schnelle Antwort

Tobi

 

[crich]

hehe .. kann ich verstehen. benutz einfach unser install-misdn.tar.gz das geht auch mit dem 2.6.8 und wir haben echt lange damit gearbeitet. Dafür wirds allerdings kaum noch updates geben.

PS nein du kannst nicht mit einem 2.6.8 kernel einen 2.6.12 source nehmen, das wird nicht gehen.

 

[ramazz0tti]

moin,

welches isn ueberhaupt von dem ganzen gebastel die letzte brauchbare version, die noch nicht beim start von asterisk diese fehlermeldung bringt?

[chan_misdn.so]Feb 20 18:49:18 WARNING[22421]: loader.c:325 __load_resource: /usr/lib/asterisk/modules/chan_misdn.so: undefined symbol: ast_pickup_call
Feb 20 18:49:18 WARNING[22421]: loader.c:499 load_modules: Loading module chan_misdn.so failed!

kernel 2.6.15.4, http://www.beronet.com/download/chan_misdn/unstable/chan_misdn-0.3.0-rc20.tar.gz, asterisk 1.2.4 - oder doch besser so langsam auf vISDN umsteigen?

rc15 hat mit kernel 2.6.15.1 noch ein bisschen getan (zumindest fuern paar stunden, bis es dann abgekackt ist und man manchmal wenigstens mit einem /etc/init.d/misdn-init restart das zeuch wiederbeleben konnte, oft war aber ein komplett-reboot faellig).

edit: 0.3.0-rc15 ist doch die letzte benutzbare version - wofuer sind dann die teile nach rc15?

btw, auf dem produktionssystem die sirrix-treiber laufen stabil seit ich die karte eingebaut habe im dezember letzten jahres und haben eine vollstaendigere euro-isdn-implementation - also sollte sowas in funktionierend und stabil eigentlich kein problem sein ...

 

[crich]

res_features.so muss vor chan_misdn geladen sein! poste mal deine modules.conf.

btw. vISDN sieht nach nem netten Ansatz aus, probiers einfach vielleicht machts dich glücklicher

 

[ramazz0tti]

moin,

res_features.so muss vor chan_misdn geladen sein! poste mal deine modules.conf.

das wurde bis jetzt noch gar nicht explizit in modules.conf geladen, aber du wuerdest daran glauben, wenn es folgendermassen da drin steht, dass es dann auch mit rc20 tut? btw, ein changelog oder so gibts nicht, oder?

[modules]
autoload=yes
noload => pbx_gtkconsole.so
noload => pbx_kdeconsole.so
noload => app_intercom.so
noload => chan_modem.so
noload => res_musiconhold.so
noload => chan_alsa.so
noload => chan_oss.so
load => res_features.so
load => chan_misdn.so
noload => chan_oh323.so
noload => chan_skinny.so
noload => app_dtmftotext.so
[global]
chan_modem.so=no

... vielleicht machts dich glücklicher

richtig gluecklich bin ich auf jeden fall mit der entscheidung, fuer das produktionssystem mich fuer sirrix entschieden zu haben - das war son richtiger gluecksgriff, wenn man so die probleme quer durchs forum mit zappeltel und misdn sieht.

sonst noch richtig stabil und auch am ausgereiftesten ist capi mit aktiven avm-karten, das lief auch jahrelang anstandslos, aber nur amtsseitig, unterstuetzt keinen internen S0-bus. aktive karten von diehl/eicon habe ich leider keine mehr, das war zuletzt unter os/2 mit cfos/capi ...


cu,
*markus*

 

[crich]

nun ja, das ist keine Glaubensfrage denke ich.

Funktioniert es denn ?? oder gibts da noch ein Problem? Ich bin eigentlich eher daran interessiert bestehende Probleme zu beseitigen, deshalb habe ich mich auch hier in dieses Forum eingeklinkt.

 

[ramazz0tti]

moin,

Funktioniert es denn ??

jo, jez tuz tatsaechlich mit rc20, wenn man das so in modules.conf drin hat:

[...]
load => res_features.so
load => chan_misdn.so
[...]

mal sehn, wie lange diesmal, bevor es sich wieder abgenutzt hat und der nexte rebuht faellich wird ...

edit:
also dieser muell kommt immer noch haufenweise bei datenverbindungen ueber misdn am internen S0-bus (X.75 transparent):

kernel: channel_senddata: next_skb exist ERROR (skb->len=64 next_skb->len=64)


cu,
*markus*