Desktop Sharing Call Flows

마지막으로 수정된 항목: 2009-03-10

The following topics describe how the signaling and media flows are established in several basic desktop sharing examples.

Creating a Desktop Sharing Conference

As noted earlier, a desktop sharing session between two Office Communicator clients is a peer-to-peer session from the point of view of the RTP remote display and keyboard/mouse data; however, SIP control data still is proxied by each user’s Front End Server.

The following figure shows a call flow between two Office Communicator clients. Both clients in the example are on the internal network, and both belong to the same Office Communications Server pool. The clients have already established an IM session with each other, and then User1 clicks the Share Desktop control.

This action causes User1’s Office Communicator client to send a SIP INVITE message containing the following Session Description Protocol (SDP) data, including a list of ICE candidates, to User2’s Office Communicator client to indicate that User1 wants to share his or her desktop with User2:

v=0
o=- 0 0 IN IP4 192.168.100.20
s=session
c=IN IP4 192.168.100.20
b=CT:99980
t=0 0
m=applicationsharing 4636 TCP/RTP/AVP 127
a=ice-ufrag:Ze3C
a=ice-pwd:s0a6z9xeF6+wQvu6lCDen9oG
a=candidate:1 1 TCP-PASS 2120613887 192.168.100.20 18608 typ host 
a=candidate:1 2 TCP-PASS 2120613374 192.168.100.20 18608 typ host 
a=candidate:2 1 TCP-ACT 2121006591 192.168.100.20 4636 typ host 
a=candidate:2 2 TCP-ACT 2121006078 192.168.100.20 4636 typ host 
a=cryptoscale:1 client AES_CM_128_HMAC_SHA1_80 inline:7Qze/34RrnOBYwHVlcXWGdmlBYX7yvehzzoV4k3p|2^31|1:1
a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:3t/fXZ5Fjho3/lkMea1c2xNhTfJxYGAM2KU/VGdu|2^31|1:1
a=setup:active
a=connection:new
a=rtcp:4636
a=mid:1
a=rtpmap:127 x-data/90000
a=x-applicationsharing-session-id:1
a=x-applicationsharing-role:sharer
a=x-applicationsharing-media-type:rdp

If User2 accepts the invite, his or her Office Communicator client sends back an OK with a list of ICE candidates. Both clients evaluate the ICE candidate pairs. User1 then sends a new SIP INVITE message containing the winning IP address for his or her computer, and User2 returns a 200 OK message with the winning IP address for his or her computer. By using this information, the two Office Communicator clients establish an SRTP session over TCP between the two negotiated endpoints, and User1 sends an RDP stream that mirrors his or her desktop to User2 over the SRTP channel.

Adding a User to a Desktop Sharing Conference

Continuing on with this same example, User1 needs to add a third participant, User3, to the existing desktop sharing meeting with User2. (In this example, User3 is also in the same pool as User1 and User2.) User1 clicks the Invite button, clicks Invite a Contact, and then clicks User3.

At this point, the meeting must transition from a peer-to-peer session to a multiparty conference, with IM traffic routed through an IM Conferencing Server and the desktop sharing traffic through an Application Sharing Conferencing Server.

This transition starts when User1’s client sends a SIP SERVICE message to its Front End service specifying a new conference ID and a request for a Focus and conferencing servers for the possible meeting modalities (IM, Web conferencing, A/V conferencing, and application sharing).

The Focus Factory provisions a meeting Focus and writes it to the back-end database. User1 then sends a SIP INVITE to the Focus. The Front End Server instantiates the Focus on one of the Front End Servers in its pool, which in turn communicates with an Conferencing Server Factory in that pool to have specific conferencing servers assigned to it.

In this example, only the IM Conferencing Server and the Application Sharing Conferencing Server are required. The Focus communicates with both, adds a conference to each, and then registers a channel in each for User1.

Meanwhile, User1’s client sends a SIP SUBSCRIBE message to the Focus, which returns the details of the conference. Subsequent SIP INFO messages sent to the Focus return additional provisioning data to User1’s client.

At this point User1’s client send a SIP INVITE message to the IM Conferencing Server, thereby establishing a session with it, and it also sends a SIP INVITE to the Application Sharing Conferencing Server containing an SDP message with its ICE candidates. As described earlier for the peer-to-peer session, User1’s client and the Application Sharing Conferencing Server evaluate the candidates, after which User1’s client sends a new SIP INVITE message containing its winning candidate and the Application Sharing Conferencing Server then replies with its winning candidate. The SRTP session is then established over TCP between the two negotiated endpoints.

Next, User1’s client sends a new SIP INVITE message, which contains the URI of the meeting Focus, to User2’s client. User 1’s client also exchanges SIP BYE messages with Client2, causing it to drop the earlier TCP/SRTP/RDP session.

Now User2’s client sends a SIP INVITE to the Focus, obtains the conference information, and requests that the Focus add User2 to the IM Conferencing Server and the Application Sharing Conferencing Server. User2’s client sends a SIP SUBSCRIBE request to the Focus and then invites the IM Conferencing Server and the Application Sharing Conferencing Server in the same manner as User1’s client.

In the last stage of the process, User1’s client sends a SIP INVITE message, which contains the URI of the meeting Focus to User3’s client, and then ends the session with a SIP BYE. User3’s client uses the obtained URI to send a SIP INVITE message to the Focus and joins the meeting and conferencing servers in exactly the same way as User2’s client did.

As this point, all three users are connected to the Focus, the IM Conferencing Server, and the Application Sharing Conferencing Server. User1 is sharing his or her desktop, which is sent over the TCP/SRTP channel to the Application Sharing Conferencing Server, where it is repeated back to the clients of User2 and User3. The Focus publishes the meeting roster to the clients, which now shows User1 currently sharing his or her desktop.

참고

In the following diagrams, the SIP ACKs and some other traffic have been skipped for readability.

 

Desktop Sharing Session Control

The user who initiates desktop sharing has full control over his or her computer, and by default the other participants can only view the shared desktop or selected monitor. If the sharer wants to give another participant control, he or she can give that individual control, while other participants can only view the desktop. The user who initiates sharing can also choose to share control with all participants, but there is no way to allow a subset of participants to have control; it is granted either to one participant at a time or to all participants.

If the sharer clicks Share Control with All Participants, it requires communication and cooperation between the participants, because any attendee can seize control at any time. The sharer, however, can rescind shared control at any time, which again gives him or her sole control of the desktop. The following flow chart shows how control of sharing works.

Office Communications Server 2007 R2 permits only one participant’s desktop to be shared at a time. If another participant shares his or her desktop, the original sharer’s desktop session is closed and replaced by a view of the new sharer’s desktop. This is not something the meeting leader can control. All meeting participants whose meeting policy settings include Enable program and desktop sharing can cause an existing sharing session to terminate and be replaced with their own shared desktop or monitor.

참고

Communicator Web Access users have a similar sharing and remote control experience, except that users with multiple monitors cannot select a single monitor; they can share their entire desktop only. Also, the sharer’s assigned meeting policy determines whether anonymous users can take control of his or her desktop.