[Erledigt] ISDN Anlagenanschluss D-Kanal trace als Call Statistik auswerten

databoss

Neuer User
Mitglied seit
13 Jun 2005
Beiträge
5
Punkte für Reaktionen
0
Punkte
0
Ich habe ein paar grundsätzliche Fragen zum ISDN D-Kanal um damit falls möglich, eine Call Statistik zu erstellen.
Streng genommen ist dies keine Frage zu einem reinen VOIP Thema, doch tummeln sich hier so viele ISDN Experten, sodass ich denke, dass meine Frage hier sehr gut aufgehoben sein könnte.

Die Voraussetzungen:
In einer Firma haben wir 4 NTBA’s als Anlagenanschluss an einer kleinen Siemens HiCom angeschlossen. Trotz intensiver Bemühungen ist es mir nicht gelungen der Anlage zu entlocken was ich mir wünsche – eine einfache Call Statistik. Es gibt zwar Kauflösungen für die HiCom, die sind aber nicht so wie ich mir das vorstelle und zudem auch teuer.

Meine Idee:
ist nun die Verbindungen eine die Ebene davor aus dem D-Kanal auszulesen. Meine ersten Versuche in diese Richtung sind recht vielversprechend, werfen aber auch einige Fragen auf.

Bisherige Versuche:
Ich habe zunächst den D-Kanal trace auf meiner Fritzbox hier zuhause angesehen. Das sieht gut aus, ich denke dass ich mit meinen Programmierkenntnissen damit eine Datenbank füllen könnte um daraus dann eine Call Statistik zu erstellen.
In der Firma haben wir eine Bintec RT1202 als Faxempfänger die auch einen CAPI Server hat. Wenn ich nun dort den D-Kanal trace sehe ich nur die Faxe die dorthin geroutet werden mit der Meldung „Call wurde von einer anderen Applikation übernommen“ so dass ich auch keine Dauer des Gespräches sehen würde. Soweit klar, wenn ich mir das auch anders gewünscht hätte.

Fragen:
Meine Idee ist es nun eine Fritzbox (ohne Anrufannahme) an einen der NTBAs vor die Siemens HiCom zu hängen um von dort per Net CAPI das D-Kanal Protokoll auszuwerten.

Würde ich dort überhaupt alle ankommenden und abgehenden Gespräche mit Anfang und Ende sehen?

Hat jedes NTBA eines Anlagenanschlusses seinen eigenen D-Kanal oder sehen alle alles?

Habt ihr eine bessere/einfachere Idee an die Verbindungsdaten zu kommen?

Gibt es dazu vielleicht schon eine fertige Lösung?
 
Zuletzt bearbeitet:
Hat jedes NTBA eines Anlagenanschlusses seinen eigenen D-Kanal oder sehen alle alles?
Du redest sicherlich von BRI-Anschlüssen, ich kenne das Szenario nur mit 2 PRI-Anschlüssen für eine TK (genauer einen Telefonie-Server mit Dialogic-Hardware), das Prinzip dürfte aber dasselbe sein.

Jeder Anschluß hatte natürlich seinen eigenen D-Kanal. Es wurden auch eingehende Gespräche nicht auf beiden Anschlüssen signalisiert (so nach dem Motto "Wer schneller ist, gewinnt."), in der VSt wurde eine der beiden Leitungen gewählt (nach welchen Kriterien, das ließ sich in der VST konfigurieren, von Round-Robin bis streng sequentiell) und dann wurde auch nur auf dieser Leitung signalisiert.

War die Leitung bereits am Beginn der "Lotterie" nicht verfügbar (kein Framing oder voll belegt), wurde sie bei der Auswahl nicht berücksichtigt. Trat während der Signalisierung (vor der Annahme) ein Fehler auf der Leitung auf, wurde in der VSt der Vorgang von vorne gestartet.

