Lors de la vidéoconférence (y compris le partage d’applications de bureau), il doit y avoir un dénominateur commun entre les plates-formes de la conférence afin qu’elles puissent toutes communiquer et comprendre efficacement le trafic envoyé et reçu.

Le but de cet article est d’expliquer les différences entre les différentes méthodes utilisées; H.239 ; BFCP ; RDP et VbSS par les principaux fournisseurs d’ appareils et de clients H.323 , SIP et Skype Entreprise lors du partage de données (bureau ou application) dans les vidéoconférences et en quoi ceux-ci diffèrent de l’ancienne norme T.120 précédemment utilisée via NetMeeting.

Terminologie – soyez clair sur ce que vous voulez dire:

Lorsque nous parlons de partage de données ou d’applications ou de collaboration, nous devons être clairs sur ce que nous voulons vraiment dire. En effet, selon le système que nous utilisons, le partage de données peut vraiment signifier la présentation de données; ou la collaboration de données pourrait en fait être un partage de données et non une véritable collaboration si nous cédions le contrôle de l’application partagée à quelqu’un d’autre. Nous espérons que la distinction deviendra plus claire au fur et à mesure que vous lirez ce document.

L’ancienne norme de partage de données T.120 a disparu:

Pour le partage de données (postes de travail complets, fenêtres ou applications), l’ UIT a initialement approuvé la norme T.120 . La base de T.120 a été initialement développée et proposée par Microsoft.

La norme T.120 permet le partage de données et une véritable collaboration dans la mesure où d’autres points d’extrémité pourraient être accordés, puis prendre réellement le contrôle du bureau ou de l’application partagé. La plupart des fournisseurs ont proposé des solutions T.120 en intégrant NetMeeting soit directement dans leurs systèmes basés sur PC, soit indirectement avec un PC relié à leurs systèmes Settop non basés sur PC.

T.120 était vraiment une opération en deux étapes. Dans un premier temps, vous pouvez partager votre bureau ou votre application avec d’autres participants à la vidéoconférence. Ces participants verraient ou afficheraient ensuite vos données partagées, mais c’est tout ce qu’ils pouvaient faire, ils ne pouvaient pas interagir ou modifier vos données. La deuxième étape était une véritable collaboration en ce sens qu’une fois que vos données étaient partagées, vous pouviez transférer le contrôle, ou un participant pouvait demander le contrôle et vous pouviez alors leur accorder le contrôle. Une fois le contrôle transféré, ils pouvaient alors changer, modifier ou supprimer vos données comme si c’était les leurs, car ils avaient un contrôle total. Mais à tout moment, vous pouvez reprendre le contrôle. Par conséquent, il s’agit d’une véritable collaboration de données et pas seulement d’un partage de données (visualisation).

Cependant, NetMeeting a été pris en charge pour la dernière fois dans Windows XP et, par conséquent, T.120 a disparu et a été remplacé par la norme H.239 – parfois appelée norme Dual Video.

H.239 est la nouvelle norme de partage de données utilisée par les appareils H.323:

La norme H.239 définit la manière dont les canaux multimédias supplémentaires sont utilisés et gérés par les systèmes de visioconférence H.323. H.239 introduit le concept d ‘«affichage des données», dans lequel les graphiques du bureau du PC sont convertis en un flux multimédia séparé et transmis avec le flux vidéo principal. Le nouveau dénominateur commun est le flux multimédia, donc peu importe si le point final est basé sur un PC ou un settop.

Le point clé ici est que H.239 est le protocole de contrôle tandis que le média réel (contenu) est vidéo et généralement codé en utilisant H.264 AVC, mais pourrait se replier pour utiliser H.263.

Les terminaux prenant en charge H.239 recevront le double flux (graphiques du bureau et vidéo principale), puis afficheront les graphiques du bureau et la vidéo distante dans des fenêtres séparées. Les points de terminaison qui ne prennent pas en charge H.239 afficheront les graphiques du bureau au lieu de la vidéo principale (vidéo distante pour eux) dans une fenêtre, qui peut ne pas être en plein écran, lorsque les données sont partagées. Dès que le partage s’arrête, ces points de fin reviennent à l’affichage de la vidéo principale dans la fenêtre unique.

Mais le bureau, la fenêtre ou l’application partagé était en fait un flux vidéo; donc tout ce que vous pouvez faire est de visionner la vidéo. Vous ne pouvez pas recevoir le contrôle, ni demander le contrôle, puis modifier les données; c’est juste une vidéo de tout ce qui vous est partagé. Donc H.239 n’est pas vraiment une vraie collaboration de données, c’est juste des données affichées.

Cependant, H.239 permet d’inclure l’audio de l’application partagée.

Tous les principaux fournisseurs de produits H.323 prennent en charge la norme double vidéo H.239 dans leurs derniers produits; Cisco (Tandberg) a DuoVideo, Polycom a H.239 People + Content et / ou Polycom People + Content IP (PPCIP) dans leurs gammes RealPresence Group et HDX,  Lifesize prend en charge H.239 dans leur Icon, Express, Team, Room et Les produits Cloud et Yealink ont H.239 dans leurs points de terminaison VC800, VC500, VC Desktop, VC Mobile tandis que le visiophone VP-T49G peut recevoir des données H.239. 

Protocole Binary Floor Control – BFCP – utilisé par les appareils SIP:

Nous utilisons le terme SIP générique pour identifier les appareils qui adhèrent à la norme SIP par opposition aux appareils qui utilisent la version Microsoft de SIP, que nous appelons par souci de clarté (MS-SIP). 

Les points de terminaison SIP utilisent généralement BFCP, qui, comme H.239, envoie efficacement le bureau ou l’application partagé en tant que deuxième flux vidéo que le point de terminaison de réception affiche ensuite dans une deuxième fenêtre ou à la place de la vidéo des «  têtes parlantes  » pendant que le partage est actif. .

Lorsque deux points de terminaison établissent une connexion BFCP, ils doivent déterminer quel point de terminaison agira en tant que serveur de contrôle d’étage, puis l’autre agira en tant que client de contrôle d’étage pour ce flux spécifique. S’il existe deux flux, un point de terminaison doit à nouveau agir en tant que serveur de contrôle d’étage, mais il n’est pas nécessaire qu’il s’agisse du même point de terminaison pour chaque flux.

Si vous regardez une trace du partage d’application, vous verrez quelque chose comme:

m = application 3238 UDP / BFCP *
a = sendrecv
a = setup: actpass
a = connection: new
a = floorctrl: cs

m = application 3238 UDP / BFCP * indique que ce flux de partage d’application particulier est sur le port IP 3238 en utilisant RTP qui est intégré dans les paquets UDP . Et que le flux est en fait BFCP .
a = setup: actpass la connexion n’était pas encore établie; une fois fait, ce serait soit actif, soit passif .
a = connexion: nouveau indique qu’il s’agit d’une nouvelle connexion.
a = floorctrl: cs indique que l’expéditeur est prêt à agir à la fois en tant que client de contrôle d’étage et serveur de contrôle d’étage.

Encore une fois, le point ici est que BFCP est le protocole de contrôle tandis que le média réel (contenu) est vidéo et généralement codé en utilisant H.264 AVC.

Différence majeure de connectivité entre les appareils H.323 (et SIP génériques) et Microsoft Skype Entreprise:

Comme nous pouvons le voir dans ce qui précède, les périphériques H.323 utilisent H.239 pour contrôler le flux multimédia tandis que les périphériques SIP utilisent BFCP pour contrôler le flux multimédia; le média réel étant la vidéo.

Une destination clé entre le fonctionnement de Microsoft Skype for Business est que les appareils H.323 et SIP génériques fournissent le contenu dans la même connexion. Lorsque le contenu est partagé, il prend effectivement la bande passante du flux vidéo principal (têtes parlantes) au sein de la session.

Par comparaison, Microsoft Skype Entreprise utilise généralement Microsofts XH.264UC comme codec pour le flux vidéo principal, G.722 / 2 Stereo comme codec pour le flux audio et RDP ou VbSS pour contrôler le contenu; mais ces flux sont créés dans des connexions séparées, chaque connexion ayant sa propre bande passante allouée.

Avec Skype Entreprise, car le contenu est partagé au sein d’une connexion établie séparément; les sessions audio et vidéo n’ont pas vraiment besoin d’exister pour que SfB puisse partager du contenu. En revanche, les conférences H.323 (et SIP générique) doivent d’abord établir la connexion et le flux vidéo, puis ajouter le flux de contenu à l’appel. 

Microsofts Remote Desktop Protocol – RDP – utilisé par Skype for Business:

Microsoft a développé son protocole de bureau à distance propriétaire – RDP et l’a utilisé dans Lync 2013, Skype for Business 2015 et Skype for Business 2016 pour le partage de bureau et d’application entre clients. En savoir plus sur Skype Entreprise 2016 plus tard, car il prend également en charge une nouvelle méthode de partage. 

RDP est une extension de la norme ITU-T T.128 pour le partage d’applications multipoint qui se trouve sous la norme parapluie T.120 qui était à l’origine utilisée par l’application Microsoft NetMeeting.

Si vous regardez une trace du partage d’application Skype Entreprise, vous verrez quelque chose comme:

m = partage d’applications 58545 TCP / RTP / AVP 127
.
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

m = applicationsharing 58545 TCP / RTP / AVP 127 indique que ce flux de partage d’ applications particulier est sur le port IP 58545 utilisant RTP qui est intégré dans les paquets TCP et attribué un type de charge utile de 127
a = rtpmap: 127 x-data / 90000 indique que PT 127 fait référence pour envoyer les données à une fréquence d’horloge de 90000 Hz.
a = x-applicationsharing-media-type: rdp indique que le média réel est RDP

Partage d’écran basé sur la vidéo Microsofts – VbSS – utilisé par Skype for Business 2016:

Les principales limites de l’utilisation de RDP sont une faible fréquence d’images et une consommation élevée de bande passante. Pour y remédier, Microsoft a développé le partage d’écran basé sur la vidéo – VbSS comme méthode alternative pour le partage de bureau. VbSS est pris en charge par le dernier client Skype Entreprise 2016 de (16.0.6330.1000) trouvé dans Office 2016.

Les principaux objectifs de VbSS sont les suivants:

Rendre le partage d’écran plus fiable par rapport à l’utilisation de RDP
Accélérez la configuration de la session et l’expérience vidéo. RDP peut afficher ~ 3 images par seconde; tandis que
VbSS peut atteindre jusqu’à 30 ips lors de l’utilisation de la vidéo XH.264UC
Fonctionne beaucoup mieux que RDP dans des conditions de faible bande passante; même lors du partage de contenu en mouvement rapide

Pour atteindre ces objectifs, VbSS utilise UDP comme protocole sous-jacent. C’est plus efficace que d’utiliser TCP, ce que fait RDP, à condition que la connexion réseau puisse prendre en charge le trafic sans perte. Il existe également un compromis entre l’intégrité et la netteté de l’image pour la fiabilité, le mouvement et l’efficacité. Mais cela ne devrait pas vraiment être trop évident pour les utilisateurs. En effet, VbSS envoie le contenu comme un autre flux vidéo (de la même manière, mais pas le même que H.239 ou BFCP).

Il est important de savoir que Skype Entreprise 2016 ne remplace pas RDP par VbSS. De plus, il existe certaines restrictions quant au moment où VbSS peut être utilisé. Skype Entreprise 2016 utilise toujours RDP comme solution de secours ou alternative au lieu de VbSS lorsque les circonstances l’exigent.

Il n’y a qu’un seul flux de contenu. Tous les points de terminaison de la conférence doivent prendre en charge et utiliser VbSS; si un client plus ancien qui ne prend pas en charge VbSS se joint, alors tout le monde passe de manière transparente à l’utilisation de RDP
Bien que VbSS soit pris en charge dans les conférences point à point et multipoint, il ne peut être utilisé que lors du partage de bureau. RDP est utilisé lors du partage d’une fenêtre (programme) ou de fichiers PowerPoint.
Le partage de contenu avec VbSS fournit un flux vidéo en lecture seule. Si un point de terminaison est donné ou demande de prendre le contrôle à distance, la session reviendra de manière transparente à l’utilisation de RDP
Une fois qu’une session passe de l’utilisation de VbSS à RDP; il ne revient pas. Pour utiliser à nouveau VbSS, la session partagée doit être arrêtée et redémarrée

Par conséquent, dans une trace de partage d’application Skype Entreprise 2016, vous verrez à la fois RDP et VbSS publiés dans l’ instruction SDP (Session Description Protocol). Cela permet à la session de passer de manière transparente de l’utilisation de VbSS à RDP.

La première partie montre que le nouvel attribut de niveau de session a = x-mediabw avec m = applicationsharing pour annoncer RDP ressemblera à quelque chose comme:

Content-Type: application / sdp
Content-Transfer-Encoding: 7bit
Content-ID: <037525b415ce510283b11781d2fe0dc8>
Content-Disposition: session; traitement = optionnel
v = 0
o = – 0 1 IN IP4 52.112.129.146
s = session
c = IN IP4 52.112.129.146
b = CT: 99980
t = 0 0
a = x-mediabw: applicationsharing-video send = 12000; recv = 12000
m = partage d’applications 58956 TCP / RTP / AVP 127
a = ice-ufrag: lOMR
a = ice-pwd: FNRu1flT4UadfkHOKad0ivnK
.
— liste complète des candidats TCP pour les données RDP et crypto —
.
a = setup: passif
a = connection: new
a = rtcp: 58956
a = mid: 1
a = rtpmap: 127 x-data / 90000
a = rtcp-mux
.
a = x-applicationsharing-session-id: 1
a = x-applicationsharing-role: partageur
a = x-applicationsharing-media-type: rdp
a = x-applicationsharing-contentflow: sendonly
.

m = applicationsharing 58956 TCP / RTP / AVP 127 indique que ce flux de partage d’ applications particulier est sur le port IP 58956 utilisant RTP qui est intégré dans les paquets TCP et attribué un type de charge utile de 127
a = rtpmap: 127 x-data / 90000 indique que PT 127 fait référence pour envoyer les données à une fréquence d’horloge de 90000 Hz.
a = x-applicationsharing-media-type: rdp indique que le média réel est RDP

Ensuite montre la partie VbSS supplémentaire qui annonce la nouvelle session multimédia à l’aide de l’ instruction m = video et les deux nouveaux a = label: applicationsharing-video et a = x-mediasettings: attributs pour VbSS.


m = vidéo 56573 RTP / AVP 122123
c = IN IP4 52.112.129.178
a = plage x-ssrc: 682792806-682792905
a = rtcp-fb: * envoi de l’application x-message: src, x-pli recv: src, x -pli
a = rtcp-rsize
a = label: applicationsharing-video
a = ice-ufrag: w6i1
a = ice-pwd: wtuIQtPW + 92Ycl1DYcDkrHWh
a = x-mediasettings: applicationsharing-video = requis
.
— liste complète des candidats UDP et TCP pour les données VbSS et crypto —
.
a = rtcp: 57439
a = sendonly
a = rtpmap: 122 X-H264UC / 90000
a = fmtp: 122 packetization-mode = 1; mst-mode = NI-TC
a = rtpmap: 123 x-ulpfecuc / 90000
a = rtcp- mux

m = vidéo 56573 RTP / AVP 122123 indique que ce flux vidéo particulier est sur le port IP 56573 utilisant RTP et l’ordre de préférence est d’utiliser le codec vidéo avec le type de charge utile de 122 , puis 123
a = rtpmap: 122 X-H264UC indique que 122 est la version spécifique PT pour Microsofts de H.264 SVC, la même que celle utilisée pour la «vidéo des têtes parlantes».
/ 90000 indique la fréquence d’horloge et est utilisé par tous les codecs vidéo Lync répertoriés.
packetization-mode = 1 indique que UCConfig Mode 1 est le mode d’évolutivité SVC maximum pris en charge.

UCConfig Mode 1 est la capacité d’encoder des couches temporelles séparées dans un seul flux vidéo par résolution. Cela dit, avec le partage de contenu VbSS, il n’y a qu’une seule résolution.

La résolution maximale prise en charge par H.264 SVC est de 1920×1080 (1080p) à 30 ips. Mais cela n’est pas annoncé dans la déclaration du SDP et il n’y a pas de moyen facile d’identifier ce que cela peut être. H.264 SVC nécessite un codage et un décodage par les clients SfB respectifs; la résolution qui peut être obtenue dépend donc vraiment des capacités matérielles des clients SfB. 

Problèmes lors du partage entre SIP et Skype Entreprise:

Les applications de visioconférence basées sur les normes SIP (et H.323) n’utilisent généralement PAS RDP ou VbSS . Par conséquent, cela présente l’un des nombreux défis à surmonter lors de l’intégration de clients Skype Entreprise et / ou Lync 2013 avec des systèmes de visioconférence SIP (et / ou H.323), en particulier si vous souhaitez afficher le point de terminaison SIP (voir) l’application partagée des clients Skype Entreprise.

L’envoi de contenu dans l’autre sens et le partage du bureau ou des applications des points de terminaison SIP (ou H.323) avec un client Skype Entreprise ou Lync 2013 est un problème légèrement moindre car ceux-ci utilisent généralement BFCP ou H.239 qui envoie efficacement le bureau ou l’application en tant que deuxième flux vidéo que le client Skype Entreprise ou Lync 2013 peut comprendre et afficher dans une deuxième fenêtre ou à la place de la vidéo «têtes parlantes» lorsque le partage est actif.

Le problème principal ne concerne pas les flux multimédias (vidéo, audio, données) utilisés par les différents terminaux, mais les flux de signalisation (protocole). Une solution consiste à utiliser une infrastructure vidéo supplémentaire pour transcoder entre les différents points de terminaison, les médias respectifs et les flux de signalisation. Mais cela peut être coûteux, surtout si vous devez fournir et prendre en charge votre propre infrastructure sur site. Une alternative à votre propre infrastructure consiste à utiliser une solution Cloud telle que Lifesize Cloud qui fournit tout sur la base d’un abonnement.

L’autre option consiste à utiliser un point de terminaison qui prend en charge H.323 et l’intégration native avec Skype Entreprise. La série Polycom RealPresence Group avec l’option d’intégration Microsoft fournit une telle solution. Avec le dernier logiciel (v6.1.7) et l’option d’intégration, RealPresence Group prend en charge nativement à la fois la signalisation Microsoft RDP et VbSS et les médias SVC Microsofts H.264. Il peut désormais s’inscrire auprès des serveurs Skype Entreprise sur site ou utiliser un abonnement Office 365. Pour ces serveurs, le système RealPresence Group ressemble à n’importe quel autre client Skype Entreprise 2016. Par conséquent, le système RealPresence Group peut effectuer des appels H.323 vers d’autres points de terminaison H.323 ou il peut passer des appels Skype Entreprise avec d’autres clients Skype Entreprise.

Si le système RealPresence Group participe à une conférence MS-SIP avec un client Skype Entreprise 2016, les deux peuvent utiliser VbSS pour envoyer ou recevoir le partage de bureau; et cela peut aller jusqu’à 1080p30 s’ils utilisent un support SVC H.264. 

Remarque : le système RealPresence Group ne peut pas effectuer d’appels SIP génériques s’il est enregistré auprès de Skype Entreprise. En effet, Skype Entreprise utilise la version Microsoft de SIP (MS-SIP) et le groupe RealPresence ne peut être configuré que pour utiliser une seule version de SIP, MS-SIP ou SIP générique.