CAPIoTCP (NetCAPI): bei VoIP/All-IP-Anschlüssen keine saubere Rufnummernübermittlung?

[telchef]

Hallo zusammen!

System:

FRITZ!Box 7390
- FRITZ!OS 06.23 edit -> inzwischen 06.30 (keine Veränderung)
- CAPI aktiviert
- Telekom All-IP-Anschluß (kein externes ISDN mehr)

Windows 8 Pro 64 bit

FRITZ!fax_3.07.04.exe (Build 11.12.01)
- capi2032.dll (3.8.3.0)
- capi2032.dll vom "FRITZ!"-Programmverzeichnis ("C:\Program Files (x86)\FRITZ!\") in's "C:\Windows\SysWOW64\" verlegt, damit auch andere CAPI-Prgramme (welche die CAPI-DLL im Systemverzeichnis erwarten) die Netzwerk-CAPI nutzen können.

Shamrock CapiInfo


Shamrock CapiDog


---------------------------------------

Problem:

AVMs Netzwerk-CAPI stellt ja 5 virtuelle Controller zur Verfügung.

Entsprechend http://www.wehavemorefun.de/fritzbox/CAPI-over-TCP:

•	Controller 1: ISDN - extern - 2 B-Kanäle 
•	Controller 2: ISDN - extern - 2 B-Kanäle 
•	Controller 3: S0-Bus - intern - 2 B-Kanäle 
•	Controller 4: POTS - extern - 1 B-Kanal 
•	Controller 5: SIP - extern - 3 B-Kanäle 
Der Unterschied von Controller 1 und 2 ist (noch) unklar.

Der erste (oder die ersten beiden) stellt ja den externen ISDN-Anschluß der FB dar. Kamen früher über Extern-ISDN Anrufe rein, konnte man diese mit CapiDog sehen.
(Ein externer ISDN-Anruf wurde auf Controller 1 und Controller 2 als "klingelt" dargestellt. Und auf Controller 3, falls am internen S0 ein ISDN-Telefon oder eine ISDN-Anlage angeschlossen ist [egal ob in der FB als Telefoniegerät eingerichtet oder nicht]: )




Kommt nun über Extern-VoIP ein Anruf rein, wird dieser nur noch auf dem Controller 3 gezeigt (Intern-S0);
ich hätte erwartet, daß man ihn auch an Controller 5 sehen müßte:



(Das ist z.B. wichtig, wenn man keinen internen S0 hat oder kein Telefoniegerät/TK-Anlage daran eingerichtet ist, um trotzdem Anrufe an der Netzwerk-CAPI sehen zu können.)


Versendet man per FRITZ!fax ein Fax über VoIP nach Extern, wird im CapiDog nichts angezeigt (als ob kein Anruf stattfindet).



Frage:

Funktioniert Controller 5 nicht sauber? Hat da jemand Erfahrungen?



FRITZ!fax (eingestellt auf Controller 5 bzw "FRITZ!Box Internet") erkennt dagegen auf jeden Fall reinkommende Anrufe bzw. dessen kommende Rufnummern.
Grundsätzlich scheint also Controller 5 zu funktionieren.




(Ziel ist übrigens, bei einem Anwendungsprogramm, das einen ISDN-Anrufmonitor hat, VoIP-Anrufe [die über VoIP-"Amtsleitung" reinkommen] anzeigen zu können. Mir scheint dort aber keine Nummer rüberzukommen.)


Gruß, Harald

 

[telchef]

Übrigens (gerade getestet):

Wenn ich der FRITZ!Box 7390 einen analogen Amtsanschluß verpasse, dann kann ich via FRITZ!fax (über Controller 4 bzw. "FRITZ!Box Amtsanschluß Analog") auch Faxe erfolgreich empfangen und senden.

Aber auch dabei bleibt der CapiDog still (es wird nichts bei Controller 4 - Kanal 1 angezeigt). Ist also genauso wie bei den externen VoIP-Kanälen der FRITZ!Box.

Die Netzwerk-CAPI scheint also bei externen analogen/VoIP-Anrufen nicht so normal zu signalisieren, wie bei externen ISDN-Anrufen.
Sieht so aus, als könnte man so die Netzwerk-CAPI nicht zum Anzeigen von Rufnummern/Anrufern nutzen. -> Mist!
(Allerdings kann ja FRITZ!Fax eine übertragene VoIP-Anrufer-Rufnummer erkennen.)


Gruß, Harald

 

[telchef]

Noch eine Untersuchung mit FRITZ!fon gemacht:

Mit Parameter -c5 gestartet, um mit Controller 5 zu arbeiten ("C:\Program Files (x86)\FRITZ!\FriFon32.exe" -c5) funktioniert dieses Softphone von AVM auch über die Netzwerk-CAPI.
FRITZ!fon zeigt auch die Anrufer-Rufnummer. Aber auch hier bleibt CapiDog still.


Gruß, Harald

 

[telchef]

Controller 4 ist ja POTS extern und somit für analoge Amtsanschlüsse gedacht, der soll ja nicht auf FONx reagieren.

Und Controller 1 ist ISDN extern und reagiert auch auf externe Anrufe. Ich sehe da nicht den Unterschied, den Du meinst.

Bei Controller 5 vermute ich, dass der Standard AVM Eigenbau ist und der CAPIdog zu inkompatibel ist.

Vermuten kann man das. Mir geht es eher um Wissen oder Erfahrung.


Gruß, Harald

 

[informerex]

bitte mal das Tool aus der Signatur verwenden, damit wir eine Übersicht haben, ob die cpai2032 korrekt installiert wurde und wo.

des weiteren welche konkrete Problem hast du nun?
zumal CAPIdog kein AVM-Tool ist.

PS: es gibt die Möglichkeit deine Beiträge zu editieren, weil in so kurzer Zeit mehrere Beiträge ist nicht gern gesehen

//edit:
Firmware-Update für FRITZ!Box 7390 auf FRITZ!OS 06.30

 

[telchef]

bitte mal das Tool aus der Signatur verwenden, damit wir eine Übersicht haben, ob die cpai2032 korrekt installiert wurde und wo.

Die (einzige) capi2032.dll (Version 3.8.3.0) liegt, wie im Ursprungspost beschrieben, hier:
C:\Windows\SysWOW64\capi2032.dll
Daher ist sie richtig installiert - Pikachus *.exe wird für sowas einfaches nicht benötigt.

des weiteren welche konkrete Problem hast du nun?
zumal CAPIdog kein AVM-Tool ist.

Fehlende Anrufer-Rufnummer-Anzeige durch die Netzwerk-CAPI von AVM oder die FB für Drittanbieter-Applikationen.

PS: es gibt die Möglichkeit deine Beiträge zu editieren, weil in so kurzer Zeit mehrere Beiträge ist nicht gern gesehen

Danke für den Hinweis. Ich hatte den Eröffnungsbeitrag bereits ein paar mal editiert.
Die beiden Ergänzungs-Posts wollte ich nicht mit reinnehmen - der Eröffnungsbeitrag war eh schon etwas länglich.

//edit:
Firmware-Update für FRITZ!Box 7390 auf FRITZ!OS 06.30

Du meinst, das Update löst das Problem?
Aber danke - war mir noch nicht aufgefallen, daß schonwieder eine neue Version da ist.

Edit:
Das FRITZ!OS-Update bringt leider nichts in Sachen Rufnummernanzeige über Netzwerk-CAPI.
(Dafür fehlt nun der telnet-Zugang... )


Gruß, Harald

 

[andiling]

Pikachus *.exe wird für sowas einfaches nicht benötigt.

Na dann...

Wende Dich an den Support von dem von Dir genutzten Programm und kläre dort, warum dies mit dem AVM Tool nicht funktioniert.

 

[informerex]

Daher ist sie richtig installiert - Pikachus *.exe wird für sowas einfaches nicht benötigt.

das Tool zeigt nicht nur den Ort an, sondern bspw. auch die IP, ob richtig eingetragen usw. usw.
wir leben von Informationen und solche Basis-Infos gehören dazu

wenn du keine Hilfe benötigst, hat sich deine Anfrage ja erledigt bzw. andilings-Stellungnahme schließe ich mich an

 

[telchef]

Pikachus *.exe wird für sowas einfaches nicht benötigt.

Na dann...

Wenn Du das nicht glaubst, fehlt Dir offenbar etwas an Kompetenz. Entschuldige, auf so niedrigem Niveau wollte ich die Sache hier nicht besprechen; daß Computer- bzw. FRITZ!Box-Laien hier nicht weiterkommen, dürfte klar sein.

(Hast Du Deinen ersten Beitrag gelöscht? Schade.)

Wende Dich an den Support von dem von Dir genutzten Programm und kläre dort, warum dies mit dem AVM Tool nicht funktioniert.

Danke, aber solche "Tips" brauche ich nicht, denn ich ziehe mir die Hose nicht mit der Kneifzange an.
(Nebenbei: Da mit CapiDog die Ruf-Erkennung auf Controller 1-3 funktioniert, nur auf den Nicht-ISDNern 4-5 nicht, vermute ich, das die Sache eher bei AVM liegt.)


Gruß, Harald

P.S. Zu meiner Frage "Funktioniert Controller 5 nicht sauber? Hat da jemand Erfahrungen?" im Eröffnungsbeitrag konntest Du leider nichts beitragen. Offenbar nicht mal Erfahrungen. Schade.

 

[telchef]

das Tool zeigt nicht nur den Ort an, sondern bspw. auch die IP, ob richtig eingetragen usw. usw.
wir leben von Informationen und solche Basis-Infos gehören dazu

wenn du keine Hilfe benötigst, hat sich deine Anfrage ja erledigt bzw. andilings-Stellungnahme schließe ich mich an

Ich habe mehr als genug Infos geliefert - vergleiche das mal mit anderen Beiträgen...

Was hat die IP in der Registry mit der Frage der Rufnummernanzeige bei Controller 4 und 5 zu tun?
Daß die Netzwerk-CAPI bei mir grundsätzlich funktioniert, dürfte aus meinen Beiträgen hervorgehen.
Sinnlos-Anfragen, die nichts mit dem Thema zu tun haben, wie z.B. auch zur Farbe und Größe meines Monotors und ähnliches braucht hier niemand.

Pseudo-Hilfe von Laien, die keinerlei oder Laien-Erfahrungen mit der Netzwerk-CAPI haben, brauche ich in der Tat nicht.


Gruß, Harald

 

[telchef]

Was hast du für ein Monotor? Oder meinst du den ISDN-Monitor? Welche Version hast du da verwendet?

Oh, ein Windows-3.11-Programm mit Systray-Anzeige und Webserver...

Sieht mir etwas spartanisch aus - kann immerhin Griechisch! (Der Autor hätte mal lieber etwas zu dem Programm und den Möglichkeiten schreiben sollen. Aber gut, ist ein untechnisches Minimalprogramm, gratis, und für meine Zwecke unbrauchbar.)


Gruß, Harald

P.S. Ich meinte mit Monitor eigentlich das LCDisplay, welches die Rufnummern anzeigt (oder auch nicht).

 

[qwertz.asdfgh]

Vermutung:
Es fehlt bei SIP und POTS ersteinmal die Informationen des D-Kanal (worauf CapiDog in den genannten Fällen angewiesen ist), für den internen S0-Bus muss dieses erstellt/emuliert werden. Wobei ich dann wiederum nicht verstehe wie die CAPI-Anwendungen überhaupt funktionieren (bei Verwendung von Controller 5) wenn ihnen keine Informationen per (emulierten) D-Kanal auf Controller 5 zur Verfügung stehen und scheinbar stehen die Informationen auch bei einem echtem externen ISDN-Anschluss nicht auf dem emulierten Controller 5 zur Verfügung (also werden die D-Kanal Informationen auch prinzipiell nicht auf Controller 5 weitergeleitet).

Das die Informationen nun auf Controller 1 und 2 fehlen ist ja verständlicherweise nachvollziehbar, dort wird es also ohne ISDN-Anschluss in Zukunft logischerweise still bleiben aber ich hätte in der Tat erwartet, dass es bei 5-x "klingeln" müsste (übrigens auch schon zu ISDN-Zeiten und nicht erst mit VoIP), wie soll sonst z.B. FritzFon oder FritzFax ankommende Rufe erkennen (was sie ja aber interessanterweise tun)? Erlaubt die CAPI-Schnittstelle evtl. noch eine andere "Signalisierungsmethode" ohne D-Kanal? Oder wird das ganze nur in einer Variante des emulierten D-Kanal übertragen mit dem CapiDog nichts anfangen kann und daher still bleibt? Dann würde mich folgende Erklärung noch weniger verwundern als bisher:

Die Lauffähigkeit anderer ISDN/CAPI-Programme mit der FRITZ!Box ist nicht vorgesehen.

Allerdings (ist jedoch auch schon wieder Jahre her das ich mich damit beschäftigt habe) gab es ja mal (oder noch) die Möglichkeit per dtrace den D-Kanal mit zuschneiden, funktioniert das bei aktuellen FritzBoxen immer noch (einfach mal unter http://fritz.box/capture.lua nachschauen)? Wenn ja dann einfach mal mitschneiden (und auswerten), dann weiß man woran man ist bzw. wo der Fehler zu suchen wäre.

Und wie sieht es aus wenn du mit FritzFax oder FritzFon eine aktive Verbindung hast (per Controller 5), zeigt dann CapiDog bei 5-1 bis 5-5 einen B-Kanal als belegt an?

Kurzum, damit muss man wohl leben (zumindest was 1-x betrifft) und sich (wenn benötigt und Controller 5 tatsächlich "still" ist) eben die Informationen vom internen S0-Bus besorgen (dieser muss ja nicht real verwendet werden, aber u.U. muss es wohl eine FritzBox mit internemS0-Bus sein? Ich kann mir nicht vorstellen, das Controller 3 funktioniert bei FritzBoxen ohne internen S0-Bus da man bei diesen Modellen auch keine ISDN-Telefone oder ISDN-Anlage einrichten kann (was aber notwendig ist um die D-Kanal Information auf den Controller 3 zu bringen).

Jedenfalls eine interessante Feststellung, da ist man nun vorgewarnt (falls man das doch noch mal benötigen sollte) und weiß nun, dass es u.U. auch eine FritzBox mit internem S0-Bus braucht auch wenn man diesen nicht wirklich benötigt...

 

[telchef]

Hallo qwertz.asdfgh!

Danke für Deinen guten Beitrag und den Hinweis zum D-Kanal und dem Trace.


Ich vermute, für die "analogen Kanäle" (Analog-Trunk und SIP-Trunk) werden schon D-Kanal-Informationen emuliert.
(Zumindest sind ja Informationen über deren Aktivität da, und sicher auch digital, und dann kann man diese sicher leicht per CAPI bereitstellen.)

Ich meine, Du hast Controller 5 falsch verstanden:
Das ist nicht ein virtueller Controller, der quasi eine virtuelle S0-Schnittstelle (nur) für FRITZ!fax bereitstellt, sondern der stellt den virtuellen Controller dar, der die VoIP-Anrufe verarbeitet, quasi den "SIP-Trunk-Controller".
(FRITZ!fax benutzt dann nur diesen Controller, wenn man ihn auswählt - eben weil FRITZ!fax über den SIP-Trunk arbeiten soll.)

Insofern meldete der Controller 5 auch keinen Anruf, wenn über den ISDN-Trunk (externer S0) einer reinkam.
ISDN-Trunk-Anrufe sind auf dem Controller zu sehen, auf dem sie reinkommen, nämlich Controller 1. (Aus noch unbekannten Gründen gleichzeitig noch auf dem unbekannten Controller 2.) Und eben auf dem Controller 3, welcher der interne S0 ist - weil sie dort hingeleitet werden, zwecks Übergabe an ein ISDN-Telefon oder eine ISDN-TK-Anlage.

Also: Auf Controller 5 sollte nur Aktivität gezeigt werden, wenn über den SIP-Trunk Anrufe abgewickelt werden.

Und so ist es auch:
Im DTrace (Dein Tip) sind eindeutig Anruferdaten vom VoIP-Anrufer auf Controller 5 zu sehen.

(In die D-Kanal-Infos muß ich mich jetzt noch grundsätzlich reinarbeiten.
Zunächstmal kann ich ja die Unterschiede suchen, bei einem ISDN-Trunk-Anruf und bei einem SIP-Trunk-Anruf.
Wenn die gleich sind, würde es wohl an CapiDog liegen - obwohl ich mir nicht vorstellen kann, daß CapiDog nur für Controller 1-3 funktioniert, und für 4-5 nicht. Immerhin kann es die Controller ganz normal erkennen und darstellen.)

Und wie sieht es aus wenn du mit FritzFax oder FritzFon eine aktive Verbindung hast (per Controller 5), zeigt dann CapiDog bei 5-1 bis 5-5 einen B-Kanal als belegt an?

Weder in der Rufphase, noch in der Verbindungsphase zeigt CapiDog für Controller 5 was an. Weder bei abgehenden "Fritz-Faxen", noch bei kommenden.


Gruß, Harald

 

[telchef]

Das reicht an Vermutungen. Jetzt ist erstmal wieder Wissen gefragt.

Dann beglücke uns doch mal mit Wissen - ich bin in diesem Thread schließlich der Fragesteller (von mir wird es nicht kommen, sonst wäre das Problem keins oder schonbeseitigt).


Gruß, Harald

P.S. Ich staune, wieviel Mühe sich jemand gibt, ein völlig nutzloses Posting mit 3 Zitaten zusammenzuklamüsern...
Wenn Du in dieser Sache einen kompetenten Beitrag hättest leisten können, hättest Du es sicher getan. Welchen Sinn hat also Dein Gequatsche? Beitragszähler erhöhen?

 

[qwertz.asdfgh]

Ich vermute, für die "analogen Kanäle" (Analog-Trunk und SIP-Trunk) werden schon D-Kanal-Informationen emuliert.

Ja, sonst könnten diese Informationen nicht auf dem internen S0-Bus vorhanden sein bei einem VoIP/POTS-Anschluss. Die Frage ist eben ob es Unterschiede gibt zwischen den Controllern und dafür kann man dtrace verwenden um das festzustellen.

Ich meine, Du hast Controller 5 falsch verstanden

Das ist mir im Nachhinein auch gerade klar geworden (hatte früher mit ISDN tatsächlich immer Controller 1 verwendet, das hatte ich vergessen). Das erklärt aber nur warum Controller 5 "still" bleibt bei einem ISDN-Anschluss aber nicht warum er nun bei VoIP "still" bleibt (5-1 bis 5-5 steht für die 5 gleichzeitig verwendbaren SIP-Kanäle der FritzBox welche intern wie extern verwendet werden können (ein Unterschied zu den Controllern 1-4), daran hatte ich vorhin noch nicht gedacht (obwohl logisch)).

(FRITZ!fax benutzt dann nur diesen Controller, wenn man ihn auswählt ...)

Das wiederum war und ist klar.

Im DTrace (Dein Tip) sind eindeutig Anruferdaten vom VoIP-Anrufer auf Controller 5 zu sehen.
---
Zunächstmal kann ich ja die Unterschiede suchen, ...

Genau das ist die Frage, in wie weit unterscheiden sich die D-Kanal Informationen vom Controller 3 (interner S0) zu Controller 5 (und evtl. Controller 1/2 bei ISDN-Anschluss)? Vielleicht findet man dann die Ursache des Problem.

Wenn die gleich sind,

Davon gehe ich jetzt einfach mal nicht aus, sonst würde es das Problem ja eigentlich nicht geben...

... obwohl ich mir nicht vorstellen kann, daß CapiDog nur für Controller 1-3 funktioniert, und für 4-5 nicht.

Vielleicht könnte aber genau das die Ursache sein (was wiederum meiner Annahme im vorhergehenden Satz widersprechen würde) obwohl:

Immerhin kann es die Controller ganz normal erkennen und darstellen.

Aber wie KunterBunter schon schrieb, nun ist Wissen gefragt anstatt weiterer Annahmen und dieses wiederum kann man aus den D-Kanal Mitschnitten "extrahieren"...

 

[telchef]

Hier mal die Anfänge der Traces. Ein paar Unterschiede gibt's schon.
Siehe z.B. "Interface type:" und "Information channel selection:".

Edit: Habe die Zeichen der Rufnummern im Trace mal durch "x" bzw. "xx" ersetzt, statt die ganzen Hex-Kolonnen zu entfernen, und die sonstigen Bytes der D-Kanal-Message wiederhergestellt.

Anruf auf SIP-Trunk:

                    Controller 5 (RECEIVE)  D3    11:46:15:42
                    08 01 07 05 04 03 80 90 A3 18 03 A9 83 88 6C 0D
                    01 80 xx xx xx xx xx xx xx xx xx xx xx 6C 0E 30
                    80 34 39 xx xx xx xx xx xx xx xx xx xx 6D 0D 01
                    80 xx xx xx xx xx xx xx xx xx xx xx 4D 0D 01 80
                    xx xx xx xx xx xx xx xx xx xx xx A1 70 0A B0 37
                    23 xx xx xx xx xx xx xx 71 02 81 37 7D 02 91 81
                    Protocol discriminator Q.931: 08 
                    Call reference (from originator): 07 
                    SETUP: 05 
                      bearer capability: 04 03 80 90 A3 
                        Information transfer capability: speech
                        Transfer mode: Circuit mode
                        Information transfer rate: 64 kbit/s
                      channel identification: 18 03 A9 83 88 
                        [b]Interface type: other interface[/b]
                        Preferred/exclusive: exclusive
                        D-channel indicator: not the D-channel
                        [b]Information channel selection: indicated in the following octets[/b]
                      calling party number: 6C 0D 01 80 xx xx xx xx xx xx xx xx xx xx xx
                        Type of number: unknown
                        Numbering plan: ISDN/Telephony
                        Calling party number: xxxxxxxxxxx
                      calling party number: 6C 0D 01 80 xx xx xx xx xx xx xx xx xx xx xx
                        Type of number: network specific number
                        Numbering plan: unknown
                        Calling party number: xxxxxxxxxxx
                      calling party subaddress: 6D 0D 01 80 xx xx xx xx xx xx xx xx xx xx xx
                      connected subaddress: 4D 0D 01 80 xx xx xx xx xx xx xx xx xx xx xx
                      sending complete: A1 
                      called party number: 70 0A B0 37 23 xx xx xx xx xx xx xx            <- 7 # x x x x x x x
                        Type of number: network specific number
                        Numbering plan: unknown
                        Called party number: 7#xxxxxxx
                      called party subaddress: 71 02 81 37 
                      high layer compatibility: 7D 02 91 81 
                        High layer characteristics identification: telephony

Anruf auf ISDN-Trunk:

                    Controller 1 (RECEIVE)  D3    13:09:00:64
                    08 01 01 05 A1 04 03 80 90 A3 18 01 8A 6C 05 00
                    83 xx xx xx 70 04 81 xx xx xx 7D 02 91 81 
                    Protocol discriminator Q.931: 08 
                    Call reference (from originator): 01 
                    SETUP: 05 
                      sending complete: A1 
                      bearer capability: 04 03 80 90 A3 
                        Information transfer capability: speech
                        Transfer mode: Circuit mode
                        Information transfer rate: 64 kbit/s
                      channel identification: 18 01 8A 
                        [b]Interface type: basic interface[/b]
                        Preferred/exclusive: exclusive
                        D-channel indicator: not the D-channel
                        [b]Information channel selection: B2 channel[/b]
                      calling party number: 6C 05 00 83 xx xx xx
                        Type of number: unknown
                        Numbering plan: unknown
                        Calling party number: xxx
                      called party number: 70 04 81 xx xx xx 
                        Type of number: unknown
                        Numbering plan: ISDN/Telephony
                        Called party number: xxx
                      high layer compatibility: 7D 02 91 81 
                        High layer characteristics identification: telephony

Gruß, Harald

 

[PeterPawn]

Der "unbekannte" Controller 2 (ich habe gerade so gar keine Lust bei #1 mit dem Lesen zu beginnen) könnte (sind "Spekulationen" hier erlaubt?) der ebenfalls auf Q.931 umgesetzte DECT-Controller sein ... da sind die Unterschiede zum ISDN ja noch geringer als bei den anderen Emulationen.

Irgendwie habe ich so etwas im Hinterkopf (denkbar, daß da whmf nicht mehr stimmt) und außerdem fehlt der eben auch in der Liste der Telefonie-Schnittstellen.

Ein Test wäre ganz einfach ... beim Wählen einer abgehenden Rufnummer in einzelnen Ziffern (auch bei "en bloc", aber einzelne Ziffern sind in einem IE leichter zu finden im dtrace-Log) sollte eigentlich auf Controller 2 richtig Ballett sein, wenn man ein DECT-MT benutzt, noch bevor das auf einem anderen Controller in ein "call setup" mündet - es könnte ja auch eine "interne Steuerungsfunktion" sein. Auch müßte dann eigentlich auf C2 "immer etwas los sein", denn da werden ja häufiger Zustandsinformationen ausgetauscht - allerdings kann es auch sein, daß da nur das "boxseitige Interface" der DECT-Basis dranhängt und die Kommunikation zwischen BSC und MT da doch nicht zu sehen ist.

Ansonsten ist doch eine D-Kanal-Signalisierung auf C5 auch im dtrace in #16 zu sehen ... ist halt kein "B-Kanal". Wenn die bisher als "Anrufmonitor" getesteten Programme nur auf SETUP (bzw. später auf "ALERTING" oder was auch immer da kommen mag) reagieren, wenn ein B-Kanal involviert ist (das läuft halt in der Emulation als "other channel", ansonsten wären einige Programme sicherlich auch verwirrt, wenn ein SIP-Channel nicht alle Capabilities eines B-Kanals bietet - das geht bei den Protokollen auf B1-B3 los), dann wäre das ja auch eine Erklärung, warum so ein Monitor nicht bellt.

PS: Irgendwas stimmt auch mit der dtrace-Ausgabe nicht ... in einem IE sollten bei CLI/COL hexadezimale (max. noch dezimale) Daten auftauchen (ggf. auch als "string"). Die Zeichen A, C, D und E passen noch in dieses Schema, die Zeichen H, N, S, T, U und Z sind "out of range".

 

[telchef]

So, habe nun mal mit daCAPI die Aktivitäten auf den Controllern angeschaut.

Das Programm funktioniert besser und zeigt auch die Rufnummern auf Controller 5 (fast) wie erwartet an.

Bis auf "Called party number": Die wird von der FB ja als "7#5554321" im Trace dargestellt, d.h. die 7. konfigurierte SIP-Nummer (Index von 0 über 7 bis ...).
daCAPI zeigt die gerufene MSN dann als "75554321" (obwohl die MSN ja nur 5554321 lautet), es wird also die 7 mit reingenommen und das Doppelkreuz rausgefiltert. (Ob man das in daCAPI noch irgendwie umkonfigurieren kann, habe ich noch nicht herausgefunden.)

Also kann man davon ausgehen, daß Shamrock CapiDog die "D-Kanal-Meldungen" nicht vollständig/richtig auswertet.


Fakt ist außerdem mal leider das: Bei Applikationen, die nicht mit "Mehrcontroller"-CAPIs umgehen können, ist man in Sachen Rufnummernanzeige aufgeschmissen, wenn man einen VoIP-Anschluß an der FB hat, da diese eben nur den ersten Controller abfragen/bedienen können.
Das war eine Sache, die ich im Rahmen dieser Untersuchung herausfinden mußte. (Wenn man's jetzt weiß, ist's natürlich logisch.) Insofern ist es bei solchen Apps egal, was Controller 5 ausspuckt...

PS: Irgendwas stimmt auch mit der dtrace-Ausgabe nicht ... in einem IE sollten bei CLI/COL hexadezimale (max. noch dezimale) Daten auftauchen (ggf. auch als "string"). Die Zeichen A, C, D und E passen noch in dieses Schema, die Zeichen H, N, S, T, U und Z sind "out of range".

Ich sehe nicht, wo da H, N, S, T, U und Z sein sollen - oder meinst Du die von mir im Trace für die Veröffentlichung hier im Trace ersetzten "----DATENSCHUTZ----"?
Edit: Inzwischen habe ich die Traces oben verbessert (statt "----DATENSCHUTZ----" nun "x" eingefügt, wo Ziffern der Rufnummern standen).

Gruß, Harald

 

[PeterPawn]

Das sollte zwar nur ein Beweis meines absonderlichen Humors sein, aber wenn sich aus der Änderung jetzt der im Text von Dir herausgearbeitete Unterschied in der Signalisierung im CdPN-IE auch ablesen läßt, war das ja doch gar nicht so absonderlich.

Aber noch einmal ohne jeden Scherz ... es kommt ja bei jedem Monitor darauf an, wie er die für ihn selbst relevanten Nachrichten (auf einem D-Kanal sind ja auch die verschiedensten Informationen unterwegs) selektiert. Wenn dann durch die Emulation ein bestimmtes Merkmal anders "aussieht" als erwartet, dann rutscht so eine Message schon mal durch das Sieb.

Wenn man sich das CdPN-IE auf dem C5 mal einzeln anschaut, ist da ja schon ein Unterschied vorhanden:

70 -> CdPN-IE (Q.931-Spec., S. 67)
0A -> Länge der folgenden Daten (10)
B0 -> geteilte Bedeutung ... Bits 7,6,5 = 011 => Network specific number, Bits 4,3,2,1 = 0000 => unknown numbering plan

Dagegen auf C1:

70 -> CdPN-IE
04 -> Länge
81 -> 7,6,5 = 000 => unknown number type (das ist auch eher kein externer Anruf), 4,3,2,1 = 0001 => E.164 format (ISDN numbering)

Abgesehen davon, daß das auf C1 offensichtlich also auch "nur" ein interner Anruf war, sieht man einen deutlichen Unterschied in der signalisierten Nummer.

Der Präfix mit "7#" ist da eher Kosmetik ... wenn natürlich FRITZ!Fax um diese Eigenheit weiß und das entsprechend auswertet, ist schon klar, warum FRITZ!Fax damit klarkommt, andere Programme eben nicht.

Die erkennen dann u.U. eben nicht einmal, daß sie für eine Message zuständig sein könnten (weil die CdPN stimmt), wenn da - wie von daCAPI bei der Anzeige offenbar - nur die Raute gefiltert und nicht alles vor der Raute komplett ignoriert wird.

Wenn dann so ein Monitor noch auf die "81" als CdPN-Format "spekuliert" (oder auch auf 91, A1 ... wenn für ihn die Information "ISDN numbering" in den Bits 1-4 entscheidend ist), dann erkennt er den Eintrag ggf. gar nicht als für ihn gedacht bzw. nicht einmal als "normales Call-Setup". Das sieht ja dann - nach Deiner Schilderung - bei CapiDog wohl so aus, wenn da nicht einmal die - zweifellos ja lt. Trace vorhandenen - SETUP-Messages angezeigt werden.

Wenn Du nach einer Lösung zur Anzeige eingehender Anrufe suchst, brauchst Du also vermutlich einen Monitor mit offenem Quelltext, damit man erstens prüfen kann, wie da entschieden wird, ob die D-Kanal-Message relevant ist und zweitens das im Fall der Fälle an die eigenen Bedürfnisse anpassen kann.

EDIT/Fazit: Die Eingangsfrage "Funktioniert C5 nicht sauber?" würde ich also mit "Doch, durchaus." beantworten. Es ist ein Problem der Auswertung der D-Kanal-Messages, die in der Emulation sicherlich etwas anders "aussehen" können (m.E. immer noch Q.931-konform sind, daher "funktioniert das sauber") und damit kommen dann offenbar einige der von Dir verwendeten Programme trotzdem nicht klar. Warum das so ist, kann man wieder nur spekulieren ... ohne Blick in den Quelltext der Anwendung bringt das aber alles auch nichts.

EDIT2: Wie ein Blick auf die Webseite von Shamrock offenbart, werden dort auch nur ISDN-Karten unterstützt, das steht deutlich unter dem Text zum "CapiDog". Das macht die Filterung auf E.164 als "numbering format" für mich noch etwas wahrscheinlicher, wenn schon PRI-Karten (auch ISDN, aber für den PMX mit 30 B-Kanälen und Abweichungen im D-Kanal-Protokoll ggü. BRI) nicht richtig unterstützt werden - wobei da auch die Beschränkung auf zwei B-Kanäle in der Taskbar der Grund sein könnte; spannend wäre es ja mal, wie die Anzeige bei einer 4-S0-Karte aussehen würde.

EDIT3: Muß man #1 jetzt so verstehen, daß Du ein Programm schreibst, das einen ISDN-Anrufmonitor integriert hat und dieses an die AVM-NetCAPI anpassen willst? Wenn nicht, kannst Du ja mal einen Blick auf "JAnrufmonitor" werfen, vielleicht signalisiert dessen CAPI-Version ja auch auf C5 ordentlich einen eingehenden Anruf.

 

[telchef]

Hallo PeterPawn!

Danke für Deine Erklärungen zu den D-Kanal-Messages. Das hilft zum Verständnis der Sache gut.
Und ich denke, Deine Überlegungen sind genau richtig.

Abgesehen davon, daß das auf C1 offensichtlich also auch "nur" ein interner Anruf war, sieht man einen deutlichen Unterschied in der signalisierten Nummer.

Das könnte daran liegen, daß ich für Testanrufe den internen S0er einer TK-Anlage an den externen S0er der FB angeschlossen habe (mangels echtem ISDN-Amtsanschlusses inzwischen).
Ich nehme an, die signalisiert nicht genauso, wie es die Vermittlungsstelle tun würde.

EDIT3: Muß man #1 jetzt so verstehen, daß Du ein Programm schreibst, das einen ISDN-Anrufmonitor integriert hat und dieses an die AVM-NetCAPI anpassen willst? Wenn nicht, kannst Du ja mal einen Blick auf "JAnrufmonitor" werfen, vielleicht signalisiert dessen CAPI-Version ja auch auf C5 ordentlich einen eingehenden Anruf.

Nein, ich wollte eine/mehrere fertige Anwendungsprogramme mit integriertem ISDN-Anrufmonitor in Betrieb nehmen / testen (ohne ISDN-Karte im betroffenen PC). Dabei stieß ich auf die Probleme.
(Ein weiteres Problem ist schon alleine, daß einfache Programme nicht die Umstellung des Controllers in ihrem ISDN-Monitor zulassen...)

jAnrufmonitor (die CAPI-Variante) wollte ich auch noch testen, hatte aber noch keinen PC, wo ich das gefahrlos tun konnte.


Gruß, Harald