Der Artikel der letzten Woche hat erklärt, wie »Jami« Peer-to-Peer-Verbindungen mit ICE herstellt und TURN verwendet, falls dies nicht geht. (Falls du ihn nicht schon gelesen hast, solltest du dies auf jeden Fall tun, bevor du hier weiterliest, außer, du kennst dich schon sehr gut mit dieser Sache aus). Diese Protokolle sind in der PJSIP Bibliothek implementiert, auf die sich »Jami« stark verlässt, um direkte Verbindungen zwischen Teilnehmern auszuhandeln. Obwohl PJSIP als Referenz für Voice-over-IP-Kommunikationsanwendungen gilt, ist es nicht dafür ausgelegt, in einem verteilten Netzwerk zu funktionieren. Daher musste unser Team große Beiträge zum PJSIP-Projekt leisten. Um die Verbesserungen zu verstehen, ist es notwendig, den Unterschied zwischen UDP und TCP zu begreifen. Beide sind Datentransferprotokolle, die Maschinen erlauben zu kommunizieren, allerdings funktionieren sie anders.
TCP überwacht den Zustand jedes einzelnen versendeten Datenpakets und stellt sicher, dass sie zuverlässig übertragen wurden, indem der Empfänger den Erhalt jedes einzelnen Pakets bestätigen muss und der Sender verlorene Pakete erneut senden muss. UDP hingegen kümmert sich nicht um Paketverlust. Zwar ist es weniger zuverlässig, wird aber für Anwendungen wie z.B. Mediastreaming, bevorzugt, weil die Daten zeitkritisch sind. In diesen Fällen resultiert ein verlorenes Paket nur in kleinen Video- oder Audiofehlern, und darauf zu warten, dass das Paket erneut versendet wird, macht das Problem nur schlimmer, als einfach weiterzumachen. Allerdings kann beim Datentransfer ein einzelnes verlorenes Paket eine ganze Datei beschädigen. Daher ist Zuverlässigkeit wichtiger als Pünktlichkeit, und daher ist TCP für solche Falle besser geeignet.
PJSIP unterstützte TCP, aber nicht über ICE oder TURN, und daher mussten wir dies selbst implementieren, um Peer-to-Peer-Kommunikation zu ermöglichen. Wir haben damit begonnen, den RFC 6062 Standard in PJSIP zu implementieren, was so TCP-Datentransfer alleine über TURN ermöglichte. Dies wurde 2017 fertiggestellt und erlaubte uns die File-Sharing-Funktion zu »Jami« hinzuzufügen. Wir haben vor kurzem die Unterstützung für den RFC 6544 Standard in PJSIP fertiggestellt, die uns endlich ermöglicht, echte Peer-to-Peer-Dateitransfers in »Jami« über ICE über TCP durchzuführen, ohne einen TURN-Server zu benötigen.
Die Verbesserung, die wir vorgenommen haben, hat auch noch einen anderen wichtigen Vorteil. Während eines SIP-Anrufs ist immer ein Steuerkommunikationskanal zusätzlich zu einem Audio- und Videokanal offen. Der Steuerkanal hat viele Funktionen, er wird verwendet, um Anrufe zu starten, zu beenden, zu pausieren und fortzusetzen, Textnachrichten zu senden, die VCard, die den Avatar und Anzeigenamen beinhaltet, zu senden, Codecs zu vereinbaren und die Videoausrichtung zu ändern. Weil wir uns für diesen Kanal auf UDP verlassen mussten, konnte Paketverlust ab und an zu Problemen und unerwartetem Verhalten führen. In näherer Zukunft werden wir für diesen Kanal TCP verwenden und damit diese Probleme lösen und »Jami« so viel zuverlässiger machen.
Unsere Implementierung von RFC 6062 wurde inzwischen upstream vom PJSIP-Team integriert, und für unsere RFC 6544 Implementierung wird dies ebenfalls geschehen, sobald sie fertig ist. Dies macht die Funktionen für andere Anwendungen verfügbar, die auch diese Bibliothek verwenden. Dies ist ein perfektes Beispiel, wie Open-Source-Projekte wie »Jami« und PJSIP aufeinander aufbauen und wie sie zusammenarbeiten können, um sich gegenseitig zu verbessern. Das nächste Mal, wenn du eine Datei mit »Jami« verschickst, wirst du ein besseres Verständnis dafür haben, was alles im Hintergrund notwendig ist, um dies zu ermöglichen. Für mehr technische Details über den Dateitransfer in »Jami« kann man unsere Dokumentation lesen.
Von Sébastien Blin und François Naggar-Tremblay
