App-Sharing / Video Based Screen Sharing (VbSS)

Schon der Lync 2010 Client konnte eine "Desktop-Freigabe" nutzen, d.h. ein Anwender konnte den eigenen Desktop oder ausgewählte Programme dem anderen Kommunikationspartner zeigen. Dass eine "Datenverbindung" besser nicht über eine ungesicherte UDP-Verbindung laufen sollte, sollte einleuchten. Microsoft hat anfangs einfach den Weg gewählt, hier RDP als Übertragungsprotokoll zu nutzen. Das bliebt bis in Jahr 2016 und Skype for Business das primäre Protokoll.

Das Problem hierbei ist allerdings, dass die Anzeige manchmal verzögert und der Bandbreitenbedarf nicht zu unterschätzen ist. Daher hat Microsoft in 2016 einen zweiten Codec zugelassen. Unter dem Begriff "VBSS  Video based Screen Sharing" kann ein Bildschirm auch als "Video" (H264) über UDP übertragen werden. Bei Paketverlusten wird das Bild zwar etwas "matschig" aber es bleibt nicht stehen.

Einladung RDP in einer P2P Verbindung

Die Einladung ging an meine dynamische IP-Adresse auf der FritzBox (79.196.135.245) und wurde so an meinen Client weiter gegeben: (Zeilen teilweise umgebrochen)

INVITE sip:79.196.135.245:59039;transport=tls;ms-opaque=5f4b050c32;ms-received-cid=56A2C00 SIP/2.0
From: "KonfRoom1"<sip:demo@netatwork.de>;tag=xxx;epid=xxx
To: <sip:frank.carius2@netatwork.de>;epid=xxx
Call-ID: 579b99ee6cb8495ea7b35402fa69060c
CSeq: 1 INVITE
Contact: <sip:demo@netatwork.de;opaque=User:epid:SPszCrES2liHWE1OmaC5xQAA;gruu> 
  User-Agent: UCCAPI/15.0.4805.1000 OC/15.0.4805.1000 (Skype for Business)
Supported: ms-dialog-route-set-update
Ms-Conversation-ID: AdGF6XUwB6amAg2GSw2ydGyS1wqTHQAAbWLA
Supported: timer
Supported: histinfo
Supported: ms-safe-transfer
Supported: ms-sender
Supported: ms-early-media
ms-keep-alive: UAC;hop-hop=yes
Allow: INVITE, BYE, ACK, CANCEL, INFO, UPDATE, REFER, NOTIFY, BENOTIFY, OPTIONS
ms-subnet: 10.238.152.0
ms-endpoint-location-data: NetworkScope;ms-media-location-type=Intranet
Ms-Sensitivity: private-no-diversion
Supported: ms-conf-invite
Content-Type: application/sdp
history-info: <sip:frank.carius@netatwork.de>;index=1
ms-edge-proxy-message-trust: ms-source-type=AutoFederation;
   ms-ep-fqdn=nawsfbedge.netatwork.de;
   ms-source-network=federation;ms-source-verified-User=verified

v=0
o=- 0 0 IN IP4 80.66.20.22
s=session
c=IN IP4 80.66.20.22
b=CT:99980
t=0 0
m=applicationsharing 50856 TCP/RTP/AVP 127
a=ice-ufrag:9z3B
a=ice-pwd:M/k9HEoI1prOAT4N8YKTJ2Oh
a=candidate:1 1 TCP-PASS 2120613887 192.168.213.233 11136 typ host 
a=candidate:1 2 TCP-PASS 2120613374 192.168.213.233 11136 typ host 
a=candidate:2 1 TCP-ACT 2121006591 192.168.213.233 18657 typ host 
a=candidate:2 2 TCP-ACT 2121006078 192.168.213.233 18657 typ host 
a=candidate:3 1 TCP-PASS 2120612863 10.238.153.159 25357 typ host 
a=candidate:3 2 TCP-PASS 2120612350 10.238.153.159 25357 typ host 
a=candidate:4 1 TCP-ACT 2121005567 10.238.153.159 9417 typ host 
a=candidate:4 2 TCP-ACT 2121005054 10.238.153.159 9417 typ host 
a=candidate:5 1 TCP-PASS 174454783 80.66.20.22 50856 typ relay raddr 10.238.153.159 rport 3417 
a=candidate:5 2 TCP-PASS 174454270 80.66.20.22 50856 typ relay raddr 10.238.153.159 rport 3417 
a=candidate:6 1 TCP-ACT 174847487 80.66.20.22 50856 typ relay raddr 10.238.153.159 rport 3417 
a=candidate:6 2 TCP-ACT 174846974 80.66.20.22 50856 typ relay raddr 10.238.153.159 rport 3417 
a=cryptoscale:1 client AES_CM_128_HMAC_SHA1_80 inline:8G2cFD7261KcLIxieX3/7WD+h8gnFPC9XHVh5iAG|2^31|1:1
a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:8kBrdbEcPCR8TEsFh/WEImJ/BCUiAISg6kLzfyTJ|2^31|1:1
a=crypto:3 AES_CM_128_HMAC_SHA1_80 inline:43CW52joJxYTyQlVlpH0C+57HxKFZASUb4/Kl9Gg|2^31
a=setup:active
a=connection:new
a=rtcp:50856
a=mid:1
a=rtpmap:127 x-data/90000
a=rtcp-mux
a=x-applicationsharing-session-id:1
a=x-applicationsharing-role:sharer
a=x-applicationsharing-media-type:rdp

