mISDN + app_pipe + HDLC = remote isdn port?

[WolfgangA]

Hallo,

für mISDN / chan_misdn gibt es app_pipe und die Möglichkeit HDLC für Datencalls zu aktivieren.

Ist es möglich mit chan_misdn / app_pipe einen ISDN Port von einer Asterisk via IP auf eine andere Asterisk umzuleiten?

D.h. ich schliesse eine z.b. ein ISDN Endgerät (Telefon, EC-Gerät etc.) auf einen mISDN Port am Standort A an, und verbinde am Standort B einen mISDN Port mit einen ISDN Anschluss.

Wolfgang

 

[crich]

ich verstehe deinen Plan nicht so ganz, aber mit app_pipe und hdlc kann man folgendes tun:

eine Einwahl in Asterisk per RAS, z.b. mit einer ISDN Karte unter windows. Damit kann man einen Asterisk Server Remote Administrieren wenn dieser nicht am Internet angeschlossen ist und deshalb keine möglichkeit besteht die Administration per Internet zu machen.

 

[WolfgangA]

Danke für die Info bzgl. RAS Einwahl. Ich vermute, in diesem Fall piped app_pipe die Datenverbindung auf pppd.

Mein Plan war/ist jedoch, einen physischen ISDN Port umzuleiten. (Eine "ISDN Bridge")
(also _keine_ Remote Capi)

D.h. einen mISDN Port auf Anlage1 via IP mit eine mISDN Port auf Anlage2 zu verbinden, um dann transparent ein ISDN Endgerät an Anlage1 nutzen, dessen ISDN Anschluss am mISDN Port auf Anlage2 konnektiert ist.

Beispiel: EC Karten Leser, Datenverbindungen, LKW Maud Station

Im Prinzip ähnlich wie eine Wireless Bridge (auf beiden Seiten Ethernet, unabhängig von Layer 3 Protokoll)

Geht soetwas mit mISDN/chan_misdn?

 

[pluto70]

Wäre TDMoe für Dich vielleicht eine Lösung? Habe mich damit noch nicht beschäftigt, aber von der Beschreibung her könnte es helfen.

http://www.voip-info.org/wiki/index.php?page=Asterisk+TDMoE

 

[crich]

naja zwei entfernte Rechner kannst du ja per VoIP mit IAX z.b. verbinden. soweit ich weiss reicht IAX die Asterisk Datenframes 1:1 zur gegenstelle weiter. In diesem fall müsstest du bei chan_misdn nur die hdlc=yes option aktivieren um einen hdlc frame pro asterisk frame zu lesen/schreiben, dann könnte das klappen. (natürlich nur wenn die Daten auch per HDLC codiert sind, bei ppp ist das der fall)

 

[WolfgangA]

Ja das scheint in die richtige Richtung zu gehen - Danke.

Jedoch ist mir nicht klar, on man damit nur PRI's bridgen kann, oder auch BRI's.
Muss ich im Detail angucken.

Wolfgang

 

[crich]

das ist egal ob pri oder bri

 

[divB]

Du könntest mal schaun ob LanCAPI was für dich ist! http://sourceforge.net/projects/capi20proxy oder rcapid oder so

 

[WolfgangA]

Das Problem mit dem CAPI Sharing ist, dass es eine Schnittstelle per SW zur verfügung stellt, keinen Remote ISDN Port in Hardware.

Möglicherweise kann man die Remote CAPI mit chan_capi wieder auf einen physischen ISDN Port bridgen, aber ich glaube nicht dass das stabil funktioniert.

Trotzdem Danke.

//Nachtrag: TDMoE ist grundsätzlich der richtige Ansatz.
Aber - es ist oE (over Ethernet) und nicht oIP. D.h. es funktioniert auf Layer 2 und nicht auf Layer 3 (IP) Ebene.
Beide Systeme muessen daher im selben Ethernet Segment stehen.
Die Anforderung an das Timing für TDM liegt bei 1ms. Daher wird sogar ein Crossoverkabel empfohlen.

 

[schlaile]

