Microsoft fördert seinen Webstandard für Echtzeitkommunikation

Multimediadaten in Echtzeit auszutauschen, diese Fähigkeit sollen die Web-Browser der Zukunft haben. Das W3C arbeitet dazu an dem Standard WebRTC, von dem Chrome und Firefox bereits Teile integriert haben. Im August 2012 legte Microsoft einen Gegenentwurf vor und zeigt jetzt erstmals einen Prototypen für sein Protokoll.

Für ein Remake der Browser-Kriege des vergangenen Jahrhunderts dürften die Meinungsverschiedenheiten zwischen Microsoft und W3C jedoch nicht reichen. Denn das große Ziel ist das Gleiche: Browser sollen Video- und Audiodaten in Echtzeit ohne Plug-ins senden oder empfangen können. Während sich das W3C auf die direkte Brower-zu-Browser-Kommunikation konzentriert, hält der Softwarekonzern den Austausch mit beliebigen Multimediafähigen Systemen für wichtig.
WebRTC setzt bisher auf die Protokolle SIP (Session Initiation Protocol) und SDP (Session Description Protocol),  jedoch sind hier noch viele Fragen offen und Microsoft kritisiert diesen Ausgangspunkt: Die Technik sei nicht geeignet, mit VoiP-Geräten (Voice-over-IP-Technik) hinter Firewalls oder über diverse Router hinweg zu funktionieren. Zudem seien die Protokolle nicht zustandslos.

Microsofts CU-RTC-Web (Customizable, Ubiquitous Real-Time Communication over the Web) setzt hingegen auf RTP (Real-Time Transport Protocol) und RTCP (Real-Time Connection Protocol). Das an HTTP orientierte SIP wiederum bedient sich ebenfalls dieser beiden Protokolle. Bislang lässt sich jedoch mit dem vom W3C vorgesehenen SDP keine Verbindung aufbauen, die mehrere Streams über denselben Kanal überträgt.

Laut Microsoft füge sich CU-RTC-Web besser in die üblichen Web-Protokolle ein, da es zustandslos sei: Kein Kommunikationsteilnehmer müsse sich merken, was der andere getan habe oder gerade erwarte. Außerdem ermögliche es der Anwendung, auf sich ändernde Bandbreiten zu reagieren.

So könne sie sich für die bevorzugte Übertragung von Video- oder Audiodaten entscheiden oder schlicht auf eine höhere Übertragungsleistung warten. Mit SIP/SDP ist dies aber nicht möglich, da SDP alle Parameter für die gesamte Session oder den kompletten Stream festlegt. Anders als SDP will Microsofts Vorschlag viele Details nicht dem Protokoll, sondern den Anwendungen überlassen.