HFC-Karte mit Dahdi und Asterisk 1.6

Flex78 · 31 Jul 2010

sparkie schrieb:
Seit ich grundsaetzlich mit

Code:

exten => s,1,lcr_config(eoslec)

bzw.

Code:

exec Dial LCR/s0-internal/1/eoslec

arbeite hoere ich keine Beschwerden mehr von der Gegenseite

Leider betrifft das aber ein LCR-misdn-Setup und ist daher wohl nicht ganz vergleichbar mit meiner Ausgangssituation. Die LCR Lösung war mir zu rechenintensiv und die dort entstandenen Echos waren wesentlich schlechter bis überhaupt nicht zu filtern. Mit leistungsstärkerer Hardware wäre das eventuell besser zu lösen gewesen...

Bei meinem jetzigen Setup mit vzaphfc und chan_dahdi ist oslec eingeschaltet und funktioniert auch fast optimal, jedoch gelegentlich nicht ohne vollständige Echounterdrückung. Im Falle eines Echos höre nur ich mich selbst. Die Gesprächspartner klagen nicht über Echos - manchmal aber über eine roboterähnliche Verzerrung meiner Stimme. Die Echos treten verstärkt bei Gesprächspartnern mit analogen Endgeräten auf. Die gelegentliche Roboter-Stimme beim Gesprächspartner kommt auch nur wenn oslec aktiviert ist...

Als IP-Telefon kommen Snom 370s zum Einsatz. Selbst der direkte Anschluß eines dieser Telefone an die Netzwerkschnittstelle der Asteriskanlage bringen keine Linderung. Somit schließe ich ein träges Netzwerk aus und vermute das es an der Kombination von oslec sowie rxgain und txgain liegt. Vor allem auch, da sich Änderungen dieser Werte bei Tests "gefühlt" auf die Echo Unterdrückungsqualität ausgewirkt haben. Kann jedoch nur Willkür feststellen. Leider finde ich keine Möglichkeit die Werte objektiv richtig einzustellen. Gibt es vielleicht eine "geeichte" deutsche Gegenstelle mit deren Hilfe man diese Kalibrierung durchführen kann? Oder würdet Ihr einfach auf eine stark echobelastete Gegenstelle hin optimieren?

Im übrigen handelt es sich um einen ISDN-Anschluß, der noch zu Zeiten von Arcor eingerichtet und von Vodafone übernommen wurde. Eventuell besteht das Problem nur an meinem Anschluß? Leider habe ich momentan keine Möglichkeit die Anlage an einem alternativen ISDN-Anschluß zu testen.

Malcreatiure · 31 Jul 2010

sparkie schrieb:
also damit HFC-S + chan_dahdi laeuft muss einiges gepatcht werden. Siehe Zusammenfassung hier:

Muss glücklicherweise nicht. Hier ein kleines Howto:

Voraussetzung Installiertes Ubuntu Lucid (ich nahm 64bit), HFC-S PCi Karte im TE Modus.

Code:

$> apt-get install install dahdi dahdi-dkms  dahdi-linux

die automatisch generierten Module wieder löschen:

Code:

$> dkms remove -m dahdi -v 2.2.1+dfsg-1ubuntu2 --all

aktuelles base.c für das Modul zaphfc herunterladen:

Code:

$> wget http://zaphfc.googlecode.com/svn-history/r7/branches/2.2/zaphfc/base.c -O /usr/src/dahdi-2.2.1+dfsg-1ubuntu2/drivers/dahdi/zaphfc/base.c

das Modul erneut bauen

Code:

$> dkms add -m dahdi -v 2.2.1+dfsg-1ubuntu2

Code:

$> dkms build -m dahdi -v 2.2.1+dfsg-1ubuntu2

Code:

$> dkms install -m dahdi -v 2.2.1+dfsg-1ubuntu2

Asterisk und dahdi neu starten bzw. laden oder das System neu starten. fertig.

Larry · 11 Aug 2010

Flex78 schrieb:
Bei meinem jetzigen Setup mit vzaphfc und chan_dahdi ist oslec eingeschaltet und funktioniert auch fast optimal, jedoch gelegentlich nicht ohne vollständige Echounterdrückung. Im Falle eines Echos höre nur ich mich selbst. Die Gesprächspartner klagen nicht über Echos
[...]
Die Echos treten verstärkt bei Gesprächspartnern mit analogen Endgeräten auf.

Das kann ich so bestätigen... Ich bin mir (gefühlt) ganz sicher, dass dieses Problem eigentlich nur in Verbindung mit Analog-Anschlüssen (oder ISDN->Analog Konstrukten) auftritt.
Ganz düster kann ich mich daran erinnern, mal irgendwann irgendwo einen Artikel über die "Entstehung von Echos bei (VoIP-)Gesprächen" gelesen zu haben. Wenn sich mein Hirn nicht täuscht, lief es letztlich darauf hinaus, dass je öfter ein Signal gewandelt/umgesetzt werden muss, die Wahrscheinlichkeit eines Echos deutlich ansteigt und entweder gar nicht mehr oder nur per Trimmung von rxgain/txgain (geht bei Asterisk übrigens live während eines Gesprächs) gemindert werden kann...

manchmal aber über eine roboterähnliche Verzerrung meiner Stimme.

Den Fall mit "roboterähnliche Verzerrung" habe ich selber noch nie gehabt, wohl aber ein Kunde, den ich von mISDN auf vzaphfc umgestellt habe (aber auch nur bei diesem Kunde). Wenn dort die Verzerrung auftritt, bleibt sich bis zu einem restart von Asterisk bestehen - egal ob der Gegenüber ISDN, Analog oder GSM nutzt. Sehr seltsam das. Interessant ist auch, dass der Kunde die identische Hardware wie ich selber einsetzt; der signifikante Unterschied ist, dann mein Asterisk unter 32-Bit Gentoo, seines unter 64-Bit Gentoo läuft...

