[gelöst] Asterisk 1.4/1.6 + kernel 2.6.26 + Debian lenny + mISDN v2 oder mISDN v1

unlimitopen · 4 Nov 2008

perfekt, lag tatsächlich an der Version 1.2... Thanks -

Habe aber nun das problem sobald ich einen anruf annehme - legt anscheinend der lcr / asterisk auf -

Zur Anmerkung: ich kann max. 3 mal durchklingeln lassen, dann wird mir auf dem Handy mitgeteilt - das der Anrufer nicht erreichbar wäre.

extensions.conf

Code:

[Int]
exten => 0,1,Dial(LCR/Int/${EXTEN:1})
exten => _0.,1,Dial(LCR/Int/${EXTEN:1})
exten => 123456,1,Dial(SIP/2000)

Live Log - Asterisk

Code:

*CLI> [Nov  4 23:42:20] NOTICE[17059]: chan_lcr.c:1171 receive_message: [call=NULL ast=NULL] Received new ref by LCR, due to incomming call. (ref=2)
[Nov  4 23:42:20] NOTICE[17059]: chan_lcr.c:281 alloc_call: [call=0 ast=NULL] Call instance allocated.
[Nov  4 23:42:20] NOTICE[17059]: chan_lcr.c:744 lcr_in_setup: [call=2 ast=NULL] Incomming setup from LCR. (callerid 1774137722, dialing 123456)
[Nov  4 23:42:20] NOTICE[17059]: chan_lcr.c:654 lcr_start_pbx: [call=2 ast=lcr/5] Try to start pbx. (exten=123456 context=Int complete=no)
[Nov  4 23:42:20] NOTICE[17059]: chan_lcr.c:319 send_message: [call=NULL ast=NULL] Sending MESSAGE_OVERLAP to socket.
[Nov  4 23:42:20] NOTICE[17059]: chan_lcr.c:695 lcr_start_pbx: [call=2 ast=lcr/5] Extensions matches.
[Nov  4 23:42:20] NOTICE[17059]: chan_lcr.c:726 lcr_start_pbx: [call=2 ast=lcr/5] Starting call to Asterisk due to matching extension.
    -- Executing [123456@Int:1] Dial("lcr/5", "SIP/2000") in new stack
    -- Called 2000
    -- SIP/2000-0a04bc70 is ringing
[Nov  4 23:42:20] NOTICE[17166]: chan_lcr.c:2090 lcr_indicate: [call=2 ast=lcr/5] Received indicate AST_CONTROL_RINGING from Asterisk.
[Nov  4 23:42:20] NOTICE[17166]: chan_lcr.c:319 send_message: [call=NULL ast=NULL] Sending MESSAGE_ALERTING to socket.
    -- ast_get_srv: SRV lookup for '_sip._udp.sipgate.de' mapped to host sipgate.de, port 5060
    -- SIP/2000-0a04bc70 answered lcr/5
