Timeout beim Rauswählen unter Xen

FabianWolter

Neuer User
Mitglied seit
1 Jan 2006
Beiträge
35
Punkte für Reaktionen
0
Punkte
0
Hallo,

ich versuche mISDN unter xen 3.0.2-2 zum Laufen zu bekommen. Im Asterisk steckt eine HFC-Karte, dessen Treiber ohne Fehlermeldungen im Syslog oder auf der Console geladen werden. Die Karte ist für den TE-Mode konfiguriert.

Nun möchte ich über einen SIP-Client ins Festnetz anrufen und bekomme mit aktiviertem Debug folgende Meldungen:

Code:
    -- Executing Set("SIP/11-0819ccd8", "LANGUAGE()=de") in new stack
    -- Executing Set("SIP/11-0819ccd8", "CALLERID(name)=Wolter Tel2") in new stack
    -- Executing Set("SIP/11-0819ccd8", "CALLERID(number)=5105435") in new stack
    -- Executing Dial("SIP/11-0819ccd8", "mISDN/g:group1/5105435|120|TW") in new stack
P[ 0]  --> Group Call group: group1
P[ 1] Group [group1] Port [1]
P[ 1] portup:1
P[ 0]  --> * NEW CHANNEL dad:5105435 oad:(null)
P[ 1]  --> updating channel name to [mISDN/0-u4]
P[ 1] * Queuing chan 0x81a2c38
P[ 1]  --> TON: Unknown
P[ 1]  --> LTON: Unknown
P[ 1]  --> CTON: Unknown
P[ 1] * CALL: g:group1/5105435
P[ 1]  --> * dad:5105435 tech:mISDN/0-u4 ctx:incoming
P[ 1]  --> * adding2newbc ext 5105435
P[ 1]  --> * adding2newbc callerid 5105435
P[ 1] update_config: Getting Config
P[ 1]  --> pres: -1 screen: -1
P[ 1]  --> pres: 0
P[ 1]  --> PRES: Allowed (0x0)
P[ 1]  --> SCREEN: Unscreened (0x0)
P[ 1] NO OPTS GIVEN
P[ 1] I SEND:SETUP oad:5105435 dad:5105435 pid:5
P[ 1]  --> bc_state:BCHAN_CLEANED
P[ 1]  --> channel:0 mode:TE cause:16 ocause:16 rad: cad:
P[ 1]  --> info_dad: onumplan:0 dnumplan:0 rnumplan:0 cpnnumplan:0
P[ 1]  --> caps:Speech pi:0 keypad: sending_complete:0
P[ 1]  --> screen:0 --> pres:0
P[ 1]  --> addr:0 l3id:30003 b_stid:0 layer_id:0
P[ 1]  --> facility:FAC_NONE out_facility:FAC_NONE
P[ 1] --> new_l3id 30004
P[ 1]  --> * SEND: State Dialing pid:5
    -- Called g:group1/5105435
P[ 1] Sending msg, prim:30580 addr:41000104 dinfo:30004
P[ 1] handle_frm: frm->addr:42000103 frm->prim:3ff82
P[ 1] I IND :TIMEOUT oad:5105435 dad:5105435 pid:5 state:CALLING
P[ 1]  --> channel:255 mode:TE cause:16 ocause:16 rad: cad:
P[ 1]  --> info_dad: onumplan:0 dnumplan:0 rnumplan:0 cpnnumplan:0
P[ 1]  --> caps:Speech pi:0 keypad: sending_complete:0
P[ 1]  --> screen:0 --> pres:0
P[ 1]  --> addr:0 l3id:30004 b_stid:0 layer_id:0
P[ 1]  --> facility:FAC_NONE out_facility:FAC_NONE
P[ 1]  --> bc_state:BCHAN_CLEANED
P[ 1] --> state: CALLING
P[ 1] I SEND:DISCONNECT oad:5105435 dad:5105435 pid:5
P[ 1]  --> bc_state:BCHAN_CLEANED
P[ 1]  --> channel:255 mode:TE cause:16 ocause:1 rad: cad:
P[ 1]  --> info_dad: onumplan:0 dnumplan:0 rnumplan:0 cpnnumplan:0
P[ 1]  --> caps:Speech pi:0 keypad: sending_complete:0
P[ 1]  --> screen:0 --> pres:0
P[ 1]  --> addr:0 l3id:30004 b_stid:0 layer_id:0
P[ 1]  --> facility:FAC_NONE out_facility:FAC_NONE
P[ 1] handle_frm: frm->addr:42000103 frm->prim:3f182
P[ 1]  --> lib: RELEASE_CR Ind with l3id:30004
P[ 1]  --> lib: CLEANING UP l3id: 30004
P[ 1] empty_chan_in_stack: 255
P[ 1] $$$ CLEANUP CALLED pid:5
P[ 1] hangup_chan
P[ 1] -> queue_hangup
P[ 1] release_chan: bc with l3id: 30004
P[ 1] * RELEASING CHANNEL pid:5 ctx:incoming dad:5105435 oad:0005105435 state: CALLING
P[ 1]  --> * State Down
P[ 1]  --> Setting AST State to down
P[ 1] Sending msg, prim:34580 addr:41000104 dinfo:30004
  == Everyone is busy/congested at this time (1:0/0/1)
    -- Executing Goto("SIP/11-0819ccd8", "dialStates|CHANUNAVAIL|1") in new stack
    -- Goto (dialStates,CHANUNAVAIL,1)
    -- Executing Set("SIP/11-0819ccd8", "LANGUAGE()=de") in new stack
    -- Executing Congestion("SIP/11-0819ccd8", "") in new stack
  == Spawn extension (dialStates, CHANUNAVAIL, 2) exited non-zero on 'SIP/11-0819ccd8'