-
Larry

Larry · 11 Aug 2010

Asterisk-1.8b / NT-Mode

Habe heute in einem Anfall von Geilheit zwei experimentelle Ebuilds für libpri/asterisk-1.8 (beide Beta) gebaut, um endlich mal mit dem NT-Mode voran zu kommen. Dieser soll ja nun endlich seit libpri-1.4.11.* unterstützt sein (Asterisk 1.6 mit Patch, 1.8 out-of-the-box).
Ergebnis: Das selbe in grün. Die Übertragung von SIP zum ISDN-Phone (via NT) klappt glasklar, die Übertragung von ISDN (NT) zu SIP ist völlig verknistert.
Also Ersatz-NTBA 'rausgekramt, angekabelt und geht! Davon überrascht habe ich mal die DIPs der NTBAs verglichen und mit Entsetzen festgestellt, dass jener NTBA, mit dem ich die ganze Zeit teste, die DIPs für "Pkt-Pkt" auf "ON" und "100 Ohm" auf "OFF" stehen hatte. Klassicher Fall von "On und Off vertauscht" :doof: Ich werd' wohl langsam alt...

Also alles nochmal zurück auf die letzen stabilen Versionen und geht immer noch. Ich darf also behaupten, dass der NT-Mode nun endlich mit libpri/dahdi/vzaphfc/asterisk läuft. Sowohl in Asterisk 1.6, als auch in 1.8 (hier ohne jegliche krumme Patcherei).

Wer todesmutig ist, kann sich gerne mal die beiden Ebuilds zu Gemüte führen und Feedback geben.

Ich mach mir jetzt erstmal 'n Bier auf. Habsch mir verdient, behaupte ich mal...

-
Larry

sparkie · 11 Aug 2010

Larry schrieb:
Also Ersatz-NTBA 'rausgekramt, angekabelt und geht! Davon überrascht habe ich mal die DIPs der NTBAs verglichen und mit Entsetzen festgestellt, dass jener NTBA, mit dem ich die ganze Zeit teste, die DIPs für "Pkt-Pkt" auf "ON" und "100 Ohm" auf "OFF" stehen hatte.

also mein letzter Test mit den Staenden vom 24.07.2010 hat noch nicht das gewuenschte Ergebnis gebracht (mit HFC-S PCI).

Klassicher Fall von "On und Off vertauscht" :doof: Ich werd' wohl langsam alt...

das habe ich deswegen auch gerade noch mal ge'checkt. Und nein - zumindest das ist ok hier.
Aber vielleicht habe ich was anderes verbockt

Also alles nochmal zurück auf die letzen stabilen Versionen und geht immer noch. Ich darf also behaupten, dass der NT-Mode nun endlich mit libpri/dahdi/vzaphfc/asterisk läuft. Sowohl in Asterisk 1.6, als auch in 1.8 (hier ohne jegliche krumme Patcherei).

Es haette also alles mit den Software-Staenden vom 24.07.2010 funktionieren sollen?
Muss ich mir wohl nochmal anschauen.

Ich mach mir jetzt erstmal 'n Bier auf. Habsch mir verdient, behaupte ich mal...

aber in jedem Fall:bier:
Ich geh' jetzt dann aber trotzdem auf'n Bier obwohl ich mir das (noch) nicht verdient habe

- sparkie

sparkie · 11 Aug 2010

so nach 'nem Bierchen noch ein wenig compiliert. Sah soweit alles ganz gut aus. Beim Start des Systems (das unter chan_lcr im NT-MODE uebrigens einwandfrei lief) bekomme ich einen:

Code:

[...]
Aug 11 19:55:16 ceduna kernel: [   30.678165] vzaphfc: HFC-S PCI A ISDN (V1.42) loading
Aug 11 19:55:16 ceduna kernel: [   30.682611] vzaphfc 0000:05:00.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
Aug 11 19:55:16 ceduna kernel: [   30.686891] vzaphfc: card 0: registered ZTHFC1/0/1
Aug 11 19:55:16 ceduna kernel: [   30.690937] vzaphfc: card 0: registered ZTHFC1/0/2
Aug 11 19:55:16 ceduna kernel: [   30.694956] vzaphfc: card 0: registered ZTHFC1/0/3
Aug 11 19:55:16 ceduna kernel: [   30.698939] ------------[ cut here ]------------
Aug 11 19:55:16 ceduna kernel: [   30.702971] WARNING: at /root/AST/DAHDI-LINUX/dahdi-linux-2.3.0.1/drivers/dahdi/dahdi-base.c:5866 dahdi_register+0x2d/0x27b [dahdi]()
Aug 11 19:55:16 ceduna kernel: [   30.707119] Hardware name:         
Aug 11 19:55:16 ceduna kernel: [   30.711301] Modules linked in: zaphfc(+) dahdi_transcode dahdi crc_ccitt fuse xt_state ipt_LOG xt_tcpudp iptable_mangle iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 iptable_filter ip_tables x_tables option usbserial rng_core i2c_i801 pcspkr psmouse serio_raw evdev processor button usbhid ext3 hid jbd mbcache ide_gd_mod ata_generic ide_pci_generic usb_storage ahci libata piix uhci_hcd scsi_mod ehci_hcd ide_core video output usbcore r8169 mii thermal fan thermal_sys [last unloaded: scsi_wait_scan]
Aug 11 19:55:16 ceduna kernel: [   30.725911] Pid: 1737, comm: modprobe Not tainted 2.6.30-hot.1-686 #2
Aug 11 19:55:16 ceduna kernel: [   30.730739] Call Trace:
Aug 11 19:55:16 ceduna kernel: [   30.735500]  [<c0127160>] ? warn_slowpath_common+0x5e/0x8a
Aug 11 19:55:16 ceduna kernel: [   30.740236]  [<c0127196>] ? warn_slowpath_null+0xa/0xc
Aug 11 19:55:16 ceduna kernel: [   30.744977]  [<fc0a5a2e>] ? dahdi_register+0x2d/0x27b [dahdi]
Aug 11 19:55:16 ceduna kernel: [   30.749709]  [<c0329be0>] ? printk+0xe/0x16
Aug 11 19:55:16 ceduna kernel: [   30.754423]  [<fc0e0ba7>] ? hfc_probe+0x8ce/0xb57 [zaphfc]
Aug 11 19:55:16 ceduna kernel: [   30.759181]  [<fc0e0c8f>] ? hfc_probe+0x9b6/0xb57 [zaphfc]
Aug 11 19:55:16 ceduna kernel: [   30.763919]  [<c020f90d>] ? local_pci_probe+0xb/0xc
Aug 11 19:55:16 ceduna kernel: [   30.768666]  [<c0210283>] ? pci_device_probe+0x41/0x63
Aug 11 19:55:16 ceduna kernel: [   30.773351]  [<c0276f3a>] ? driver_probe_device+0x76/0xfe
Aug 11 19:55:16 ceduna kernel: [   30.777978]  [<c0277002>] ? __driver_attach+0x40/0x5b
Aug 11 19:55:16 ceduna kernel: [   30.783238]  [<c0276a06>] ? bus_for_each_dev+0x37/0x5f
Aug 11 19:55:16 ceduna kernel: [   30.787770]  [<c0276e21>] ? driver_attach+0x11/0x13
Aug 11 19:55:16 ceduna kernel: [   30.792271]  [<c0276fc2>] ? __driver_attach+0x0/0x5b
Aug 11 19:55:16 ceduna kernel: [   30.796737]  [<c02764cb>] ? bus_add_driver+0x99/0x1bf
Aug 11 19:55:16 ceduna kernel: [   30.801174]  [<c027721b>] ? driver_register+0x87/0xe0
Aug 11 19:55:16 ceduna kernel: [   30.805585]  [<c01c0793>] ? proc_register+0xf8/0x142
Aug 11 19:55:16 ceduna kernel: [   30.809994]  [<c02105b8>] ? __pci_register_driver+0x33/0x8b
Aug 11 19:55:16 ceduna kernel: [   30.814406]  [<fc0e5000>] ? hfc_init_module+0x0/0x30 [zaphfc]
Aug 11 19:55:16 ceduna kernel: [   30.818811]  [<c010113e>] ? do_one_initcall+0x55/0x155
Aug 11 19:55:16 ceduna kernel: [   30.823208]  [<c0147331>] ? sys_init_module+0x87/0x187
Aug 11 19:55:16 ceduna kernel: [   30.827579]  [<c0102ff4>] ? sysenter_do_call+0x12/0x28
Aug 11 19:55:16 ceduna kernel: [   30.831926] ---[ end trace 020195c764753be1 ]---
Aug 11 19:55:16 ceduna kernel: [   30.836735] vzaphfc: card 0: resetting
Aug 11 19:55:16 ceduna kernel: [   30.861103] vzaphfc: card 0 configured for NT mode at mem 0xdfc00000 (0xfc0e8000) IRQ 20
[...]

Belegen der Leitung zeigt Null Reaktion am Asterisk (laeuft im Debug Mode).

Dabei sehen so diverse neuralgische Stellem im System eigentlich ganz gut aus:

/etc/dahdi/system.conf

Code:

span=1,0,0,ccs,ami
# termtype: nt
bchan=1-2
hardhdlc=3
echocanceller=oslec,1-2

# Global data

loadzone        = us
defaultzone     = us

Code:

/usr/sbin/dahdi_cfg -v
DAHDI Tools Version - 2.3.0

DAHDI Version: 2.3.0.1
Echo Canceller(s): OSLEC
Configuration
======================

SPAN 1: CCS/ AMI Build-out: 0 db (CSU)/0-133 feet (DSX-1)

3 channels to configure.

Setting echocan for channel 1 to oslec
Setting echocan for channel 2 to oslec
Setting echocan for channel 3 to none

Code:

*CLI> dahdi show channels group g0
   Chan Extension  Context         Language   MOH Interpret        Blocked    State     
      1            s0-internal                default                         In Service
      2            s0-internal                default                         In Service

Code:

*CLI> dahdi show channels trunkgroup 1
   Chan Extension  Context         Language   MOH Interpret        Blocked    State     
 pseudo            default                    default                         In Service
      1            s0-internal                default                         In Service
      2            s0-internal                default                         In Service

Code:

*CLI> dahdi show status
Description                              Alarms  IRQ    bpviol CRC4   Fra Codi Options  LBO
HFC-S PCI A ISDN card 0 [NT]             OK      0      0      0      CCS AMI           0 db (CSU)/0-133 feet (DSX-1)
*CLI> dahdi show version
DAHDI Version: 2.3.0.1 Echo Canceller: OSLEC

Code:

*CLI> pri show span 1 
Primary D-channel: 3
Status: Up, Active
Switchtype: EuroISDN
Type: Network
Overlap Dial: 0
Logical Channel Mapping: 0
Timer and counter settings:
  N200: 3
  N202: 3
  K: 1
  T200: 1000
  T202: 10000
  T203: 10000
  T303: 4000
  T305: 30000
  T308: 4000
  T309: 6000
  T313: 4000
  T-HOLD: 4000
  T-RETRIEVE: 4000
  T-RESPONSE: 4000
  T-STATUS: 4000
  T-ACTIVATE: 10000
  T-DEACTIVATE: 4000
  T-INTERROGATE: 4000
  T-RETENTION: 30000
  T-CCBS1: 4000
  T-CCBS2: 2700000
  T-CCBS3: 20000
  T-CCBS4: 5000
  T-CCBS5: 3600000
  T-CCBS6: 3600000
  T-CCNR2: 10800000
  T-CCNR5: 11700000
  T-CCNR6: 11700000
Overlap Recv: No

Code:

pri show spans
PRI span 1/0: Up, Active

vielleicht ist meine vzaphfc Version ein wenig alt? Keine Ahnung was da derzeit fuer eine Version angesagt ist. Geschweige denn wo man die findet.

- sparkie

Larry · 12 Aug 2010

sparkie schrieb:

Beim Start des Systems (das unter chan_lcr im NT-MODE uebrigens einwandfrei lief) bekomme ich einen:

Code:

Aug 11 19:55:16 ceduna kernel: [   30.698939] ------------[ cut here ]------------
Aug 11 19:55:16 ceduna kernel: [   30.702971] WARNING: at /root/AST/DAHDI-LINUX/dahdi-linux-2.3.0.1/drivers/dahdi/dahdi-base.c:5866 dahdi_register+0x2d/0x27b [dahdi]()
Aug 11 19:55:16 ceduna kernel: [   30.707119] Hardware name:         
Aug 11 19:55:16 ceduna kernel: [   30.711301] Modules linked in: zaphfc(+) dahdi_transcode dahdi crc_ccitt fuse xt_state ipt_LOG xt_tcpudp iptable_mangle iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 iptable_filter ip_tables x_tables option usbserial rng_core i2c_i801 pcspkr psmouse serio_raw evdev processor button usbhid ext3 hid jbd mbcache ide_gd_mod ata_generic ide_pci_generic usb_storage ahci libata piix uhci_hcd scsi_mod ehci_hcd ide_core video output usbcore r8169 mii thermal fan thermal_sys [last unloaded: scsi_wait_scan]
Aug 11 19:55:16 ceduna kernel: [   30.725911] Pid: 1737, comm: modprobe Not tainted 2.6.30-hot.1-686 #2
Aug 11 19:55:16 ceduna kernel: [   30.730739] Call Trace:[...]

