ISDN-Audiocodec über SIP-Strecke benutzen?

Status
Für weitere Antworten geschlossen.

VerTex

Benutzer
Hallo Zusammen,

mich beschäftigt folgende Frage:

Kann man "alte" ISDN Codecs wie Dialog4 oder CDQ in der heutigen Zeit auch über eine internetbasierende Telefonstrecke benutzen?

Ich stelle mir das so vor, dass man z.B. im Studio und am Außenveranstaltungsort einen DSL Anschluss hat, an dem jeweils eine FritzBox mit internem S0 Anschluss hängt. Die eine Fritzbox ist an der anderen als SIP Client angemeldet und soll dann vom Audiocodec von ISDN nach SIP (Internet) umsetzen. Im Studio wandelt die dortige Box das SIP "Signal" wieder in das ISDN "SIgnal" zurück und schickt es an den Codec.

Dass dieses mit einem datenkomprimierenden Voicecodec auf der SIP Strecke nicht funktionieren kann, ist mir klar, aber kann man nicht irgendwo festlegen, dass ein verlustloser/transparanter Codec verwendet wird, der die 64kBit 1:1 durchreicht?

Nur mal so in den Raum gesponnen, um die alten Geräte für (unkritische!) Audioübertragung weiter verwenden zu können. Zum Wegwerfen sind sie zu schade ...

Bin auf Eure Meinungen gespannt

VT
 
Nope!

Die Idee ist an sich toll, aber......
Die ISDN-Kisten wollen ihre Verbindung Framen bis ein Sync entsteht.
Dazu benötigen sie wohl auch den ISDN B-Kanal.
Jedenfalls machen sie das auf der Euro-ISDN Norm.

Falls Du DSL hast, verwende moderne AOIP-Codecs zur Übertragung, die können das.
Diese S0-Bus ISDN-Schnittstelle an den Fritz!Boxen ist nur ein "pseudo-ISDN"
für ISDN-Telefon Endgeräte. Den wird ISDN vor gegaukelt. (Nicht für ISDN-Codecs geeignet)

Und ja, die alten Kisten kann man bald wegwerfen.
Schade drum, aber sie brauchen "echtes" ISDN.

Bestandskunden werden ihr ISDN zwar behalten können, aber neue kommen nicht hinzu
bzw. werden nach und nach alle auf SIP und AOIP umsteigen.


Gruß Codo
 
Also,

völlig undenkbar ist das erstmal nicht, aber ich bin mir zu 99% sicher, dass das in der Praxis scheitern wird.

Problem sind die grundlegend unterschiedlichen Eigenschaften von ISDN- und IP-Netzen (TDM/synchron vs. Paketvermittelt/asynchron). Die ISDN-Codecs gehen von Eigenschaften aus, die keine IP-Strecke liefern kann. Alles, was man probieren könnte, kann für einen bestimmten Einsatzzweck funktionieren, aber ein genrelles "ISDN transparent über IP tunneln" ist nicht möglich. Selbes Problem hat man mit Fax over IP, es keine 100%-Lösung, um über IP in der selben Qualität mit den alten Faxgeräten zu arbeiten.

Als Ansatz denkbar ist RFC4040, der eine transparente Verpackung eines 64kbit/s ISDN D-Kanals über IP versucht und z.B. von FritzBoxen unterstützt werden soll. Gedacht ist dies für EC-Kartenterminals etc., die allerdings keine synchrone Verbindung brauchen (Timing ist vernachlässigbar). Die Fritzboxen unterstützen laut Google RFC4040 / "Clearmode", aber auch hier stehen wir vor dem Problem, die Daten entweder zuverlässig (über TCP) oder annähernd im richtigen Timing (UDP) aber keinesfalls synchron zu erhalten. Während bei einer bekannten und benannten Audiocodierung Paketverlust von den beteiligten User Agents (IP-Codecs, Telefone, Gateways) zufriedenstellend abgehandlet werden kann, gibt es beim Clearmode keine Möglichkeit, hier richtig zu reagieren, der ISDN-Codec kriegt also unerwartete Daten, es gibt Aussetzer, die Verbindung bricht zusammen, was weiss ich. Falls es doch funktioniert, hängt es evtl. extrem von der Qualität des Netzwerkes ab, sollte es z.B. im LAN funktionieren kann es trotzdem übers Internet überhaupt nicht gehen.
Zudem weiss ich nicht, ob bei RFC4040 die ISDN-Signalisierung überhaupt so weitergegeben wird, dass die Codecs einen gültigen Verbindungsaufbau erkennen. Hier kenne ich mich zu wenig mit den unteren Schichten des ISDN (und dem, was die Codec-Hersteller dort machen) aus, um das vorauszusagen. Es gibt Lösungen, die Q.931-Tunneling über H.323 oder SIP machen (z.B. von Cisco und Patton), aber da wird's extrem aufwändig -> IP-Codecs kaufen ist dann auf jeden Fall billiger und besser. RFC4040 sagt auch nichts über Kanalbündelung aus, das müsste auch aktiv abgehandelt werden, um zumindest die beiden 64kbit-Kanäle in sich synchron zu haben.

