Video Based Screen Sharing (VBSS)

Die "Freigabe" eines Desktops in einer Lync/Skype for Business 1:1 Verbindung oder in einem Meeting war oft langsam und träge. Insbesondere war die Darstellung von Videos sehr ruckelig. Das lag an der eingesetzten Technik: Die Clients haben die Daten per RDP übertragen. RDP selbst kann aber maximal 8 Frames/Sek übertragen. Für normale "Bildschirmarbeit im Rahmen eines Terminal Server Betrieb ist das ausreichend.

Mit Lync und Skype for Business ist aber schnell zu merken. dass die Performance besser sein könnte. Mit einem Update im Februar und März 2016 hat Microsoft den Client erweitert, damit er einen "Video-Strom" (H.264 content sharing) mit 15fps anstelle von RDP sendet.

Einschränkung

Aktuell funktioniert das nur bei 1:1 Desktop-Sharing Verbindungen ohne Fernsteuerung. Immer wenn so eine "Desktop Sharing Session" zu einer Konferenz hochgestuft wird oder der Betrachter die Steuerung übernimmt, wird dynamisch der Codec wieder auf RDP zurück gestellt. Ein Wechsel zurück auf H264 erfolgt aber nicht mehr, wenn nur noch zwei Personen im Meeting sind oder die Steuerung an den Präsentierenden zurück übergeben wird.

Dies kann man auch in den Status-Meldungen (QoE-Report) sehen:

51031; reason="This session starting with VbSS"; UserType="Callee"; 
MediaType="application-sharing-video"; 
MediaChanBlob="NetworkErr=no error,ErrTime=0,RTPSeq=0,SeqDelta=0,RTPTime=3711340580526,
   RTCPTime=0,TransptRecvErr=0x0,RecvErrTime=0,TransptSendErr=0x0,SendErrTime=0,
   InterfacesStall=0x0,InterfacesConnCheck=0x0,MediaTimeout=0,BlobVer=1";
BaseAddress="192.168.102.34:50042";
LocalSite="192.168.102.34:50050";
NetworkName="netatwork.de";
RemoteSite="10.2.0.5:8766"; 
MediaEpBlob="ICEWarn=0x0,ICEWarnEx=0x0,LocalMR=80.66.20.21:59910,RemoteMR=123.123.123.46:55767,
   PortRange=50040:50059,LocalMRTCPPort=58145,RemoteMRTCPPort=55767,LocalLocation=2,RemoteLocation=2,
   FederationType=1,StunVer=2,CsntRqOut=0,CsntRqIn=0,CsntRspOut=0,CsntRspIn=0,Interfaces=0x2,
   BaseInterface=0x2,IceRole=2,RtpRtcpMux=1,AllocationTimeInMs=230,FirstHopRTTInMs=2,TransportBytesSent=0,
   TransportPktsSent=0,IceConnCheckStatus=3,PrelimConnChecksSucceeded=0,IceInitTS=3711340575557,
   ContactSrvMs=241,AllocFinMs=291,FinalAnsRcvMs=0,FirstPathMs=4719,BlobGenTime=3711340580538,
   MediaDllVersion=6.0.8953.259,BlobVer=1";
MediaMgrBlob="MrDnsE=avedge.netatwork.de,MrResE=0,MrErrE=11001,MrBgnE=37113405755499536,
   MrEndE=37113405755513864,MrDnsI=nawsfbedge.netatwork.de,MrResI=1,MrErrI=0,
   MrBgnI=37113405755456728,MrEndI=37113405755489952,MrDnsCacheReadAttempt=0,BlobVer=1"

Wenn Dann aber die Fernsteuerung aktiviert wird, dann ist auch das als Falback zu sehen:

51034; reason="RDP fallback - Control given/control granted"; UserType="Callee"; 
MediaType="application-sharing-video";
MediaChanBlob="NetworkErr=no error,ErrTime=0,RTPSeq=0,SeqDelta=0,RTPTime=3711340732816,
   RTCPTime=3711340732617,TransptRecvErr=0x0,RecvErrTime=0,TransptSendErr=0x0,
   SendErrTime=0,InterfacesStall=0x0,InterfacesConnCheck=0x0,MediaTimeout=0,BlobVer=1";
BaseAddress="192.168.102.34:50042";
LocalAddress="80.66.20.21:59910";
LocalSite="192.168.102.34:50050";
NetworkName="netatwork.de";
RemoteAddress="123.123.123.46:54662";
RemoteSite="10.2.0.51:8766";
MediaEpBlob="ICEWarn=0x20,ICEWarnEx=0x0,LocalMR=80.66.20.21:59910,
   RemoteMR=123.123.123.46:55767,PortRange=50040:50059,LocalMRTCPPort=58145,
   RemoteMRTCPPort=55767,LocalLocation=2,RemoteLocation=2,FederationType=1,
   StunVer=2,CsntRqOut=30,CsntRqIn=30,CsntRspOut=30,CsntRspIn=30,
   Interfaces=0x2,BaseInterface=0x2,Protocol=0,LocalInterface=0x2,LocalAddrType=2,
   RemoteAddrType=2,IceRole=2,RtpRtcpMux=1,AllocationTimeInMs=230,FirstHopRTTInMs=2,
   TransportBytesSent=7956,TransportPktsSent=240,IceConnCheckStatus=4,PrelimConnChecksSucceeded=0,
   IceInitTS=3711340575557,ContactSrvMs=241,AllocFinMs=291,FinalAnsRcvMs=0,FirstPathMs=4719,
   ReinviteRcvMs=9710,AckReinviteSntMs=9752,FCsntRqSntMs=9801,FCsntRqRcvMs=9910,LCsntRqSntMs=155849,
   LCsntRqRcvMs=155729,BlobGenTime=3711340732871,MediaDllVersion=6.0.8953.259,BlobVer=1";
MediaMgrBlob="MrDnsE=avedge.netatwork.de,MrResE=0,MrErrE=11001,MrBgnE=37113405755499536,
   MrEndE=37113405755513864,MrDnsI=nawsfbedge.netatwork.de,MrResI=1,MrErrI=0,
   MrBgnI=37113405755456728,MrEndI=37113405755489952,MrDnsCacheReadAttempt=0,BlobVer=1"

Die Einträge sollten in der Art auch in dem lokalen UCCAPI-Log zu sehen sein.

Zukunft

Ich bin sicher, dass Microsoft hier weiter entwickelt. Rein technisch gibt es keinen Grund, dass ein Screen Sharing nicht auch in einer Konferenz über H.264 erfolgt. In der Office 365 Roadmap ist diese Funktion auch schon als "erwartet" dokumentiert.

Ich könnte mir ebenfalls vorstellen, dass auch wieder ein Wechsel von RDP zu "H.264 content sharing" möglich ist. Interessant ist dieser Codec auch für 3rd Party Produkte, die heute z.B. Bildschirm "mitschneiden" oder RDP wiedergeben (z.B. Polycom).

Mittlerweile unterstützt auch die IPad/IPhone-App die Funktion VbSS

Weitere Links