Yup, das gibts bei auch schon eine ganze Weile. Ich hatte es seinerzeit bei bugs.gentoo.org geposted, als wir dort das dahdi/zaphfc-Ebuild zurecht gezimmert haben: Request for dahdi-2.3.0 & dahdi-tools-2.3.0 ebuilds (ab Comment #24).
Ein Kollege antwortete darauf:

it's a warning triggered by slow path detection code (CONFIG_SLOW_WORK). If you also enable CONFIG_PRINTK_TIME, you'll get an idea of just how slow the path in question is. If you choose to keep this option enabled and the hardware takes some time to initialize then it may well trigger this warning. It is unlikely that it indicates any kind of fault.

Also habe ich's ersteinmal ignoriert und bis dato hat es auch keinerlei Probleme verursacht - und ich arbeite/telefoniere täglich damit. Sieht halt nur ~~scheiße~~ unschön aus.

Belegen der Leitung zeigt Null Reaktion am Asterisk (laeuft im Debug Mode).
Dabei sehen so diverse neuralgische Stellem im System eigentlich ganz gut aus:

Code:

/etc/dahdi/system.conf(...jede Menge Code...)

Joah, sieht eigentlich alles gut aus...

vielleicht ist meine vzaphfc Version ein wenig alt? Keine Ahnung was da derzeit fuer eine Version angesagt ist. Geschweige denn wo man die findet.

Der Sourcecode kommt von hier, ziehen kannst Du ihn per

Code:

svn co http://zaphfc.googlecode.com/svn/

aber da hat sich seit mindestens März nix mehr getan. Der Stand ist weiterhin Revision 7.

-
Larry

sparkie · 12 Aug 2010

Larry schrieb:
Also habe ich's ersteinmal ignoriert und bis dato hat es auch keinerlei Probleme verursacht - und ich arbeite/telefoniere täglich damit. Sieht halt nur ~~scheiße~~ unschön aus.

ok, dann ist das ja mal geklaert. Witzigerweise tritt das aber nur im NT-Mode auf. Habe ich im TE-Mode noch nicht gesehen.... ABer ist wurscht

Code:
Der Sourcecode kommt von hier, ziehen kannst Du ihn per

Code:

svn co http://zaphfc.googlecode.com/svn/

aber da hat sich seit mindestens März nix mehr getan. Der Stand ist weiterhin Revision 7.

gut. Habe ich gerade nochmal verglichen. Genau diesen Stand verwende ich auch.

Also Dahdi im TE Mode laeuft hier ja schon einige Monate produktiv. Den chan_lcr habe ich parallel dazu auf einer anderen Kiste im NT-Mode seit Monaten ohne Probleme am Laufen.

Deswegen schliesse ich Hardware- oder Basis/Kernelprobleme aus. Genau diese chan_lcr Anlage wollte ich jetzt testweise mal auf Dahdi NT Mode umruesten.

Ich fuehre hier nochmal meine Software/Hardware auf.

Hardware:
1 x HFC-S PCI

Software:
libpri-1.4.12-beta1.tar.gz
+ libpri-1.4.11.1-multilib.patch
+ libpri-1.4.11.1-respect-cflags.patch
+ libpri-1.4.11.1-respect-ldflags.patch
+ libpri-1.4.11.1-werror-is-ill-advised.patch

dahdi-linux-2.3.0.1.tar.gz
+ dahdi-2.2.1.1-gcc44-hack.patch
+ dahdi-2.2.1.1-parallel-make.patch
+ dahdi-2.2.1.1-oslec.patch
+ dahdi-2.2.1.1-kbuild-oslec.patch
+ dahdi-tzafrir-branch-20100403.patch
+ dahdi-2.2.1.1-kbuild-vzaphfc.patch

dahdi-tools-2.3.0.tar.gz
+ dahdi-tools-2.2.1.1-no-hardware-fiddling.patch

asterisk-1.8.0-beta3.tar.gz
+ asterisk-1.8.0-gsm-pic.patch
+ asterisk-1.6.2.8-pri-missing-keyword.patch
+ asterisk-1.6.2.8-inband-indications.patch
+ asterisk-1.6.1-uclibc.patch

Vielleicht siehst Du noch irgendeinen Unterschied zu Deinem funktionierendem Setup?

- sparkie

Larry · 12 Aug 2010

sparkie schrieb:
ok, dann ist das ja mal geklaert. Witzigerweise tritt das aber nur im NT-Mode auf. Habe ich im TE-Mode noch nicht gesehen.... ABer ist wurscht

Ach...bei mir taucht es unabhängig vom Modus auf...aber sei's drum...

Ich fuehre hier nochmal meine Software/Hardware auf.
1 x HFC-S PCI
libpri-1.4.12-beta1.tar.gz
dahdi-linux-2.3.0.1.tar.gz
dahdi-tools-2.3.0.tar.gz
asterisk-1.8.0-beta3.tar.gz

Ah, ein todesmutiger! :keks:
Hmm, nein, soweit identisch. Was mir sonst nur noch in den Sinn kommt, ist, dass Du wohl Debian einsetzt (schließe ich aus Deinem Footer). Möglicherweise spielen dann andere Faktoren noch eine Rolle (header, glibc etc.)?
Hast Du auch artig alles der Reihenfolge nach kompiliert (libpri->dahdi-linux->dahdi-tools->asterisk)?

-
Larry

sparkie · 12 Aug 2010

Larry schrieb:
wohl Debian einsetzt (schließe ich aus Deinem Footer). Möglicherweise spielen dann andere Faktoren noch eine Rolle (header, glibc etc.)?

richtig ist Debian. Aber meine Buildscripten sind fuer den jetzigen Versuch bis auf die angefuehrten Versionsstaende praktisch gleich wie fuer den TE Mode. Und da geht ja alles wunderbar.

Hast Du auch artig alles der Reihenfolge nach kompiliert (libpri->dahdi-linux->dahdi-tools->asterisk)?

ja ich war artig:meinemei:

dann muss ich wohl noch weiter suchen...

Vielleicht gibt's ja bald noch andere die es vor mir zum Laufen bekommen

auf jeden Fall mal danke fuer Deine Hilfe!

- sparkie

sparkie · 13 Aug 2010

Larry schrieb:
Wer todesmutig ist, kann sich gerne mal die beiden Ebuilds zu Gemüte führen und Feedback geben.

so kurzer Status Upgrade. DAHDI TE Mode laeuft einwandfrei mit den im obigen Post angegebenen aktuellsten Beta-Versionsstaenden.

was nach wie vor nicht funktioniert ist der NT Mode. Dafuer ist also chan_lcr IMHO immer noch die mit Abstand beste Loesung. Die laeuft hier seit Monaten voellig problemlos.

Dabei spreche ich hier ausdruecklich von dieser Karte:

Code:

05:00.0 0280: 1397:2bd0 (rev 02)
        Subsystem: 1075:c101
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 16 (4000ns max)
        Interrupt: pin A routed to IRQ 20
        Region 0: I/O ports at d000 [disabled] [size=8]
        Region 1: Memory at dfc00000 (32-bit, non-prefetchable) [size=256]
        Capabilities: [40] Power Management version 1
                Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
        Kernel driver in use: vzaphfc

Vielleicht geht's ja wenigstens mit anderer Hardware.

- sparkie

sparkie · 14 Aug 2010

sparkie schrieb:
was nach wie vor nicht funktioniert ist der NT Mode.

Hallo Leute,

geschafft! NT-Mode funzt jetzt bei mir zum ersten Mal auch mit DAHDI.

Aber:
Aus mir voellig unverstaendlichen Gruenden muss ich hierzu nach einem Reboot/ vzaphfc-Reload einmalig einen 'Dial' auf's dahdi

Code:

exten => 1,1,Dial(DAHDI/g1/${EXTEN})

ausfuehren. Diesen Workaround fahre ich z.B. mit einem

Code:

asterisk -rx 'console dial 1'

nach Reboot an.

Belegen der Leitung funktioniert erst ab da!

Man muss also den internen S0 Bus zunaechst von Asterisk aus ansteuern. Erst ab da geht es auch in der umgekehrten Richtung (z.B. waehlen direkt vom ISDN Telefon). Da soll einer drauf kommen:hehe:

Ansonsten geht das System einwandfrei. Keine weiteren Anomalien bis jetzt.

Witzig: Selbst nach einem Asterisk-Restart ist der 'Dial' nicht mehr noetig, nur eben nach Reboot/vzaphfc Restart. Wohl doch noch 'nen klitzekleiner dahdi-linux/vzaphfc Treiber-Bug irgendwo...

War reiner Zufall, dass ich da draufgekommen bin

[EDIT]
Wenn ich den 'Workaround-Dial' ausfuehre bekomme ich einmal diesen Ruelpser:

Code:

[Aug 14 12:31:17] ERROR[2151]: chan_dahdi.c:13533 dahdi_pri_error: 1 N(R) 0 not within ack window!  Bad Bad Bad!
[Aug 14 12:31:17] ERROR[2151]: chan_dahdi.c:13533 dahdi_pri_error: 1 Network MDL can't handle error of type J
[Aug 14 12:31:17] ERROR[2151]: chan_dahdi.c:13533 dahdi_pri_error: 1 MDL-ERROR (J) in state 8

Der blaest das System offenbar richtig durch. Ab da funzt es bis zum naechsten Reboot.
[/EDIT]

- sparkie

Flex78 · 16 Aug 2010

Larry schrieb:
Das kann ich so bestätigen... Ich bin mir (gefühlt) ganz sicher, dass dieses Problem eigentlich nur in Verbindung mit Analog-Anschlüssen (oder ISDN->Analog Konstrukten) auftritt.
Ganz düster kann ich mich daran erinnern, mal irgendwann irgendwo einen Artikel über die "Entstehung von Echos bei (VoIP-)Gesprächen" gelesen zu haben. Wenn sich mein Hirn nicht täuscht, lief es letztlich darauf hinaus, dass je öfter ein Signal gewandelt/umgesetzt werden muss, die Wahrscheinlichkeit eines Echos deutlich ansteigt und entweder gar nicht mehr oder nur per Trimmung von rxgain/txgain (geht bei Asterisk übrigens live während eines Gesprächs) gemindert werden kann...

Habe die Echos nun fast vollständig mit rxgain=0.2 und txgain=-0.2 eliminieren. Den "Hörermikro Volume"-Wert der Snom 370 Telefone musste ich noch auf 6 anheben. Ab einem "Hörermikro Volume"-Wert von 7 übersteuert die Sendeleistung und Gesprächspartner klagen über krachen in der Leitung. Der Ausschlag im dahdi_monitor bestätigt die Übersteuerung.

Obwohl der oslec echo canceller laut http://www.rowetel.com/blog/?page_id=454 offiziell keine "tweaks" benötigt, scheine ich durch das "Tweaken" doch ein besseres Filterergebnis zu erreichen.

Mit Hilfe einer "US-williwatt-Testnummer", die ich unter http://www.blindhog.net/phone-directory-from-phreaksandgeekscom/ gefunden habe (Leider konnte ich keine deutsche Testnummer ausfindig machen...) und der Anleitung unter http://www.mattgwatson.ca/2008/05/howto-tune-zaptel-dahdi-fxo-interfaces-on-asterisk-pbx/ konnte ich meinen Empfangswert korrigieren. Die Korrektur der Sendewerte nach dieser Anleitung brachte leider noch nicht die erhoffte Echo-Linderung...

Den Sendewert musste ich subjektiv (nach Sicht) mit Hilfe von

Code:

dahdi_monitor 1 -vv

während eines Telefonats mit einer echolastigen Gegenstelle anheben. Sende- und Empfangsleistung haben nun in etwa den gleichen Ausschlag im dahdi_monitor.

Momentan erhalte ich nur noch hörbare Echos bei eingeschalteter Freisprecheinrichtung meiner Gesprächspartner.

swenz · 2 Mrz 2011

Hallo zusammen,

was bei euch letztes Jahr prima funktionierte, tut's bei mir nicht. Ich habe alles, was ich finden konnte, durchgearbeitet und verglichen. Es sieht alles gut aus, aber es tut's nicht. Wenn ich nach draußen telefoniere, bekomme ich

Code:

obelisk*CLI> 
  == Using SIP RTP CoS mark 5
    -- Executing [00179xxxxxxx@ihw:1] Verbose("SIP/user1-00000002", "2,ISDN Anruf zu 0179xxxxxxx") in new stack
  == ISDN Anruf zu 0179xxxxxxx
    -- Executing [00179xxxxxxx@ihw:2] Dial("SIP/user1-00000002", "dahdi/1/0179xxxxxxx,45,r") in new stack
[Mar  2 16:43:33] WARNING[1132]: app_dial.c:1747 dial_exec_full: Unable to create channel of type 'dahdi' (cause 0 - Unknown)
  == Everyone is busy/congested at this time (1:0/0/1)
    -- Executing [000179xxxxxxx@ihw:3] Verbose("SIP/user1-00000002", "2,CHANUNAVAIL") in new stack
  == CHANUNAVAIL
    -- Executing [00179xxxxxxx@ihw:4] Hangup("SIP/user1-00000002", "") in new stack
  == Spawn extension (ihw, 00179xxxxxxx, 4) exited non-zero on 'SIP/user1-00000002'

Aber mal der Reihe nach. Ich benutze:
- Ubuntu 10.10
- Asterisk 1:1.6.2.7-1ubuntu1.1
- dahdi 1:2.2.1-0ubuntu2
- libpri 1.4.11.2-1
- kernel 2.6.35-27-generic-pae
- Network controller [0280]: Cologne Chip Designs GmbH ISDN network controller [HFC-PCI] [1397:2bd0] (rev 02)
Subsystem: Cologne Chip Designs GmbH ISDN Board [1397:2bd0]
Flags: bus master, medium devsel, latency 16, IRQ 17
I/O ports at ec00 [disabled]
Memory at febff400 (32-bit, non-prefetchable)
Capabilities: [40] Power Management version 1
Kernel driver in use: vzaphfc
Kernel modules: zaphfc, hisax, hfcpci

Es sieht meiner Ansicht nach alles gut aus:

- cat /proc/dahdi/1
Span 1: ZTHFC1 "HFC-S PCI A ISDN card 0 [TE] " (MASTER) AMI/CCS

1 ZTHFC1/0/1 Clear (In use) (SWEC: OSLEC)
2 ZTHFC1/0/2 Clear (In use) (SWEC: OSLEC)
3 ZTHFC1/0/3 Hardware-assisted HDLC (In use)

- dahdi show status
Description Alarms IRQ bpviol CRC4 Fra Codi Options LBO
HFC-S PCI A ISDN card 0 [TE] OK 0 0 0 CCS AMI YEL 0 db (CSU)/0-133 feet (DSX-1)
DAHDI_DUMMY/1 (source: HRtimer) 1 UNCONFI 0 0 0 CAS Unk YEL 0 db (CSU)/0-133 feet (DSX-1)

dahdi show channels
Chan Extension Context Language MOH Interpret Blocked State
pseudo default default In Service
1 incoming de default In Service
2 incoming de default In Service

- pri show span 1
Primary D-channel: 3
Status: Provisioned, Down, Active
Switchtype: EuroISDN
Type: CPE
Overlap Dial: 0
Logical Channel Mapping: 0
Timer and counter settings:
N200: 3
N202: 3
K: 1
T200: 1000
T202: 10000
T203: 10000
T303: 4000
T305: 30000
T308: 4000
T309: 6000
T313: 4000
T-HOLD: 4000
T-RETRIEVE: 4000
T-RESPONSE: 4000
Overlap Recv: No

/etc/dahdi/system.conf:

Code:

span = 1,0,0,ccs,ami
bchan = 1-2
hardhdlc=3
echocanceller = oslec,1-2
loadzone = de
defaultzone = de

/etc/dahdi/modules

Code:

dahdi
zaphfc
dahdi_transcode
dahdi_echocan_oslec
dahdi_dummy

/etc/asterisk/chan_dahdi.conf

Code:

[trunkgroups]

[channels]
language=de
switchtype=euroisdn

pridialplan=dynamic
prilocaldialplan=local
internationalprefix = 00
nationalprefix = 0
localprefix = 0xxxx
privateprefix = 0xxxxyyyyyyy
unknownprefix =
priindication = outofband

facilityenable = yes
usecallerid=yes
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
immediate=no
echocancel=yes
echocancelwhenbridged=yes
echotraining=yes
callgroup=1
pickupgroup=1
mohinterpret=default
mohsuggest=default

group=1
signalling=bri_cpe_ptmp
; p2p TE mode  => bri_cpe
; p2mp TE mode => bri_cpe_ptmp
; p2p NT mode  => bri_net
; p2mp NT mode => bri_net_ptmp
context=incoming
channel => 1-2

Hardware und Verkabelung sind auch ok, der alte Asterisk 1.4 läuft unter Debian mit mISDN wie gehabt und derselbe Test sieht so aus:

Code:

obelisk*CLI> 
    -- Executing [00179xxxxxxx@ihw:1] Verbose("SIP/user1-081ef300", "2|ISDN Anruf zu 0179xxxxxxx") in new stack
  == ISDN Anruf zu 0179xxxxxxx
    -- Executing [000179xxxxxxx@ihw:2] Dial("SIP/user1-081ef300", "mISDN/1/0179xxxxxxx|45|r") in new stack
    -- Called 1/0179xxxxxxx
    -- mISDN/1-u3 is proceeding passing it to SIP/user1-081ef300
    -- mISDN/1-u4 is ringing
    -- mISDN/1-u4 answered SIP/user1-081ef300
  == Spawn extension (ihw, 00179xxxxxxx, 2) exited non-zero on 'SIP/user1-081ef300'

Ich habe bestimmt irgendwo einen blöden Fehler drin. Am Code sollte doch nichts mehr falsch sein, nachdem letztes Jahr alles funktioniert hat, oder?

Es wäre sehr nett, wenn ihr mal drübergucken und den Knackpunkt finden würdet. Danke im voraus

privi · 2 Mrz 2011

Malcreatiure schrieb:
Muss glücklicherweise nicht. Hier eine kleines Howto:

Voraussetzung Installiertes Ubuntu Lucid (ich nahm 64bit), HFC-S PCi Karte im TE Modus.

Code:

$> apt-get install install dahdi dahdi-dkms dahdi-linux

die automatisch generierten Module wieder löschen:

Code:

$> dkms remove -m dahdi -v 2.2.1+dfsg-1ubuntu2 --all

aktuelles base.c für das Modul zaphfc herunterladen:

Code:

$> wget http://zaphfc.googlecode.com/svn-history/r7/branches/2.2/zaphfc/base.c -O /usr/src/dahdi-2.2.1+dfsg-1ubuntu2/drivers/dahdi/zaphfc/base.c

das Modul erneut bauen

Code:

$> dkms add -m dahdi -v 2.2.1+dfsg-1ubuntu2

Code:

$> dkms install -m dahdi -v 2.2.1+dfsg-1ubuntu2

Asterisk und dahdi neu starten bzw. laden oder das System neu starten. fertig.

@Malcreatiure:

Bei mir kommt mit Ubuntu Lucid 32 Bit beim Punkt

Code:

$> dkms install -m dahdi -v 2.2.1+dfsg-1ubuntu2

ein Fehler:

Code:

$ dkms install -m dahdi -v 2.2.1+dfsg-1ubuntu2

Error! Could not locate dahdi_dummy.ko for module dahdi in the DKMS tree.
You must run a dkms build for kernel 2.6.32-28-generic-pae (i686) first.
$

kann es sein dass man erst noch

Code:

$ dkms build -m dahdi -v 2.2.1+dfsg-1ubuntu2

machen muss?

Derzeit scheitere ich hieran:

Code:

[Mar  2 18:23:35] WARNING[3856]: app_dial.c:1745 dial_exec_full: Unable to create channel of type 'DAHDI' (cause 34 - Circuit/channel congestion)

Larry · 3 Mrz 2011

Moin!

swenz schrieb:
Status: Provisioned, Down, Active
[...]
Kernel driver in use: vzaphfc
Kernel modules: zaphfc, hisax, hfcpci

Es sieht meiner Ansicht nach alles gut aus:

Hmmm...der Channel ist down...
Kannst Du per lsmod sicher stellen, dass hisax und hfcpci auch wirklich nicht geladen sind (auch nicht zuvor geladen wurden)? Narrensicher wäre ein Blacklist-Eintrag der Module und Reboot des PC.

pridialplan=dynamic
prilocaldialplan=local

Setzte die beiden doch mal bitte auf unknown. Ich konnte bei zaphfc mit dynamic und local nie richtig etwas mit anfangen, im Gegenteil, eher gab es gelegentlich seltsamen Ärger. Am stabilsten läuft es bei mir halt mit unknown.

Außerdem ist mir aufgefallen, dass Du mittels

dial(dahdi/1/${EXTEN}....)

wählst; das ist an sich zwar nicht falsch, wird Dir aber später ganz bestimmt noch Probleme bereiten, denn so Du wählst IMMER auf dahdi-Channel 1. Was aber, wenn der z.B. bereits durch einen anderen Ruf belegt ist? Richtig, Du kommst nicht 'raus... Also besser per

dial(dahdi/g1/${EXTEN}....)

wählen (ist ja auch so mittels group=1 in der chan_dahdi.conf definiert)

-
Larry

Larry · 3 Mrz 2011

...was mir noch aufgefallen ist:

- Asterisk 1:1.6.2.7-1ubuntu1.1
- dahdi 1:2.2.1-0ubuntu2
- kernel 2.6.35-27-generic-pae

Vielleicht ist auch das dahdi/zaphfc-Modul veraltet; dahdi liegt schon länger in der Version 2.4.0 vor, und auch hierfür gibt es reichlich geänderten Code für zaphfc .

-
Larry

swenz · 3 Mrz 2011

Danke für deine Antworten, Larry. Nachdem ich hisax und hfcpci in die Blacklist aufgenommen und rebootet hatte, blieb das Problem. Dann habe ich mich deinem zweiten Kommentar zugewandt, den Ubuntu-Asterisk samt Dahdi deinstalliert, mir die Quellen geholt und neu gebaut. Das ging auch ganz prima, aber da ist ja kein zaphfc drin. Also habe ich zaphfc da hineingebastelt, so wie du es in deinem Patch dahdi-linux-2.2.0.2_zaphfc.tar.bz2 gemacht hast. Aber so geht das nicht. Zuerst fand er linux/autoconf.h nicht. Darauf habe ich linux durch generated ersetzt. Jetzt gibt es großes Gemotze:

Code:

make -C drivers/dahdi/firmware firmware-loaders
make[1]: Betrete Verzeichnis '/usr/src/dahdi-linux-2.4.0/drivers/dahdi/firmware'
make[1]: Verlasse Verzeichnis '/usr/src/dahdi-linux-2.4.0/drivers/dahdi/firmware'
make -C /lib/modules/2.6.35-27-generic-pae/build SUBDIRS=/usr/src/dahdi-linux-2.4.0/drivers/dahdi DAHDI_INCLUDE=/usr/src/dahdi-linux-2.4.0/include DAHDI_MODULES_EXTRA=" " HOTPLUG_FIRMWARE=yes modules DAHDI_BUILD_ALL=m
make[1]: Betrete Verzeichnis '/usr/src/linux-headers-2.6.35-27-generic-pae'
  CC [M]  /usr/src/dahdi-linux-2.4.0/drivers/dahdi/zaphfc/zaphfc.o
In file included from /usr/src/dahdi-linux-2.4.0/drivers/dahdi/zaphfc/zaphfc.c:28:
/usr/src/dahdi-linux-2.4.0/drivers/dahdi/zaphfc/zaphfc.h:5: error: expected identifier or ‘(’ before ‘<’ token
/usr/src/dahdi-linux-2.4.0/drivers/dahdi/zaphfc/zaphfc.h:17: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘logged_in_user_email’
/usr/src/dahdi-linux-2.4.0/drivers/dahdi/zaphfc/zaphfc.h:20: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘relative_base_url’
...

Hast du irgendwo eine Anleitung, wie ich das hinkriege?

Viele Grüße
Susanne

Larry · 4 Mrz 2011

swenz schrieb:
Hast du irgendwo eine Anleitung, wie ich das hinkriege?

*räusper* nicht wirklich...habe unter Ubuntu noch nie ein eigenes Package gebaut...
Macht aber auch nix; gestern ist eine neue Version von dahdi/dahdi-tools erschienen, wofür ich gerade eben ein Package für Gentoo gebaut und publiziert habe.
Die fix-und-fertig gepatchten Sourcen (so, wie sie Gentoo bauen würde) habe ich Dir hinterlegt; versuche doch mal bitte damit Dein Glück...: dahdi-linux-2.4.1 und dahdi-tools-2.4.1

-
Larry

privi · 4 Mrz 2011

Bei mir läufts...

Bei mir läufts jetzt mit Debian Squeeze wie unter

http://www.ip-phone-forum.de/showthread.php?t=230918#post1681513

beschrieben.

HFC-Karte mit Dahdi und Asterisk 1.6

Neuer User

Neuer User

Neuer User

Neuer User

Anhänge

Aktives Mitglied

Aktives Mitglied

Neuer User

Aktives Mitglied

Neuer User

Aktives Mitglied

Aktives Mitglied

Aktives Mitglied

Neuer User

Neuer User

Neuer User

Neuer User

Neuer User

Neuer User

Neuer User

Neuer User

Statistik des Forums