Gut zu sehen ist hier, dass es diesmal keine UDP-Kandidaten im Angebot gibt. RDP geht nur über TCP. Die öffentliche IP-Adressen ist aber die AV-Edge und die Rolle ist ein "Sharer

Die Antwort enthält ebenfalls nur TCP Kandidaten und die Rolle als Viewer:

SIP/2.0 200 OK
From: "KonfRoom1"<sip:demo2@netatwork.de>;tag=xxx;epid=xxx
To: <sip:frank.carius2@netatwork.de>;epid=xxx;tag=xxx
Call-ID: 579b99ee6cb8495ea7b35402fa69060c
CSeq: 1 INVITE
Contact: <sip:frank.carius2@netatwork.de;opaque=User:epid:xxx;gruu> 
  User-Agent: UCCAPI/15.0.4805.1000 OC/15.0.4805.1000 (Skype for Business)
Supported: histinfo
Supported: ms-safe-transfer
Supported: ms-dialog-route-set-update
Allow: INVITE, BYE, ACK, CANCEL, INFO, UPDATE, REFER, NOTIFY, BENOTIFY, OPTIONS
Session-Expires: 720;refresher=uac
ms-endpoint-location-data: NetworkScope;ms-media-location-type=Internet
Supported: ms-conf-invite
Proxy-Authorization: TLS-DSK qop="auth", realm="SIP Communications Service", opaque="A56BCE98", 
  targetname="NAWLYNC002.netatwork.de", crand="c93cf8b5", cnum="1748", 
  response="xxxxxxxxxxxxxxxx"
Content-Type: application/sdp
Content-Length: 1437

v=0
o=- 0 1 IN IP4 80.66.20.21
s=session
c=IN IP4 80.66.20.21
b=CT:99980
t=0 0
m=applicationsharing 55202 TCP/RTP/SAVP 127
a=ice-ufrag:cTV3
a=ice-pwd:Pe6DfB41/jtBL0KaiJBYciaW
a=candidate:1 1 TCP-PASS 2120613887 192.168.178.55 4387 typ host 
a=candidate:2 1 TCP-ACT 2121006591 192.168.178.55 23646 typ host 
a=candidate:3 1 TCP-PASS 2120612863 192.168.56.1 28198 typ host 
a=candidate:4 1 TCP-ACT 2121005567 192.168.56.1 31378 typ host 
a=candidate:5 1 TCP-PASS 2120611839 192.168.182.1 31602 typ host 
a=candidate:6 1 TCP-ACT 2121004543 192.168.182.1 1048 typ host 
a=candidate:7 1 TCP-PASS 2120610815 192.168.23.1 3911 typ host 
a=candidate:8 1 TCP-ACT 2121003519 192.168.23.1 27014 typ host 
a=candidate:9 1 TCP-PASS 2120609791 192.168.178.77 26068 typ host 
a=candidate:10 1 TCP-ACT 2121002495 192.168.178.77 5246 typ host 
a=candidate:11 1 TCP-PASS 174451711 80.66.20.21 55202 typ relay raddr 79.196.135.245 rport 23397 
a=candidate:12 1 TCP-ACT 174844415 80.66.20.21 55202 typ relay raddr 79.196.135.245 rport 23397 
a=candidate:13 1 TCP-ACT 1684793343 79.196.135.245 23397 typ srflx raddr 192.168.178.55 rport 23397 
a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:QkiyNCs0d3Bg8/f6/FMTZsN2Ct2ZSR0FRk+X5D6Z|2^31|1:1
a=setup:active
a=connection:existing
a=mid:1
a=rtpmap:127 x-data/90000
a=rtcp-mux
a=x-applicationsharing-session-id:1
a=x-applicationsharing-role:viewer
a=x-applicationsharing-media-type:rdp

Interessant: Hier kommen "High"-Ports der Edge Server zum Einsatz, obwohl die Edge Server auf diesen Ports von Extern gar nicht zu erreichen sind. Das sieht aber nur so aus, denn in Realität ist es ja eine "RELAY"-Adresse und damit tunnel der Client dies über 3478 oder 443 zum Edge Server. Das ist hier aber nicht ersichtlich weil es für die Gegenseite ja auch irrelevant ist, wie der Client zum TURN-Server kommt

Weitere Links