[Nov  4 23:42:38] NOTICE[17166]: chan_lcr.c:2103 lcr_indicate: [call=2 ast=lcr/5] Received indicate -1.
[Nov  4 23:42:38] NOTICE[17166]: chan_lcr.c:1886 lcr_answer: [call=2 ast=lcr/5] Received answer from Asterisk (maybe during lcr_bridge).
[Nov  4 23:42:38] NOTICE[17166]: chan_lcr.c:319 send_message: [call=NULL ast=NULL] Sending MESSAGE_CONNECT to socket.
[Nov  4 23:42:38] NOTICE[17166]: chan_lcr.c:1901 lcr_answer: [call=2 ast=lcr/5] Requesting B-channel.
[Nov  4 23:42:38] NOTICE[17166]: chan_lcr.c:319 send_message: [call=NULL ast=NULL] Sending MESSAGE_BCHANNEL to socket.
[Nov  4 23:42:38] ERROR[17166]: chan_lcr.c:2139 lcr_indicate: [call=2 ast=lcr/5] Received indicate from Asterisk with unknown condition 20.
[Nov  4 23:42:38] NOTICE[17059]: chan_lcr.c:1076 receive_message: [call=NULL ast=NULL] Received BCHANNEL_ASSIGN message. (handle=00000001) for ref 2
[Nov  4 23:42:38] NOTICE[17059]: bchannel.c:133 bchannel_create: [call=2 ast=NULL] Open DSP audio
[Nov  4 23:42:38] NOTICE[17059]: bchannel.c:190 bchannel_activate: [call=2 ast=NULL] Activating B-channel.
[Nov  4 23:42:38] NOTICE[17059]: chan_lcr.c:319 send_message: [call=NULL ast=NULL] Sending MESSAGE_BCHANNEL to socket.
[Nov  4 23:42:38] NOTICE[17059]: bchannel.c:602 bchannel_handle: [call=2 ast=NULL] DL_ESTABLISH confirm: bchannel is now activated (socket 30).
[Nov  4 23:42:38] NOTICE[17059]: bchannel.c:82 ph_control: [call=NULL ast=NULL] Sending PH_CONTROL DSP-TX_DEJITTER 240f,0
[Nov  4 23:42:38] NOTICE[17059]: bchannel.c:82 ph_control: [call=NULL ast=NULL] Sending PH_CONTROL DSP-DTMF 2100,0
[Nov  4 23:43:00] ERROR[17166]: chan_lcr.c:2139 lcr_indicate: [call=2 ast=lcr/5] Received indicate from Asterisk with unknown condition 20.
  == Spawn extension (Int, 123456, 1) exited non-zero on 'lcr/5'
[Nov  4 23:43:00] NOTICE[17166]: chan_lcr.c:1935 lcr_hangup: [call=2 ast=lcr/5] Received hangup from Asterisk thread.
[Nov  4 23:43:00] NOTICE[17166]: chan_lcr.c:1945 lcr_hangup: [call=2 ast=lcr/5] Releasing ref and freeing call instance.
[Nov  4 23:43:00] NOTICE[17166]: chan_lcr.c:319 send_message: [call=NULL ast=NULL] Sending MESSAGE_BCHANNEL to socket.
[Nov  4 23:43:00] NOTICE[17166]: chan_lcr.c:319 send_message: [call=NULL ast=NULL] Sending MESSAGE_RELEASE to socket.
[Nov  4 23:43:00] NOTICE[17166]: chan_lcr.c:256 free_call: [call=2 ast=NULL] Call instance freed.
[Nov  4 23:43:00] NOTICE[17059]: bchannel.c:363 bchannel_receive: [call=NULL ast=NULL] ignoring data, because no call associated with bchannel
[Nov  4 23:43:00] NOTICE[17059]: bchannel.c:363 bchannel_receive: [call=NULL ast=NULL] ignoring data, because no call associated with bchannel
[Nov  4 23:43:00] NOTICE[17059]: chan_lcr.c:1143 receive_message: [call=NULL ast=NULL] Received BCHANNEL_REMOVE message. (handle=00000001)
[Nov  4 23:43:00] NOTICE[17059]: chan_lcr.c:319 send_message: [call=NULL ast=NULL] Sending MESSAGE_BCHANNEL to socket.

/usr/local/lcr/interfaces.conf

Code:

[Int]
portnum 0
te-special

Es wäre echt super wenn ihr nochmals mir einen Tipp geben könntet. Ich lese gerade mir die Doku nochmals durch.

gongbuster · 5 Nov 2008

moin,

also ich bin nicht der große extensions.conf-experte, aber versuch mal, die ersten 2 zeilen rauszunehmen. so erzeugst du nen loop?

was genau macht te-special in der interfaces.conf? hab ich nur "portnum 0" drinne stehen...

grüße
sven

gongbuster · 5 Nov 2008

moin,

ok, der letzte commit von gestern im lcr hat offensichtlich einiges durcheinander gehauen. habe heute mal die aktuellste version gezogen, danach konnte ich nicht mehr telefonieren / angerufen werden. also:

git-revert efc550418c0b107c07818809a3d8e779e476dcd4

dann neu kompilieren und es sollte besser klappen mit dem can_lcr...

viele grüße
sven