Nun ist das vielleicht theoretisch bei 30 B-Kanälen pro Anschluß etwas anderes, aber da ein Anlagenanschluß ja per Definition nicht auf mehreren Anlagen enden kann (Point-to-Point), macht eine parallele Signalisierung auf mehreren Anschlüssen ja auch bei 4x2 Kanälen keinen Sinn, es "enden" ja alle D-Kanäle an derselben Stelle. Ich behaupte also einmal, Du bräuchtest ohnehin für jedes ISDN-"Kabel" einen "Lauscher" (und dann ist z.B. eine C4 oder sogar 4xA1 besser geeignet als eine FB), der dabei aber per Schnittstellen-Definition schon nicht erlaubt ist, da ein Anlagenanschluß - anders als ein Mehrgeräte-Anschluß - keine parallel angeschlossenen Endgeräte erlaubt. Du müßtest also dafür sorgen, daß Dein "Capture-Equipment" wirklich absolut passiv ist und seinerseits keinerlei Signalisierung von sich gibt, nicht nur keine Anrufe annimmt. Mit einer FRITZ!Box wird Dir das eher nicht gelingen.
Die "elektrische" Frage, also die zusätzliche Belastung des S0-Bus hinter dem Netzabschluß, dürfte m.E. nicht so kritisch sein, solange der Bus vom Netzabschluß ausreichend gespeist wird, notfalls also den Netzstecker des NTBA (beim AA normalerweise nicht nötig, da der NTBA von der VSt. gespeist wird und die TK auch eine eigene Versorgung hat) in eine passende Steckdose.
 
Zuletzt bearbeitet:
OK, habe ich gerade verwechselt.
 
Hallo,

ein ganz anderer Lösungsansatz:
Warum schließt Du nicht einfach an die serielle Schnittstelle der Anlage einen Windows XP Rechner mit laufendem Hyperterminal an?
Dann bekommst Du pro Gespräch einen Datensatz, und hast damit die Möglichkeit diese dann extern (z.B. mit Excel) weiterzuverarbeiten

Gruß S
 
Dann bekommst Du pro Gespräch einen Datensatz, und hast damit die Möglichkeit diese dann extern (z.B. mit Excel) weiterzuverarbeiten
Wenn das geht (ich kenne Siemens Hicom nicht), dann würde ich aber eher einen RasPi nehmen und mit dem die Daten lesen, aufbereiten und dann gleich per Web-Interface auf der LAN-Schnittstelle bereitstellen. ;)
 
Warum schließt Du nicht einfach an die serielle Schnittstelle der Anlage einen Windows XP Rechner mit laufendem Hyperterminal an?

Ja! Das war auch meine erste Idee, bis mir klar wurde das dass zur Gebührenerfassung gedacht ist und somit vermutlich nur die ausgehenden Gespräche erfasst, oder?
 
Du redest sicherlich von BRI-Anschlüssen

Ja, richtig.

Du bräuchtest ohnehin für jedes ISDN-"Kabel" einen "Lauscher" (und dann ist z.B. eine C4 oder sogar 4xA1 besser geeignet als eine FB), der dabei aber per Schnittstellen-Definition schon nicht erlaubt ist, da ein Anlagenanschluß - anders als ein Mehrgeräte-Anschluß - keine parallel angeschlossenen Endgeräte erlaubt.

Hmm ok - ich habe sogar noch eine C4 aus unserem alten Faxserver rumliegen.

Würden denn dann per Capi2032.dll alle 4 D-Kanäle auf einen Streich belauschbar sein?

Du müßtest also dafür sorgen, daß Dein "Capture-Equipment" wirklich absolut passiv ist und seinerseits keinerlei Signalisierung von sich gibt, nicht nur keine Anrufe annimmt. Mit einer FRITZ!Box wird Dir das eher nicht gelingen.

OK im Prinzip verstanden, denke ich.

Aber wie bitte kann sich denn sicherstellen, dass die Karte absolut passiv ist und keine Signalisierung von sich gibt?
Das kann ich mit praktisch im Moment nicht vorstellen wie ich darauf Einfluss habe.
 
Das kann ich mit praktisch im Moment nicht vorstellen wie ich darauf Einfluss habe.
Hast Du auch nicht, jedenfalls nicht mit irgendwelchen Treibern des Herstellers und schon gar nicht auf CAPI-Ebene.

Die darunterliegende Software dient ja gerade dazu, die Kommunikation auf Hardware-Ebene für Dich zu übernehmen, da muß man dann also schon direkt selbst ran.