crich: IAX scheint das mit dem unveränderten Durchreichen der Daten nicht besonders ernst zu nehmen. Nach meinen Versuchen verwandelt sich der Datenstrom unauffällig durch IAX von Digital -> Speech. Selbst das Setzen der /h-Option mit dem Vorschlaghammer im Dial-Cmd des Ziel-Rechners überzeugt ihn nicht so wirklich.

(Zur Info: zwei ISDN-Karten im selben Rechner funktionieren mit misdn wunderbar, nur der Tunnel über IAX, wenn man zwei Rechner verwendet, vermurkst das ganze...)

Gibt es eigentlich einen Channel-Treiber bei Asterisk, der die Frames _tatsächlich_ völlig unverändert (von mir aus auch mit TCP, sollte bei HDLC ja eigentlich nix machen) durchschiebt?

Oder anders gefragt: was ist das sinnvolle Gegenstück zu

app_pipe(/usr/bin/ssh|fremdrechner|extension)

auf dem empfangenden Rechner?

Ich spiele gerade schon mit dem Gedanken einen reinen Daten-Channel-Treiber zu basteln oder alternativ reichlich merkwürdige Konstruktionen mit dem Agent-Interface in Kombination mit app_pipe und netcat zu basteln...

Wenn jemand eine intelligentere Lösung weiß, wäre ich sehr dankbar, da ich genau das gleiche brauche wie WolfgangA.

Viele Grüße,
Peter

 

[WolfgangA]

Es gibt zt_ethernet (oder ähnlich) als Treiber. Der Channeltreiber arbeitet auf Ethernet (Layer 2 Ebene) und _nicht_ auf IP / TCP oder UDP Ebene, wg. des Timings.
Man kann diesen Treiber nur innerhalb eines Netzwerksegments nutzen.
Für meine Anwendung kann ich den allerdings nicht nutzen.
D.h. auch mein "Problem" ist noch offen.

 

[schlaile]

... das Problem besteht für mich gerade darin, daß es über mehrere Switche läuft...

trotzdem: danke!

Viele Grüße,
Peter

 

[schlaile]

Hi Wolfgang,

Du wirst es nicht glauben, es geht

Das Problem ist, daß nach dem IAX-Transfer misdn mit sehr viel Liebe zur richtigen Anwahl überredet werden muß.

Bei mir ist die Konfiguration:

EC-Cash-Gerät -> Asterisk1 -> Ethernet -> Asterisk2 -> Amt

Der wesentliche Trick besteht jetzt darin, das Dial-Kommando auf Asterisk2 so abzusetzen, daß auch ein HDLC-Kanal ohne aktiviertem DSP aufgemacht wird, also:

Auf Asterisk1:

Dial(IAX2/userassword@asterisk2/${EXTEN}@from-iax);

Auf Asterisk2:

Dial(mISDN/1/${EXTEN}/h1n);

Habe mir gerade eben per PIN-Zahlung 1 Cent erfolgreich vom Konto abgebucht

Ist der 1-Parameter als Ergänzung zu "h" eigentlich irgendwo außerhalb des chan_misdn-Sourcecodes dokumentiert? Ich habe das erst durch misdn-Logvergleich rausbekommen...

"h" erzeugt einen Digital-Kanal, die "1"-Option setzt den Kanal dann auf HDLC, das "n" deaktiviert den DSP.

Viele Grüße & Viel Erfolg,
Peter

--
P.S.: Verwendete Asterisk-Version: 1.4.0, misdn: mISDN-1_1_2

 

[WolfgangA]

Hallo Peter,
Respekt!
Ich werde es ausprobieren!
Vielen Dank dass Du die Lösung gepostet hast.

VG

Wolfgang
P.S. Kannst Du vllt. nocheinmal etwas zur Stabilität schreiben wenn Du die Lösung etwas länger im Einsatz ist?

 

[schlaile]

Hallo zusammen,

was ich noch erwähnen wollte: bis mISDN Version 1.1.5 funktionierte der Trick nur an einer Nebenstelle unserer Alcatel-Anlage zuverlässig.

Mit 1.1.5 läuft es jetzt auch klaglos direkt am Amt.

Viele Grüße,
Peter