unlimitopen · 5 Nov 2008

Jo, das war gestern Nacht etwas zu spät

Hallo Zusammen,

jawoll das war ein Fehler von mir!
Aber Jetzt bekomme ich wie andere zwar Anrufe mit folgende Syslog Meldungen

Code:

Nov  5 21:05:50 testdebian kernel: [  576.324374] DSP modul 2.0
Nov  5 21:05:50 testdebian kernel: [  576.324374] mISDN_dsp: DSP clocks every 64 samples. This equals 2 jiffies.
Nov  5 21:06:23 testdebian kernel: [  609.588620] base_sock_release(d7d531e0) sk=de8db600
Nov  5 21:06:23 testdebian kernel: [  609.588620] base_sock_release(d7d537e0) sk=de8dc000
Nov  5 21:06:24 testdebian kernel: [  609.849213] base_sock_release(d7d53c60) sk=de8dc000
Nov  5 21:06:24 testdebian kernel: [  609.849240] init_card: entered
Nov  5 21:06:24 testdebian kernel: [  609.849254] reset_hfcpci: entered
Nov  5 21:06:24 testdebian kernel: [  609.849257] HFC_PCI: resetting HFC ChipId(30)
Nov  5 21:06:24 testdebian kernel: [  609.849263] HFC-PCI status(4) before reset
Nov  5 21:06:24 testdebian kernel: [  609.852008] HFC-PCI status(2) after reset
Nov  5 21:06:24 testdebian kernel: [  609.852008] HFC-PCI status(4) after 5us
Nov  5 21:06:24 testdebian kernel: [  609.852008] inithfcpci: entered
Nov  5 21:06:24 testdebian kernel: [  609.936028] HFC PCI: IRQ 5 count 33
Nov  5 21:06:24 testdebian kernel: [  609.936039] create_l2entity: ret 1 0
Nov  5 21:06:24 testdebian kernel: [  609.936050] create_l2entity: ret 2 0
Nov  5 21:09:43 testdebian kernel: [  809.310462] ------------[ cut here ]------------
Nov  5 21:09:43 testdebian kernel: [  809.310462] WARNING: at kernel/softirq.c:141 local_bh_enable+0x27/0x71()
Nov  5 21:09:43 testdebian kernel: [  809.310462] Modules linked in: mISDN_dsp nls_utf8 isofs zlib_inflate udf nls_base crc_itu_t radeon drm ipv6 ppdev lp video output ac battery cpufreq_conservative cpufreq_powersave cpufreq_ondemand cpufreq_stats freq_table cpufreq_userspace loop parport_pc parport psmouse serio_raw hfcpci mISDN_core button i2c_sis96x i2c_sis630 shpchp pci_hotplug i2c_core sis_agp agpgart evdev ext3 jbd mbcache ide_cd_mod cdrom ide_disk sis5513 ide_pci_generic ide_core 8139too floppy ata_generic 8139cp mii libata scsi_mod dock ohci_hcd usbcore thermal processor fan thermal_sys
Nov  5 21:09:43 testdebian kernel: [  809.310462] Pid: 1221, comm: mISDN_hfc-pci.1 Not tainted 2.6.26-1-686 #1
Nov  5 21:09:43 testdebian kernel: [  809.310462]  [<c012242b>] warn_on_slowpath+0x40/0x66
Nov  5 21:09:43 testdebian kernel: [  809.310462]  [<c0135eec>] getnstimeofday+0x37/0xbc
Nov  5 21:09:43 testdebian kernel: [  809.310462]  [<c0134362>] ktime_get_ts+0x22/0x49
Nov  5 21:09:43 testdebian kernel: [  809.310462]  [<c0134396>] ktime_get+0xd/0x21
Nov  5 21:09:43 testdebian kernel: [  809.310462]  [<c0119081>] hrtick_start_fair+0xeb/0x12c
Nov  5 21:09:43 testdebian kernel: [  809.310462]  [<c0118bd8>] wakeup_preempt_entity+0x2e/0x45
Nov  5 21:09:43 testdebian kernel: [  809.310462]  [<c011fc07>] check_preempt_wakeup+0xa2/0xc2
Nov  5 21:09:43 testdebian kernel: [  809.310462]  [<c01df904>] rb_insert_color+0x8c/0xad
Nov  5 21:09:43 testdebian kernel: [  809.310462]  [<c0133c2e>] enqueue_hrtimer+0xc9/0xd4
Nov  5 21:09:43 testdebian kernel: [  809.310462]  [<c01266c3>] local_bh_enable+0x27/0x71
Nov  5 21:09:43 testdebian kernel: [  809.310462]  [<c0261b68>] sk_filter+0x63/0x6b
Nov  5 21:09:43 testdebian kernel: [  809.310462]  [<c02514bc>] sock_queue_rcv_skb+0x26/0xb1
Nov  5 21:09:43 testdebian kernel: [  809.310462]  [<e0a9bf68>] l2_got_ui+0x0/0x40 [mISDN_core]
Nov  5 21:09:43 testdebian kernel: [  809.310462]  [<e0a97bc4>] mISDN_send+0x4b/0x6a [mISDN_core]
Nov  5 21:09:43 testdebian kernel: [  809.310462]  [<e0a9a9c0>] l2up+0x25/0x48 [mISDN_core]
Nov  5 21:09:43 testdebian kernel: [  809.310462]  [<e0a9762d>] mISDN_FsmEvent+0x6f/0xa1 [mISDN_core]
Nov  5 21:09:43 testdebian kernel: [  809.310462]  [<e0a9bb8e>] l2_send+0x1ab/0x516 [mISDN_core]
Nov  5 21:09:43 testdebian kernel: [  809.310462]  [<e0a9e299>] mgr_bcast+0x6e/0x10b [mISDN_core]
Nov  5 21:09:43 testdebian kernel: [  809.310462]  [<e0a994dd>] mISDNStackd+0x1f1/0x4d0 [mISDN_core]
Nov  5 21:09:43 testdebian kernel: [  809.310462]  [<c013177c>] autoremove_wake_function+0x0/0x2d
Nov  5 21:09:43 testdebian kernel: [  809.310462]  [<e0a992ec>] mISDNStackd+0x0/0x4d0 [mISDN_core]
Nov  5 21:09:43 testdebian kernel: [  809.310462]  [<c01316bb>] kthread+0x38/0x5d
Nov  5 21:09:43 testdebian kernel: [  809.310462]  [<c0131683>] kthread+0x0/0x5d
Nov  5 21:09:43 testdebian kernel: [  809.310462]  [<c01044f3>] kernel_thread_helper+0x7/0x10
Nov  5 21:09:43 testdebian kernel: [  809.310462]  =======================
Nov  5 21:09:43 testdebian kernel: [  809.310462] ---[ end trace c29fc9e6b7b54492 ]---
Nov  5 21:09:43 testdebian kernel: [  809.313192] changing DTMF Threshold to 0
Nov  5 21:10:05 testdebian kernel: [  830.933169] changing DTMF Threshold to 0
Nov  5 21:10:13 testdebian kernel: [  839.288872] changing DTMF Threshold to 0
Nov  5 21:13:10 testdebian kerneloops: Submitted 1 kernel oopses to www.kerneloops.org
Nov  5 21:15:17 testdebian kernel: [ 1143.160339] changing DTMF Threshold to 0
Nov  5 21:15:27 testdebian kernel: [ 1153.082875] changing DTMF Threshold to 0
Nov  5 21:15:41 testdebian kernel: [ 1167.209063] changing DTMF Threshold to 0
Nov  5 21:15:48 testdebian kernel: [ 1173.731846] changing DTMF Threshold to 0