Das ist sicherlich nicht Dein Interesse. Insofern wollte ich eigentlich auch eher klar machen, daß Deine Idee so nicht funktionieren kann, wenn man nicht wesentlich mehr Aufwand treibt, als Du es Dir vorstellst. Wenn das nicht deutlich genug herauskam aus den Begründungen, dann tut es mir leid und ich gelobe Besserung. Ich wollte halt nicht platt "geht nicht" schreiben, weil es eben mit entsprechendem Aufwand theoretisch auch machbar wäre. Das ist dann aber eher ein theoretisches Thema für irgendeine Abschlußarbeit als von praktischem Nutzen.

Du müßtest Dich quasi als passiver Lauscher am S0-Bus auf die Lauer legen und nur die vorbeirauschenden Frames eines nach dem anderen "nach oben" durchreichen und dann analysieren lassen. Dabei darf Deinerseits kein einziges Frame gesendet werden, deshalb habe ich auch bewußt die B1-Karte in meiner Aufzählung nicht erwähnt, weil die das bereits in ihrer Firmware erledigt und da willst Du sicherlich nicht auch noch einsteigen. ;)
Ich vermute mal (reiner Verdacht, durch nichts belegt bisher), da wird die Hardware irgendeinen Puffer haben (es kann natürlich auch sein, daß da wirklich byte-seriell gearbeitet wird) um ein komplettes Frame zu speichern (ggf. als Ringpuffer, damit während der "Verarbeitung" des vorherigen Frames das nächste gespeichert werden kann, 144 kBit/s sind ja nun auch nicht so eine riesige Herausforderung) und man müßte dieses dann mit einem passenden Kerneltreiber erst einmal nur abholen. Wenn es einen Linux-Treiber für passive ISDN-Karten von AVM gibt, müßte man da die Vorgehensweise ja nachsehen können. Solange man selbst nichts sendet, sollte man wie ein schwarzes Loch sein (eigentlich eher nicht, weil man ja nicht alles aufsaugt, andere Endgeräte sehen die Frames ja auch noch).
Daher würde ich sagen: theoretisch machbar, bei Deinem Anliegen bringt es Dich aber nicht unmittelbar vorwärts.

Wenn Dir ein einfaches "geht nicht" aber lieber gewesen wäre, reiche ich es nach: geht nicht.

Bist Du Dir eigentlich sicher, daß auf der seriellen nur ausgehende Gespräche dabei sind oder ist das nur eine Vermutung ?

EDIT: Jetzt kann natürlich jemand sagen, die Bitrate am BRI ist aber 192 kBit/s, aber da ist der Framing-Overhead mit drin und ich habe nur die 2 B-Kanäle und den D-Kanal zusammengerechnet, da ich erst einmal davon ausgehe, daß der ganze Synchronisationskram von der Hardware gemacht wird und deshalb wirklich nur der Payload der Frames abgeholt werden muß.
 
Zuletzt bearbeitet:
Wenn Dir ein einfaches "geht nicht" aber lieber gewesen wäre, reiche ich es nach: geht nicht.

Danke für die klaren Worte, wenngleich ich Deine ausführliche Schilderung noch mehr schätze, denn so konnte ich dazulernen.


Bist Du Dir eigentlich sicher, daß auf der seriellen nur ausgehende Gespräche dabei sind oder ist das nur eine Vermutung ?

Nein ich bin mir bei dem seriellen Ausgang nicht sicher, es ist aber sehr wahrscheinlich.
Ich werde das vermutlich aber jetzt als nächsten Schritt ausprobieren.
 
Bist Du Dir eigentlich sicher, daß auf der seriellen nur ausgehende Gespräche dabei sind oder ist das nur eine Vermutung ?

Man kann sich natürlich auch kommende Gespräche ausgeben lassen.

Gruß S.
 
Man kann sich natürlich auch kommende Gespräche ausgeben lassen.

Stimmt, ich habe mir das jetzt genauer angesehen... blöd das ich das nicht gleich nachgesehen habe und dem Verkäufer bzw. der Bezeichnung 'Gebührenerfassung' auf den Leim gegangen bin, denn der hat mir gesagt, dass dort nur gehende Gespräche ausgegeben werden.

Das geht sogar über LAN / TCP. :)

Wobei ich die Erfahrung gemacht habe, dass sich das interne LAN Interface der Anlage gerne aufhängt. Weiß jemand woran das liegt, bzw. Abhilfe?


Das Problem mit der Call Statistik ist jetzt auf jeden Fall gelöst.

Vielen Dank für den Tipp.
 
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.