Hänge ich parallel zum Asterisk ein Telefon an den S0-Bus, bekomme ich dort ein Freizeichen. (Der Bus kommt von T-Com.)

Ein Layer 1 Problem kann ich daher ausschließen. An einem anderen Asterisk funktionieren Kabel und Karte anstandslos.

Rufe ich aus dem Festnetz den Asterisk an, erscheint auf der Asterisk-Konsole noch nicht einmal bei mISDN-Debuglevel 4 irgendeine Meldung. Wenn ich an den gleichen S0-Bus an dem Asterisk hängt ein Telefon anschließe klingelt dies auch.

Meine misdn.conf sieht folgendermaßen aus:

Code:
[general]
misdn_init=/etc/asterisk/misdn-init.conf
bridging=yes
stop_tone_after_first_digit=yes
dynamic_crypt=no
append_digits2exten=yes

[default]
context=incoming
language=de
nationalprefix=0
internationalprefix=00
rxgain=0
txgain=0
te_choose_channel=no
dialplan=0
hdlc=no
echocancelwhenbridged=no

[group1]
ports=1
msns=*

[edit]Das Problem tritt sowohl mit chan_misdn-0.4.0-rc5 als auch mit chan_misdn-0.3.1-rc23 auf.[/edit]

Hat jemand einen Tipp, was da schief läuft?

Gruß Fabian
 
Zuletzt bearbeitet:
Hallo,

ich hatte die gleichen Probleme mit Xen 3.0.2
die Lösung für mich war ein ein:

Code:
echo Y > /sys/module/pciback/parameters/permissive

Ich hatte noch ein paar weitere Unstimmigkeiten/Auffälligkeiten:
Mein Setup hat ein Athlon 1Ghz mit 512MB RAM und 2 HFC-PCI-Karten. Eine im TE-Modus zur Anbindung an Arcor und eine im NT-Modus für interne ISDN-Telefone.

Ohne XEN:
Wenn ich in der misdn.conf
Code:
bridging=yes
eingestellt habe, so "oopste" mein Kernel regelmäßig.

Mit XEN:
Lief alles Problemlos. Jedoch ist mir aufgefallen, dass die Kernelkonfiguration
Code:
Processor type and features  --->Timer frequency
auf 100Hz eingestellt ist. Wechselte ich diesen Wert auf 250Hz (so wie es auf meiner OHNE-XEN Installation der Fall war) so "oopste" der Kernel wieder fröhlich vor sich hin. Desweiteren war der "oops" so tödlich, dass das ganze XEN-System (dom0 und alle domUs) auch mit abgestürzt sind. (Das hat etwas auf die Stimmung gedrückt, da ich mir von XEN erhoffte, dass lediglich die domU mit der Asterisk Installation abstürzt. Ich könnte mir vorstellen, dass es an der Permissive-Einstellung liegt...)

Da ich meinen Server jetzt komplett auf XEN umgestellt habe ist es mir leider nicht mehr möglich die Timer frequency ohne XEN mit 100Hz zu testen, um zu überprüfen ob die "oopses" dann auch verschwinden. Vielleicht kann das jemand mal durchtesten...


mfg Florian
 
Hey, super! Das war es.

Die Karte arbeitet jetzt sowohl im NT- als auch im TE-Modus.

Zu dem bridging-Problem: So wie ich das verstanden habe bewirkt die Einstellung "bridging=yes", dass die Telefonate hardwaremäßig gebridged werden. Und ich glaube das kann die hfcpci gar nicht.

Gruß Fabian
 
Hi,

ja das genau richtig. Bei der hfc-pci sollte dann das kernel misdn dsp module das bridging übernehmen. Das spart etwas latenzzeit gegenüber dem softwarebridging im kernel...


mfg Florian
 
Das hat auch mal funktioniert.
Ich glaube bis 0.3.0-rc21
Danach kommt es immer zu dem Kernel oooops.
crinch kann aber angeblich nichts machen, weil es anscheinend an den misdn Treiber liegt. Obwohl mich das wundert, weil bis 0.3.0-rc21 hat es auch funktioniert.
 
Ich versuche auch gerade, eine HFC Karte mit mISDN unter Xen zum Laufen zu bekommen (NT-Mode)
Es compiliert und lädt alles nur passiert "nix". Wenn ich bei einem internen Telephon den Hörer abnehme kommt keine Meldung (gleiche Config ohne Xen geht).

Was macht die permissive-Konfiguration und muss ich die in der dom0 oder in der domU eingeben?

@FabianWolter, fheese: Welche Kernelversionen verwendet ihr (dom0 und domU), könnt ihr vielleicht mal die .configs posten?
Welche Version von Asterisk und mISDN und chan_msdn?

lg,
divB

/EDIT: Hab es mit permissive grad probiert, bei mir oopst zaphfc sofort und mISDN geht zwar für ein paar Sekunden aber nach den ersten Sekunden in einem Gespräch oopst auch das :-( :-( Verwenden tu' ich die neuste Xen 3.0.4 in der domU und FedoraCore6 in der dom0.
 
Zuletzt bearbeitet:
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.