Das sieht nicht gut aus, ich werde mal die git misdn treiber probieren.

Vielen, vielen Dank!

gongbuster · 5 Nov 2008

den stacktrace bekomme ich auch, allerdings nur ein einziges mal nach nem neustart des rechners beim ersten telefongespräch. habe das auch schon mal irgendwann auf der isdn4linux-ml gemeldet und hatte auch nen patch per pm bekommen, der das geheilt hat. hatte aber keine lust, den weiter zu pflegen und es läuft ja. ich buch das momentan nter schönheitsfehler...

das mit den git-treibern ist trotzdem ne gute idee, da ist dann auch der oslec-ec dabei... gute sache das.

viel spaß
sven

unlimitopen · 5 Nov 2008

zusaätzliche Fragen

Wenn wir schon einmal dabei sind - wie lässt sich eigentlich die mISDN Karte/Treiber Geschichten einstellen->

Beispiel

es gab früher unter /etc/misdn-init.conf
einen Eintrag wie rxgain txgain und echocancelation off etc.
wie und wo kann ich das denn nun einstellen.

Grüße
christian

gongbuster · 5 Nov 2008

das schöne bei der v2-lösung ist, dass sich das alles "on the fly" machen lässt. misdn-init.conf etc. sind damit geschichte. den rest regelst du über die extensions.conf. bei eingehenden anrufen via isdn z.b.:

exten => 1234567890,1,lcr_config(eoslec:s)
exten => 1234567890,n,Dial(SIP/1234)

sorgt dafür, dass oslec genutzt und dtmf-inband-übertragung aktiviert wird. bei ausgehenden gesprächen:

exten => _0.,1,Dial(LCR/Int/${NUM1:1}/eoslec:s)

die möglichen weiteren optionen sind in der lcr-doku irgendwo im unteren drittel zu finden. noch nicht dokumentiert ist der parameter "r" (ohne irgendeinen weiteren), damit klappts dann auch mit iaxmodem/hylafax als fax-lösung...

viele grüße
sven

unlimitopen · 5 Nov 2008

ach, man da liest man die Doku schon....

kläre mich kurz auf

)

dtmf-inband-übertragung - was bedeutet ?? sorry...

gongbuster · 5 Nov 2008

bei sip werden die dtmf-daten normalerweise außerhalb des audio-streams übertragen. wenn du während eines (isdn-)gespräches also ne taste auf deinem (sip-)telefon drückst, hört dein gegenüber das "pieps" nicht. wenn du jemanden per isdn anrufst, möchtest du das aber in der regel... die option "s" generiert dann aus den sip-daten den entsprechenden ton im isdn-audio-kanal.

effekt: automaten wie "bitte drücken sie die 2, wenn sie eine waschmaschine kaufen wollen" oder die windows-aktivierungs-hotline (wers braucht...) funktionieren auch von nem sip-telefon aus...

hoffe, das war so verständlich...

have phun
sven

unlimitopen · 5 Nov 2008

verneige mich und ich spreche zu dir

:groesste:

Thanks a lot

Grüße
christian

thomasmebes · 21 Jan 2009

Neue mISDN-Version

Für alle, die auch ein Problem hatten mit dem compilieren der mISDN 1.X-Version, es gibt seit heute, ~17 Uhr die Version 1.1.9

http://www.misdn.org/downloads/releases/mISDN-1_1_9.tar.gz
http://www.misdn.org/downloads/releases/mISDNuser-1_1_9.tar.gz

Problem war zwar scho im mISDN_1_1 branch behoben, aber ich wußte das bsp. noch nicht, sicherlich einige hier auch nicht?

Also mit den src (s.o.) sollte das übersetzen der Quellen nun kein Problem mehr geben.

Ich hatte bsp. Probleme mit dem Debian Kernel 2.6.26

Lieben Gruß

Thomas

jacekw4101 · 27 Jan 2009

Hallo thomasmebes,

Danke für den Tipp. ich konnte heute erfolgreich den mISDN-Treiber (1_1_9.1) kompilieren und einsetzen. Es funktioniert mit dem im Asterisk (1.4.23.1) eingebautem chan_misdn.so ohne Probleme.

Gruß

jacek

karls0 · 30 Jan 2009

foschi schrieb:
Etwas offtopic hier im misdn-forum, aber für ein stabiles System kommt kartenbasierte Hardware wenig und misdn eher gar nicht in Frage - hängt aber auch von Deinen Anforderungen ab.