Einzig für Denkbar halte ich: G.722 aka "Wideband-Telefonie". Die Fritzboxen können den 16kHz/mono G.722 Codec zwischen ISDN und SIP umsetzen. In der VoIP-Welt ist G.722 recht verbreitet (zumindest implementiert), und bietet extrem viel bessere Audioqualität als der Telefonie-Standard G.711 A-law. Wenn dein ISDN-Codec G.722 unterstützt und mit der Fritzbox über dessen Verwendung handelseinig wird, kannst du die alten ISDN-Codecs zumindest als sehr gute Telefonhybriden weiterverwenden. In dem Fall würden die bei Clearmode auftretenden Nachteile nicht vorhanden sein, weil auch in der IP-Welt G.722 signalisiert wird und kein unbekannter Datenstrom bitgenau durchgereicht werden muss.

Gruß, Markus
 
Mit der Fritz!Box (in meinem Fall 7390), ihrer CAPI- und TAPI-Funktionalität übers Netzwerk habe ich mich die Tage hinreichend gequält. Das Fazit: unterm Strich funktioniert nur SIP wirklich gut und da mag sie am liebsten G.711 A-Law. Alles andere lief entweder nicht besser oder gleich gar nicht. Wie oben schon angemerkt wurde, macht die Fritz!Box intern praktisch gar nichts anderes als SIP. Will heißen: Es wird jeder Anschluß umgesetzt und über das interne Gate gerouteet.
 
Wie oben schon angemerkt wurde, macht die Fritz!Box intern praktisch gar nichts anderes als SIP. Will heißen: Es wird jeder Anschluß umgesetzt und über das interne Gate gerouteet.

Wo haste die Info her? Das halte ich für unwarscheinlich. So wie ich gehört habe (ich finde keine Unterlagen) basiert das Telefonie-Switching in der Fritzbox auf einer CAPI-Architektur, in der der/die SIP-Gateways als CAPI-Interface auftaucht. Das würde Sinn machen, da AVM ja historisch genau hier ihre Kompetenzen hat. Das hiesse dann, dass zumindest Verbindungen zwischen interner/externem S0-Bus und den Analogports in einem TDM-Kontext bleiben.
 
Bei den Fritzboxen wäre ich nach eigener Erfahrung zumindest skeptisch, ob das wirklich intern alles transparent bzw. über CAPI abgehandelt wird. Stichwort: Telefon-Daemon auf der Box. Der kann zwar nach außen ne ganze Menge, scheint aber wenig dokumentiert. Ich gehe nicht davon aus, dass AVM den selbst entwickelt hat. Dafür spricht auch, dass faktisch alles in den Fritzboxen in übersichtlichen ASCII-Configfiles eingestellt wird, der Telefonbereich jedoch sein eigenes Süppchen mit einer (vermutlich binären Konfigurationsdatei) kocht und grundlegende Funktionen (z.B. internes Weiterleiten mit Nebenstellen zwischen den Ports), was ansich jede "Billig-Telefonanlage" kann AFAIK nicht unterstützt. Ich habe bei dem Versuch, solches zu realisieren, mehrmals graue Haare bekommen.
 
Das war ja eben das Problem, dass das zumindest mit der TAPI und CAPIoIP und dem Phoner nicht klappte. Ich ging ebenfalls davon aus, dass es günstig sein müsse, so auf den internen Bus zu kommen.
Beim Nachlesen im Forum des Herausgebers dieses Tools war dann zu erfahren, dass das an einer Reihe von Inkompatibilitäten der AVM-Treiber scheitert und deshalb empfiehlt der Herausgeber die Lite-Version, die ausschließlich ein SIP-Telefon darstellt. Neugierig, wie ich bin, konnte ich mir einen Blick in die Prozessliste der Box nicht verkneifen und stellte dort fest, dass für die aktiven Telefoniegeräte je ein SIP-Daemon auf localhost hängt.

Nachdem ich so stundenlang verzweifelt herumzukonfigurieren versuchte, habe ich entnervt akzeptiert, dass zumindest mit dem Phoner (nicht Lite, die gefällt mir nicht) wirklich nur SIP ernsthaft funktioniert. So ganz glücklich bin ich damit nicht. Auch mit der analogen Telefonie nicht, da die bei der 7390 grausam rauscht und in den ersten Sekunden eines Gesprächs ich mich mit leichter Latenz selbst höre, was auch für Umsetzung spricht. Ebenso die Funktionalität der automatischen Faxweiche, bei der ich schlicht nicht glaube, dass die so hardwaremäßig überhaupt umgesetzt werden konnte, wie sie funktioniert.

Da AVM aber traditionell nichts dokumentiert, was nicht zwingend dokumentiert werden muss, und auch sonst nichts herausrückt, werden die ganz genauen Interna wohl nur ersichtlich, wenn man die Hardware aufschraubt und sich in der Linux- und Busybox-Welt so gut auskennt wie in seiner Westentasche.
 
Mahlzeit!

Also wenn ich die Antworten richtig interpretiere, wird es nicht (zuverlässig) funktionieren? Framing ist ein Argument, keiner kann garantieren, dass der IP Stream über Stunden ohne Abriß stabil läuft :(

Vielen Dank in dir Runde!

VT
 
Das Problem (und das macht auch bei Fax over IP Schwierigkeiten) besteht aus 2 Komponenten: Jitter und Packet Loss... Beides Dinge, die bei ISDN keine Rolle spielen, da die Zeitschlitze in der übergeordneten Ebene fest vorgegeben sind, bei IP aber nicht.
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben