H.239 Data Sharing when Video Conferencing


Overview:

When Video Conferencing (including desktop application sharing), there must be a common denominator between platforms in the conference so that they can all effectively communicate and understand the traffic that is sent and received.

The purpose of this paper is to explain H.239 Data Sharing in greater detail and how it differs from the older T.120 standard previously used via NetMeeting.

It is assumed that the reader has a general knowledge of Video Conferencing systems and the standards involved. However, the following technical papers are available to provide more information on these topics:

Terminology - be clear about what you mean:

When we talk about data or application sharing or collaboration, we need to be clear as to what we really mean. This is because, depending upon what system we use, data sharing might really mean data showing; or data collaboration might actually be data sharing and not true collaboration were we hand over control of the shared application to someone else. The distinction will hopefully become clearer as you read this paper.

The old T.120 Data Sharing standard has gone:

For Data Sharing (complete desktops, windows or applications), the ITU initially approved the T.120 standard. The basis of T.120 was originally developed and put forward by Microsoft.

T.120 allows data sharing and true collaboration to the extent that another endpoints could be granted and then actually take control of the shared desktop or application. Most vendors offered a T.120 solutions by integrating NetMeeting either directly into their PC based systems or indirectly with a PC linked to their non-PC based Settop systems.

T.120 was really a two stage opeartion. In the first stage, you could share your desktop or application with other participants in the video conference. These participants would then see or view your shared data, but that's all they could do, they couldn't interact or change your data. The second stage was true collabration in that once your data was shared, you could then hand control over, or a participant could request control and you could then grant control to them. Once control was handed over, they then could change or edit or delete your data as if it was theirs as they had full control. But at any time you could take back control. Hence, this is true data collaboration and not just data sharing (viewing).

However, NetMeeting was last supported in Windows XP and hence T.120 has gone and been replaced by the H.239 standard - sometimes referred to as Dual Video standard.

H.239 is the new data sharing standard used by H.323 devices:

The H.239 standard defines how additional media channels are used and managed by H.323 Video Conferencing systems. H.239 introduces the concept of 'data-showing', whereby the PC desktop graphics is converted into a separate media stream and transmitted along with the main video stream. The new common denominator is the media stream, so it does not matter if the endpoint is PC or settop based.

Endpoints that support H.239 will receive the dual stream (desktop graphics and main video) and then display the desktop graphics and far-end video in separate windows. Endpoints that don't support H.239 will display the desktop graphics instead of the main video (far-end video to them) in one window, which may not be full screen, when data is shared. As soon as sharing stops, these endpioints will then revert back to displaying the main video in the single window.

But the shared desktop, window or application was actually a video stream; so all you can do is view the video. You cannot be handed control, or request control and then change the data; its just a video of whatever is being shared to you. So H.239 is not really true data collaboration, it's just data showing.

All the major vendors support the H.239 Dual Video Standard in their latest products; Cisco (Tandberg) have DuoVideo, Polycom have H.239 People+Content and/or Polycom People+Content IP (PPCIP) in their RealPresence Group and HDX series, Lifesize have H.239 support in their Icon, Express, Team, Room and Cloud products and Yealink have H.239 in their VC800, VC500, VC Desktop, VC Mobile endpoints whilst the VP-T49G Video Phone can receive H.239 data. 

Binary Floor Control Protocol - BFCP - used by SIP devices:

SIP endpoints typically use BFCP, which like H.329, effectively sends the shared desktop or application as a second video stream that the receiving endpoint then displays in either a second window or in place of the 'talking heads' video whilst the sharing is active.

When two endpoints establish a BFCP connection, they must determine which endpoint will act as a floor control server, then the other will act as a floor control client for that specific stream. If there are two streams, then again one endpoint must act as the floor control server, but it does not have to be the same endpoint for each stream.

If you look at a trace of the application sharing, you will see something like:

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

m=application 3238 UDP/BFCP * indicates that this particular application sharing stream is over IP Port 3238 using RTP that's embedded in UDP packets. And that the stream is actually BFCP.
a=setup:actpass the connection was not yet established; once done, this would be either active or passive.
a=connection:new indicates that it is a new connection.
a=floorctrl:c-s indicates that the sender is willing to act both as a floor control client and floor control server.

Microsofts Remote Desktop Protocol - RDP - used by Skype for Business:

Microsoft developed their proprietary Remote Desktop Protocol - RDP and used it within Lync 2013 and Skype for Business 2015 for Application Sharing between clients. RDP is an extension of the ITU-T T.128 standard for Multipoint Applications Sharing that sits under the T.120 umbrella standard that was originally used by Microsofts NetMeeting application.

If you look at a trace of the Skype for Business application sharing, you will see something like:

m=applicationsharing 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 indicates that this particular applicationsharing stream is over IP Port 58545 using RTP that's embedded in TCP packets and assigned a Payload Type of 127
a=rtpmap:127 x-data/90000 indicates that PT 127 refers to sending the data at a clock rate of 90000Hz.
a=x-applicationsharing-media-type:rdp indicates that the actual media is RDP

Sharing between SIP and Skype for Business:

SIP (and H.323) standards based videoconferencing applications typically DO NOT use RDP. Hence, this presents one of the many challenges that needs to be overcome when integrating Skype for Business 2015 and Lync 2013 clients with SIP (and/or H.323) videoconferencing systems, especially if you want the SIP endpoint to display (see) the Skype for Business clients shared application.

Sharing the SIP (or H.323) endpoints desktop or applications with a Skype for Business 2015 or Lync 2013 client is a slightly lesser issue as these typically use BFCP or H.329 that effectively sends the desktop or application as a second video stream that the Skype for Business 2015 client can understand and display in either a second window or in place of the 'talking heads' video whilst the sharing is active.

The main issue is not with the media (video, audio, data) streams used by the different endpoints, it's with the signalling (protocol) streams. One solution is to use additional video infrastructure to transcode between the different endpoints respective media and signalling streams. But this can be expensive, especially if you have to provide and support your own On-Premise infrastructure. An alternative to your own infrastructure is to use a Cloud solution such as the Lifesize Cloud that provides everything on a subscription basis.

The other option is to use an endpoint that supports H.323 and native integration with Skype for Business. The Polycom RealPresence Group 310 with the Microsoft Integration option provides such a solution. With the latest software (v6.1.2) and integration option, the RealPresence Group natively supports Microsoft RDP signalling and Microsofts H.264 SVC media. It can now register with either Skype for Business On-Premise servers or use an Office 365 subscription. To these servers, the RealPresence Group system looks like any other Skype for Business client. Hence, the RealPresence Group system can make either H.323 calls to other H.323 endpoints or it can makes Skype for Business calls with other Skype for Business clients.

Note: the RealPresence Group system cannot make generic SIP calls if it is registered with Skype for Business. This is because Skype for Business uses Microsoft's version of SIP (MS-SIP) and the RealPresence Group can only be configured to use one version of SIP, either MS-SIP or generic SIP.