Es gibt genügend produktiv genutzte Asterisk-Server, die ohne Karten und misdn auskommen. Warum Digium das macht? Weil sie es nicht besser wissen bzw. BRI in den US keine Rolle spielt?

Hi,
ich spiel zwar schon einige Zeit mit Asterisk herum und habe seit drei Monaten einen mit einer beronet 8-fach ISDN-Karte im Produktivbetrieb. Deine Aussage schreckt mich nun ein wenig

oder sogar ganz ordentlich. Wie bekommst du deine BRIs denn ohne Karte in den Asterisk???

Mein * hängt sich nämlich sporadisch auf (mit Fehler "misdn P[ 0] handle_bchan: BC not found for prim:120282 with addr:52010101 dinfo:ffffffff") und die "Lösungen", die ich bisher gefunden habe helfen nicht. Und jetzt lese ich dein Statement

Mit welcher Hardware und Software (Treiber) würdest es denn lösen?

HobbyStern · 8 Mrz 2009

Hi, hast was warten müssen auf ne Antwort, aber was spät kommt, kommt gut

Mit welcher Hardware und Software (Treiber) würdest es denn lösen?

Foschi u.a. rät ganz gerne zu Patton Hardware bzw. Gateways - diese stellen dann somit einen externen Zugriff auf ISDN Leitungen zur Verfügung.

Ich denke aber alles in allem (es war oft hier ein Thema) ist mISDN nicht mehr zu dem Lösungsansatz zu gebrauchen zu welchem es einmal gedacht war

.

Ich habe hier seit 2005 eine produktive mISDN v1 Lösung stehen (angefangen mit v0.x) die mich am Anfang sehr viel Nerven gekostet hat, dann aber lief und lief und lief..Das wichtigste an dieser Variante ist mehr als bekannt - ändere es nicht wenn es denn einmal läuft.

Zum Einsatz in Firmen welche man als Kunde betreut, wie es IMHO Foschi tut würde ich Foschis Aussage unterstreichen, mISDN ist nicht produktiv einsetzbar, die Karten von Beronet sind leicht anfällig und produzieren viel Last.

Sofern man aber um eine Homelösung spricht ist mISDN in der v1 eine gute Wahl, für meine kleine Firma hier ist mISDN auch okay.

Aktuell versuche ich einen sauberen, produktiven Wechsel auf *1.4.23 und somit zwangsweise auf mISDN v2...wie damals, reichlich schlecht dokumentiert..

LG Stefan

karls0 · 8 Mrz 2009

Danke Stefan,

ich hab inzwischen Foschi's Rat befolgt und bin Patton-Jünger geworden.

Siehe http://www.ip-phone-forum.de/showthread.php?t=186759

Trotzdem Danke und liebe Grüße aus Ösiland

Karl

HobbyStern · 8 Mrz 2009

Gern geschehen.

Kann man denn Deinen Umstieg in kurzen Worten beschreiben, bist Du zufrieden?

Ich sitze gerade (mal wieder) an Folgeschwierigkeiten einer Updatelösung von mISDN....da zwingt sich einem immer wieder die Frage auf ob sicher ganze Alheil mit mISDN überhaupt lohnt..

LG Stefan

crich · 8 Mrz 2009

Schaut euch mal unsere neue Karte "beroFix" an, damit wirds keine Treiber/Kernel/Asterisk-Versions- Probleme mehr geben. Damit wird die ISDN Karte dann auch eher zu einem SIP2ISDN Gateway.

blauerpeti · 8 Mrz 2009

..und der Preis?

crich · 8 Mrz 2009

So wie die passiven (4S0 etwa 500). Wir wollen keinen Grund liefern mehr die "alten" zu kaufen.

[gelöst] Asterisk 1.4/1.6 + kernel 2.6.26 + Debian lenny + mISDN v2 oder mISDN v1

Neuer User

Neuer User

Neuer User

Neuer User

Neuer User

Neuer User

Neuer User

Neuer User

Neuer User

Neuer User

Neuer User

Neuer User

Neuer User

Aktives Mitglied

Neuer User

Aktives Mitglied

Mitglied

Mitglied

Mitglied

Statistik des Forums